Document revision date: 30 March 2001

## OpenVMS User's Manual

Previous | Contents | Index

## 18.2 Using Detached Processes

A detached process is either interactive or noninteractive, depending on the parent process. Either you or the operating system perform the login, depending on the argument you provided to the DCL command RUN or the Create Process system service ($CREPRC). (Both RUN and $CREPRC execute the LOGINOUT.EXE image in SYS$SYSTEM.)

## 18.3 Using Subprocesses

The SPAWN command enables you to create a subprocess of your current process. Within this subprocess, you can interact with the system and log out of the subprocess to return to your parent process or switch between your parent process and subprocesses. Only one of your processes is executing at any time.

Each user on the system is represented by a job tree. A job tree is a hierarchy of all your processes and subprocesses with your main process at the top. A subprocess is dependent on the parent process and is deleted when the parent process exits. By default, the subprocess assumes the name of the parent process followed by an underscore and a unique number. For example, if the parent process name is DOUGLASS, the subprocesses are named DOUGLASS_1, DOUGLASS_2, and so on.

### 18.3.1 Using Subprocesses to Spawn Tasks

To interrupt a task, perform a second task, then return to the original task, you can use Ctrl/Y to interrupt the first task, spawn a subprocess to perform the second task, exit from the subprocess, and then enter the CONTINUE command to return to the first task. By default, when you create a subprocess, the parent process hibernates and you are given control at DCL level within the subprocess. Your default directory is the current directory of the parent process. For example, if you press Ctrl/Y to interrupt an EVE editing session, enter the CONTINUE command and press Ctrl/W to refresh the screen.

### 18.3.2 Using Subprocesses to Perform Multiple Tasks

To perform a second task while continuing to work on your original task, you can create the subprocess with the SPAWN/NOWAIT command. SPAWN/NOWAIT generates a noninteractive, batch-like subprocess and is used to execute only commands that do not require input.

Because both the parent and the subprocess are executing concurrently, both attempt to control the terminal. To prevent conflicts, also specify the following:

- /OUTPUT qualifier
  Indicates that the subprocess should write output to a specified file rather than to the terminal
- SPAWN command parameter or /INPUT qualifier
  Indicates that the subprocess should execute the specified commands rather than reading input from the terminal

When you specify the /INPUT qualifier of the SPAWN command, the subprocess is created as a noninteractive process that exits upon encountering a severe error or an end-of-file indicator. At DCL level, Ctrl/Z is treated as an end-of-file indicator.

### 18.3.3 Creating a Subprocess

Because each process you create is unique, commands executed in one process do not usually affect any other process. However, because control of the terminal passes between processes, commands that affect the terminal characteristics (for example, SET TERMINAL) affect any process controlling that terminal. For example, if one process inhibits echoing and exits without restoring it, echoing remains inhibited for the next process that gains control of the terminal. Reset any altered terminal characteristics with the SET TERMINAL command.

In the following example, a user interrupts a command image (the TYPE command) by pressing Ctrl/Y, spawns a subprocess, exits from the subprocess, and returns to the original process:

    $ TYPE MICE.TXT
    Once the weather turns cold, mice may find a crack in the
    foundation and enter your house.  They are looking for food and
    shelter from the harsh weather ahead.
       .
       .
       .
    [Ctrl/Y]
    $ SPAWN
    %DCL-S-SPAWNED, process DOUGLASS_1 spawned
    %DCL-S-ATTACHED, terminal now attached to process DOUGLASS_1
    $ MAIL
    MAIL>
       .
       .
       .
    MAIL> EXIT
    $ LOGOUT
      Process DOUGLASS_1 logged out at 31-DEC-1999 12:42:12.46
    %DCL-S-RETURNED, control returned to process DOUGLASS
    $ CONTINUE
    Once inside, they may gnaw through electrical wires and raid
    your food. Because mice reproduce so quickly, what started
    as one or two mice can quickly become an invasion.  If you seal
    the cracks and holes on the exterior of your foundation, you can
    prevent these rodents from ever getting in.

### 18.3.4 Exiting from a Subprocess

To exit from a subprocess created by the SPAWN command, use one of the following commands:

- LOGOUT
  When you exit from a subprocess with the LOGOUT command, the subprocess is deleted (along with any subprocesses that it created) and you are returned to the parent process.
- ATTACH
  When you exit from a subprocess with the ATTACH command, the subprocess hibernates and control of your terminal is transferred to the specified process. You must specify either a process name as a parameter to the ATTACH command or a process identification (PID) number as a value of the /IDENTIFIER qualifier of the ATTACH command.

The following example shows how to exit from the subprocess DOUGLASS_1 and attach to the process DOUGLASS:

    $ ATTACH DOUGLASS
    %DCL-S-RETURNED, control returned to process DOUGLASS
    $ SHOW PROCESS
    11-DEC-1999 10:34:58.50   VTA303             User: DOUGLASS
    Pid: 25C002B4   PROG. name: DOUGLASS         UIC: [200,200]
    Priority:   4   Default file spec: SYS$SYSDEVICE:[DOUGLASS]

    Devices allocated: $11$VTA303:

### 18.3.5 Subprocess Context

The subprocess context is the environment that the subprocess inherits from the parent process. By default, a subprocess inherits the following items: defaults, privileges, symbols, logical names, control characters, message format, verification state, and key definitions. Collectively, these items create an environment for the subprocess.

The following items are not inherited from parent processes:

- Process identification (PID) number
  The system assigns each created subprocess a unique PID number.
- Process name
  By default, the subprocess name consists of the name of the parent process followed by an underscore and an integer. Use the /PROCESS qualifier of the SPAWN command to specify a process name other than the default. A process name must be unique.
- Created commands
  Commands that are defined by a parent process using the SET COMMAND command are not copied to a subprocess. To use a created command in a subprocess, you must use SET COMMAND to create that command for the subprocess.
- Authorize privileges
  When you spawn to a subprocess, the process context contains the privileges of the parent process, not the privileges that you are authorized to enable. For example, if you plan to spawn to a subprocess while in Mail and to perform a privileged operation, you must first set the proper privilege in the parent process before you invoke Mail.

You can use the following SPAWN command qualifiers to prevent the subprocess from inheriting a number of these items:

SPAWN Command Qualifier | Items Inhibited or Changed
--- | ---
/CARRIAGE_CONTROL, /PROMPT | DCL prompt
/NOCLI | CLI (command language interpreter; DCL by default)
/NOKEYPAD | Keypad definitions
/NOLOGICAL_NAMES | Logical names
/NOSYMBOL | Symbols

The /SYMBOL and /LOGICAL_NAMES qualifiers do not affect system-defined symbols (such as $SEVERITY and $STATUS) or system-defined logical names (such as SYS$COMMAND and SYS$OUTPUT).

Because copying logical names and symbols to a subprocess can be time-consuming (a few seconds), you may want to use the /NOLOGICAL_NAMES and /NOSYMBOL qualifiers to the SPAWN command unless you plan to use the logical names or symbols in the subprocess. If you use subprocesses frequently, the ATTACH command provides the most efficient way to enter and exit a subprocess. This method allows you to transfer control quickly between the parent process and subprocess rather than repeatedly waiting for the system to create a new subprocess for you.

## 18.4 Connecting to Disconnected Processes on Virtual Terminals

If virtual terminals are enabled and a modem line connection is lost, a process remains active on the system as a disconnected virtual terminal process. You must reconnect to the process within the time period specified by the system manager (the default value is 900 seconds or 15 minutes). If you fail to reconnect to the process before this time expires, the system deletes the process.

Note You can connect only to a virtual terminal process associated with your user identification code (UIC).

### 18.4.1 Terminal Disconnections

A terminal can be disconnected in the following circumstances:

- You lose the modem signal between the host and the terminal.
- You press the BREAK key on a terminal with the TT2$M_SECURE characteristic set.
- You enter the DCL command DISCONNECT.
- You enter the DCL command CONNECT/CONTINUE.

If your process is disconnected, you have the option of reconnecting to the old process and returning to the state it was in before you were disconnected. When you log in, the system prompts you as follows:

        You have the following disconnected process:
    Terminal   Process name    Image name
    VTA52:     RWOODS          (none)
    Connect to above listed process [YES]:

If you press the Return key or enter Yes, you are logged out of your current process as if automatic execution of the DCL command CONNECT/CONTINUE had been performed for you. If you enter No or if you delay too long in responding (so that a response period timeout occurs), you remain logged in to your new process. You lose the ability to connect to the old process.

When you have multiple disconnected sessions, you are prompted for the name of the virtual terminal to which you want to reconnect. If you do not want to connect to any of the displayed sessions, enter No.

### 18.4.2 Removing Disconnected Processes

The system automatically removes your disconnected processes after a certain interval. You can conserve system resources, however, if you directly log out of any disconnected processes, as follows:

Step | Task
--- | ---
1 | Enter the DCL command SHOW USERS to determine if you have other disconnected jobs.
2 | Enter the DCL command CONNECT/LOGOUT to log out of the current process. Connect back through each of the associated virtual terminals (as noted by the terminal prefix VTA) until you reach the last existing process.
3 | Enter the DCL command LOGOUT.

### 18.4.3 Managing Disconnected Processes

Virtual terminals allow you to maintain more than one disconnected process at a time. You must keep in mind, however, that while you are logged in to a virtual terminal, the physical terminal is disconnected. Any I/O requests directed to a device other than the physical terminal associated with your current virtual terminal process will enter a waiting state. The pending process will terminate when the timeout period expires. If, however, you reconnect to the physical terminal that is to receive the I/O request, the process continues from the point at which it entered the waiting state. Naming each process with a name that relates to its context makes it easier to reconnect to the desired process.

For example, a user named SMITH running a process to edit a file might use the SET PROCESS/NAME command to name the process SMITH_EDIT. Later, to continue editing, SMITH can easily determine which process is appropriate.

A system manager can restrict the use of virtual terminals systemwide or on a per terminal basis.

## 18.5 Working with Batch Jobs

A batch job is a noninteractive process. Because a batch job executes in a process of its own, you can have two or more processes doing different things at the same time. For example, you can use batch jobs to:

- Perform a task interactively while the system executes a program or command procedure in batch mode
- Run command procedures that take a long time to execute
- Execute command procedures or programs after hours
- Run certain programs at a reduced priority (for example, if the program uses a disproportionate amount of system resources)

### 18.5.1 Submitting Batch Jobs

When you submit a batch job, the system creates a detached process with your account and process characteristics. The system runs the job from that process and deletes the process when the job completes. The system also executes the system login command procedure (SYLOGIN.COM) and your login command procedure (LOGIN.COM) and then executes the command procedures in the batch job. As these procedures execute, output is written to a log file. When the batch job completes, you can print the log file or save it in one of your directories.

To run a job in batch mode, submit your job to a batch queue (a list of batch jobs waiting to execute) by entering the DCL command SUBMIT. When you submit a job, it is directed to the default batch queue SYS$BATCH where it is added to the end of the queue of jobs waiting to be executed. When the jobs preceding yours are completed, your job is executed. On an OpenVMS system, the number of batch jobs that can execute simultaneously is specified when the batch queue is created by the system manager. By default, the SUBMIT command uses a file type .COM.

In the following example, the command enters JOB1.COM into SYS$BATCH:

    $ SUBMIT JOB1
    Job JOB1 (queue SYS$BATCH, entry 651, started on SYS$BATCH)

The system displays the name of the job, the queue containing the job, and the entry number assigned to the job. You receive the DCL prompt after your job is submitted to the batch queue. If you need to reference your batch job in any DCL commands (DELETE/ENTRY, for example), do so by using the job entry number. (You can obtain the job entry number by using the SHOW ENTRY command.) Note that if multiple procedures are submitted in a batch job, the batch job terminates when any procedure exits with an error or fatal (severe) system message.

Your batch job does not necessarily have to start running at the time you submit it to the batch queue. To specify a different time, enter the SUBMIT/AFTER command. In the following example, the job is submitted after 11:30 P.M.:

    $ SUBMIT/AFTER=23:30 JOB1.COM

When you submit a command procedure for batch execution, the system saves the complete file specification for the command procedure, including the version number. If you update a command procedure after you submit it, the batch job executes the version of the command procedure that you submitted rather than the new version.

Because your login defaults are not usually the defaults needed to access the files mentioned in your command procedures, use one of the following methods to ensure that the correct files are accessed:

- Use complete file specifications --- When referring to a file in a command procedure or when passing a file to a command procedure, include the device and directory names as part of the file specification.
- Use the SET DEFAULT command --- Before referring to a file in a command procedure, use the SET DEFAULT command at the beginning of the command procedure to specify the proper device and directory.

As a batch job executes, it writes output to a log file. By default, the log file has the same name as the command procedure you submit with the file type .LOG. When the job is finished, the system prints the log file and deletes it from your directory. See Section 18.5.3 for information on saving log files.

Checking for Batch Jobs in Your Login Command Procedure

Each time you submit a batch job, the system executes your login command procedure. You can cause sections of your login command procedure to be included or omitted when you execute batch jobs by using the F$MODE lexical function to test for batch jobs.

In the following example, the login command procedure includes commands, logical names, and symbols that are used exclusively for batch jobs. The section is labeled BATCH_COMMANDS, and the following command is included at the beginning of the login command procedure:

    IF F$MODE() .EQS. "BATCH" THEN GOTO BATCH_COMMANDS
       .
       .
       .

To prevent the system from executing any commands in your login command procedure when you submit a batch job, place the following command at the beginning of the procedure:

    IF F$MODE() .NES. "INTERACTIVE" THEN EXIT

You can place this command anywhere in your login command procedure. When you submit a batch job, the system executes your login command procedure only to the point at which the preceding command is placed.

Submitting Multiple Command Procedures

When you enter the SUBMIT command, you can specify several command procedures to be executed in one job. Unless you specify a name with the /NAME qualifier, the SUBMIT command uses the name of the first command procedure as the job name. Note that if an error causes any command procedure in a job to exit, the entire job terminates.

When a batch job executes, the operating context of the first procedure (UPDATE.COM) is not preserved for the second procedure (SORT.COM). The system deletes local symbols created by UPDATE.COM before SORT.COM executes. Global symbols, however, are preserved.

You cannot specify different parameters for individual command procedures within a single job.

In the following example, the SUBMIT command creates a batch job that executes UPDATE.COM then SORT.COM:

    $ SUBMIT UPDATE,SORT
    Job UPDATE (queue SYS$BATCH, entry 207) started on SYS$BATCH

The following example passes the same two parameters to UPDATE.COM and to SORT.COM:

    $ SUBMIT UPDATE, SORT/PARAMETERS = -
    _$ (DISK1:[ACCOUNT.BILLS]DATA.DAT, DISK2:[ACCOUNT]NAME.DAT)
    $ Job UPDATE (queue SYS$BATCH, ENTRY 208) started on SYS$BATCH

### 18.5.2 Passing Data to Batch Jobs

The default input stream (SYS$INPUT) for a batch job is the command procedure that is being executed. Because a detached process is executing the batch job, you cannot redefine SYS$INPUT to the terminal (as you can with command procedures that you execute interactively.) To pass input to a batch job, use one of the following techniques:

- Include the data in the command procedure itself.
  To include data in a command procedure, place the data on the lines after the command or image.
- Temporarily define SYS$INPUT as a file.
  To define SYS$INPUT temporarily as a file, use the DEFINE/USER_MODE command.
- Pass parameters to the command procedure when you submit it for execution.
  To pass parameters to a command procedure, use the /PARAMETERS qualifier when you submit the batch job.

Note that you cannot specify different parameters for individual command procedures within a single job. Use separate SUBMIT commands if you need to pass different groups of parameters.

In the following example, data lines are passed to the image AVERAGE.EXE:

    $! Execute AVERAGE.EXE
    $ RUN AVERAGE
    647
    899
    532
    401
    $ EXIT

In the following example, SYS$INPUT is temporarily defined as a file:

    $ DEFINE/USER_MODE SYS$INPUT STATS.DAT
    $ RUN AVERAGE
    $ EXIT

In the following example, the parameters in the file EMPLOYEES.DAT are passed to the command procedure CHECKS.DAT:

    $ SUBMIT/PARAMETERS=(DISK1:[PAYROLL]EMPLOYEES.DAT) CHECKS
    Job CHECKS (queue SYS$BATCH, entry 209) started on SYS$BATCH

Note The SHOW QUEUE/FULL command displays full information about jobs in a batch queue. This display includes any parameters that you pass to the procedure. Therefore, do not pass confidential information (such as a password) to a batch job.

Previous | Next | Contents | Index

| privacy and legal statement |
6489PRO_048.HTML