CMS Pipelines

CMS Pipelines is a feature of the VM/CMSoperating system that allows the user to create and use a pipeline. The programs in a pipeline operate on a sequential stream of records. A program writes records that are read by the next program in the pipeline. Any program can be combined with any other because reading and writing is done through a device independent interface.

CMS Pipelines provides a CMS command, PIPE. The argument string to the PIPE command is the pipeline specification. PIPE selects programs to run and chains them together in a pipeline to pump data through.

Because CMS programs and utilities don't provide a device independent stdin and stdout interface, CMS Pipelines has a built-in library of programs that can be called in a pipeline specification. These built-in programs interface to the operating system, and perform many utility functions.

Data on CMS is structured in logical records rather than a stream of bytes. For textual data a line of text corresponds to a logical record. In CMS Pipelines the data is passed between the stages as logical records.

CMS Pipelines users issue pipeline commands from the terminal or in EXEC procedures. Users can write programs in REXX that can be used in addition to the built-in programs.

A simple example that reads a disk file, separates records containing the string "Hello" from those that do not. The selected records are modified by appending the string "World!" to each of them; the other records are translated to upper case. The two streams are then combined and the records are written to a new output file.

PIPE (end ?) < input txt | a: locate /Hello/ | insert / World!/ after | i: faninany | > newfile txt a ? a: | xlate upper | i:

In this example, the < stage reads the input disk file and passes the records to the next stage in the pipeline. The locate stage separates the input stream into two output streams. The primary output of locate (records containing Hello) passes the records to the insert stage. The insert stage modifies the input records as specified in its arguments and passes them to its output. The output is connected to faninany that combines records from all input streams to form a single output stream. The output is written to the new disk file.

La salida secundaria de locate(marcada por la segunda aparición de la a:etiqueta) contiene los registros que no cumplieron con el criterio de selección. Estos registros se convierten a mayúsculas (por la xlateetapa) y se pasan al flujo de entrada secundario de faninany(marcado por la segunda aparición de la i:etiqueta).

La topología de la canalización en este ejemplo consta de dos canalizaciones conectadas. El carácter final (el ?en este ejemplo) separa las canalizaciones individuales en el conjunto de canalizaciones. Los registros leídos del archivo de entrada pasan por cualquiera de las dos rutas de la topología de la canalización. Dado que ninguna de las rutas contiene etapas que necesiten almacenar registros en búfer, CMS Pipelines garantiza que los registros lleguen en faninanyel orden en que pasaron por locate.

El ejemplo de flujo de trabajo se presenta en formato vertical, con cada etapa en una línea separada. Cuando se introduce un flujo de trabajo como comando CMS, todas las etapas se muestran en una sola línea.

El concepto de tubería simple se amplía de las siguientes maneras:

• Un programa puede definir una secuencia de subrutinas para realizar una función sobre la totalidad o parte de sus datos de entrada.
• Se puede definir una red de tuberías interconectadas. Los programas pueden estar en varias tuberías simultáneamente, lo que les da acceso a múltiples flujos de datos.
• Los datos que se pasan de una etapa a la siguiente están estructurados como registros. Esto permite que las etapas operen con un único registro sin necesidad de almacenar datos en búfer de forma arbitraria para buscar caracteres especiales que separen las líneas individuales.
• Normalmente, las etapas acceden al registro de entrada en modo de localización y generan los registros de salida antes de consumir el registro de entrada. Este enfoque secuencial no solo evita copiar los datos de un búfer a otro, sino que también permite predecir el flujo de registros en flujos de datos múltiples.
• Un programa puede redefinir dinámicamente la topología de la canalización. Puede reemplazarse a sí mismo con otra canalización, insertar un segmento de canalización antes o después de sí mismo, o ambas cosas. Un programa puede usar los datos de la canalización para construir sus especificaciones.

CMS Pipelines ofrece varias características para mejorar la solidez de los programas:

• Un error de sintaxis en la estructura general del pipeline o en cualquiera de los programas individuales provoca que se suprima todo el pipeline.
• El gestor de flujos de datos de CMS coordina el inicio de los programas en la cadena de procesamiento y la asignación de recursos . Los programas individuales pueden participar en esta coordinación para garantizar que las acciones irreversibles se pospongan hasta que todos los programas de la cadena hayan tenido la oportunidad de verificar los argumentos y estén listos para procesar los datos. Cuando finaliza la cadena de procesamiento, el gestor se encarga de liberar los recursos.
• Los errores que se producen durante el flujo de datos en la canalización pueden ser detectados por todos los programas participantes. Por ejemplo, en tales circunstancias, un archivo de disco podría no ser reemplazado.

John Hartmann, de IBM Dinamarca, comenzó el desarrollo de CMS Pipelines en 1980. ^{[ 1 ]} IBM comercializó el producto como un producto independiente durante la década de 1980 y lo integró en VM/ESA a finales de 1991. Con cada lanzamiento de VM, el código de CMS Pipelines también se actualizó hasta que se congeló funcionalmente en el nivel 1.1.10 en VM/ESA 2.3 en 1997. Desde entonces, la última versión de CMS Pipelines está disponible para su descarga en la página web de CMS Pipelines para los usuarios que deseen explorar nuevas funciones.

El nivel actual de CMS Pipelines se incluye de nuevo en las versiones de z/VM desde z/VM 6.4, disponible desde el 11 de noviembre de 2016.

En 1995 se lanzó una implementación de CMS Pipelines para TSO denominada BatchPipeWorks dentro del producto BatchPipes/MVS . La implementación actualizada de TSO estuvo disponible como servicio ofrecido por IBM Dinamarca hasta 2010.

Ambas versiones se mantienen a partir de una única base de código fuente y se conocen comúnmente como Pipelines CMS/TSO . La especificación está disponible en la Edición del Autor. ^{[ 2 ]}

También puedes encontrar implementaciones de código abierto en Java y Swift . ^{[ 3 ] [ 4 ]}

• Tuberías por lotes
• Shell (informática)
• Programación basada en flujo

• Distribución de la biblioteca de tiempo de ejecución de las canalizaciones CMS/TSO