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
