Finally, TPNS also provides extensive user exit access to its internal processes to enable the simulation of user-defined (home-grown) line disciplines, communications protocols, devices (terminals and printers) and programs.

[3] TPNS is therefore the appropriate test tool for installations that need to test: WSim fully supports a subset of TPNS-simulated devices and programmed resources: CPI-C,[13]: 61–72  TCP/IP servers and clients (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients),[13]: 91–108  and SNA LU simulation.

), the application and finally to the file or database record (disk I/O) and back; that is to say, without the need to install any networking hardware and software components except the networking access method (VTAM or IBM TCP/IP for MVS) that already runs in—or is already network-connected to—the host system (server) under test.

After the simulation has completed, the test programmer can therefore run any of three TPNS-supplied log analysis utilities to list and review the data exchanges in detail (ITPLL),[16]: 31–86  to calculate and print response times reports (ITPRESP),[16]: 147–172  or to compare the 3270 screen images logged during two simulation runs of the same script(s) and report on differences between them (ITPCOMP).

With TPNS V3R1 (1989), IBM added the Structured Translator Language—or 'STL', a TPNS high-level scripting language with a syntax based on REXX—to make it easier for test scripts to be written by programmers familiar with REXX or similar structured programming languages.

Both scripting languages provide a comprehensive set of coding facilities that enable the test programmer to: WSim supports the same scripting language facilities as TPNS, except that its network configuration (NTWRK) definitions require only those statements provided for CPI-C, TCP/IP servers and clients (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients), and SNA LU simulation.

This enables test personnel to ensure that a subsequent simulation run will not fail because of coding errors in the scripts themselves.

[1]: 99–116  It is also possible to query the activity of a simulated device and its current script,[1]: 103–111  and to intervene in real time, by altering the rate of message traffic, for example.

[1]: 91–93  Its generated data traffic was transmitted from its MVS address space, first across a channel-adapter to its TPNS Control Program (TPNCP) running in a dedicated IBM 37x5 Communications Controller, and then across teleprocessing lines connected back-to-back between the TPNCP and the target IBM 37x5 channel-attached to the host system under test and its application subsystems (CICS, IMS, DB2, TSO/ISPF, etc.).

With TPNS V2R4 (1987), ITPENTER was enhanced with the Display Monitor, so that the screen images of a simulated 3270 display could be externalized onto a real 3270 terminal, thus enabling test personnel to monitor the ongoing, live execution of a script during the simulation run, in real time.

[5]: 32 With TPNS V3R5 (1997), ITPENTER was enhanced to run as a TCP/IP for MVS application, thus sending the data traffic generated by its simulated terminals and/or programmed resources (clients) to the application(s) (servers) under test via the IBM TCP/IP V3R2 for MVS High Performance Native Sockets (HPNS) API, subsequently renamed 'the Macro API'.

[20][21]: 17–28 In 1998, IBM introduced the Test Manager for TPNS V3R5[19] which added substantial automation features that streamline many repetitive tasks associated with planning, preparing, operating and analyzing a TPNS-based simulation run, while still enabling the test programmer optionally to retain full awareness, in real-time, of the events unfolding at every step and to intervene if necessary.

[16]: 63–106 The Echo program (ITPECHO)[16]: 151–159  is supplied with TPNS (and WSim) as a ready-made VTAM application that runs in the system under test as a target for messages sent by real or simulated 3270 display device(s).

Using ITPECHO enables network connectivity and load testing to be carried out without the need to set up a copy of a production-level application and its databases, thereby saving test personnel the effort of writing scripts or allocating disk space for such an application and its datasets.

AVMON also tracks the time it takes for the monitored subsystem to return a response, and reports whenever a user-specified performance threshold is exceeded.