BatchPipes to Job Optimizer Pipes conversion

This conversion can be done gradually. First, rules can be defined for new jobs that are implementing Job Optimizer Pipes. Later, existing jobs can be changed to use rules instead of BatchPipes subsystem parameters.

Before starting the conversion, note the following differences between BatchPipes or BatchPipes-compatible pipes processing and Job Optimizer Pipes pipes processing:

• In BatchPipes, the participant type is decided according to the Open type (input - reader; output - writer). The JCL DISP parameter is not used.

  However, in Job Optimizer Pipes, the participant type is decided according to the PRTYPE subsystem parameter (if specified), the JCL DISP parameter, and the Pipe Rule definition (if the job was specifically defined in the rule).

• In Job Optimizer Pipes, the number of participants that are allowed to access the pipe is controlled by the Minimum writers, Additional writers, Minimum readers, and Additional readers options. Only the number of participants that is specified in these options is allowed to access the pipe (if the Additional writers option or the Additional readers option is set to Y, any number of participants can access the pipe).

  This feature is different in BatchPipes processing, in which any number of participants can access the pipe while it is active. The Accept additional writers and Accept additional readers initialization parameters affect only BatchPipes-compatible pipes and do not control the number of participants for Job Optimizer Pipes.

• DCB parameters support for Job Optimizer Pipes:
  • BUFNO and EROPT parameters are not used for Job Optimizer Pipes pipes processing. If these parameters are used for BatchPipes processing, the appropriate Pipe Rule option should be set. Check which options should be set and how to interpret the values.
  • The LRECL, RECFM, and BLKSIZE parameters that are specified on the DD statement are used as the pipe attributes, unless they are overridden during Open. This feature is different from BatchPipes support. In BatchPipes, if these parameters are specified on the DD statement, they are used as the pipe attributes even if they are overridden during Open.
• Open processing differences:
  • In BatchPipes, a reader can close and reopen the pipe several times during its process. In Job Optimizer Pipes, a reader can reopen the pipe only if it did not read anything from the pipe. If the reader opens the pipe, reads data, closes and opens the pipe again, it fails.
  • In BatchPipes, a participant is allowed to close the pipe and reopen it as a different participant type, (for example, a writer can write to the pipe, close it, and then open it as a reader). This process is not allowed in Job Optimizer Pipes. If a participant wants to connect to the pipe with a different type, it has to deallocate the pipe and then allocate the pipe again.
• Several Pipe Rule options do not have equivalent BatchPipes subsystem parameters. These options offer features that do not exist in BatchPipes and might be considered when converting from BatchPipes to Job Optimizer Pipes pipes. These parameters are as follows:
  • The Reader data option defines which portion of the data the reader will read. This option affects the processing of pipes that have multiple readers:
    • N - (default) indicates that each reader will read the next available data block from the pipe. BatchPipes also works this way.
    • A - indicates that all of the readers of the pipe will read all of the data from the pipe. There is no equivalent BatchPipes parameter. To achieve this functionality in BatchPipes, a fitting has to be created by the pipe writer or reader to write the data to another pipe and this pipe is read by another reader that needs to read all of the pipe data. If there are jobs that are using this method to enable multiple readers to read all of the data, these jobs can be changed to access the same pipe, and the Reader data option should be set to A.
    • The Writer signals EOF=Deallocation definition allows the writer to open and close the pipe several times during its process without writing end-of-file. The end-of-file is written when the writer finishes its process and deallocates the pipe. The reader receives the end-of-file indication after the writer finishes writing all of the data.
  • The Writer signals EOF=Deallocation definition allows the writer to open and close the pipe several times during its process without writing end-of-file. The end-of-file is written when the writer finishes its process and deallocates the pipe. The reader receives the end-of-file indication after the writer finishes writing all of the data.
  • The Reader error option=Delay definition specifies that when Job Optimizer Pipes encounters an error in the pipe processing, it allows the reader to continue reading from the pipe until end-of-file is received. The reader then abends. This option prevents losing data that was written to the pipe but still indicates that there was a problem in the process.

The first step of the conversion should be to review the pipe default rule (member JOPDEFRL) and modify it as needed to ensure that correct defaults will be used for all pipes. If the conversion is done gradually while using BatchPipes-compatible pipes, the fields that are used for BatchPipes-compatible pipes should not be changed. Change these values only after full conversion is finished.