  OpenVMS Upward-Compatibility Statement? 
 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.
 
 Answer written or last revised on  24-NOV-2004 
