|
HP OpenVMS Systemsask the wizard |
|
The Question is: At the momen we are running openvms 6.2, we want to upgrade to openvms 7.2. We would like to know if the upgrade, affects our DCL procedure files? The Answer is :
Correctly-written DCL command procedures and correctly-written user-mode
application code should not be affected by an OpenVMS upgrade.
Full upward binary compatibility of all user-mode applications is a
central goal of HP OpenVMS Engineering, and a key OpenVMS customer
expectation.
On OpenVMS Alpha systems, OpenVMS Engineering assumes, works for, tests
for, and targets upward-compatibility of user-mode applications;
applications that are specifically using only documented interfaces,
that are lacking latent bugs, that are not using position-dependent
coding constructs, and that are not specifically dependent on the
OpenVMS version number itself or on a version-dependent product.
Like OpenVMS Alpha, OpenVMS VAX releases are expected to provide
upward-compatibility of all valid user-mode code. On OpenVMS VAX V6.0
and later systems, OpenVMS Engineering further assumes that
privileged-mode software application code such as device drivers --
again, code that is using only documented interfaces, lacking latent
bugs, and not otherwise version- dependent nor position-dependent --
will also be upward-compatible.
To validate upward-compatibility, OpenVMS Engineering uses a variety of
mechanisms. Examples of these mechanisms include source code reviews,
statistical quality controls, an extensive regression test suite, tools
which verify the values of constants and symbols, and programs for
distributing early copies of OpenVMS releases via software developer
kits and field test kits. All of these mechanisms target the early
identification of compatibility problems, and the rapid remediation
of regressions.
User-mode or privileged-mode application code containing latent bugs,
position- or version- dependent code, or that are using undocumented
interfaces may well require rework or rebuild as ECO kits are applied
or as OpenVMS is upgraded. Privileged-mode code may require rework
across major OpenVMS Alpha releases.
That said, HP OpenVMS Engineering has broken upward-compatibility
in a few product areas, the (contractually obligated) removal of
Display Postscript from DECwindows being a salient example. (While
not specifically a change in OpenVMS itself, this change has tripped
at least two layered products: NOTES, and DECwrite.) Another more
subtle example of upward-compatibility issue is the errant code
generator found in older compilers; code that was invalid and was
found incompatible with the Alpha Architecture, and that caused the
generated (application) code to fail on EV6 and later. (qv: the
SRM_CHECK tool and information available on the OpenVMS Freeware
V4 distribution (http://www.hp.com/go/openvms/freeware), and in
the 21264 directory.
HP OpenVMS Engineering has also (deliberately) tightened the handling
of the file delete permissions at OpenVMS V6.0, which broke a few
applications and which also prevented various errant file deletions
(as part of the NCSC Class C2 security), and OpenVMS Engineering and
the compiler teams have also also tightened up the syntax checks on
occasion.
...
Note: full upward-compatibility of user-mode code -- that code
also using documented interfaces and lacking latent bugs
-- is a general expectation of most any OpenVMS upgrade.
Major release ("dot-zero" release)
o eg: OpenVMS Alpha V7.0, OpenVMS VAX V6.0
o Key designator: the "dot zero"
o Contains new features, new capabilities
o Can include new hardware support.
o User-mode code using documented interfaces is expected to
operate without alteration.
o Often includes changes to kernel-mode data structures.
o Can require changes (recompile or reassembly, possibly
recoding) of kernel-mode (privileged-mode) code.
o The full battery of OpenVMS tests run on this release.
o The release is a general release, and is targeted for use on
all supported processors.
o Customers with software services contracts receive this
release automatically.
Minor release ("dot" release)
o eg: OpenVMS Alpha V7.1, OpenVMS VAX V6.2
o Key designator: the "dot not-zero"
o Contains new features, new capabilities
o Can include new hardware support.
o User-mode code using documented interfaces is expected to
operate without alteration.
o Few (compatible), or no, changes to kernel-mode data structures.
o Kernel-mode (privileged-mode) code using documented interfaces
is expected to continue to operate without alteration.
o The full battery of OpenVMS tests run on this release.
o The release is a general release, and is targeted for use on
all supported processors.
o Customers with software services contracts receive this
release automatically.
Maintenance release ("dash" release):
o eg: OpenVMS VAX V5.5-2, OpenVMS Alpha V7.1-2
o Key designator: the "dash"
o Not a vehicle for new features nor new capabilities -- these
releases are intended for new hardware and a roll-up of
maintenance fixes.
o Can include new hardware support.
o User-mode code using documented interfaces is expected to
operate without alteration.
o Few (compatible) or no changes to kernel-mode data structures.
o Kernel-mode (privileged-mode) code using documented interfaces
is expected to continue to operate without alteration.
o The full battery of OpenVMS tests are run on this release.
o The release is a general release, and is targeted for use on
all supported processors.
o Customers with software services contracts receive this
release automatically.
Limited Hardware Release ("LHR" or "hardware" or "H" release):
o eg: OpenVMS Alpha V6.2-1H3, OpenVMS Alpha V7.1-1H2
o Key designator: the "H"
o Not a release vehicle for new features, new capabilities, nor
bugfixes -- the hardware release is intended solely for new
hardware and new configuration support.
o Includes new hardware support.
o Includes only those ECO kits that are directly affected by the
work for new hardware support -- only those ECO kits and
changes specifically required to prevent regressions are
included in this release.
o User-mode code using documented interfaces is expected to
operate without alteration.
o Few (compatible) or no changes to kernel-mode data structures.
o Kernel-mode (privileged-mode) code using documented interfaces
is expected to continue to operate without alteration.
o A limited battery of OpenVMS tests are run on this release.
o The release is not a general release, and is targeted for use
only on configurations including specific new hardware.
o Customers must explicitly order this release.
o Customers are normally encouraged to upgrade off of hardware
releases as soon as a subsequent "mainline" release is available.
For related information and discussions around Alpha microprocessor
architecture and upward-compatibility of code for particular Alpha
microprocessors, please see topics including (2738), (2932), and (6829).
These cited topics also list other related discussions.
|