Ok, I'm replying to this latest because it gets to the heart of some of it,
then I'll go back to some of the others. I'm very grateful for all the
responses; if anyone thinks I've left their trenchant point unacknowledged,
it's sure not deliberate, feel free to poke me here or offline! I really want
to understand this as much as I can, at least this week (that's me
acknowledging that in a month I will have forgotten most of it--thank &deity
for email archives).
Kurt Quackenbush wrote, in part:
>2. SMP/E does not support substitution in JCLIN like is possible with
>JCL and the JCL interpreter/converter.
Yeah, I was getting that idea, thanks for confirming it for realz.
>3. The binder LIBRARY statement in JCLIN is not supported by SMP/E.
Well...not quite true per the book:
"
Normally, LIBRARY statements should not be used in JCLIN data. An
exception is when the CALLLIBS operand is specified on the JCLIN
command or ++JCLIN MCS, or when //*CALLLIBS=YES is encountered after a
job card preceding a link-edit step. JCLIN processing then allows for
the LIBRARY statement to be used to specify those modules (external
references) that are to be excluded from the automatic library search
during the following:
- The current linkage editor job step (restricted no-call function)
- Any subsequent linkage editor job step (never-call function)
A LIBRARY statement should be used only if a SYSLIB DD statement is
also used. It should not be used to specify additional automatic call
libraries; the SYSLIB DD statement should be used instead.
"
This is why we have it in there. The backstory here is that the person who
added this is gone, and left no documentation. Worse, he added it without any
discussion, and we didn't realize it was there: all our testing worked fine
because he had the USS path hard-coded in JCLIN, and then when customers got it
they had problems, first because the USS path didn't exist and then because
they didn't want the stuff at that hard-coded location in their USS filesystem.
>The LIBRARY statement tells the binder to "include this thing when
>building the load module". If you want to include a file when building
>a load module, and if that file is not a module defined by ++MOD (or
>from assembled source) then use the INCLUDE statement, specify the
>target library ddname (instead of the DISTLIB ddname used when
>including a MOD) and add the comment "TYPE=UTIN". Like this:
>
> INCLUDE tgtddname('libsapi.a') TYPE=UTIN
If I understood this, I'd do it. "use the INCLUDE statement"--where? In JCLIN?
We're back to "no substitution in JCLIN", if so. My more knowledgeable guy is
back today and I'll ask him if he groks this.
>You can read all about which binder statements SMP/E supports and
>generally how SMP/E processes link edit steps in JCLIN here:
>https://www.ibm.com/docs/en/zos/3.2.0?topic=processing-link-edit-steps
Maybe this is the key, not sure yet. The JCLIN certainly includes lots of HEWL
invocations and lots of INCLUDE statements, but again, aren't we back to "no
substitution in JCLIN"?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
