Re: SVCDUMP processing question
On Wed, 26 Mar 2008 23:16:15 -0400, Jim Mulder [EMAIL PROTECTED] wrote: ... Are all SVCDUMPS synchronous? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A870/20.1.2?SHELF=EZ2ZO10IDT=20060620155240 ... Thanks. That helps. But now, to really understand this, all I have to do is find out how the SDUMPX is coded when VTAM dumps DB2 because something died in a VTAM exit in DB2. I have no idea if the criteria for a BRANCH entry are met (I suspect they could be.) and if so, if the BARSNCH entry was taken. I suspect not since the dump title said SYNCH. From a data collection standpoint, that's good. From a processing standpoint, that's bad. DB2 has a lot it could be doing completely unrelated to its VTAM exit that abended. Hopefully data capture does not take long, but I think DB2 address spaces can be big. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
On Wed, 26 Mar 2008 23:16:15 -0400, Jim Mulder [EMAIL PROTECTED] wrote: ... Every SVCDUMP sets the tasks in an address space nondispatchable while dumping that address space. But for an asynchronous dump, this is asynchronous with repsect to the unit of work which issued the SDUMP macro. ... I've reread this and tried applying it to DB2/VTAM dump I was considering. The exit code in question is code residing in the DB2 address space executed by VTAM. VTAM issues the SDUMPX. Synchronous vs. asynchronous brobably doesn't matter much in this case. The exit's unit of work may have stuff it could be cleaning up on the VTAM side of the interface, but VTAM work in general is going to keep plugging away. It sounds like the DB2 address space is going to be made non- dispatchable in either case. Hopefully data capture does not take too long. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SVCDUMP processing question
I need remedial training in MVS disagnostic techniques. :-( I seem to have combined the concepts of QUIESCE yes/no and SYNCH / ASYNCH. I sort of understand that QUIESCE=YES protects common storage during dump capture by limiting the dispatching of other address spaces (and probably have the details horribly wrong). What does SYNCSVCD do? Something similar with multiple taks within a single address space? I know QUIESCE=YES has caused us all kinds of performance problems in the past so we gone to NO everywhere we could find the option. However, we still are getting synchronous SVC dumps taken. I'm not sure we even have the option of setting that except for SLIP dumps. Is that a problem? Sorry if this is a bonehead question. If it rates an RTFM, please point me to the FM. Thank you. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Wednesday, March 26, 2008 3:23 PM To: IBM-MAIN@bama.ua.edu Subject: SVCDUMP processing question I need remedial training in MVS disagnostic techniques. :-( I seem to have combined the concepts of QUIESCE yes/no and SYNCH / ASYNCH. I sort of understand that QUIESCE=YES protects common storage during dump capture by limiting the dispatching of other address spaces (and probably have the details horribly wrong). What does SYNCSVCD do? Something similar with multiple taks within a single address space? I know QUIESCE=YES has caused us all kinds of performance problems in the past so we gone to NO everywhere we could find the option. However, we still are getting synchronous SVC dumps taken. I'm not sure we even have the option of setting that except for SLIP dumps. Is that a problem? SNIP At least two places to look: MVS Authorized Services Guide and MVS System Commands discusses the SYNC aspects. QUIESCE is a new one on me, and I can't find anything for such an option with a dump. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Wednesday, March 26, 2008 3:23 PM To: IBM-MAIN@bama.ua.edu Subject: SVCDUMP processing question I need remedial training in MVS disagnostic techniques. :-( I seem to have combined the concepts of QUIESCE yes/no and SYNCH / ASYNCH. I sort of understand that QUIESCE=YES protects common storage during dump capture by limiting the dispatching of other address spaces (and probably have the details horribly wrong). What does SYNCSVCD do? Something similar with multiple taks within a single address space? I know QUIESCE=YES has caused us all kinds of performance problems in the past so we gone to NO everywhere we could find the option. However, we still are getting synchronous SVC dumps taken. I'm not sure we even have the option of setting that except for SLIP dumps. Is that a problem? SNIP At least two places to look: MVS Authorized Services Guide and MVS System Commands discusses the SYNC aspects. QUIESCE is a new one on me, and I can't find anything for such an option with a dump. Under SDUMP[X]... ,QUIESCE=YES ,QUIESCE=NO Specifies that the system is to be set nondispatchable until the contents of the SQA and the CSA are dumped (YES), or that the system is to be left dispatchable (NO). If the SDATA parameter does not specify SQA or CSA, the QUIESCE=YES request is ignored. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Rutledge Sent: Wednesday, March 26, 2008 4:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SVCDUMP processing question Thompson, Steve wrote: snip QUIESCE is a new one on me, and I can't find anything for such an option with a dump. Under SDUMP[X]... ,QUIESCE=YES ,QUIESCE=NO Specifies that the system is to be set nondispatchable until the contents of the SQA and the CSA are dumped (YES), or that the system is to be left dispatchable (NO). If the SDATA parameter does not specify SQA or CSA, the QUIESCE=YES request is ignored. snip You just know that when the day is full of 'rupts, you are going to miss something. And I missed that one. I was even doing SEARCH with reader and looking at the INDEX area. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
On Wed, 26 Mar 2008 17:34:26 -0400, Thompson, Steve [EMAIL PROTECTED] wrote: ... At least two places to look: MVS Authorized Services Guide and MVS System Commands discusses the SYNC aspects. QUIESCE is a new one on me, and I can't find anything for such an option with a dump. ... Interesting. I can't find SYNC in the Auth Services Guide or under SDUMP/SDUMPX in the Auth Services Macros. I *can* find a very brief description of QUIESCE under SDUMP: Specifies that the system is to be set nondispatchable until the contents of the SQA and the CSA are dumped (YES) I wish they had said something other than the system. I guess that means NOTHING is despatched except the dump processing. I can find SYNCSVCD under SLIP in an old Commands manual (1.4 I think) but not in our 1.8 manual. Odd. SVCD is mentioned so I'm pretty sure I didn't get the wrong manual. Maybe I should extend the remedial training to include manual reading. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
On Wed, 26 Mar 2008 18:42:02 -0400, Bob Rutledge [EMAIL PROTECTED] wrote: ... I can find SYNCSVCD under SLIP in an old Commands manual (1.4 I think) but not in our 1.8 manual. Odd. ... No comment. However... http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA2G171/4.52.5.7? SHELF=EZ2ZO10IDT=20070123043204CASE= ... Ok. I'm blind. Or maybe I mistyped my search arg. I now see it in multiple syntax diagrams. And in the z/OS Diagnosis Guide it says the SLIP ACTION can specify SVCD or SYNCSVCD. That's nice. It agrees with the Commands manual. But I'm still a bit short on descriptions and explanations. Just from the concept of synchronous I assume something is suspended in SYNCSVCD processing. And I assume that something is not as extensive as with QUIESCE=YES. My gut feeling is all processing in the dumped address space is suspended (which could be good for diagnosis but bad for processing) but that's a guess. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
Patrick O'Keefe wrote: On Wed, 26 Mar 2008 18:42:02 -0400, Bob Rutledge [EMAIL PROTECTED] wrote: ... I can find SYNCSVCD under SLIP in an old Commands manual (1.4 I think) but not in our 1.8 manual. Odd. ... No comment. However... http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA2G171/4.52.5.7? SHELF=EZ2ZO10IDT=20070123043204CASE= ... Ok. I'm blind. Or maybe I mistyped my search arg. I now see it in multiple syntax diagrams. And in the z/OS Diagnosis Guide it says the SLIP ACTION can specify SVCD or SYNCSVCD. That's nice. It agrees with the Commands manual. But I'm still a bit short on descriptions and explanations. Just from the concept of synchronous I assume something is suspended in SYNCSVCD processing. And I assume that something is not as extensive as with QUIESCE=YES. My gut feeling is all processing in the dumped address space is suspended (which could be good for diagnosis but bad for processing) but that's a guess. Under SLIP ACTION=SYNCSVCD, it says: SLIP will stop the unit of work before starting the dump to ensure that the restart occurs after the dump has completed. And from this side of the Blue Divide, that's as good as it gets. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
Bob Rutledge wrote: Patrick O'Keefe wrote: ... Just from the concept of synchronous I assume something is suspended in SYNCSVCD processing. And I assume that something is not as extensive as with QUIESCE=YES. My gut feeling is all processing in the dumped address space is suspended (which could be good for diagnosis but bad for processing) but that's a guess. Under SLIP ACTION=SYNCSVCD, it says: SLIP will stop the unit of work before starting the dump to ensure that the restart occurs after the dump has completed. And from this side of the Blue Divide, that's as good as it gets. I should have added that, since SYNCSVCD is used (only) with PER traps, it can be more than good for diagnosis. You really want the work that altered that storage or fetched that unexpected instruction to sit still while it's having its picture taken. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
On Wed, 26 Mar 2008 19:48:32 -0400, Bob Rutledge [EMAIL PROTECTED] wrote: ... Under SLIP ACTION=SYNCSVCD, it says: SLIP will stop the unit of work before starting the dump ... I should have added that, since SYNCSVCD is used (only) with PER traps, ... Aha! That explains why I can't find anything comparable to ACTION other than on SLIP. ...it can be more than good for diagnosis. You really want the work that altered that storage or fetched that unexpected instruction to sit still while it's having its picture taken. ... Well, I guess it depends on what unit of work means. If it means the TCB or RB, I agree. If it means the whole address space, then I'm not so sure. But I suspect it *does* mean the TCB or RB. I had not been thinking of it like that. Today I saw an SVCDUMP that had SYNC DUMP in its title and wondered what that implied. It was taken during an ECSA shortage event where many address spaces locked up. I was afraid the dumps were adding to the problem. (Maybe they were. Are all SVCDUMPS synchronous?) It's probably more likely we still have QUIESCE=YES somewhere. BTW, I *DID* need remedial manual reading. I didn't know that one BookManager found a reference in a section you then have to switch to a browser FIND function to find additional references in that section. You don't (or at least *I* don't) get multiple BookManager search results for multiple hits in the same section. :-( Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/26/2008 06:14:38 PM: Interesting. I can't find SYNC in the Auth Services Guide or under SDUMP/SDUMPX in the Auth Services Macros. I *can* find a very brief description of QUIESCE under SDUMP: Specifies that the system is to be set nondispatchable until the contents of the SQA and the CSA are dumped (YES) I wish they had said something other than the system. I guess that means NOTHING is despatched except the dump processing. QUIESCE=YES sets all address spaces nondispatchable except those which have either ASCBXMPT or ASCBPXMT turned on in the ASCB (IHAASCB). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVCDUMP processing question
Well, I guess it depends on what unit of work means. If it means the TCB or RB, I agree. If it means the whole address space, then I'm not so sure. But I suspect it *does* mean the TCB or RB. I had not been thinking of it like that. In MVS, a unit of work is a TCB or an SRB/SSRB. But SLIP A=SYNCSVCD works only with enabled unlocked TCBs. Every SVCDUMP sets the tasks in an address space nondispatchable while dumping that address space. But for an asynchronous dump, this is asynchronous with repsect to the unit of work which issued the SDUMP macro. Are all SVCDUMPS synchronous? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A870/20.1.2?SHELF=EZ2ZO10IDT=20060620155240 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
