| Other Names: |
|
| Latest Release Version: | Workload Simulator V1.1 |
| Operating System: | MVS/370, OS/390, z/OS |
| Platform: | |
| Genre: | Test automation software |
| License: | Proprietary |
Teleprocessing Network Simulator (TPNS) is an IBM licensed program, first released in 1976 as a test automation tool to simulate the end-user activity of network terminal(s) to a mainframe computer system, for functional testing, regression testing, system testing, capacity management, benchmarking and stress testing.[1]
In 2002, IBM re-packaged TPNS and released Workload Simulator for z/OS and S/390 (WSim) as a successor product.[2]
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 (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients). TPNS can also simulate devices using the Airline Line Control (ALC) and the HDLC protocols. The full implementation of SNA in TPNS enables it to simulate all LU types (including LU6.2 and CPI-C), PU types (including PU2.1), and SSCP functions. 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.
TPNS is therefore the appropriate test tool for installations that need to test:
Note: In this configuration, TPNS transmits its generated data traffic 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 (server) under test and its subsystems, applications and databases/files.
Note: In this configuration, TPNS transmits its generated data traffic from its MVS address space to the target application directly across the networking access method's API and does not, therefore, require a dedicated IBM 37x5 Communications Controller to run its TPNCP, or any other 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.
WSim fully supports a subset of TPNS-simulated devices and programmed resources: CPI-C,[13] TCP/IP servers and clients (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP 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 (either the VTAM API or the TCP/IP High Performance Native Sockets, or Macro, API) to the subsystem (CICS, IMS, DB2, TSO/ISPF, etc.), 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.
In addition to its use as a test tool exchanging message traffic with a system under test, TPNS/Wsim has been deployed:
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 (the simulator) 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(s) operating real terminal(s). In turn, the target application(s) running in the system under test respond(s) to the simulated terminal(s) and, if the simulation is successful, these exchanges would continue until the programmed scripts reach the end of the simulation run - i.e., when the simulated users have all completed their scripted activity and logged off, for example - at which time ITPENTER is terminated by the test programmer.
During the simulation, ITPENTER keeps a log (on tape or disk) of all messages exchanged between the simulated device(s) and the real application(s) 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] to calculate and print response times reports (ITPRESP), or to compare the 3270 screen images logged during two simulation runs of the same script(s) and report on differences between them (ITPCOMP).
When TPNS was re-packaged and renamed 'WSim' in 2002, the term 'TPNS language' was changed to 'WSim language' in the product publications; however, the existing nomenclature was maintained and all TPNS components re-packaged into WSim - such as the TPNS program names and message numbers (ITPxxxxx), for example - retained their existing identity.
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. 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 (ITPSTL) 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 (i.e. 'script-generated') into the TPNS language in order to be executable during the simulation run.
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.
The simulator program ITPENTER can also be run as a preprocessor (when submitted with parameter PARM='PREP'), simply to check the syntax of networks and scripts before they are submitted for a simulation run. This enables test personnel to ensure that a subsequent simulation run will not fail because of coding errors in the scripts themselves.
One of the benefits of using test scripts is that they can be run repeatedly throughout the test cycle, as functional errors in the application under test 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 (database enquiry or data entry) 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.[1]
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 (WSim).
The Interactive Data Capture (IDC) script generator is a 'pass-through & data intercept' VTAM application (ITPIDC) 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 (TPNS language or STL).
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.
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 (NPM V1R4 or later) VTAM PIU log (FNMVLOG), or by the IBM VTAM (V4R1 or later) Full Buffer Trace. When the tracing activity is completed, a utility (ITPLU2RF) reformats the trace dataset into a log dataset in the format required as input to the IDC script generator (see previous section), which can also create scripts in batch mode (ITPLSGEN). This reformatted IDC log can also be analyzed by the three post-processing utilities (list the log's contents, calculate response times or compare screen images).
The script generator processes the trace dataset produced by the IBM Network Performance Monitor (NPM), or by the IBM VTAM Buffer Trace in conjunction with the IBM Generalized Trace Facility (GTF), 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 (CM/2) 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 (ITPSGEN), which produces scripts:
The TCP/IP script generator is unique to WSim and was introduced in December 2015.[18] It processes a TCP/IP trace dataset produced by the WSim-supplied TCP/IP Trace Utility (ITPIPTRX), which invokes the z/OS Communication Server real-time, application-controlled TCP/IP trace Network Management Interface (NMI) to capture TCP/IP data trace records. These trace records contain HTTP messages (packets and data) exchanged between a server and client. The TCP/IP script generator (ITPIPGEN) 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 (ITPENTER), 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 (ITPIPFMT) is also supplied to format and print the contents of the trace dataset created by the TCP/IP Trace Utility (ITPIPTRX).
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 (or its affiliated WSim Test Manager) which, like TPNS (and WSim), 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.[19]
Once the TPNS program ITPENTER (the simulator) has been submitted for execution and is up and running,[1] test personnel can use a range of TPNS-specific operator commands to initialise, start, alter, and stop the execution of one or more TPNS networks and their associated scripts.[1] It is also possible to query the activity of a simulated device and its current script,[1] and to intervene in real time, by altering the rate of message traffic, for example.[1]
In its early releases, ITPENTER ran as a MVS procedure controlled from the MVS operator console.[1] 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 V1R5 (1979), ITPENTER was enhanced to run from a TSO command list (in the TSO user address space) and therefore to operate simulations from a remote display terminal in the VTAM network instead of the MVS system console.[5]
With TPNS V2R3 (1985), ITPENTER was enhanced to run as a VTAM application, thus sending the data traffic generated by its simulated terminals or programmed resources (now defined as VTAM logical units) via the VTAM API to the application under test.[5] 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.
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. 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.[5]
With TPNS V3R3 (1992), all TPNS programs and utilities (ITPxxxxx) could be operated entirely from ISPF in a panel-driven fashion, instead of through the TSO command line or through discrete JCL job streams.[5]
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]
In 1998, IBM introduced the Test Manager for TPNS V3R5 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.
During the simulation, ITPENTER keeps a log (on tape or disk) of all messages exchanged between the simulated device(s) and the real application(s) under test. After the simulation has completed, the test programmer can therefore run any of three TPNS-supplied log analysis utilities.
The log list utility (ITPLL) is used to list and review the logged data in detail, including operator commands, data transmitted and received, screen images, message generation tracing, and test data verification.[16]
The response time calculator (ITPRESP) is used to calculate and print response times reports.
The log compare utility (ITPCOMP) is used to compare the 3270 screen images logged during two simulation runs of the same script(s) and report on differences between them.
The Echo program (ITPECHO) 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. As its name implies, ITPECHO will return exactly the message it has just received (when sent with the 'Enter' key), but it can also return the amount of data that was requested in the previous message (when sent with the 'PF5' key), from real or simulated display device(s). 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.
Rather than applying TPNS as a test tool, AVMON (AVailability MONitor) is a TPNS implementation designed to monitor the availability and performance of real network subsystems running in production (NetView and TSO). The TPNS-supplied sample AVMON scripts monitor only NetView and TSO, but a user installation may add support for monitoring more subsystems (CICS, IMS, DB2, etc.) 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(s). During the TPNS simulation run, AVMON updates the TPNS log dataset, which can therefore be processed by the three TPNS log analysis utilities (log list, response times calculator and log compare).
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.