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
