A bit more to Binyamin's explanation.
Back in the '90s when I was working on ACS/WYLBUR, I needed to
change the SYSLIB concatenation during "assembly time", and so I
created the ASYSLIB "directive".
Just so you know and understand, "ASYSLIB" allowed one to change
the SYSLIB concatenation as often as needed. This way you could
have the SYSLIB DD point to the current SCP level, and SYSLIB2 DD
(or whatever name you wanted as long as it did not conflict with
any other HLASM was using) could point to a different SCP or even
ISV list where the macro names could be in conflict with IBM's
macro names. And then ASYSLIB with no operand would take you back
to the default SYSLIB DD.
So I wrote all the code for it (and the doc), but then noticed
that I was being told that the "yyy" macros were coming from
SYS1.AMODGEN (in those days, we had various levels of code for
SCPs, JES2, JES3, ISVs, etc.), when SYS1.* wasn't in that
concatenation.
I can't remember if I published ASYSLIB or not. I know I didn't
send it off to CBT, and I wish I had. But since ACS owned all of
it (since I was an employee of theirs at the time), the full
ASYSLIB system I wrote (including PUSH/POP ASYSLIB) never made it
outside of our development lab.
Meanwhile, I had thought that HLASM was doing things one way,
when it was doing it another. Dr. Erhman and I talked, and he
realized that upon changing the concatenation (by changing DD
names), he had the code still using what it had been using -- the
list for SYSLIB that he had already obtained.
I never tried having a secondary SYSLIB (e.g. SYSLIB2) having
more DSNs in it than the SYSLIB to see what kind of error would
have happened...).
And so, it was agreed that this was a "FIN" issue, and the next
release of the HLASM had the fix for this. And to put it as
simply as possible (since Dr. John didn't share what he did
exactly) HLASM today knows to check the DDname being used to make
sure it matches the one it had been using.
As a result, it knows from where the macros come from that you
specify in your assembly because that is a very static situation,
unless you decide to use HLASM exits in a "strange" way to inject
code into the stream.
HTH,
Steve Thompson
On 11/27/2016 02:07 AM, Binyamin Dissen wrote:
RDJFCB + BLDL - look at the "C" value.
On Sat, 26 Nov 2016 19:15:34 -0700 Paul Gilmartin
<[email protected]> wrote:
:>A couple recent threads on IBM-MAIN asked, "How can I tell where
:>my load module came from?" and "How can a Rexx EXEC know where
:>it came from?"
:>
:>The consensus (I call it a consensus because I joined it) is
:>that it's damned hard. Once a library is OPENed there's little
:>information but the DEB which contains only UCBs and TTRs (well,
:>lotsa other stuff, but it's no help).
:>
:>Yet, HLASM effortlessly produces:
:> ASMA435I Record 1 in user.ASM(FROMPDS) on volume: 000000
<SNIPPAGE>
