Barbara,
Why not non-sms DSNTYPE? We do.
Data Set Name . . . . : SYS1.SADMP1
General Data Current Allocation
Management class . . : **None** Allocated cylinders : 60,014
Storage class . . . : **None** Allocated extents . : 1
Volume serial . . . : SADMP0
Device type . . . . : 3390
Data class . . . . . : **None**
Organization . . . : PS Current Utilization
Record format . . . : FBS Used cylinders . . : 1
Record length . . . : 4160 Used extents . . . : 1
Block size . . . . : 24960
1st extent cylinders: 60014
Secondary cylinders : 0 Dates
Data set name type : LARGE Creation date . . . : 2009/10/28
SMS Compressible. . : NO Referenced date . . : 2009/10/28
Expiration date . . : ***None***
_________________________________________________________________
Dave Jousma
Assistant Vice President, Mainframe Services
[email protected]
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
Barbara Nitz
Sent: Wednesday, February 15, 2012 3:43 AM
To: [email protected]
Subject: sadump (and autoipl)
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
