| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 71.1 | | TLE::D_SMITH | Duane Smith -- DEC C RTL | Thu Mar 27 1997 06:47 | 13 |
| Dave,
The DEC C RTL group continues to produce ECO kits for OpenVMS V5.5-2
and later. If we confirm that the problem is truly a bug (and not a
user error) *and* this is important to your application, we will be
more than happy to fix it in a 6.1 ECO kit.
I did not read anything in DECC_BUGS 1009 which implied that we were
not willing to work with you. Had we replied saying that you indeed
had found a bug, but we would not fix it, then I could understand why
you would have written the base note.
Duane Smith
|
| 71.2 | | TLE::D_SMITH | Duane Smith -- DEC C RTL | Thu Mar 27 1997 06:53 | 7 |
| Dave also opened a new note turris::decc_bugs 1283 illustrating the
problem followed by a reply saying that he may have been wrong. An
edit was done to the module for OSF clearing pointing out that two
ungetc calls in a row were to be avoided. He is now attempting to
apply this same edit to the OpenVMS side of the code.
Duane
|
| 71.3 | Supported, With "Prior Version" Contract | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Mar 27 1997 10:59 | 7 |
|
The current and immediately previous OpenVMS version is supported
for all customers with a support contract. Specific older OpenVMS
releases formally supported for customers that have a "prior version
support" contracts. "Prior version support" contracts are available
for specific OpenVMS versions as far back as OpenVMS VAX V5.5-2 and
OpenVMS Alpha V6.1.
|
| 71.4 | In way of explanation | SMAUG::GARROD | IBM Interconnect Engineering | Thu Mar 27 1997 17:18 | 34 |
| Re:
> I did not read anything in DECC_BUGS 1009 which implied that we were
> not willing to work with you. Had we replied saying that you indeed
> had found a bug, but we would not fix it, then I could understand why
> you would have written the base note.
In no way was .0 meant to imply any sort of dissatisfaction. In fact
I feel the exact opposite way. The reply I got there was most helpful
and showed that what I'd found was not a bug but a feature of the
standard. I have since modified the code to use fsetpos() instead of
ungetc() and it works fine.
The intent of .0 here was to find out the official position on what
versions of OpenVMS are still supported. I included the reference to my
DECC note because that was the prime reason for asking at that time,
ie when thought I may have to deal with getting an ECO that I didn't
think existed. But in case I needed the info on what the min supported
O/S version is anyway so I appreciate the answer in .3.
Just to confirm does .3 mean that. OpenVMS V6.1 is no longer supported
by Digital (except for under prior version support) and that V6.2 is
the oldest version of OpenVMS that is currently supported.
Just to be clear I'm happy with either answer (YES or NO) I just need
to know. If the answer is V6.2 then we'll cease to issue kits/ECOs that
work on V6.1 (ie we can upgrade our build system to V6.2). If the
answer is V6.1 we'll wait until V6.1 is no longer formally supported.
I have some other reasons I'd like get upgraded to V6.2 and this is
what is holding us back at present.
Thanks again,
Dave
|
| 71.5 | | QUARK::LIONEL | Free advice is worth every cent | Sun Mar 30 1997 21:20 | 6 |
| Going by the normal rules, V6.2 would now be unsupported since it was
more than six months after V7.0 came out (and now there's V7.1).
However, I know that systems are still being FISed with some variant of
V6.2, so perhaps there's an exemption.
Steve
|
| 71.6 | V6.2-1H3, V7.0, and V7.1 | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Mar 31 1997 13:19 | 13 |
| : Going by the normal rules, V6.2 would now be unsupported since it was
: more than six months after V7.0 came out (and now there's V7.1).
: However, I know that systems are still being FISed with some variant of
: V6.2, so perhaps there's an exemption.
V6.2-1H3, V7.0, and V7.1 are -- if memory serves -- the only current
"standard version support" contract systems. (V6.2-1H3 and V7.0 are
the two OpenVMS versions that are "immediately prior" to V7.1.)
Other, older, OpenVMS versions require a "prior version support"
contract, and only specific older OpenVMS versions are available under
"prior version" support contracts.
|
| 71.7 | in the real world, it doesn't matter that much anyway | GIDDAY::GILLINGS | a crucible of informative mistakes | Mon Mar 31 1997 21:46 | 14 |
| Dave,
The previous notes are, of course, correct about *contractual* support.
However, here in the trenches, at the front line, we're generally expected
to provide support for customers on *any* version of OpenVMS. We have at
least one customer still running VMS V3.7 and several on V4.7 (though they
don't call very often). There is still a fairly large number running V5.5x
and an even larger number on V6.1 (VAX and Alpha). I don't think our
geography is going to do anything with "prior version support" (hey, why
bother selling something when you could just give it away?).
About the only place that "formal" support matters is in getting patches.
John Gillings, Sydney CSC
|