I’ve always liked Vnnnnn, where n is the order of acquisition in your organization, eg V00001 for the first volume acquired, V00002 for the second, etc. The V is there to not confuse commands that need a volser as input into thinking they’re dealing with a real address (once had that problem with a system that had all numeric userids --- ick), and I’ve never rolled over within the same complex during my time there.
If you stick to decimal numbering most people don’t confuse them with addresses, and if you go through a lot of disks (as I assume Visa does), you’re still unlikely to replace 99,999 at a time. Works with LPARs, VM, z/OS, pretty much any situation you come to. On 8/27/10 10:45 AM, "Schuh, Richard" <rsc...@visa.com> wrote: Also, if you have dasd that is EMIFd to n LPARS, how do you know (a) whether a disk is spare or in use if all of the dasd have volsers ZLnnnn, and (b) if in use, by which LPAR? IO can see using VMnnnn as an indicator that a volume has not yet been deployed, but once it has, it needs to be labeled using another convention. Since we seem to replace our DASD farm every 2 or 3 years, device number has no place in the scheme other than to denote a spare volume. Regards, Richard Schuh
