We also define SYS1.SADMP DSNTYPE=LARGE w/o benefit of SMS. I don't think it matters what you name the data set. We just use the 'well known' name (I love that open systems wriggle out of the 'standard' trap). When you IPL SAD, it goes to the DSN pointed to by SYS1.PAGEDUMP.Vxxxxxx on the IPL volume. Formatting the SAD volume places pointers to additional volumes, if any.
As to whether a null reply in the reported case would have reverted SAD to the original values, I think we're all looking to Barbara to answer her own question. ;-) . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Mark Zelden <[email protected]> To: [email protected] Date: 02/15/2012 06:28 AM Subject: Re: sadump (and autoipl) Sent by: IBM Mainframe Discussion List <[email protected]> On Wed, 15 Feb 2012 02:43:08 -0600, Barbara Nitz <[email protected]> wrote: >My sadump program is coded with DDSPROMPT=NO (to enable sadump autoipl) and a dump data set name that is NOT SYS1.SADMP (since something needed to get done in SMS for dsntype=large, and sys1 is not sms-managed - don't ask me about particulars). > >When we migrated to 1.12, we were on old DASD hardware, and the sadmp data set got reallocated using the old volser. I noticed that the volser was wrong in the amdsaosg job, and *that* got redone to use the new addresses on the new controller (the old one is gone). > >This morning I needed to take an sadump for the RSM/ASM/Supervisor problems that we have. I failed spectacularly: > >- sadump gave me AMD092I with a reason code of 8 indicating a device number mismatch. >I went and reallocated the sadump output data set on the same volume(s), but with the new device numbers (from a different system in the plex) > >- now sadump bitterly complained via amd001A and wanted the device address. I specified that. > >- Unfortunately, due to ddsprompt=no, sadump now *expects* the data set name to be sys1.sadmp. Of course, it couldn't find it on that volume. > >Am I correct in assuming that simply giving a null reply to amd001a would have taken the original values as described in the amdsosg job and would have essentially redriven sadump from the beginning? (Since I have reallocated all sadump output datasets, I cannot really test anymore). > >Rattled as I was, I ended up reIPLing the lpar without the sadump. :-( Let's wait for recurrance of the RSM problem. > >Regards, Barbara I can't answer your question, but I can tell you that you can use DSNTYPE=LARGE to allocate the output disk dump data sets without SMS control. I assume you are using hlq.SBLSCLI0(AMDSADDD) REXX exec to allocate them. The last keyword can be "LARGE". In the largest sysplex I support we use 4 3390-27s. Of course it is a good idea to test SADUMP after you make any changes. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
