Document revision date: 19 July 1999

The execution of Ctrl/Y does not automatically reset the default Ctrl/Y action (that is, to prompt for command input at the Ctrl/Y command level). A Ctrl/Y action remains in effect until one of the following conditions occurs:

• The procedure terminates (as a result of pressing Ctrl/Y, executing an EXIT or STOP command, or a default error condition handling action).
• Another ON CONTROL_Y command is executed.
• The procedure executes the SET NOCONTROL=Y command (see Section 15.13).

A Ctrl/Y action can be specified in each active command level and affects only the command level in which it is specified.

When the command procedure shown in the following example executes, each Ctrl/Y interruption results in the execution of the SHOW TIME command. After each SHOW TIME command executes, the procedure resumes execution at the command following the command that was interrupted:

$ ON CONTROL_Y THEN SHOW TIME

Figure 15-2 illustrates the flow of execution following Ctrl/Y interruptions.

Figure 15-2 Flow of Execution Following Ctrl/Y Action

1. The Ctrl/Y interruption occurs during the execution of the TYPE command.
2. Control is then transferred to the label CLEAN_UP.
3. After executing the routine, the command procedure exits and returns to the interactive command level.
4. The Ctrl/Y interruption occurs during the execution of the TYPE command.
5. The WRITE command specified in the ON command is executed.
6. The command procedure continues execution at the command following the interrupted command.

Figure 15-3 illustrates what happens when Ctrl/Y is pressed during the execution of nested command procedures.

Figure 15-3 Ctrl/Y in Nested Procedures

1. If a Ctrl/Y interruption occurs while SEARCH.COM is executing, control is transferred to the label CLEAN_UP.
2. If a Ctrl/Y interruption occurs while SUBSEARCH.COM is executing, control is transferred to the label NEXT_STEP in SEARCH.COM.
3. Because no Ctrl/Y action is specified in SUBSEARCH.COM, the procedure exits to the previous command level when a Ctrl/Y interruption occurs.
4. If a Ctrl/Y interruption occurs while SUBSUB.COM is executing, the SHOW TIME is executed.

The following sections describe how to disable and enable Ctrl/Y interruptions.

15.13.1 Using SET NOCONTROL=Y

The SET NOCONTROL=Y command disables Ctrl/Y handling. That is, if a command procedure executes the SET NOCONTROL=Y command, pressing Ctrl/Y has no effect.

The SET NOCONTROL=Y command also cancels the current Ctrl/Y action established with the ON CONTROL_Y command. To reestablish the default Ctrl/Y action, use the following two commands:

$ SET NOCONTROL=Y $ SET CONTROL=Y

The SET NOCONTROL=Y command disables Ctrl/Y handling and cancels the current ON CONTROL_Y action. The SET CONTROL=Y command enables Ctrl/Y handling. At this point, the default action is reinstated. That is, if Ctrl/Y is pressed during the execution of the procedure, the command interpreter prompts for a command at the Ctrl/Y command level.

You can use the SET NOCONTROL=Y command at any command level. It affects all command levels until the SET CONTROL=Y command reenables Ctrl/Y handling.

15.13.2 Using SET CONTROL=Y

An ON CONTROL_Y command remains in effect until another ON CONTROL_Y or a SET NOCONTROL=Y command executes or the command procedure exits.

To exit from a nonterminating loop when Ctrl/Y is disabled, you must delete your process from another terminal using the DCL command STOP. If you disable the default Ctrl/Y action, reset it as soon as possible. To reset the default Ctrl/Y action, execute the SET NOCONTROL=Y command followed by the SET CONTROL=Y command.

In this command procedure, pressing Ctrl/Y while a file is being typed passes control to the label END_TYPE:

. . . $! Type a file $ IF COMMAND .NES. "TY" THEN GOTO END_TYPE $ ON CONTROL_Y THEN GOTO END_TYPE $ TYPE 'FILESPEC' $END_TYPE: $! $! Reset default $ SET NOCONTROL=Y $ SET CONTROL=Y . . .

When each DCL command in a command procedure completes execution, the command interpreter saves a condition code that describes the reason why the command terminated. This code can indicate successful completion or it can identify an informational or error message.

The command interpreter examines the condition code after it performs each command in a command procedure. If an error that requires special action has occurred, the system performs the action. Otherwise, the next command in the procedure executes.

15.14.1 Displaying Condition Codes ($STATUS)

The command interpreter saves the condition code as a 32-bit longword in the reserved global symbol $STATUS. The $STATUS symbol conforms to the format of a system message code as follows:

• Bits 0--2 contain the severity level of the message.
• Bits 3--15 contain the message number.
• Bits 16--27 contain the number associated with the facility that generated the message.
• Bits 28--31 contain internal control flags.

When a command completes successfully, $STATUS has an odd value. (Bits 0--2 contain a 1 or a 3.) When any type of warning or error occurs, $STATUS has an even value. (Bits 0--2 contain a 0, 2, or 4.) The command interpreter maintains and displays the current hexadecimal value of $STATUS. You can display the ASCII translation of $STATUS by entering the SHOW SYMBOL $STATUS command.

In the following example, the file name (%FRED.LIS) is entered incorrectly:

$ CREATE %FILE.LIS %CREATE-E-OPENOUT, error opening %FRED.LIS; as output -RMS-F-WLD, invalid wildcard operation $ SHOW SYMBOL $STATUS $STATUS = " %X109110A2" $ WRITE SYS$OUTPUT F$MESSAGE(%X109110A2) %CREATE-E-OPENOUT, error opening !AS as output

15.14.2 Condition Codes with the EXIT Command

When a command procedure exits, the command interpreter returns the condition code for the previous command in $STATUS. The condition code provides information about whether the most recent command executed successfully.

When you use the EXIT command in a command procedure, you can specify a value that overrides the value that DCL would have assigned to $STATUS. This value, called a status code, must be specified as an integer expression.

When a command procedure contains nested procedures to create multiple command levels, you can use the EXIT command to return a value that explicitly overrides the default condition codes.

Examine the following two command procedures:

$! This is file A.COM $! $ @B . . .

$! This is file B.COM $! $ ON WARNING THEN GOTO ERROR . . . $ ERROR: $ EXIT 1

The ON command in B.COM means that if any warnings, errors, or severe errors occur when B.COM is executing, the procedure is directed to the label ERROR. Here, the condition code is explicitly set to 1, indicating success. Therefore, when B.COM terminates, it passes a success code back to A.COM regardless of whether an error occurred.

15.14.3 Determining Severity Levels

The low-order three bits of $STATUS represent the severity of the condition that caused the command to terminate. This portion of the condition code is contained in the reserved global symbol $SEVERITY. The $SEVERITY symbol can have the values 0 to 4, with each value representing one of the following severity levels:

Value	Severity
0	Warning
1	Success
2	Error
3	Information
4	Fatal (severe) error

Note that the success and information codes have odd numeric values, and warning and error codes have even numeric values.

15.14.4 Testing for Successful Completion

You can test for the successful completion of a command with IF commands that perform logical tests on $SEVERITY or $STATUS as follows:

$ IF $SEVERITY THEN GOTO OKAY $ IF $STATUS THEN GOTO OKAY

These IF commands branch to the label OKAY if $SEVERITY and $STATUS have true (odd) values. When the current value in $SEVERITY and $STATUS is odd, the command or program completed successfully. If the command or program did not complete successfully, then $SEVERITY and $STATUS are even; therefore, the IF expression is false.

Instead of testing whether a condition is true, you can test whether it is false. For example:

$ IF .NOT. $STATUS THEN ...

The command interpreter uses the severity level of a condition code to determine whether to take the action defined by the ON command as described in Section 15.9.

15.15 Using Commands That Do Not Set $STATUS

Most DCL commands invoke system utilities that generate status values and error messages when they complete. However, there are several commands that do not change the values of $STATUS and $SEVERITY if they complete successfully. These commands are as follows:

CONTINUE	DECK	DEPOSIT
EOD	EXAMINE	GOTO
IF	RECALL	SET SYMBOL/SCOPE
SHOW STATUS	SHOW SYMBOL	STOP
WAIT

If any of these commands result in a nonsuccessful status, the condition code is placed in $STATUS and the severity level is placed in $SEVERITY.

15.16 Login Command Procedures

A login command procedure is a command procedure that the operating system automatically executes each time you log in. The system also executes this procedure at the beginning of every batch job that you submit.

There are two types of login command procedures:

• Systemwide (or group-defined)
• Personal

Systemwide login command procedures have the following characteristics:

• They are executed before your personal login command procedure
• When a systemwide login command procedure terminates, it passes control to your personal login command procedure
• They allow your system manager to make sure that certain commands are always executed when you log in

To establish a systemwide login command procedure, your system manager equates the logical name SYS$SYLOGIN to the appropriate login command procedure. Your system manager can specify that this login command procedure be used for all system users or for a certain group of users.

15.16.2 Personal Login Command Procedures

You can create a personal login command procedure to execute the same commands each time you log in.

Your system manager assigns the file specification for your login command procedure. In most installations, the login command procedure is called LOGIN.COM. Therefore, you should name your login command procedure LOGIN.COM unless your system manager tells you otherwise.

Refer to Appendix C for a complete annotated LOGIN.COM procedure.

15.16.3 Login Command Procedures in Captive Accounts

Your system manager can set up captive accounts by placing the name of a special command procedure in the LGICMD field for your account. If you log in to a captive account, you can perform only functions specified in the command procedure for your account; you cannot use the complete set of DCL commands. For more information about captive accounts, refer to the OpenVMS System Manager's Manual.

Advanced DCL programming includes the use of complex command procedures and the DCL command PIPE.

Complex command procedures can perform program-like functions. You can use variable input in a command procedure, execute sections of the procedure only if certain conditions are true, execute subroutines, or invoke other command procedures.

You can also use the DCL command PIPE to perform program-like functions. For example, using the PIPE command, you can execute one or more of the following operations from the same DCL command line:

• Pipelining (a sequence of commands)
• Input/output redirection
• Multiple and conditional command execution
• Background processing

This chapter includes information about the following:

• Performing command procedure input
• Using parameters to pass data to nested command procedures
• Performing command procedure output
• Reading and writing files (file I/O)
• Handling file I/O errors
• Techniques for controlling execution flow
• Creating new command levels
• Writing Case statements
• Using the PIPE command

You should read this chapter if you:

• Have read Chapter 15
• Have basic knowledge of programming in DCL and want to learn more advanced methods

For additional information, refer to the following:

• The OpenVMS DCL Dictionary, for complete information about the commands discussed in this chapter
• The OpenVMS Guide to Extended File Specifications, for additional information about programming with DCL in an evironment with Extended File Specifications

Command procedures frequently require data provided by a user. This data, or input, can be obtained either interactively (as described in Chapter 15) or noninteractively. This chapter discusses noninteractive input methods, and different interactive methods than those described in Chapter 15.

You can use the same data each time a command procedure executes. To do this, place the data in the command procedure on data lines following the command that requires the data.

This command procedure executes the command procedure CENSUS.EXE. CENSUS.EXE reads the data 1993, 1994, and 1995 each time the procedure executes:

$ ! CENSUS.COM $ ! $ RUN CENSUS 1993 1994 1995 $ EXIT

16.1.1 Restrictions to Including Data in Command Procedures

DCL passes the text on a data line directly to the command procedure. Therefore, it will not process data that must be translated such as:

• Symbols
• Logical names
• Arithmetic expressions

Other methods of obtaining input data for command procedures that are described in the following sections are:

• Using parameters to pass data
• Using parameters to pass data to batch jobs
• Using parameters to pass data to nested command procedures
• Using the INQUIRE and READ commands to prompt for data
• Using the SYS$INPUT logical name to obtain data

The following list contains guidelines for passing parameters as data to command procedures:

• Place the parameters after the file specification of the command procedure.
• You can pass up to eight parameters to a command procedure.
• If you pass fewer than eight parameter values, the extra symbols are assigned null values. A null value is a string with no characters and is represented by quotation marks (" ").
• Separate the parameters with one or more spaces or tabs.

DCL places parameters passed to command procedures in the local symbols P1 to P8. P1 is assigned to the first parameter value, P2 the second, P3 the third, and so on. For example, the following command invokes the command procedure SUM.COM and passes eight parameters to the procedure:

$ @SUM 34 52 664 89 2 72 87 3

16.2.1 Specifying Parameters as Integers

When you specify an integer as a parameter, it is converted to a string. In the following example, P1 is the string value 24; P2 is the string value 25:

$ @ADDER 24 25

You can use the symbols P1 to P8 in both integer and character string expressions; DCL performs the necessary conversions automatically.

16.2.2 Specifying Parameters as Character Strings

To preserve spaces, tabs, or lowercase characters in a character string, place quotation marks (" ") before and after the string. For example:

$ @DATA "Paul Cramer"

In the following example, P1 is Paul Cramer and P2 is null. If you omit the quotation marks, each character string is passed as a separate parameter. For example:

$ @DATA Paul Cramer

In this example, the strings Paul and Cramer are converted to uppercase letters; P1 is PAUL and P2 is CRAMER.

As another example, if you invoke DATA.COM with the following command:

$ @DATA "Paul Cramer" 24 "(555) 111-1111")

P1 to P8 are defined in DATA.COM as follows:

• P1 = Paul Cramer
• P2 = 24
• P3 = (555) 111-1111
• P4--P8 = null

To pass the value of a symbol, place an apostrophe before and after the symbol. To preserve spaces, tabs, and lowercase characters in the symbol value, enclose the value in three sets of quotation marks. You must also use three sets of quotation marks to include a quotation mark as part of a string.

An alternative is to enclose the text in quotation marks and where a symbol appears, precede the symbol with two apostrophes and follow it with one apostrophe.

In the following example, P1 is Paul and P2 is Cramer because DCL removes quotation marks when you pass a symbol to a command procedure:

$ NAME = "Paul Cramer" $ @DATA 'NAME'

In the following example, P1 is "Paul Cramer" and P2 is null:

$ NEW_NAME = """Paul Cramer""" $ @DATA 'NEW_NAME'

In the following example, P1 is translated to Paul Cramer:

$ ! DATA.COM $ @NAME "''P1'"

16.2.4 Specifying Parameters as Null Values

To pass a null parameter, use one set of quotation marks as a placeholder in the command string. In the following example, the first parameter passed to DATA.COM is a null parameter:

$ @DATA "" "Paul Cramer"

In this example, P1 is null and P2 is Paul Cramer.

16.3 Using Parameters to Pass Data to Batch Jobs

To pass parameters to a command procedure executed in batch mode, use the SUBMIT command qualifier /PARAMETERS.

If you execute more than one command procedure using a single SUBMIT command, the specified parameters are used for each command procedure in the batch job.

In the following example, the command passes three parameters to the command procedures ASK.COM and GO.COM, which are executed as batch jobs:

$ SUBMIT/PARAMETERS=(TODAY,TOMORROW,YESTERDAY) ASK.COM, GO.COM)

In the following example, the SUBMIT command passes two parameters to the command procedures: LIBRARY.COM and SORT.COM:

$ SUBMIT- _$ /PARAMETERS=(DISK:[ACCOUNT.BILLS]DATA.DAT,DISK:[ACCOUNT]NAME.DAT) - _$ LIBRARY.COM, SORT.COM

The batch job executes as if you had logged in and executed each of the command procedures. This SUBMIT command executes a batch job that logs in under your account, executes your login command procedure, and then executes the following commands:

$ @LIBRARY DISK:[ACCOUNT.BILLS]DATA.DAT DISK:[ACCOUNT]NAME.DAT) $ @SORT DISK:[ACCOUNT.BILLS]DATA.DAT DISK:[ACCOUNT]NAME.DAT)

You can also pass data to a batch job by including the data in a command procedure or by defining SYS$INPUT to be a file. The specified parameters are used for each command procedure in the batch job.

	privacy and legal statement
6489PRO_040.HTML