Since our environment is fairly dynamic, what I've done is to let SYSTEM
CONFIG vary on all the devices that are visible to our LPAR, and then parse
through a Q DASD ALL in AUTOLOG1, looking for CP OWNED and CP SYSTEM. Any
other volume I find, I vary offline, keeping my zOS peers happy and off my
case about holding their devices and keeping them from being able to back
up, etc....
In this way, I don't need to keep the devices list up to date in SYSTEM
CONFIG, which was getting up into the hundreds of lines.
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OC-1-13 200 First Street SW
/( )\ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 3/21/07 11:01 PM, "Alain Benveniste" <[EMAIL PROTECTED]> wrote:
> 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: IBMVM@LISTSERV.UARK.EDU
>> 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: IBMVM@LISTSERV.UARK.EDU
>>> 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/
>>> --------------------------------------------------------
>>>
>>
