On Tue, 18 Nov 2025 19:24:00 -0500, Mike Shaw <[email protected]> wrote: >On Tue, Nov 18, 2025, 6:13 PM Phil Smith III <[email protected]> wrote:
>> The F1 relfile is the JCLIN data. Ours includes: >> //SYSLIN DD * >> LIBRARY '&USSPATH.lib/libsapi.a' >Why not put the JCLIN content after a ++JCLIN statement within the function >SYSMOD itself, rather than as a RELFILE? JCLIN is not JCL despite looking the same. SMP/e ignores much of the supplied JCL in JCLIN and interprets very specific parts for specific SMP/e definitions. There's much confusion here with SMP/e. I'll cover a few obvious points that are causing confusion. Phil didn't supply enough JCLIN but I'll make some educated guesses about his intent. It's been a long time since I packaged a product so things may have changed somewhat. 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. 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. 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. 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). This is by no means a complete list. >> but all I get out of it is "It's not that easy". Correct? >ACS, SMS definitions are site defined with no IBM defaults. >DSN=SMPE*.** going to SMPE* volumes. 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
