>Even IBM has moved away from customers doing SMP/E installations. >They deliver pre-built SMP/E environments.
Pre-built simply means IBM did the SMP/e work for you (along with other customization task). IBM did not move away from SMP/e. z/OS will always be maintained using SMP/e. >Does the install even need to be SMP/E? >Would e.g. a non-SMP/E portable software instance >be easier for both you and your customers? >Build on your systems and deliver the results. SMP/e is consistent and sysprogs plan maint around it. It's fairly simple to create very basic SMP/e install / maint but I (and I suspect Kurt) aren't recommending this approach but the choice is up to you if it's meets your customer's needs. If you don't want to use SMP/e bells & whistles, then remember that SMP/e uses the same utilities (e.g. binder, iebcopy, zip, ...). 1. If you must use LIBRARY, then use DDN instead of path. Customers must never specify anything in JCLIN (even &volser). Binder and SMP/e support LIBRARY DDN. Your dev can should change to this method. 2. If you always ship your entire archive instead of updating specific modules in the archive, then forget about LIBRARY and simply link your load modules on your machines and ship the module without the archive. SMP/e and binder are built to handle this situation. Important note: only link your archive into the module because other things may be site dependent (e.g. LE, MIGLIB, ...). If we are to be of help, we need to know more about your process. Keep it short because but having 2 statements of ??? from the link tells us very little. We know nothing of the execs that build your product. We don't even know if you apply (or how you create) PTFs. > But some customers insist, "Fix no problem other than the > one I reported!" Fear of collateral damage results in > regenerative maintenance phobia. ROTFLOL, customers can easily be like Unix and fix 1,000 problems at once by applying 1,000 PTF. Standard vendor practice is 1 problem = 1 apar. It's not for the Customer. We guarantee 99.9999999% uptime. Customers have confidence knowing they can fix that problem on a live system. It stops vendors from doing cleanup because I'm working on that code. >With a non-SMP/E full replacement delivery, I can identify and check out >and test the exact code you're running. In an ideal world, the focus would be on z/OS vendors instead of customer needs. I had an english friend who fixed German industrial lathes in non-germanic countries because Germans won't fix improperly maintained equipment. If you don't have the proper bolt, then you must wait 2 days for the new one. His job was to fix lathes where customers would use a steel bar instead of waiting. >But I do need to document that "If you want to use SMS You cannot adequately document using SMS. Customers who want to use SMS within product install & maintenance will have already designed that strategy. They already know exactly how to make those changes in your jcl and know the consequences. You don't want to cause problems for customers who don't understand the consequences. >There are hundreds of modules, not all of which we need. If you link each module locally with your archive, then SMP/e will happily handle this module that includes everything. Alternatively, you could look at the binder listing to write the INCLUDEs that occurred automatically and add them to the JCLIN. >> //SYSLMOD DD PATH='/path/name/irrelevant' >> //*LIBRARYDD=UNIXLOAD > > Not a sysprog (well, not a z/OS sysprog), so I'm not accustomed to anything > like that. LIBRARYDD is part of JCLIN and falls completely under your purview. More important, I keep stressing DDDEF instead of paths. LIBRARYDD allows you to use your binder statements from dev and have it compatible with SMP/e. Do you want to change your binder JCL to //SYSLMOD DD DSN='ignore.ignore.UNIXLOAD' every time you build the JCLIN or is it better to code //*LIBRARYDD once? It's a comment to binder but not SMP/e. >>some things are not heavily used nor complete. >> Do you think LIBRARY doc is going to be robust like INCLUDE? > > Why would I have any opinion about LIBRARY vs. INCLUDE? > Both are statements. Why would I expect one to be better documented than > another? LIBRARY is so seldom used that Kurt didn't know SMP/e supported it. Pitfalls with LIBRARY are not well documented because of the lack of use. INCLUDE requires more effort but it ensures SMP/e knows about everything used from the library. >Again, I'm lost. "partially under SMP/E control"? >And who said anything about changing occurrences after installation? Your archive contains objects that aren't defined to SMP/e. As for changing occurrences, your LIBRARY statement contains a path name. Sysprogs probably don't know how to change and you will need to document it. More important, they won't think about it. UCLIN DDDEF is the method sysprogs use to modify paths and filenames. You're creating an exception to the rule. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
