Re: sadump (and autoipl)
> Talking of AUTOIPL and sadump, when I tested this, the only way to > see that sadump had finished was when the NIP messages came up on > the real console, indicating sadump was done. That's fine and dandy > when I am expecting an sadump, but what about when the sadump is > taken due to a real problem (and not me just v xcf,sadump,reipl)? > How can I see (without interrupting sadump) how far it had come? > Just open the operating system messages window on the HMC? Since you have SMSYSC in the loadparm, SADMP should be happily writing its usual progress messages to the operating system messages window on the HMC. > >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. > Now he tells me! I had been standing there and thinking to just > reload sadump. The last time I did this I ended up with a nice > system trace of what sadump had done :-(. > What's the point of no return? In other words, when shouldn't I > reload sadump in order to get a dump with meaningful content for the > problem I am sadumping for? (I think I understand the 4K pages in nucleus.) I don't think there is a point of no return. SADMP only uses 4MB of storage for itself, and as long as there is some useable DAT structure in place when you IPL SADMP, it will use the 4MB of real storage that was backing the 4MB of virtual storage starting at virtual address 0100. So no matter how many times you reload, SADMP will be using the same 4MB of real storage, and the rest of real storage is still from the z/OS system that you were trying to dump. When SADMP issues AMD087I DUMP OF A PREVIOUS STAND-ALONE DUMP PROGRAM NOW COMPLETE AMD088D REPLY 'T' TO TERMINATE, OR 'U' TO CONTINUE DUMPING. REPLY= it means that SADMP has finished dumping all of the real storage that was in use by SADMP and the z/OS system that was being dumped. If you reply U, it will continue on to dump the requested paged out storage, and then any real storage that was not in use (i.e., on an available frame queue). It used to be that you had to know how to do some incantations in IPCS to make sense of one of these dumps, but I changed SADMP in z/OS 1.10 to put a little but of extra information in the dump header record that z/OS 1.10 IPCS uses to avoid the need for the incantations. These also used to be some potential problems when SADMP had to use the store status data to determine whether it the thing it was dumping had been running in ESA/390 mode, or z/Architecture mode. In z/OS 1.12, I changed z/OS IPL and SADMP IPL processing to immediately switch into z/Architecture mode, so that SADMP and IPCS can safely assume that the thing being dumped was z/Architecture. 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
Re: sadump (and autoipl)
> Vacation? Not likely. I just don't know all the answers off the top > of my head, Impossible. :-) You're destroying the image I have of you! > Prior to DSNTYPE=LARGE in z/OS 1.7, the only way to use an >extent size larger than 64k tracks was to use an extended >format data set, and extended format data sets must be on >SMS-managed volumes. I believe that our setup dates to that time before dsntype=large. That explains the SMS-managed HLQ. And since it is not exactly easy to test, if something works, don't change it. Testing time has to be fought for. I didn't mean for you to go read the book. Once I had the time (and no pressure to get finished anymore), that's what I found. Hence my question. My original question was also meant as heads-up for everyone else not to forget sadump in all its glory when changing DASD. Now I have to get the 1.13 book to see the revised text. > 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. Well, I did specify SMSYSC as loadparm, both for this attempt and in the autoipl setting. I have to say that I always feel stupid when I look up this stuff, because I cannot really get a clear answer what is what and what I should specify. I used the 1.12 books and hope that your 1.13 revision makes it clearer. I'll let you know. :-) After all, you must be tired of me always asking about this stuff. I took ddsprompt=YES to mean that prompts would show up on the HMC, regardless of the loadparm. And given that I have to fight to test sadump even in the sysprog sandplex, I have to get it right first time. :-( Talking of AUTOIPL and sadump, when I tested this, the only way to see that sadump had finished was when the NIP messages came up on the real console, indicating sadump was done. That's fine and dandy when I am expecting an sadump, but what about when the sadump is taken due to a real problem (and not me just v xcf,sadump,reipl)? How can I see (without interrupting sadump) how far it had come? Just open the operating system messages window on the HMC? > 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. Especially on a z196 HMC, where the click-yes click-no requires concentrated reading to do the correct clicking, interspersed with typing in passwords for just about anything. I don't even know how I get to single object operations on the z196 HMC. >The HMC and I are not the best of friends. ... I suppose it is >because I don't comprehend the beauty of its >object-oriented design. Or so I have been told. Same here. First thing we did was get it back to the old view - almost none of us was able to find anything anymore, and certainly not in a pinch when the manager wants things done yesterday. > It is easy to do a PSW Restart of SADMP under VM. No slur on you, but I have gotten the impression that IBM development thinks that the rest of the world works under VM, too, and hence cannot comprehend what goes on with a 'real' console in 'real' lpar mode. That is often worlds apart and makes some development responses seem extremely arrogant to a customer - they have no clue how the world works, other than when running under VM, and just cannot comprehend why there is a problem. > 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. Now he tells me! I had been standing there and thinking to just reload sadump. The last time I did this I ended up with a nice system trace of what sadump had done :-(. What's the point of no return? In other words, when shouldn't I reload sadump in order to get a dump with meaningful content for the problem I am sadumping for? (I think I understand the 4K pages in nucleus.) >But I don't consider manual >writing to be one of my better-developed skills. Don't know why. You manage splendidly when you explain things, in my opinion. Skip, I had a good laugh at the joke! Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 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).
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 Di
Re: sadump (and autoipl)
As regards the HLQ part, we have successfully used a non-SYS1 SMS managed 4xm27 dataset for the non-prompt AUTOIPL Sadump: AMDSADMP IPL=D3390,VOLSER=SD, OUTPUT=(DBD36,PXSYS.OPER.SADMP), DDSPROMPT=NO, MINASID=ALL, REUSEDS=ALWAYS, CONSOLE=((SYSC),(0C0,3278),(0E0,3278)) .. and for the dataset ... EX 'SYS1.SBLSCLI0(AMDSADDD)' 'REALLOC + (SD00DA,SD00DB,SD00DC,SD00DD)(PXSYS.OPER.SADMP) + (3390,SCXSYSGS) 32382 YES LARGE' (the set-up is a common target for multiple sysplexes, and we do have 2 Sadump flavours - i.e. there is also a traditional one with prompt). I can provide the 'full' job including the pagedump allocations if anyone is really interested. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Fax:(31)115-67-1762 Dow Benelux B.V. Regardless of that, on our test systems, we always use a HLQ other than SYS1, because it is convenient for us to have the SADMP data sets cataloged in a shared user catalog. There isn't any reason I am aware of to need to use SYS1 as the HLQ. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: sadump (and autoipl)
> I love it when you guys do that to me! :-) Especially as I was too > fast to remedy the situation by reallocating everything before I had > figured out what I should have answered those prompts with! Jim > Mulder must be on vacation - I had hoped he could confirm this for me. Vacation? Not likely. I just don't know all the answers off the top of my head, and was tied up with other problems. I will get to it. > As far as the sys1.sadmp vs. .sadmp goes - it might be a remnant > of when we first took sadumps back to DASD. Since then we didn't go > to new DASD hardware, so it is kind of understandable that I wasn't > aware of this, especially as I wasn't involved in the DASD > migration. I had caught the sys1.pagedump thing and the wrong unit > in the amdsaosg generation, but I missed the reallocation of the > output dataset. The general take here is anyway, that sadumps are > only there to indulge me. > > Why we use the SMS-managed HLQ, I have no clue. I had been told way > back when that that was the only way to go multivolume or whatever. > I am reluctant to change this now, since it had worked so far (other > than this last attempt). Prior to DSNTYPE=LARGE in z/OS 1.7, the only way to use an extent size larger than 64k tracks was to use an extended format data set, and extended format data sets must be on SMS-managed volumes. Regardless of that, on our test systems, we always use a HLQ other than SYS1, because it is convenient for us to have the SADMP data sets cataloged in a shared user catalog. There isn't any reason I am aware of to need to use SYS1 as the HLQ. 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
Re: sadump (and autoipl)
I trade blonde jokes with a blonde friend. A recent gem from her (nothing personal!): A gorgeous young redhead goes into the doctor's office and said that her body hurt wherever she touched it. 'Impossible!' says the doctor.. 'Show me.' The redhead took her finger, pushed on her left shoulder and screamed, then she pushed her elbow and screamed even more. She pushed her knee and screamed; likewise she pushed her ankle and screamed. Everywhere she touched made her scream. The doctor said, 'You're not really a redhead, are you? 'Well, no' she said, 'I'm actually a blonde.' 'I thought so,' the doctor said, 'Your finger is broken.' There is an IBM-MAIN thread moral here: if what you're doing hurts, stop doing it. Doctor's orders. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Barbara Nitz To: IBM-MAIN@bama.ua.edu Date: 02/15/2012 09:07 PM Subject:Re: sadump (and autoipl) Sent by:IBM Mainframe Discussion List >As to whether a null reply in the reported case would have reverted SAD to >the original values, I think we're all looking to Barbara to answer her >own question. ;-) I love it when you guys do that to me! :-) Especially as I was too fast to remedy the situation by reallocating everything before I had figured out what I should have answered those prompts with! Jim Mulder must be on vacation - I had hoped he could confirm this for me. As far as the sys1.sadmp vs. .sadmp goes - it might be a remnant of when we first took sadumps back to DASD. Since then we didn't go to new DASD hardware, so it is kind of understandable that I wasn't aware of this, especially as I wasn't involved in the DASD migration. I had caught the sys1.pagedump thing and the wrong unit in the amdsaosg generation, but I missed the reallocation of the output dataset. The general take here is anyway, that sadumps are only there to indulge me. Why we use the SMS-managed HLQ, I have no clue. I had been told way back when that that was the only way to go multivolume or whatever. I am reluctant to change this now, since it had worked so far (other than this last attempt). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: sadump (and autoipl)
>As to whether a null reply in the reported case would have reverted SAD to >the original values, I think we're all looking to Barbara to answer her >own question. ;-) I love it when you guys do that to me! :-) Especially as I was too fast to remedy the situation by reallocating everything before I had figured out what I should have answered those prompts with! Jim Mulder must be on vacation - I had hoped he could confirm this for me. As far as the sys1.sadmp vs. .sadmp goes - it might be a remnant of when we first took sadumps back to DASD. Since then we didn't go to new DASD hardware, so it is kind of understandable that I wasn't aware of this, especially as I wasn't involved in the DASD migration. I had caught the sys1.pagedump thing and the wrong unit in the amdsaosg generation, but I missed the reallocation of the output dataset. The general take here is anyway, that sadumps are only there to indulge me. Why we use the SMS-managed HLQ, I have no clue. I had been told way back when that that was the only way to go multivolume or whatever. I am reluctant to change this now, since it had worked so far (other than this last attempt). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: sadump (and autoipl)
We also define SYS1.SADMP DSNTYPE=LARGE w/o benefit of SMS. I don't think it matters what you name the data set. We just use the 'well known' name (I love that open systems wriggle out of the 'standard' trap). When you IPL SAD, it goes to the DSN pointed to by SYS1.PAGEDUMP.Vxx on the IPL volume. Formatting the SAD volume places pointers to additional volumes, if any. As to whether a null reply in the reported case would have reverted SAD to the original values, I think we're all looking to Barbara to answer her own question. ;-) . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mark Zelden To: IBM-MAIN@bama.ua.edu Date: 02/15/2012 06:28 AM Subject: Re: sadump (and autoipl) Sent by:IBM Mainframe Discussion List On Wed, 15 Feb 2012 02:43:08 -0600, Barbara Nitz wrote: >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 I can't answer your question, but I can tell you that you can use DSNTYPE=LARGE to allocate the output disk dump data sets without SMS control. I assume you are using hlq.SBLSCLI0(AMDSADDD) REXX exec to allocate them. The last keyword can be "LARGE".In the largest sysplex I support we use 4 3390-27s. Of course it is a good idea to test SADUMP after you make any changes. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: sadump (and autoipl)
On Wed, 15 Feb 2012 02:43:08 -0600, Barbara Nitz wrote: >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 I can't answer your question, but I can tell you that you can use DSNTYPE=LARGE to allocate the output disk dump data sets without SMS control. I assume you are using hlq.SBLSCLI0(AMDSADDD) REXX exec to allocate them. The last keyword can be "LARGE".In the largest sysplex I support we use 4 3390-27s. Of course it is a good idea to test SADUMP after you make any changes. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: sadump (and autoipl)
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 . . . : 4160Used 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 david.jou...@53.com 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:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Wednesday, February 15, 2012 3:43 AM To: IBM-MAIN@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
