IBM TPNS

TPNS admite la simulación de una amplia gama de protocolos y dispositivos de red: SNA / SDLC , start-stop , BSC , TWX , TTY , X.25 Packet Switching Network , Token Ring Local Area Network y servidores y clientes TCP/IP ( Telnet 3270 y 5250 , Telnet Line Mode Network Virtual Terminal , FTP y clientes UDP simples ). ^{[ 3 ]} TPNS también puede simular dispositivos que utilizan los protocolos Airline Line Control (ALC) y HDLC . La implementación completa de SNA en TPNS le permite simular todos los tipos de LU (incluidos LU6.2 y CPI-C ), tipos de PU (incluido PU2.1) y funciones SSCP . Finalmente, TPNS también proporciona un amplio acceso de salida de usuario a sus procesos internos para permitir la simulación de disciplinas de línea , protocolos de comunicación , dispositivos ( terminales e impresoras ) y programas definidos por el usuario (desarrollados internamente) . ^{[ 3 ]}

Por lo tanto, TPNS es la herramienta de prueba adecuada para instalaciones que necesitan probar:

• ya sea la ruta de configuración completa del sistema de componentes de hardware y software, desde la interfaz de línea de teleprocesamiento ( módem , por ejemplo) hasta el subsistema ( CICS , IMS , DB2 , TSO / ISPF , etc.), la aplicación y finalmente hasta el archivo o registro de base de datos ( E/S de disco ) y viceversa;

Nota: En esta configuración, TPNS transmite el tráfico de datos generado desde su espacio de direcciones MVS , primero a través de un adaptador de canal a su Programa de Control TPNS (TPNCP) que se ejecuta en un Controlador de Comunicaciones IBM 37x5 dedicado , y luego a través de líneas de teleprocesamiento conectadas en serie entre el TPNCP y el canal IBM 37x5 de destino conectado al sistema host (servidor) bajo prueba y sus subsistemas, aplicaciones y bases de datos/archivos. ^{[ 3 ]}

• o solo los sistemas de aplicación y sus componentes de hardware y software, desde la API del método de acceso a la red (ya sea la API VTAM o la API de sockets nativos de alto rendimiento TCP/IP , o macro) hasta el subsistema (CICS, IMS, DB2, TSO/ISPF, etc.), la aplicación y finalmente hasta el archivo o registro de base de datos (E/S de disco) y viceversa;

Nota: En esta configuración, TPNS transmite el tráfico de datos generado desde su espacio de direcciones MVS a la aplicación de destino directamente a través de la API del método de acceso a la red y, por lo tanto, no requiere un controlador de comunicaciones IBM 37x5 dedicado para ejecutar su TPNCP, ni ningún otro componente de hardware y software de red, excepto el método de acceso a la red (VTAM o IBM TCP/IP para MVS) que ya se ejecuta en el sistema host (servidor) bajo prueba, o que ya está conectado a la red de este. ^{[ 3 ]}

• o ambas. ^{[ 3 ]}

WSim es totalmente compatible con un subconjunto de dispositivos simulados por TPNS y recursos programados: servidores y clientes TCP/IP CPI-C , ^{[ 13 ] : 61–72} ( Telnet 3270 y 5250 , terminal virtual de red en modo de línea Telnet , FTP y clientes UDP simples ), ^{[ 13 ] : 91–108} y simulación SNA LU . ^{[ 13 ] : 73–87} WSim se basa únicamente en interfaces de software para comunicarse con el sistema bajo prueba.

Por lo tanto, WSim es la herramienta de prueba adecuada para instalaciones que necesitan probar sistemas de aplicaciones y sus componentes de hardware y software, desde la API del método de acceso a la red (ya sea la API VTAM o la API de sockets nativos de alto rendimiento TCP/IP , o la API Macro) hasta el subsistema (CICS, IMS, DB2, TSO/ISPF, etc.), la aplicación y, finalmente, hasta el archivo o registro de la base de datos (E/S de disco) y viceversa; es decir, sin necesidad de instalar ningún componente de hardware y software de red, excepto el método de acceso a la red (VTAM o IBM TCP/IP para MVS) que ya se ejecuta en el sistema host ( servidor) que se está probando , o que ya está conectado a la red de este.

Además de su uso como herramienta de prueba para el intercambio de tráfico de mensajes con un sistema bajo prueba , TPNS/Wsim se ha implementado en:

• como herramienta de gestión de sistemas : para supervisar la disponibilidad de un sistema en línea , desde la perspectiva del usuario final ; ^{[ 14 ] : 361–433}

• como herramienta de desarrollo de software : para prototipar programas de software durante el proceso de desarrollo. ^{[ 15 ]}

Inicialmente, TPNS proporcionó su propio "lenguaje TPNS", un lenguaje de alto nivel, similar a un ensamblador de macros , con instrucciones de programación y operandos que un programador de pruebas utilizaría para definir:

• la configuración del/de los dispositivo(s) de red que se van a simular (definiciones NTWRK, simplemente llamado la red ), ^{[ 13 ] : 11–60} normalmente uno o más terminales, como pantallas de visualización IBM 3270 ;
• uno o más scripts de texto de mensajes (definiciones MSGTXT, simplemente llamados scripts ), ^{[ 13 ] : 109–230} correspondientes a las pulsaciones de teclas y la actividad de transmisión de datos del usuario simulado en el terminal simulado. Se podrían escribir scripts separados para realizar escenarios de prueba específicos, como: 'inicio de sesión', 'consulta de datos', 'entrada de datos' y 'cierre de sesión', por ejemplo;
• la secuencia en la que cada terminal simulada (o todas) deben ejecutar los scripts:
  • En NTWRK, una o más instrucciones PATH definen el orden en que se ejecutan los MSGTXT, ^{[ 13 ] : 52}
  • Cada terminal NTWRK tiene un operando PATH que nombra la(s) instrucción(es) PATH asignada(s) a la terminal. ^{[ 13 ] : 69, 93, 100}

Una vez definidos, estos scripts de prueba se ejecutan durante la simulación. El programa TPNS ITPENTER (el simulador) procesa las instrucciones enviadas y crea flujos de datos en los formatos y protocolos requeridos, antes de enviarlos al sistema bajo prueba como si provinieran de usuarios reales que operan terminales reales. A su vez, las aplicaciones de destino que se ejecutan en el sistema bajo prueba responden a las terminales simuladas y, si la simulación es exitosa, estos intercambios continúan hasta que los scripts programados finalizan la simulación ( es decir, cuando todos los usuarios simulados han completado su actividad programada y han cerrado sesión, por ejemplo ), momento en el que el programador de pruebas finaliza ITPENTER.

Durante la simulación, ITPENTER mantiene un registro (en cinta o disco) de todos los mensajes intercambiados entre el/los dispositivo(s) simulado(s) y la(s) aplicación(es) real(es) bajo prueba. Una vez finalizada la simulación, el programador de pruebas puede ejecutar cualquiera de las tres utilidades de análisis de registros proporcionadas por TPNS para listar y revisar los intercambios de datos en detalle (ITPLL), ^{[ 16 ] : 31–86} para calcular e imprimir informes de tiempos de respuesta (ITPRESP), ^{[ 16 ] : 147–172} o para comparar las 3270 imágenes de pantalla registradas durante dos ejecuciones de simulación del mismo script e informar sobre las diferencias entre ellas (ITPCOMP). ^{[ 16 ] : 87–146}

Cuando TPNS se rediseñó y se renombró como 'WSim' en 2002, el término 'lenguaje TPNS' se cambió a 'lenguaje WSim' en las publicaciones del producto; sin embargo, se mantuvo la nomenclatura existente y todos los componentes de TPNS que se integraron en WSim , como los nombres de los programas TPNS y los números de mensaje (ITPxxxxx), por ejemplo , conservaron su identidad original.

Con TPNS V3R1 (1989), IBM agregó el Structured Translator Language ( o 'STL'), un lenguaje de scripting de alto nivel de TPNS con una sintaxis basada en REXX , para facilitar la escritura de scripts de prueba por parte de programadores familiarizados con REXX o lenguajes de programación estructurados similares. ^{[ 13 ] : 231–564} STL hizo posible escribir scripts de prueba, no solo para la actividad habitual de operadores de terminales simulados, sino también para intercambios entre programas simulados de TPNS y programas de aplicación reales o, por ejemplo, para prototipar elementos de una red compartida ATM . ^{[ 15 ]} Los scripts escritos en STL deben traducirse al lenguaje TPNS antes de la ejecución de la simulación y se proporciona una utilidad de traducción (ITPSTL) para ese propósito.

Otra forma de definir STL sería como un "lenguaje de generación de scripts"; sus cláusulas de programación son idénticas a las de REXX, pero necesitan ser traducidas (es decir, "generadas mediante scripts") al lenguaje TPNS para poder ejecutarse durante la simulación.

Ambos lenguajes de scripting proporcionan un conjunto completo de herramientas de codificación que permiten al programador de pruebas:

• especificar los datos de entrada introducidos por el/los usuario/s simulado/s, junto con las acciones relacionadas: contar hacia atrás los retrasos del tiempo de espera, pulsar teclas para enviar datos y luego esperar respuestas de la aplicación bajo prueba; ^{[ 14 ] : 107–136}
• realizar una prueba lógica del contenido de los mensajes entrantes y/o salientes y tomar una de una amplia gama de acciones opcionales según los resultados de la evaluación; ^{[ 14 ] : 165–194, 92–95 [ 13 ] : 27–41, 150–164, 217}
• establecer cláusulas de verificación de datos de prueba que creen registros de log para condiciones 'predichas buenas'/'predichas malas'; ^{[ 14 ] : 176–177}
• datos de texto de mensajes de grupo en tablas de datos de usuario, para hacer que los scripts sean más genéricos e independientes de los datos; ^{[ 14 ] : 88–89, 121–125}
• invocar una amplia gama de opciones de campos de datos para crear datos de prueba dinámicamente en los mensajes; ^{[ 14 ] : 118–119 [ 13 ] : 199–207}
• recopilar datos en tiempo real en áreas de guardado, durante la ejecución de la simulación, para reutilizarlos como datos de prueba " sobre la marcha "; ^{[ 14 ] : 129–136}
• generar números aleatorios; ^{[ 14 ] : 119–120}
• mantener una amplia gama de contadores e interruptores; ^{[ 14 ] : 202–209}
• establecer eventos para sincronizar la actividad de usuarios simulados; ^{[ 14 ] : 209–217 [ 13 ] : 24, 28, 145, 151, 172, 194, 303–304, 433}
• Se configuraron colas con nombre para proporcionar un método de encolamiento para pasar datos entre recursos simulados; ^{[ 8 ] : 76–79}
• realizar operaciones de E/S de archivos secuenciales ( QSAM ) desde un script a un conjunto de datos externo definido por el usuario; ^{[ 8 ] : 87–91}
• Seleccionar herramientas de depuración de scripts , incluyendo un rastreo de generación de mensajes (MSGTRACE) que registra el flujo paso a paso de todas las pruebas lógicas, acciones (realizadas e ignoradas) e intercambios de datos que ocurren durante la ejecución de los scripts; ^{[ 14 ] : 87 [ 17 ] : 19–30}
• registrar el tráfico de mensajes durante la ejecución de la simulación, ^{[ 14 ] : 90–92} para el análisis posterior al procesamiento (incluido el seguimiento de la generación de mensajes, los datos transmitidos/recibidos, la impresión de imágenes de pantalla, la verificación de datos de prueba , el cálculo del tiempo de respuesta y la comparación de imágenes de pantalla en simulaciones repetidas de los mismos scripts);
• definir y modificar la tasa a la que se genera el tráfico de mensajes durante la ejecución de la simulación; ^{[ 14 ] : 86–90, 173–184}
• especificar los protocolos para el inicio y la finalización de la sesión entre recursos programados simulados y programas reales, así como para el intercambio de datos entre ellos; ^{[ 14 ] : 26–56}
• y muchos más.

WSim admite las mismas funciones de lenguaje de scripting que TPNS, excepto que sus definiciones de configuración de red (NTWRK) solo requieren las instrucciones proporcionadas para CPI-C , servidores y clientes TCP/IP ( Telnet 3270 y 5250 , terminal virtual de red en modo de línea Telnet , FTP y clientes UDP simples ) y simulación SNA LU .

El programa simulador ITPENTER también puede ejecutarse como preprocesador (cuando se envía con el parámetro PARM='PREP'), simplemente para verificar la sintaxis de las redes y los scripts antes de enviarlos para una ejecución de simulación. Esto permite al personal de pruebas asegurarse de que una ejecución posterior de la simulación no falle debido a errores de codificación en los propios scripts. ^{[ 16 ] : 11–24}

Una de las ventajas de usar scripts de prueba es que se pueden ejecutar repetidamente durante todo el ciclo de prueba, a medida que los errores funcionales en la aplicación bajo prueba y/o los defectos en todo el sistema se resuelven gradualmente con el tiempo, para mejorar la confiabilidad, la capacidad o el rendimiento de cualquiera o todos los componentes de hardware o software del sistema bajo prueba. Para las pruebas funcionales y de regresión, los programadores de pruebas normalmente definirían una red de un solo terminal simulado que ejecuta scripts de prueba diseñados para evaluar un conjunto completo de transacciones (consulta de base de datos o entrada de datos) de forma secuencial y a velocidades de tráfico de mensajes bajas o promedio. Para las pruebas de sistema, de rendimiento/capacidad, de estrés y de evaluación comparativa, los mismos programadores de pruebas definirían grandes redes de docenas o incluso miles de terminales simulados, cada uno ejecutando , por ejemplo , una serie de estos scripts de prueba funcionales, ahora agrupados para ejercitar la mayor cantidad posible de componentes del sistema a altas velocidades de tráfico de mensajes. ^{[ 1 ] : 17–24}

El generador de scripts de captura interactiva de datos (IDC) ^{[ 16 ] : 175–212} es una aplicación VTAM de "transmisión directa e interceptación de datos" (ITPIDC) controlada por el programador de pruebas desde una pantalla 3270 real en sesión con una aplicación de destino para la cual se requiere un script. ITPIDC mantiene dos sesiones SNA simultáneamente: una sesión LU primaria con el terminal 3270 real operado por el programador de pruebas y una sesión LU secundaria con la aplicación de destino. Durante la sesión de captura de datos , o "grabación" , ITPIDC registra el tráfico de datos intercambiado entre el dispositivo 3270 real del programador de pruebas y la aplicación de destino, y luego usa ese registro para generar el script equivalente, en cualquiera de los dos lenguajes de scripting (lenguaje TPNS o STL).

Dado que el conjunto de datos de registro de IDC tiene exactamente el mismo formato que el conjunto de datos de registro que crea TPNS durante una ejecución de simulación, se puede utilizar como entrada para las utilidades de posprocesamiento de TPNS para imprimir su contenido, calcular los tiempos de respuesta de la sesión de IDC o comparar las imágenes de pantalla de la sesión de captura de datos con el registro de TPNS obtenido al ejecutar el script generado por IDC.

Al capturar la actividad de una red de producción compuesta por uno o varios dispositivos 3270, el reformateador de trazas y generador de scripts 3270 ^{[ 16 ] : 213–230} procesa el conjunto de datos de traza producido por el registro VTAM PIU (FNMVLOG) del Monitor de rendimiento de red de IBM (NPM V1R4 o posterior), o por el rastreo de búfer completo de IBM VTAM (V4R1 o posterior). Cuando se completa la actividad de rastreo, una utilidad (ITPLU2RF) reformatea el conjunto de datos de traza en un conjunto de datos de registro en el formato requerido como entrada para el generador de scripts IDC (ver sección anterior), que también puede crear scripts en modo por lotes (ITPLSGEN). Este registro IDC reformateado también puede ser analizado por las tres utilidades de posprocesamiento (listar el contenido del registro, calcular los tiempos de respuesta o comparar imágenes de pantalla).

El generador de scripts ^{[ 16 ] : 231–269} procesa el conjunto de datos de rastreo producido por el Monitor de rendimiento de red de IBM (NPM), o por el Rastreo de búfer VTAM de IBM junto con la Instalación de rastreo generalizada de IBM (GTF), al rastrear una red de producción de uno o varios dispositivos 3270, así como dispositivos de varios tipos y protocolos, incluidos LU0, LU1, LU2, LU4 , LU 6.2 y recursos CPI-C . Para la generación de scripts CPI-C, también es posible utilizar el conjunto de datos de rastreo LU 6.2 creado por el Administrador de comunicaciones de OS/2 (CM/2) o el Servidor de comunicaciones de IBM . Diferentes utilidades proporcionadas por TPNS reformatean cualquiera de estos conjuntos de datos de rastreo en un conjunto de datos de formato único que se utiliza como entrada para el generador de scripts (ITPSGEN), que produce scripts:

• Opcionalmente, en cualquiera de los dos idiomas (TPNS o STL) para todos los tipos de dispositivos compatibles, excepto los recursos programados en CPI-C;
• solo en STL para recursos programados en CPI-C. ^{[ 16 ] : 309}

El generador de scripts TCP/IP ^{[ 16 ] : 277–282} es exclusivo de WSim y se introdujo en diciembre de 2015. ^{[ 18 ]} Procesa un conjunto de datos de rastreo TCP/IP producido por la utilidad de rastreo TCP/IP (ITPIPTRX) proporcionada por WSim, ^{[ 16 ] : 167–170} que invoca la interfaz de administración de red (NMI) de rastreo TCP/IP en tiempo real y controlada por la aplicación del z/OS Communication Server para capturar registros de rastreo de datos TCP/IP. Estos registros de rastreo contienen mensajes HTTP (paquetes y datos) intercambiados entre un servidor y un cliente. El generador de scripts TCP/IP (ITPIPGEN) procesa este conjunto de datos de rastreo y crea un script, en el lenguaje STL, que replica la comunicación que tuvo lugar entre el servidor y el cliente. Después de la traducción de STL al lenguaje WSim y al ejecutar la simulación (ITPENTER), el script generado envía los mensajes del cliente —obtenidos del rastreo— al puerto del servidor y espera a recibir un mensaje del servidor. ^{[ 16 ] : 277} También se proporciona una utilidad separada (ITPIPFMT) ^{[ 16 ] : 171–172} para formatear e imprimir el contenido del conjunto de datos de rastreo creado por la utilidad de rastreo TCP/IP (ITPIPTRX).

Es práctica habitual que un script obtenido de un generador de scripts sea posteriormente editado por programadores de pruebas para que dichos scripts sean más reutilizables. Este proceso de edición consiste en añadir cláusulas de programación de scripts avanzadas que los generadores de scripts no pueden proporcionar, como por ejemplo, reubicar datos codificados en tablas de datos de usuario que luego pueden ampliarse con más datos de prueba. Esta edición puede realizarse directamente en los conjuntos de datos NTWRK y MSGTXT, o a través de los servicios del Administrador de Pruebas TPNS (o su afiliado Administrador de Pruebas WSim ) que, al igual que TPNS (y WSim), también se ejecuta bajo TSO/ISPF. El Administrador de Pruebas es una herramienta de usabilidad interactiva basada en el conocimiento , diseñada para aumentar la productividad del personal de pruebas y optimizar el ciclo de pruebas, permitiendo que los proyectos de prueba se organicen metódicamente durante el desarrollo y la ejecución de los casos de prueba , y en el posterior análisis de los resultados de las pruebas. ^{[ 19 ]}

Una vez que el programa TPNS ITPENTER (el simulador) se ha enviado para su ejecución y está en funcionamiento, ^{[ 1 ] : 66–70} el personal de pruebas puede utilizar una serie de comandos de operador específicos de TPNS para inicializar, iniciar, modificar y detener la ejecución de una o más redes TPNS y sus scripts asociados. ^{[ 1 ] : 99–116} También es posible consultar la actividad de un dispositivo simulado y su script actual, ^{[ 1 ] : 103–111} e intervenir en tiempo real, por ejemplo, modificando la tasa de tráfico de mensajes. ^{[ 1 ] : 113–114}

En sus primeras versiones, ITPENTER se ejecutaba como un procedimiento MVS controlado desde la consola del operador MVS. ^{[ 1 ] : 91–93} Su tráfico de datos generado se transmitía desde su espacio de direcciones MVS , primero a través de un adaptador de canal a su Programa de Control TPNS (TPNCP) que se ejecutaba en un controlador de comunicaciones IBM 37x5 dedicado , y luego a través de líneas de teleprocesamiento conectadas en serie entre el TPNCP y el canal IBM 37x5 de destino conectado al sistema host bajo prueba y sus subsistemas de aplicación ( CICS , IMS , DB2 , TSO / ISPF , etc.).

Con TPNS V1R5 (1979), ITPENTER se mejoró para ejecutarse desde una lista de comandos TSO (en el espacio de direcciones de usuario TSO) y, por lo tanto, para operar simulaciones desde una terminal de visualización remota en la red VTAM en lugar de la consola del sistema MVS. ^{[ 5 ] : 30}

Con TPNS V2R3 (1985), ITPENTER se mejoró para ejecutarse como una aplicación VTAM, enviando así el tráfico de datos generado por sus terminales simuladas o recursos programados (ahora definidos como unidades lógicas VTAM) a través de la API VTAM a la aplicación bajo prueba. ^{[ 5 ] : 30} Esto eliminó la necesidad de un 37x5 y otro hardware de teleprocesamiento dedicado cuando se utiliza TPNS para probar sistemas de aplicaciones que se ejecutan bajo VTAM, como CICS , IMS , DB2 , ISPF y otros sistemas de procesamiento de transacciones en línea .

Con TPNS V2R4 (1987), ITPENTER se mejoró con el Monitor de Pantalla, de modo que las imágenes de pantalla de una pantalla 3270 simulada podían proyectarse en un terminal 3270 real, lo que permitía al personal de pruebas supervisar la ejecución en directo de un script durante la simulación, en tiempo real. También fue posible operar TPNS desde la consola NetView y, a su vez, automatizar las simulaciones de TPNS desde NetView mediante listas de comandos de NetView proporcionadas por TPNS . ^{[ 5 ] : 31}

Con TPNS V3R3 (1992), todos los programas y utilidades de TPNS (ITPxxxxx) podían operarse completamente desde ISPF de forma controlada por panel, en lugar de a través de la línea de comandos de TSO o a través de flujos de trabajo JCL discretos . ^{[ 5 ] : 32}

Con TPNS V3R5 (1997), ITPENTER se mejoró para funcionar como una aplicación TCP/IP para MVS, enviando así el tráfico de datos generado por sus terminales simulados y/o recursos programados (clientes) a la(s) aplicación(es) (servidores) bajo prueba a través de la API IBM TCP/IP V3R2 para MVS High Performance Native Sockets (HPNS), posteriormente renombrada como "API Macro". ^{[ 20 ] [ 21 ] : 17–28}

En 1998, IBM presentó el Test Manager para TPNS V3R5 ^{[ 19 ]} que agregó importantes características de automatización que agilizan muchas tareas repetitivas asociadas con la planificación, preparación, operación y análisis de una ejecución de simulación basada en TPNS, al tiempo que permite al programador de pruebas mantener opcionalmente un conocimiento completo, en tiempo real, de los eventos que se desarrollan en cada paso e intervenir si es necesario.

La utilidad de lista de registros (ITPLL) se utiliza para listar y revisar en detalle los datos registrados, incluidos los comandos del operador, los datos transmitidos y recibidos, las imágenes de pantalla, el seguimiento de la generación de mensajes y la verificación de datos de prueba. ^{[ 16 ] : 25–61}

La calculadora de tiempo de respuesta (ITPRESP) se utiliza para calcular e imprimir informes de tiempos de respuesta. ^{[ 16 ] : 107–149}

La utilidad de comparación de registros (ITPCOMP) se utiliza para comparar las 3270 imágenes de pantalla registradas durante dos ejecuciones de simulación del mismo script o scripts e informar sobre las diferencias entre ellas. ^{[ 16 ] : 63–106}

El programa Echo (ITPECHO) ^{[ 16 ] : 151–159} se suministra con TPNS (y WSim) como una aplicación VTAM lista para usar que se ejecuta en el sistema bajo prueba como destino para los mensajes enviados por dispositivos de visualización 3270 reales o simulados. El uso de ITPECHO permite realizar pruebas de conectividad de red y de carga sin necesidad de configurar una copia de una aplicación de nivel de producción y sus bases de datos, lo que ahorra al personal de pruebas el esfuerzo de escribir scripts o asignar espacio en disco para dicha aplicación y sus conjuntos de datos. Como su nombre indica, ITPECHO devolverá exactamente el mensaje que acaba de recibir (cuando se envía con la tecla 'Intro'), pero también puede devolver la cantidad de datos que se solicitó en el mensaje anterior (cuando se envía con la tecla 'PF5'), desde dispositivos de visualización reales o simulados. Esta última función es útil para crear condiciones de prueba donde los mensajes de 'envío' y 'recepción' deben tener longitudes diferentes y variables. Para proporcionar la cantidad de datos solicitada, ITPECHO rellena su mensaje con tantas apariciones del alfabeto como sean necesarias, o una fracción del mismo si la cantidad de datos solicitada es inferior a 26 caracteres.

En lugar de utilizar TPNS como herramienta de prueba, AVMON ( AVailability MONitor ) ^{[ 14 ] : 319–367} es una implementación de TPNS diseñada para supervisar la disponibilidad y el rendimiento de subsistemas de red reales en producción (NetView y TSO). Los scripts de AVMON de ejemplo proporcionados por TPNS supervisan únicamente NetView y TSO, pero una instalación de usuario puede añadir soporte para supervisar más subsistemas (CICS, IMS, DB2, etc.) y cualquiera de sus aplicaciones, modificando o ampliando los scripts de AVMON , por ejemplo, mediante el generador de scripts Interactive Data Capture mencionado anteriormente para crear los nuevos scripts. Durante la ejecución de la simulación de TPNS, AVMON actualiza el conjunto de datos de registro de TPNS, que puede ser procesado por las tres utilidades de análisis de registro de TPNS (lista de registros, calculadora de tiempos de respuesta y comparación de registros).

AVMON supervisa la disponibilidad simulando un único usuario de terminal en sesión con un subsistema real, enviando periódicamente un breve mensaje de sondeo y detectando cuándo el subsistema deja de estar disponible. Cuando el usuario simulado detecta la indisponibilidad, envía un mensaje a la consola del operador para alertarlo del problema. AVMON también registra el tiempo que tarda el subsistema supervisado en responder e informa cuando se supera un umbral de rendimiento especificado por el usuario. Mediante la utilidad TPNS Response Time, las estadísticas de rendimiento de toda la ejecución de la supervisión se pueden compilar en un único informe, proporcionando así a la instalación evidencia de los tiempos de respuesta de extremo a extremo experimentados por los usuarios finales del subsistema. Para operaciones automatizadas, AVMON también puede modificarse para realizar funciones de operador cuando detecta que un recurso real se ha vuelto inoperativo y, por lo tanto, requiere la intervención del operador, como reiniciar el recurso, por ejemplo.