Conference ssag::ask_ssag

    The KZPSA as shipped is at SCSI Target 7.  The HSZ40 is user selectable
    with up to 4 SCSI Targets assigned.  When performing a show this look
    for SCSI targets and if you did not change it the default is "0".  The
    SCSI ID 6 you spoke about is slot dependant and is the SCSI ID in
    relation to the Disks not the host.
    
    If you have not created a LUN by the simple operation of using an
    individual disk to test with:
    
    HSZ>init disk100
    HSZ>add unit d0 disk100
    
    You would not be able to create a volume with a filesystem.
    
    If after this above is done boot Alpha and now you should see a disk.
    
    Paul

    I have already done all of the steps in .-1.  I thought I had explained
    that in my base note.
    
    The problem is that the Alpha _CAN_ see the disk, but any attempts to
    access it hang the system.
    

    Can you include a SHO THIS and SHO UNIT FULL from the HSZ?
    
              Mark d.

    This is what I get on the console now.  (I had more disks plugged in,
    they all looked the same: at the moment only one is plugged in.)
    
HSZ> show this
Controller:
        HSZ40 ZG65009288 Firmware V30Z-2, Hardware  A01
        Not configured for dual-redundancy
        SCSI address 7
        Time: NOT SET
Host port:
        SCSI target(s) (6), No preferred targets
        TRANSFER_RATE_REQUESTED = 10MHZ
Cache:
        16 megabyte read cache, version 2
        Cache is GOOD
        Host Functionality Mode = A
HSZ> show unit full
    LUN                                      Uses
--------------------------------------------------------------

  D601                                       DISK110
        Switches:
          RUN                    NOWRITE_PROTECT        READ_CACHE            
          NOWRITEBACK_CACHE     
          MAXIMUM_CACHED_TRANSFER_SIZE = 32
        State:
          ONLINE to this controller
          Not reserved
          PREFERRED_PATH = THIS_CONTROLLER
        Size: 2049853 blocks
HSZ> sho disk fu
Name          Type                      Port Targ  Lun        Used by
------------------------------------------------------------------------------

DISK110       disk                         1    1    0        D601
          DEC      RZ26     (C) DEC 392A
        Switches:
          NOTRANSPORTABLE       
          TRANSFER_RATE_REQUESTED = 10MHZ (synchronous 10 MHZ negotiated)
        Size: 2049853 blocks
        Configuration being backed up on this container
    
    This should probably be a separate note, but I first tried to do a 
    
    SET HOST /SCSI
    
    command which is mentioned in the manuals, and I get
    
    %DCL-W-ACTIMAGE, error activating image HSZTERM$SCSIPAD
    
    Any suggestions on where this image is provided?  Should it have been
    on media supplied with the HSZ or do I have to try to track down a
    CONDIST somewhere in ZKO?
    
    Thanks again.
    

    From your response to the request for a show this and a sho units it
    does seem you do not have a LUN 0 on SCSI target 6 but you do have a
    LUN 1.  Without a LUN 0 the system will not look for LUN1.  Change from
    D601 to D600 and see if the symptoms change.
    

    I missed it the first time but change your cache_policy=b because it
    appears your cache battery entry does not appear.
    
    Paul

|                     <<< Note 6382.5 by JULIET::SMITH_P >>>
|                                   -< LUN 0 >-
|
|    From your response to the request for a show this and a sho units it
|    does seem you do not have a LUN 0 on SCSI target 6 but you do have a
|    LUN 1.  Without a LUN 0 the system will not look for LUN1.  Change from
|    D601 to D600 and see if the symptoms change.
    
    This seems rather odd to me: I do not remember seeing anything like
    this in the documentation.  Could you supply a pointer?
    
    In any event, I had a D600 before, and since reading your note I
    created one again.
    
    When there was only one drive at D601 the VMS system could see a
    DKB601, but it was offline.
    
    With a drive at D600 and one at D601 the VMS system sees a drive at
    DKB600 which is offline, and a drive at D601 which is online.  However,
    any attempts to access any unit, or do a SYSMAN IO AUTO hangs the
    system.
    
    None of this looks right.  We don't have any of this kind of trouble
    with our much older HSJ40.  I followed the system configuration manual
    to the letter several times, and it ought to just plug in and run.  But
    NOTHING is working correctly.
    
    (We didn't have any trouble with our HSC70 either, but of course there
    was less to go wrong in the configuration.)
    
    I am more convinced than ever that the unit is just plain defective as
    delivered and that I'm going to have to call Field Service to get a
    replacement or something.  But I need to be able to establish that it
    really isn't working before I can put in the service call.
    
|        <<< SSAG::DISK$ARCH2:[NOTES$LIBRARY.SSAG]ASK_SSAG.NOTE;32767 >>>
|                    -< Ask the Storage Architecture Group >-
|================================================================================
|Note 6382.6        Can see HSZ40 but can't access any drives.             6 of 6
|JULIET::SMITH_P                                       4 lines  10-FEB-1997 10:02
|                              -< Cahce Batteries >-
|--------------------------------------------------------------------------------
|    I missed it the first time but change your cache_policy=b because it
|    appears your cache battery entry does not appear.
|    
|    Paul
    
    Apparently, we don't have any.  I opened up the unit to look, and the
    spaces for the batteries are empty and there is a jumper in the
    "battery disable" position.
    
    Aren't brand-new HSZ40s supposed to have batteries?
    
    I dug through the papers that came with it and it included what looks
    like a printout of the console with a SHOW THIS_CONTROLLER FULL
    command.  The printout looks similar to what I get now.  It does show
    CACHE_POLICY = A, however.  It also shows all of the licenses disabled.
    We ordered it with shadowing and raid licenses, and the paperwork
    included documents to that effect.
    

    Pointer to HSZTERM is CSC32::ISG$COMMON:[HSZ40.HSZTERM_VMS]. And 
    another thing you might do is SCSI_INFO on the DKA600 or DKA601 device.
    See if the controller responds. Another thing I might do is a 
    CLEAR LOST_DATA D600 or D601. Sometimes there is lost data even though
    the SHO UNIT output doesn't indicate it. I'd suggest doing the 
    CLEAR LOST_DATA D600 to at least rule that out as a possibility.
    
                             Mark d.

    Since you do not have any cache batteries and the jumper is installed(a
    good thing) and you do not have a license for WBC set this
    cache_policy=b.  This will put the controller in write through mode.
    
    Also most os require a LUN 0 to look for a LUN 1.
    
    Paul
    

|     <<< Note 6382.8 by CSC32::M_DIFABIO "MOVL #OPINION,EXE$GL_BLAKHOLE" >>>
|                    -< CLEAR LOST_DATA, just to be sure... >-
|
|    Pointer to HSZTERM is CSC32::ISG$COMMON:[HSZ40.HSZTERM_VMS]. And 
    
    Thanks for the pointer.  Unfortunately, HSZTerm does not install
    properly on OpenVMS V7.1 on the Alpha (guess the kit hasn't caught up
    yet?).  There is a CLI failure, error parsing 'CACHING', specified
    entry not found in command tables.
    
|    another thing you might do is SCSI_INFO on the DKA600 or DKA601 device.
|    See if the controller responds. Another thing I might do is a 
|    CLEAR LOST_DATA D600 or D601. Sometimes there is lost data even though
    
    This command fails on my HSZ40 console, it says LOST_DATA can't be
    performed because there is no LOST_DATA.
    
    We're going back over all of the paper-work.  The system was ordered
    with licenses and the paperwork that came with it says we have
    licenses, but I have to see if they were loaded properly.
    

|    another thing you might do is SCSI_INFO on the DKA600 or DKA601 device.
    
    I tried this, and the controller never responds.  The system is just
    hung forever, or until I do a Control-P on the system console.  At that
    point, I get an "unknown system state" error, and I have to INIT the
    system to continue.
    
    When I boot now I get an error I don't remember seeing before,
    
    CAM command EXECUTE_SCSI_IO timed out
    
    even if I'm booting from a local disk and not trying to access the
    HSZ40.

    I don't want to drag this along through the notesfile, so I'll mail 
    you on a couple other things to try. One thing I'd like to know is
    where termination is (for the scsi bus) and what the terminator looks
    like. (Metal with a black cover or a molded plastic terminator.)
    
                      Mark d.

    
    Thanks to some off-line help from M. Difabio, my system is now working.
    
    The HSZ40 was supplied with a BN21F-10 cable.  This cable was either
    defective, or is too long even for differential SCSI.  I replaced it
    with a BN21F-05 and everything appears to be working normally.
    
    Bart.
    

    I don't find a BN21F-xx in the price file.  I would have expected a
    BN21K-xx.