🚀 go-pugleaf

Thanks

The IEANTCR is in service provider and the IEANTRT is in client code. So
they are in 2 seperate AS's and refer correctly.

Yes I was able to resolve that. But currently I am stuck at a new problem
while calliing into the PC routine from client address space, I get:



IEF450I ASDC00 ASDC00 - ABEND=S053 U0000 REASON=00000297 139
        TIME=00.08.50


The etdefs are as follows:

ETDESC ETDEF TYPE=INITIAL ETD1 ETDEF
TYPE=ENTRY,PROGRAM='AFDS002',SSWITCH=YES,SASN=NEW,X
STATE=PROBLEM,AKM=(0:15),EKM=(0:15),EK=8,PKM=REPLACE ETD2 ETDEF
TYPE=ENTRY,PROGRAM='AFDS003',SSWITCH=YES,SASN=NEW,X
STATE=PROBLEM,AKM=(0:15),EKM=(0:15),EK=8,PKM=REPLACE ETDEF TYPE=FINAL

And the services are authorized to be executed from any address spaces. Both
the services are loaded into LPA.The PC numbers are specified through
name/token and the client I am writing is able to get to that:

L 14,sv1pc
pc 0(14)



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