Re: 0C4 pic 11 in stimer exit on retry
All together now - "Show the code". On Fri, 3 May 2024 12:55:22 -0400 Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu> wrote: :>I have recovery routine which got control on abend of stimer exit irb :>On retry I am getting S0C4 PIC 11 reloading my registers from the system :>primed r13 I check 13 on input before the abend and at the retry point and :>it has the same value :>When I abend in the stimer exit does the system do anything to my save area :>R13 -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
Was your recovery routine set within the IRB or by the mainline? The reg 13 within the IRB is for the IRB and storage associated with an RB is freed when the RB terminates. If you "retry" you are retrying to the RB that set the recovery. Thus any regs for retry should be ones associated with that RB. Of at least as much importance: Show the data. Including the 8-byte translation exception address. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
Was 24 bit number like a TCB or RB first byte 00 it’s an address given by the system the doc says Thanks Get Outlook for iOS<https://aka.ms/o0ukef> From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 3, 2024 4:00:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 0C4 pic 11 in stimer exit on retry You didn't say that the high 32 bits of R13 was zero. Were they? -- Tom Marchant On Fri, 3 May 2024 13:15:12 -0400, Joseph Reichman wrote: >I just noticed that on abend I was in amode 64 and retry in amode 31 but this >should have no effect as r13 was a 24 bit address the stimer exit did get >control in amode 64 I saved only 31 bit registers > > > > >> On May 3, 2024, at 1:00 PM, Seymour J Metz wrote: >> >> That stems from a bad address. Are you in the correct address mode? Could >> you have done a premature FREEMAIN? >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu> >> Sent: Friday, May 3, 2024 12:55 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: 0C4 pic 11 in stimer exit on retry >> >> Hi >> >> I have recovery routine which got control on abend of stimer exit irb >> >> On retry I am getting S0C4 PIC 11 reloading my registers from the system >> primed r13 I check 13 on input before the abend and at the retry point and >> it has the same value >> >> When I abend in the stimer exit does the system do anything to my save area >> R13 >> >> Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
You didn't say that the high 32 bits of R13 was zero. Were they? -- Tom Marchant On Fri, 3 May 2024 13:15:12 -0400, Joseph Reichman wrote: >I just noticed that on abend I was in amode 64 and retry in amode 31 but this >should have no effect as r13 was a 24 bit address the stimer exit did get >control in amode 64 I saved only 31 bit registers > > > > >> On May 3, 2024, at 1:00 PM, Seymour J Metz wrote: >> >> That stems from a bad address. Are you in the correct address mode? Could >> you have done a premature FREEMAIN? >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu> >> Sent: Friday, May 3, 2024 12:55 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: 0C4 pic 11 in stimer exit on retry >> >> Hi >> >> I have recovery routine which got control on abend of stimer exit irb >> >> On retry I am getting S0C4 PIC 11 reloading my registers from the system >> primed r13 I check 13 on input before the abend and at the retry point and >> it has the same value >> >> When I abend in the stimer exit does the system do anything to my save area >> R13 >> >> Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
I just noticed that on abend I was in amode 64 and retry in amode 31 but this should have no effect as r13 was a 24 bit address the stimer exit did get control in amode 64 I saved only 31 bit registers > On May 3, 2024, at 1:00 PM, Seymour J Metz wrote: > > That stems from a bad address. Are you in the correct address mode? Could > you have done a premature FREEMAIN? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu> > Sent: Friday, May 3, 2024 12:55 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 0C4 pic 11 in stimer exit on retry > > Hi > > I have recovery routine which got control on abend of stimer exit irb > > On retry I am getting S0C4 PIC 11 reloading my registers from the system > primed r13 I check 13 on input before the abend and at the retry point and > it has the same value > > When I abend in the stimer exit does the system do anything to my save area > R13 > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 11 in stimer exit on retry
That stems from a bad address. Are you in the correct address mode? Could you have done a premature FREEMAIN? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 3, 2024 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 0C4 pic 11 in stimer exit on retry Hi I have recovery routine which got control on abend of stimer exit irb On retry I am getting S0C4 PIC 11 reloading my registers from the system primed r13 I check 13 on input before the abend and at the retry point and it has the same value When I abend in the stimer exit does the system do anything to my save area R13 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
0C4 pic 11 in stimer exit on retry
Hi I have recovery routine which got control on abend of stimer exit irb On retry I am getting S0C4 PIC 11 reloading my registers from the system primed r13 I check 13 on input before the abend and at the retry point and it has the same value When I abend in the stimer exit does the system do anything to my save area R13 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMER
TTIMER CANCEL Joe On Mon, Apr 8, 2024 at 4:43 PM Tony Thigpen wrote: > How do you cancel an outstanding STIMER? > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMER
You can cancel an STIMER via TTIMER CANCEL. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMER
If you need to cancel it, I think you have to change to STIMERM. I was just looking at the manual for this (2.4) and I had thought there was a way to cancel it, but the book indicates that STIMERM must be used if one needs to do a cancel. "Cancels a specific timer request (CANCEL parameter)" << this is under STIMERM Steve Thompson On 4/8/2024 5:42 PM, Tony Thigpen wrote: How do you cancel an outstanding STIMER? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
STIMER
How do you cancel an outstanding STIMER? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
This thread led me to wonder if there was a change from STIMER REAL (meaning a time interval, which is the default) to STIMER TASK (meaning a CPU time limit), or vice versa. Note that STIMERM does not support the "TASK" option (it was felt to be too complex, and not necessary, to have to deal with multiple such STIMER's associated with a task). A single exploiter can use STIMER TASK within the same task that has multiple exploiters using STIMERM REAL Using STIMER REAL to monitor task CPU time is not a good fit. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
I looked at the APAR text and I would consider it inaccurate (and/or incorrect). >From the APAR text: It should be noted: IMS establishes a time limit using the STIMER macro and the TASK parameter to indicate that the time interval is only decreased when the associated task is running. Any ESS that WAITs or SUSPENDs the IMS dependent region will therefore not decrease the time interval during these events and will not drive STIMER exit routines to issue abends. Use of "time limit" and "time interval" surely is an unclear usage of terms. STIMER TASK provides a "CPU Time limit" (most would not think of it that way if they see only "time limit"). And there is no "time interval". The STIMER remains in effect as long as it takes to use that much CPU time. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
Thanks for the link. Today I learned that what's included in the timing is controlled by the STIMER parameter in IMS procedures. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Sunday, January 28, 2024 3:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Has there always been STIMER TASK? [You don't often get email from fogar...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] That change was made a decade ago (in 2013 in IMS v13) to catch runaway Db2 activitty in the IMS transaction. See IMS Apar https://www.ibm.com/support/pages/apar/PM86872 On Sat, Jan 27, 2024 at 5:55 AM Schmitt, Michael wrote: > In IMS Transaction Manager you can define a PROCLIM for each transaction, > with a count and/or CPU-time-per-transaction, aka the "processing limit > count time". The manual says: > > This is the amount of time (for non-Fast-Path transactions, in seconds; > for Fast Path transactions, in hundredths of seconds) allowable to process > a all messages for a given transaction during a single schedule. The number > specifies the maximum CPU time allowed for each message to be processed in > the message processing region. The value is a number that can range from 1 > to 65 535. Specifying the maximum value means that no time limit is placed > on the application program. > > When a transaction exceeds the limit IMS abends it with a U0240: "a > message processing program exceeded the allowable execution time." > > I swear that it used to be that the calling chain of every U0240 ended in > the application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. > That implied that the way it worked was: > > > * IMS saves the transaction's CPU time at the start of the transaction > (or perhaps when the application retrieved its input message). > * Whenever the application called IMS, IMS would compute the CPU time > used so far and compare it to the process limit. > > But now I see U0240's are the result of an interrupt, which can hit > anywhere. For example, if the application was in it's own code when the > time runs out, the interrupt fires and IMS then abends with the U0240. > > What I'm wondering is, why the change? > > I'm guessing the way it is working now is IMS is setting an STIMER TASK > with an exit, which measures a 'task-time interval', measured by the CPU > timer only while the task is in execution. > > Was that not always an option? > > __ > Michael Schmitt | DXC Apps Development | MassMutual > (737) 910-8248 | michael.schm...@dxc.com > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
That change was made a decade ago (in 2013 in IMS v13) to catch runaway Db2 activitty in the IMS transaction. See IMS Apar https://www.ibm.com/support/pages/apar/PM86872 On Sat, Jan 27, 2024 at 5:55 AM Schmitt, Michael wrote: > In IMS Transaction Manager you can define a PROCLIM for each transaction, > with a count and/or CPU-time-per-transaction, aka the "processing limit > count time". The manual says: > > This is the amount of time (for non-Fast-Path transactions, in seconds; > for Fast Path transactions, in hundredths of seconds) allowable to process > a all messages for a given transaction during a single schedule. The number > specifies the maximum CPU time allowed for each message to be processed in > the message processing region. The value is a number that can range from 1 > to 65 535. Specifying the maximum value means that no time limit is placed > on the application program. > > When a transaction exceeds the limit IMS abends it with a U0240: "a > message processing program exceeded the allowable execution time." > > I swear that it used to be that the calling chain of every U0240 ended in > the application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. > That implied that the way it worked was: > > > * IMS saves the transaction's CPU time at the start of the transaction > (or perhaps when the application retrieved its input message). > * Whenever the application called IMS, IMS would compute the CPU time > used so far and compare it to the process limit. > > But now I see U0240's are the result of an interrupt, which can hit > anywhere. For example, if the application was in it's own code when the > time runs out, the interrupt fires and IMS then abends with the U0240. > > What I'm wondering is, why the change? > > I'm guessing the way it is working now is IMS is setting an STIMER TASK > with an exit, which measures a 'task-time interval', measured by the CPU > timer only while the task is in execution. > > Was that not always an option? > > __ > Michael Schmitt | DXC Apps Development | MassMutual > (737) 910-8248 | michael.schm...@dxc.com > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
If we think about, it, waiting for an IMS call before checking CPU time would not help stop runaway loops. Before the IMS tcb does the LINK to the application program it can easily set an STIMER(N) . It could theoretically also do it via a DIE. Don't recall if IMS MPPs have a restriction about using STIMER On Fri, 26 Jan 2024 18:55:12 + "Schmitt, Michael" wrote: :>In IMS Transaction Manager you can define a PROCLIM for each transaction, with a count and/or CPU-time-per-transaction, aka the "processing limit count time". The manual says: :>This is the amount of time (for non-Fast-Path transactions, in seconds; for Fast Path transactions, in hundredths of seconds) allowable to process a all messages for a given transaction during a single schedule. The number specifies the maximum CPU time allowed for each message to be processed in the message processing region. The value is a number that can range from 1 to 65 535. Specifying the maximum value means that no time limit is placed on the application program. :>When a transaction exceeds the limit IMS abends it with a U0240: "a message processing program exceeded the allowable execution time." :>I swear that it used to be that the calling chain of every U0240 ended in the application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. That implied that the way it worked was: :> * IMS saves the transaction's CPU time at the start of the transaction (or perhaps when the application retrieved its input message). :> * Whenever the application called IMS, IMS would compute the CPU time used so far and compare it to the process limit. :>But now I see U0240's are the result of an interrupt, which can hit anywhere. For example, if the application was in it's own code when the time runs out, the interrupt fires and IMS then abends with the U0240. :>What I'm wondering is, why the change? :>I'm guessing the way it is working now is IMS is setting an STIMER TASK with an exit, which measures a 'task-time interval', measured by the CPU timer only while the task is in execution. :>Was that not always an option? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has there always been STIMER TASK?
Bitsavers has IBM System/360 Operating System Control program Services, dated April, 1968. STIMER is in page 108. TASK and REAL are both there, as are exit and wait. Does that count as "always"? http://www.bitsavers.org/pdf/ibm/360/os/R01-08/C28-6541-1_Control_Program_Services_Apr66.pdf -- Tom Marchant On Fri, 26 Jan 2024 18:55:12 +, Schmitt, Michael wrote: >In IMS Transaction Manager you can define a PROCLIM for each transaction, with >a count and/or CPU-time-per-transaction, aka the "processing limit count >time". The manual says: > >This is the amount of time (for non-Fast-Path transactions, in seconds; for >Fast Path transactions, in hundredths of seconds) allowable to process a all >messages for a given transaction during a single schedule. The number >specifies the maximum CPU time allowed for each message to be processed in the >message processing region. The value is a number that can range from 1 to 65 >535. Specifying the maximum value means that no time limit is placed on the >application program. > >When a transaction exceeds the limit IMS abends it with a U0240: "a message >processing program exceeded the allowable execution time." > >I swear that it used to be that the calling chain of every U0240 ended in the >application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. That >implied that the way it worked was: > > > * IMS saves the transaction's CPU time at the start of the transaction (or > perhaps when the application retrieved its input message). > * Whenever the application called IMS, IMS would compute the CPU time used > so far and compare it to the process limit. > >But now I see U0240's are the result of an interrupt, which can hit anywhere. >For example, if the application was in it's own code when the time runs out, >the interrupt fires and IMS then abends with the U0240. > >What I'm wondering is, why the change? > >I'm guessing the way it is working now is IMS is setting an STIMER TASK with >an exit, which measures a 'task-time interval', measured by the CPU timer only >while the task is in execution. > >Was that not always an option? > >__ >Michael Schmitt | DXC Apps Development | MassMutual -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Has there always been STIMER TASK?
In IMS Transaction Manager you can define a PROCLIM for each transaction, with a count and/or CPU-time-per-transaction, aka the "processing limit count time". The manual says: This is the amount of time (for non-Fast-Path transactions, in seconds; for Fast Path transactions, in hundredths of seconds) allowable to process a all messages for a given transaction during a single schedule. The number specifies the maximum CPU time allowed for each message to be processed in the message processing region. The value is a number that can range from 1 to 65 535. Specifying the maximum value means that no time limit is placed on the application program. When a transaction exceeds the limit IMS abends it with a U0240: "a message processing program exceeded the allowable execution time." I swear that it used to be that the calling chain of every U0240 ended in the application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. That implied that the way it worked was: * IMS saves the transaction's CPU time at the start of the transaction (or perhaps when the application retrieved its input message). * Whenever the application called IMS, IMS would compute the CPU time used so far and compare it to the process limit. But now I see U0240's are the result of an interrupt, which can hit anywhere. For example, if the application was in it's own code when the time runs out, the interrupt fires and IMS then abends with the U0240. What I'm wondering is, why the change? I'm guessing the way it is working now is IMS is setting an STIMER TASK with an exit, which measures a 'task-time interval', measured by the CPU timer only while the task is in execution. Was that not always an option? __ Michael Schmitt | DXC Apps Development | MassMutual (737) 910-8248 | michael.schm...@dxc.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
As was mentioned in one of the threads, you need to follow the RB chain (TCBRBP points to the newest). The STIMER exit itself is running as an IRB. When any RB ends normally, the registers associated with the previously running RB (some saved in the current RB, some in the RB's XSB) and the PSW associated with the previously running RB (saved in that previous RB/XSB) is used to give control (thus has the next instruction address). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
As you are unlocked, the TCB would not be the place to look. You would examine the previous RB - which might be in the middle of something not part of your code - to determine exactly what you want. For example, if you determine that you are in the middle of an I/O routine, you probably would want to find where in your application the I/O was invoked. How would you use this information? On Fri, 20 Oct 2017 10:30:55 -0400 Thomas David Rivers wrote: :>Well - :> :> When an STIMER (STIMERM) exit "pops" - there is little to say :> about the state of the task... but, if you wanted to know _where_ :> the program was executing at the time of the exit... where would :> you look? :> :> I wandered around the TCB a little - but nothing was immediately :> obvious; and I thought someone here probably knows precisely :> where this is kept. :> :> - Thanks - :> - Dave Rivers - -- Binyamin Dissen 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
>Strictly a guess on my part, but I'd bet that your exit is running under an IRB chained to a PRB. I would further guess that the PSW and REGS at the time the STIMERM popped would be in that PRB. Of course, this is strictly a guess on my part and is not GUPI. Registers and (old) PSW are stored at different places. Registers are stored in the current (I)RB control block (and extensiotn to it), the PSW is stored in the RB (PRB, IRB, SVRB, ...) that was the current RB at the time the IRB was instantiated. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
Charles Mills wrote: And of course the next instruction might not be in your load module, it might be in some service your code called. I suspect your original need is solvable but might be a larger container of worms than might be anticipated. Charles Yeah - that's quite all right though - let's me know where it is... - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
And of course the next instruction might not be in your load module, it might be in some service your code called. I suspect your original need is solvable but might be a larger container of worms than might be anticipated. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, October 20, 2017 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit? On Fri, Oct 20, 2017 at 9:30 AM, Thomas David Rivers wrote: > Well - > > When an STIMER (STIMERM) exit "pops" - there is little to say about > the state of the task... but, if you wanted to know _where_ the > program was executing at the time of the exit... where would you look? > > I wandered around the TCB a little - but nothing was immediately > obvious; and I thought someone here probably knows precisely where > this is kept. > > - Thanks - > - Dave Rivers - > > -- > Strictly a guess on my part, but I'd bet that your exit is running under an IRB chained to a PRB. I would further guess that the PSW and REGS at the time the STIMERM popped would be in that PRB. Of course, this is strictly a guess on my part and is not GUPI. -- I just child proofed my house. But the kids still manage to get in. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine tasks PSWA "next instruction to execute" from an STIMER exit?
On Fri, Oct 20, 2017 at 9:30 AM, Thomas David Rivers wrote: > Well - > > When an STIMER (STIMERM) exit "pops" - there is little to say > about the state of the task... but, if you wanted to know _where_ > the program was executing at the time of the exit... where would > you look? > > I wandered around the TCB a little - but nothing was immediately > obvious; and I thought someone here probably knows precisely > where this is kept. > > - Thanks - > - Dave Rivers - > > -- > Strictly a guess on my part, but I'd bet that your exit is running under an IRB chained to a PRB. I would further guess that the PSW and REGS at the time the STIMERM popped would be in that PRB. Of course, this is strictly a guess on my part and is not GUPI. -- I just child proofed my house. But the kids still manage to get in. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Determine tasks PSWA "next instruction to execute" from an STIMER exit?
Well - When an STIMER (STIMERM) exit "pops" - there is little to say about the state of the task... but, if you wanted to know _where_ the program was executing at the time of the exit... where would you look? I wandered around the TCB a little - but nothing was immediately obvious; and I thought someone here probably knows precisely where this is kept. - Thanks - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
