IBM TPNS

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Teleprocessing Network Simulator (TPNS)[1] is a licensed program developed by IBM as a test automation tool to simulate one or many network terminal(s) to a mainframe computer system, for functional testing, system testing, regression testing, capacity management, benchmarking and stress testing.[2]:19–22 TPNS was re-packaged and renamed Workload Simulator for z/OS and S/390 (WSim) in 2002.[3]

In addition to its general use as a test tool exchanging message traffic with a system under test, TPNS has been deployed:

History

  • Teleprocessing Network Simulator (TPNS) Version 1 Release 1 was introduced as Program Product 5740-XT4 in February, 1976.[6] Between 1976 and 1981, IBM delivered four additional releases, culminating in V1R5.[7]:29–30
  • In August 1981, IBM announced TPNS Version 2 Release 1 as Program Product 5662-262. Between 1981 and 1987, IBM delivered three additional releases, culminating in V2R4.[7]:30–31
  • In January 1989, IBM announced TPNS Version 3 Release 1 as Program Product 5688-121. Between 1989 and 1996, IBM delivered four additional releases, culminating in V3R5.[7]:31–32
  • In December 1997, IBM announced a TPNS V3R5 Service Level 9711 Functional and Service Enhancements release.[8]
  • In September 1998, IBM announced Teleprocessing Network Simulator (TPNS) Test Manager (for TPNS V3R5) as a usability enhancement to automate the test process further in order to improve productivity through a logical flow, and to streamline TPNS-based testing of IBM 3270 applications or CPI-C transaction programs.[9]
  • In December 2001, IBM announced a TPNS V3R5 Service Level 0110 Functional and Service Enhancements release.[10]
  • In August 2002, IBM announced Workload Simulator for z/OS and S/390 (WSim) V1.1 as Program Number 5655-I39, a re-packaged successor product to TPNS,[11] alongside Workload Simulator for z/OS and S/390 (WSim) Test Manager V1.1, a re-packaged successor to TPNS Test Manager.[12]

Features

Simulation support

Teleprocessing Network Simulator 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:

  • either the entire system configuration path of hardware and software components, from the teleprocessing line interface (modem, for example) all the way to the subsystem (CICS, IMS, DB2, etc.), the application and finally to the file or database record (disk I/O) and back;
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.
  • or only 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, etc.), the application and finally to the file or database record (disk I/O) and back;
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.
  • or both.

Workload Simulator for z/OS and S/390 (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.[13]:73–87 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, 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.

Scripting languages

TPNS initially provided its own high-level, macro assembler-like language with programming statements and operands that a test programmer would use to define:

  • the configuration of the network device(s) to be simulated (NTWRK definitions),[13]:11–60 typically one or more terminal(s), such as IBM 3270 display screen(s);
  • one or more message text script(s) (MSGTXT definitions),[13]:109–230 corresponding to the keystrokes and data transmission activity of the simulated user(s) at the simulated terminal(s), such as: 'login', 'data enquiry', 'data entry' and 'logout', for example. The sequence in which test scripts are executed by each simulated terminal is defined via: 1. one or more PATH statement(s) in the NTWRK,[13]:52 and 2. the PATH operand of each terminal.[13]:69,93,100

Once defined, these test scripts are executed during the simulation run, when TPNS creates data streams in the required formats and protocols and sends 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.

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 (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.

During the simulation run, TPNS 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 run TPNS-supplied log analysis utilities to review the data exchanges in detail,[14]:31–86 to calculate response times,[14]:147–172 or to compare the 3270 screen images logged during two simulation runs of the same script(s).[14]:87–146

With TPNS V3R1 (1989), IBM provided 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.[13]:231–564 STL therefore made it possible to write test scripts, not only for the usual activity of simulated terminal operators, but also for exchanges between simulated and real application programs or, for example, to prototype elements of an ATM shared network.[5] Scripts written in STL must be translated into the TPNS macro assembler-like language before the simulation run and a translator utility is provided for that purpose.

Both scripting languages provide a comprehensive set of coding facilities that enable the test programmer to:

  • specify the input data (TEXT) entered by the simulated user(s) and any associated actions: think time delays (DELAY), pressing function keys (ENTER, PF3, etc.) and waiting for responses (WAIT) from the application under test;[4]:243–248
  • specify the protocols for session initiation and termination between simulated programmed resources and real programs, as well as performing data exchanges between them;[4]:26–56
  • define and alter the rate at which message traffic (EMTRATE) is generated during the simulation run;[4]:86–90,173–184
  • logic-test the content of incoming and/or outgoing messages and taking one of a wide range of optional actions according to the results of the evaluation (IF-THEN-ELSE);[4]:185–217, 92–95[13]:27–41,156–171, 219
  • set up test verification clauses that create log records for 'predicted good'/'predicted bad' conditions (VERIFY);[4]:90–92
  • externalize message text data into user tables, to make scripts more flexible and reusable (MSGUTBL);[4]:99,137–141
  • invoke an extensive range of data field options, to create test data dynamically into messages;[4]:90–92[13]:209–217
  • save real-time data into save areas for additional test data processing during the simulation run;[4]:146–154
  • generate random numbers;[4]:96–97
  • maintain a wide range of counters and switches;[4]:141–145,226–234
  • set up events to synchronise the activity of simulated users (ON/SIGNAL, WAIT/POST);[4]:167–168,234–243[13]:150–151,179–180
  • set up named queues to provide a queuing method for passing data between simulated resources (QUEUE);[15]:76–79
  • perform sequential file I/O (QSAM) operations from a script to a user-defined, external dataset;[15]:87–91
  • select script debugging facilities, including a message generation trace which logs the step-by-step flow of all logic tests, actions and data exchanges occurring during the execution of scripts (MSGTRACE);[4]:208–212
  • log message traffic during the simulation run,[4]:90–92 for post-processing analysis (including test data verification, response time calculation and screen image comparison across repeated simulations of the same scripts);
  • and many more.

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.

Script generation

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

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

The Interactive Data Capture (IDC) script generator[14]:175–211 is a 'pass-through & data intercept' application controlled by the test programmer from one real 3270 display screen in session with a real application for which a script is required. During the data capture—or 'recording'—session, the IDC application logs the data traffic exchanged between the test programmer and the real application, and then uses that log to generate the equivalent script, in either of the two scripting languages (macro assembler 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.

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

The 3270 trace reformatter and script generator[14]:213–229 processes the trace dataset produced by the IBM Network Performance Monitor (NPM), or the IBM VTAM Buffer Trace, when capturing the activity of a production network consisting of one or many 3270 devices. When the tracing activity is completed, the utility (ITPLU2RF)reformats the trace dataset into the 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 and compare screen images).

The script generator (ITPSGEN)

The script generator[14]:231–269 processes the trace dataset produced by the IBM Network Performance Monitor (NPM), or the IBM 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 non-3270 devices of various types and protocols, including LU0, LU1, LU2, LU4 and/or LU 6.2/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. Finally, the script generator itself produces scripts:

  • optionally in either language (macro-level or STL) for all its supported device types except CPI-C;
  • in STL only for CPI-C programmed resources.[14]:309

The TCP/IP script generator (ITPIPGEN)

The TCP/IP script generator[14]:277–282 was introduced into Wsim in October 2015. It processes a TCP/IP trace dataset produced by the Wsim-supplied TCP/IP Trace Utility (ITPIPTRX),[14]:167–172 which invokes the real-time, application-controlled TCP/IP trace Network Management Interface (NMI) to capture TCP/IP data trace records; these contain HTTP messages exchanged between a server and client. The TCP/IP script generator (ITPIPGEN) then creates a script in the STL language which, at simulation time, will replicate the communication that occurred between the server and client: the generated STL script sends the client messages—obtained from the trace—to the server port, and waits to receive a message from the server.[14]:277

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 manually or through the use of the TPNS Test Manager or its affiliated WSim Test Manager, both of which run under ISPF as knowledge-based, interactive utilities designed to boost the productivity of test personnel and further optimize the test cycle.[16]

Operational interfaces

In its early releases, TPNS 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 (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.).

Running under TSO

With V1R5 (1979), TPNS 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.[7]:30

Running as a VTAM application

With V2R3 (1985), TPNS was further 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.[7]:30 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 V2R4 (1987), TPNS introduced the Display Monitor which enabled the screen images of a simulated 3270 display to 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.[7]:31

Running under ISPF

With V3R3 (1992), TPNS and all its utilities could be operated from ISPF in a panel-driven fashion, instead of through the basic TSO command line.[7]:32

Running as a TCP/IP for MVS application

With V3R5 (1997), TPNS was further 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'.[17]:17–28 [18]:17–28

Test Manager

With V3R5 (1998), IBM introduced the TPNS Test Manager[16] 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 to retain full awareness, in real-time, of the events unfolding at every step and to intervene if necessary.

Additional facilities

The Echo program

The Echo program (ITPECHO)[14]:205–214 is supplied with TPNS (and WSim) and is 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). The Echo program enables network connectivity and load testing to be carried out without test personnel having to secure the availability of a production-level application. As its name implies, it will return exactly the message it has just received (sent with the 'Enter' key), but it can also return the amount of data that was requested in the previous message (sent with the 'PF5' key) from real or simulated display(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, the Echo program 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 (AVailability MONitor)[4]:361–433 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.

Publications library

Teleprocessing Network Simulator (TPNS) library

  • TPNS Samples SC30-3454
  • TPNS Operation SC30-3289
  • TPNS Messages and Codes SC30-3310
  • TPNS General Utilities SC30-3290
  • TPNS Script Generating Utilities SC30-3453
  • TPNS Planning and Installation SH20-2488
  • TPNS Language Reference SH20-2489
  • Defining TPNS Networks SC31-6008
  • Creating TPNS Message Generation Decks SC31-6009
  • Using TPNS Structured Translator Language (STL) and STL Translator SC31-6013
  • TPNS STL Reference Card SX75-0065
  • TPNS User Exits SC31-6071
  • TPNS Licensed Program Specifications GH20-5323
  • TPNS General Information GH20-2487
  • TPNS Primer SC31-6043
  • TPNS Master Index GC31-6059
  • TPNS Function and Service Enhancements V3R5 (1997) SC31-8654-00
  • TPNS Function and Service Enhancements V3R5 (2001) SC31-8654-02

Workload Simulator (WSim) library

  • Creating Workload Simulator Scripts SC31-8945
  • Workload Simulator Script Guide and Reference SC31-8946
  • Workload Simulator Utilities Guide SC31-8947
  • Workload Simulator User's Guide SC31-8948
  • Workload Simulator Test Manager User's Guide and Reference SC31-8949
  • Workload Simulator User Exits SC31-8950
  • Workload Simulator Messages and Codes SC31-8951

References

  1. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015.
  2. ↑ *Lua error in package.lua at line 80: module 'strict' not found. Retrieved on January 13, 2015.
  3. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  4. ↑ 4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 4.10 4.11 4.12 4.13 4.14 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on January 13, 2016
  5. ↑ 5.0 5.1 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on July 3, 2006
  6. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  7. ↑ 7.0 7.1 7.2 7.3 7.4 7.5 7.6 Lua error in package.lua at line 80: module 'strict' not found.
  8. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  9. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  10. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 30, 2015
  11. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  12. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 1, 2015
  13. ↑ 13.00 13.01 13.02 13.03 13.04 13.05 13.06 13.07 13.08 13.09 13.10 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on January 13, 2016.
  14. ↑ 14.00 14.01 14.02 14.03 14.04 14.05 14.06 14.07 14.08 14.09 14.10 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on January 13, 2016
  15. ↑ 15.0 15.1 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 29, 2015.
  16. ↑ 16.0 16.1 Lua error in package.lua at line 80: module 'strict' not found. Retrieved on January 13, 2016.
  17. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 29, 2015.
  18. ↑ Lua error in package.lua at line 80: module 'strict' not found. Retrieved on October 29, 2015.

Bibliography

  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.

External links

Retrieved from "https://infogalactic.com/w/index.php?title=IBM_TPNS&oldid=3841262"