> 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. xxxx.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 [email protected] with the message: INFO IBM-MAIN
