On Fri, 25 May 2018 07:37:53 -0500, John McKown wrote: >On Fri, May 25, 2018 at 7:26 AM Tom Marchant wrote: > >> On Fri, 25 May 2018 12:20:18 +0000, Allan Staller wrote: >> >> >Check the releted DDDEF's and the SYSLIB/CALLLIB concat. >> >> SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits. > >True for SMP/E usagre. The Binder, at least in batch, uses the DD SYSLIB >for autocall (CALL option). However, SMP/E, when it scans the ++JCLIN, will >notice any Binder SYSLIBs. It will store the last qualifier as a DDDEF name >in the appropriate LMOD. When the Binder is invoked for that LMOD, SMP/E >will dynamically allocate the DDDEFs in the LMOD entry to some SMPnnnnn DD >name and pass that name as the alternate SYSLIB name to the Binder. > SYSLIB? SYSLMOD? Whatever. I don't believe SMP/E cares about SYSLIB DD statement images in Binder JCLIN. But the DDNAME on INCLUDE statements must match the DLIB NAMED on the ++MOD MCS.
I once had a heated argument with a co-worker who observed that the SYSLMOD DSN in JCLIN was not an existing data set, and insisted that it must refer to a real data set. I tried to explain to him that what he saw was not JCL, but he persisted, arguing that if each line starts with "//" it must be JCL! >However, I don't control the LMOD entry, it was set up for me by IBM when I >installed SMP/E and maintained by them. And, just to be complete, AOSBN is >not mentioned in the LMOD SYSLIB equivalent. Only LINKLIB is mentioned in >the Binder SYSMOD for this LMOD. > >Again, the output from SMP/E and the LIST LMOD XREF output can be viewed >on Github here: >https://gist.github.com/JohnArchieMckown/20d995cce8e2f201a4cf9725c4932092 -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
