Hi Jonathan, Thanks for responding.
If it's confusing to you on the inside, imagine how it feels to me on
the outside.
I have the following guesses:
1) I'm guessing either that CDAHLASM invokes ASMA90 twice, or it
makes heavy use of its exit points to maintain both control and
awareness with respect to what ASMA90 is doing. (Or both)
2) It would be really helpful if CDAHLASM would issue messaging
explaining its terminations, but I don't have a way of asking them
this; do your?
3) Hursley probably doesn't own CDAHLASM, but it's all ASMAnnnn
messages we're seeing so you guys get the blame.
4) My opinion of CDAHLASM's intentional premature terminations is unprintable.
Best,
Dave
At 11/29/2022 09:04 AM, Jonathan Scott wrote:
There are so many weird things in that output that I can't make
much sense of it!
One thing I can definitely say is that the ASMA417C message and
the associated ASMA935U message would prevent the assembly from
running, so I suspect that they are from a second assembly step
following the one that gets the macro error, and the initial
output has been overwritten by that from the second attempt.
These messages are normally written to the job log with WTP
rather than to SYSPRINT or SYSTERM.
Another weird thing is that as far as I know option processing
messages such as ASMA438N do not normally appear on SYSTERM
although in some cases they would appear on the job log written
with WTP, so that looks more like job log output than SYSTERM.
Any options specified in an ASMAOPT file have priority over
options specified as parameter on the ASMA90 call, so if the
PARM conflicts with the ASMAOPT that would cause ASMA438N
messages to be issued in that case.
When a program invokes ASMA90, it can provide an alternate
DDname list which is used instead of the standard DDnames, as
described in the topic "Invoking the Assembler dynamically" in
in chapter 7 "Assembling your program on z/OS" in the HLASM
Programmer's Guide. So it might not be SYSLIN which is
missing in that case.
My overall theory would be that if the initial assembly fails
because of that macro, the calling layer ends up invoking the
assembler again in a way which makes a mess. However, it is
difficult to imagine how it could cause those particular
symptoms.
Jonathan Scott, HLASM
IBM Hursley, UK
