CMS Pipelines implementa el concepto de canalización bajo el sistema operativo VM / CMS . Los programas en una tubería operan en un flujo secuencial de registros. Un programa escribe registros que lee el siguiente programa de la canalización. Cualquier programa se puede combinar con cualquier otro porque la lectura y la escritura se realizan a través de una interfaz independiente del dispositivo.
Paradigma | Programación de flujo de datos |
---|---|
Diseñada por | John P. Hartmann ( IBM ) |
Desarrollador | IBM |
Apareció por primera vez | 1986 |
Lanzamiento estable | 1.1.12 / 0012 / 2020-06-03 |
Plataforma | IBM z Systems |
SO | z / VM 7.1 |
Sitio web | http://vm.marist.edu/~pipeline |
Influenciado por | |
Canalización (Unix) |
Descripción general
Tuberías CMS proporciona un comando CMS, PIPE
. La cadena de argumentos del PIPE
comando es la especificación de la canalización. PIPE selecciona programas para ejecutar y los encadena en una tubería para bombear datos.
Debido a que los programas y utilidades de CMS no proporcionan una interfaz stdin y stdout independiente del dispositivo , CMS Pipelines tiene una biblioteca incorporada de programas que se pueden llamar en una especificación de canalización. Estos programas integrados se conectan al sistema operativo y realizan muchas funciones de utilidad.
Los datos en CMS están estructurados en registros lógicos en lugar de un flujo de bytes. Para datos textuales, una línea de texto corresponde a un registro lógico. En CMS Pipelines, los datos se pasan entre las etapas como registros lógicos.
Los usuarios de CMS Pipelines emiten comandos de canalización desde la terminal o en los procedimientos EXEC. Los usuarios pueden escribir programas en REXX que se pueden utilizar además de los programas integrados.
Ejemplo
Un ejemplo simple que lee un archivo de disco, separa los registros que contienen la cadena "Hola" de aquellos que no la contienen. Los registros seleccionados se modifican agregando la cadena "¡Mundo!" a cada uno de ellos; los otros registros se traducen a mayúsculas. Luego, las dos secuencias se combinan y los registros se escriben en un nuevo archivo de salida.
TUBO (¿fin?) | a: localizar / Hola / | insertar / World! / after | yo: faninany | > archivo nuevo txt a ? a: | xlate superior | I:
En este ejemplo, la <
etapa lee el archivo de disco de entrada y pasa los registros a la siguiente etapa de la canalización. La locate
etapa separa el flujo de entrada en dos flujos de salida. La salida principal de locate
(registros que contienen Hello) pasa los registros al insert
escenario. La insert
etapa modifica los registros de entrada como se especifica en sus argumentos y los pasa a su salida. La salida está conectada a faninany
eso combina registros de todos los flujos de entrada para formar un único flujo de salida. La salida se escribe en el nuevo archivo de disco.
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 traducen a mayúsculas (por xlate
etapa) 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 ( ?
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. Debido a que ninguna de las rutas contiene etapas que necesiten almacenar registros en búfer, CMS Pipelines asegura que los registros lleguen faninany
en el orden en que pasaron locate
.
La canalización de ejemplo se presenta en "forma de retrato" con las etapas individuales en líneas separadas. Cuando una canalización se escribe como un comando CMS, todas las etapas se escriben en una sola línea.
Características
El concepto de canalización simple se amplía de estas formas:
- Un programa puede definir una canalización de subrutinas para realizar una función en todos o en parte de sus datos de entrada.
- Se puede definir una red de tuberías que se cruzan. Los programas pueden estar en varias canalizaciones al mismo tiempo, lo que le da acceso al programa a múltiples flujos de datos.
- Los datos que se pasan de una etapa a la siguiente se estructuran como registros. Esto permite que las etapas operen en un solo registro sin la necesidad de almacenar datos arbitrariamente en el búfer para buscar caracteres especiales que separen las líneas individuales.
- Las etapas normalmente acceden al registro de entrada en el modo de localización y producen los registros de salida antes de consumir el registro de entrada. Este enfoque de paso de bloqueo no solo evita copiar los datos de un búfer al siguiente; también permite predecir el flujo de registros en tuberías de múltiples flujos.
- Un programa puede redefinir dinámicamente la topología de la canalización. Puede reemplazarse a sí mismo con otra canalización, puede insertar un segmento de canalización antes o después de sí mismo, o ambos. Un programa puede usar datos en la canalización para construir especificaciones de canalización.
CMS Pipelines ofrece varias características para mejorar la solidez de los programas:
- Un error de sintaxis en la estructura general de la canalización o en cualquier programa hace que se suprima toda la canalización.
- El despachador de CMS Pipelines coordina la puesta en marcha de los programas en proceso y la asignación de recursos . Los programas individuales pueden participar en esa coordinación para garantizar que las acciones irreversibles se pospongan hasta un punto en el que todos los programas en proceso hayan tenido la oportunidad de verificar los argumentos y estén listos para procesar los datos. Cuando se termina la canalización, el despachador se asegura de que los recursos se liberen nuevamente.
- Todos los programas participantes pueden detectar los errores que ocurren mientras los datos fluyen en la tubería. Por ejemplo, es posible que un archivo de disco no se reemplace en tales circunstancias.
Historia
John Hartmann, de IBM Dinamarca, comenzó el desarrollo de CMS Pipelines en 1980. [1] El producto fue comercializado por IBM como un producto separado durante los años 80 y se 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, el último nivel de CMS Pipelines ha estado disponible para descargar desde la página de inicio de CMS Pipelines para los usuarios que deseen explorar nuevas funciones .
El nivel actual de la CMS Tuberías está incluido en el z / VM libera de nuevo desde z / VM 6.4, disponible desde noviembre 11 2016.
En 1995 se lanzó una implementación de CMS Pipelines para TSO como BatchPipeWorks en el producto BatchPipes / MVS . La implementación de TSO actualizada ha estado disponible como una oferta de servicio de IBM Dinamarca hasta 2010.
Ambas versiones se mantienen a partir de una única base de código fuente y se conocen comúnmente como CMS / TSO Pipelines . La especificación está disponible en la edición del autor. [2]
Ver también
Referencias
- ^ VM y la comunidad VM, Melinda Varian
- ^ Edición de autor de CMS / TSO Pipelines Edición de autor