Conference ssdevo::hsz40_product

    
    Use the 8-bit Pers. Module and the BN12H 50/50pin HiDensity connector
    cable, as indiacted in the release notes (If I remember correctly).
    
    Your solution is NOT terminator at ONE end of the UPPER-BYTE SCSI and
    as such NOT recommended (I might work, but it does not....),
    
    		Jan

    Jan,
    
    While you are correct, the upper 8bits are not terminated on both
    ends of the physical bus, it will still operate correctly. The
    Bus is only operated in 8bit mode, so the upper 8bits are not driven.
    The single terminator will hold the lines in a stable state to allow
    the wide devices to pass self test. Since all transfers are 8bits,
    the drives will not use the upper bits. 
    
    The cable is a 50 wire cable, so the upper lines do not leave the I/O
    module. 
    
    Bert
    

    
        "Are the 16-bit personality modules supported with narrow
         controllers ? "
	
	For the HSx40/HSx50 we had the answer in the releasenotes and
	the SPD... It was a clear NO !

	Now with the new release V3.1/V5.1 we seem to lift this restriction.
	The SPD/releasenotes are telling on the first page that now both
	8-bit and 16-bit personalities are supported. 
	But on the following pages with devices supported, just below 
	the tables, we see "wide drives require BA356 shelves and 8-bit I/O
	modules".
	I assume this should read as "wide drives require BA356 shelves 
	and 8-bit or 16-bit I/O modules" ?
	
	BUT is it supported that V2.7/5.0 driven controllers  operate with the 
	16-bit I/O modules ? 
    
	Bert told in .2 that this works, but supported ? 
    
	This is important to know in case of an escalation. 
    	We look like donkeys when we escalate a case with such a config
	and are then referred to "Don't you read releasenotes/SPD's ?"

	The background behind that is the following:

	We had 2 cases where a VAR sold the HSZ50 with BA356 and wide I/O
	modules and we could not see any devices (RZ28D-VW) on all 6
	SCSI channels with the 16-bit I/O modules. The switches on the I/O
	where set all correctly. Swapping the 16-bit with 8-bit modules fixed
	it. The required BN21N-02 where all DEC manufactured.
	We did not further investigate, because we considered this as a not 
	supported config. Since it was a new installation, we advised the
    	VAR to look for the correct parts.

	Could someone clarify this for now and forever ?
	We really need a definitive statement here.

	Something besides this:

	The SOC from November 1996 tells in the Alphaserver 4100 section on
	page 2.131 " HSZ40-Cx requires BN21N-02 for connection from
	HSZ40-Cx to BA356R Storage Shelf".
	That leaded to the case that loads of 4100 where sold with this
	"wrong" config.

	Thanks for any clarification.

	Martin
    

    Martin,
    
    I was going to call, but there is a small time difference. :-)
    
    Yes, starting with HSOF V3.1 and V5.1 both 8 and 16bit I/O modules
    are supported. And I did review the documentation, and corrected
    some of the areas that referenced the 8bit module, its appears that
    either I missed a spot, or my input was not included... Sorry...
    
    The reason for inlcuding support in V3.1 and V5.1 is made by product
    management. While we have included both modules in testing, this is the
    first time it was part of the formal qualification process. 
    
    I still expect the 16bit to work with other versions of HSOF, but
    the SPD does limit older version to 8bit only. If there is a large
    need expressed to the product management, they may remove the
    restriction on V2.7, V3.0 and V5.0. 
    
    If you have a configuration that does not work, then something is broke.
    it should work, it does work.
    
    Regards,
    Bert
    

    
    Bert,
    
    thanks a bunch for your clarification. Thats exactly what i was looking	
    for.
    Next time when i come across a nonworking 16-bit config, i
    can/will/should put a lot more investigation into it. 
    With the knowledge that it should/does work. ;-)
    
    Thanks again and best regards,
    
    Martin