I have some assembler programs which put "hooks" in the PLI programs by modifying the following hex offsets of the PL/I TCA so that the assembler program can trace storage allocation and module flow
X'48 of TCA to get address of PL/I overflow routine for getting VDA
X'6C' of TCA to get address of PL/I dynamic storage
X'F0' of TCA to get address PL/I flow routine .
X'74' of TCA for overflow routine for getting DSA..
These offsets were based on on old PL/I compiler. With Enterprise PL/I compiler which conforms to LE, these offsets are no longer valid .. The "hooks" no longer work ..
My questions are
a) How to find equivalent PL/I TCA offset under LE ?..
b) Are we better off by redesigning this assembler to use LE based services instead of playing with PL/I TCA offsets ..
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
I believe choice b) would be wiser. Traversing control blocks, using IBM defined DSECT's, should only require a re-assembly/link of the Assembler program if there were DSECT changes.
Control block traversing in a high-level language, such as PL/I or COBOL, using undocumented methods, can be risky (as you've found out), so use Assembler and you'll be OK as long as it's supported by IBM. However, I don't think you'll need to use LE Callable routines to accomplish this. If so, you'd have to make the Assembler program fully LE-compiliant or using "CEEPIPI" (non-CICS) for temporary compliance, which in both cases, is more of a PITA than anything.
The TCA DSECT should be the same, regardless of the language. But, I could be wrong as PL/I does some funny stuff under the covers.
Bill, thanks for your quick response.. I really do not know which IBM defined DSECT to use for these. I went through MVS data area manuals and , I could not figure out .. Will keep looking though ..
Problem is these assembler programs query the save area chain , change the the PL/I environment for the called PL/I main based on these TCA offsets, write a trace record for storage allocation and module flow . and continue with passing control to PLI main routine Since storage allocation has become common under LE ( not language specific ) using these PLI specific TCA will not work .. Since I do not have code this, but suggest a design approach , I thought I would suggest RPTSTG option in my design document for tracing storage allocation ..
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Here's some excerpt code to get you started. R1 and R2 can be substituted for whatever registers you decide to use -
Code:
CVT DSECT=YES,LIST=YES CVT-DSECT (PREFIX=NO)
IKJTCB TCB-DSECT
IEFTIOT1 IEFTIOT1 TIOT-DSECT
IHAACEE ACEE-DSECT
IHAASXB ASXB-DSECT
IHAASCB ASCB-DSECT
*
L R1,CVTPTR CVT-ADDRESS
L R2,0(,R1) ADDRESS OF TCB POINTERS
LR R1,R2 SAME
L R1,4(,R1) TCB-ADDRESS
ST R1,ADDRTCB STORE IN FWORD (SAFEKEEPING)
L R1,TCBTIO-TCB(,R1) LOAD TIOT-ADDRESS
ST R1,ADDRTIOT STORE IN FWORD (SAFEKEEPING)
***********************************************************************
* GET THE 'USERID', 'JOB-NAME' AND 'JOB-NUMBER' VIA CONTROL *
* BLOCK TRAVERSING. *
***********************************************************************
L R2,12(,R2) POINT TO 'ASCB'
ST R2,ADDRASCB STORE IN FWORD (SAFEKEEPING)
L R2,ASCBASXB-ASCB(,R2) CHAIN TO 'ASXB' ADDRESS
ST R2,ADDRASXB STORE IN FWORD (SAFEKEEPING)
L R2,ASXBSENV-ASXB(,R2) CHAIN TO 'ACEE' ADDRESS
ST R2,ADDRACEE STORE IN FWORD (SAFEKEEPING)
MVC USERID,ACEEUSRI-ACEE(R2) POPULATE 'USERID'
L R2,ADDRTIOT LOAD 'TIOT' ADDRESS
MVC JOBNAME,0(R2) POPULATE 'JOB-NAME'
L R2,540 CURRENT 'TCB'
L R2,180(,R2) POINT TO 'JFCB'
L R2,316(,R2) POINT TO 'SSID'
LA R2,12(,R2) OK, WE'RE HERE
MVC JOBNBR,0(R2) POPULATE AS C'JOB00000'
This may not be what you exactly need, but it can get you on your way.
Thank you Bill. I think what you showed me help me to get further on my way .. Thanks once again ..
To answer, Mr Woodger's question , what I am maintaining is an old PL/I based IMS application which had a debug/trace feature implemented using Assembler. This trace function stopped working after the application moved to LE environment .. ( that is, Enterprise PL/I compiler )
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
BTW, welcome to the forum. We offer our services free of charge and if you post within the rules of the forum, you'll be assisted when a member can spare some of his/her time.
However, we do encourage that a poster attempts to find the answer to his/her question before posting. It will show other members that you've tried to find an answer or, the answer with which you've found is a little confusing or requires additional explanation..
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
Do you actually need this "feature"? There must be hundreds of thousands of PL/1 IMS programs in the world that do not have this and yet they are maintained and debugged successfully.
I agree with you, Nic. But, I cannot make that call. I will inform the customer about this . Just wanted to get a opinion from the experts, since I could not see a solution (by continuing to use PL/I's TCA for tracing ) based on my own knowledge, walking through the assembly code, reading through manuals..
, I thought I would suggest RPTSTG option in my design document for tracing storage allocation ..