My suggestion, as someone who has converted application programs to SMP/E packaging in the past, is to be sure allocate your own CSI sandbox, with your own zones, distribution libraries, and target libraries, where you can play, experiment, and test without affecting anyone else on the system. --Roger
On Fri, Sep 11, 2015 at 10:31 AM, Ed Gould <[email protected]> wrote: > Charles, > about 15 years ago we had a european product foisted up on us from a user. > This was not SMP installable. > The boss told me to try and install it. > It was a so so installation some minor gotchas but it went reasonably > smoothly.. > I ran into a problem with it in execution (detail are blurred by now). I > contacted the author and was told to hand link edit one of their modules > outside of SMPE . I said that is iffy for this but what about the rest of > the product if we run into any issues? The answer was yes we have had > issues with that and that is the way the product works. > I got off the phone and told my boss and he told me to drop it as the > product must be completely SMPe maintainable. > He told me to write him a memo and explain the issues and he forwarded it > up to his boss and the answer came back to delete the product. > > Ed > > ps: I am replying to you directly as my reply to IBM-Main have been > bouncing and since no one is owning IBM main anymore I don't know who to > complain to. > > > > On Sep 11, 2015, at 10:26 AM, Charles Mills wrote: > > I assume one of the reasons you are venturing down this road is not so >>> much because >>> you (or your customers) think the initial install of your software in >>> SMP/E format is >>> very exciting, but rather because of the prospect of follow-on service >>> in PTF format. >>> >> >> I can't speak for the OP but I can speak to our own recent expedition >> into the wonderful world of building for SMP/E. No, the motivation had >> nothing to do with PTFs. We have a pretty simple product and for us, so far >> at least, for better or worse every fix consists of either (1) a change to >> configuration files in character form, so the change can be e-mailed as a >> simple text file or snippet with some edit instructions; or (2) an entire >> new build just like a new installation but with a JCL process that does not >> clobber existing customer parms. >> >> No, the motivation was customer requests. I said to a customer sysprog "I >> thought our IEBCOPY install was pretty good." He said "it's great, and >> SMP/E is a pain in the [butt], but it's a consistent pain in the [butt]. >> Every vendor's IEBCOPY install is unique." >> >> Customers -- especially the largest customers -- don't IMHO by-and-large >> love SMP/E, but they know it and live and breathe it, and they want vendor >> products delivered that way. >> >> Charles >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Kurt Quackenbush >> Sent: Friday, September 11, 2015 8:09 AM >> To: [email protected] >> Subject: Re: SMP/E Help >> >> I need some help with SMP/E. I need to convert our software to use >>> SMP/E. I am not a SMP/E heavy. I have the following; >>> >>> 1. Linklib >>> 2. Proclib >>> 3. Parmlib >>> 4. JCLLIB ( for install ) , this can be removed , because SMP/E will >>> do it 5. Rexx Clistlib >>> >> >> Further thoughts on the process of packaging your software in SYSMOD >> format: I assume one of the reasons you are venturing down this road is >> not so much because you (or your customers) think the initial install of >> your software in SMP/E format is very exciting, but rather because of the >> prospect of follow-on service in PTF format. Therefore, you must consider >> how you intend to supply parts/files later in PTFs before you create your >> initial FUNCTION SYSMOD. >> >> In my opinion, most parts/files ("elements" in SMP/E terminology) are >> very simple to package and install. Using your example, procs, parmlib >> members, sample JCL, execs, are all very simple to manage, package, and >> install, because they are just members of a partitioned data set that are >> copied and replaced by SMP/E. It is modules and load modules that cause >> the most grief. >> >> Traditional z/OS software is SMP/E packaged using MOD elements to >> describe modules that get link edited during the APPLY to create load >> modules (load modules or program objects). It is link edit steps in JCLIN >> that tells SMP/E how to put the MODs together to create these load >> modules. This is all a very well grooved path, but, JCLIN and MODs can be >> a great pain, and I'd say the cause of most grief for packagers and >> installers. >> >> You can greatly simplify you and your customers' efforts if you can avoid >> MODs and JCLIN altogether. That is, it is far simpler to package complete >> load modules using PROGRAM elements rather than as individual MODs with >> JCLIN. PROGRAM elements treat load modules as simple members of a >> partitioned data set that can be copied and replaced. No JCLIN is >> necessary and no link edit processing is performed by SMP/E. >> >> To determine if you can successfully use PROGRAM elements you have to >> consider the contents of your load modules and how they are built. Do your >> load modules include any parts not supplied by you? For example, callable >> services from CSSLIB or SCEELKED? Modules from subsystems or other >> products, like SDSNLOAD or ISPLLIB? Side decks (IMPORT >> statements) to resolve DLL references? If so, then you may want to, or >> need to, package individual modules as MODs and supply JCLIN to define your >> load modules. Shucks. However, if your load modules are rather simple and >> include only modules that you own, then you should consider using PROGRAM >> elements in your SYSMOD packaging for your initial FUNCTION and subsequent >> PTFs. >> >> Kurt Quackenbush -- IBM, SMP/E Development >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
