On 2014-08-12 14:23, Hardee, Chuck wrote: > Paul, > > Yes, that is all I can find as well, but if only ++MODs can be used to cause > a link, what is the ++PROGRAM used for. > The reference manual states that it is used to deliver a linked edited load > module, but it says nothing about what the load module would be used for. > > So, assuming for the moment that ONLY ++MODs can be used to deliver object > programs for use by the linkage editor, how would one accomplish the > following: > > SMP/E environment #1: > Deliver, assemble and link the 8 constituent modules creating 8 standalone > load modules. > Capture the output of the assembler during the assembly process in order to > deliver the object decks to SMP/E environment #2. > Here, you appear to be using SMP/E as a CM/Source Control tool. SMP/E isn't the ideal tool for this purpose (to wit the difficulties you describe later). But, the price is right, and it's what you're familiar with. Readers here who know my preferences would not be surprised if I suggested "make" rather than SMP/E to manage environment #1.
How are you packaging the ++PROGRAM elements? Inline, via GIMDTS, or in relative files. RELFILEs are perfectly legal in PTFs, but highly unconventional. The objection is that the customer wallows in SMPTLIBs. (Do SMPTLIBs go away on an ACCEPT PURGE?) Then, it's a crying shame that GIMDTS is not allowed for ++MOD elements. Why, dammit!? That would get you home free. > SMP/E environment #2: > Deliver the object decks from SMP/E environment #1. > Link the 8 object decks along with a stub to create a load module usable in > the environment controlled by SMP/E #2. > > The two environments cannot be combined. > I suspect the customer will never see environment #1. > I have tried changing my assembler options to state OBECT versus NOOBJECT, > and supplying a DD statement for SYSLIN and that works, on a module by module > basis. However, I also have UCLIN MAC GENASM statements for each of the > modules so that if any of the macros and DSECTs used by the module are > changed, the source will be reassembled and the modules relinked. Delivering > a macro that is used by 2 or more of the modules causes them to be > reassembled and that's where the problem lies. In the deliver process of the > new macro, if more than one module gets reassembled, the output decks > overwrite each other to that only the last module assembled is saved. > > If I can figure out how to cause SMP/E to keep the output of each module > assembly when a new macro is delivered, then I'm home free as I can deliver > an object deck via ++MOD to the second environment rather than load modules > via ++PROGRAMs. > > Ideas? > Thoughts? > Not really. Filter the Binder SYSPRINT and SMP/E SMPOUT to find newly built objects and re-do the assemblies outside SMP/E, using the DISTLIB as source and SYSLIB? Ugh! -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
