[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | system management communications forum |
|
Moderator: | CHEST::THOMPSON |
|
Created: | Fri Mar 21 1986 |
Last Modified: | Thu Jul 08 1993 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 490 |
Total number of notes: | 2018 |
35.0. "The Software Upgrade debate starts again!!" by RDGE00::HAYES (Ian Hayes, ext. 4992) Thu Oct 09 1986 10:37
New European IS plans for the next round of software upgrades...
From: GABRIEL JIMENEZ
FUNC: ISOP-RESOURCES PLNG
ADDR: GEO
TEL: 821-4661 <77166@DECMAIL@GVAML2@GEO>
We plan to migrate all European production machines to VMS V4.5.
You'll find attached the minutes of the last project meeting, for your
information.
If you have any questions or comments regarding these plans, please
feel free to get in touch with any of the following people, all
members of the project team :
Margaret Carpenter - ADG, GVA
Pierre Roblin - Rel. Mgmt, FYO
Gabriel Jimenez - ISOP, GVA
NOTE to country managers : Could you please ensure that there are no
conflicts with locally developped applications and/or with the users.
Please could you confirm to me that the date of Feb 13 - Mar 16
doesn't cause you a major problem.
-------------------------------------------------------------------------
08-Oct-1986
Subject: VMS V4.4 and Cluster Upgrade Project - status
1. According to the two experts invited, Jeanine Lambert and John Shade,
there are only 2 known bugs in VMS V4.4, one in DBMS and one in BASIC
Run time library. Both are under control.
The decision was taken to migrate to VMS V4.5 because :
- VMS V4.5 is a bug-fix of VMS V4.4
- The V4.5 release date doesn't impact our plans.
2. An extract of technical documentation is being prepared by Pierre
Roblin and will be sent to ADG groups and datacenters.
3. There will be no special recommendations as it seems that no
particular problems are expected.
4. It is foreseen that each ADG group will have to test, in a cluster
environment, each one of the applications they own using the products
shown in the "Frozen list of VMS V4.5 migration products" here below.
This task should start and be completed as soon as possible in order
to be able to plan or re-plan this project.
Per application, there are three different cases that have been identified
which are significant for the project team :
a. The application runs as it is. No modification needed,
(maybe some kind of recommendation will be issued).
b. The application needs some modification. A new kit will be
made available according to target dates.
c. The application is impossible to migrate or to make it run
in a cluster environment.
5. The local applications have always been an issue during any migration
process. The local development organisations must be made aware of our
plans.
ACTION : Gabriel to communicate our plans to the country managers.
6. PROJECT PLAN, TARGET DATES :
- DECEMBER 26th - based on testing, ADG knows and communicates
to the project team if the applications they own will run as they are
or will need modifications (new kit or procedures to upgrade).
- JANUARY 30th - All new kits and/or procedures are in the
hands of Release Management for installation testing.
- FEBRUARY 16th - All new kits and/or procedures are available
for distribution to datacenters.
- FEBRUARY 16th to MARCH 13th is the "migration window". All
datacenters must have completed the migration by March the 16th.
Best regards.
------------------------------------------------------------------------
7. Frozen list of VMS V4.5 migration products
Product Availability
------- ------------
VMS V4.4 (pre-requisite)Available
VMS V4.5 October
BASIC V3.0 October
COBOL V3.3 available
C V2.2 available
PASCAL V3.4 October
FORTRAN V4.5 Available
PL/1 V2.4 available
RDB V2.1 September
DBMS V3.1 September
ADA V1.3 October
CDD V3.3 September
ACMS V2.0 Available
TDMS V1.6 September
FMS V2.3 available
DATATRIEVE V3.4 available
DECGRAPH V1.4 available
T.R | Title | User | Personal Name | Date | Lines |
---|
35.1 | This should stir it up! | RDGE43::KEW | Jerry built systems | Thu Oct 09 1986 12:44 | 21 |
| Triffic!
We are developing SIM, with DBMS 2.2 and VMS 4.3 to go into production
under VMS 4.5 and DBMS 3.1. We need to have access to the features of DBMS
V3, apart from anything, because of its cluster handling. DBMS v 3.0 is
fault laden. DBMS 3.1 requires VMS 4.4 as a minimum.
ADG has a cluster reflecting today's state of IS machines, but we are
developing for tomorrows state.
Proposal:
'De-couple' the cluster, into 2 machines and one, with the one machine
running the latest versions of layered products. That machine to be used by
those teams developing who require such a resource.
Just saying NO to this proposal will not make this problem go away.
|
35.2 | Yes and No | RDGE43::HAYES | Ian Hayes, ext. 4992 | Fri Oct 10 1986 10:00 | 16 |
| I agree that we should have some computer resource to use for running
the latest version of software to cope with this situation which
seems to arise about once every three months!
I disagree that we should start dismantling what we have worked
so hard to get (some of us more than others - thanks Vicky + Steve).
Rather we should get additional resource to provide this service.
The hardware strategy proposed by the consultants yonks ago had
in it an R&D machine which would have been used for precisely this
purpose. What a shame it never materialised.
We should not 'make do' with what we've got - it is barely sufficient
as it is. Rather we should make strong representations to get the
extra that we need to ensure that DEC'S business applications don't
go down the tubes! How much is that worth??!
|
35.3 | | RDGE00::KEW | Jerry built systems | Fri Oct 10 1986 10:25 | 13 |
| > I disagree that we should start dismantling what we have worked
> so hard to get (some of us more than others - thanks Vicky + Steve).
> Rather we should get additional resource to provide this service.
I agree entirely Ian, I suggested the de-coupling of the cluster in order
to raise the temperarure of the debate. I would have thought that a 750 as
a minimum would be appropriate for such an R&D machine. Being asked to
design to exploit a software environment we havn't even worked with is
verging on the ludicrous.
Jerry
|