Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Programming Concepts Manual


Previous Contents Index

7.2.1 Obtaining the Command Line

The LIB$GET_FOREIGN routine returns the contents of the command line that you use to activate an image. It can be used to give your program access to the qualifiers of a foreign command or to prompt for further command line text.

A foreign command is a command that you can define and then use as if it were a DCL or MCR command in order to run a program. When you use the foreign command at command level, the CLI parses the foreign command only and activates the image. It ignores any options or qualifiers that you have defined for the foreign command. Once the CLI has activated the image, the program can call LIB$GET_FOREIGN to obtain and parse the remainder of the command line (after the command itself) for whatever options it may contain.

The OpenVMS DCL Dictionary describes how to define a foreign command.

The action of LIB$GET_FOREIGN depends on the environment in which the image is activated:

Example

The following PL/I example illustrates the use of the optional force-prompt argument to permit repeated calls to LIB$GET_FOREIGN. The command line text is retrieved on the first pass only; after this, the program prompts from SYS$INPUT.


 
EXAMPLE: ROUTINE OPTIONS (MAIN); 
 
%INCLUDE $STSDEF;           /* Status-testing definitions */ 
 
DECLARE COMMAND_LINE CHARACTER(80) VARYING, 
        PROMPT_FLAG FIXED BINARY(31) INIT(0), 
        LIB$GET_FOREIGN ENTRY (CHARACTER(*) VARYING, 
                               CHARACTER(*) VARYING, 
                               FIXED BINARY(15), 
                               FIXED BINARY(31)) 
          OPTIONS(VARIABLE) RETURNS (FIXED BINARY(31)), 
        RMS$_EOF GLOBALREF FIXED BINARY(31) VALUE; 
 
/* Call LIB$GET_FOREIGN repeatedly to obtain and print 
   subcommand text. Exit when end-of-file is found. */ 
 
DO WHILE ('1'B);                   /* Do while TRUE */ 
  STS$VALUE = LIB$GET_FOREIGN 
                 (COMMAND_LINE,'Input: ',, 
                  PROMPT_FLAG); 
  IF STS$SUCCESS THEN 
    PUT LIST ('  Command was ',COMMAND_LINE); 
  ELSE DO; 
    IF STS$VALUE ^= RMS$_EOF THEN 
      PUT LIST ('Error encountered'); 
    RETURN; 
    END; 
  PUT SKIP;                    /* Skip to next line */ 
  END;                      /* End of DO WHILE loop */ 
END; 
 
 

Assuming that this program is present as SYS$SYSTEM:EXAMPLE.EXE, you can define the foreign command EXAMPLE to invoke it, as follows:


$ EXAM*PLE :== $EXAMPLE

Note the optional use of the asterisk in the symbol name to denote an abbreviated command name. This permits the command name to be abbreviated as EXAM, EXAMP, EXAMPL or to be specified fully as EXAMPLE. See the OpenVMS DCL Dictionary for information about abbreviated command names.

Note that the use of the dollar sign ($) before the image name is required in foreign commands.

Now assume that a user runs the image by typing the foreign command and giving "subcommands" that the program displays:


$ EXAMP Subcommand 1 
  Command was     SUBCOMMAND 1
Input: Subcommand 2 
  Command was     SUBCOMMAND 2
Input: ^Z 
$

In this example, Subcommand 1 was obtained from the command line; the program prompts the user for the second subcommand. The program terminated when the user pressed the Ctrl/Z key sequence (displayed as ^Z) to indicate end-of-file.

7.2.2 Chaining from One Program to Another

The LIB$RUN_PROGRAM routine causes the current image to exit at the point of the call and directs the CLI, if present, to start running another program. If LIB$RUN_PROGRAM executes successfully, control passes to the second program; if not, control passes to the CLI. The calling program cannot regain control. This technique is called chaining.

This routine is provided primarily for compatibility with PDP-11 systems, on which chaining is used to extend the address space of a system. Chaining may also be useful in an operating system environment where address space is severely limited and large images are not possible. For example, you can use chaining to perform system generation on a small virtual address space because disk space is lacking.

With LIB$RUN_PROGRAM, the calling program can pass arguments to the next program in the chain only by using the common storage area. One way to do this is to direct the calling program to call LIB$PUT_COMMON in order to pass the information into the common area. The called program then calls LIB$GET_COMMON to retrieve the data.

In general, this practice is not recommended. There is no convenient way to specify the order and type of arguments passed into the common area, so programs that pass arguments in this way must know about the format of the data before it is passed. Fortran COMMON or BASIC MAP/COMMON areas are global OWN storage. When you use this type of storage, it is very difficult to keep your program modular and AST reentrant. Further, you cannot use LIB$RUN_PROGRAM if a CLI is present, as with image subprocesses and detached subprocesses.

Examples

The following PL/I example illustrates the use of LIB$RUN_PROGRAM. It prompts the user for the name of a program to run and calls the RTL routine to execute the specified program.


CHAIN:  ROUTINE OPTIONS (MAIN) RETURNS (FIXED BINARY (31)); 
DECLARE LIB$RUN_PROGRAM ENTRY (CHARACTER (*))  /* Address of string 
                                               /* descriptor        */ 
        RETURNS (FIXED BINARY (31));           /* Return status     */ 
%INCLUDE $STSDEF;    /* Include definition of return status values  */ 
DECLARE COMMAND CHARACTER (80); 
        GET LIST (COMMAND) OPTIONS (PROMPT('Program to run: ')); 
        STS$VALUE = LIB$RUN_PROGRAM (COMMAND); 
/* 
   If the function call is successful, the program will terminate 
   here.  Otherwise, return the error status to command level. 
*/ 
        RETURN (STS$VALUE); 
END CHAIN; 

The following COBOL program also demonstrates the use of LIB$RUN_PROGRAM. When you compile and link these two programs, the first calls LIB$RUN_PROGRAM, which activates the executable image of the second. This call results in the following screen display:


THIS MESSAGE DISPLAYED BY PROGRAM PROG2 
 
WHICH WAS RUN BY PROGRAM PROG1 
 
USING LIB$RUN_PROGRAM 


 
IDENTIFICATION DIVISION. 
PROGRAM-ID.  PROG1. 
 
ENVIRONMENT DIVISION. 
 
DATA DIVISION. 
 
WORKING-STORAGE SECTION. 
 
01    PROG-NAME    PIC X(9)     VALUE "PROG2.EXE". 
01    STAT         PIC 9(9)     COMP. 
    88  SUCCESSFUL              VALUE 1. 
 
ROUTINE DIVISION. 
 
001-MAIN. 
        CALL "LIB$RUN_PROGRAM" 
            USING BY DESCRIPTOR PROG-NAME 
            GIVING STAT. 
        IF NOT SUCCESSFUL 
            DISPLAY "ATTEMPT TO CHAIN UNSUCCESSFUL" 
            STOP RUN. 
 
IDENTIFICATION DIVISION. 
 
PROGRAM-ID.  PROG2. 
 
ENVIRONMENT DIVISION. 
 
DATA DIVISION. 
 
ROUTINE DIVISION. 
 
 
001-MAIN. 
        DISPLAY " ". 
        DISPLAY "THIS MESSAGE DISPLAYED BY PROGRAM PROG2". 
        DISPLAY " ". 
        DISPLAY "WHICH WAS RUN BY PROGRAM PROG1". 
        DISPLAY " ". 
        DISPLAY "USING LIB$RUN_PROGRAM". 
        STOP RUN. 
 

7.2.3 Executing a CLI Command

The LIB$DO_COMMAND routine stops program execution and directs the CLI to execute a command. The routine's argument is the text of the command line that you want to execute.

This routine is especially useful when you want to execute a CLI command after your program has finished executing. For example, you could set up a series of conditions, each associated with a different command. You could also use the routine to execute a SUBMIT or PRINT command to handle a file that your program creates.

Because of the following restrictions on LIB$DO_COMMAND, you should be careful when you incorporate it in your program.

You can also use LIB$DO_COMMAND to execute a DCL command file. To do this, include the at sign (@) along with a command file specification as the input argument to the routine.

Some DCL CLI$ routines perform the functions of LIB$DO_COMMAND. See the OpenVMS DCL Dictionary for more information.

Example

The following PL/I example prompts the user for a DCL command to execute after the program exits:


EXECUTE: ROUTINE OPTIONS (MAIN) RETURNS (FIXED BINARY (31)); 
 
DECLARE LIB$DO_COMMAND ENTRY (CHARACTER (*))  /* Pass DCL command  */ 
                                              /*  by descriptor    */ 
         RETURNS (FIXED BINARY (31));         /* Return status     */ 
%INCLUDE $STSDEF;    /* Include definition of return status values */ 
 
DECLARE COMMAND CHARACTER (80); 
 
        GET LIST (COMMAND) OPTIONS (PROMPT('DCL command to execute: ')); 
        STS$VALUE = LIB$DO_COMMAND (COMMAND); 
/* 
   If the call to LIB$DO_COMMAND is successful, the program will terminate 
   here.  Otherwise, it will return the error status to command level. 
*/ 
 
        RETURN (STS$VALUE); 
 
END EXECUTE; 

This example displays the following prompt:


DCL command to execute: 

What you type after this prompt determines the action of LIB$DO_COMMAND. LIB$DO_COMMAND executes any command that is entered as a valid string according to the syntax of PL/I. If the command you enter is incomplete, you are prompted for the rest of the command. For example, if you enter the SHOW command, you receive the following prompt:


$_Show what?:

7.2.4 Using Symbols and Logical Names

The RTL provides a number of routines that give you access to the CLI callback facility. These routines allow a program to "call back" to the CLI to perform functions that normally are performed by CLI commands. These routines perform the following functions:
LIB$GET_SYMBOL Returns the value of a CLI symbol as a string.

Optionally, this routine also returns the length of the returned value and a value indicating whether the symbol was found in the local or global symbol table. This routine executes only when the current CLI is DCL.

LIB$SET_SYMBOL Causes the CLI to define or redefine a CLI symbol.

The optional argument specifies whether the symbol is to be defined in the local or global symbol table; the default is local. This routine executes only when the current CLI is DCL.

LIB$DELETE_SYMBOL Causes the CLI to delete a symbol.

An optional argument specifies the local or global symbol table. If the argument is omitted, the symbol is deleted from the local symbol table. This routine executes only when the current CLI is DCL.

LIB$SET_LOGICAL Defines or redefines a supervisor-mode process logical name.

Supervisor-mode logical names are not deleted when an image exits. This routine is equivalent to the DCL command DEFINE. LIB$SET_LOGICAL allows the calling program to define a supervisor-mode process logical name without itself executing in supervisor mode.

LIB$DELETE_LOGICAL Deletes a supervisor-mode process logical name.

This routine is equivalent to the DCL command DEASSIGN. LIB$DELETE_LOGICAL does not require the calling program to be executing in supervisor mode to delete a supervisor-mode logical name.

For information about using logical names, see Chapter 12.

7.2.5 Disabling and Enabling Control Characters

Two run-time library routines, LIB$ENABLE_CTRL and LIB$DISABLE_CTRL, allow you to call the CLI to enable or disable control characters. These routines take a longword bit mask argument that specifies the control characters to be disabled or enabled. Acceptable values for this argument are LIB$M_CLI_CTRLY and LIB$M_CLI_CTRLT.
LIB$DISABLE_CTRL Disables CLI interception of control characters.

This routine performs the same function as the DCL command SET NOCONTROL= n, where n is T or Y.

It prevents the currently active CLI from intercepting the control character specified during an interactive session.

For example, you might use LIB$DISABLE_CTRL to disable CLI interception of Ctrl/Y. Normally, Ctrl/Y interrupts the current command, command procedure, or image. If LIB$DISABLE_CTRL is called with LIB$M_CLI_CTRLY specified as the control character to be disabled, Ctrl/Y is treated like Ctrl/U followed by a carriage return.

LIB$ENABLE_CTRL Enables CLI interception of control characters.

This routine performs the same function as the DCL command SET CONTROL= n, where n is T or Y.

LIB$ENABLE_CTRL restores the normal operation of Ctrl/Y or Ctrl/T.

7.2.6 Creating and Connecting to a Subprocess

You can use LIB$SPAWN and LIB$ATTACH together to spawn a subprocess and attach the terminal to that subprocess. These routines will execute correctly only if the current CLI is DCL. For more information on the SPAWN and ATTACH commands, see the OpenVMS DCL Dictionary. For more information on creating processes, see Chapter 1.
LIB$SPAWN Spawns a subprocess.

This routine is equivalent to the DCL command SPAWN. It requests the CLI to spawn a subprocess for executing CLI commands.

LIB$ATTACH Attaches the terminal to another process.

This routine is equivalent to the DCL command ATTACH. It requests the CLI to detach the terminal from the current process and reattach it to a different process.

7.3 Access to VAX Machine Instructions

The VAX instruction set was designed for efficient use by high-level languages and, therefore, contains many functions that are directly useful in your programs. However, some of these functions cannot be used directly by high-level languages.

The run-time library provides routines that allow your high-level language program to use most VAX machine instructions that are otherwise unavailable. On Alpha machines, these routines execute a series of Alpha instructions that emulate the operation of the VAX instructions. In most cases, these routines simply execute the instruction, using the arguments you provide. Some routines that accept string arguments, however, provide some additional functions that make them easier to use.

These routines fall into the following categories:

The VAX Architecture Reference Manual describes the VAX instruction set in detail.

7.3.1 Variable-Length Bit Field Instruction Routines

The variable-length bit field is a VAX data type used to store small integers packed together in a larger data structure. It is often used to store single flag bits.

The run-time library contains five routines for performing operations on variable-length bit fields. These routines give higher-level languages that do not have the inherent ability to manipulate bit fields direct access to the bit field instructions in the VAX instruction set. Further, if a program calls a routine written in a different language to perform some function that also involves bit manipulation, the called routine can include a call to the run-time library to perform the bit manipulation.

Table 7-3 lists the run-time library variable-length bit field routines.

Table 7-3 Variable-Length Bit Field Routines
Entry Point Function
LIB$EXTV Extracts a field from the specified variable-length bit field and returns it in sign-extended longword form.
LIB$EXTZV Extracts a field from the specified variable-length bit field and returns it in zero-extended longword form.
LIB$FFC Searches the specified field for the first clear bit. If it finds one, it returns SS$_NORMAL and the bit position ( find-pos argument) of the clear bit. If not, it returns a failure status and sets the find-pos argument to the start position plus the size.
LIB$FFS Searches the specified field for the first set bit. If it finds one, it returns SS$_NORMAL and the bit position ( find-pos argument) of the set bit. If not, it returns a failure status and sets the find-pos argument to the start position plus the size.
LIB$INSV Replaces the specified field with bits 0 through [ size -1] of the source ( src argument). If the size argument is 0, nothing is inserted.

Three scalar attributes define a variable bit field:

Figure 7-1 shows the format of a variable-length bit field. The shaded area indicates the field.

Figure 7-1 Format of a Variable-Length Bit Field


Bit fields are zero-origin, which means that the routine regards the first bit in the field as being the zero position. For more detailed information about VAX bit numbering and data formats, see the VAX Architecture Reference Manual.

The attributes of the bit field are passed to an RTL routine in the form of three arguments in the following order:

pos

Bit position relative to the base address. The pos argument is the address of a signed longword integer that contains this bit position.

size

Size of the bit field. The size argument is the address of an unsigned byte that contains this size.

base

Base address. The base argument contains the address of the base address.

Example

The following BASIC example illustrates three RTL routines. It opens the terminal as a file and specifies HEX> as the prompt. This prompt allows you to get input from the terminal without the question mark that VAX BASIC normally adds to the prompt in an INPUT statement. The program calls OTS$CVT_TZ_L to convert the character string input to a longword. It then calls LIB$EXTZV once for each position in the longword to extract the bit in that position. Because LIB$EXTVZ is called with a function reference within the PRINT statement, the bits are displayed.


10      EXTERNAL LONG FUNCTION 
                OTS$CVT_TZ_L,           ! Convert hex text to LONG 
                LIB$EXTZV               ! Extract zero-ended bit field 
 
20      OPEN "TT:" FOR INPUT AS FILE #1%     ! Open terminal as a file 
        INPUT #1%, "HEX>"; HEXIN$            ! Prompt for input 
        STAT%=OTS$CVT_TZ_L(HEXIN$, BINARY%)   ! Convert to longword 
        IF (STAT% AND 1%) <> 1%               ! Failed? 
        THEN 
                PRINT "Conversion failed, decimal status ";STAT% 
                GO TO 20                      ! Try again 
        ELSE 
                PRINT HEXIN$, 
                PRINT STR$(LIB$EXTZV(N%, 1%, BINARY%)); 
                        FOR N%=31% to 0% STEP -1% 


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
5841PRO_019.HTML