Updated: 11 December 1998

OpenVMS Programming Interfaces: Calling a System Routine

1. The module $SYSSRVNAM in the FORTRAN system default library FORSYSDEF.TLB contains INTEGER and EXTERNAL declarations for each of the system services, so you need not explicitly provide these declarations in your program. Module $LNMDEF defines constants and data structures used when calling the logical name services, and module LIB$ROUTINES contains declarations for the LIB$ Run-Time Library routines.
2. The structure of an OpenVMS 3-longword item list is declared and then used to define the record variable ITEM_LIST. The second element will be used for the terminator.
3. The VOLATILE declaration is required for variables that are modified by means other than a direct assignment or as an argument in a routine call.
4. Return status variables should always be declared as longword integers.
5. The LEN intrinsic function returns the allocated length of EQUIV_NAME. The %LOC built-in function returns the address of its argument.
6. By default, FORTRAN passes arguments by reference, except for strings which are passed by CLASS_S descriptor. Arguments are omitted in FORTRAN by leaving the comma as a placeholder. All arguments must be specified or explicitly omitted.
7. A condition value can be tested for success or failure by a true/false test. For more information on testing return statuses, see the OpenVMS FORTRAN documentation.

Example 4-8 System Service Call in Pascal

[INHERIT('SYS$LIBRARY:STARLET', (1) 'SYS$LIBRARY:PASCAL$LIB_ROUTINES')] PROGRAM ORION (OUTPUT); TYPE Item_List_Cell = RECORD CASE INTEGER OF (2) 1:( { Normal Cell } Buffer_Length : [WORD] 0..65535; Item_Code : [WORD] 0..65535; Buffer_Addr : UNSIGNED; Return_Addr : UNSIGNED ); 2:( { Terminator } Terminator : UNSIGNED ); END; Item_List_Template(Count:INTEGER) = ARRAY [1..Count] OF Item_List_Cell; VAR Item_List : Item_List_Template(2); Translated_Name : [VOLATILE] VARYING [255] OF CHAR; (3) Status : INTEGER; BEGIN { Specify the buffer to return the translation } (4) Item_List[1].Buffer_Length := SIZE(Translated_Name.Body); Item_List[1].Item_Code := LNM$_String; Item_List[1].Buffer_Addr := IADDRESS(Translated_Name.Body); Item_List[1].Return_Addr := IADDRESS(Translated_Name.Length); { Terminate the item list } Item_List[2].Terminator := 0; { Translate the CYGNUS logical name } Status := $trnlnm(Tabnam := 'LNM$FILE_DEV', Lognam := 'CYGNUS', (5) Itmlst := Item_List); IF NOT ODD(Status) (6) THEN LIB$SIGNAL(Status) ELSE WRITELN('CYGNUS is equivalent to ',Translated_Name); END.

Pascal Notes

1. The Pascal environment file STARLET.PEN defines OpenVMS system services, data structures and constants. PASCAL$LIB_ROUTINES declares the LIB$ Run-Time Library routines.
2. The structure of an item list entry is defined using a variant record type.
3. The VARYING OF CHAR type is a variable-length character string with two components: a word-integer length and a character string body, which in this example is 255 bytes long. The VOLATILE attribute is required for variables which are modified by means other than a direct assignment or as an argument in a routine call.
4. The functions SIZE and IADDRESS are used to obtain the allocated size of the string body and the address of the string body and length. The returned length will be stored into the length field of the varying string Translated_Name, so that it will appear to be the correct size.
5. The definition of the SYS$TRNLNM routine in STARLET.PEN contains specifications of the passing mechanism to be used for each argument thus, it is not necessary to specify the mechanism here.
6. The IF statement performs a logical test following the function reference to see if the service completed successfully. If an error or warning occurs during the service call, the error is signaled.

Example 4-9 System Service Call in VAX MACRO

CYGDES: .ASCID /CYGNUS/ (1) ; Descriptor for CYGNUS string TBLDES: .ASCID /LNM$FILE_DEV/ (2) ; Logical name table NAMBUF: .BLKB 255 (3) ; Output buffer NAMLEN: .BLKW 1 (4) ; Word to receive length ITEMS: .WORD 255 ; Output buffer length .WORD LNM$STRING ; Item code .ADDRESS - ; Output buffer NAMBUF .ADDRESS - ; Return length NAMLEN .LONG 0 ; List terminator . . . .ENTRY ORION,0 (5) ; Routine entry point & mask $TRNLNM_S - (6) TABNAM=TBLDES, - LOGNAM=CYGDES, - ITMLST=ITEMS BLBC R0,ERROR (7) ; Check for error . . . .END

VAX MACRO Notes

1. The input character string descriptor argument is defined using the .ASCID directive.
2. The name of the table to search is defined using the .ASCID directive.
3. Enough bytes to hold the output data are allocated for an output character string argument.
4. The MACRO directive .BLKW reserves a word to hold the output length.
5. A routine name and entry mask show the beginning of executable code in a routine or subroutine.
6. A macro name that has the suffix _S or _G calls the service.
   You can specify arguments by keyword (as in this example) or by positional order. (Keyword names correspond to the names of the arguments shown in lowercase in the system service format descriptions in the OpenVMS System Services Reference Manual.) If you omit any optional arguments (if you accept the defaults), you can omit them completely if you specify arguments by keyword. If you specify arguments by positional order, however, you must specify the comma for each missing argument.
   Use the number sign (#) to indicate a literal value for an argument.
7. The BLBC instruction causes a branch to a subroutine named ERROR (not shown) if the low bit of the condition value returned from the service is clear (low bit clear = failure or warning). You can use a BSBW instruction to branch unconditionally to a routine that checks the return status.

This chapter describes the libraries that contain C header files for routines supplied by the OpenVMS Alpha operating system.

5.1 SYS$STARLET_C.TLB Equivalency to STARLETSD.TLB

The SYS$STARLET_C.TLB file, which was introduced in OpenVMS Alpha Version 1.0, contains all the .H files that provide STARLET functionality equivalent to STARLETSD.TLB. The file SYS$STARLET_C.TLB, together with DECC$RTLDEF.TLB that ships with the DEC C Compiler, replaces VAXCDEF.TLB that previously shipped with the VAX C Compiler. DECC$RTLDEF.TLB contains all the .H files that support the compiler and RTL, such as STDIO.H.

If you are running an application from a release prior to OpenVMS Alpha Version 1.0, the following differences may require source changes:

• RMS structures
  Previously, the RMS structures FAB, NAM, RAB, XABALL, and so forth, were defined in the appropriate .H files as "struct RAB {...", for example. The .H files supplied in OpenVMS Alpha Version 1.0 define them as "struct rabdef {...". To compensate for this difference, lines of the form "#define RAB rabdef" have been added. However, there is one situation where a source change is required because of this change. If you have a private structure that contains a pointer to one of these structures and your private structure is defined (but not used) before the RMS structure has been defined, you will receive compile-time errors similar to the following:

  %CC-E-PASNOTMEM, In this statement, "rab$b_rac" is not a member of "rab".

  
  This error can be avoided by reordering your source file so that the RMS structure is defined before the private structure. Typically, this involves moving around "#include" statements.

• LIB (privileged interface) structures
  Historically, three structures from LIB (NFBDEF.H, FATDEF.H, and FCHDEF.H) have been made available as .H files. These files were shipped as .H files in OpenVMS Alpha Version 1.0 and 1.5 (not in the new SYS$STARLET_C.TLB). As of OpenVMS Alpha Version 1.0, the file SYS$LIB_C.TLB, containing all LIB structures and definitions, has been added. These three .H files are now part of that .TLB and are no longer shipped separately. Source changes may be required, as no attempt has been made to preserve any existing anomalies in these files. The structures and definitions from LIB are for privileged interfaces only and are therefore subject to change.
• Use of "variant_struct" and "variant_union" In the new .H files, variant_struct and variant_union are always used, whereas previously some structures used struct and union. Therefore, the intermediate structure names cannot be specified when referencing fields within data structures.
  For example, the following statement:

  AlignFaultItem.PC[0] = DataPtr->afr$r_pc_data_overlay.afr$q_fault_pc[0];

  
  becomes:

  AlignFaultItem.PC[0] = DataPtr->afr$q_fault_pc[0];

• Member alignment
  Each of the .H files in SYS$STARLET_C.TLB saves and restores the state of "#pragma member_alignment".
• Conventions The .H files in SYS$STARLET_C.TLB adhere to some conventions that were only partly followed in VAXCDEF.TLB. All constants (#defines) have uppercase names. All identifiers (routines, structure members, and so forth) have lowercase names. Where there is a difference from VAXCDEF.TLB, the old symbol name is also included for compatibility, but users are encouraged to follow the new conventions.
• Use of Librarian utility to access the .H files
  During installation of OpenVMS Alpha Version 1.0, the contents of SYS$STARLET_C.TLB are not extracted into the separate .H files. The DEC C Compiler accesses these files from within SYS$STARLET_C.TLB, regardless of the format of the #include statement. If you want to inspect an individual .H file, you can use the Librarian utility, as in the following example:

  $ LIBRARY /EXTRACT=AFRDEF /OUTPUT=AFRDEF.H SYS$LIBRARY:SYS$STARLET_C.TLB

• Additional .H files included in SYS$STARLET_C.TLB
  In addition to the .H files derived from STARLET sources, SYS$STARLET_C.TLB includes .H files that provide support for DECthreads, such as CMA.H.

As of OpenVMS Alpha Version 7.0, SYS$LIBRARY:SYS$STARLET_C.TLB (or STARLET) provides C function prototypes for system services, as well as new and enhanced data structure definitions. The new definitions are more consistent with the OpenVMS C language coding conventions and definitions (typedefs) used in SYS$LIBRARY:SYS$LIB_C.TLB.

In order to maintain source compatibility for existing users of STARLET.H, the "old style" function declarations and definitions are still provided by default. To take advantage of the new system service function prototypes and type definitions, you must explicitly enable them.

You can define the __NEW_STARLET symbol with a DEC C command line qualifier or include the definition directly in your source program. For example:

• Define the _NEW_STARLET symbol with the DEC C command line qualifier as follows:

  /DEFINE=(__NEW_STARLET=1)

  
  or

• Define the _NEW_STARLET symbol in your C source program before including the SYS$STARLET_C.TLB header files:

  #define __NEW_STARLET 1 #include <starlet.h> #include <vadef.h>

To see the currently available system service function prototypes in STARLET.H, you can use the Librarian utility as shown in the following example:

$ LIBRARY/OUTPUT=STARLET.H SYS$LIBRARY:SYS$STARLET_C.TLB/EXTRACT=STARLET

The following example shows a new system service function prototype as it is defined in STARLET.H:

#pragma __required_pointer_size __long int sys$expreg_64( struct _generic_64 *region_id_64, unsigned __int64 length_64, unsigned int acmode, unsigned int flags, void *(*(return_va_64)), unsigned __int64 *return_length_64); #pragma __required_pointer_size __short

For more information about DEC C pointer size pragmas, see the DEC C User's Guide for OpenVMS Systems.

The following source code example shows the sys$expreg_64 function prototype referenced in a program.

#define __NEW_STARLET 1 /* Enable "New Starlet" features */ #include <starlet.h> /* Declare prototypes for system services */ #include <gen64def.h> /* Define GENERIC_64 type */ #include <vadef.h> /* Define VA$ constants */ #include <ints.h> /* Define 64-bit integer types */ #include <far_pointers.h> /* Define 64-bit pointer types */ { int status; /* Ubiquitous VMS status value */ GENERIC_64 region = { VA$C_P2 }; /* Expand in "default" P2 region */ VOID_PQ p2_va; /* Returned VA in P2 space */ uint64 length; /* Allocated size in bytes */ extern uint64 page_size; /* Page size in bytes */ status = sys$expreg_64( &region, request_size, 0, 0, &p2_va, &length ); ... }

Table 5-1 lists the data structures that are used by the new function protypes.

Table 5-1 Structures used by_NEW_STARLET prototypes

Structure Used by Prototype	Defined by Header File	Common Prefix for Structure Member Names	Description
struct _cluevthndl	cluevtdef.h	cluevthndl$	Cluster event handle
struct _fabdef	fabdef.h	fab$	File access block
struct _generic_64	gen64def.h	gen64$	Generic quadword structure
struct _ieee	ieeedef.h	ieee$	IEEE Floating point control structure
struct _ile2 1	iledef.h	ile2$	Item list entry 2
struct _ile3 1	iledef.h	ile3$	Item list entry 3
struct _iosa	iosadef.h	iosa$	I/O status area
struct _iosb	iosbdef.h	iosb$	I/O status block
struct _lksb	lksbdef.h	lksb$	Lock status block
struct _rabdef	rabdef.h	rab$	RMS record access block
struct _secid	seciddef.h	secid$	Global section identifier
struct _va_range	va_rangedef.h	va_range$	32-bit virtual address range

This appendix describes the use of generic macros to specify argument lists with appropriate symbols and conventions in the system services interface to MACRO assemblers.

System service macros generate argument lists and CALL instructions to call system services. These macros are located in the system library SYS$LIBRARY:STARLET.MLB. When you assemble a source program, this library is searched automatically for unresolved references.

Knowledge of VAX MACRO rules for assembly language programming is required for understanding the material presented in this appendix. The VAX MACRO and Instruction Set Reference Manual contains the necessary prerequisite information.

Each system service has four macros associated with it. These macros allow you to define symbolic names for argument offsets, construct argument lists for system services, and call system services. Table A-1 lists the generic macros and the functions they serve.

Table A-1 Generic Argument List Macros of the System Service Interface

Macro	Function
$ nameDEF	Defines symbolic names for the argument list offsets.
$ name	Defines symbolic names for the argument list offsets and constructs the argument list.
$ name_S	Calls the system service and constructs the argument list.
$ name_G	Calls the system service and uses the argument list constructed by $ name macro.

A.1 Using Macros to Construct Argument Lists

• $name
• $name_S

The macro you use depends on which macro you are going to use to call the system service. If you use the $name_G macro to call a system service, you should use the $name macro to construct the argument list. If you use the $name_S macro to call a system service, you can also use it to construct the argument list.

A.1.1 Specifying Arguments with the $name_S Macro and the $name Macro

When you use the $name_S or the $name macro to construct an argument list for a system service, you can specify arguments in any one of three ways:

• By using keywords to describe the arguments. All keywords must be followed by an equals sign (=) and then by the value of the argument.
• By using positional order, with omitted arguments indicated by commas in the argument positions. You can omit commas for optional trailing arguments.
• By using both positional order and keyword names (positional arguments must be listed first).

For example, $MYSERVICE can have the following format:

$MYSERVICE arga ,[argb] ,[argc] ,argd

For purposes of this example, assume that arga and argb require you to specify numeric values and that argc and argd require you to specify addresses.

Examples A-1 and A-2 show valid ways of writing the $name_S macro to call $MYSERVICE.

Example A-1 Using Keywords with the$ name_S Macro

MYARGD: .LONG 100 . . . $MYSERVICE_S ARGB=#0,ARGC=0,ARGA=#1,ARGD=MYARGD

Example A-2 Specifying Arguments in Positional Order with the$ name_S Macro

MYARGD: .LONG 100 . . . $MYSERVICE_S #1,,,MYARGD

The argument list is pushed on the stack, as follows:

PUSHAL MYARGD PUSHL #0 PUSHL #0 PUSHL #1

Note that all arguments, whether specified positionally or with keywords, must be valid assembler expressions because they are used as source operands in instructions.

Examples A-3 and A-4 show valid ways of writing a $name macro to construct an argument list for a later call to $MYSERVICE.

Example A-3 Using Keywords with the$ name Macro

LIST: $MYSERVICE - ARGB=0, - ARGC=0, - ARGA=1, - ARGD=MYARGD

Example A-4 Specifying Arguments in Positional Order with the$ name Macro

LIST: $MYSERVICE - 1,,,MYARGD

Both methods generate the following:

LIST: .LONG 4 .LONG 1 .LONG 0 .LONG 0 .ADDRESS - MYARGD

Note that all arguments, whether specified positionally or by keyword, must be expressions that the assembler can evaluate to generate .LONG or .ADDRESS data directives. Contrast this to the arguments for the $name_S macro, which must be valid assembler expressions because they are used as source operands in instructions.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

5843PRO_007.HTML