Re: CA-1 TMSXITJ
The point of origin is an SMF exit, presumably hung as an IRB off of the Initiator so the JOBSTEP TCB is not directly available; you have to look for it. I rather doubt that any SMF exit like this is run as an IRB. Many SMF exits do run under the initiator TCB. It may well be that the JOBSTEP TCB does not exist yet (or any longer, depending on the exit). I suppose the TCB may still exist in some of the termination cases (just not yet freemained) even if the task has terminated. (IEFUTL is an exit that runs as an IRB) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
In 665755e5c3e01845ad6bda0855b8cec732f931f...@gscmamp01ex.firmwide.corp.gs.com, on 09/05/2011 at 03:30 PM, Bonaduce, Frank frank.bonad...@gs.com said: This is the information that I passed down to the original poster with a suggestion of how I follow the TCB 'chain' down to the JOBSTEP TCB, There may be more than one. presumably hung as an IRB off of the Initiator In that case the daughter TCB is yhe correct jobstep. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
Peter - Yes, that would be correct and a partial assumption on my part since the work I had been doing recently was with IEFUTL. At least in that case, there is no doubt that it runs under the Initator. This is evidenced by what is seen in the TCB chain where you do eventually reach the JOBSTEP TCB. I simply passed this info along as a possible avenue of exploration for the original poster. It is entirely possible that in his scenario, there may not as yet be a JOBSTEP TCB for the particular SMF exit he is using. Frank. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Peter Relson Sent: Tuesday, September 06, 2011 7:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CA-1 TMSXITJ The point of origin is an SMF exit, presumably hung as an IRB off of the Initiator so the JOBSTEP TCB is not directly available; you have to look for it. I rather doubt that any SMF exit like this is run as an IRB. Many SMF exits do run under the initiator TCB. It may well be that the JOBSTEP TCB does not exist yet (or any longer, depending on the exit). I suppose the TCB may still exist in some of the termination cases (just not yet freemained) even if the task has terminated. (IEFUTL is an exit that runs as an IRB) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
This is the information that I passed down to the original poster with a suggestion of how I follow the TCB 'chain' down to the JOBSTEP TCB, assuming that's what he needs to do. The reason for this is that the point of origin is an SMF exit, presumably hung as an IRB off of the Initiator so the JOBSTEP TCB is not directly available; you have to look for it. Frank. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Peter Relson Sent: Sunday, September 04, 2011 9:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CA-1 TMSXITJ ... L R3,ASXBFTCB Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. This does not produce, and never has produced, the address of a random TCB. It produces the address of the TCB for the RCT (region control task). User code will typically not run with PSATOLD equal to that task. Regarding making the assumption that you can use TCBUSER: not a good assumption. TCBUSER has always been intended for use by the owner of the TCB. But since that has never been made clear, we added STCBUSER in z/OS 1.7 with commentary that attempts to be clear about that. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
On Sun, 4 Sep 2011 09:31:59 -0400 Peter Relson rel...@us.ibm.com wrote: :... : L R3,ASXBFTCB : Unfortunately, under z/OS it produces the address of a random TCB. We : tried changing the code to obtain the TCB address directly from PSATOLD : but that doesn't seem to be working either. :This does not produce, and never has produced, the address of a random :TCB. It produces the address of the TCB for the RCT (region control :task). User code will typically not run with PSATOLD equal to that task. :Regarding making the assumption that you can use TCBUSER: not a good :assumption. TCBUSER has always been intended for use by the owner of the :TCB. But since that has never been made clear, we added STCBUSER in z/OS :1.7 with commentary that attempts to be clear about that. Owner: target module of the ATTACH. Must be set only by that module or a module in its component As the vast majority of the targets of ATTACH are problem state, how can they use it? Is there some API that sets it? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
On Mon, 5 Sep 2011 23:21:44 +0300, Binyamin Dissen wrote: On Sun, 4 Sep 2011 09:31:59 -0400 Peter Relson wrote: ... :Regarding making the assumption that you can use TCBUSER: not a good :assumption. TCBUSER has always been intended for use by the owner of the :TCB. But since that has never been made clear, we added STCBUSER in z/OS :1.7 with commentary that attempts to be clear about that. Owner: target module of the ATTACH. Must be set only by that module or a module in its component As the vast majority of the targets of ATTACH are problem state, how can they use it? Is there some API that sets it? Otherwise, might one use name/token services for the same purpose? Is there a convention for avoiding conflicts of token names? Are any tokens automatically reclaimed when: o The task ends? o The job ends? o Other (specify)? I also think of POSIX environment variables. I suspect those require LE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
... L R3,ASXBFTCB Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. This does not produce, and never has produced, the address of a random TCB. It produces the address of the TCB for the RCT (region control task). User code will typically not run with PSATOLD equal to that task. Regarding making the assumption that you can use TCBUSER: not a good assumption. TCBUSER has always been intended for use by the owner of the TCB. But since that has never been made clear, we added STCBUSER in z/OS 1.7 with commentary that attempts to be clear about that. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
For the archives in case someone else runs into a similar problem. Our IEFUJI exit GETMAINs memory for a TCB extension, stores selected data from the SMF parameters and the ACEE in this memory, and places the address of the extension in TCBUSER. We then use the data in the extension for our TSO submit exit and the CA-1 accounting exit. In all the exits, we find the TCB address using PSAOLD-ASCBASXB-ASXBFTCB and the ACEE address using ASXBSENV. This has worked for us from MVS 4.5 back in the early 90s all the way through OS/390 1.3, 2.5, and 2.10. Something obviously changed in the interval to z/OS 1.11. I don't know if it was in z/OS or in the newer version of CA-1 (probably CA-1). The net result is that the CA-1 accounting exit is called before our IEFUJI has populated the TCBUSER field. Our solution to use code similar to IEFUJI in our accounting exit and extract the desired data directly from the SMF parameters and the ACEE. The problem does not affect our TSO submit exit. By the time a TSO user can submit a job, the TCBUSER field contains the address of our TCB extension. Thanks to all who responded with suggestions. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Monday, August 29, 2011 5:53 AM To: IBM-MAIN@bama.ua.edu Subject: CA-1 TMSXITJ We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Monday, August 29, 2011 8:53 AM To: IBM-MAIN@bama.ua.edu Subject: CA-1 TMSXITJ We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? If this is not resolved, then I would open a case with CA CA1 support. They have always been very helpful when I had issues with exits. I do not use that particular exit, so I am not familar with this code. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
Barry - Sorry for the empty reply earlier (finger-check). You are definitely on the right track. ASXBFTCB is the first TCB on a TCB queue for the address space, which is likely the RCT (Region Control Task). For the 'average' batch job you have to drill down to the fourth or fifth TCB in the queue to get to the jobstep TCB. Just follow the TCBTCB field (offset 116 in the TCB) for each successive TCB until you find the jobstep TCB (or hex zeros at the end). You can identify it by looking at the TIOT associated with each TCB to see if the JOBNAME in the respective TIOT matches the jobname. If you are working with an SMF exit, you can get the jobname from either the JMR or the Common Exit Parameter list which contains a copy of the JMR. All the preceeding TCBs/TIOTs contain jobnames of either MSTJCL00 or INIT. I just completed work on an IEFUTL module where I needed to interrogate the jobstep DDs looking for tape devices which required this approach. I'm working on z/OS 1.10 and 1.12 systems. Let me know if I can be of further assistance. Frank. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Monday, August 29, 2011 8:53 AM To: IBM-MAIN@bama.ua.edu Subject: CA-1 TMSXITJ We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CA-1 TMSXITJ
We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
Barry, either PSATOLD or PSAAOLD should work. Why do you think you're getting a random TCB? The only thing I can think of is perhaps IEFUJI is too early and you're getting the info for the initiator, not the address space. But I can't recall that having changed. What version of CA1 are you migrating from/to? Mary Anne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
In b282be35b5a4494894d4ecfba2bf7847180f58d...@xch-nw-17v.nw.nos.boeing.com, on 08/29/2011 at 05:52 AM, Schwarz, Barry A barry.a.schw...@boeing.com said: Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. What TCB does PSATOLD point to when the exit is entered? Surely there is way for a job to find it's own TCB? Shirley there is no its own TCB, only its own TCB's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-1 TMSXITJ
If by own TCB of a job, you mean the job step TCB of the currently executing step which is either the current TCB, or some TCB for which the current TCB is a subtask (or other descendant), then the following should find the TCB: USING PSA,R0 L R3,PSATOLDCurrent TCB (zero for SRB mode) USING TCB,R3 L R3,TCBJSTCB Job step TCB Stephen R. Donaldson, Code Magus Limited (England reg. no. 4024745) Number 6, 69 Woodstock Road, Oxford, OX2 6EY, United Kingdom Voice: +44 1865 310 768 Fax: +44 1865 316 979 Cell: +44 787 9897709 Support: +44 1865 589826 Skype:vixxmovz SkypeIn +44 1865 589820 http://www.codemagus.com mailto:step...@codemagus.com Schwarz, Barry A wrote: We are migrating our CA-1 TMSXITJ accounting exit from OS/390 (where it was called TMSUX2J) to z/OS 1.11. The exit needs to find the TCB for the batch job mounting the tape. What has worked in the past is USING PSA,R0 L R3,PSAAOLD USING ASCB,R3 L R3,ASCBASXB USING ASXB,R3 L R3,ASXBFTCB USING TCB,R3 Unfortunately, under z/OS it produces the address of a random TCB. We tried changing the code to obtain the TCB address directly from PSATOLD but that doesn't seem to be working either. As part of our debugging we added some WTOs. Since the messages showed up in the job log, we assume the exit is running in the batch job's address space. Surely there is way for a job to find it's own TCB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
