The “preprocessing” and “postprocessing” functions make it possible to execute any commands (operating system commands, procedures, etc.) with the aid of a file transfer request in the local and remote systems. The commands are passed to the corresponding system instead of the file name. To do this, the following applies:
the file name must be enclosed in double quotes (Unix systems and Windows systems) or must be specified as a C string (BS2000, z/OS).
The first character is a pipe symbol ’|‘. Then follow the commands, separated by ';' (or '&' or '&&' in Windows systems, in which case the command string must start with cmd /c). The maximum length of the pre- and postprocessing command is limited by the maximum length of the file name.
If the characters ’|&’ are specified instead of the pipe symbol, the transfer request is restartable, see "Preprocessing and postprocessing".
Preprocessing passes the result to the system’s standard output (SYSLST on BS2000, SYSPRINT on z/OS, stdout on Unix systems and Windows systems). Postprocessing reads the data from the relevant system’s standard input (SYSIN on BS2000, SYSTSIN on z/OS, stdin on Unix systems and Windows systems). However, the standard output/input does not usually support all the file formats possible at the system in question. You can avoid this restriction by using the %TEMPFILE variable instead of the standard output/input. This has the advantage of permitting the use of any required file format. Even if a preprocessing command cannot be output to the standard output or if a postprocessing command cannot read from standard input, normally it may be helpful to specify %TEMPFILE in the request parameters.
Pre- and postprocessing are part of the request brackets. The issuer of the request always receives a feedback report on the successful or unsuccessful completion of the pre/postprocessing.
You should note the following when using the pre/postprocessing function:
Preprocessing/postprocessing runs as part of the file transfer operation and under the same transfer admission. These specifications are either explicitly stated in the file transfer request or in a transmission profile’s USER-ADMISSION.
If the request is handled via an admission profile, the FILE-PROCESSING function must be permitted in the profile or, alternatively, a file name prefix starting with the pipe symbol '|' must be defined.
When non-restartable pre/postprocessing is involved, the connection to the partner must remain intact until the entire processing session is completed.
Restart capability during preprocessing and postprocessing
During restartable pre- and postprocessing, the data to be transferred between openFT and the processing command is always saved to a temporary file. By this means, the request is divided into 3 phases: preprocessing, transfer and postprocessing.
The restart capability of a pre- and postprocessing session is brought about when you specify an additional “&” before pre- and postprocessing in the transfer command. During this, requests made with openFT partners behave as follows:
Loss of connection during preprocessing:
If the connection is lost during the execution of the preprocessing command, the command is still executed until completion after the connection is lost. If the system is restarted after the command has completed execution, then the temporary file is transferred.Loss of connection during transmission:
In this case openFT performs a restart for the temporary file as is usually the case.Loss of connection during postprocessing:
If the connection is lost during the execution of the postprocessing command, the command is still executed until completion after the connection is lost. If the system is restarted, then all other actions left over that belong to the openFT request are performed (e.g. any follow-up processing or the status report to the partner).
Notes on BS2000 systems
The openFT subsystem cannot be stopped, as long as there are still restartable requests, whose pre- and postprocessing sessions have not been completed. If this is taking too long, the system administrator can cancel the batch jobs belonging to the requests (using the CANCEL command). In this case, the message FTR2083 is displayed during the next restart of openFT.
If restartable requests are still active in the command execution phase when openFT is stopped using STOP-FT, then shut-down is delayed by up to 2 minutes. If command execution still has not been completed after 2 minutes, openFT will be stopped and the request will be cancelled during the next START-FT.
Notes on Unix systems and Windows systems
The temporary file is stored in the directory .openFTTmp and is deleted only after the command has finished execution (regardless of whether or not the command was successful or unsuccessful).
.openFTTmp is created by openFT if it does not yet exist. It is located in the home directory of the corresponding user. On the local host this user is the user under whose user ID the request was started. On the remote host this user is the user whose user ID was specified or who is the owner of the specified transfer admission.
Server function for remote command execution (ftexec)
One special form of preprocessing is the server function for the remote command execution (ftexec command for Unix and Windows systems, EXECUTE-REMOTE-CMD command for BS2000 and FTEXEC command for z/OS). This command makes it possible to execute commands on a remote system. The exit code and/or the output from stdout and stderr (Unix or Windows systems), SYSLST and SYSOUT (BS2000) or STDOUT=SYSPRINT und STDERR=SYSTSPR (z/OS) are output at the local computer. This command thus acts as the execution of the command on the local computer.