5.2 The exec Functions

There are six exec functions that you can call to execute a DEC C image in the child process. These functions expect that vfork has been called to set up a return address. The exec functions will call vfork if the parent process did not.

When vfork is called by the parent, the exec function returns to the parent process. When vfork was called by an exec function, the exec function returns to itself, waits for the child to exit, and then exits the parent process. The exec function does not return to the parent process unless the parent calls vfork to save the return address.

Unlike UNIX based systems, the exec functions in the DEC C RTL cannot determine if the specified program image exists. Therefore, the exec functions will appear to succeed even though the image does not exist. The status of the child process, returned to the parent process, will indicate that this error occurred. You can retrieve this error code by using the wait function.

Note

The vfork and exec functions in the DEC C RTL on OpenVMS systems work differently than on UNIX systems:

• On UNIX systems, vfork creates a child process, suspends the parent, and starts the child running where the parent left off.

• On OpenVMS systems, vfork establishes context later used by an exec, function but it is the exec function, not vfork, that starts a process running the specified program.

For a progammer, the key differences are:

• On OpenVMS systems, code between the the call to vfork and the call to an exec function runs in the parent process. On UNIX systems, this code runs in the child process.

• On OpenVMS systems, the child inherits open file descriptors and so on, at the point where the exec function is called. On UNIX systems, this occurs at the point where vfork is called.

If you really need the UNIX behavior of vfork and exec functions, consider using OpenVMS POSIX, which has an enclosed subsystem and suitable changes to the kernel to correctly implement the UNIX behavior of vfork.

5.2.1 Exec Processing

The exec functions use the LIB$SPAWN routine to create the subprocess and activate the child image within the subprocess. This child process inherits the parent's environment, including all defined logical names and command-line interpreter symbols. The exec functions use the logical name VAXC$EXECMBX to communicate between parent and child; this logical name must not exist outside the context of the parent image.

The exec functions pass the following information to the child:

• The parent's umask value, which specifies whether any access is to be disallowed when a new file is created. For more information about the umask function, see the Reference Section.

• The file-name string associated with each file descriptor and the current position within each file. The child opens the file and calls lseek to position the file to the same location as the parent. If the file is a record file, the child is positioned on a record boundary, regardless of the parent's position within the record. For more information about file descriptors, see Chapter 2. For more information on the lseek function, see the Reference Section.

  This information is sent to the child for all descriptors known to the parent including all descriptors for open files, null descriptors, and duplicate descriptors.

  File pointers are not transferred to the child. For files opened by a file pointer in the parent, only their corresponding file descriptors are passed to the child. The fdopen function must be called to associate a file pointer with the file descriptor if the child will access the file-by-file pointer. For more information about the fdopen function, see the Reference Section.

• The signal database. Only SIG_IGN (ignore) actions are inherited. Actions specified as routines are changed to SIG_ DFL (default) because the parent's signal-handling routines are inaccessible to the child.

• The environment and argument vectors.

When everything is transmitted to the child, exec processing is complete. Control in the parent process then returns to the address saved by vfork and the child's process ID is returned to the parent.

See also Section 4.2.4 for a discussion of signal actions and the SIGCHLD signal.

5.2.2 Exec Error Conditions

The exec functions will fail if LIB$SPAWN cannot create the subprocess. Conditions that can cause a failure include exceeding the subprocess quota or finding the communications by the context mailbox between the parent and child to be broken. Exceeding some quotas will not cause LIB$SPAWN to fail, but will put LIB$SPAWN into a wait state that can cause the parent process to hang. An example of such a quota is the Open File Limit quota.

You will need an Open File Limit quota of at least 20 files, with an average of three times the number of concurrent processes that your program will run. If you use more than one open pipe at a time, or perform I/O on several files at one time, this quota may need to be even higher. See your system manager if this quota needs to be increased.

When an exec function fails, a value of -1 is returned. After such a failure, the parent is expected to call either the exit or _ exit function. Both functions then return to the parent's vfork call, which returns the child's process ID. In this case, the child process ID returned by exec is less than zero. For more information about the exit function, see the Reference Section.