(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. 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 [email protected] with the message: INFO IBM-MAIN
