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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joseph Reichman <reichman...@gmail.com> 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 <reichman...@gmail.com> 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 <sme...@gmu.edu> 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://wwww.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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >> Michael Stein <m...@zlvfc.com> >> 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 ---------------------------------------------------------------------- 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
