Conference 44.370::system_management

    Re: .0
    
    Ian,
    
    I think you'll find that because there's a two month window for the
    field to migrate to the new EASE platfrom (and some of 'em even miss
    this!) that we do not upgrade PASTIT until the end of the window.
    
    While you can have subsidiary A running EASE V5.4-2 on 1st. January
    1992 you'll find that this will be supported from CURRNT. Subsidiary B
    may not upgrade until 28th. February 1992 (or later) and so we keep
    EASE 5.4-1A on PASTIT to support them in tandem.
    
    In addition to this it is possible that if the EASE 5.5 platform is
    agreed upon and available it could be installed on FUTURS allowing any
    development for July 1992 and after to progress at the same time as
    well - I know what I mean - I think.
    
    Comments?
    
    Keith.
    

Keith,

The idea is to keep the single cluster at the lowest level until the final 
upgrade date (as pastit now) but test your appications on say ADGTST. Thus, 
they will effectively be covered for the whole of the EASE window.

So, combine PASTIT, CURRNT and FUTURS and have ADGTST for testing.

Why not reduce the EASE window at the same time. 

We must be able to save a couple of quid by clustering the macnines.

Mark

re .2;

if you keep everything at the lowest level, how do you handle development?

Today, we are developing for RDB V4.0A on FUTURS.

In March or April, we'll have VMS V5.5 on FUTURS, with a new batch/printing
system which is incompatible with V5.4-1A.

My personal view is that the four cluster model we have evolved today
is reasonable, but there is always scope for reviewing and improving 
what we are doing.


Now that we have EASE, maybe we could consolidate down to two clusters,
as we currently always have two clusters running the same version
(either FUTURS/CURRNT or CURRNT/PASTIT). We do this mainly for support
reasons; maybe we can review this and modify the model.

Any input from Support on this?

Peter

P.S. how on earth do you spell incompatible anyway? Is this right? It 
doesn't look it?

    I always thought you could run _different_ version of VMS on different
    nodes in a cluster� - this wouldn't be as easy as Ian's sujestion of a
    single homogeneous cluster but it would improve uptime.
    
    	Rik
    
    �Since 5.2'ish

>Why not reduce the EASE window at the same time. 


	Any suggestions on how to migrate 70+ machines/clusters in one
	location, in less than 8 weekends, during EOY/BOY and still keep the 
	business going, are greatfully received.


	Heather

>	location, in less than 8 weekends, during EOY/BOY and still keep the 

You migrate during end of year?

Make bigger clusters hence less upgrades.

Mark

    One thing I could never understand is why migrate during end-of-year /
    end-of-quater (And why have an end of quater over christmas / EOY near
    to 4 July) ``I'm afraid America is on holiday this week, please call
    back later. Have a nice day.''
    
    	Rik (Not entierly in gest)

re .3 Peter,

You say that today we are developing using RDB V4.0A but only for a maximum
of 4 months when by which time PASTIT will be running the same version.

Does this 4 month lead really buy the project much ? Are the new features
(ignoring bug fixes for now) *REALLY* necessary for development. You almost
certainly did the design more than 4 months ago without knowledge of any of
the new features that could be utilised.


You also mention VMS V5.5 with the new batch/print sub system not being
compatabile (sp?) with 5.4-??. I don't think VMS engineering have ever
supported downwards compatibility. Do you mean it to be the other
way round ?


Sticking with slightly advanced product versions for a minute. Say, for example,
a project finished early. By using the new features/versions this product
could not be released for some time, until the start of the migration
window. This may contain multiple bug fixes that required major database
reorganisations, impractical as a patch release, which solves many of the
customers outstanding problems.

I still have not been convinced that one cluster (barring test machines)
is inadequate.

Ian.

>You migrate during end of year?

	The summer upgrade window is July/August. EOY/BOY , depending on
	application, is anywhere between mid June/August (the first EOM is
	quite interesting sometimes!)

	The business think it's much less risky for them to upgrade after
	their application EOY/BOY, than before. Also, they would rather
	the upgrade Jan/Feb after the eo6months/bo6months than before.

	
	
>Make bigger clusters hence less upgrades.

	But their would be more applications and more chance of failures, so
	we would upgrade less each weekend........chicken and egg?


	Heather

re .4; yup, you can run a mixed-version cluster (used to be called
a rolling upgrade) but than means you use the "old" way, until the
"new" way is everywhere.

It also means that you use the "old" databases, etc..... 

re .5; .6 and .7;

the migration windows were decided "by the business", not I.S. or ADG.
The customer wanted it then, so that's when they get it.

re.8; the new batch/print subsystem is not compatible with the existing
one. You can run the old one on V5.5, but you should migrate....

Re RDB V4.0A et al; we should know the new stuff coming down the line, and we
should be designing for new features. We also are able to run this new
stuff on SBPEXE and it's satellites, so we have an extra test bed available.
For example, SBPEXE is running VMS V5.4-3, and will be going to V5.5
in the near future, after we have tested it on one or two systems.

  >Sticking with slightly advanced product versions for a minute. Say, for example,
  >a project finished early. By using the new features/versions this product
  >could not be released for some time, until the start of the migration

Hmm, this could easily turn into a good reason for us never to migrate...

Peter.