Jon Perryman wrote, in part: >1. IBM discourages the use of the LIBRARY statement in JCLIN. Is there >a reason why LIBRARY DDN won't work because DDN is the SMP/e preferred >method? See "Standard Packaging Rules for z/OS-Based Products" >https://publibz.boulder.ibm.com/epubs/pdf/gimpkg80.pdf which is old >but I suspect is still relevant. Maybe you can find a more current >version.
But the book also says: >Normally, LIBRARY statements should not be used in JCLIN data. An >exception is when the CALLLIBS operand is specified on the JCLIN >command or ++JCLIN MCS, or when //*CALLLIBS=YES is encountered after a >job card preceding a link-edit step. And we have //*CALLLIBS=YES The book goes on to say: >A LIBRARY statement should be used only if a SYSLIB DD statement is >also used. Which we also have. >2. Customers should never have the ability to modify functions nor >PTFs.. "&USSPATH.lib/libsapi.a" is unacceptable. Functions, PTFs and >more belong to you. They should never be under the customer's control. libsapi.a is a library we provide, that lives in USS. We can't tell the customer "It must be put in /x/y/z/". So I don't understand this assertion. We also don't tell them on the MVS side "You must put the code in ABC.DEF.LOADLIB", same thing, no? >3. Never use hardcoded paths (e.g. /usr/lib/libsapi.a) in your >functions or PTFs. Instead, use relative paths (e.g. >../../lib/libsapi.a or ./lib/libsapi.a) where possible. I'm guessing >that libsapi.a is not part of your product which should be referenced >through a DDN instead of a path. As a last resort, you supply the >customer with UCLIN that modifies the appropriate SMP/e object because >customers must never modify your PTFs nor functions. Well, since you guessed wrong, I'm not sure how to interpret this. >4. I'm guessing that F1 is not a relfile. Instead, it is most likely >job to install your tape or it's a PDS with multiple install jobs. >Nothing of the function or PTF should be in F1 because they must never >be modified by customers. That job will contain UCLIN that allows >customers to define their environment (e.g. DDN's). F1 contains only the JCLIN. >While SMS is simple, guiding your customers to make wise choices is >the hard part. I suspect that no one is using SMS for their important >products because of the problems it introduces. You should ask people >what they find useful. I personally believe categories of datasets is >most useful. For instance, they might find the following categories >useful (target runtime, target non-runtime, target smp, dist libraries >including smp, global smp). They may want the ability to use a common >global smp. What we've seen before is that people use varied locations for vendor products, so we're trying to be as flexible as possible while making it as simple as possible. Y'all convinced me that trying to accommodate SMS was madness; current plan there is to use &VOLSER and tell them in the doc, "If you don't want the entire product on a single volume and/or want to use SMS to allocate the data sets, look for &VOLSER in the jobs and update as appropriate". ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
