3.4 SCSI Cluster Considerations Point to the OpenVMS Cluster Systems book for device nam- ing info. If you are creating an OpenVMS Galaxy with shared SCSI buses, you must note the following: For OpenVMS to correctly give the SCSI devices the same name on each instance, you will likely need to utilize the device-naming feature of OpenVMS. For example, assume that you have the following adapters on your system when you enter the SHOW CONFIG command: PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller KZPxxx) PKC0 (UltraSCSI controller) When you make this system a two-instance Galaxy, you ???????????? Instance 0 PKA0 (UltraSCSI controller) Instance 1 PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller) Your shared SCSI will be connected from PKA0 on instance 0 to PKB0 on instance 1. If you initialize the system with the LP_COUNT environm- net variable set to 0, you will not be able to boot OpenVMS on the system unless the SYSGEN parameter STARTUP_P1 is set to MINIMUM. This is because, with the LP_COUNT variable set to 0, you will no have PKB connected to PKC, and the SCSI device-naming that was set up for initializing with multiple partitions is not correct for initializing with the LP_COUNT variable set to 0. During the device configuration that occurs during boot, OpenVMS will notice that PKA0 and PKB0 are connected together. OpenVMS expects that each device has the same allocation class and names, but in this case - they will not. The device naming which was set up for the 2 instance Galaxy will not function correctly since the console naming of the controllers has changed... Also, there appears to be a problem with setting SCSI IDs for SCSI adapters in the console. This is something that needs to be done for SCSI cluster. It currently appears that on the 4100, you must set instance 1 to SCSI id 6 and leave instance 1 at 7. We don't yet understand this behavior with the console, so I can't provide a detailed release note here - only that we may need something for FT3.