Conference evms::y2k

Here are 5 reasons for not conducting a Year 2000 due diligence on V5.5-2.

1_	We have limited resources (particularly time and people).
	If we want to keep the needed level of accuracy and quality required
	by this effort, we have to focus on V7.1 and V6.2.
	Addressing V5.5-2 also is an extremely difficult and expensive goal.

2_	We are not dropping support for V5.5-2 NOW.
	Instead, we are recommending customers to plan for upgrading a product 
	that will be 9 years old (that is close to say obsolete) in 2000.

3_	We are not dropping support for V5.5-2.
	Instead, we are simply saying that we do not want to commit to
	providing a complete due diligence effort for Year 2000 isuues on 
	V5.5-2.

4_	A customer relying on V5.5-2 is a lost customer for OSSG anyway.
	OSSG cannot get anymore "real" revenues from him/her.
	The biggest revenue here is coming from service contracts, but OSSG
	gets only a part of it.
	Since MCS owns the business of service contracts they may want to
	fund an effort on V5.5-2. But this effort cannot be performed in 1997,
	it may be done in 1998 or 1999.

5_	one of the main resons for a customer staying with V5.5-2 is the 
	presence of a mission critical application running on this platform 
	that a vendor does not intend to port to more recent releases.
	But in this case, having V5.5-2 Year 2000 ready does not solve the 
	problem, because it is highly unlikely that the same vendor is willing
	to spend time and resources in conducting an investigation of the same
	application that they don't want to spend time and resources in porting
	to other releases. 

Even if we provide some year 2000 support on V5.5-2 via a Due Diligence,
what aboyt all the layered software?

MCS is currently supporting the following products in the Previous Version
support program. Are they enough?


OpenVMS		V5.5-2		V6.2
---------	------		----
DECnet IV	V5.5-2		V6.2
DECnet-Plus	 ---		V6.3
DW Motif	V1.2-3		V1.2-3 (non-English)
		V1.2-4		V1.2-4
TCP/IP		V4.0		V4.1 or current if it runs back to V6.2
PW (LanMan)	V5.0		V5.0

What about all other software, from All-in-1 to compilers, etc.?
IS it possible to identify a minimal meaningful set?

    I don't want to start a rat hole on why customers don't upgrade, but
    some customers do not upgrade because of the sheer effort involved in
    upgrading for no perceived benefit.
    
    I work with a customer who has somewhere in the region of 400 systems
    (mainly microVAX 3100s and VAX 4000 500s, 505s, 105As 106As)
    Even though these systems run exactly the same software, you can
    imagine the effort involved in upgrading these systems, which are
    spread across the UK. They are all running V5.5-2H4
    
    Two years ago, I would have been saying that the customer had over 2000
    systems running VMS V5.2-1.
    
    They only managed to get a business justification for the effort and
    cost involved in replacing 2000 Q1 microVAX systems because of the
    lower maintenance cost and increased reliability of the newer hardware.
    
    Now that the customer has gone through that, there is no business
    justification for moving to a later version of VMS. The systems do what
    they want, there are no major enhancements done on these systems.
    
    To this customer, attempting to justify upgrading on the basis that
    DIGITAL has decided to no longer provide support for V5.5-2 would be
    like a motor manufacturer making parts unavailable for a particular
    model of car.
    
    I do see the point about where the majority of the revenue goes, but
    that's internal DIGITAL politics. The customer should not need to
    suffer because of that. Perhaps there's a way of doing it through prior
    version support.
    
    Having said all that, I think it would be an excellent idea if this
    customer did upgrade to VMS V7.2 and I will do all I can to persuade
    the customer that he should.
    
    Graham

Some customers are concerned about upgrading from 5.5-2 because of the specific 
hardware that they are using.

The only explicit example that I have is UNIBUS.

I would like feedback on how important this issue is, and any other possible
example.

thanks,

	Vittorio

Another issue with the 5.5-2 year 2000 support has been reported being
the large number of patches and TIMA kits produced over the life of V5.5-2.

What code are we going to investigate? It would make sense to conduct the 
investigation on the base code plus all the patches.
But at this point many customers will have to install *ALL* the patches 
distributed so far, and this may mean that some customers may have to 
perform serious maintenance, including reboots, activities that they may 
want to avoid.

Is this an issue?

   If we decide to not ECO V5.5-2, we need to start sending this information
   out to our customers now, and we should expect to hear a number of loud
   objections voiced to this policy.

   We are presently getting 10K delta-time patch requests back as far as
   VAX V4.x and Alpha V1.5, and we are running into sites at power plants
   and steel mills -- these folks need time to migrate off OpenVMS, or to
   migrate to a current release, or they need a Y2K ECO kit.

   10K is actually a fairly minor problem -- Y2K is going to be viewed
   (correctly or otherwise) as a rather larger problem than 10K.

	--

   If we choose to back-port the Y2K ECO kits to specific older OpenVMS
   releases, we should also expect to perform integration of various TIMA
   kits into a few "super TIMA" kits that include Y2K ECOs and other
   associated fixes, and then have these ECO kits verified by QTV.  (In
   many cases we will have no choice here, as many customer sites are
   already running extensively patched releases of OpenVMS, and we will
   not be permitted any regressions -- we have to check the existing TIMAs.)

	--

   It might be less of a headache for us to simply authorize our customers
   to perform an OpenVMS upgrade to the current release for the cost of the
   necessary media kits.  (This certainly won't solve all our customers'
   Y2K problems, but it will make us look a bit better overall, and it will
   reduce the eventual engineering load that should be expected should we
   not have Y2K ECOs available for most key OpenVMS releases.)

   In other words, target the Y2K ECOs for specific releases -- V5.5-2H4
   on VAX, and V6.2 and V7.1 on both, for starters -- and encourage
   customers to upgrade to these releases at little or no cost.  This
   may also lower our support costs -- though yes, we don't get the
   revenues from the upgrades.

	--

   The full-blown Y2K evaluation, and the initial ECO release can be based
   on V7.1, but we need to have our plans in place for the other "lesser
   evaluatation" releases at the time we start talking publicly (seriously)
   about the Y2K ECO.

    re .last few
    
    These notes seem to have gone off the topic a bit.
    
    The base note started out discussing the question "should we
    investigate V5.5-2 for compliance". This is quite separate from "should
    we backport to V5.5-2 the fixes for any Y2K problems found in the due
    diligence effort for some later release and fix any known Y2K problems
    that are specific to V5.5-2".
    
    From a practical standpoint I believe our position has to be that we do
    not verify and claim compliance for V5.5-2 but on the other hand the
    installed base figures suggest that it would not be reasonable not to
    supply fixes for the earlier version providing that customers are
    prepared to pay for the earlier version support. With over 2 years to
    go surely some kind of revenue arrangements can be made within Digital.
    
    In the final analysis then the business justification for any customer
    considering upgrading is the risk that there exist unknown Y2K problems
    that will be discovered after 31-DEC-1999 (or in any case too late to
    fix before the day). There is a cost in upgrading and there is a cost
    if their systems fail horribly. Their choice... With over 2 years to
    go, if we communicate our position _now_, 99% of customers (figure
    extracted from the atmosphere) could upgrade if they wanted to.
    
    From what I've seen of the known Y2K issues in VMS most customers
    running any version of VMS will not be affected. Application failures
    are much more likely and Digital can't do anything about that.

    re .3:
    
>    Even though these systems run exactly the same software, you can
>    imagine the effort involved in upgrading these systems, which are
>    spread across the UK. They are all running V5.5-2H4
    
    What I can't understand is why it is perceived that an "upgrade" to
    a new release is somehow more traumatic than applying an ECO which,
    in essence, achieves the same purpose. This is especially true of
    the kind of "super ECO" which would be necessary if Digital were to
    be forced to give a firm committment that it resolves "all Y2K
    problems".
    
    Certainly this effort will not be trivial, but that's just one of the
    costs of running computer systems. It would be the same (or, possibly
    worse) with any other brand of hardware or software. On the other hand,
    if the customers systems are unaffected by Y2K issues, they don't need
    to upgrade at all. But, they can't have it both ways TANSTAAFL.
    
>    DIGITAL has decided to no longer provide support for V5.5-2 would be
>    like a motor manufacturer making parts unavailable for a particular
>    model of car.
    
    It's not that the parts are "made unavailable", but there comes a time
    in the lifecycle of any product that it becomes uneconomic to continue
    to *produce* parts. The pool of available parts then gets smaller and
    more expensive. Try to purchase door panel for a (say) 1960's model
    car...
    
    Digital spends money on correcting and improving our software. These
    changes are made available to customers in a form which is tested and
    supported, called "releases". If customers choose not to avail themselves
    of these mechanisms, that's their problem. They cannot expect Digital to
    bear additional, non-revenue producing costs, just because *they* are
    not prepared to bear the costs of maintaining their systems. 
    
    On the other hand, if the customer is prepared to *pay* enough money
    for backports that it is worth Digital's while to perform them, it
    may be possible to convince engineering to take their money. However,
    I doubt this would be cheaper than just upgrading along the tried and
    true paths.
    						John Gillings, Sydney CSC
                                                                          

    Re: .-1
    
    It took 18 months for this customer to sufficiently test all his
    applications on V5.5-2H4.
    
    This is a system used by around 50000 users (they have 6500 terminal
    servers!), so it is not surprising that the customer is concerned about
    introducing problems. For example, during an early pilot with a few
    hundred users, a problem was discovered with the newer version of LAT
    imposing a stricter compliance with the LAT specification, resulting in
    problems when one user on a DS200 switched off their terminal (other
    users on that same terminal server to the same VMS system were
    disconnected).
    
    We are still seeing new problems even now 4 years later : an
    interesting one where the audit server and LAT rating algorithm
    calculation get into sync, resulting a very much depressed LAT rating
    for no aparent reason and terminal typahead buffers not always being
    deallocated are two recent ones that spring to mind.
    
    The customer wants a stable system. The longer he stays on 5.5-2H4, the
    more stable it becomes. To move to 7.2 could result in instability and
    a rise in the number of fault calls from the users (his internal end
    customer). In his organisation senior managers are goaled on low
    numbers of faults. They don't get many chances.
    
    Now, for this particular customer, I think the way round the effort of
    an upgrade is that they will have to perform significant year 2000
    testing, so they might as well do it on VMS V7.2 as 5.5-2H4.
    
    Graham

    Given the version percentages presented, I wonder what the market
    would be for a V5.5-3 release ("all" known fixes, Y2K, etc).

Sell the sources and let someone else make a couple of bucks supporting these
folks forever.  Perhaps Mentec would be interested?

    Getting back to the basic question, are there systems that can't be
    upgraded.  Yes!  Granted most of the reasons are economic, but the
    numbers can become very large when the cost (to the end user) of
    changes in documentation, testing, and new hardware is considered.  For
    example one custome system (owned by US Govt) is running custom UNIBUS
    hardware that in an interface to yet another custom card on both IBM
    and UNIVAC computers.  There are plans to replace this link, but no
    money until 2005.  So no upgrade until 2007 or so.  
    
    For this customer, 7.1 is not an option, as the system is a 780, which
    is not supported by 7.1.  A hardware upgrade is even more expensive,
    due to the costs to change the documentation and associated testing,
    not the cost of the kits and/or changes in their application. 
    
    I have another customer that is slowly migrating off of VWS and VMS
    5.5-2.  For them the expense to move to Motif was rather large, and
    will take time.  This customer is turn must then sell their customer on
    the need to replace functioning hardware with newer hardware for no
    preceived added value.  Thus the cost to the end user will be smaller
    for the patch than for a new (and not needed) system.  
    
    In a third case, a customer has 28 sites each running a 2-node cluster 
    of FT410s.  They are also stuck on VMS 5.5-2 as the FT services have
    been sold and not (to my knowledge) updated.  So what is this customer
    to do?  There is no upgrade/migration path for them at this time.  And
    given the criticallity of the system, there is not time to replace it
    before Friday Dec 29,1999.  However there is time to TEST what they
    have, and help them correct any problems.
    
    So what can we do?
    
    I would propose that NSIS working with VMS Engineering test and ECO
    selected prior versions of VMS.  NSIS would then sell this kits with
    some Y2K consulting to these customers just like any other upgrade
    only make some direct revenue for time and effort expended.  The goal
    would be to charge less than the cost to upgrade to 7.1 from any
    previous version.  If the customer is on 3.7, then the ECO for 3.7
    would cost more than the ECO for 5.5-2, as more kits and licenes would
    be needed.   
    
    Don..
     
    
    To keep the cost to engineering down, I would further propose that some
    of the revenue to NSIS be passed back to engineering to be used to hire
    contractors to perform the work.  
    
    	Don..

   Building ECO images for antique versions of OpenVMS gets to be quite, uh,
   entertaining.  We have to switch to the old source code control libraries
   to get to the older V5.* sources for the older 10K patches, and we must
   use the older build environment, etc.

re: .10   ("all" known fixes, Y2K, etc).

how about renaming V7.2 to V5.5-3 ?  :-)

Actually, I like the UNIX group's move to retire all versions before V3.2G.
I grant you it's easier to get their installed base to upgrade.

Mark

Re: .8

�    What I can't understand is why it is perceived that an "upgrade" to
�    a new release is somehow more traumatic than applying an ECO which,
�    in essence, achieves the same purpose.

There are two reasons why the application of an ECO not only is perceived
cheaper, but definitely *is* cheaper than upgrading to a new version - possibly
spanning a few intermediate versions.

First, as has been mentioned before, thorough application testing is required
before an upgrade to a new OS version (and associated layered products). One of
the previous replies mentioned 18 months of testing. I've personally spent
several years in a group which engineered and supported internal applications,
and I've helped and coordinated our groups qualification efforts before the our
European datacenters could upgrade OpenVMS and layered products. Although we got
an "impact document" which saved us considerable labour it still was a lot of
work to test and fix the applications under various environments (install,
reconfigure, upgrade the application, ...).

Ususally, this effort is not required for an ECO, because it fixes a particular
problem - in most cases with no or minimal side effects. A new version of
OpenVMS contains new features, completely rewritten components etc. which
largely increase the chance that at least some undocumented behaviour changes,
so the compatibility tests are required.

Second, the implementation differs by a factor of 10 or 20. Even a big ECO which
replaces two or three dozens of images can be applied in a couple of minutes
even on a MicroVAX II, probably followed by a reboot (which can be postponed in
many cases). A VMS upgrade takes considerably longer, given the several phases
it executes (create an upgrade system root, copy stuff around, clean up behind
yourself, apply the new version, switch back to the original root etc.),
including at least two reboots. On older equipment an upgrade easyly takes
between two and three hours, without layered product upgrades which might be
required. And I'm not even talking about disk space requirements for the OpenVMS
upgrade which may require to load some applications directories off the system
disk during the upgrade and get them back afterwards. Then, multiply the time
difference by 50, 300 or more.

Today, we are used to have more memory and more disk space in an average home PC
than we had in a MicroVAX II, 2000 or the early 3100s which still serve their
purpose if used in an stable environment. The examples in the previous replies
show that - in many cases - customers are not just too ignorant to upgrade.

In my eyes, it is rather short-sightened (?) to classify the effort to produce a
patch for V5.5 or earlier as 'non-revenue producing'. When it comes to the
selection of hardware and operating system for new applications, the ability
*and* willingness of the manufacturer to support his products over time are an
important factor for the decision. While it is true that the V5.5 license has
been sold long ago, the customer payed the price because he expected solid
support from a company like Digital. The fact that we do or don't support old
releases in the Y2K effort may influence their next buy decision.

Having said all that, there is another category of customers beside those who
can't (easyly) upgrade: many customers only want an official statement from
Digital about what will and what won't work on Jan 1, 2000 so they can decide
whether they need to plan for upgrades (budget- and labourwise) or whether they
are safe. For them, it makes a lot of a difference whether we say "we don't
know" or "feature foo / component bar will break".

Thanks for listening,
Hans.

re .12:

>... the system is a 780, which is not supported by 7.1.

But it is supported by V6.2 which will be Y2K ok, yes?

:In my eyes, it is rather short-sightened (?) to classify the effort to
:produce a patch for V5.5 or earlier as 'non-revenue producing'.

   Yes, you're entirely correct, but there's more to the decision...

   Do we spend our time and effort doing ECOs for very old releases,
   doing ECOs for more recent releases, or introducing new things for
   us to ECO?  � :-)  

   And after the ECO kit is created, one must integrate the fix back
   into more recent versions -- the further back one creates an ECO,
   the more involved this "anti-regression" process can become.

   And then there is the nightmare of ECO testing -- one often finds
   ECOs become interdependent, and one finds interesting problems
   when random ECOs are applied and "collide".

   OpenVMS is presently set up to ECO as far back as V5.5.  Setting up
   to ECO older releases is certainly possible (depending on how much
   time and effort we want to expend), but it gets more "interesting"
   the further back in time one goes.

    
    This is my first visit to this notesfile.  It is a result of audits
    being performed on two of my larger OpenVMS customers which are running
    are running V5.5-2 on some of their systems.  The reason for not upgrading
    is the legacy applications do not support current versions of OpenVMS or 
    the application has been so stable that they don't feel there is need to
    invest the time.
    
    I don't agree or disagree what is the right thing to do regarding testing
    year 2k issues on OpenVMS 5.5-2 but I am concerned (so is the customer)
    about our consistency.  A few months back we announced prior version
    support which included 5.5-2 and 6.2.  We said there were so many
    systems out there running these versions which had no need to upgrade,
    that we would continue to provide support for these versions for a long
    long time, ignoring the rule that we don't provide support more than 2 
    versions.
    
    Even though there probably are no operating systems issue and any 
    issues are within the application, the message the customer gets 
    from all this less support for OpenVMS.

:                                                      -< concerned customer >-

:    I don't agree or disagree what is the right thing to do regarding testing
:    year 2k issues on OpenVMS 5.5-2 but I am concerned (so is the customer)
:    about our consistency.  A few months back we announced prior version
:    support which included 5.5-2 and 6.2.  We said there were so many
:    systems out there running these versions which had no need to upgrade,
:    that we would continue to provide support for these versions for a long
:    long time, ignoring the rule that we don't provide support more than 2 
:    versions.

    These "prior version support" contracts are extra-cost contracts.
    The support policy itself has not changed -- the current version,
    and the previous version (for up to a year) is supported under a
    standard support contract.  Beyond that, specific older versions
    and products are supported only with a "prior version" contract.
    See http://www.digital.com/services/mcs/mcs_support.htm for details.

    Some folks expect a full evaluation for Y2K compliance, and this is
    underway.  This is a large project, as it involves checking the entire
    source pool.

    We must complete this evalation work before we know all of what we need
    to ECO -- if we need to ECO much of anything.  Once we have this ECO in
    place for a V7.1-based release, then we can see how difficult it will
    be to backport the contents of ECO, and then we can make decisions on
    what releases we will backport to.

    We have some specific deadlines for when we will have a Y2K compliant
    release, and these dates are well before 2000.  Once we have the Y2K
    compliant release (or the Y2K ECO kit) understood, documented, and
    underway, *then* we can start looking at backporting the fixes to older
    releases.

    I seriously doubt we will make any "Y2K compliance" statements for older
    releases, but I expect certain older releases will have ECO kits available.

    --

    The bottom -- and oft repeated -- line:  the customer *must* test.  The
    customer *must* test.  There is *no* way around this need for testing,
    if the customer wants to be assured their own systems will continue to
    operate.  (Vendor "compliance" statements are something likely thought
    up to keep lawyers occupied :-) -- even with a vendor Y2K compliance
    statement, there can be some snippet of local code key to the whole
    customer environment that could fail at the year 2000.)

    --

    I and others here in OpenVMS engineering definitely understand the
    customer's concerns on older releases, having just come through the 10K
    delta-time ECO.  Right now, we are not currently in a position to comment
    on nor promise ECOs for older releases -- we've got our hands full with the
    whole Y2K evaluation process.  (We may end up remastering some older
    OpenVMS releases if we provide a Y2K ECO kit, given the age of these
    releases and given the number of overlapping ECOs present for these older
    releases, and given the testing requirements.)