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

Conference clt::cobol

Title:VAX/DEC COBOL
Notice:Kit,doc,performance talk info-->DIR/KEY=KIT or DOC or PERF_TALK
Moderator:PACKED::BRAFFITT
Created:Mon Feb 03 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3250
Total number of notes:13077

3197.0. "Upgrade selling advice required" by CCAD14::MCCULLOCH () Tue Feb 11 1997 18:25

(Posted in DEC C and DEC COBOL Conferences)

Hi All,

I hope I haven't missed a note concerning this issue, but I need some general
advice on "How to sell a compiler upgrade to a customer".

I have recently been assigned to a project with a large DIGITAL customer (both
hardware and software).

As part of the project, some development is required to enhance their current
application etc.

Anyway, having been working on Alpha Technology for a while it's like a step
back in time to work on their system.

The application consists of 90% COBOL and 10% C running on VAX with versions as
below:

OpenVMS for VAX V6.1
VAX COBOL V4.4-64
VAX C V3.2-044

I can't believe that how old these versions are, but the point is that I need
to convince the customer to upgrade.  As far as I can see, their application is
not "dependent" on these versions, they have just never bothered to upgrade and
have therefore fallen further and further behind the latest supported versions.
The customer is of the "if it works, don't break it" type, but for my own
sanity and my wish (together with others who work on the project) to break out
of the "Ark", I want to sell an upgrade path to the customer's technical and
management staff.

What I have come up with so far (summarised) is:

Advantages:
1. Current versions are not supported - latest versions are fully supported.
2. The latest versions are much better compilers than the ones installed (full
code optimisation, better coding error detection, adhere to standards, aid
Alpha migration).

Disadvantages:
1. Upgrade may (probably will!) involve code changes, so full analysis will be
required.  Then full System Test after work carried out.

Does anyone have any other suggestions, or pointers to help me in my quest ?
If anyone has written a document concerning the advantages of upgrades, then
you may email me direct.

Thanks for your attention,

Malcolm McCulloch
Application Development Centre,
Christchurch
New Zealand

T.RTitleUserPersonal
Name
DateLines
3197.1Other reasons to upgrade to VAX COBOL V5.4PACKED::BRAFFITTTue Feb 11 1997 19:2927
>OpenVMS for VAX V6.1
>VAX COBOL V4.4-64
>VAX C V3.2-044

    VAX COBOL V4.4 is not Y2K-compliant since it does not include the
    intrinsic functions (1989 addendum to the ANSI-85 standard).
    
    VAX COBOL V5.4 just went to the SSB, and it is Y2K-compliant.  It is
    possible that the customer applications are Y2K-compliant even with VAX
    COBOL V4.4-64, but VAX COBOL V5.4 would give the customer the needed
    base to upgrade any applications that are not Y2K-compliant.  See
    keyword 2000 in this Notes conference for pointers to more information
    on COBOL and Y2K issues.
    
    If the customer is using /STANDARD=V3, the first thing they should do
    is upgrade their applications to /STANDARD=85 with VAX COBOL V4.4. 
    They should then upgrade to VAX COBOL V5.4 which supports the operating
    system version they are currently using (OpenVMS VAX V6.1).  They could
    then also upgrade to OpenVMS VAX V7.0 if they want to do this since VAX
    COBOL V5.4 also supports V7.0.
    
    There is other new functionality such as segmented key support in VAX
    COBOL V5.4 beyond what they have in VAX COBOL V4.4.  One thing you
    could do is give the customer a copy of the VAX COBOL V5.4 release
    notes which are comprehensive covering all changes since VAX COBOL
    V4.4.  See keyword kit in this Notes conference for a pointer to the
    VAX COBOL V5.4 kit and documentation.