From: Vinit [vadya@ibjus.com]
Sent: Thursday, January 09, 2003 4:31 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Firmware Update and VMS upgrade chanded device names.

Thanks John,

Found out VMS 7 has a sys$devices.dat which can actually make this happen.
I just mapped by PKD0: to 1
made all the devices to be presented as DKAn: rather than DKDn:
:)
Cheers
Vinit Adya

John Santos <JOHN@egh.com> wrote in message news:<1030108182151.25162C-100000@Ives.egh.com>...
> On 8 Jan 2003, Vinit wrote:
> 
> > Hi Everyone,
> > 
> > I had an existing AXP4100, with all disks named DKAn: connected to 
> > SCSI controller SCSI PKD0: (disk served by HSZ70.) Now after firmware
> > update  on AS4100 console, and an fresh install of VMS (new disk) all
> > disk devices have changed to DKDn:
> > 
> > Could you help!
> > 
> > Regards
> > Vinit Adya
> 
> It sounds like either the controller changed its name from PKA0: to PKD0:,
> or that you used to have an allocation class defined for the HSZ70.
> 
> If the 1st case, then either you have added some new controllers or
> the firmware change caused a change in the naming rules for controllers.
> There is nothing much you can do about this except 1) to back out the
> firmware update (not recommended).  2) Reorganize the controllers on
> the PCI to get your HSZ70 controller (currently PKD0:) to come out
> as PKA0:.  This may not be possible.  A built-in controller, e.g. the
> one for the CD, might always be PKA0:, or there might be an issue with
> 32-bit vs 64-bit PCI slots or 33Mhz vs. 66Mhz buses that could cause
> potentially serious performance problems.  3) Assign logical names
> of the form "DKAnnn:" to each "DKDnnn:" disk.  This could cause
> collisions with existing real DKAnnn: devices, though.
> 
> If the second case, then the old names were *NOT* DKAnnn:, but were
> $xxx$DKAnnn:, where the xxx was the allocation class.  When you
> reinstalled VMS, did you wipe out or retain sys$system:modparams.dat
> and the file where port allocation classes are maintained?  (I forget
> where these live.)
> 
> </RANT>
> 
> *Never* ever use physical device names in *anything*, except in
> sys$manager:sylogicals.com, where you should assign logical
> names for all the physical devices.  (Actually, it is better to
> put these commands in a separate .com file and call it from 
> sylogicals.com. Then you can move things around whenever you want
> to by just editting the file and executing it interactively.)
> 
> For example, you could number all your disks from 0 to n, and
> assign logicals of the form "DISKn:" to each physical disk, and
> then always use the "DISKn:" logical names everywhere else,
> even when mounting them in systartup_vms.com.  (This is the old
> MicroVMS scheme, I think.)
> 
> Alternatively, you can use the logical names (based on volume
> labels) assigned by VMS when you mount the disks.  Then the
> only place the physical drive name appears is in the mount
> command; everywhere else, you must use "DISK$label:" instead.
> 
> 
> Applications should use a second level (or even third level) of
> logical names assigned to the first level in application startup files.
> For example, application FOO's monthly reports should be stored
> in FOO_MONTHLY:, which is defined as DISK17:[FOO.MONTHLY], or
> better yet, define FOO_ROOT: as a concealed, terminal logical
> name for DISK17:[FOO.] and define FOO_MONTHLY: as FOO_ROOT:[MONTHLY].
> 
> This way FOO can be moved to a different disk independently of
> your physical volume labeling scheme.  (You may want to put more
> than one application on a single disk or split appart applications
> that were formerly on a single disk for reasons of load balancing,
> or because the data requirements are changing and things no longer
> fit.  This makes such things much easier.)
> 
> </END_RANT>