> 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).
The book says:
****
DDSPROMPT={YES|NO}
DDSPROMPT=YES allows the stand-alone dump program to prompt the
operator for an output dump data set when dumping to a DASD device.
When DDSPROMPT=YES is specified, after replying to message AMD001A
with a DASD device number, message AMD002A is also issued to
prompt the operator for a dump data set name.
DDSPROMPT=NO indicates that the stand-alone dump program should
not prompt for a dump data set name when dumping to a DASD device.
When DDSPROMPT=NO is specified, after replying to message AMD001A
with a DASD device number, the stand-alone dump program uses data
set SYS1.SADMP. DDSPROMPT=NO is the default.
Note that regardless of the DDSPROMPT= keyword value, you can
always use a default device and dump data set name by specifying
the OUTPUT=(Dunit,ddsname) keyword. The stand-alone dump program
uses the default values specified on the OUTPUT= keyword when the
operator uses the EXTERNAL INTERRUPT key to bypass console
communication, or if the operator provides a null response to
message AMD001A.
***
So, yes, a null reply to AMD100A would use the the OUTPUT=
specification from your AMDSADMP macro.
But you shouldn't need DDSPROMPT=NO to allow for
AutoIPL of SADMP. If the first character of your SADMP IPL
(or AutoIPL) load parameter is S, and the second character
is N, O, or M (N or O would be typical for AutoIPL),
SADMP will use the OUTPUT= specification from your
AMDSADMP macro.
The only reason that these is a DDSPROMPT keyword is
that the original dump to DASD support in SP4.3.0 was
very low budget, and did not allow a data set name to
be specified. The data set name had to be SYS1.SADMP.
When support was added in a later release for more
flexible data set naming, we had to maintain (for
compatibility's sake) a mode of operation where a
name of SYS1.SADMP was assumed. Hence, the DDSPROMPT
keyword, and its compatible default of NO. But I don't
recommend using that.
Also, when you get in a pickle with SADMP, you can
usually do a PSW Restart of the SADMP IPL CPU (usually,
CPU 0 unless IPLed via AutoIPL) to get back to the
beginning of SADMPm processing. PSW Restart is a
bit inconvenient on the HMC (I think you may need to get
into single object operation (or whatever that is called),
and then bring up a CPU list for your LPAR, then select
the one CPU that is in the operating state, and then
select PSW Restart. Or something like that. The
HMC and I are not the best of friends. It is easy to
do a PSW Restart of SADMP under VM. Why it seems so
clumsy on the HMC, I don't know. I suppose it is
because I don't comprehend the beauty of its
object-oriented design. Or so I have been told.
If all else fails, you can Re-IPL SADMP.
It used to be that you would not get any paged out
storage dumped if you did that, but I fixed that in
z/OS 1.9. All you lose when you Re-IPL is 4MB of the
z/OS read-only nucleus (in the dump, you will see 4MB of
SADMP code and storage at those addresses). But unless
the problem you are trying to diagnose is one of the rare
cases where some read-only nucleus storage was overlaid
using a real address, a channel program, or a
coupling operation, then you can just take an SDUMP
with the DUMP command after you re-IPL z/OS, specifying
SDATA=ALLNUC, and look at the read only nucleus storage
in that dump (as long as your nucleus was not relinked
before the Re-IPL of z/OS).
I recommend reading section 4.4
"Running the stand-alone dump program" in the z/OS 1.13
level of MVS Diagnosis: Tools and Service Aids.
I went through SADMP chapter of this manual for
z/OS 1.13 and tried to fix most of the things that had
been wrong, or obsolete for many releases. Hopefully
is is a little better now. But I don't consider manual
writing to be one of my better-developed skills.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
