Well, that helped, but I think we need Michael to take a look at his code:
0198EA 0700 89802+ CNOP 0,4
01-CALL
0198EC 47F0 B11C 198F4 89803+ B *+8
BRANCH AROUND VCON 01-CALL
0198F0 00000000 89804+IHB8321B DC V(DAFMB)
ENTRY POINT ADDRESS 01-CALL
0198F4 4110 AFF8 00FF8 89809+ LA 1,W_WRK
LOAD PARAMETER REG 1 03-IHBIN
0198F8 41E0 B570 19D48 89810+ LA 14,=C'ITE='
PICKUP PARAMETER 02-IHBOP
0198FC 0000 0000 00000 89811+ LA 15,SMF82ITE
PICKUP PARAMETER 02-IHBOP
** ASMA044E UNDEFINED SYMBOL - SMF82ITE
** ASMA435I RECORD 268 IN SYS1.MACLIB(IHBOPLTX) ON VOLUME: RST01A
019900 4100 0004 00004 89812+ LA 0,4
PICKUP PARAMETER 02-IHBOP
019904 90E0 1000 00000 89813+ STM 14,0,0(1)
STORE INTO PARAM. LIST 02-IHBOP
019908 58F0 B118 198F0 89814+ L 15,IHB8321B
LOAD 15 WITH ENTRY ADR 01-CALL
01990C 05EF 89815+ BALR 14,15
BRANCH TO ENTRY POINT 01-CALL
89816 CALL DAFMB, Move
Binary Comment X
(=C'IML=',SMF82IML,4),
Maximum data length X
_________________________________________________________________
Dave Jousma
Assistant Vice President, Mainframe Engineering
[email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Bob Rutledge
Sent: Wednesday, February 25, 2015 3:16 PM
To: [email protected]
Subject: Re: new version of DAF?
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
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
