Re: Dasd Volser standards documented
Phil, I don't really know if these restrictions are really documented anywhere in any IBM official publication. I do know that IBM Endicott follows the name the volume with its function rulethe install volumes for z/VM 6.1 are 610RES, 610PAG and 610SPL. Some sites expand on that naming standard and name their DASD, using names like USR001, LNX001, or 61LX01 to at least give them an idea of what's on the volume and what system it belongs to. Hope this helps. On 07/28/2010 09:25 AM, Philip Tully wrote: I appreciate the responses, but the specifics are I am looking for are what should not be used. I think we all have enough experience to know we should use and '*' in the volser, but are these kind of restrictions documented? -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Dasd Volser standards documented
On Wednesday, 07/28/2010 at 10:26 EDT, Philip Tully tull...@optonline.net wrote: I appreciate the responses, but the specifics are I am looking for are wh at should not be used. I think we all have enough experience to know we shou ld use and '*' in the volser, but are these kind of restrictions documented ? There's no documentation that I'm aware of, but you'll want to avoid volsers that are 1 to 4 hexadecimal digits (i.e. could be interpreted as a device address) or that match the keywords on any of these commands - QUERY DASD - QUERY ALLOC - ATTACH - DETACH This includes volids like FREE, ALL, BOXED, ACTIVE, VOLID, VOLUME, etc. Also avoid imbedded blanks. Alan Altmark z/VM Development IBM Endicott
Dasd Volser standards documented
I was wondering if there was an IBM document which gave suggestions for D ASD volser conventions and/or limitations. I have seen plenty of local writt en ones, but I can't remember it being in a manual. TIA Phil
Re: Dasd Volser standards documented
On Wed, Jul 28, 2010 at 2:28 PM, Philip Tully tull...@optonline.net wrote: I was wondering if there was an IBM document which gave suggestions for DASD volser conventions and/or limitations. I have seen plenty of local written ones, but I can't remember it being in a manual. No wonder you can't remember... My code has this: /* Comply with C-S 3-8010-003, dated 1981-12 ;-) credits ALTMARKA */ | Rob
Re: Dasd Volser standards documented
Phil, I was wondering if there was an IBM document which gave suggestions for DASD volser conventions and/or limitations. In the Virtualization Cookbooks, some of which are Redbooks and thus IBM documents, we recommend using the last four characters of the volser as the DASD rdev. If this convention is followed it guarantees unique labels and makes it easy to know which DASD is which. But that leaves only two characters. The first character is recommended to signify the LPAR. The second character is recommended to be the function of the DASD: S for spool, P for page, M for minidisk, V for VM (or CP Owned) and T for temporary disk. This system has worked fairly well for us on our own systems, but of course is not perfect. Hope this helps. Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: Dasd Volser standards documented
On Wed, Jul 28, 2010 at 2:52 PM, Michael MacIsaac mike...@us.ibm.com wrote: In the Virtualization Cookbooks, some of which are Redbooks and thus IBM documents, we recommend using the last four characters of the volser as the DASD rdev. If this convention is followed it guarantees unique labels and makes it easy to know which DASD is which. But that leaves only two That's definitely not the old school tradition where we were told to avoid volser based on real device address. You'd name the volume after the data or purpose, not on where it is sitting. Today it's probably less common to find a volume restored on another HDA when you get back in the office. Since your approach probably will have exceptions too, you'll have to use the right info anyway (rather than code 'DETACH' substr(volser,2) for example - the lookup stage is your friend for that...) | Rob
Re: Dasd Volser standards documented
And with the ease of copying DASD via Flashcopy, I move volumes from device to device for various reasons, VOLSERs with the device address does not work for me. YMMV. On Wed, Jul 28, 2010 at 9:06 AM, Rob van der Heij rvdh...@gmail.com wrote: On Wed, Jul 28, 2010 at 2:52 PM, Michael MacIsaac mike...@us.ibm.com wrote: In the Virtualization Cookbooks, some of which are Redbooks and thus IBM documents, we recommend using the last four characters of the volser as the DASD rdev. If this convention is followed it guarantees unique labels and makes it easy to know which DASD is which. But that leaves only two That's definitely not the old school tradition where we were told to avoid volser based on real device address. You'd name the volume after the data or purpose, not on where it is sitting. Today it's probably less common to find a volume restored on another HDA when you get back in the office. Since your approach probably will have exceptions too, you'll have to use the right info anyway (rather than code 'DETACH' substr(volser,2) for example - the lookup stage is your friend for that...) | Rob
Re: Dasd Volser standards documented
Hello Everyone, We do use the last 3 digits example DS6900 is real dasd 0900. But the naming convention has to be set my your sites standards and balanced against what you need and what you do with your DASD. In our case, we make sure that Operators/Applications/Systems/CE/outside IBM VMer's/etc. can come in and look to see where All dasd are and where they are connected. And yes YMMV! Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Pace Sent: Wednesday, July 28, 2010 9:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dasd Volser standards documented And with the ease of copying DASD via Flashcopy, I move volumes from device to device for various reasons, VOLSERs with the device address does not work for me. YMMV. On Wed, Jul 28, 2010 at 9:06 AM, Rob van der Heij rvdh...@gmail.com wrote: On Wed, Jul 28, 2010 at 2:52 PM, Michael MacIsaac mike...@us.ibm.com wrote: In the Virtualization Cookbooks, some of which are Redbooks and thus IBM documents, we recommend using the last four characters of the volser as the DASD rdev. If this convention is followed it guarantees unique labels and makes it easy to know which DASD is which. But that leaves only two That's definitely not the old school tradition where we were told to avoid volser based on real device address. You'd name the volume after the data or purpose, not on where it is sitting. Today it's probably less common to find a volume restored on another HDA when you get back in the office. Since your approach probably will have exceptions too, you'll have to use the right info anyway (rather than code 'DETACH' substr(volser,2) for example - the lookup stage is your friend for that...) | Rob
Re: Dasd Volser standards documented
Mark, And with the ease of copying DASD via Flashcopy, I move volumes from device to device for various reasons, Well sure, so do I. I either FLASHCOPY starting at cylinder 1, or if I need the entire disk copied, I relabel (clip) the target volume per the convention after the copy. FLASHCOPYing the entire volume without clipping one volume afterwards guarantees duplicate volsers. If there are any z/OS systems that also have access that DASD, the z/OS IPL process will stop when duplicate volsers are found (as I understand it). This gets the z/OS people mad at us z/VM people. That's *one* reason I always try to avoid duplicate volsers. FWIW... Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: Dasd Volser standards documented
Definitely NOT trying to inspire another I remember when all we had were zeroes to bang together, because ones hadn't been invented yet! conversation, but... I learned to despise VOLSERs associated with real device addresses when I was still too young to legally buy my own beer. It seemed like a great idea at first, but entropy - in the form of recalcitrant hardware and intractable operations staff - conspired with physically removable / relocatable 3330 disk packs to make a special kind of hell. RDEV addresses in volume labels? Don't touch it. It's evil! Stick with something that associates the volumes with their intended purpose, instead of the rdev address. Except when you're plugging in your IPL address, and perhaps other rare special occasions, you really shouldn't ever have to *care* what the rdev address is. Here endeth the rant... -dan. *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Mark Pace *Sent:* Wednesday, July 28, 2010 9:21 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Dasd Volser standards documented And with the ease of copying DASD via Flashcopy, I move volumes from device to device for various reasons, VOLSERs
Re: Dasd Volser standards documented
On IBM internal systems, they break the 6 char volser into 3 2 character fields. The first 2 characters are for the volume usage (PG for paging, SP for spool, RS for sysres, you get the idea). The next 2 identify the LPAR or VM system (so you need a list somewhere that maps these 2 character ids to your LPARs). The last 2 are the serial number, which can be any unique combination of letters and numbers. Of course, you can use 1 character for system id and volume type as Mike suggested, and have more characters available for the serial number. -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Re: Dasd Volser standards documented
Yep, I understand that. Once the volume is copied and put online the old volume is clipped. Since I'm both the z/VM guy and the z/OS guy (and vse and linux) I have no one to blame but myself. On Wed, Jul 28, 2010 at 9:34 AM, Michael MacIsaac mike...@us.ibm.comwrote: Mark, And with the ease of copying DASD via Flashcopy, I move volumes from device to device for various reasons, Well sure, so do I. I either FLASHCOPY starting at cylinder 1, or if I need the entire disk copied, I relabel (clip) the target volume per the convention after the copy. FLASHCOPYing the entire volume without clipping one volume afterwards guarantees duplicate volsers. If there are any z/OS systems that also have access that DASD, the z/OS IPL process will stop when duplicate volsers are found (as I understand it). This gets the z/OS people mad at us z/VM people. That's *one* reason I always try to avoid duplicate volsers. FWIW... Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: Dasd Volser standards documented
I appreciate the responses, but the specifics are I am looking for are wh at should not be used. I think we all have enough experience to know we shou ld use and '*' in the volser, but are these kind of restrictions documented ?
Re: Dasd Volser standards documented
From ICKDSF VOLID(serial) Writes the volume serial number in the volume or minidisk label. *For serial, substitute 1 to 6 alphanumeric characters for the volume serial number. If fewer than six characters are specified, the serial is left-justified, and the remainder of the field is padded with blanks (X'40').* On Wed, Jul 28, 2010 at 10:25 AM, Philip Tully tull...@optonline.netwrote: I appreciate the responses, but the specifics are I am looking for are what should not be used. I think we all have enough experience to know we should use and '*' in the volser, but are these kind of restrictions documented?
Re: Dasd Volser standards documented
But some other o/s's or tools don't like x'40's in them. So don't use less than 6. Can't remember if it was z/OS or some component of GDPS, but play it safe and use six. marcy From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Pace Sent: Wednesday, July 28, 2010 7:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Dasd Volser standards documented From ICKDSF VOLID(serial) Writes the volume serial number in the volume or minidisk label. For serial, substitute 1 to 6 alphanumeric characters for the volume serial number. If fewer than six characters are specified, the serial is left-justified, and the remainder of the field is padded with blanks (X'40'). On Wed, Jul 28, 2010 at 10:25 AM, Philip Tully tull...@optonline.net wrote: I appreciate the responses, but the specifics are I am looking for are what should not be used. I think we all have enough experience to know we should use and '*' in the volser, but are these kind of restrictions documented?
Re: Dasd Volser standards documented
Haven't tried it, but was thinking naming a DASD volume named ALL might confuse some commands?Seems like over the years there have been either userids or volume names that needed to be restricted/discouraged for such reasons... but I don't remember seeing a specific list offhand. Scott Rohling On Wed, Jul 28, 2010 at 8:48 AM, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: But some other o/s's or tools don't like x'40's in them. So don't use less than 6. Can't remember if it was z/OS or some component of GDPS, but play it safe and use six. marcy From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Pace Sent: Wednesday, July 28, 2010 7:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Dasd Volser standards documented From ICKDSF VOLID(serial) Writes the volume serial number in the volume or minidisk label. For serial, substitute 1 to 6 alphanumeric characters for the volume serial number. If fewer than six characters are specified, the serial is left-justified, and the remainder of the field is padded with blanks (X'40'). On Wed, Jul 28, 2010 at 10:25 AM, Philip Tully tull...@optonline.net wrote: I appreciate the responses, but the specifics are I am looking for are what should not be used. I think we all have enough experience to know we should use and '*' in the volser, but are these kind of restrictions documented?
Re: Dasd Volser standards documented
One more voice in the chorus of those who despise using the rdev in the volser of any disks except for spare packs. Here, the storage management folks do a dasd refresh every two years. When they init the packs that are to belong to VM, they are given volsers of the form VMrdev. When I copy the packs that are in use, I can easily determine the use of any given disk in the farm because all of the used dasd have volsers that are comprised of a mnemonic prefix and a sequence number. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Michael MacIsaac Sent: Wednesday, July 28, 2010 5:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dasd Volser standards documented Phil, I was wondering if there was an IBM document which gave suggestions for DASD volser conventions and/or limitations. In the Virtualization Cookbooks, some of which are Redbooks and thus IBM documents, we recommend using the last four characters of the volser as the DASD rdev. If this convention is followed it guarantees unique labels and makes it easy to know which DASD is which. But that leaves only two characters. The first character is recommended to signify the LPAR. The second character is recommended to be the function of the DASD: S for spool, P for page, M for minidisk, V for VM (or CP Owned) and T for temporary disk. This system has worked fairly well for us on our own systems, but of course is not perfect. Hope this helps. Mike MacIsaac mike...@us.ibm.com (845) 433-7061
