On 2/25/2015 10:47 AM, Jousma, David wrote:
All,
Just brought my z/OS 1.13 system up to current maintenance. Interestingly, DAF
now abends with a 0C4. Tried reassembling it on latest macros, and that fails
too. Looks like something changed in macro GFSAUSMF.
11826+*
DESERV -- mapped by ICHRUTKN @26A
11827 AGO .NODFSMS1
11828 .NODFSMS1 ANOP
11829 AIF ('&ST_DFSMS07' NE
'YES').NODFSMS071 new in DFSMS 1.2
11830 GFSAUSMF SMF
RT 42 ST 7
** ASMA254I *** MNOTE *** 11831+ 4,SMF must be numeric in GFSAUSMF
01-GFSAU
11832+*
11833+*
SMF Records
PAGE 193
ACTIVE USINGS: NONE
D-LOC OBJECT CODE ADDR1 ADDR2 STMT SOURCE STATEMENT
HLASM R6.0 2015/02/25 10.37
11834+********************************************************************
11835+* Header for SMF record type 42
should be used from IGWSMF @02C
11836+********************************************************************
11837+*
OA41861 added parameters to the macro and "SMF" isn't one of the allowable ones.
As was taught to me over 45 years ago, it's a really good idea to code a ','
in the absence of operands in assembler statements because you never know who's
going to change what. If you do so now to the line generating the error
GFSAUSMF , SMF RT 42 ST 7
it looks like it's going to generate the same definitions as it used to. If
not, sing out and I'll take a closer look at it.
Bob
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
