| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2091.1 | Depends on the amount of development | CXXC::REPETE | Rich Peterson 381-1802 ZKO2-3/N30 | Tue Feb 11 1997 16:15 | 24 |
| If the development is just a minor tweak on what they have running
now, it would be a pretty hard sell.
But if they're actually going to make significant enhancements, then
it's maybe a little easier to convince them that doing the work to
use a compiler and runtime library that conform to industry standards
and has responsive support when problems or bugs are encountered will
pay off in product quality and employee satisfaction.
Regarding "dependence on version", it's likely that any significant
code base developed with the VAX C compiler will contain some degree
of dependence on the VAX C compiler that might not be completely
duplicated by the /standard=vaxc mode of DEC C. So it would be
a mistake to claim there would be no source changes necessary. And
at least for the C compiler, it probably would not be wise to sell on
optimization - the goal for the VAX version of DEC C was to be
comparable to VAX C. Modifying the VAX code generator and optimizer
to beat VAX C wasn't and isn't on the todo list. For performance,
the Digital solution is to upgrade to Alpha.
The VAX C to DEC C Migration Guide, which ships with DEC C on VAX, has
some other fodder in it that might be useful, especially around the
runtime libraries and in reassuring the customer that the migration
can be done in safe steps.
|
| 2091.2 | | TLE::REAGAN | All of this chaos makes perfect sense | Tue Feb 11 1997 17:17 | 18 |
| I don't understand "why" you are telling them they need to upgrade?
Is something broken?
Note that given our current PAK scheme, Digital makes absolutely
no money when a customer upgrades from on version to the next.
They don't need a new PAK, they just install the latest version
from the CD distribution.
I usually say "if it ain't broke, don't fix it". However, one
argument might be to say "doing the upgrade now at our leisure
is better than doing it under pressure when we eventually have
a real reason down the road".
As for code changes, the VAX C to DEC C migration might certainly
involve changes. However, the VAX COBOL version upgrade should be
transparent for legal COBOL code.
-John
|
| 2091.3 | Clarifications | CCAD14::MCCULLOCH | | Tue Feb 11 1997 18:24 | 41 |
|
Hi All,
Thanks for your replies so far.
To clarify some issues as to "why" I think they should upgrade.
The project involves some interface between OpenVMS VAX and a product running
on DIGITAL UNIX. The development on UNIX uses the DEC C compiler, but the team
is having to use the VAX C compiler on the VAX. Quite a lot of the UNIX code
is modified to run on the VAX - in other words there are common files.
So, in my opinion, it would make more sense to run DEC C on both platforms.
Of course, there is existing VAX C code. I note (and agree) that this code
will require some work to bring it up to scratch.
I also hear that VAX COBOL V5.4 is Y2K compliant which I think would definitely
interest the client.
I think that another issue of pursuing upgrades is electronic documentation.
Have you tried finding a copy of the Users Guide for VAX COBOL V4.4 on CD
lately ? It is one of the issues which persuades me (though I respect others
views) to keep "current" in terms of versions.
Reply .2 touches on the sales issue which may be important for DIGITAL.
By keeping the client current, the day that we (DIGITAL) suggest to
the customer that (as is pointed out, for performance reasons) they migrate
to Alpha, then at that stage there may be siginificant sales Bucks coming
through.
The migration would surely be easier from current versions that old ones.
I will print out the latest VAX C to DEC C Migration guide for tips as you
suggest in .1 - thanks.
Any more views on upgrades welcome,
Malcolm McCulloch
Application Development Centre,
Christchurch
New Zealand
|
| 2091.4 | If They Have A "C" License, Do It | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed Feb 12 1997 10:07 | 14 |
|
If you're planning to operate with DEC C on any platform -- OpenVMS
Alpha or Digital UNIX, you'll definitely want to upgrade to compatible
C compilers. It will reduce the number of compiler-related differences,
and will tend to flag platform differences.
DEC C is quite superior to VAX C in error messages, code generation,
code portability, and general C support.
If the customer has a current "C" license, they can upgrade for the
cost of a distribution kit. (If they do not already have one.)
And both DEC C and VAX C can co-exist on a system. I'd use this to
port the VAX C code to DEC C, and from there to other platforms.
|
| 2091.5 | Boy, you must lead a sheltered life.... | CVG::PETTENGILL | mulp | Mon Feb 17 1997 20:56 | 19 |
| >I can't believe that how old these versions are, but the point is that I need
>to convince the customer to upgrade.
Most of DEC's internal business systems are based on VAX/VMS V5.5-2.
> If the customer has a current "C" license, they can upgrade for the
> cost of a distribution kit. (If they do not already have one.)
Well, they way that they would have a "current" C license would be by having
a support contract that covered C. Otherwise, their C license would be limited
to the version of C that they already have. The fact that the PAK allows them
to use software doesn't mean that they have the right to use the software.
> DEC C is quite superior to VAX C in error messages, code generation,
> code portability, and general C support.
Its really a matter of DEC C _plus_ the recent releases of the RTLs and
headers that are superior to VAX C and the 57 flavors of DU C compilers
and previous generations of RTLs and headers.
|
| 2091.6 | | TLE::REAGAN | All of this chaos makes perfect sense | Tue Feb 18 1997 08:20 | 13 |
| >Well, they way that they would have a "current" C license would be by having
>a support contract that covered C. Otherwise, their C license would be limited
>to the version of C that they already have. The fact that the PAK allows them
>to use software doesn't mean that they have the right to use the software.
Can you show me the words in the T&Cs that support this? From my
understanding (and all of the product managers I've talked to), there
isn't anything that prohibits the customer from taking subsequent
releases from the distribution media. Whether is "moral" or not, I
don't think its prohibited. However, I'm not a lawyer so my opinion
isn't what counts I suppose.
-John
|
| 2091.7 | See Price Book For License Info | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Feb 18 1997 10:00 | 29 |
|
The customer is licensed for a specific version, and (often) any updates
to the package up to one year after the license is issued. The customer
is not licensed for subsequent versions without a support license, or a
version upgrade.
The T&C explicitly mentions that the customer may receive media from
DIGITAL that contains software kits the customer is not licensed for.
The T&C also explicitly indicates that any new versions must be licensed
subject to the terms of the T&C, and only on the processor(s) the
software was previously licensed.
The T&C doesn't go into details on the license itself, or on what the
license covers. And that is the information that answers this question.
(The T&C doesn't really describe what a license covers -- it just says
that you must have a license.) The best spot for the license information
is in the Price Book.
>Well, they way that they would have a "current" C license would be by having
>a support contract that covered C. Otherwise, their C license would be limited
>to the version of C that they already have. The fact that the PAK allows them
>to use software doesn't mean that they have the right to use the software.
Correct, and that's what I meant by `current'.
: ...and all of the product managers I've talked to...
Now you've talked to one (former) PM that disagrees.
|