=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

z

10.15 Why do lib$spawn, lib$set_symbol fail in detached processes?



GThe processing within run-time library (RTL) calls such as lib$attach, Clib$disable_ctrl, lib$do_command, lib$enable_ctrl, lib$get_symbol, Dlib$run_program, lib$set_symbol, lib$set_logical, and lib$spawn, is =dependent on and requires the presence of a command language Einterpreter (CLI), such as DCL. Without a CLI present in the current Hprocess, these calls will fail with a "NOCLI, no CLI present to perform function" error.

7Detached processes typically do not have a CLI present.

HIn place of lib$spawn, sys$creprc can often be used. The context of the Gparent process (symbols and logical names) will not be propogated into Dthe subprocess when sys$creprc is used, though when there is no CLI :present in the process this (lack of) propogation is moot.

FTo create a detached process with a CLI, you must specify LOGINOUT as Fthe target image as discussed elsewhere in the FAQ, or only use these Acalls (and any other calls requiring a CLI) from images that are >running in an "interactive", "batch", or "other" mode process.

BAlso note that the lib$spawn and the C system call will fail in a GCAPTIVE login environment. The lib$spawn call can be gotten to work in <this environment with the specification of the TRUSTED flag.

10.16 Where can I obtain Bliss, and the libraries and supporting files?



DThe Bliss language compilers and documentation are available on the OpenVMS Freeware distributions.

ABliss language source code that contains the following statement:

 

"
%  LIBRARY 'SYS$LIBRARY:STARLET.L32'; 




?or similar requires the presence of the Bliss libraries. These Clibraries are created on the target system using the Bliss require 8files, and are built using the following Bliss commands:

6STARLET.L32 contains the public interfaces to OpenVMS:

 

"
6    $ BLISS /LIBRARY=SYS$COMMON:[SYSLIB]STARLET.L32 -          SYS$LIBRARY:STARLET.REQ 




CLIB.L32 contains both the public and private interfaces to OpenVMS:

 

"
2    $ BLISS /LIBRARY=SYS$COMMON:[SYSLIB]LIB.L32 - 4        SYS$LIBRARY:LIB.REQ+SYS$LIBRARY:STARLET.REQ 




2The equivilent files for Bliss64 are created with:

 

"
5    $ BLISS/A64/LIBRARY=SYS$COMMON:[SYSLIB]LIB.L64 - 4        SYS$LIBRARY:LIB.R64+STARLET.REQ+STARLET.R64 9    $ BLISS/A64/LIBRARY=SYS$COMMON:[SYSLIB]STARLET.L64 -          SYS$LIBRARY:STARLET.R64 




ESome Bliss code may also require the OpenVMS VAX architecture flags. BThe following is the equivilent of the Alpha ARCH_DEFS.REQ module:

 

"
! 8! This is the OpenVMS VAX version of ARCH_DEFS.REQ, and ;! contains the architectural definitions for conditionally :! compiling OpenVMS Bliss sources for use on VAX systems. ;! (If you should encounter compilation errors here, please 5! seriously consider upgrading your Bliss compiler.) ! MACRO VAXPAGE = 1%; MACRO BIGPAGE = 0%; ! <MACRO VAX =                     ! = 1 if compiled BLISS/VAX @        %BLISS(BLISS32V)%;      ! = 0 if not compiled BLISS/VAX  PMACRO EVAX =                    ! = 1 if compiled BLISS/E* (Obsolete, old name) M        (%BLISS(BLISS32E) OR %BLISS(BLISS64E))%; ! = 0 if compiled /VAX /Inn  KMACRO ALPHA =                   ! = 1 if compiled BLISS/E* (New arch name) M        (%BLISS(BLISS32E) OR %BLISS(BLISS64E))%; ! = 0 if compiled /VAX /Inn  KMACRO IA64 =                    ! = 1 if compiled BLISS/I* (New arch name) P        (%BLISS(BLISS32I) OR %BLISS(BLISS64I))%; ! = 0 if compiled /VAX or /Ann  MACRO ADDRESSBITS = D        %BPADDR%;               ! = 32 or 64 based on compiler used  




GSome Bliss code may require the definition files for the OpenVMS older =LIBRTL routine lib$tparse, or the newer lib$table_parse call:

 

"
5    $ BLISS /LIBRARY=SYS$COMMON:[SYSLIB]TPAMAC.L32 -         SYS$LIBRARY:TPAMAC.REQ 


f

10.17 How can I open a file for shared access?



EWhen creating a file, it is often useful to allow other applications Fand utilities---such as TYPE---to share read access to the file. This @permits you to examine the contents of a log file, for instance.

DA C source example that demonstrates how to do this is available in 0topic (2867) in the OpenVMS Ask The Wizard area:



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

HDepending on the environment, you may need to use C calls such as fsync ?and fflush, and---in specific cases---the setvbuf(_IONBF) call.

FFor related materials around commands that can potentially be used to Goverride file locking---to view the file contents as currently written Dto disk---see Section 9.12.t

10.18 How can I have common sources for messages, constants?



EUse the GNM tools on the OpenVMS Freeware to have common sources for EMSG (message) files and SDML (Document) documentation files. Use the FDOCUMENT command to convert the SDML documentation into the necessary Hformats (Text, Postscript, HTML, etc). Use the MESSAGE/SDL tool (latent Fin OpenVMS) to create an SDL file based on the messages. Then use the ESDL tool (available on the OpenVMS Freeware) to convert the SDL file Finto language-specific definitions. (There is also a converter around Bto convert SDL into SDML, if you want to get pictures of the data #structures for your documentation.)y

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;  2    lib$signal(SS$_DEBUG,1,ascic_debug_commands);      return 1;     } 




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

10.20 Dealing with Endian-ness?



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

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

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

10.21 How to resolve LINK-I-DATMISCH errors?



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

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

 

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




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

10.22 HP C and other OpenVMS C Programming Considerations?



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

EBoth compilers can be installed at the same time on the same OpenVMS GVAX 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.

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

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

HVarious 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 Einstallation of a HP C RTL kit, a kit that is included with the HP C Hcompiler. OpenVMS VAX versions V6.1 and later do not require a seperate GRTL kit, but HP C RTL ECO kits are available to resolve problems found +with the C RTL on various OpenVMS releases.

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

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

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



HPermit 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 Hstructures. The alignment of structure members normally only comes into Fplay with specific unaligned data structures---such as the sys$creprc Gquota itemlist---and with data structures that are using data that was ?organized by a system using byte or other non-member alignment.

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

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

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



HFor additional information on the OpenVMS Ask The Wizard (ATW) area and Bfor a pointer to the available ATW Wizard.zip archive, please see iSection 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



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

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

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

FFloating point is prohibited in OpenVMS Alpha inner-mode (privileged) Gcode, and in any process or other execution context that does not have Bfloating point enabled. C programmers developing and working with DOpenVMS Alpha high-IPL kernel-mode code such as device drivers will Hwant to become familiar with the floating point processing available in 3the environment, and with the C compiler qualifier F/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.

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

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

GWhen 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 
      ... 




1and here is some associated example Bliss code...

 

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


?

10.22.2 Other common C++ issues



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

 

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




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

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

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

 

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




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

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

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

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

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

2To reference the version-dependent symbol library Dsys$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.

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

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

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



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

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




 r Y \ ^  
PreviousNextContentsIndex