On Wed, 19 Nov 2025 09:11:19 -0500, Phil Smith III <[email protected]> wrote: >Jon Perryman wrote, in part:
>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. Phil, you are doing the most evil thing possible in SMP/e and you need to spend time understanding the concepts to avoid damaging your product at a customer site. If you must use LIBRARY, then at least use it correctly for SMP/e. SMP/e provides multiple solution to solve this problem correctly but this is not one of them. We've only seen a very small snippet of your install process so it's difficult to say what works best in your situation. Sysprog question: Is there any one of you that would think to update JCLIN every time you create a new maint environment for his product? Is your expectation to only modify DDDEF or are there additional consideration? 1. Stop thinking in terms of cloning because that's a zVM and zLinux concept where you're applying maint to a live system. In z/OS, maint is applied to inactive copies of products. 2. What makes you think LIBRARY /x/y/z/ in JCLIN is your only solution? Wouldn't LIBRARY MYLIB in JCLIN and UCLIN DDDEF MYLIB /x/y/z/ work equally as well while supporting standard maint philosophy? 3. I have to agree with Kurt about using INCLUDE instead of LIBRARY. Critical products typically specify NCAL which ignore syslib autocall, AUTOCALL and LIBRARY in SMP/e and binder for a reason. As you say, libsapi.a is "your" library that in theory you distribute using SMP/e. You should be telling SMP/e about the contents of that library to be consistent during your update process, the binder should be verifying using those same includes. SMP/e can bury problems that customers may not notice (e.g. NCAL rc=8). >The book goes on to say: This SMP/e book says many things but some things are not heavily used nor complete. Do you think LIBRARY doc is going to be robust like INCLUDE? I'm happy that you've gone 10 years without a problem but I'm a little surprised. >>I'm guessing that libsapi.a is not part of your product which should be >>referenced >>through a DDN instead of a path. >Well, since you guessed wrong, I'm not sure how to interpret this. I guessed wrong because your libsapi.a is partially under SMP/e control and partially not. Common practice is to be consistent and have 1 customer change to redefine the location (namely DDDEF). Instead, the customer must change all occurrences after the product is installed. > >>4. I'm guessing that F1 is not a relfile. >F1 contains only the JCLIN. This is definitely not a relfile. You say your customers copy & modify this JCLIN. >>While SMS is simple, guiding your customers to make wise choices is the hard >>part. >> 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; Does anyone here know of anyone using SMS instead of VOLSER to install products? Phil, do you have customers asking to install using SMS instead of VOLSER? It's simple to accommodate SMS but critical products are installed using VOLSER. The problem is having 3 systems in a SYSPLEX but you only want 1 using the newest updates for 1 product. Using SMS requires DSN changes instead of simple Using &VOLSER instead of &DISTVOL, &RUNVOL, &TARGVOL and &GLOBVOL means that your customers must determine when each dataset is needed. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
