>Jon Perryman wrote, in part: >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.
Well, that's why I'm here. As I said, the person who added the LIBRARY stuff did so without consultation or documentation and then left. Apparently he hacked it into sorta working, but isn't doing it correctly from a theological perspective. The whole point of this thread is to figure out what we're doing wrong and how to make it better; calling it "evil" seems...unproductive. >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? I never wanted a customer to have to update the JCLIN. That was the whole point of the variables: to avoid that (and also to minimize changes required to the SMP/E jobs themselves). >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. I don't think I ever used the word "clone"? Not sure what you're saying there. >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? Again, I never said it was. I said this is what it does currently. If LIBRARY MYLIB and DDDEF MYLIB will solve it, great; that would let us use the variables in the ALLOC job as desired. This is a useful clue, I can dig into it, thanks. >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). There are hundreds of modules, not all of which we need. This code runs on a dozen or so platforms, and has many long entry point names to boot. So we need it to autocall--otherwise every time we pick up a new version of the common code we'll have a nightmare of adding INCLUDEs. Yes, I wish that was different, but it's just not realistic to INCLUDE each module. >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. Why would I have any opinion about LIBRARY vs. INCLUDE? Both are statements. Why would I expect one to be better documented than another? I'm baffled. 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. Again, I'm lost. "partially under SMP/E control"? And who said anything about changing occurrences after installation? I don't understand what you're seeing that I'm not saying, dude. >This is definitely not a relfile. You say your customers copy & modify >this JCLIN. No I didn't. I said that was ONE OPTION that I would prefer not to have to follow. >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? Again, your token window seems small--I was asking recently about SMS vs. VOLSER and folks here convinced me that I didn't need to worry about SMS. But I do need to document that "If you want to use SMS, look for the &VOLSERs and fix it there". That's ALL I'm going to say about it -- at that point they're on their own. I appreciate the input, though I'm baffled by some of your inferences/implications. The DDDEF sounds promising! And yes, I'm sure that was mentioned before but without enough context for me to grok what it meant. Y'all are way more familiar with SMP/E than I am, obviously, and thus I'm fumbling around here. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
