Instalación de procesamiento de transacciones

Transaction Processing Facility (TPF) ^[2] es un sistema operativo en tiempo real de IBM para computadoras mainframe que desciende de la familia IBM System/360 , que incluye zSeries y System z9 .

TPF ofrece procesamiento de transacciones rápido, de gran volumen y alto rendimiento, manejando grandes cargas continuas de transacciones esencialmente simples en redes grandes y geográficamente dispersas.

Si bien existen otros sistemas de procesamiento de transacciones de nivel industrial, en particular los propios CICS e IMS de IBM , la especialidad de TPF es el volumen extremo, la gran cantidad de usuarios simultáneos y los tiempos de respuesta muy rápidos. Por ejemplo, se encarga del procesamiento de transacciones con tarjeta de crédito VISA durante la temporada alta de compras navideñas. ^{[3] [2]}

La aplicación de reserva de pasajeros TPF PARS , o su versión internacional IPARS, es utilizada por muchas aerolíneas. PARS es un programa de aplicación ; TPF es un sistema operativo.

Uno de los principales componentes opcionales de TPF es una base de datos especializada de alto rendimiento denominada TPF Database Facility (TPFDF). ^[4]

Un primo cercano de TPF, el monitor de transacciones ALCS , fue desarrollado por IBM para integrar los servicios de TPF en el sistema operativo de mainframe más común MVS , ahora z/OS .

TPF surgió del Airline Control Program (ACP), un paquete gratuito desarrollado a mediados de los años 60 por IBM en asociación con importantes aerolíneas de Norteamérica y Europa. En 1979, IBM presentó TPF como reemplazo de ACP y como un producto de software de pago. El nuevo nombre sugiere su mayor alcance y su evolución hacia entidades no relacionadas con las aerolíneas.

TPF era tradicionalmente un entorno de lenguaje ensamblador IBM System/370 por razones de rendimiento, y muchas aplicaciones de ensamblador de TPF persisten. Sin embargo, versiones más recientes de TPF fomentan el uso de C. Otro lenguaje de programación llamado SabreTalk nació y murió en TPF.

IBM anunció la entrega de la versión actual de TPF, denominada z/TPF V1.1, en septiembre de 2005. Lo más importante es que z/TPF agrega direccionamiento de 64 bits y exige el uso de herramientas de desarrollo GNU de 64 bits. ^{[5] [6]}

El compilador GCC y los compiladores DIGNUS Systems/C++ y Systems/C son los únicos compiladores compatibles con z/TPF. Los compiladores Dignus ofrecen cambios reducidos en el código fuente al pasar de TPF 4.1 a z/TPF.

Los usuarios actuales incluyen a Sabre (reservas), VISA Inc. (autorizaciones), American Airlines , ^[7] American Express (autorizaciones), DXC Technology SHARES (reservas), Amtrak , Marriott International , Travelport (Galileo, Apollo, Worldspan), Citibank , Trenitalia (reservas), Delta Air Lines (reservas y operaciones) y Japan Airlines . ^[8]

Aunque el 3083 de IBM estaba destinado a ejecutar TPF en un " monoprocesador rápido ", ^[9] TPF es capaz de ejecutarse en un multiprocesador , es decir, en sistemas en los que hay más de una CPU. Dentro de la LPAR , las CPU se denominan flujos de instrucciones o simplemente flujos I. Cuando se ejecuta en una LPAR con más de un flujo I, se dice que TPF se ejecuta en modo de acoplamiento estrecho . TPF se adhiere a los conceptos de SMP ; no existe ningún concepto de distinciones basadas en NUMA entre direcciones de memoria.

La profundidad de la lista de CPU preparada se mide a medida que se recibe cualquier transacción entrante y se pone en cola para el flujo de entrada con la demanda más baja, manteniendo así un equilibrio de carga continuo entre los procesadores disponibles. En los casos en que las configuraciones acopladas de forma flexible se llenan con CPC multiprocesador ( complejo de procesamiento central , es decir, la máquina física empaquetada en un gabinete de sistema ), la SMP se lleva a cabo dentro del CPC como se describe aquí, mientras que el uso compartido de recursos entre CPC se lleva a cabo como se describe en Acoplamiento flexible , a continuación.

En la arquitectura TPF, toda la memoria (excepto un área de prefijo de 4 KB ) se comparte entre todos los flujos I. En los casos en que los datos residentes en la memoria deben o deberían mantenerse separados por flujos I, el programador normalmente asigna un área de almacenamiento en una cantidad de subsecciones igual a la cantidad de flujos I, luego accede al área asociada al flujo I deseada tomando la dirección base del área asignada y agregándole el producto del número relativo de flujos I por el tamaño de cada subsección.

TPF es capaz de soportar múltiples mainframes (de cualquier tamaño, ya sea un I-stream único o múltiples I-stream) que se conectan y operan en una base de datos común. Actualmente, 32 mainframes IBM pueden compartir la base de datos TPF; si un sistema de este tipo estuviera en funcionamiento, se llamaría 32-way loosely coupled . El sistema de acoplamiento flexible más simple sería dos mainframes IBM que comparten un DASD ( Direct Access Storage Device ). En este caso, el programa de control se cargaría de manera equitativa en la memoria y cada programa o registro en el DASD podría ser accedido potencialmente por cualquiera de los mainframes.

Para serializar los accesos entre registros de datos en un sistema acoplado de forma flexible, se debe utilizar una práctica conocida como bloqueo de registros . Esto significa que cuando un procesador de mainframe obtiene una retención de un registro, el mecanismo debe evitar que todos los demás procesadores obtengan la misma retención y comunicar a los procesadores solicitantes que están esperando. Dentro de cualquier sistema acoplado de forma flexible, esto es fácil de gestionar entre flujos de datos mediante el uso de la tabla de retención de registros . Sin embargo, cuando el bloqueo se obtiene fuera del procesador TPF en la unidad de control DASD, se debe utilizar un proceso externo. Históricamente, el bloqueo de registros se lograba en la unidad de control DASD mediante un RPQ conocido como LLF (Limited Locking Facility) y más tarde ELLF (extended). Tanto LLF como ELLF fueron reemplazados por Multipathing Lock Facility (MPLF). Para ejecutar z/TPF en clúster (acoplado de forma flexible) se requiere MPLF en todas las unidades de control de disco o un dispositivo de bloqueo alternativo llamado Coupling Facility. ^{[10] [11]}

Los registros que deben ser gestionados de forma obligatoria mediante un proceso de bloqueo de registros son aquellos que se comparten con el procesador. En TPF, la mayoría de los accesos a los registros se realizan mediante el tipo de registro y el ordinal . Dado un tipo de registro en el sistema TPF de 'FRED' con 100 registros u ordinales, en un esquema de procesamiento compartido, el tipo de registro 'FRED' ordinal '5' se resolvería exactamente en la misma dirección de archivo en DASD, lo que requeriría el uso de un mecanismo de bloqueo de registros.

Se accederá a todos los registros compartidos del procesador en un sistema TPF a través de la misma dirección de archivo que se resolverá en la misma ubicación.

Un registro único de procesador es aquel que se define de tal manera que cada procesador que se espera que esté en el complejo acoplado de forma flexible tiene un tipo de registro de 'FRED' y quizás 100 ordinales. Sin embargo, si un usuario en 2 o más procesadores examina la dirección de archivo en la que se resuelve el tipo de registro 'FRED', ordinal '5', notará que se utiliza una dirección física diferente.

TPF no es un sistema operativo de propósito general. La función especializada de TPF es procesar mensajes de entrada de transacciones y luego devolver mensajes de salida en una proporción 1:1 en un volumen extremadamente alto con límites máximos de tiempo transcurridos muy cortos.

TPF no tiene una funcionalidad de interfaz gráfica de usuario incorporada y nunca ha ofrecido facilidades de visualización gráfica directa: implementarla en el host se consideraría una desviación innecesaria y potencialmente dañina de los recursos del sistema en tiempo real. La interfaz de usuario de TPF está controlada por línea de comandos con terminales de visualización de texto simples que se desplazan hacia arriba, y no hay cursores, ventanas o íconos controlados por mouse en un TPF Prime CRAS ^[12] ( conjunto de agente de sala de computadoras , que se considera mejor como la "consola del operador"). Los mensajes de caracteres están destinados a ser el modo de comunicación con los usuarios humanos. Todo el trabajo se realiza mediante el uso de la línea de comandos, similar a UNIX sin X. Hay varios productos disponibles que se conectan a Prime CRAS y brindan funciones de interfaz gráfica al operador de TPF, como TPF Operations Server . ^[13] Las interfaces gráficas para los usuarios finales, si se desean, deben ser proporcionadas por sistemas externos. Dichos sistemas realizan análisis sobre el contenido de los caracteres (consulte Screen scrape ) y convierten el mensaje a/desde la forma gráfica deseada, según su contexto.

Al ser un sistema operativo de propósito especializado, TPF no aloja un compilador/ensamblador, editor de texto ni implementa el concepto de un escritorio como se podría esperar encontrar en un sistema operativo de propósito general. El código fuente de la aplicación TPF se almacena comúnmente en sistemas externos y, de la misma manera, se crea "fuera de línea". A partir de z/TPF 1.1, Linux es la plataforma de creación compatible; los programas ejecutables destinados a la operación z/TPF deben respetar el formato ELF para s390x-ibm-linux.

Para utilizar TPF es necesario conocer su Guía de comandos ^[14], ya que no existe un "directorio" de comandos en línea ni una función de ayuda "man" a la que los usuarios estén acostumbrados. Los comandos creados y enviados por IBM para la administración del sistema de TPF se denominan "mensajes funcionales", comúnmente denominados " mensajes Z ", ya que todos tienen como prefijo la letra "Z". Las demás letras están reservadas para que los clientes puedan escribir sus propios comandos.

TPF implementa la depuración en un modo cliente-servidor distribuido, lo cual es necesario debido a la naturaleza multiprocesadora y sin interfaz gráfica del sistema: pausar todo el sistema para detener una sola tarea sería altamente contraproducente. Los paquetes de depuración han sido desarrollados por proveedores externos que adoptaron enfoques muy diferentes para las operaciones de "interrupción/continuación" requeridas en el host TPF, implementando protocolos de comunicación únicos utilizados en el tráfico entre el desarrollador humano que ejecuta el cliente de depuración y el controlador de depuración del lado del servidor, así como la forma y función de las operaciones del programa de depuración en el lado del cliente. Dos ejemplos de paquetes de depuración de terceros son Step by Step Trace de Bedford Associates ^[15] y CMSTPF , TPF/GI y zTPFGI , todos de TPF Software, Inc. ^[16]. Ninguno de los paquetes es totalmente compatible con el otro, ni con la propia oferta de IBM. La oferta del cliente de depuración de IBM está empaquetada en un IDE llamado IBM TPF Toolkit . ^[17]

TPF está altamente optimizado para permitir que los mensajes de la red compatible se envíen a otra ubicación, se enruten a una aplicación (un conjunto específico de programas) o para permitir accesos extremadamente eficientes a los registros de la base de datos.

Históricamente, todos los datos del sistema TPF tenían que caber en tamaños de registro (y bloque de memoria) fijos de 381, 1055 y 4K bytes. Esto se debía en parte a los tamaños de registro físico de los bloques ubicados en DASD. Se ahorraba mucha sobrecarga al liberar cualquier parte del sistema operativo de dividir grandes entidades de datos en otras más pequeñas durante las operaciones de archivo y volver a ensamblarlas durante las operaciones de lectura. Dado que el hardware de IBM realiza la E/S mediante el uso de canales y programas de canal , TPF generaría programas de canal muy pequeños y eficientes para realizar su E/S, todo en nombre de la velocidad. Dado que en los primeros días también se le daba prioridad al tamaño de los medios de almacenamiento, ya sea memoria o disco, las aplicaciones TPF evolucionaron para hacer cosas muy poderosas mientras utilizan muy pocos recursos.

En la actualidad, muchas de estas limitaciones se han eliminado. De hecho, los registros DASD de menos de 4K todavía se utilizan gracias a la compatibilidad con versiones anteriores. Con los avances logrados en la tecnología DASD, la lectura y escritura de un registro de 4K es tan eficiente como la de un registro de 1055 bytes. Los mismos avances han aumentado la capacidad de cada dispositivo, de modo que ya no se da tanta importancia a la capacidad de comprimir datos en el modelo más pequeño posible.

TPF también tuvo sus segmentos de programa asignados como registros de tamaño de 381, 1055 y 4K bytes en diferentes puntos de su historia. Cada segmento consistía en un solo registro; con una aplicación típicamente completa que requería quizás decenas o incluso cientos de segmentos. Durante los primeros cuarenta años de la historia de TPF, estos segmentos nunca fueron editados por enlaces . En cambio, el código de objeto reubicable (salida directa del ensamblador) se disponía en la memoria, se resolvían sus símbolos reubicables internamente (autorreferenciales) y luego se escribía toda la imagen en un archivo para cargarla más tarde en el sistema. Esto creó un entorno de programación desafiante en el que los segmentos relacionados entre sí no podían direccionarse directamente entre sí , y la transferencia de control entre ellos se implementaba como el servicio de sistema ENTER/BACK .

En los primeros días de ACP/TPF (circa 1965), el espacio de memoria estaba severamente limitado, lo que dio lugar a una distinción entre programas residentes en archivos y residentes en el núcleo : solo los programas de aplicación utilizados con más frecuencia se escribían en la memoria y nunca se eliminaban ( residencia en el núcleo ); el resto se almacenaban en archivos y se leían a pedido, y sus búferes de memoria de respaldo se liberaban después de la ejecución.

La introducción del lenguaje C en TPF en la versión 3.0 se implementó primero de acuerdo con las convenciones de segmentos, incluida la ausencia de edición de enlaces. Este esquema demostró rápidamente ser poco práctico para cualquier cosa que no fuera el más simple de los programas en C. En TPF 4.1, se introdujeron módulos de carga verdaderamente y completamente enlazados en TPF. Estos se compilaron con el compilador C/C++ de z/OS utilizando archivos de encabezado específicos de TPF y se vincularon con IEWL , lo que resultó en un módulo de carga conforme a z/OS, que de ninguna manera podría considerarse un segmento TPF tradicional. El cargador TPF se amplió para leer el formato de archivo de módulo de carga exclusivo de z/OS y ​​luego diseñar las secciones de módulos de carga residentes en el archivo en la memoria; mientras tanto, los programas en lenguaje ensamblador permanecieron confinados al modelo de segmentos de TPF , lo que creó una disparidad obvia entre las aplicaciones escritas en ensamblador y las escritas en lenguajes de nivel superior (HLL).

En z/TPF 1.1, todos los tipos de lenguaje fuente se unificaron conceptualmente y se editaron completamente para cumplir con la especificación ELF . El concepto de segmento se volvió obsoleto, lo que significa que cualquier programa escrito en cualquier lenguaje fuente, incluido el ensamblador, ahora puede ser de cualquier tamaño. Además, se hicieron posibles las referencias externas y los programas de código fuente separados que alguna vez habían sido segmentos ahora se podían vincular directamente entre sí para formar un objeto compartido . Un punto de valor es que las aplicaciones heredadas críticas pueden beneficiarse de una mayor eficiencia a través de un simple reempaquetado : las llamadas realizadas entre miembros de un único módulo de objeto compartido ahora tienen una longitud de ruta mucho más corta en tiempo de ejecución en comparación con las llamadas al servicio ENTER/BACK del sistema . Los miembros del mismo objeto compartido ahora pueden compartir regiones de datos escribibles directamente gracias a la funcionalidad de copia en escritura también introducida en z/TPF 1.1; que casualmente refuerza los requisitos de reentrada de TPF .

Los conceptos de residencia en archivos y memoria también quedaron obsoletos debido a un punto de diseño de z/TPF que buscaba que todos los programas residieran en la memoria en todo momento.

Dado que z/TPF tenía que mantener una pila de llamadas para programas de lenguaje de alto nivel, lo que daba a los programas HLL la capacidad de beneficiarse de la asignación de memoria basada en pila , se consideró beneficioso extender la pila de llamadas a programas de lenguaje ensamblador de forma opcional, lo que puede aliviar la presión de la memoria y facilitar la programación recursiva .

Todos los programas ejecutables z/TPF ahora están empaquetados como objetos compartidos ELF.

Históricamente y en sintonía con el anterior, los bloques centrales (la memoria) también tenían un tamaño de 381, 1055 y 4 K bytes. Como TODOS los bloques de memoria tenían que ser de este tamaño, se descartaba la mayor parte de la sobrecarga para obtener memoria que se encontraba en otros sistemas. El programador solo necesitaba decidir qué tamaño de bloque se ajustaría a la necesidad y solicitarlo. TPF mantendría una lista de bloques en uso y simplemente entregaría el primer bloque de la lista disponible.

La memoria física se dividió en secciones reservadas para cada tamaño, de modo que un bloque de 1055 bytes siempre provenía de una sección y regresaba allí; el único trabajo adicional necesario era agregar su dirección a la lista de la tabla de bloques físicos correspondiente. No se requirió compactación ni recopilación de datos.

A medida que las aplicaciones se volvieron más avanzadas, las demandas de memoria aumentaron y, una vez que C estuvo disponible, se necesitaron fragmentos de memoria de tamaño indeterminado o grande. Esto dio lugar al uso de almacenamiento en montón y algunas rutinas de gestión de memoria. Para aliviar la sobrecarga, la memoria TPF se dividió en marcos de 4 KB de tamaño (1 MB con z/TPF). Si una aplicación necesita una cierta cantidad de bytes, se le concede la cantidad de marcos contiguos necesarios para cubrir esa necesidad.

• Transaction Processing Facility: A Guide for Application Programmers (Serie informática Yourdon Press) de R. Jason Martin (tapa dura, abril de 1990), ISBN 978-0139281105 

• z/TPF (IBM)
• Grupo de usuarios de TPF (Grupo de usuarios de TPF)