DKCs and DKDs disk in two alphaserver systems

[WilliamSmith11]

Hi
A customer have a two storage attached in two system in cluster running open VMS , he want attach this two storage RA10000 with controller HSZ52 two to new machine DS25 and ES45.

In the old system the disk of the two storages are presented to the system as DKCs and DKDs from the >>> prompt. In the new system only I have the controller that come with the machine so I have DKA, if I install the old controller card (HBA scsi) to the new ds25 or ES45 I will get DKA,DKB, and DKC.

My question is there is some way to edit or something else in such way that the system can see DKCs and DKDs in place that DKBs and DKCs I dont want a third scsi card , I want only work with the two card added to the systems.

Thank you

W.S

[David Jones_21 · Accepted solution]

I don't think you have much control over PKx assignements. Are you trying to share the devices between machines or just don't fixup application references to the old devices? In the former case, you can use port allocation classes so the disks on the SCSI appear as $xxx$DKAnnn. You use a special command in SYSBOOT to assign the corresponding PKc (whatever it ends up) to allocation class xxx.

[John Gillings]

William,

Controller letters are allocated according to "discovery" by the console. The only way you can affect them is to physically move cards around between slots. Different platforms use different search mechanisms to discover controllers, so there is no hard rule that can be applied to all systems. All you can say is for a given hardware configuration the assigned controller letters will be stable. However, if you add or remove cards, the letters may change.

Port allocation classes can be used to change the naming of SCSI devices. The intent was for use in shared SCSI busses to force the name of a particular device to be the same on all nodes with direct paths, but there's no reason they can't be used in your circumstances to get some control over device naming (though maybe not as much as you'd like!)

V7.1 or higher

SYSGEN parameters ALLOCLASS and DEVICE_NAMING must be non-zero

From SYSBOOT> prompt issue the command:

SYSBOOT> SET/CLASS PKB n

Where n is different from the node ALLOCLASS. Devices on the PKB bus will now be named $n$DKAxxx

See SYS$SYSTEM:SYS$DEVICES.DAT for current settings (but DON'T try to edit that file!)

[Ian Miller.]

I think using port allocation classes is the way to get the names consistant on both systems. The names will not be same as the old names but they will be be same. Something could be done with logical names but best not.

http://h71000.www7.hp.com/doc/82FINAL/6318/6318pro_006.html#index_x_304
http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/00/00/33-con.html

[Jan van den Ende]

... and then, assuming your apps hardcoded use DKBx, DKCy and DKDz, the trick to be able to run your app is:

$ DEFI/SYS/EXEC/TRANS=CONC DKBx $m$DKArrr:
$ DEFI/SYS/EXEC/TRANS=CONC DKCy $n$DKAsss:
$ DEFI/SYS/EXEC/TRANS=CONC DKDz $m$DKAttt:

hth,

Proost.

Have one on me.

jpe

[Robert Gezelter]

WS,

I concur with Jan.

While I recommend that clients restrict physical device names to a very limited set of command files used during the startup process, I often encounter sites where this advice has not been followed in the past.

The long term solution is to fix the references to logical names based on volume names or data category (see my HP OpenVMS Technical Journal Version 3 paper, a reprint of which is available via http://www.rlgsc.com/publications/vmstechjournal/inheritance.html).

As a short term bridge, I have often used concealed logicals as a way to "bridge" between a configuration which relies on physical device names to a new physical configuration, while we sort out the logical environment. This allows production use to continue without interruption.

- Bob Gezelter, http://www.rlgsc.com