When I use CALL MACRO for non re entrant code, I do not have to use the EXECUTE form, so my code looks more like this:
Code:
CALL ABCD,(P1,P2,P3),VL
In this case, I get the last parm address with the higher order byte set. This is all good.
But for RE-ENTRANT code , when using the Execute form of the CALL macro where should the VL attribute be specified.
This is the code:
Code:
CALL ABCD,MF=(E,PARMADDR)
PARMADDR CALL ,(P1,P2,P3),MF=L
I tried putting the VL right after the PARMADDR and it actually changes the address to actual data it references to. Then VL anywhere else gives S0C1. I would please like to understand where should the VL attribute go in the execute form for the last parm address to be set with higher order byte on.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
From the Assembler Services Guide manual:
Quote:
Lengths and formats of parameters are defined by the called service. For an AMODE 24 or AMODE 31 program, the parameter list consists of 4-byte wide address slots; for an AMODE 64 program, the parameter list consists of 8-byte wide address slots. For an AMODE 24 or AMODE 31 program, the high order bit of the last address slot is used to indicate the end of the list. For an AMODE 64 program, that convention is not used. Instead, a separate parameter would be provided if the target program needs to be able to determine how many parameters were passed. That separate parameter could be within the parameter list (for example, the first parameter list slot) or could be in register 0.
Robert, Thank you so much and appreciate everyone who participated in this thread to help me with this problem. I have got all the information which is required.
18 CALL TEST2,(A,B),VL,MF=(E,PARMLIST)
00001E 0700 20+ CNOP 0,4
000020 47F0 C028 00028 21+ B *+8
000024 00000000 22+IHB0007B DC V(TEST2)
000028 4110 C068 00068 27+ LA 1,PARMLIST
00002C 41E0 C074 00074 28+ LA 14,A
000030 41F0 C080 00080 29+ LA 15,B
000034 90EF 1000 00000 30+ STM 14,15,0(1)
000038 9680 1004 00004 31+ OI 4(1),X'80'
00003C 58F0 C024 00024 32+ L 15,IHB0007B
000040 05EF 33+ BALR 14,15
34 CALL TEST3,(,B,C),VL,MF=(E,PARMLIST)
000042 0700 36+ CNOP 0,4
000044 47F0 C04C 0004C 37+ B *+8
000048 00000000 38+IHB0013B DC V(TEST3)
00004C 4110 C068 00068 43+ LA 1,PARMLIST
000050 41E0 C080 00080 44+ LA 14,B
000054 41F0 C08C 0008C 45+ LA 15,C
000058 90EF 1004 00004 46+ STM 14,15,4(1)
00005C 9680 1008 00008 47+ OI 8(1),X'80'
000060 58F0 C048 00048 48+ L 15,IHB0013B
000064 05EF 49+ BALR 14,15
The OI instruction is setting the high order bit of the last argument as defined in the parameter list as specified the CALL macro.
Not all the macros that provide for MF=E / MF=L expansions behave this way. For example -
Code:
OPEN (DCB1,OUTPUT,DCB2,OUTPUT),MF=(E,OPARM)
...
OPARM OPEN (*-*,,*-*),MF=L
will not alter the high order bit, though it will carefully preserve any of the remaining bits in the high order byte of the last word in the prototype parameter list.
<War story on>I, my self, was caught up in this years ago. I had noticed this behavior in OPEN and CLOSE. Quite suddenly, OPEN and CLOSE were changed to set the high order bit. "Yipee," I said to my self, "They're behaving correctly!" After the next PTF cycle, OPEN and CLOSE reverted to their previous behavior. After some thought I realized the issue: the new behavior broke programs that used MF=E to alter some, though not all of a prototype parameter list; the new behavior cut off the parameter list.<War story off>
My war story makes a point. In theory, you should regard the macro expansion as a black box, but not a black box to be fully trusted, especially when using MF=E to fill in a prototype parameter list built by MF=L. In other words, check the expansion.
.jpg)
