Conference 44.370::system_management

>
>		 Changes to account passwords etc. from Wednesday
>		 to Friday will not apply on the VMS V5.0 system
>		 on Monday.
>

And presumably new mail notifications will be "lost" as well?

>
>	Information Services
>

Hang on, we can't all of have written this!

Terry

    Does this imply that you think we should not go up to Version 5.0 since
    it will cause you some inconvience with your unread mail counter.
    
    The only other acceptable work around for this, is us to have the
    system down for two working days while we upgrade the live system.
    
    Regards
                 
    RISP Group
    (Regional Infomation Services Planning Group) 

>    Does this imply that you think we should not go up to Version 5.0 since
>    it will cause you some inconvience with your unread mail counter.
>    

No, not at all. Although there are potential problems with an upgrade,
as CURRNT is used to support several applications. My point was, that people
should be warned to check their mail, as VMS will not tell them
about it, immediately after the upgrade.

Terry

	What will happen to all those V4.7 applications which were moved
	to currnt, and still require V4.7 (I think there are some still
	around). ?

	The CURRNT Cluster is being upgraded as a result of a
    	request from the ADG Consultancy Group.

	We presume that this decision was made after consultation
	with all the relevant groups in ADG.  Any problems with
	this decision should be taken up with the Consultancy
	groups.

	Regards,




	RISP Group
	(Regional Information Services Planning Group)
    

    Re .3   CURRNT cluster should not be used to support applications.
    All applications supported from the Crescent should be installed on
    PASTIT not on CURRNT (or FUTURS).
    
    Re .4  Please enter an answer here if you have applications still being
    developed for VMS 4.7 systems. 
    State the size of the application (disk blocks) and the date when you
    expect to finish development. Please also indicate the
    reason why VMS V4.7 development is necessary rather than V 5.0
    
    

    For OFW V2, we are required to supply a kit that works on both
    VMS 4.7 and VMS 5. We are currently developing the software on CURRNT.
    
    The current application size is quite large due to us requiring
    larg(ish)/(e) feeders for testing (>100K blocks).
    
    We shall finish development in the near future.
    
    Upgrading the system to V5 isn't a problem so long as you don't
    mind us doing development on PASTIT also. We would require development
    accounts on PASTIT and would also need to keep the application on
    the machine after development has ceased in order to support our
    V4.7 version of the software.

    The reason for us creating kits for both versions of VMS is that
    we cannot guarantee that all sites that wish to use the new version
    of OFW will be at V5 at time of release.    
    
    
    				Jamie.

    Thanks Jamie, but can you be more specific about completion dates?

    Speak to Mike Stapley.
    
    
    
    
    				Jamie.

    Therw are currently four A & L Development Team projects that need
    to run under V 4.7, these are :-
    
    		Comand V2.0       approx   161000 blocks
    		Migration V2.0    approx   129000 blocks
    		Ofrs V1.0	  approx   76000 blocks
    		Oasm V1.0	  approx   51000 blocks
    
    We are currently in pilot in four subs, they are UK, Germany, Italy
    and France. So we cann't upgrade to version 5 until all the subs
    running pilot have.
    
    
    		Graham
    
    

       The RAM application is currently being developed under VMS v4.7.
       The application is approximately 150,000 blocks in size and 
       I would envisage RAM needing to remain under VMS v4.7 for the 
       next 2.5 weeks. 

       Hope this helps Jerry,

        Nick

    
    
    		The schedule VMS V5.0 Upgrade on CURRNT
    		this weekend 4th/5th March has been cancelled
    		untill further notice.
    
    
    
    
    
    		

    Any idea when the clusters will move up to VMS V5.xxxx ?
    
    Just curious !
    
    Rob

    Good question Rob!
    
    How about.....
    PASTIT cluster EASE V5 upgrade sometime between May 8th-19th
    CURRNT cluster V5 upgrade (EASE as well??) ASAP.
    
    Are there any objections from the ADG camp? If so please winge here,
    CURRNT objections by 26th April.
    PASTIT objections by 3rd May.
    
    
    
    
     

    I know that the plan was that all field machines should be upgraded
    during early May, but my contacts with the subs suggest that mid-late
    May and even early June are more likely in practice.
    
    Given that, then surely we MUST have at least one cluster on V4.7,
    until ALL machines in the field ( or at least all those used for
    ADG supported applications ) have been upgraded. 
    
    Don't forget that software compiled and linked under V5 will not
    run under V4.7. ( or is there some way round this ?? )
    
    Chris.
    

    I hate to use four letter words so early in the morning but,
    
    how am I going to get my 'PDPs' to talk correctly with VMS V5.0
    systems?
    
    I understand that there are some problems around V5.0->RSTS
    
    Thoughts, ideas, suggestions ???
    
    H E L P  ! ! !		:^)

re .15;

Chris, I hope that all the subs do hit the target of mid-May - otherwise
it's getting a bit too close for comfort considering EOY/BOY....

Should ADG be in the business of attempting to support an obsolete
environment for the subs? After my experiences over RSTS/E with ADG, I feel
very strongly we should not.

re .16;

Keith - the only known problem with VMS V5.0 and RSTS/E V8.0 is with
VAXen "pushing" RMS stream files onto the PDP. A simple workaround
is to "pull" the file onto the PDP. This problem has been notified
to the IS European Migration Team, along with some other options
(one of which was migrate to RSTS/E V9.6!!) No doubt we'll be notified
when the decision is made. At this time, the V5 migration is *not*
being delayed for this (or any other) reason.

Peter.

>    Chris, I hope that all the subs do hit the target of mid-May - otherwise
>    it's getting a bit too close for comfort considering EOY/BOY....
     
    So do I, but what do we do if they don't ? I have had fairly firm
    feedback from Zurich, that they will not be upgrading their DDMLS
    machine until 3-4 June. ( this was a few months ago though, they
    may have changed their position )
    
>    Should ADG be in the business of attempting to support an obsolete
> environment for the subs? After my experiences over RSTS/E with ADG, I feel
> very strongly we should not.
  
    Me too, although I feel the subs should be given a couple of weeks
    leeway, say until 9th June.
    
    If it is the policy of this group to not support a given environment
    after a certain date, then I feel that all the subs should be informed
    ( perhaps they have ??? ), so that they can take this into account.
    
    Obviously, if the change goes through before the subs have upgraded,
    it will leave support people and project leaders in a potentially
    embarrasing situation...
    
    	"You want your priority one hotline fixed ??. Are you on version
         5 yet ???....No....Well give me a ring in a couple of weeks
         when you have upgraded and we will see what we can do."
	
    All I ask is that one of the clusters is left on V4.7 until a date
    beyond which all the subs can have no reasonable excuse to have
    not upgraded. I suggest June 9th.
    
    Chris.
    

    It is DEC's policy to terminate support for operating systems six
    months after the next version has been released. If we refuse to
    support external customers, why should internal customers be
    treated differently? 

    If ADG can't upgrade within six months then 

        1. ADG compares badly to the expected norm, and/or
        2. DEC's support policy is unrealistic.


    Terry

re .18;

Chris, I'm in violent agreement that one of the clusters should reflect
what is currently in the field, i.e .PASTIT. If the field don't hit the
required *and agreed to* implementation date, is that an ADG problem?
We will obviously give any problem "our best efforts" but are we in the
ball game of providing VMS or layered product support? I always thought we
were into applications....

re .19;

Terry, the answers to internal and external customers are not necessarily the
same; our RSTS/E V8.0 cocktail is still supported by Valbonne; an external
customer formally asking for RSTS/E V8.0 would only recieve it on
a) a best effforts only basis, and
b) at full Time and Materials cost.

Unless of course they can negotiate a better deal!

I can give you a loooooong discourse on why we still use RSTS/E V8.0
internally, if you reeeeeally want!

Peter.

>Terry, the answers to internal and external customers are not necessarily the
>same; our RSTS/E V8.0 cocktail is still supported by Valbonne; an external
>customer formally asking for RSTS/E V8.0 would only recieve it on
>a) a best effforts only basis, and
>b) at full Time and Materials cost.
>

ADG have sold internal applications to external customers in the past
and may well do so again. I think it would prove embarrassing if ADG were
to say this application runs only under version A of VMS but DEC will only
support version B. Regardless of the position in the past, we must endeavour
to use officially supported version of the system software to guarantee a good
service to customers and to leave ourselves with an escalation path in case
of trouble.

Terry

>>    Chris, I hope that all the subs do hit the target of mid-May - otherwise
>>    it's getting a bit too close for comfort considering EOY/BOY....
     

	The upgrade window given to the field by Jim Kirk, and passed through 
	to the country co-ordinators, is 1st April to 31st May.
	
	31st May is mid-week, 3-4 June is the last week-end.

	Where did mid-May come from???????????

	This date also assumed we would have no problems upgrading with EASE.

	We have had problems with both VMS 4.7 EASE, and V5 Ease, and such 
	considerable problems with 20/20 2.3, that we have recommended that
	the UK stop upgrading to this version until Access Technology can fix
	some of the major bugs/problems, and agree to improve things for the 
	future.    

	Although the field hopes to hit the target date of 4 June, there may be 
	some who have been impacted by these problems, and are late as a result.
		
	Heather.

re .22

>The upgrade window given to the field by Jim Kirk, and passed through 
>to the country co-ordinators, is 1st April to 31st May.
>31st May is mid-week, 3-4 June is the last week-end.

>Where did mid-May come from???????????

Mid-May was given to me over the phone , or maybe I mis-understood the
details - I only took over as the ADG Mr. Migration recently....

Re the problems with 20/20 V2.3 - I guess this has been raised somewhere,
but I haven't been informed, and it hasn't been raised in the
RUTILE::V5_MIGRATION conference as a known problem. Is this an
EASE problem, or does 20/20 not run cleanly under VMS V5.0?

I agree that if there is a major problem with the upgrade, then
a review may be needed to decide whether to continue. But, be aware
of the potentially major support problems with running VMS V4.7 beyond
the published deadlines, unless full agreement is reached with all
the relevant parties (e.g. Area Support, Local I.S., ADG, etc.)

And of course, we all know that EOY/BOY is rapidly approaching - that's the
only immovable target date in the calender....

Peter.

    Right then, the only objection for CURRNT to be upgraded is that 2020
    doesn't work too well on EASE V5.
    
    I'm not aware of any applications software that *must* use 2020 to
    operate -please enlighten me if this is not correct - so the way is now
    open for CURRNT to be upgraded to VMS V5 (EASE or otherwise).
    
    So all we need now is someone to take the machine down for a few days
    while it's upgraded.
    
    Watch this space for dates of upgrade.

>Re the problems with 20/20 V2.3 - I guess this has been raised somewhere,

 Yes, to the European Internal Product Manager - Chris Robins, (she "lives"
 on the second floor of the Crescent) who has been negotiating these problems 
 with Access Technology. 
 We now have support from Access for 20/20 2.1 under VMS V5....until something 
 else is sorted out with 20/20 2.3.
 
 We also have confirmation from the UK Assist team that this won't affect 
 ASSIST in the UK. 
 We don't run MRE with 20/20 .... YET.

>But, be aware of the potentially major support problems with running VMS V4.7 
>beyond the published deadlines, unless full agreement is reached with all
>the relevant parties (e.g. Area Support, Local I.S., ADG, etc.)

  Our dates, and the ONLY official dates, are published to the sites from 
  Jim Kirk, he heads a committee which represent all European ADG groups, End 
  User Computing groups and Country Operations groups, and which has final say 
  on what versions are used, and when.
  The 1st April-31st May dates come from him.

  I'm quite concerned if you're not getting the same info as all the subs,
  'cause this could cause problems. Some people will not be able to change 
  their schedule of upgrades at this late date, especially sites such as 
  Germany where there are very strict Government rules about overtime working. 

  If the communication line is a bit shakey, I suggest contacting Jim, or 
  Steve Draper - who I beleive is a member of this committee.
 
>And of course, we all know that EOY/BOY is rapidly approaching - that's the
>only immovable target date in the calender....

 Oh, 'cmon Peter, how long have you worked in ADG???????

	Heather      ex_euro_support_who_remembers_ARMS_being_fixed_to_take_
		     cash_received_after_EOY_close_and_then_backdated.....
		     didn't_the_figures_look_good_even_if_they_were_late!

			:-)		     

re .25

-----------------------------------------------------------------------
>But, be aware of the potentially major support problems with running VMS V4.7 
>beyond the published deadlines, unless full agreement is reached with all
>the relevant parties (e.g. Area Support, Local I.S., ADG, etc.)

  Our dates, and the ONLY official dates, are published to the sites from 
  Jim Kirk, he heads a committee which represent all European ADG groups, End 
  User Computing groups and Country Operations groups, and which has final say 
  on what versions are used, and when.
  The 1st April-31st May dates come from him.
----------------------------------------------------------------------------

I'm a bit confused, as your comment doesn't seem to relate to the bit you cut
out of my previous note - However I think we are all in agreement on these
dates!

Are you now confirming that 20/20 will run under VMS V5.0, and is fully
supported by Valbonne, as published in VTX? Or is there still a
problem for production sites (but not our CURRNT cluster, where we
aren't making heavy use of 20/20, or if we are, there are other systems that
could be used instead) ?

Oh and by the way, we are already starting to plan the installation of
VMS V5.1 on FUTURS - more details later, as they emerge!


Peter.

As far as I know, Steve Draper is not a member of this forum - although I may
be on the grounds that nobody actually told me I was a member!!

ADG's interests on this body are taken care of by Chris Lovell (@FYO) who then
passes the info on to the Mr. Migration at each ADG site - Peter, in
Basingstoke's case.

Steve

> - However I think we are all in agreement on these dates!

	Good, this was my main concern, as I know some of our sites are not
	upgrading until 3/4 June.

>Are you now confirming that 20/20 will run under VMS V5.0, and is fully
>supported by Valbonne, as published in VTX? Or is there still a
>problem for production sites (but not our CURRNT cluster, where we
>aren't making heavy use of 20/20, or if we are, there are other systems that
>could be used instead) ?

OK, this one may have to be taken off-line, anyone wanting exact details should
contact their CSMs, (or Chris Robins) who have been given full details of the
problems found both updating to 2.3, and then running it if you manage the 
first hurdle.

20/20 is a third party product, and as such, cannot be fully supported by 
Valbonne, because they don't have the code - so can't fix the bugs.
Most people don't use Valbonne for support, they contact their local IS, or 
Access Technology.

The file naming convention has changed dramatically, you can no-longer tell the
difference between a macro, worksheet.........there are a couple of nasty bugs 
with 2.3 itself, and numerous ones with the 2.3 ALL-IN-1 interface - which is 
also copywrited by Access Technology.

Access have agreed to support 20/20 2.1 on VMS V5 (I'm not sure whether this is
just for the UK, or Europe-wide), until these problems can be resolved.

Heather.

    MRE Uses 2020 v2.3 - we were most surprised to see subs coming out
    with 2020 v2.32.11 - which expects load-files in a different format.
    
    Caused a few headaches at the time, but at least we know WHY the
    procedures fail, and WHAT to do to fix them.
    
    Now,
    	Do we tell them they're "unsupported, as they're outside our
    layered product matrix, or.........
    

    Proposed VMS 4.7 -> 5.0-2 upgrade dates:
    
    CURRNT cluster - 15-19th May.
    PASTIT cluster - Wed 7th June
    
    Service offerred by IS would mean that both upgrades would take place
    IN PRIME TIME only.
    
    PASTIT already has EASE V4.7, so it would probably be done starting at
    16:00 and be unavailable for roughly 2 hours.
    
    CURRNT hasn't been EASEified so the upgrade will probably take 3-4 days
    if layered products are included. This could be done in several ways:
    1) Whole cluster down for 3-4 days
    2) Whole cluster down for 1 day then layered products upgraded over
    next 2-3 days
    3) If hardware available -
    	take copy of system disk
    	remove single node from CURRNT cluster. 
    	Upgrade single node cluster while 2 node cluster continues
    	reintroduce single node into main cluster and reboot
    	mangle changed files together
    
    2 looks the best bet to me, but I await your comments with interest.
    

>< Note 217.30 by NECK::THOMPSON >
>                        -< V5 upgrade dates - perhaps? >-
>
>    Service offerred by IS would mean that both upgrades would take place
>    IN PRIME TIME only.
>    
>    CURRNT hasn't been EASEified so the upgrade will probably take 3-4 days
>    if layered products are included. This could be done in several ways:
>    1) Whole cluster down for 3-4 days
>    2) Whole cluster down for 1 day then layered products upgraded over
>    next 2-3 days


If either of these two methods are used, can we assume that the CURRNT data 
discs will be made available on another cluster during the upgrade? 
If this is not possible, then I'd strongly suggest that over-time be paid to 
some one from I.S. to do this. The cost of CURRNT being unavailable, for 
1500, or more, man-hours would seem considerable.

Terry

    CURRNT cluster - 15-19th May 2 hours downtime, probably 16:00-18:00
    PASTIT cluster - Wed 7th June , 16:00-18:00
    
    CURRNT's system disc will be modified so that it's EASE compatible.
    This will happen from now until the week starting 15th May. During that
    week an EASE V5.0 system will be installed on CURRNT, down time approx 2
    hours.
    
    All changes affecting CURRNT's system disk should be
    avoided from now until after the upgrade. If changes are essential then
    they MUST be planned in advance with IS system management. If you don't
    do this then a) you may put the upgrade procedure at risk b) your
    changes will be erased when EASE is installed.
    
    The progress of converting to EASE will only be possible if more
    space is available on data disks. Please check that you've deleted
    obselete files.