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/
> --------------------------------------------------------
>
