Document revision date: 15 July 2002 | |
Previous | Contents | Index |
Example 20-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. |
Example 20-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 |
This chapter describes the libraries that contain C header files for
routines supplied by the OpenVMS Alpha operating system.
21.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 Compaq 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:
%CC-E-PASNOTMEM, In this statement, "rab$b_rac" is not a member of "rab". |
AlignFaultItem.PC[0] = DataPtr->afr$r_pc_data_overlay.afr$q_fault_pc[0]; |
AlignFaultItem.PC[0] = DataPtr->afr$q_fault_pc[0]; |
$ LIBRARY /EXTRACT=AFRDEF /OUTPUT=AFRDEF.H SYS$LIBRARY:SYS$STARLET_C.TLB |
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.
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 Compaq C command line qualifier or include the definition directly in your source program. For example:
/DEFINE=(__NEW_STARLET=1) |
#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 Compaq 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( ®ion, request_size, 0, 0, &p2_va, &length ); ... } |
Table 21-1 lists the data structures that are used by the new function protypes.
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 chapter describes the different I/O programming capabilities provided by the run-time library and illustrates these capabilities with examples of common I/O tasks. This chapter contains the following sections:
Section 22.1 describes the input and output operations within a program.
Section 22.2 describes using SYS$INPUT and SYS$OUTPUT.
Section 22.3 describes using LIB$GET_INPUT and LIB$PUT_OUTPUT for simple user I/O.
Section 22.4 describes using the SMG$ run-time library routines for managing the appearance of terminal screens.
Section 22.5 describes using screen management input routines and the
SYS$QIO and SYS$QIOW system services to perform special actions.
22.1 Choosing I/O Techniques
The operating system and its compilers provide the following methods for completing input and output operations within a program:
The DEC Text Processing Utility (DECTPU) is a text processor that can be used to create text editing interfaces. DECTPU has the following features:
In addition, DECTPU offers the following special features:
The method you select for I/O operations depends on the task you want to accomplish, ease of use, speed, and level of control you want.
The Compaq DECforms for OpenVMS software is a forms management product for transaction processing. DECforms integrates text and graphics into forms and menus that application programs use as an interface to users. DECforms software offers application developers software development tools and a run-time environment for implementing interfaces.
DECforms software integrates with the Application Control and Management System (ACMS), a transaction process (TP) monitor that works with other Compaq commercial applications to provide complete customizable development and run-time environments for TP applications. An asynchronous call interface to ACMS allows a single DECforms run-time process to control multiple terminals simultaneously in a multithreaded way, resulting in an efficient use of memory. By using the ACMS Remote Access Option, DECforms software can be distributed to remote CPUs. This technique allows the host CPU to offload forms processing and distribute it as closely as possible to the end user.
In contrast to OpenVMS RMS, RTLs, SYS$QIOs, and device driver I/O, program language I/O statements have the slowest speed and lowest level of control, but they are the easiest to use and are highly portable.
OpenVMS RMS and RTL routines can perform most I/O operations for a high-level or assembly language program. For information about OpenVMS RMS, see the OpenVMS Record Management Services Reference Manual.
System services can complete any I/O operation and can access devices not supported within OpenVMS RMS. See Chapter 23 for a description of using I/O system services.
Writing a device driver provides the most control over I/O operations, but can be more complex to implement. For information about device drivers for VAX systems, see the OpenVMS VAX Device Support Manual. The OpenVMS VAX Device Support Manual has been archived but is available on the OpenVMS Documentation CD-ROM.
Several types of I/O operations can be performed within a program, including the following:
Previous | Next | Contents | Index |
privacy and legal statement | ||
5841PRO_055.HTML |