The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

10.19 How do I activate the OpenVMS Debugger from an application?


#include {lib$routines.h} 
#include {ssdef.h} 
#include {string.h} 
 
main() 
    { 
    char ascic_debug_commands[128]; 
    char *dbgcmd = "*show calls;go;exit"; 
 
    strcpy( ascic_debug_commands, dbgcmd ); 
    ascic_debug_commands[0] = (char) strlen( dbgcmd ) - 1; 
 
    lib$signal(SS$_DEBUG,1,ascic_debug_commands); 
 
    return 1; 
    } 

Also see Section 10.28 for another related discussion of the OpenVMS Debugger, and of a technique that uses the SS$_DEBUG signal.

10.20 Dealing with Endian-ness?

OpenVMS VAX, OpenVMS Alpha and OpenVMS I64 (as well as all Microsoft Windows implementations) all support and all use the little-endian byte ordering. Certain Alpha microprocessors and certain Intel Itanium processors can be configured to operate in big-endian and potentially in bi-endian mode. HP-UX typically operates big-endian.

With little-endian byte order, the least significant byte is always the first byte; the byte at the lowest address. With big-endian byte ordering, the byte storage order in memory is dependent on the size of the data (byte, word, longword) that is being referenced.

Endian-ness is a problem has been solved many times before. Some of the typical solutions include htonl/htons and ntohl/ntohs in the standard C library and the TCP/IP Services XDR (eXternal Data Representation) libraries. One of the more recently introduced network formats, and one that is seeing extensive press and marketing coverage, is XML.

10.21 How to resolve LINK-I-DATMISCH errors?

The message LINK-I-DATMISCH is informational, and indicates that the version of the specified shareable image found in the system shareable image directory does not match the version of the shareable image that was originally loaded into IMAGELIB.OLB, one of the OpenVMS libraries typically searched by the LINKER.

From a privileged username, you can usually completely repair this via the following DCL command:


$ LIB/REPLACE/SHARE SYS$LIBRARY:IMAGELIB.OLB SYS$SHARE:LIBRTL.EXE 

This command assumes that the shareable image that was found in the SYS$SHARE: area is valid and upward-compatiable, and that the image has simply replaced an older version without also updating IMAGELIB.

10.22 HP C and other OpenVMS C Programming Considerations?

VAX C V3.2 was released for OpenVMS VAX systems in 1991. DEC C V4.0 replaced VAX C V3.2 in 1993 as the HP C compiler for OpenVMS VAX systems. HP C is the ANSI C compiler for OpenVMS Alpha systems. VAX C predates the ANSI C standards, and has various areas that are not compliant with ANSI C requirements. HP C is an ANSI C compiler, and can also compile most VAX C code when /STANDARD=VAXC is specified. Versions of this compiler between V3.2 and V6.5 (exclusive) were known as DEC C, DIGITAL C, and Compaq C.

Both compilers can be installed at the same time on the same OpenVMS VAX system, allowing a migration from VAX C to DEC C, and allowing the same DEC C code to be used on OpenVMS VAX and OpenVMS Alpha.

The system manager can choose the system default C compiler when HP C is installed on a system with VAX C, and a C programmer can explicitly select the required compiler for a any particular compilation.

A current "C" license PAK allows access to both VAX C and HP C on the same OpenVMS VAX system.

Various HP C versions can be installed on OpenVMS VAX V5.5-2 and later. OpenVMS VAX releases such as V5.5-2 and V6.0 will require the installation of a HP C RTL kit, a kit that is included with the HP C compiler. OpenVMS VAX versions V6.1 and later do not require a seperate RTL kit, but HP C RTL ECO kits are available to resolve problems found with the C RTL on various OpenVMS releases.

With HP C, for automatic resolution of the standard C library routines by the LINKER utility, use the /PREFIX qualifier, such as /PREFIX=ALL_ENTRIES. If a particular application program replaces an existing C library routine, use /PREFIX=(ALL_ENTRIES,EXCEPT=(...)). (VAX C required explicit specification of an RTL shareable image or C object library during the link.)

When the /PREFIX is requested, the compiler generates a "decc$" prefix on the specified symbols. This prefix allows the LINKER to resolve the external symbols against the symbols present in the DECC$SHR library. The DECC$SHR library is included in the IMAGELIB.OLB shareable image library, and IMAGELIB is searched by default when any program (written in any language) is LINKed. Because the standard C library routine names are very likely to match application routines written in other languages, a prefix "decc$" is added to the C symbol names to assure their uniqueness; to prevent symbol naming conflicts. C programs, however, can sometimes have private libraries for various purposes, and the external routines share the same names as the library routines. (This is not recommended, but there are applications around that use this technique.) Thus the need to explicity specify whether or not the "decc$" prefix should be prepended to the external symbol names by the compiler.

The qualifiers, and most (all?) with associated pragmas, that may be of interest when migrating VAX C code to HP C include:

Permit structure members to be naturally aligned whenever possible, and avoid using /NOMEMBER_ALIGNMENT. If you need to disable member alignment, use the equivilent #pragma to designate the specific structures. The alignment of structure members normally only comes into play with specific unaligned data structures---such as the sys$creprc quota itemlist---and with data structures that are using data that was organized by a system using byte or other non-member alignment.

Versions of HP C such as V6.0 include the capability to extract the contents of the standard header libraries into directories such as SYS$SYSROOT:[DECC$LIB...], and provide various logical names that can be defined to control library searches. With HP C versions such as V6.0, the default operations of the compiler match the expectations of most OpenVMS programmers, without requiring any definitions of site-specific library-related logical names. (And logical names left from older DEC C versions can sometimes cause the compiler troubles locating header files.)

HP C V5.6 and later include a backport library, a mechanism by which HP C running on older OpenVMS releases can gain access to newer RTL routines added to the RTL in later OpenVMS releases---the language RTLs ship with OpenVMS itself, and not with the compilers.

Example C code is available in SYS$EXAMPLES:, in DECW$EXAMPLES (when the DECwindows examples are installed), in TCPIP$SERVICES (or on older releases, UCX$EXAMPLES) when HP TCP/IP Services is installed), on the Freeware CD-ROMs, and at web sites such as

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. ATW has been superceded (for new questions) by the ITRC discussion forums; the area remains available for reference.

10.22.1 Other common C issues

The localtime() function and various other functions maintain the number of years since 1900 in the "struct tm" structure member tm_year. This field will contain a value of 100 in the year 2000, 101 for 2001, etc., and the yearly incrementation of this field is expected to continue.

The C epoch typically uses a longword (known as time_t) to contain the number of seconds since midnight on 1-Jan-1970. At the current rate of consumption of seconds, this longword is expected to overflow (when interpreted as a signed longword) circa 03:14:07 on 19-Jan-2038 (GMT), as this time is circa 0x7FFFFFFF seconds since the C base date. (The most common solution is to ensure that time_t is an unsigned.)

If C does not correctly handle the display of the local system time, then check the UTC configuration on OpenVMS---the most common symptom of this is a skew of one hour (or whatever the local daylight saving time change might be). This skew can be caused by incorrect handling of the "is_dst" setting in the application program, or by an incorrect OpenVMS UTC configuration on the local system. (See section Section 4.4.)

Floating point is prohibited in OpenVMS Alpha inner-mode (privileged) code, and in any process or other execution context that does not have floating point enabled. C programmers developing and working with OpenVMS Alpha high-IPL kernel-mode code such as device drivers will want to become familiar with the floating point processing available in the environment, and with the C compiler qualifier /INSTRUCTION_SET=[NO]FLOATING_POINT. Device drivers and other similar kernel-mode C code must be compiled with /INSTRUCTION_SET=FLOATING_POINT and /EXTERN_MODEL=STRICT_REFDEF.

Additionally, the SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY parameter will be needed to be appended to the module specification or declared via the C compiler's include library logical name mechanism when the C compiler is resolving kernel-mode data structures and definitions. This library contains OpenVMS kernel-mode and other system declaractions, and particularly a mixture of undocumented definitions and declarations, and particularly definitions and declarations that are subject to change (and that can accordingly lead to requirements for the recompilation of application code).

In addition to the user-mode C Run-Time Library (RTL) mentioned in the OpenVMS C RTL documentation and referenced over in Section 3.9, there is a second and parallel kernel-mode RTL accessable to device drivers and other kernel code on OpenVMS Alpha and OpenVMS I64. The most common time this second C library is noticed is when C code is (erroneously) linked with /SYSEXE/SYSLIB, and duplicate symbol errors typically then arise. As code running in supervisor-, executive- or kernel-mode context cannot call out a user-mode RTL or other user-mode library, you will want to respecify the command as LINK /SYSEXE/NOSYSLIB. This will eliminate the duplicate symbol errors, since only the kernel-mode library will be referenced, and it will also avoid calling out into the user-mode libraries.

When sharing variables with other languages, here is some example HP C code...


      ... 
      #pragma extern_model save 
      #pragma extern_model strict_refdef 
      extern int   VMS$GL_FLAVOR; 
      #pragma extern_model restore 
      ... 

and here is some associated example Bliss code...


      ... 
      EXTERNAL 
         VMS$GL_FLAVOR, 
      .... 

10.22.2 Other common C++ issues

HP C++ (a separate compiler from HP C) provides both symbol mangling and symbol decoration. Some of the details of working with longer symbol names and the resulting symbol name mangling in mixed language environments are listed in the shareable image cookbook, and in the C++ documentation. Symbol name decoration permits the overloading of functions (by adding characters to the external symbol for the function to indicate the function return type and the argument data types involved), and mixed-language external references can and often do need to disable this decoration via the extern "C" declaration mechanism:


      extern "C" 
        { 
        extern int ExternSymbol(void *); 
        extern int OtherExternSymbol(void *); 
        } 

Also see Section 14.7 for information on /ARCHITECTURE and /OPTIMIZE=TUNE.

See Section 10.15 for information on the C system and the lib$spawn call in CAPTIVE environments.

Constructs such as the order of incrementation or decrementation and the order of argument processing within an argument list are all implementation-defined. This means that C coding constructs such as:


    i = i++; 
    a[i] = i++; 
    foo( i, i++, --i); 

are undefined and can have (adverse) implications when porting the C code to another C compiler or to another platform. In general, any combination of ++, --, =, +=, -=, *=, etc operators that will cause the same value to be modified multiple times (between what the ANSI/ISO C standard calls "sequence points") produce undefined and implementation-specific results.

Within C, the following are the "sequence points": the ";" at the end of a C statment, the ||, &&, ?:, and comma operators, and a call to a function. Note specifically that = is NOT a sequence point, and that the individual arguments contained within a function argument list can be processed from right to left, from left to right, or at any random whim.

HP C for OpenVMS VAX (formerly DEC C) and VAX C do differ in the related processing.

So you are looking for OpenVMS-specific definitions (include files)?

UCBDEF.H, PCBDEF.H and other OpenVMS-specific definitions---these are considered part of OpenVMS and not part of the C compiler kit---are available on all recent OpenVMS Alpha releases.

To reference the version-dependent symbol library sys$share:sys$lib_c.tlb, use a command similar to the following for compilation:


$ CC sourcea+SYS$LIBRARY:SYS$LIB_C/LIB 

You can also define DECC$TEXT_LIBRARY to reference the library.

You will want to review the Programming Concepts manual, and specifically take a quick look at Chapter 21.

And some general background: the STARLET definitions (and thus the sys$starlet_c.tlb library) contain the symbols and the definitions that are independent of the OpenVMS version. The LIB definitions (and thus sys$lib_c) contain symbols and definitions that can be dependent on the OpenVMS version. You won't need to rebuild your code after an OpenVMS upgrade if you have included definitions from STARLET. The same cannot be said for some of the definitions in LIB---you might need to rebuild your code. (The UCB structure can and has changed from release to release, for instance.)

Recent versions of C automatically search sys$starlet_c.tlb. Explicit specification of sys$lib_c.tlb is required.

Also see the Ask The Wizard website topics (2486), (3803), and (1661):

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. ATW has been superceded (for new questions) by the ITRC discussion forums; the area remains available for reference.

See Section 9.5 for information on the C off_t limitations, resolved in OpenVMS V7.3-1 and later and in ECO kits available for specific OpenVMS releases. The use of a longword for off_t restricts applications using native C I/O to file sizes of two gigabytes or less, or these applications must use native RMS or XQP calls for specific operations.

10.23 Status of Programming Tools on OpenVMS VAX?

DECthreads V7.3 and the HP C compiler (also known as Compaq C and DEC C) V6.4 are presently expected to be the last updates and the last releases of these development packages for use on OpenVMS VAX. The run-time support for both DECthreads (CMA$RTL) and for C (DECC$CRTL) will continue to be maintained, and will continue to be available on OpenVMS VAX. The VAX C V3.2 compiler is the final VAX C compiler release for OpenVMS VAX, and the VAX C Run-Time Library (VAXCRTL) will also continue to be available.

New development and new features and product enhancements continue for the OpenVMS Alpha and the OpenVMS IA-64 DECthreads and C compilers.

10.24 Choosing a Version Number for Application Code?

One of the common rules-of-thumb used for choosing a displayed version number string for a new version of a layered product or an application, its implications, and its expected effects on client applications and users, follows:

For additional version-numbering materials and for information on assigning module generation numbers, please see the OpenVMS (POLYCENTER) Software Product Installation Utility---variously refered to by acronyms including PCSI and SPIA---reference manual available within the OpenVMS documentation set.

Of course, all of this is obviously subject to interpretation, particularly around the distinction between large and small changes and such. The scale of the application is also a factor, as larger and more complex applications will tend toward smaller increments and will tend to see the maintenance number incremented, while new releases of smaller applications will tend to see the minor version incremented somewhat more frequently.

The goal of all this is to provide a guide to relative scale of changes and the associated effort involved in an upgrade for the user and/or for the application programmer.

10.25 Selecting a Process Dump Directory?

You can customize the device and directory for the process dump by defining the logical names SYS$PROCDMP and SYS$PROTECTED_PROCDMP. The former is for non-privileged dumps, while the latter is the location where privileged image dumps are written, and preferably an area protected against untrusted access. For example:


$ define SYS$PROCDMP SYS$ERRORLOG: 
$ define /exec SYS$PROTECTED_PROCDMP SYS$ERRORLOG: 

The abouve presumes that the SYS$ERRORLOG logical name points to a valid location.

There is presently no means to change the name of the generated dump file from IMAGENAME.DMP to something else. Accordingly, you will want to use different target directories for this purpose, particularly if there is more than one application or process potentially writing process dumps.


Previous Next Contents Index