Richard, All the devices coded in the imbed file as offline_at_ipl are still seen as DEV OFFLINE by the system even if we code sensed 0000-ffff in the config file, as you show. At this time I suppose I will use the cp q all offline cmd, extract all the DEV and vary on them. Not very nice.
Alain Le 21/03/07 21:36, « Schuh, Richard » <[EMAIL PROTECTED]> a écrit : > Go ahead and let the devices be sensed. We take a slightly different approach. > We have > > Devices , > Online_at_IPL 0000-FFFF, > Dynamic_I/O 0000-FFFF, > Sensed 0000-FFFF > > Followed by (it happens to be the last entry in the CONFIG) > > IMBED DEVICES OFFLINE > > Where the devices offline file lists in agonizing detail which devices are to > be taken offline. All of the devices are sensed, so we need not mess with > RDEVICE at all except for a few unsupported devices that we have. We took > this approach because of the demands placed on us by the DASD Storage > Management Group (MVS centric), who give us a scattering of disks intermixed > with those belonging to that other system, and by other people who think that > MVS disks should never be online to a VM system. They happen to be the tail > that wags the dog. > > This doesn't eliminate the need to have an EXEC or Pipeline to vary on the > ones that you do not want attached to system during the IPL, but it does > insure that the device blocks are built according to the data returned by the > sensing operation during roll-call. We do not have the problem of duplicate > volume serials, so that is not a concern of ours. > > Regards, > Richard Schuh > > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf > Of Alain Benveniste > Sent: Wednesday, March 21, 2007 1:03 PM > To: [email protected] > Subject: Re: System Config : suggestion (corrected) > > James, > > I didn't give enough infos : the problem is how to treat duplicate volsers > as Berry says Offline during IPL but get them Online just after. > > I have tested a similar solution where the idea was to pipe cp q da offline > and vary on the result. The problem is that what we code with Offline_at_ipl > is not sensed which means that the DASD are seen as DEV xxxx OFFLINE. Cp q > da offline cmd sends nothing back. To 'resolve' this the only way I found is > to let the Offline_at_ipl and add the Rdevice type dasd for all the ranges. > That's an other problem because Rdevice only supports 256 dev by cmd... > > Alain > Paris, France > > > > > Le 21/03/07 15:47, « Stracka, James (GTI) » <[EMAIL PROTECTED]> a écrit : > >> Interesting. We reverse the order: >> >> Devices , >> Offline_at_IPL 0000-FFFF, >> Sensed 0000-FFFF, >> Online_at_IPL 0400-0408 , >> 0A00-0AEF , >> A9A0-A9AF , >> AC30-AC3F , >> AFAF , >> BC90-BCA8 , >> C940-C94F , >> CD40-CD5F >> >> >> >> -----Original Message----- >> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On >> Behalf Of Berry van Sleeuwen >> Sent: Wednesday, March 21, 2007 9:40 AM >> To: [email protected] >> Subject: Re: System Config : suggestion (corrected) >> >> >> Hello Alain, >> >> We use an input file to select what DASD addresses should be online >> after >> an IPL. The file is basically a Q DASD. The file is read and attaches >> the >> DASD to system, dedicated DASD is left free and DASD that is not used is >> >> set offline. The only thing we have to do is (re)build the DASD file >> when >> a volume has been added or deleted. (PIPE CP Q DASD | > DASD FILE D) It >> saves us from changing the system config every time we change the DASD >> configuration. If the files are located on shared DASD the DASD FILE can >> >> be named something like VMLXHW1 DASD for the VMLXHW1 node. >> >> This doesn't work when we have duplicate DASD volumes that are required >> during IPL. We have some VM's that still use the default zVM440 DASD >> volume ID's. When a default 440W01 or something like that has not been >> relabeled the 'wrong' addresses must be set offline in the system >> config: >> >> FBVM03: Devices , >> Online_at_IPL 0000-FFFF, >> OFFLINE_AT_IPL 2100-21DF, >> OFFLINE_AT_IPL 21EA-21FF, >> OFFLINE_AT_IPL 2200-239F, >> OFFLINE_AT_IPL 23A4-23FF, >> Sensed 0000-FFFF >> >> Regards, Berry. >> -------------------------------------------------------- >> >> If you are not an intended recipient of this e-mail, please notify the >> sender, >> delete it and do not read, act upon, print, disclose, copy, retain or >> redistribute it. Click here for important additional terms relating to this >> e-mail. http://www.ml.com/email_terms/ >> -------------------------------------------------------- >> >
