(Maybe more than you wanted to hear about SAD)


1. 'SYSPLEX' means 'using XCF'. You may or not use CF structures. If so, it's 
parallel sysplex. If not, it's basic sysplex. There is a difference in how 
‘system down’ works, but it's still sysplex.



2. SAD is designed to dump a running (but probably very ill) system. The system 
does not need to be shut down first. If it's already down as in a wait state, 
SAD works fine, but 'down' is not a requirement or even a desirable path.



3. My opinion: configure SAD to work without any operator intervention. That 
is, once SAD has been IPLed, the dump should proceed automatically with 
predefined volumes and a default title something like this:



     AUTOIPL WAIT STATE CODE 00000A70 DUMP DATE/TIME  06/29/2016 03:26:30 
SYSNAME xx



4.  See example below for coding AMDSADMP.



5. In DIAGxx, include this line. It will produce automatic SAD in case of wait 
state with automatic reIPL from last sysres used. Depending on system use, this 
may all occur without operator awareness(!)



     AUTOIPL SADMP(uuuu,SMSYSC) MVS(LAST)  /* IPL SAD FROM VOLUME CONTAINING 
SYS1.PAGEDUMP.Vvolser */



6. In a parallel sysplex, all members will know that a system as died. There 
should be no ‘reply when system is down’ message. In a basic sysplex, you may 
have to reply ‘down’.



7. Once this (or some other) system is available, copy the SAD to tape or some 
other protected location so it does not get overwritten.



8. Run IPCS pointing to the SAD. If the dump is structurally incomplete, IPCS 
will complain. Otherwise assume it’s OK.



9. Sample AMDSADMP for operator-less SAD:



AMDSADMP VOLSER=volser,     VOLUME CONTAINING SAD IPL TEXT    *

      CONSOLE=SYSC,         USE HMC AS CONSOLE                *

      IPL=DSYSALLDA,        MAKE SURE WE GET THE DEVICE       *

      REUSEDS=ALWAYS,       ALWAYS OVERWRITE DATA SET         *

      MINASID=PHYSIN,       GET AT LEAST SWAPPED IN GUYS      *

      DUMP=(your options),                                    *

      OUTPUT=Duuuu          SADUMP TO DASD FORMATTED FOR SAD





.

.

J.O.Skip Robinson

Southern California Edison Company

Electric Dragon Team Paddler

SHARE MVS Program Co-Manager

323-715-0595 Mobile

626-302-7535 Office

robin...@sce.com





-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: Tuesday, August 30, 2016 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SAD testing in sysplex



Hello,



Is there a IPCS commands that can show me that SAD was written completely ?



On Tue, Aug 30, 2016 at 5:28 PM, Elardus Engelbrecht < 
elardus.engelbre...@sita.co.za<mailto:elardus.engelbre...@sita.co.za>> wrote:



> Nathan Astle wrote:

>

> >I am creating a SAD test for one of our sandbox system which is part

> >of

> sysplex shared with other production LPAR.

> >So as a SAD testing, I am bringing down the LPAR and leaving with

> >just

> few task up.

>

> Just a few tasks? This is not SAD.

>

> >My question is when I load the SAD IPL and once I confirm the SAD IPL

> with the VOLUMES used for SAD datasets.

>

> >Can I remove the sandbox LPAR from sysplex prior to confirming the

> >SAD

> datasets or after completing the SAD process I can remove the SANDBOX

> lpar from sysplex ?

>

> Mark Jacobs gave you a serious warning, but I have one question: Do

> you want that LPAR to stay inside or outside the Sysplex after IPL? In

> other words, when are you planning to vary it out of Sysplex?

>

> Another nasty thing to consider, is your LPAR using XCF?

>

> Oh, things like shared JES2/3 spool, shared HSM, RACF, etc. may make

> your attempt futile.

>

> But, if you take some precautions, your attempt to do a SAD may work.

>

> Good luck.

>

> Groete / Greetings

> Elardus Engelbrecht



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to