HP OpenVMS Systems

ask the wizard
Content starts here

Application Upward-Compatibility?

» close window

The Question is:

Will a program run in OpenVMS v.7 that runs
and designed for V 1.5
Program : HIMILL (by FIDIA)

The Answer is :

  User-mode code and applications are expected to be upward-compatible on
  OpenVMS Alpha.  Kernel-mode code and kernel-mode applications can and
  sometimes will require a rebuild of the images and can potentially
  require some amount of recoding as OpenVMS Alpha is upgraded.
  User-mode code and applications are expected to be upward-compatible
  on OpenVMS VAX.  Both user- and kernel-mode code and applications are
  expected to be upward-compatible on OpenVMS VAX V6.0 and later.
  Analogous to the existing high level of source code compatibility among
  OpenVMS VAX and OpenVMS Alpha, OpenVMS on Itanium Processor Family (IPF)
  platforms is expected to have a high level of source compatibility.
  (References in the code to architecture-specific constructs are one area
  where there will be the potential for source code differences, of course.)
  This assumes no (relevent) latent bugs exist in the application code,
  and also assumes the use of only documented and supported interfaces.
  In the case of a specific product or application package, you will want
  to contact the vendor and/or the associated support organization.
  The OpenVMS Wizard does encourage rebuilding old(er) application source
  code with newer compilers, though this is not strictly necessary.
  Rebuilding code with newer tools permits the incorporation of newer
  code optimizations, and the newer tools can also be better at locating
  existing latent errors.  (If you can target execution of your code on
  specific generations of the Alpha microprocessors (and subsequent Alpha
  generations), also please see the information in the OpenVMS FAQ for
  some details on the /ARCHITECTURE and /OPTIMIZE qualifiers.)
  There are a (very) few areas where OpenVMS and layered products are
  not upward-compatible.  One such area is Display Postscript, where
  contractual obligations required its removal in newer versions of
  the DECwindows package.  Another (rare) area is where the applicable
  standards have changed in an incompatible fashion, and full standards
  compliance is a requirement.
  For related information and discussions, please see topics including
  (2738), (2932), (6829), and particularly please see topic (7555).
  Other related topics include (173), (866), (1052), (1171), (1904),
  (2738), (2932), (4336), and (6049).

answer written or last revised on ( 24-NOV-2004 )

» close window