Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

Ah yes, I remember seeing that advice during our latest GDPS upgrade. Unless 
(again) I'm missing something, that statement in its short form is misleading. 
In practice, we mirror (XRC, not PPRC) from one data center to another. GDPS 
runs in the remote data center to 'pull' data from production. The GDPS 'K 
system' runs there but does not perform any IPLs except to bring up DR systems 
for the first time. That's not what AUTOIPL impacts anyway until after DR IPL, 
by which time GDPS is totally out of the picture. 

I'm dimly aware that GDPS can be set up differently for other purposes. In our 
case, I cannot imagine how GDPS would even know about AUTOIPL, much less be 
inconvenienced by it.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Sunday, May 14, 2017 9:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

Hello Skip,

GDPS-PPRC - doesn't like any IPL activity that is not performed via the GDPS 
panels.

extract from:-

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieag300/wsat.htm

Note:
AutoIPL is not appropriate in a GDPS® environment.


Regards
Bruce


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

Re: AUTOIPL SADUMP LOADPARM flag value

[Bruce Hewson]

Hello Skip,

GDPS-PPRC - doesn't like any IPL activity that is not performed via the GDPS 
panels.

extract from:-

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieag300/wsat.htm

Note:
AutoIPL is not appropriate in a GDPS® environment.


Regards
Bruce

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

OK, I'm intrigued. We use GDPS (strictly) for DR failover from primary to 
alternate data center. Nothing on the GDPS front is automatic. It would require 
a Management decree to actually fail over. I see AUTOIPL as a means to restart 
a single system in the same location quickly with minimal intervention. What am 
I missing?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Saturday, May 13, 2017 5:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

Hi Skip,

why not REIPL ?

one acronym  ==  GDPS   :-)

Regards
Bruce Hewson


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

Re: AUTOIPL SADUMP LOADPARM flag value

[Bruce Hewson]

Hi Skip,

why not REIPL ?

one acronym  ==  GDPS   :-)

Regards
Bruce Hewson

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Tom Conley]

On 5/12/2017 5:18 PM, Jesse 1 Robinson wrote:

It's Friday, so I can (re)tell my war story. Shortly after z/OS R13 hit our 
first prod system, I noticed one morning that the system had been IPLed around 
05:00. Everyone denied having done it. Then I discovered a fresh SAD taken 
around the same time. Sent if off to IBM. Next day or two, the same thing 
happened. The system was wait-stating after running clean out of storage 
frames! It made no sense. I posted the problem here.

Jim Mulder saw the thread and rang me up with a few questions. The failing 
system, unlike the sandbox, was being mirrored to the DR data center. All of 
it. Every single volume. Jim suspected and then confirmed that because of a 
change in R13, a failing page-in caused an I/O redrive, which lost track of the 
failing page request, which never got put back on the queue. With XRC active, 
some percentage of page-ins got tangled up with SDM I/O. More lost frames. 
Eventually MVS ran completely out of frames, and the system wait-stated. Auto 
SAD. Auto IPL. It was Development, so at 05:00, there were no user calls. Ops 
never noticed.

Jim fixed the problem immediately. I believe in auto IPL.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com



Just don't forget to set MVS(LAST).  The res volume you save may be your 
own.


Regards,
Tom Conley

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

It's Friday, so I can (re)tell my war story. Shortly after z/OS R13 hit our 
first prod system, I noticed one morning that the system had been IPLed around 
05:00. Everyone denied having done it. Then I discovered a fresh SAD taken 
around the same time. Sent if off to IBM. Next day or two, the same thing 
happened. The system was wait-stating after running clean out of storage 
frames! It made no sense. I posted the problem here. 

Jim Mulder saw the thread and rang me up with a few questions. The failing 
system, unlike the sandbox, was being mirrored to the DR data center. All of 
it. Every single volume. Jim suspected and then confirmed that because of a 
change in R13, a failing page-in caused an I/O redrive, which lost track of the 
failing page request, which never got put back on the queue. With XRC active, 
some percentage of page-ins got tangled up with SDM I/O. More lost frames. 
Eventually MVS ran completely out of frames, and the system wait-stated. Auto 
SAD. Auto IPL. It was Development, so at 05:00, there were no user calls. Ops 
never noticed. 

Jim fixed the problem immediately. I believe in auto IPL. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Friday, May 12, 2017 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

On Fri, 12 May 2017 16:18:14 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
wrote:

>I'm curious as to why you do not want automatic reIPL after SADMP. Your   
>system is in a non-restartable wait state, after all. I view that as the  
>ultimate performance degradation. ;-) You have an SAD. If want to look at 
>it or at OPERLOG, you need at least one system in the sysplex up and  
>running. Why not this one?
>  
>IBM has recommended auto IPL for many years based on decades of problem   
>analysis.  Nothing will ever get better on a dead system. ReIPL might fail,   
>but it's worth a try. You can also speed up SAD such that no operator 
>intervention is required. It's possible for a system to die, take an SAD, 
>and reIPL before the operator gets back from coffee break. I've seen it   
>happen.   
>  

If IBM-MAIN had a like button or thumbs up, you would have it.   Haven't 
actually had
a crash in a long time, but the last time my client had one that was basically 
the scenario.
By the time I was getting instant messages and automated alerts / pages were 
going out to everyone, the system was already back up and had 100% application 
availability.  It was something like a 10 minute outage total.  The client 
wasn't happy, but it sure beats the heck out of "the old days" of initiating a 
stand alone dump manually and re-ipling after it completed.  That's if an 
operator or even a sysprog could find the doc or knew how to do an SADUMP and 
do it correctly! 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html


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

Re: AUTOIPL SADUMP LOADPARM flag value

[Mark Zelden]

On Fri, 12 May 2017 16:18:14 +, Jesse 1 Robinson  
wrote:

>I'm curious as to why you do not want automatic reIPL after SADMP. Your   
>system is in a non-restartable wait state, after all. I view that as the  
>ultimate performance degradation. ;-) You have an SAD. If want to look at 
>it or at OPERLOG, you need at least one system in the sysplex up and  
>running. Why not this one?
>  
>IBM has recommended auto IPL for many years based on decades of problem   
>analysis.  Nothing will ever get better on a dead system. ReIPL might fail,   
>but it's worth a try. You can also speed up SAD such that no operator 
>intervention is required. It's possible for a system to die, take an SAD, 
>and reIPL before the operator gets back from coffee break. I've seen it   
>happen.   
>  

If IBM-MAIN had a like button or thumbs up, you would have it.   Haven't 
actually had
a crash in a long time, but the last time my client had one that was basically 
the scenario.
By the time I was getting instant messages and automated alerts / pages were 
going
out to everyone, the system was already back up and had 100% application 
availability.  It was something like a 10 minute outage total.  The client 
wasn't happy,
but it sure beats the heck out of "the old days" of initiating a stand alone 
dump 
manually and re-ipling after it completed.  That's if an operator or even a 
sysprog
could find the doc or knew how to do an SADUMP and do it correctly! 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

I'm curious as to why you do not want automatic reIPL after SADMP. Your system 
is in a non-restartable wait state, after all. I view that as the ultimate 
performance degradation. ;-) You have an SAD. If want to look at it or at 
OPERLOG, you need at least one system in the sysplex up and running. Why not 
this one?

IBM has recommended auto IPL for many years based on decades of problem 
analysis. Nothing will ever get better on a dead system. ReIPL might fail, but 
it's worth a try. You can also speed up SAD such that no operator intervention 
is required. It's possible for a system to die, take an SAD, and reIPL before 
the operator gets back from coffee break. I've seen it happen. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Thursday, May 11, 2017 11:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

Hello Jim,

thank you.

summary:-

SADUMP treats last LOADPARM character as if it is a hexadecimal nibble.

1...  8   - reserved for IBM - do not use
.1..  4   - SADUMP will attempt re-ipl using stored DIAG member MVS() 
parameter values
..1.  2   - unassigned - do not use
...1  1   - unassigned - do not use

We will be coding "0" to ensure no auto re-ipl is attempted by SADUMP.
Our exercise is to speed up SADUMP capture. we will use loadparm  SNSYSC0.

For our general usage we will code a SYMBOL for the SADUMP ucb address, and use 
AUTOMATION script to identify the UCB address of the second volume in the 
sysres set based on our volume naming standards, use SYMUPDTE process to 
dynamically update the symbol value, then use SET DIAG command to update the 
SADUMP UCB address. This to be performed after every IPL.

Activities, such as TDMF relocation of SYSRES volumes will be managed by 
re-driving the AUTOMATION script.

Regards
Bruce Hewson

On Wed, 10 May 2017 14:35:09 -0400, Jim Mulder <d10j...@us.ibm.com> wrote:

>  Currently, "2" will be treated the same as "0" or " " (blank).There 
>is no reason
>why you should have specified "2", and a good reason not to - there is  
>a possibility that in some future release, we might assign some meaning 
>to "2".
>
>  Standalone dump treats this character as a hexadecimal digit 
>representing four option bits.  The first bit is an undocumented option 
>intended to be used only under my direction.  The second bit is what is 
>documented for "4".  The third (corresponding to "2") and fourth bits 
>are currently unused.
>
>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>Poughkeepsie NY


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

Re: AUTOIPL SADUMP LOADPARM flag value

[Bruce Hewson]

Hello Jim,

thank you.

summary:-

SADUMP treats last LOADPARM character as if it is a hexadecimal nibble.

1...  8   - reserved for IBM - do not use
.1..  4   - SADUMP will attempt re-ipl using stored DIAG member MVS() 
parameter values
..1.  2   - unassigned - do not use
...1  1   - unassigned - do not use

We will be coding "0" to ensure no auto re-ipl is attempted by SADUMP.
Our exercise is to speed up SADUMP capture. we will use loadparm  SNSYSC0.

For our general usage we will code a SYMBOL for the SADUMP ucb address, and use 
AUTOMATION script to identify the UCB address of the second volume in the 
sysres set based on our volume naming standards, use SYMUPDTE process to 
dynamically update the symbol value, then use SET DIAG command to update the 
SADUMP UCB address. This to be performed after every IPL.

Activities, such as TDMF relocation of SYSRES volumes will be managed by 
re-driving the AUTOMATION script.

Regards
Bruce Hewson

On Wed, 10 May 2017 14:35:09 -0400, Jim Mulder  wrote:

>  Currently, "2" will be treated the same as "0" or " " (blank).There 
>is no reason
>why you should have specified "2", and a good reason not to - there is  a
>possibility that in some future release, we might assign some meaning to 
>"2".
>
>  Standalone dump treats this character as a hexadecimal digit 
>representing four option bits.  The first bit is an undocumented option 
>intended to be used only under my direction.  The second bit is what
>is documented for "4".  The third (corresponding to "2") and fourth bits 
>are 
>currently unused. 
>
>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>Poughkeepsie NY

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

Re: AUTOIPL SADUMP LOADPARM flag value

[Jim Mulder]

  Currently, "2" will be treated the same as "0" or " " (blank).There 
is no reason
why you should have specified "2", and a good reason not to - there is  a
possibility that in some future release, we might assign some meaning to 
"2".

  Standalone dump treats this character as a hexadecimal digit 
representing four option bits.  The first bit is an undocumented option 
intended to be used only under my direction.  The second bit is what
is documented for "4".  The third (corresponding to "2") and fourth bits 
are 
currently unused. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> Back in 2010 I had a system coded with SADUMP(,SNSYSC2) and 
MVS(LAST).
> 
> When a 
> 
> V, XCF,sysn,OFFLINE,SADUMP,REIPL
> 
> command was issued, the system did take a Stand Alone Dump, and did IPL.
> 
> That is my recollection.
> 
> Today I have no idea why I coded the "2" in the "SSNSYSC2" 
> loadparm, and was hoping someone could explain why it worked.
> 
> The SADUMP manual says that only "0", "4" and " " (blank) are valid 
values.



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

AUTOIPL SADUMP LOADPARM flag value

[Bruce Hewson]

hello,

Back in 2010 I had a system coded with SADUMP(,SNSYSC2) and MVS(LAST).

When a 

V, XCF,sysn,OFFLINE,SADUMP,REIPL

command was issued, the system did take a Stand Alone Dump, and did IPL.

That is my recollection.

Today I have no idea why I coded the "2" in the "SSNSYSC2"  loadparm, and was 
hoping someone could explain why it worked.

The SADUMP manual says that only "0", "4" and " " (blank) are valid values.

Hope someone can help.

Thank you
Bruce Hewson

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