Conference spezko::cluster

    Are you seeing this from VMS or from the console?  If the DUB naming is 
    from a console SHOW CONFIG then I suggest asking this question in the 
    LASER notes conference since the console engineers for that system
    typically read there.  I would not be too concerned if it only shows
    that naming from the console.  The console has to be somewhat
    operating system independent and I would not expect it to always use
    VMS naming conventions.
    
    This is not expected behaviour if you are seeing this device naming
    from VMS.  Disks connected to CI controllers should always show up
    as DUA devices qualified by an allocation class (recomended) or
    controller name if allocation classes are not being used. IE:
    $1$DUA0 or HSJ001$DUA0.
    
    Brian Hibbert
    
    

    
    Thanks Brian for the response. Glad to know that the device will remain
    as DUA. I suspect I may have a bad CIXCD or bulkhead etc. Currently
    checking into it.
    
    Justin

    No, you don't have a hardware problem with the CIXCD.  Device names are
    a software concept.  They are assigned by the console software if you
    are looking at the console output, or by the operating system if you
    are looking at a SHOW DEVICE command output.  As I said before, VMS
    would normally keep the DUA device name for CI connected disks.  The
    console is free to call a device anything it wants to call it.
    
    Brian Hibbert
    

    I did some checking in the PROXY::LASER notes file. According to note
    777.* in that conference, the console does assign different letters to
    disks seen through additional CIXCD controllers.  
     Note: This applies ONLY to the >>> SHOW DEVICE command at the console
    prompt.  Once VMS boots the device names in the DCL $ SHOW DEVICE
    should all be DUA devices.
    
    Brian Hibbert
    

:     Note: This applies ONLY to the >>> SHOW DEVICE command at the console
:    prompt.  Once VMS boots the device names in the DCL $ SHOW DEVICE
:    should all be DUA devices.

  Actually, OpenVMS tends to prefer to have alternate controllers assigned
  unique controller letters, so an argument could be made that OpenVMS is
  being inconsistent here.  (Note that there are very good reasons for this
  particular inconsistency...)

  Prior to V5.3, DSSI disks were often seen as DIAn:, DIBn:, DICn:, etc.,
  depending on the DSSI controller configuration.  During the V5.3-* range,
  the system manager could select the old or the new scheme.  After V5.4, 
  all DSSI disks are known via DIAn:.

  The logical extension of the suppression of the controller letter on DSSI
  disks is the V7.1 port allocation class support.

Well this is what we experienced hence note 0.

We have an existing cluster, A8400 with one CIPCA connected to star A, A 
DEC7720 with two CIXCDs both connected to star A, and two pairs of HSJ40s
With rz28s and TZ887s connected to Star A, 4 HSC95s with RA9X, RA7X, TU81 
connected to Star A.

We added another A8400 with 2 CIXCDs. It so happened that the second CIXCD,
known as dub from the console show config, was connected to Star A. The first
CIXCD known as dua was connected to Star B. With this config we were not able
see any of the disks off the HSXXXs. Suspecting as what .1, we booted
the VMS6.2-1h3 CD and entered the DCL mode. It could not size any disk.
On the HSJ40 there were disks that were not mounted by any of the active
cluster nodes. So we did not really see any DUBX drives but it could not 
see any DUA type drives either.

Star B currently has no other devices connected to it. We plan to move a 
pair of HSJ40 there later. A second CIPCA will also be installed on the other
A8400 to connect to star B. The DEC7720's second CIXCD will also then be 
connected to Star B.

However when we switched the cables around ie first CIXCD to Star A and Second
CIXCD to Star B, we were able to size the disk both at the console and
DCL modes. We did interchange the CIXCD modules just to verify the cards
but they worked the same in any position. We did re-check the cabling and 
CINode IDs etc but could not find anything amiss.

Hence the conclusion I came too, at the time, was there was some conflict in
the naming convention used. I remember as .5 pointed out in the past
with the DSSI controllers, we did have a special sysgen parameter to decide 
what naming convention to use.  

Justin
    

    Check the header card, internal cable connections, jumpers, bent pins.
    
    Do the following from VMS to collect data:
    	$sho cluster/cont
    	add cables		! shows virtual circuits
    	add max_port		! 	cluster size setting
    	add rport_num		!	node numbers
    Remember that you should see a connection to yourseld for each adapter.
    
    Contact me if you have aditional problems.
    -Tom-
    

re: .4
>   I did some checking in the PROXY::LASER notes file. According to note
>   777.* in that conference, the console does assign different letters to
>   disks seen through additional CIXCD controllers.  
    
     Is that the reason why VMS 7.1 set the max. number of CIPCA for
    TurboLaser to be 26 ?
    
    Regards,
    Mong-Kia

    No, it's not a console issue, that is a VMS restriction but it is 
    similar.  VMS assigns each successive controller of the same type a
    different letter, IE: PNA0, PNB0, PNC0, PND0.  VMS runs out of letters
    after 26.  Disks connected to these controllers will be seen by VMS as
    DUA devices no matter which PNx0 the HSJ is connected to.
    
    Brian Hibbert