Re: AW: Re: Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
ICYDIE is Media Manager's Disabled Interrupt Exit for I/O interrupts, I would guess that ICYDIE called an exit owned by the caller of Media Manager, and that exit did the RELEASE for some unit of work that it had PAUSEd to wait for the I/O to complete. From the SSRV 11F trace entry, 1EE5C3D6 is the return address for the RELEASE. You may be able to look at that in the dump to see who it is. DB2 is one possibility. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Peter Hunkeler" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/13/2018 08:23 PM > Subject: AW: Re: Wtrln.: Are those SSRV trace entires relate to the > I/O interrupt? > Sent by: "IBM Mainframe Discussion List" > > >Yes, they are part of the I/O interrupt processing, and are not related > to the interrupted program (unless the I/O operation that caused > the interrupt is related to the interrupted program) . > > Thanks, Jim. > > Can you say something about when they occur and when not? Just > curious because I see them most of the time in this dump but only > occasionally in other dumps, it seems. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
>Yes, they are part of the I/O interrupt processing, and are not related to the interrupted program (unless the I/O operation that caused the interrupt is related to the interrupted program) . Thanks, Jim. Can you say something about when they occur and when not? Just curious because I see them most of the time in this dump but only occasionally in other dumps, it seems. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
Yes, they are part of the I/O interrupt processing, and are not related to the interrupted program (unless the I/O operation that caused the interrupt is related to the interrupted program) . Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Peter Hunkeler" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/13/2018 01:38 PM > Subject: Wtrln.: Are those SSRV trace entires relate to the I/O interrupt? > Sent by: "IBM Mainframe Discussion List" > > I'm chasing another problem where an LE program (COBOL) gets into > an endless, rather tight loop in CEEPLPKA after an S04E abend I'm > trying to understand the relation between I/O interrupt system trace > entries, and a pair of SSRV entries that very often follow the I/O entry. > > > Here is a sample sequence from the trace: > > 0003 031C 009FEA30 DSP_0872C4B6 26C62364 > 0003 031C 009FEA30 EXT TIMR _0872BFAE 1005 > 0001 031C 009FEA30 DSP_0872BFAE 26C62364 > 0001 031C 009FEA30 I/O 06B16 _0872C2C8 00104007 745786C0 > 0001 031C 009FEA30 SSRV 11F 9EE5C3D6 16701A80 8000 157A25F8 > 0001 031C 009FEA30 SSRV 150 02F5F020 7EB06940 > > The program is dispatched (DSP), interrupted at end of time slice > (EXT TIMR), dispatched again (DSP), then interrupted by an I/O which > completed (I/O). Very often, two system service calls (SSRV), first > for RELEASE (SSRV 115), second for DFSMS Media Manager ICYDIE (SSRV > 150) are seen. > > First I thought the SSRVs are related to the program, but I now have > my doubts. I'd rather think they are caused by I/O interrupt > handling. Especially, since I have seen such sequences in another > dumps, although much less often. > > Can anyone say something about the nature of those SSRV calls. > Am I safe to say they do not belong to the problem at hand? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
Agrrr.. Sorry for the misformatted mail. Trying again. I'm chasing another problem where an LE program (COBOL) gets into an endless, rather tight loop in CEEPLPKA after an S04E abend I'm trying to understand the relation between I/O interrupt system trace entries, and a pair of SSRV entries that very often follow the I/O entry. Here is a sample sequence from the trace: 0003 031C 009FEA30 DSP_0872C4B6 26C62364 0003 031C 009FEA30 EXT TIMR _0872BFAE 1005 0001 031C 009FEA30 DSP_0872BFAE 26C62364 0001 031C 009FEA30 I/O 06B16 _0872C2C8 00104007 745786C0 0001 031C 009FEA30 SSRV 11F 9EE5C3D6 16701A80 8000 157A25F8 0001 031C 009FEA30 SSRV 150 02F5F020 7EB06940 The program is dispatched (DSP), interrupted at end of time slice (EXT TIMR), dispatched again (DSP), then interrupted by an I/O which completed (I/O). Very often, two system service calls (SSRV), first for RELEASE (SSRV 115), second for DFSMS Media Manager ICYDIE (SSRV 150) are seen. First I thought the SSRVs are related to the program, but I now have my doubts. I'd rather think they are caused by I/O interrupt handling. Especially, since I have seen such sequences in another dumps, although much less often. Can anyone say something about the nature of those SSRV calls. Am I safe to say they do not belong to the problem at hand? — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
