Hartmann pipeline
|
|
A Hartmann pipeline is an extension of the Unix pipeline concept, providing for more complex paths, multiple input/output streams, and other features. It is an example and extension of Pipeline programming.
A Hartmann pipe is a non-procedural representation of a solution of a data processing problem as a dataflow. The error-prone step of translating the dataflow to a traditional procedural programming language is eliminated. Hartmann pipelines may thus be considered as an executable specification language.
The concept was developed by John Hartmann, a Danish engineer with IBM. It is available as a software product CMS Pipelines for a number of IBM platforms.
| Contents |
Features
Some of the salient characteristics that distinguish Hartmann Pipeline from ordinary Unix pipes are:
- Filters may have multiple inputs and multiple outputs. For example, a selection filter can send the found records down one output pipe and the not found records down another.
- A linear notation for representing pipeline networks.
- An interface that allows REXX programs to act as filters.
- A pacing strategy in the Pipeline supervisor that allows, for example, a stream to be split, say by a selection filter, and the records on the output legs to be processed by other filters, then merged by a join filter and have the record order preserved in result stream.
- As implied by the previous item, data streams are (generally) not simply buffered and passed along to the next filter. The filters operate in parallel with input and output records handled by the Pipeline supervisor.
Example
The utility of the many filters supplied with the program is exemplified by the LOOKUP filter:
LOOKUP matches records in its primary input stream with records in its secondary input stream and writes matched and unmatched records to different output streams. The records are matched on the basis of a key field (the contents of a specified range of columns in the records).
LOOKUP reads records from its primary and secondary input streams and writes records to its primary, secondary, and tertiary output streams, if each is connected. The secondary input stream must be defined and connected.
The records in the secondary input stream are the master records. LOOKUP first reads the master records into a buffer, where records with duplicate key fields are discarded; the first occurrence of a key is retained. The records in the buffer are referred to as the reference.
The records in the primary input stream are the detail records. LOOKUP compares detail records to records in the reference. LOOKUP writes records to three output streams, if each is connected:
- The primary output stream contains matching records. You can specify the sequence of the master and detail records written to the primary output stream and what is written to the primary output stream: both detail and master records, only detail records, or only master records.
- The secondary output stream contains detail records that do not have a matching master record.
- The tertiary output stream contains master records in ascending order by their key fields. The primary and secondary output streams are severed at the end of file on the primary input stream before records are written to the tertiary output stream.
This arrangement allows one to use other filters to prepare the dictionary, or master records for input to LOOKUP from whatever source is required. The many Input/Output filters, or drivers, allow a Hartmann Pipe to interact directly with a variety data sources, from files, to the system itself, and such things as TCP/IP ports. The repertoire of filters and drivers is rich enough that one could, for example, write a server that consisted solely of a Hartmann pipeline.
Similarity to APL
Programmers familiar with the APL programming language will see some similarities in Hartmann pipelines. It is obvious that the author was influenced by APL; some of the filters have names and functions similar to specific APL primitive functions. An example is the TAKE filter, which passes a specified number of records.
As with APL, programmers adept in the use of pipelines will have their view of data processing problems and how they may be best solved fundamentally and permanently changed.
External links
- CMS/TSO Pipelines Runtime Library Distribution (http://vm.marist.edu/~pipeline/)