Conference ssdevo::hsj40_product

This was a typo.  There are only Rev A and Rev C boards (Per product management)

To address the issues in .0:

1.  The Release Notes "mis-spoke" about the supported controller and
    cache module revisions.  HSOF V3.1 supports:

	o  HSJ30/40-Ax and HSJ30/40-Cx controller modules (there was
	   no HSJ30/40-Bx controller)

	o  Version 1 and Version 2 (hardware revision A and B) cache 
	   modules

    The information is correct in the SPD.

2.  Tables 1 through 4 in the HSJ30/40 Release Notes apply to V3.1.  The
    sentence indicating that these tables describe V5.1 is a typo.  The
    information is correct in the SPD.

3.  Regarding the question on the shutdown in the software upgrade
    process for dual-redundant configs:  The shutdown step was
    explicitly defined in the V3.1 installation procedure to clarify
    the correct process.  This step ensures that a "clean" upgrade is
    performed in which no problems with cache or RAIDsets can occur. 
    The clarification was added in response to a problem seen at an EFT
    site in which an incomplete shutdown led to subsystem problems after
    the upgrade.  Both the 2.7 and 3.1 upgrade processes require a brief
    period of controller unavailability.

Karen Moe
Array Controller Revenue Products Software Engineering

    
    This asks for more questions:
    
    (re .2, bullet #3)
    
    Does this mean that if NO writeback-cache (or raidsets) are used
    we can get away with:
    
    A)	just depressing both PCMCIA-cards, enter 2 new ones, and take care
    	that SHADOW_MBR_TMO is set high enough (as we used to do on 2.*?)
    
    	Or:
    
    B)	run a proper shutdown on both controllers, replace the cards and
    	restart both controlers (same SYSGEN parameter care?)
    
    	instead of
    
    C)	(quote from HSOF V3.1 release notes, page 22 and 23)
    	"Before upgrading the controller software, prepare the host system
    	for this situation, by either dismounting units or by shutting down
    	the system", and all the funny nofailover/nopath_a_b stuff that
    	follows this quote?
    
    	I am talking vax/axp vms on CI-clusters here. Any insight VERY
    	welcome, since the quote under C) is an HSOF-upgrade "show-stopper"
    	in my opinion. 7X24 hr clusters used to get upgraded on-the-fly
    	during the not-so-busy hours, and 99 out of 100 without any
    	problems. The quote in C) makes this job a Saturday-evening job,
    	because of the cluster-down requirement. I will have this
    	opportunity probably twice in a year. Got some 50 HSJ's running
    	in some 10 different CI-clusters. Will cost me 5 Saturday-evenings.
    
    
    		Cheers,
    
    		Bart Rietkerk-MCS Hoogeveen-Holland.

    
    This entry is going very silent...
    
    Anybody in the know that would care to elaborate on my question in
    the previous reply? I thought my query was relevant... But maybe
    to hopefull. If the answer is "NO" it would be nice to know as well
    (even if it is not what I am hoping for)
    
    	Thank you in advance!
    
    	Bart Rietkerk

I doubt that there is anyone who wants to have their feet held to the fire
if they are wrong on this subject!  If your system crashed and you lost your
data I am sure we would hear about it.. The release notes were carefully written
to cover the worst case (writeback cache).  I am sure that storage will 
recommend that you use that procedure (period!). With a read cache what you want
to do should be safe 99.44% (the ivory soap case ;-.}). if the operating system
does the right thing (which VMS seems to do with the same or better 
reliability) everything should be ok.  The problem is that if you are in the
middle of a device write the data on a block (or set of blocks) you may not
get what you expect.  Since the transfer was not confirmed to the operating
system it is supposed to retry the transfer and the resultant data until
that transfer is retried is either the old data or the new data.

The release notes encourage you to get everything into the most stable state
so you know where you are when something goes wrong and you can go back easily.
I guess they probably should say you should backup all your data first!

Clean shutdown is always the best way to go.  Developers and others don't
always worry about the wrong result because we don't usually care about the
data on our test clusters/systems but we try to do the right thing for 
the customer.

What would I do???  I am a developer so don't ask me!!!

    
    Rigth.
    
    At least that's something. The percentage you named is even better then
    the percentage I mentionned, so from that point of view the update to
    3.1 on a VMS system is even smoother than before ;-))
    
    Anyway, the impression I get is that nothing fundamental has changed
    technically. The only thing that has changed is the commitment from
    CXO in the releasenotes about what you are supposed (guaranteed) to
    get away with when doing updates. So I'll start with a development
    cluster over here, do a decent shutdown on both controllers, do it at
    a moment when there is not a lot going on. And I won't play any tricks
    on writeback HSJ's.
    
    I know I am on my own doing this (this is a new element).
    
    Let me put my concern in other words: From a formal (supported)
    functionality point of view the latest HSOF-version (3.1) lacks a much
    appreciated feature: on-the-fly firmware updates! What a pitty, the
    latest version is NOT the greatest on this specific point.
    
    	Cheers,
    
    	Bart Rietkerk.