🚀 go-pugleaf

Ing user wrote:
> Chris,
>
> when you say "if you're going to be reentrant, you also have to make the
> CALL macro reentrant" -  do you mean like this :
>
> call ieantrt,(level,name,token,retcode),mf=l
>
> getmain and copy this over and later invoke as:
>
> call ieantrt,mf=(e,<address>)
>
> If so, for my future reference where is this documented? I didn't see this
> in the auth assembler guide

Reentrancy is not just for authorized programs. The [limited]
documentation I could find was in the general Assembler
Services Guide, Chapter 11, beginning on page 10 (for the
z/OS V1.7 doc, anyway).

Kind regards,

-Steve Comstock


>
> Thanks
>
> Ing
>
>
> On Tue, 20 Sep 2005 09:47:56 -0500, Craddock, Chris <Chris_Craddock@bmc.com>
> wrote:
>
>
>>>I have a service provider that places some data in SP 227
>>>and later puts the address of the above location in a N/T
>>>pair:
>>>
>>>CALL  IEANTCR,(LLEVEL,LNAME,LTOKEN,LPERSOPT,LRETCODE)
>>>
>>> LLEVEL         DC    A(IEANT_SYSTEM_LEVEL)
>>> LPERSOPT       DC    A(IEANT_NOPERSIST)
>>> LNAME          DC    CL16'SP00001'
>>> LRETCODE       DS    F
>>> LTOKEN         DS    0XL16
>>> DS1ADDR        DS    A
>>>                DS    XL12
>>
>>Are you sure? This would be a non-reentrant call. That may work, but it
>>can also fail in surprising ways.
>>
>>
>>>In the client I am trying to obtain the address through:
>>>CALL IEANTRT,(LLEVEL,LNAME,TOKEN,RETCODE)
>>
>>                            ^^^^^
>>
>>>Initially I defined all parms in absolute storage. But I got an
>>
>>0C4-11.
>>
>>Did the IEANTRT call get the S0C4, or did you get it in your own code?
>>S0C4-11 is a reference to an invalid address. Presumably you specified
>>an invalid address in a parameter. Based on the DC's above, I would
>>guess you meant to specify LTOKEN, not TOKEN. Maybe TOKEN was a valid
>>symbol in your program, but just not the thing you wanted.
>>
>>If you had got a S0C4-4 that would mean the storage address could not be
>>fetched or stored into and I might suspect a different problem. Or not.
>>Chances are you're just passing a bad address and the system is getting
>>a program check when it tries to reference it.
>>
>>
>>>later I placed just LLEVEL & LNAME in absolute storage while token &
>>>retcode
>>>are defined through a DSECT mapping to a storage obtained as follows:
>>>GETMAIN  R,LV=LOCMLEN,SP=0
>>
>>Making your program reentrant is a good idea, but it's probably not the
>>root cause of your problem in this case. Anyway, using the "R" form of
>>GETMAIN is a bad idea because it expands as an SVC 10 - which only gets
>>you 24-bit storage no matter what AMODE you are in. It's probably no big
>>deal, but I would use "RU" instead of "R". That way you get SVC 120.
>>
>>
>>>But the assembly fails with:
>>>
>>>000080 00000000                      67+         DC    A(TOKEN)
>>>PR
>>>** ASMA032E Relocatable value found when absolute value required -
>>
>>TOKEN
>>
>>>** ASMA435I Record 176 in SYS1.MACLIB(IHBOPLTX)
>>
>>You're suffering the initial pains of getting comfortable with reentrant
>>coding. Reentrancy, like pregnancy, is an all or nothing deal. You have
>>to put the data into the working storage by using instructions like;
>>
>>               LA      R0,TOKEN                -> TOKEN
>>               ST      R0,PARMAREA             Save in parm area
>>
>>Also, if you're going to be reentrant, you also have to make the CALL
>>macro reentrant. That means using the MF=L form to reserve storage for
>>the parameter list and then using the MF=(E,...) form to point to the
>>storage you reserved for the parameters and complete the parmlist and
>>make the call. You can read about it in the assembly language services
>>guide. But back to the problem at hand... why are you calling the symbol
>>"LTOKEN" in one place and "TOKEN" in another?
>>
>>CC
>
>