[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ssdevo::hsj40_product

Title:HSJ30/40 Product Conference
Moderator:SSDEVO::EDMONDS
Created:Tue Jul 13 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1264
Total number of notes:4958

1255.0. "HSOF V3.1 Release Note Queries " by KERNEL::LOANE (Comfortably numb!!) Tue May 20 1997 06:38

    The  Rev P01 HSOF V3.1 Release notes state that HSJ30/40 -Bx and -Cx 
    controllers are supported...are  HSJ30/40-Ax  controllers  supported 
    (if they even existed)??

    The  Release  Notes  also  state that V2 Cache modules are supported 
    (Hardware rev A or B);  since  there  is  no  mention  of  V1  Cache 
    modules, does this mean they are:-
     - Not Supported (and will not work)
     - Not Supported (not qualified, so they MAY work)
     - Supported (and it was a typo)

    The Device Support Tables (1 through 4) discuss  the  support  under 
    HSOF V5.1....is this table valid for HSOF V3.1 or V5.1??

    Could   someone  explain  why  the  Dual  Redundant  config  upgrade 
    procedure (page 22) requires that  both  controllers  are  shutdown; 
    this  is  totally  different  from  previous  (simple) upgrades, and 
    appears to be causing concern for some of our Customers'  "non-stop" 
    operations.
T.RTitleUserPersonal
Name
DateLines
1255.1Typo needs to be fixed... Holdover from HSZ'sSSDEVO::RMCLEANThu May 22 1997 15:051
This was a typo.  There are only Rev A and Rev C boards (Per product management)
1255.2response to questions in .0SSDEVO::MOEKaren Moe / Array Controllers Revenue ProductsFri May 23 1997 15:5230
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
1255.3Many thanks Karen (& Ron)KERNEL::LOANEComfortably numb!!Fri May 23 1997 19:290
1255.4Another try...IJSAPL::RIETKERKBart Rietkerk-Hoogeveen-HollandTue May 27 1997 12:0137
    
    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.
1255.5any reply?IJSAPL::RIETKERKBart Rietkerk-Hoogeveen-HollandWed Jun 04 1997 10:1611
    
    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
1255.6Read the release notes ;-.]SSDEVO::RMCLEANWed Jun 04 1997 14:4123
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!!!
1255.7Understood!HLSW01::RIETKERKBart Rietkerk-Hoogeveen-HollandThu Jun 05 1997 11:1525
    
    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.