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
