Distinguishing Levels of CMS/TSO Pipelines

Developers producing software that uses CMS Pipelines may encounter a variety of Pipelines versions. Distinguishing the various versions can be confusing. The easiest solution is simply to package the CMS Pipelines Runtime Library with one's software product. If that is not feasible, the following information should make the task easier:

CMS Pipelines has gone through ten modification levels since its original release. For detailed information on the contents of levels 4 through 10, see the PIPELINE NEWS files.
The original CMS Pipelines Program Offering and Programming RPQ had version numbers of the form 1.1.n. Version numbers of that form continue to be used by the IBM-internal version of Pipelines, as well as by the versions included in the the CMS Pipelines Field-Test Program and the CMS Pipelines Runtime Library Distribution. VM/ESA CMS Pipelines also uses version numbers of this form, beginning with CMS 14 (VM/ESA V2R3M0).
Versions of Pipelines that use the original version-numbering scheme produce responses to "pipe query version" of these forms:
- PIPINX086I CMS/TSO Pipelines, 5785-RAC/SB5409 1.0110 (Version.Release/Mod) - Generated 6 Feb 1997 at 07:33:19.
- FPLINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0110 (Version.Release/Mod) - Generated 29 Aug 1997 at 17:26:57.
In this response, the first digit ("1") is the version number, the second and third digits ("01") are the release number, and the last two digits ("10") are the modification level (in decimal).
These same versions of Pipelines produce responses to "pipe query level" of this form:
- PIPINX560I CMS/TSO Pipelines, 5785-RAC/SB5409 level 110A000A.
- FPLINX560I CMS/TSO Pipelines, 5664-030/5655-A17 level 110A0018.
In this response, the first digit ("1") is the version number, the second ("1") is the release number, the third and fourth ("0A") are the modification level (in hexadecimal), and the last four digits ("000A" and "0018") are the modification sublevel, as shown in PIPELINE NEWS.
VM/ESA CMS Pipelines in CMS levels 8 through 13 used a different version-numbering scheme and, thus, gave different responses to "pipe query version" and "pipe query level", even though it contained function that was equivalent to that in an internal version. For example, the version of CMS Pipelines in VM/ESA 1.2.2 (CMS 11) is equivalent to the internal version 1.1.8, but its response to "pipe query version" is:
- DMSPIN2731I CMS Pipelines (VM/ESA) 2.0202
and its response to "pipe query level" is
- DMSPIN2988I CMS Pipelines (VM/ESA) level 22020000
See the table of version level equivalences for further detail.
VM/ESA CMS Pipelines in CMS 14 (VM/ESA V2R3M0) reverts to the original version-numbering scheme. Its response to "pipe query version" is in this form:
- FPLINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0110 (Version.Release/Mod) - Generated 24 Sep 1997 at 19:25:08
and its response to "pipe query level" is in this form:
- FPLINX560I CMS/TSO Pipelines, 5654-030/5655-A17 level 110A0020
Different versions of CMS Pipelines use different message prefixes. The PO, the PRPQ, the IBM-internal version, the Field-Test version, and the Runtime Library version all use "PIP" or "FPL". For CMS levels 8 through 13, VM/ESA CMS used "DMS" as its message prefix, but CMS 14 uses "FPL". VM/ESA 370 Feature Release 1.5 uses "PPL".
Different versions of CMS Pipelines use different message numbers. Messages with the prefixes "PIP" and "FPL" use the original message numbers; messages with the prefixes "DMS" and "PPL" use another set of message numbers. See the table of message number equivalences. Note that the exact text of the two sets of messages also differs in many cases.
All versions of Pipelines for MVS display the internal modification levels and use the original message numbers. Messages issued by BatchPipeWorks have a prefix of "BPW"; all other versions of TSO Pipelines use the prefix "PIP" or "FPL".

Testing for the presence of a specific stage

The RESOLVE pipeline command is very useful when you want to test for whether a specific stage is built in to the version of Pipes you are using. A very simple way to issue RESOLVE is with a "pipcmd" stage. For example, the easiest way to decide whether "pick" is available is to issue:

'PIPE literal resolve pick | pipcmd'

"pipcmd" will exit with the return code from RESOLVE (0 if the stage is not built in, a large number (the memory address of the stage) if it is built in). That will also be the return code from the PIPE command itself.

Testing for the presence of a specific keyword

If you need to test for a specific new keyword, such as "main" in the example below, you are likely to find "runpipe" useful:

'PIPE literal rexxvars main | runpipe'/* Test whether current.       */
 
If RC <> 0  Then Do                   /* Explain must be current.    */
   Say 'The MAIN keyword of the REXXVARS stage is required.'
   Exit RC                            /* Take error return.          */
End

Melinda Varian / Office of Computing and Information Technology / Princeton University / melinda.varian@me.com

October 8, 1997