Re: Registers in the RB
Peter Thank you for explaining it I really think I get it I agree I can generalize a recovery I am changing file192 thinking of it as estate Including cases where there is abend in 1) SVC 2) PC For these I am going to locate the user registers and off set And include for all cases when appropriate 64 bit regs. Thank you again > On Feb 5, 2024, at 3:20 AM, Peter Relson > <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > The fact that registers are saved (or at least land) in the "new RB" and the > PSW in the "old RB" was described many posts earlier. That applies in all > cases where a new (not "first") RB is created. Note that just when that > saving happens can be kind of funky for a case such as XCTL(X). > > The problem that keeps cropping up in the posts is that the OP keeps making > judgments and assumptions that are not true (sometimes because they are > wrong, sometimes because they are incomplete). And these are under the guise > of enhancing a general recovery routine that never was a general recovery > routine, and based on the questions being asked will not be (because it won't > be suitable for an FRR). Now if it's a general ESTAE-type recovery routine, > perhaps that would be a reasonable goal. > > If we want to be picky, System 0C1 is not an abend code. System 0C4 is not an > abend code. These are completion codes which might or might not result from > ABEND. > For purposes of example the hardware gives control to the program check > FLIH for interrupt code 4 the program check FLIH issues ABEND abend code > 0C4 reason 4 > Well, not exactly. Let's try to be accurate. The program check FLIH issues > SOMETHING that results in recovery seeing a system completion code of 0C4 > reason 4. That SOMETHING happens to be CALLRTM TYPE=PROGCK, about which I > will not provide any additional information. There is no ABEND at this point. > > By the way there are more reason codes for 0C4 than 4,10,11 as of > z/Architecture. > We keep saying that not everything that disrupts a running work unit creates > an RB. It is therefore obviously the case that the registers are saved > somewhere; they are not in a "new RB" when there is no new RB. > > Consider the case where there was a program check when there is an FRR. RTM > understands how to convert a program interrupt code to a system completion > code. It does so, so that it can place that in the proper areas (such as the > SDWA and TCBCMPC and STCBCMPC), and it got the time of error regs from where > the PC FLIH put them. If the FRR retries, no new RB was ever involved. > But let's say that all FRRs percolate, now this is where my hint comes in. > RTM issues an SVC D. This is unlike an application-issued (or other > system-issued) SVC D. But it is still an SVC D which is a type 2 SVC and thus > creates a new RB. Within this RB, the system places the time of error regs > that had been stashed earlier.If you want to find the time of error regs and > you can find RTM's SVRB, they are in there. > > As to the question about high halves (and ARs for that matter), they are > saved in the XSB that corresponds to the RB that has the low halves. > > There was mention about SVC D as being an SVC that can be issued in any > environment, such as being disabled (where normal SVCs cannot). That is not > accurate either (although it's not unreasonable to think of it that way). > When any SVC (x'D' is included) is issued in an improper-for-SVC environment, > the same thing happens - the SVC FLIH issues CALLRTM TYPE=SVCERR. You don't > get an RB for CALLRTM for a type 2 SVC (x'D' is included) issued in an > improper-for-SVC environment. Flow then proceeds similar to the program > interrupt case through FRR processing. If an FRR retries (ignoring a nested > FRR), that's that, no "abend" SVC was successfully processed. If we need to > get to RTM 2 for ESTAE (or even task termination) processing, then the > special SVC D is issued. > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
I have a suggestion. Try writing an IPCS CLIST that does the formatting you want. Try it on multiple dumps. When you get the CLIST worked out, then perhaps consider putting it in a recovery routine. On Sun, 4 Feb 2024 12:53:16 -0500 Joseph Reichman wrote: :>And they are in the manual you previously :> :>Posted ? :> :> :>Just for clarity sake :> :>Just ran a small test :> :>For the interrupt PSW which in the case of some PRB s might have a cde :> :>The registers that go along with that RBOPSW :>Are always in the next rb :> :>Regardless of the cause of the interrupt :> :>Hope this is right :> :>Thank you very much all :> :>> On Feb 4, 2024, at 11:49?AM, Seymour J Metz wrote: :>> :>> ?Yes, expressed in hexadecimal. Systems Codes has a complete list of program interrupt codes that can cause an S0C4 if not intercepted. :>> :>> -- :>> Shmuel (Seymour J.) Metz :>> http://mason.gmu.edu/~smetz3 :>> ??? ?? ??? :>> ?? ??? ?? :>> :>> :>> From: IBM Mainframe Discussion List on behalf of Joseph Reichman :>> Sent: Sunday, February 4, 2024 11:45 AM :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Subject: Re: Registers in the RB :>> :>> :>> Seymour :>> :>> When you say for example IC10 you are referring what would be in RBINTCOD correct ? :>> :>>> On Feb 4, 2024, at 11:33?AM, Seymour J Metz wrote: :>>> ?Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to be due to e.g., IC10, IC11. In MVT it's always IC04. :>>> :>>> -- :>>> Shmuel (Seymour J.) Metz :>>> http://mason.gmu.edu/~smetz3 :>>> ??? ?? ??? :>>> ?????? ??????? ?? :>>> :>>> :>>> From: IBM Mainframe Discussion List on behalf of Joseph Reichman :>>> Sent: Sunday, February 4, 2024 11:11 AM :>>> To: IBM-MAIN@LISTSERV.UA.EDU :>>> Subject: Re: Registers in the RB :>>> :>>> Im trying to understand so that u dont mess things up :>>> :>>> The way Seymour explained it :>>> :>>> For purposes of example the hardware gives control to the program check :>>> FLIH for interrupt code 4 the program check FLIH issues ABEND abend code :>>> 0C4 reason 4 :>>> :>>> Joe Reichman :>>> :>>> :>>>> On Sun, Feb 4, 2024 at 11:06?AM Binyamin Dissen :>>>> wrote: :>>>> :>>>> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman :>>>> wrote: :>>>> :>>>> :>But thought S0C4 is a program check :>>>> :>>>> It is. :>>>> :>>>> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. :>>>> :>>>> An error recovery routine that messes up things is worse than none. :>>>> :>>>> -- :>>>> Binyamin Dissen :>>>> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 :>>> :>>> -- :>>> 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 :>> :>> :>> -- :>> 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 -- 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: Registers in the RB
The fact that registers are saved (or at least land) in the "new RB" and the PSW in the "old RB" was described many posts earlier. That applies in all cases where a new (not "first") RB is created. Note that just when that saving happens can be kind of funky for a case such as XCTL(X). The problem that keeps cropping up in the posts is that the OP keeps making judgments and assumptions that are not true (sometimes because they are wrong, sometimes because they are incomplete). And these are under the guise of enhancing a general recovery routine that never was a general recovery routine, and based on the questions being asked will not be (because it won't be suitable for an FRR). Now if it's a general ESTAE-type recovery routine, perhaps that would be a reasonable goal. If we want to be picky, System 0C1 is not an abend code. System 0C4 is not an abend code. These are completion codes which might or might not result from ABEND. For purposes of example the hardware gives control to the program check FLIH for interrupt code 4 the program check FLIH issues ABEND abend code 0C4 reason 4 Well, not exactly. Let's try to be accurate. The program check FLIH issues SOMETHING that results in recovery seeing a system completion code of 0C4 reason 4. That SOMETHING happens to be CALLRTM TYPE=PROGCK, about which I will not provide any additional information. There is no ABEND at this point. By the way there are more reason codes for 0C4 than 4,10,11 as of z/Architecture. We keep saying that not everything that disrupts a running work unit creates an RB. It is therefore obviously the case that the registers are saved somewhere; they are not in a "new RB" when there is no new RB. Consider the case where there was a program check when there is an FRR. RTM understands how to convert a program interrupt code to a system completion code. It does so, so that it can place that in the proper areas (such as the SDWA and TCBCMPC and STCBCMPC), and it got the time of error regs from where the PC FLIH put them. If the FRR retries, no new RB was ever involved. But let's say that all FRRs percolate, now this is where my hint comes in. RTM issues an SVC D. This is unlike an application-issued (or other system-issued) SVC D. But it is still an SVC D which is a type 2 SVC and thus creates a new RB. Within this RB, the system places the time of error regs that had been stashed earlier.If you want to find the time of error regs and you can find RTM's SVRB, they are in there. As to the question about high halves (and ARs for that matter), they are saved in the XSB that corresponds to the RB that has the low halves. There was mention about SVC D as being an SVC that can be issued in any environment, such as being disabled (where normal SVCs cannot). That is not accurate either (although it's not unreasonable to think of it that way). When any SVC (x'D' is included) is issued in an improper-for-SVC environment, the same thing happens - the SVC FLIH issues CALLRTM TYPE=SVCERR. You don't get an RB for CALLRTM for a type 2 SVC (x'D' is included) issued in an improper-for-SVC environment. Flow then proceeds similar to the program interrupt case through FRR processing. If an FRR retries (ignoring a nested FRR), that's that, no "abend" SVC was successfully processed. If we need to get to RTM 2 for ESTAE (or even task termination) processing, then the special SVC D is issued. 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: Registers in the RB
CDE is irrelevant; an exit from an RB always gets the registers from the current registers and the exiting RB, and always gets the PSW from the previous RB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 6:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB That for all interrupts PSW and CDE if one exits is in old register in new Thanks > On Feb 4, 2024, at 6:40 PM, Seymour J Metz wrote: > > Yes, general registers go in the new RB, PSW in the old. Whent the task is > not running the newest RB holds the PSW and the TCB holds the general > registers. I havent checked how the top halves are handled. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 12:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > And they are in the manual you previously > > Posted ? > > > Just for clarity sake > > Just ran a small test > > For the interrupt PSW which in the case of some PRB s might have a cde > > The registers that go along with that RBOPSW > Are always in the next rb > > Regardless of the cause of the interrupt > > Hope this is right > > Thank you very much all > >> On Feb 4, 2024, at 11:49 AM, Seymour J Metz wrote: >> >> Yes, expressed in hexadecimal. Systems Codes has a complete list of program >> interrupt codes that can cause an S0C4 if not intercepted. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> ____________ >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman >> Sent: Sunday, February 4, 2024 11:45 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >> >> Seymour >> >> When you say for example IC10 you are referring what would be in RBINTCOD >> correct ? >> >>>> On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: >>> Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely >>> to be due to e.g., IC10, IC11. In MVT it's always IC04. >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> עַם יִשְׂרָאֵל חַי >>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >>> >>> >>> From: IBM Mainframe Discussion List on behalf of >>> Joseph Reichman >>> Sent: Sunday, February 4, 2024 11:11 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Registers in the RB >>> >>> I’m trying to understand so that u don’t mess things up >>> >>> The way Seymour explained it >>> >>> For purposes of example the hardware gives control to the program check >>> FLIH for interrupt code 4 the program check FLIH issues ABEND abend code >>> 0C4 reason 4 >>> >>> Joe Reichman >>> >>> >>>> On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen >>>> >>>> wrote: >>>> >>>> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >>>> wrote: >>>> >>>> :>But thought S0C4 is a program check >>>> >>>> It is. >>>> >>>> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >>>> >>>> An error recovery routine that messes up things is worse than none. >>>> >>>> -- >>>> Binyamin Dissen >>>> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.dissensoftware.com >>>> >>>> Director, Dissen Software, Bar & Grill - Israel >>>> >>>> -- >>>> For I
Re: Registers in the RB
That for all interrupts PSW and CDE if one exits is in old register in new Thanks > On Feb 4, 2024, at 6:40 PM, Seymour J Metz wrote: > > Yes, general registers go in the new RB, PSW in the old. Whent the task is > not running the newest RB holds the PSW and the TCB holds the general > registers. I havent checked how the top halves are handled. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 12:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > And they are in the manual you previously > > Posted ? > > > Just for clarity sake > > Just ran a small test > > For the interrupt PSW which in the case of some PRB s might have a cde > > The registers that go along with that RBOPSW > Are always in the next rb > > Regardless of the cause of the interrupt > > Hope this is right > > Thank you very much all > >> On Feb 4, 2024, at 11:49 AM, Seymour J Metz wrote: >> >> Yes, expressed in hexadecimal. Systems Codes has a complete list of program >> interrupt codes that can cause an S0C4 if not intercepted. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> ____________ >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman >> Sent: Sunday, February 4, 2024 11:45 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >> >> Seymour >> >> When you say for example IC10 you are referring what would be in RBINTCOD >> correct ? >> >>>> On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: >>> Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely >>> to be due to e.g., IC10, IC11. In MVT it's always IC04. >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> עַם יִשְׂרָאֵל חַי >>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >>> >>> >>> From: IBM Mainframe Discussion List on behalf of >>> Joseph Reichman >>> Sent: Sunday, February 4, 2024 11:11 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Registers in the RB >>> >>> I’m trying to understand so that u don’t mess things up >>> >>> The way Seymour explained it >>> >>> For purposes of example the hardware gives control to the program check >>> FLIH for interrupt code 4 the program check FLIH issues ABEND abend code >>> 0C4 reason 4 >>> >>> Joe Reichman >>> >>> >>>> On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen >>>> >>>> wrote: >>>> >>>> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >>>> wrote: >>>> >>>> :>But thought S0C4 is a program check >>>> >>>> It is. >>>> >>>> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >>>> >>>> An error recovery routine that messes up things is worse than none. >>>> >>>> -- >>>> Binyamin Dissen >>>> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> >>&
Re: Registers in the RB
Yes, general registers go in the new RB, PSW in the old. Whent the task is not running the newest RB holds the PSW and the TCB holds the general registers. I havent checked how the top halves are handled. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 12:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB And they are in the manual you previously Posted ? Just for clarity sake Just ran a small test For the interrupt PSW which in the case of some PRB s might have a cde The registers that go along with that RBOPSW Are always in the next rb Regardless of the cause of the interrupt Hope this is right Thank you very much all > On Feb 4, 2024, at 11:49 AM, Seymour J Metz wrote: > > Yes, expressed in hexadecimal. Systems Codes has a complete list of program > interrupt codes that can cause an S0C4 if not intercepted. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > > Seymour > > When you say for example IC10 you are referring what would be in RBINTCOD > correct ? > >> On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: >> Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to >> be due to e.g., IC10, IC11. In MVT it's always IC04. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman >> Sent: Sunday, February 4, 2024 11:11 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >> I’m trying to understand so that u don’t mess things up >> >> The way Seymour explained it >> >> For purposes of example the hardware gives control to the program check >> FLIH for interrupt code 4 the program check FLIH issues ABEND abend code >> 0C4 reason 4 >> >> Joe Reichman >> >> >>> On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen >>> wrote: >>> >>> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >>> wrote: >>> >>> :>But thought S0C4 is a program check >>> >>> It is. >>> >>> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >>> >>> An error recovery routine that messes up things is worse than none. >>> >>> -- >>> Binyamin Dissen >>> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 >> >> -- >> 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 > > > -- > 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: Registers in the RB
And they are in the manual you previously Posted ? Just for clarity sake Just ran a small test For the interrupt PSW which in the case of some PRB s might have a cde The registers that go along with that RBOPSW Are always in the next rb Regardless of the cause of the interrupt Hope this is right Thank you very much all > On Feb 4, 2024, at 11:49 AM, Seymour J Metz wrote: > > Yes, expressed in hexadecimal. Systems Codes has a complete list of program > interrupt codes that can cause an S0C4 if not intercepted. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > > Seymour > > When you say for example IC10 you are referring what would be in RBINTCOD > correct ? > >> On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: >> Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to >> be due to e.g., IC10, IC11. In MVT it's always IC04. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> >> From: IBM Mainframe Discussion List on behalf of >> Joseph Reichman >> Sent: Sunday, February 4, 2024 11:11 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >> I’m trying to understand so that u don’t mess things up >> >> The way Seymour explained it >> >> For purposes of example the hardware gives control to the program check >> FLIH for interrupt code 4 the program check FLIH issues ABEND abend code >> 0C4 reason 4 >> >> Joe Reichman >> >> >>> On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen >>> wrote: >>> >>> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >>> wrote: >>> >>> :>But thought S0C4 is a program check >>> >>> It is. >>> >>> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >>> >>> An error recovery routine that messes up things is worse than none. >>> >>> -- >>> Binyamin Dissen >>> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 >> >> -- >> 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 > > > -- > 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: Registers in the RB
Yes, expressed in hexadecimal. Systems Codes has a complete list of program interrupt codes that can cause an S0C4 if not intercepted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB Seymour When you say for example IC10 you are referring what would be in RBINTCOD correct ? > On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: > Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to > be due to e.g., IC10, IC11. In MVT it's always IC04. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 11:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > I’m trying to understand so that u don’t mess things up > > The way Seymour explained it > > For purposes of example the hardware gives control to the program check > FLIH for interrupt code 4 the program check FLIH issues ABEND abend code > 0C4 reason 4 > > Joe Reichman > > > On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen > wrote: > >> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >> wrote: >> >> :>But thought S0C4 is a program check >> >> It is. >> >> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >> >> An error recovery routine that messes up things is worse than none. >> >> -- >> Binyamin Dissen >> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
S0C4 was originally only for IC04, and in OS/VS it was only IC04, IC10 and IC11, but nowadays it can also be because of, e.g. IC28. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Binyamin Dissen Sent: Sunday, February 4, 2024 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman wrote: :>But thought S0C4 is a program check It is. It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. An error recovery routine that messes up things is worse than none. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
Seymour When you say for example IC10 you are referring what would be in RBINTCOD correct ? > On Feb 4, 2024, at 11:33 AM, Seymour J Metz wrote: > Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to > be due to e.g., IC10, IC11. In MVT it's always IC04. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Sunday, February 4, 2024 11:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > > I’m trying to understand so that u don’t mess things up > > The way Seymour explained it > > For purposes of example the hardware gives control to the program check > FLIH for interrupt code 4 the program check FLIH issues ABEND abend code > 0C4 reason 4 > > Joe Reichman > > > On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen > wrote: > >> On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman >> wrote: >> >> :>But thought S0C4 is a program check >> >> It is. >> >> It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. >> >> An error recovery routine that messes up things is worse than none. >> >> -- >> Binyamin Dissen >> http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 > > -- > 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: Registers in the RB
Since OS/VS, interrupt code 04 is less common amd an S0C4 is more likely to be due to e.g., IC10, IC11. In MVT it's always IC04. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB I’m trying to understand so that u don’t mess things up The way Seymour explained it For purposes of example the hardware gives control to the program check FLIH for interrupt code 4 the program check FLIH issues ABEND abend code 0C4 reason 4 Joe Reichman On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen wrote: > On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman > wrote: > > :>But thought S0C4 is a program check > > It is. > > It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. > > An error recovery routine that messes up things is worse than none. > > -- > Binyamin Dissen > http://secure-web.cisco.com/1816mdJ8h5-_oO1Xw58w3a8lEY_-kExorCz4aYg_qWRPUg_S6L1Z7PSPpA_kZcoVdyWJRO7o8CZk3cdmof4xYFKWUq5F_354st8NqQ1H-DfhXLX7hOZMR91CjoL1YT6Mbzl6njAZmKFdodaka0a1fK4YYTFZC0MgMlnj3ZJIgBM_AqiHoqGC_AbIMpQH0IAacZQAZlVgvJf80mITj1INV2l7F5k_pFjt0QOTQKtvKl1ATyTUInntV2lYhaRLgGmYZAWVJIDYXYDUZJUKOWAxwAMDRvCZ_zlmMheKUwEgmhUqjkH-LZSn6EJ0dT3AX1KtXJ7SEVz6_Ju0n0gr_1s7lMc-k6E1u0vGItaEOADznerc8n-GIWT-wkJUZtCSSs1yckiVlCN-FkVRjnrgwLsd35OJUqktorRcnmAbG4EHP89E/http%3A%2F%2Fwww.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 > -- 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: Registers in the RB
I’m trying to understand so that u don’t mess things up The way Seymour explained it For purposes of example the hardware gives control to the program check FLIH for interrupt code 4 the program check FLIH issues ABEND abend code 0C4 reason 4 Joe Reichman On Sun, Feb 4, 2024 at 11:06 AM Binyamin Dissen wrote: > On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman > wrote: > > :>But thought S0C4 is a program check > > It is. > > It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. > > An error recovery routine that messes up things is worse than none. > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
On Sun, 4 Feb 2024 10:29:59 -0500 Joseph Reichman wrote: :>But thought S0C4 is a program check It is. It may be a pic-4,-10, or -11. If PIC-4, PSW was updated. An error recovery routine that messes up things is worse than none. -- 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: Registers in the RB
No, if you get a system BEND 0C1 then the program interrupt code was 01; the is no program interrupt code 0C1. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB Can you for proposed that I understand differentiate between a program check and abend S0C1 is a program check S0C4 is not I understand the abend SVC 13 is not a program check But thought S0C4 is a program check Thank you > On Feb 4, 2024, at 10:27 AM, Joseph Reichman wrote: > > Seymour thanks > > This Manuel is from from 1987 ? > > Micheal was 1976 > > Is this still valid ? > > I’ll read it in really not looking for easy way out > > Peter R said he answered in this general thread > > I did look back before posting > > The only thing I noticed was in the case of an abend for example 0F8 the type > of abend issued by the SVC FLIH the registers are in the next RB or ABend > SVCRB > > I thought in the case of a program check I.E. S0C1,4 etc it would be by that > I mean the registers and PSW in the PRB that represented that unit of work > > This program that abended was initiated by synch SVC 12 but I wasn’t looking > at the SVRB but the PRB > > Thanks > >> On Feb 4, 2024, at 10:14 AM, Seymour J Metz wrote: >> >> The processing for SYNCH is the same whether it is issued from a PRB or an >> SVRB; the caller's PSW goes into the old RB and the caller's general >> registers go into the new PRB. >> >> <http://.bitsavers.org/pdf/ibm/370/MVS_XA/LY28-1765-0_MVS_XA_Version_2_Release_2.0_System_Logic_Library_Supervisor_Control_Jun1987.pdf> >> is newer. >> >> Sometimes they get better. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> ____________ >> From: IBM Mainframe Discussion List on behalf of >> Michael Stein >> Sent: Sunday, February 4, 2024 4:06 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >>>> On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: >>> It was my understanding probably erroneously that when a RB I guess I am >>> talking about a PRB gets interrupted and that can happen in one of two >>> instances >>> >>> 1)An SVC >>> 2)A Program check e.g. S0C1,4, >> >> There are many interrupts possible: External, I/O, Program, SVC plus a few >> others. Also including software caused like asynchronous exit routines. >> >> The bottom level of the system has to deal with these and one of it's >> main concerns is where to save the state of whatever was running when >> the interrupt happened. >> >> Since there are multiple CPUs and many many tasks & SRBs etc, it's >> important that the state information (PSW & registers) are only saved >> in areas others won't use at the same time otherwise they would get >> overlay by another interrupt or processor leading to disaster. >> >> While the OS interrupt routines have processor related storage they can >> only use this during the time they are disabled. If they are going to >> return to the interrupted work then they can restore them and return, >> otherwise they must move/save the state elsewhere before they enable. >> >> For an OS task the registers and PSW are saved in task related control >> blocks, a combination of the TCB and RBs. >> >> The SVC interrupt handler save state depending on the type of SVC: >> >> type 1: (required to hold local lock, so can use areas address space >> related)) >> registers -> TCBGRS (?) >> PSW -> some address space related area (?) >> >> type 2,3,4: (doesn't require holding local lock so can't use address space >>related area) >> . SVC caller's PSW & interupt code in top RB on TCB RB chain >> . gets SVRB, puts SVC issuer registers into this SVRB >> and addes it to the top of the TCB RB chain >> so: >> . SVRB register contain the SVC issuer's registers >> . SVRB PSW is the SVC routines PSW >> . TCBGRS is the SVC routines registers >> >> Keep in mind that a type 2,3,4 SVC can issue another SVC (which will >> if type 2,3,4 add
Re: Registers in the RB
The cited OS/VS2 PLM is for release 3.7; It's backlevel for the MVS turnkey system, but I don't know of an online repository that has the 3.8 version with SU updates. Similarly, the cited OS/360 MVT PLM is for R17, way back-level for the 21,8 turnkey system, and I don' know of a more recent online copy. Is there anybody in the DC metropolitan area willing to scan and OCR a bunch of manuals for bitsavers? I have dead trees that are not on their site. 0C4 is a system ABEND code that can occur as the result of, e,g., program interrupt codes 04, 10, 11; there is no program interrupt code 0C4. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 4, 2024 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB Seymour thanks This Manuel is from from 1987 ? Micheal was 1976 Is this still valid ? I’ll read it in really not looking for easy way out Peter R said he answered in this general thread I did look back before posting The only thing I noticed was in the case of an abend for example 0F8 the type of abend issued by the SVC FLIH the registers are in the next RB or ABend SVCRB I thought in the case of a program check I.E. S0C1,4 etc it would be by that I mean the registers and PSW in the PRB that represented that unit of work This program that abended was initiated by synch SVC 12 but I wasn’t looking at the SVRB but the PRB Thanks > On Feb 4, 2024, at 10:14 AM, Seymour J Metz wrote: > > The processing for SYNCH is the same whether it is issued from a PRB or an > SVRB; the caller's PSW goes into the old RB and the caller's general > registers go into the new PRB. > > <http://.bitsavers.org/pdf/ibm/370/MVS_XA/LY28-1765-0_MVS_XA_Version_2_Release_2.0_System_Logic_Library_Supervisor_Control_Jun1987.pdf> > is newer. > > Sometimes they get better. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Michael Stein > Sent: Sunday, February 4, 2024 4:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > >> On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: >> It was my understanding probably erroneously that when a RB I guess I am >> talking about a PRB gets interrupted and that can happen in one of two >> instances >> >> 1)An SVC >> 2)A Program check e.g. S0C1,4, > > There are many interrupts possible: External, I/O, Program, SVC plus a few > others. Also including software caused like asynchronous exit routines. > > The bottom level of the system has to deal with these and one of it's > main concerns is where to save the state of whatever was running when > the interrupt happened. > > Since there are multiple CPUs and many many tasks & SRBs etc, it's > important that the state information (PSW & registers) are only saved > in areas others won't use at the same time otherwise they would get > overlay by another interrupt or processor leading to disaster. > > While the OS interrupt routines have processor related storage they can > only use this during the time they are disabled. If they are going to > return to the interrupted work then they can restore them and return, > otherwise they must move/save the state elsewhere before they enable. > > For an OS task the registers and PSW are saved in task related control > blocks, a combination of the TCB and RBs. > > The SVC interrupt handler save state depending on the type of SVC: > > type 1: (required to hold local lock, so can use areas address space related)) >registers -> TCBGRS (?) >PSW -> some address space related area (?) > > type 2,3,4: (doesn't require holding local lock so can't use address space > related area) >. SVC caller's PSW & interupt code in top RB on TCB RB chain >. gets SVRB, puts SVC issuer registers into this SVRB > and addes it to the top of the TCB RB chain > so: >. SVRB register contain the SVC issuer's registers >. SVRB PSW is the SVC routines PSW >. TCBGRS is the SVC routines registers > > Keep in mind that a type 2,3,4 SVC can issue another SVC (which will > if type 2,3,4 add another SVRB). Or it might issue the SYNCH SVC > resulting in an RB being added to the RB chain (holding the SVC issuing > SYNCH's PSW. Where the SVCs routine registers go I don't know. > Perhaps SYNCH with restore=y
Re: Registers in the RB
Can you for proposed that I understand differentiate between a program check and abend S0C1 is a program check S0C4 is not I understand the abend SVC 13 is not a program check But thought S0C4 is a program check Thank you > On Feb 4, 2024, at 10:27 AM, Joseph Reichman wrote: > > Seymour thanks > > This Manuel is from from 1987 ? > > Micheal was 1976 > > Is this still valid ? > > I’ll read it in really not looking for easy way out > > Peter R said he answered in this general thread > > I did look back before posting > > The only thing I noticed was in the case of an abend for example 0F8 the type > of abend issued by the SVC FLIH the registers are in the next RB or ABend > SVCRB > > I thought in the case of a program check I.E. S0C1,4 etc it would be by that > I mean the registers and PSW in the PRB that represented that unit of work > > This program that abended was initiated by synch SVC 12 but I wasn’t looking > at the SVRB but the PRB > > Thanks > >> On Feb 4, 2024, at 10:14 AM, Seymour J Metz wrote: >> >> The processing for SYNCH is the same whether it is issued from a PRB or an >> SVRB; the caller's PSW goes into the old RB and the caller's general >> registers go into the new PRB. >> >> <http://.bitsavers.org/pdf/ibm/370/MVS_XA/LY28-1765-0_MVS_XA_Version_2_Release_2.0_System_Logic_Library_Supervisor_Control_Jun1987.pdf> >> is newer. >> >> Sometimes they get better. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> ____________ >> From: IBM Mainframe Discussion List on behalf of >> Michael Stein >> Sent: Sunday, February 4, 2024 4:06 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Registers in the RB >> >>>> On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: >>> It was my understanding probably erroneously that when a RB I guess I am >>> talking about a PRB gets interrupted and that can happen in one of two >>> instances >>> >>> 1)An SVC >>> 2)A Program check e.g. S0C1,4, >> >> There are many interrupts possible: External, I/O, Program, SVC plus a few >> others. Also including software caused like asynchronous exit routines. >> >> The bottom level of the system has to deal with these and one of it's >> main concerns is where to save the state of whatever was running when >> the interrupt happened. >> >> Since there are multiple CPUs and many many tasks & SRBs etc, it's >> important that the state information (PSW & registers) are only saved >> in areas others won't use at the same time otherwise they would get >> overlay by another interrupt or processor leading to disaster. >> >> While the OS interrupt routines have processor related storage they can >> only use this during the time they are disabled. If they are going to >> return to the interrupted work then they can restore them and return, >> otherwise they must move/save the state elsewhere before they enable. >> >> For an OS task the registers and PSW are saved in task related control >> blocks, a combination of the TCB and RBs. >> >> The SVC interrupt handler save state depending on the type of SVC: >> >> type 1: (required to hold local lock, so can use areas address space >> related)) >> registers -> TCBGRS (?) >> PSW -> some address space related area (?) >> >> type 2,3,4: (doesn't require holding local lock so can't use address space >>related area) >> . SVC caller's PSW & interupt code in top RB on TCB RB chain >> . gets SVRB, puts SVC issuer registers into this SVRB >> and addes it to the top of the TCB RB chain >> so: >> . SVRB register contain the SVC issuer's registers >> . SVRB PSW is the SVC routines PSW >> . TCBGRS is the SVC routines registers >> >> Keep in mind that a type 2,3,4 SVC can issue another SVC (which will >> if type 2,3,4 add another SVRB). Or it might issue the SYNCH SVC >> resulting in an RB being added to the RB chain (holding the SVC issuing >> SYNCH's PSW. Where the SVCs routine registers go I don't know. >> Perhaps SYNCH with restore=yes is newer? >> >> Also IRBs for asynchronous exit routines can be added to the RB chain. >> In this case the interrupted registers will be in the
Re: Registers in the RB
Seymour thanks This Manuel is from from 1987 ? Micheal was 1976 Is this still valid ? I’ll read it in really not looking for easy way out Peter R said he answered in this general thread I did look back before posting The only thing I noticed was in the case of an abend for example 0F8 the type of abend issued by the SVC FLIH the registers are in the next RB or ABend SVCRB I thought in the case of a program check I.E. S0C1,4 etc it would be by that I mean the registers and PSW in the PRB that represented that unit of work This program that abended was initiated by synch SVC 12 but I wasn’t looking at the SVRB but the PRB Thanks > On Feb 4, 2024, at 10:14 AM, Seymour J Metz wrote: > > The processing for SYNCH is the same whether it is issued from a PRB or an > SVRB; the caller's PSW goes into the old RB and the caller's general > registers go into the new PRB. > > <http://.bitsavers.org/pdf/ibm/370/MVS_XA/LY28-1765-0_MVS_XA_Version_2_Release_2.0_System_Logic_Library_Supervisor_Control_Jun1987.pdf> > is newer. > > Sometimes they get better. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf of > Michael Stein > Sent: Sunday, February 4, 2024 4:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Registers in the RB > >> On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: >> It was my understanding probably erroneously that when a RB I guess I am >> talking about a PRB gets interrupted and that can happen in one of two >> instances >> >> 1)An SVC >> 2)A Program check e.g. S0C1,4, > > There are many interrupts possible: External, I/O, Program, SVC plus a few > others. Also including software caused like asynchronous exit routines. > > The bottom level of the system has to deal with these and one of it's > main concerns is where to save the state of whatever was running when > the interrupt happened. > > Since there are multiple CPUs and many many tasks & SRBs etc, it's > important that the state information (PSW & registers) are only saved > in areas others won't use at the same time otherwise they would get > overlay by another interrupt or processor leading to disaster. > > While the OS interrupt routines have processor related storage they can > only use this during the time they are disabled. If they are going to > return to the interrupted work then they can restore them and return, > otherwise they must move/save the state elsewhere before they enable. > > For an OS task the registers and PSW are saved in task related control > blocks, a combination of the TCB and RBs. > > The SVC interrupt handler save state depending on the type of SVC: > > type 1: (required to hold local lock, so can use areas address space related)) >registers -> TCBGRS (?) >PSW -> some address space related area (?) > > type 2,3,4: (doesn't require holding local lock so can't use address space > related area) >. SVC caller's PSW & interupt code in top RB on TCB RB chain >. gets SVRB, puts SVC issuer registers into this SVRB > and addes it to the top of the TCB RB chain > so: >. SVRB register contain the SVC issuer's registers >. SVRB PSW is the SVC routines PSW >. TCBGRS is the SVC routines registers > > Keep in mind that a type 2,3,4 SVC can issue another SVC (which will > if type 2,3,4 add another SVRB). Or it might issue the SYNCH SVC > resulting in an RB being added to the RB chain (holding the SVC issuing > SYNCH's PSW. Where the SVCs routine registers go I don't know. > Perhaps SYNCH with restore=yes is newer? > > Also IRBs for asynchronous exit routines can be added to the RB chain. > In this case the interrupted registers will be in the IRB register save > area and the interrupted PSW will be in what was the top RB before the > IRB was added. > > I don't know if IBM makes available current logic manuals but old ones > exist like: > > https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 > > It's not clear how much change has happened since then, but some of the > basic concepts likely haven't changed all that much. Look up how the > SVC interrupt handler works... > > Or an yet older manual for MVT, no SRBs just tasks, usually only one CPU, > but similar TCB/RB structures: > > https://ia903101.us.archive.org/20/items/b
Re: Registers in the RB
Where registers are stored depends on the type of interrupt, and there are five types, not just two. In the case of a program check*, what happens depends on the type, state and whether it is covered by a match [E]SPIE. In the case of a program check resulting in an S0Cx or S0Dx ABEND, the PSW is stored in the failing RB and the general registers are stored in the new ABEND SVRB. * ABEND S0C4 is not a program check. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Saturday, February 3, 2024 8:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Registers in the RB It was my understanding probably erroneously that when a RB I guess I am talking about a PRB gets interrupted and that can happen in one of two instances 1) An SVC 2) A Program check e.g. S0C1,4, Then if the interrupt is because of an SVC the program registers will be saved in the new SVRB if it's because of the program check then it will be saved in that RB Just was looking at my abended rb in SDWARBAD which took off via a synch macro and I deliberately abended it with a s0c1 the RBOPSW matched SDWAEC1 However the registers were in the next RB If anyone can clarify this issue I would be very grateful 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: Registers in the RB
The processing for SYNCH is the same whether it is issued from a PRB or an SVRB; the caller's PSW goes into the old RB and the caller's general registers go into the new PRB. <http://.bitsavers.org/pdf/ibm/370/MVS_XA/LY28-1765-0_MVS_XA_Version_2_Release_2.0_System_Logic_Library_Supervisor_Control_Jun1987.pdf> is newer. Sometimes they get better. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Michael Stein Sent: Sunday, February 4, 2024 4:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Registers in the RB On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: > It was my understanding probably erroneously that when a RB I guess I am > talking about a PRB gets interrupted and that can happen in one of two > instances > > 1)An SVC > 2)A Program check e.g. S0C1,4, There are many interrupts possible: External, I/O, Program, SVC plus a few others. Also including software caused like asynchronous exit routines. The bottom level of the system has to deal with these and one of it's main concerns is where to save the state of whatever was running when the interrupt happened. Since there are multiple CPUs and many many tasks & SRBs etc, it's important that the state information (PSW & registers) are only saved in areas others won't use at the same time otherwise they would get overlay by another interrupt or processor leading to disaster. While the OS interrupt routines have processor related storage they can only use this during the time they are disabled. If they are going to return to the interrupted work then they can restore them and return, otherwise they must move/save the state elsewhere before they enable. For an OS task the registers and PSW are saved in task related control blocks, a combination of the TCB and RBs. The SVC interrupt handler save state depending on the type of SVC: type 1: (required to hold local lock, so can use areas address space related)) registers -> TCBGRS (?) PSW -> some address space related area (?) type 2,3,4: (doesn't require holding local lock so can't use address space related area) . SVC caller's PSW & interupt code in top RB on TCB RB chain . gets SVRB, puts SVC issuer registers into this SVRB and addes it to the top of the TCB RB chain so: . SVRB register contain the SVC issuer's registers . SVRB PSW is the SVC routines PSW . TCBGRS is the SVC routines registers Keep in mind that a type 2,3,4 SVC can issue another SVC (which will if type 2,3,4 add another SVRB). Or it might issue the SYNCH SVC resulting in an RB being added to the RB chain (holding the SVC issuing SYNCH's PSW. Where the SVCs routine registers go I don't know. Perhaps SYNCH with restore=yes is newer? Also IRBs for asynchronous exit routines can be added to the RB chain. In this case the interrupted registers will be in the IRB register save area and the interrupted PSW will be in what was the top RB before the IRB was added. I don't know if IBM makes available current logic manuals but old ones exist like: https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 It's not clear how much change has happened since then, but some of the basic concepts likely haven't changed all that much. Look up how the SVC interrupt handler works... Or an yet older manual for MVT, no SRBs just tasks, usually only one CPU, but similar TCB/RB structures: https://ia903101.us.archive.org/20/items/bitsavers_ibm360osR1TSupervisorRel17ProgramLogicNov1968_55700209/Y28-6659-3_MVT_Supervisor_Rel_17_Program_Logic_Nov1968.pdf PS: Do the manuals get worse the newer they are? -- 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: Registers in the RB
On Sat, Feb 03, 2024 at 08:20:08PM -0500, Joseph Reichman wrote: > It was my understanding probably erroneously that when a RB I guess I am > talking about a PRB gets interrupted and that can happen in one of two > instances > > 1)An SVC > 2)A Program check e.g. S0C1,4, There are many interrupts possible: External, I/O, Program, SVC plus a few others. Also including software caused like asynchronous exit routines. The bottom level of the system has to deal with these and one of it's main concerns is where to save the state of whatever was running when the interrupt happened. Since there are multiple CPUs and many many tasks & SRBs etc, it's important that the state information (PSW & registers) are only saved in areas others won't use at the same time otherwise they would get overlay by another interrupt or processor leading to disaster. While the OS interrupt routines have processor related storage they can only use this during the time they are disabled. If they are going to return to the interrupted work then they can restore them and return, otherwise they must move/save the state elsewhere before they enable. For an OS task the registers and PSW are saved in task related control blocks, a combination of the TCB and RBs. The SVC interrupt handler save state depending on the type of SVC: type 1: (required to hold local lock, so can use areas address space related)) registers -> TCBGRS (?) PSW -> some address space related area (?) type 2,3,4: (doesn't require holding local lock so can't use address space related area) . SVC caller's PSW & interupt code in top RB on TCB RB chain . gets SVRB, puts SVC issuer registers into this SVRB and addes it to the top of the TCB RB chain so: . SVRB register contain the SVC issuer's registers . SVRB PSW is the SVC routines PSW . TCBGRS is the SVC routines registers Keep in mind that a type 2,3,4 SVC can issue another SVC (which will if type 2,3,4 add another SVRB). Or it might issue the SYNCH SVC resulting in an RB being added to the RB chain (holding the SVC issuing SYNCH's PSW. Where the SVCs routine registers go I don't know. Perhaps SYNCH with restore=yes is newer? Also IRBs for asynchronous exit routines can be added to the RB chain. In this case the interrupted registers will be in the IRB register save area and the interrupted PSW will be in what was the top RB before the IRB was added. I don't know if IBM makes available current logic manuals but old ones exist like: https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 It's not clear how much change has happened since then, but some of the basic concepts likely haven't changed all that much. Look up how the SVC interrupt handler works... Or an yet older manual for MVT, no SRBs just tasks, usually only one CPU, but similar TCB/RB structures: https://ia903101.us.archive.org/20/items/bitsavers_ibm360osR1TSupervisorRel17ProgramLogicNov1968_55700209/Y28-6659-3_MVT_Supervisor_Rel_17_Program_Logic_Nov1968.pdf PS: Do the manuals get worse the newer they are? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Registers in the RB
It was my understanding probably erroneously that when a RB I guess I am talking about a PRB gets interrupted and that can happen in one of two instances 1) An SVC 2) A Program check e.g. S0C1,4 It is true that the understanding is erroneous. There are many more cases where any RB can be interrupted, and it is not true that interrupt by SVC necessarily creates a new RB. I'm not going to answer beyond that since "asked and answered" would apply. That answer has been provided previously in the same general thread. But as a hint: SVC D is an SVC that creates an SVRB. 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
Registers in the RB
It was my understanding probably erroneously that when a RB I guess I am talking about a PRB gets interrupted and that can happen in one of two instances 1) An SVC 2) A Program check e.g. S0C1,4, Then if the interrupt is because of an SVC the program registers will be saved in the new SVRB if it's because of the program check then it will be saved in that RB Just was looking at my abended rb in SDWARBAD which took off via a synch macro and I deliberately abended it with a s0c1 the RBOPSW matched SDWAEC1 However the registers were in the next RB If anyone can clarify this issue I would be very grateful thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
