Re: General mount/shadow command?

From: Peter 'EPLAN' LANGSTOEGER (peter_at_langstoeger.at)
Date: 01/26/05 

Date: Wed, 26 Jan 2005 20:47:39 +0000 (UTC)

In article <1106763439.812684.98940@z14g2000cwz.googlegroups.com>, tadamsmar@yahoo.com writes:
>Up till now all my systems have had disks
>named DKA0 AND DKA100.

Not that bad.
But referring to the disks without logical names (except in the procedure
where the mount of these disks happen during startup) is bad.
You gain A LOT of flexibility with logical names. eg Virtual (Concealed) disks

>But we now have some systems with DKB0
>and DKB100, and I need to generalize
>my command procedures and written
>procedures. I prefer to have all
>the command procedures on all the
>systems to be the same, if possible.

Thats why there are logicalnames.
And all refer to the same logical names
(which are based on functionality not on physics).

>These are used to form a shadowset.

It is no different to a physical disk. The mount command is different.
You need a nonzero allocation class and a shadowing license. That's it.

>I was wondering if there is a generic
>way to refer to these disks in
>
>the MOUNT/SHADOW= command.

Do not use logicals in the MOUNT command.
Do use the MOUNT command to create logicals for the volumes (disks).

You need one single point with knowledge about the real hardware.
Better have it in SYCONFIG.COM than in SYLOGICALS.COM

>I know that
>
>mount dka0 sx
>
>will allow me to refer to disk$sx,

Yup. DISK$label is the default logical MOUNT assigns for the disk,
but you can specify the name of the logical yourself as the 3rd parameter
to the mount command.

>but I typically don't issue mount
>commands for these disks.

Then better change your method.
or in less aggressive words
WHO does issue mount commands then ?

>If there is no better way, I
>can check f$device(*dkb0:) to see
>if it returns a null string, and
>issued different commands based on
>this.

You could of course take F$DEVICE and F$GETDVI to get/check a list of device
names, but I think it is not worth the effort. A simple IF node .EQS. "node1"
in SYCONFIG.COM where you place the specific mount command for this node
(and you place all commands for all your nodes in the same file which you
distribute) is IMNSHO the least 'dangerous' method.

just my 0.02 

-- 
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail  peter@langstoeger.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

Relevant Pages

  • Re: General mount/shadow command?
    ... > But referring to the disks without logical names (except in the ... > You need a nonzero allocation class and a shadowing license. ... > Do not use logicals in the MOUNT command. ... > Do use the MOUNT command to create logicals for the volumes. ...
    (comp.os.vms)
  • Re: VMS naming conventions for disk volumes?
    ... just MSCP serving of the disks). ... > supported and b) it will work to have the same volume label if the disk ... > since I always have labels appropriate to the DISK$volume-label logicals ... You cannot get around this by using the third argument to MOUNT. ...
    (comp.os.vms)
  • Summary: System hardware migration best practices
    ... - Is the HDS and EMC storage all SAN-connected? ... disks and data disks. ... On new sys: ... Mount manually one by one to test: ...
    (SunManagers)
  • Summary: System hardware migration best practices
    ... - Is the HDS and EMC storage all SAN-connected? ... disks and data disks. ... On new sys: ... Mount manually one by one to test: ...
    (SunManagers)
  • Re: CD images, ISO
    ... exactly what command did you run to try to mount the disks? ... ]internet access onto linux. ... If you omit a package during the initial install, ...
    (comp.os.linux.powerpc)