> On Mar 27, 2017, at 10:07 AM, Paul Gilmartin > <0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > (I don't see the OP. Did this thread originate from Usenet?) > > On Mon, 27 Mar 2017 06:31:24 -0700, Phil Smith wrote: > >> One thing that surprised me (and continues to be a pain) is that a given >> package can only have one part with a given name. ... Seems kind of >> primitive in this day and age, especially when you're forced to work with >> eight-byte names! >> > I thought that constraint had been relieved. It's particularly onerous with > support for multiple natural languages. > > UNIX objects may have longer names, but each must have a unique 8-byte name in > the MCS. That constraint ought to be relieved. > > > On Mon, 27 Mar 2017 09:18:56 -0400, Charles Mills wrote: > >> The referenced publication was apparently last updated in 2010. It has a lot >> of detail on distribution tapes but is silent on radical concepts such as >> FTP, pax and the Internet. When I was looking for help on how the heck to >> package our stuff for SMP/E I found it less than a complete tutorial, to say >> the least. >> > Yup. I submitted an RCF on this a couple years ago. I see no effect. > > On Mon, 27 Mar 2017 08:37:27 -0400, Kurt Quackenbush wrote: >> >> 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. >> > The supplier must initiallly build the PROGRAM element using Binder > control statements. Instead, these could be converted to JCLIN for > use wiht MOD elements. The remaining hard part is generating the > CSECT operand for ++MOD MCS. I've done this by scanning the > SYSLIN. It would be a valuable feature if SMP/E incorporated this > process in APPLY, relieving the supplier of the burden. > >> 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. >> > ++PROGRAM packaging leads to enormous PTFs with problems of > overflow of SMPPTS and SMPNTS. > > Some customers prefer fine-grained service where each PTF targets > a single problem. IIRC, Ed Gould has expressed such sentiments. But > cafeteria-style service where each customer can customize a PTF > selection allows a customer the opportunity to create a configuration > that the supplier has never tested. Gil, I think I would interject here and say this. *UNLESS* your module is real really large (LIKE JAVA) disregard the succeeding statements. I have seen rather *LARGE* z/os PTFS and unless you have a small PTS they can be handled easily. JAVA is HUMONGOUS and that is where Gils comments are reasonable. *IF* your product is LARGE then Gills comments are applicable. What is Large? anything over say 20,000 80 byte “cards” would mandate some instructions that are in BOLD and maybe a larger font to tell the user that the libraries must be enlarged by say X percent. I have seen most typical installions of the typical product and I have yet to see anything worth getting excited about. Welcome to the club and I hope you believe in PREREQ and SUPs and do *NOT* tell the user to bypass(ID) like one product that is made by a equally hated vendor who will remain nameless. Ed
> > If a ++MOD element contains PC sections, those are not replaced by > service; the accumulate with each PTF. > > ++PROGRAM service can create long PRErequisite chains. If an earlier > PTF has ++HOLD, all subsequent PTFs are blocked until that hold is > resolved. > > (HLASM prints its PTF level in each SYSPRINT. I expect this to be done > by each PTF's replacing a CSECT that contains its ID. This should result > in absolutely linear PRErequisite chains.) > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
