IBM TPNS


Teleprocessing Network Simulator
is an IBM licensed program, first released in 1976 as a test automation tool to simulate one or many network terminal to a mainframe computer system, for functional testing, regression testing, system testing, capacity management, benchmarking and stress testing. In 2002, IBM re-packaged TPNS and released
Workload Simulator for z/OS and S/390 as a successor product.
In addition to its use as a test tool exchanging message traffic with a system under test, TPNS/Wsim has been deployed:
Version 1 Release 1 was introduced as Program Product 5740-XT4 in February, 1976.
Between 1976 and 1981, IBM delivered four additional releases, culminating in V1R5.
Between 1981 and 1987, IBM delivered three additional releases, culminating in V2R4.
Between 1989 and 1996, IBM delivered four additional releases, culminating in V3R5.

Simulation support

Teleprocessing Network Simulator (TPNS)

TPNS supports the simulation of a wide range of networking protocols and devices: SNA/SDLC, start-stop, BSC, TWX, TTY, X.25 Packet Switching Network, Token ring Local Area Networking, and TCP/IP servers and clients. TPNS can also simulate devices using the Airline Line Control and the HDLC protocols. The full implementation of SNA in TPNS enables it to simulate all LU types, PU types, and SSCP functions. Finally, TPNS also provides extensive user exit access to its internal processes to enable the simulation of user-defined line disciplines, communications protocols, devices and programs.
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, TCP/IP servers and clients, and SNA LU simulation. WSim relies solely on software interfaces to communicate with the system under test.
WSim is therefore the appropriate test tool for installations that need to test application systems and their hardware and software components, from the networking access method API to the subsystem, the application and finally to the file or database record and back; that is to say, without the need to install any networking hardware and software components except the networking access method that already runs in—or is already network-connected to—the host system under test.

Scripting languages

TPNS language

TPNS initially provided its own 'TPNS language', a high-level, macro assembler-like language with programming statements and operands that a test programmer would use to define:
Once defined, these test scripts are executed during the simulation run, when the TPNS program ITPENTER processes the submitted statements and creates data streams in the required formats and protocols, prior to sending them to the system under test as if they had originated from real user operating real terminal. In turn, the target application running in the system under test respond to the simulated terminal and, if the simulation is successful, these exchanges would continue until the programmed scripts reach the end of the simulation run, at which time ITPENTER is terminated by the test programmer.
During the simulation, ITPENTER keeps a log of all messages exchanged between the simulated device and the real application 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, to calculate and print response times reports , or to compare the 3270 screen images logged during two simulation runs of the same script and report on differences between them.
When TPNS was re-packaged and renamed 'WSim' in 2002, the term 'TPNS language' was changed to 'WSim language' in the product publications; however, all TPNS components re-packaged into WSim—such as the TPNS program names, for example—retained their identity and the existing nomenclature was maintained.

Structured Translator Language (STL)

With TPNS V3R1, 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. STL therefore made it possible to write test scripts, not only for the usual activity of simulated terminal operators, but also for exchanges between TPNS-simulated programs and real application programs or, for example, to prototype elements of an ATM shared network. Scripts written in STL must be translated into the TPNS language before the simulation run and a translator utility is supplied for that purpose.
Another way of defining STL would be as a 'script generation language'; its programming clauses are identical to REXX, but they need to be translated into the TPNS language in order to be executable during the simulation run.

Script coding facilities

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 definitions require only those statements provided for CPI-C, TCP/IP servers and clients, and SNA LU simulation.

Repeatability

One of the benefits of using test scripts is that they can be run repeatedly throughout the test cycle, as functional errors and/or system-wide defects are gradually resolved over time, in order to improve the reliability, capacity or performance of any, or all, hardware or software components in the system under test. For functional and regression testing, test programmers would typically define a network of just one simulated terminal executing test scripts tailored to evaluate a comprehensive set of transactions serially, and at slow or average rates of message traffic. For system testing, performance/capacity testing, stress testing and benchmarking, the same test programmers would define large networks of dozens or even thousands of simulated terminals, each running—for example—a range of these functional test scripts, now grouped together to exercise as many system components as possible at high rates of message traffic.

Script generation

TPNS provides a number of solutions to automate the creation of test scripts.
The script generation facilities described in the next three sections are also available in Workload Simulator for z/OS and S/390.

The ''Interactive Data Capture (IDC) script generator'' (ITPIDC)

The Interactive Data Capture script generator
is a 'pass-through & data intercept' VTAM application controlled by the test programmer from one real 3270 display screen in session with a target application for which a script is required. ITPIDC maintains two SNA sessions simultaneously: a primary LU session with the real 3270 terminal operated by the test programmer, and a secondary LU session with the target application.
During the data capture-or 'recording'-session, ITPIDC logs the data traffic exchanged between the test programmer's real 3270 device and the target application, and then uses that log to generate the equivalent script, in either of the two scripting languages.
Since the IDC log dataset is in exactly the same format as the log dataset TPNS creates during a simulation run, it can be used as input to the TPNS post-processing utilities to print its contents, to calculate response times of the IDC session, or to compare the screen images of the data capture session with the TPNS log obtained by running the IDC-generated script.

The ''3270 trace reformatter and script generator'' (ITPLU2RF & ITPLSGEN)

When capturing the activity of a production network consisting of one or many 3270 devices, the 3270 trace reformatter and script generator processes the trace dataset produced by the IBM Network Performance Monitor VTAM PIU log, or by the IBM VTAM Full Buffer Trace. When the tracing activity is completed, a utility reformats the trace dataset into a log dataset in the format required as input to the IDC script generator, which can also create scripts in batch mode. This reformatted IDC log can also be analyzed by the three post-processing utilities.

The ''script generator'' (ITPSGEN)

The script generator processes the trace dataset produced by the IBM Network Performance Monitor, or by the IBM VTAM Buffer Trace in conjunction with the IBM Generalized Trace Facility, when tracing a production network of one or many 3270 devices, as well as devices of various types and protocols, including LU0, LU1, LU2, LU4, LU 6.2 and CPI-C resources. For CPI-C script generation, it is also possible to use the LU 6.2 trace dataset created by the OS/2 Communications Manager or the IBM Communications Server. Different TPNS-supplied utilities reformat any of these various trace datasets into a single-format dataset used as input to the script generator, which produces scripts:
The TCP/IP script generator is unique to WSim and was introduced in December 2015. It processes a TCP/IP trace dataset produced by the WSim-supplied TCP/IP Trace Utility, which invokes the z/OS Communication Server real-time, application-controlled TCP/IP trace Network Management Interface to capture TCP/IP data trace records. These trace records contain HTTP messages exchanged between a server and client. The TCP/IP script generator then processes this trace dataset and creates a script, in the STL language, which replicates the communication that occurred between the server and client. After translation from STL into the WSim language and when running the simulation, the generated script sends the client messages—obtained from the trace—to the server port, and waits to receive a message from the server. A separate utility is also supplied to format and print the contents of the trace dataset created by the TCP/IP Trace Utility.

The ''Test Manager''

It is established practice that a script obtained from a script generator is subsequently edited by test programmers in order to make such scripts more generally reusable. This editing process consists in adding advanced script-programming clauses that script generators cannot supply, such as re-locating hard-coded data into user data tables that can then be expanded with more test data, for example. This editing can be done directly into the NTWRK and MSGTXT datasets, or through the services of the TPNS Test Manager which, like TPNS, also runs under TSO/ISPF.
The Test Manager is a knowledge-based, interactive usability tool designed to boost the productivity of test personnel, and to optimize the test cycle by enabling test projects to be organized methodically during the development and execution of test cases, and in the subsequent analysis of test results.

Run-time interfaces

In its early releases, the TPNS program ITPENTER ran as a MVS procedure controlled from the MVS operator console. Its generated data traffic was transmitted from its MVS address space, first across a channel-adapter to its TPNS Control Program 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.

Running under TSO

With TPNS V1R5, ITPENTER was enhanced to run from a TSO command list and therefore to operate simulations from a remote display terminal in the VTAM network instead of the MVS system console.

Running as a VTAM application

With TPNS V2R3, ITPENTER was enhanced to run as a VTAM application, thus sending the data traffic generated by its simulated terminals or programmed resources via the VTAM API to the application under test. This removed the requirement for a 37x5 and other dedicated teleprocessing hardware when using TPNS to test applications systems running under VTAM, such as CICS, IMS, DB2, ISPF, and other online transaction processing systems.

''Display Monitor''

With TPNS V2R4, 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. It also became possible to operate TPNS from the NetView console and, in turn, to automate TPNS simulation runs from NetView by means of TPNS-supplied NetView command lists.

Running under ISPF

With TPNS V3R3, all TPNS programs and utilities could be operated entirely from ISPF in a panel-driven fashion, instead of through the TSO command line, or through discrete JCL job streams.

Running as a TCP/IP for MVS application

With TPNS V3R5, 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 to the application under test via the IBM TCP/IP V3R2 for MVS High Performance Native Sockets API, subsequently renamed 'the Macro API'. Retrieved on October 29, 2015.

''Test Manager''

With TPNS V3R5, IBM introduced the TPNS Test Manager 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.

Post-processing utilities

During the simulation, ITPENTER keeps a log of all messages exchanged between the simulated device and the real application under test. After the simulation has completed, the test programmer can therefore run any of three TPNS-supplied log analysis utilities.

Log list (ITPLL)

The log list utility is used to list and review the data exchanges in detail.

Response time calculator (ITPRESP)

The response time calculator is used to calculate and print response times reports.

Log compare (ITPCOMP)

The log compare utility is used to compare the 3270 screen images logged during two simulation runs of the same script and report on differences between them.

Additional facilities

The ''Echo'' program (ITPECHO)

The Echo program is supplied with TPNS 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. 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. As its name implies, ITPECHO will return exactly the message it has just received, but it can also return the amount of data that was requested in the previous message, from real or simulated display device. The latter feature is useful for creating test conditions where the 'send' and 'receive' messages need to be of different and variable lengths. To provide the amount of data requested, ITPECHO pads its message with as many occurrences of the alphabet as necessary, or a fraction of it if the amount of data requested in less than 26 characters.

The ''AVailability MONitor (AVMON)'' facility

Rather than applying TPNS as a test tool, AVMON is a TPNS implementation designed to monitor the availability and performance of real network subsystems running in production. The TPNS-supplied sample AVMON scripts monitor only NetView and TSO, but a user installation may add support for monitoring more subsystems and any of their applications, by modifying or extending the AVMON scripts, perhaps through the use of the Interactive Data Capture script generator mentioned above to create the new script. During the TPNS simulation run, AVMON updates the TPNS log dataset, which can therefore be processed by the three TPNS log analysis utilities.
AVMON monitors availability by simulating a single terminal user in session with a real subsystem, periodically sending a brief probing message, and sensing when the subsystem becomes unavailable. When the simulated user detects unavailability, it sends a message to the operator console alerting the operator to the problem. 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. By using the TPNS Response Time utility, the performance statistics of the entire monitoring run can be compiled into a single report, thus providing an installation with evidence of the end-to-end response times experienced by the subsystem's end-users. For automated operations, AVMON may also be modified to perform operator functions when it senses that a real resource has become inoperative and therefore requires an operator intervention, such as restarting the resource for example.

Publications library

Teleprocessing Network Simulator (TPNS) library