Ed, My "perceived" observation is that varying devices and paths in z/OS takes much longer and uses more resources than it did many moons ago under ESA, XA or SP2. It's my understanding that a lot of device validation that used to occur at IPL when a device was discovered now occurs when the device comes online, hence a faster IPL, but a slower vary online.
For example varying just 256 volumes online on 2094-408 with one dedicated CP online locks up TSO for a minute or three, and usually drops my NJE links (yeah I'm too lazy to tune this - it's a lab). I don't recall this behavior way back on 3033 or 4341, or any uniprocessor LPARs I had in early PR/SM and MLPF. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ed Gould > Sent: Monday, April 12, 2010 10:37 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] > > ________________________________ > From: Ron Hawkins <ron.hawkins1...@sbcglobal.net> > To: IBM-MAIN@bama.ua.edu > Sent: Mon, April 12, 2010 10:46:05 AM > Subject: > > Alan, > > I regularly bring 100s of volumes offline and online and have not seen this > problem. I submit the jobs in the same way as you do. The only difference is > I usually have one command per LCU which makes it easier for me to eyeball > my changes when I'm setting up tests. > > Ron > > > Ron: > > Way back when MP's first came out a lot of the vary commands did not allow for > large number of devices. > We needed on occasion to take hundreds of paths online (or offline). Our IBM > SE wrote the code to send the hundreds of onlines to the system. > We really used that code quite a bit. It *NEVER* caused any issue with the > system and we never saw any system abends as a result of these hundreds of > vary commands being issues. Granted this was 25++ years ago but I would have > thought if there would have been a bug we would have found it. > > IIRC the biggest issue we had was that Q4 was being so backed up we found > (actually IBM) was surprised at the length of our Q4. What added into our mix > (for the Q4) was we had a MSS which caused us all a lot of headaches. > > BTW our SE at the time was Jim Garner who went on to the Washington System > Center as the DASD expert there. He no longer works for IBM. > IBM lost a great asset when they smothered the System center. > > Ed > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
