IBM TPNS

Last updated
Other names
  • Teleprocessing Network Simulator (TPNS)
  • Workload Simulator (WSim)
Initial releaseFebruary, 1976;47 years ago (February, 1976)
Stable release
Workload Simulator V1.1 / September 5, 2018;5 years ago (2018-09-05)
Operating system MVS/370, OS/390, z/OS
Platform
Type Test automation software
License Proprietary
Website www.ibm.com/products/workload-simulator-for-zos

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] : 19–22 

Contents

In 2002, IBM re-packaged TPNS and released Workload Simulator for z/OS and S/390 (WSim) as a successor product. [2]

History

Features

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 (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients). [3] 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. [3]

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, TSO/ISPF, 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. [3]
  • 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, TSO/ISPF, 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. [3]

Workload Simulator for z/OS and S/390 (WSim)

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

Other uses

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

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:

  • the configuration of the network device(s) to be simulated (NTWRK definitions, simply called the network), [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, simply called scripts), [13] : 109–230  corresponding to the keystrokes and data transmission activity of the simulated user(s) at the simulated terminal(s). Separate scripts could be written to perform specific test scenarios, such as: 'login', 'data enquiry', 'data entry' and 'logout', for example;
  • the sequence in which scripts are to be executed by each (or all) simulated terminal(s):
    • in the NTWRK, one or more PATH statement(s) define(s) the order in which MSGTXTs are executed, [13] : 52 
    • each NTWRK terminal has a PATH operand that names the PATH statement(s) assigned to the terminal. [13] : 69, 93, 100 

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] : 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). [16] : 87–146 

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.

Structured Translator Language (STL)

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. [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 TPNS-simulated programs and real application programs or, for example, to prototype elements of an ATM shared network. [15] 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.

Script coding facilities

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

  • specify the input data entered by the simulated user(s), along with related actions: counting down think time delays, pressing keys to send data, then waiting for responses from the application under test; [14] : 107–136 
  • 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; [14] : 165–194, 92–95  [13] : 27–41, 150–164, 217 
  • set up test verification clauses that create log records for 'predicted good'/'predicted bad' conditions; [14] : 176–177 
  • group message text data in user data tables, to make scripts more generic and data-independent; [14] : 88–89, 121–125 
  • invoke an extensive range of data field options, to create test data dynamically into messages; [14] : 118–119  [13] : 199–207 
  • collect real-time data into save areas, during the simulation run, to re-use as 'on the fly' test data; [14] : 129–136 
  • generate random numbers; [14] : 119–120 
  • maintain a wide range of counters and switches; [14] : 202–209 
  • set up events to synchronise the activity of simulated users; [14] : 209–217  [13] : 24, 28, 145, 151, 172, 194, 303–304, 433 
  • set up named queues to provide a queuing method for passing data between simulated resources; [8] : 76–79 
  • perform sequential file I/O (QSAM) operations from a script to a user-defined, external dataset; [8] : 87–91 
  • select script debugging facilities, including a message generation trace (MSGTRACE) which logs the step-by-step flow of all logic tests, actions (taken and ignored), and data exchanges occurring during the execution of scripts; [14] : 87  [17] : 19–30 
  • log message traffic during the simulation run, [14] : 90–92  for post-processing analysis (including message generation tracing, data transmitted/received, printing screen images, test data verification, response time calculation, and screen image comparison across repeated simulations of the same scripts);
  • define and alter the rate at which message traffic is generated during the simulation run; [14] : 86–90, 173–184 
  • specify the protocols for session initiation and termination between simulated programmed resources and real programs, as well as for data exchanges between them; [14] : 26–56 
  • 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.

Syntax checking preprocessor

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. [16] : 11–24 

Repeatability

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] : 17–24 

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

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

The Interactive Data Capture (IDC) script generator [16] : 175–212  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.

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 [16] : 213–230  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 (ITPSGEN)

The script generator [16] : 231–269  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:

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

The TCP/IP script generator (ITPIPGEN)

The TCP/IP script generator [16] : 277–282  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), [16] : 167–170  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. [16] : 277  A separate utility (ITPIPFMT) [16] : 171–172  is also supplied to format and print the contents of the trace dataset created by the TCP/IP Trace Utility (ITPIPTRX).

The TPNS 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 (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]

Run-time interfaces

Operator commands

Once the TPNS program ITPENTER (the simulator) has been submitted for execution and is up and running, [1] : 66–70  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] : 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] : 113–114 

Running as a MVS procedure

In its early releases, ITPENTER ran as a MVS procedure controlled from the MVS operator console. [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.).

Running under TSO

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] : 30 

Running as a VTAM application

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] : 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 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] : 31 

Running under ISPF

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] : 32 

Running as a TCP/IP for MVS application

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 

TPNS Test Manager

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.

Post-processing utilities

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.

Log list (ITPLL)

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] : 25–61 

Response time calculator (ITPRESP)

The response time calculator (ITPRESP) is used to calculate and print response times reports. [16] : 107–149 

Log compare (ITPCOMP)

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. [16] : 63–106 

Additional facilities

The Echo program (ITPECHO)

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

The AVailability MONitor (AVMON) facility

Rather than applying TPNS as a test tool, AVMON (AVailability MONitor) [14] : 319–367  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

Workload Simulator (WSim) library

Related Research Articles

<span class="mw-page-title-main">IBM 3270</span> Family of block-oriented display terminals and printers made by IBM

The IBM 3270 is a family of block oriented display and printer computer terminals introduced by IBM in 1971 and normally used to communicate with IBM mainframes. The 3270 was the successor to the IBM 2260 display terminal. Due to the text color on the original models, these terminals are informally known as green screen terminals. Unlike a character-oriented terminal, the 3270 minimizes the number of I/O interrupts required by transferring large blocks of data known as data streams, and uses a high speed proprietary communications interface, using coaxial cable.

<span class="mw-page-title-main">MVS</span> Operating system for IBM mainframes

Multiple Virtual Storage, more commonly called MVS, is the most commonly used operating system on the System/370, System/390 and IBM Z IBM mainframe computers. IBM developed MVS, along with OS/VS1 and SVS, as a successor to OS/360. It is unrelated to IBM's other mainframe operating system lines, e.g., VSE, VM, TPF.

z/OS 64-bit operating system for IBM mainframes

z/OS is a 64-bit operating system for IBM z/Architecture mainframes, introduced by IBM in October 2000. It derives from and is the successor to OS/390, which in turn was preceded by a string of MVS versions. Like OS/390, z/OS combines a number of formerly separate, related products, some of which are still optional. z/OS has the attributes of modern operating systems but also retains much of the older functionality originated in the 1960s and still in regular use—z/OS is designed for backward compatibility.

<span class="mw-page-title-main">OS/390</span> Operating system for IBM mainframes

OS/390 is an IBM operating system for the System/390 IBM mainframe computers.

Systems Network Architecture (SNA) is IBM's proprietary networking architecture, created in 1974. It is a complete protocol stack for interconnecting computers and their resources. SNA describes formats and protocols but, in itself, is not a piece of software. The implementation of SNA takes the form of various communications packages, most notably Virtual Telecommunications Access Method (VTAM), the mainframe software package for SNA communications.

<span class="mw-page-title-main">Conversational Monitor System</span> Operating system

The Conversational Monitor System is a simple interactive single-user operating system. CMS was originally developed as part of IBM's CP/CMS operating system, which went into production use in 1967. CMS is part of IBM's VM family, which runs on IBM mainframe computers. VM was first announced in 1972, and is still in use today as z/VM.

<span class="mw-page-title-main">VM (operating system)</span> Family of IBM operating systems

VM is a family of IBM virtual machine operating systems used on IBM mainframes System/370, System/390, zSeries, System z and compatible systems, including the Hercules emulator for personal computers.

<span class="mw-page-title-main">IBM Information Management System</span> Joint hierarchical database made by IBM

The IBM Information Management System (IMS) is a joint hierarchical database and information management system that supports transaction processing.

<span class="mw-page-title-main">CICS</span> IBM mainframe transaction monitor

IBM CICS is a family of mixed-language application servers that provide online transaction management and connectivity for applications on IBM mainframe systems under z/OS and z/VSE.

Systems Application Architecture (SAA), introduced in 1987, is a set of standards for computer software developed by IBM. The SAA initiative was started in 1987 under the leadership of Earl Wheeler, the "Father of SAA". The intent was to implement SAA in IBM operating systems including MVS, OS/400 and OS/2. AIX—IBM's version of the UNIX operating system—was not a target of SAA, but does have interoperability with the SAA family.

Virtual Telecommunications Access Method (VTAM) is the IBM subsystem that implements Systems Network Architecture (SNA) for mainframe environments. VTAM provides an application programming interface (API) for communication applications, and controls communication equipment such as adapters and controllers. In modern terminology, VTAM provides a communication stack and device drivers.

IBM MQ is a family of message-oriented middleware products that IBM launched in December 1993. It was originally called MQSeries, and was renamed WebSphere MQ in 2002 to join the suite of WebSphere products. In April 2014, it was renamed IBM MQ. The products that are included in the MQ family are IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ for z/OS, and IBM MQ on IBM Cloud. IBM MQ also has containerised deployment options.

In computing, Advanced Program to Program Communication or APPC is a protocol which computer programs can use to communicate over a network. APPC is at the application layer in the OSI model, it enables communications between programs on different computers, from portables and workstations to midrange and host computers. APPC is defined as VTAM LU 6.2

Binary Synchronous Communication is an IBM character-oriented, half-duplex link protocol, announced in 1967 after the introduction of System/360. It replaced the synchronous transmit-receive (STR) protocol used with second generation computers. The intent was that common link management rules could be used with three different character encodings for messages.

ORVYL is a time-sharing monitor developed by Stanford University for IBM System/360 and System/370 computers in 1967–68. ORVYL was one of the first time-sharing systems to be made available for IBM computers. Wylbur is a text editor and word processor program designed to work either without ORVYL, or in conjunction with ORVYL.

<span class="mw-page-title-main">OS/VS1</span> IBM operating system

Operating System/Virtual Storage 1, or OS/VS1, is a discontinued IBM mainframe computer operating system designed to be run on IBM System/370 hardware. It was the successor to the Multiprogramming with a Fixed number of Tasks (MFT) option of System/360's operating system OS/360. OS/VS1, in comparison to its predecessor, supported virtual memory. OS/VS1 was generally available during the 1970s and 1980s, and it is no longer supported by IBM.

Telecommunications Access Method (TCAM) is an access method, in IBM's OS/360 and successors computer operating systems on IBM System/360 and later, that provides access to terminals units within a teleprocessing network.

Barry Appelman is recognized as being the father of the "buddy list" and AOL instant messenger. Companies had been using crude forms of Instant messaging within their own networks for over forty years, but the idea of presence, i.e. who is logged on at any given time, was non existent. It was not until Appelman, and his colleagues at the Thomas Watson Research Center, first began to write programs on the mainframe system letting each other know when they were actually online, that modern day Instant Messaging was born.


MTCS was a transaction processor that ran on IBM mainframe systems under OS/VS1 and DOS/VS.

DUCS was a teleprocessing monitor from CFS Inc. It was one of two early local teleprocessing packages for IBM's DOS/VSE environment. DUCS provided an interface and access method for programmers to 'talk' to monitors. Such access methods later became known as APIs.

References

  1. 1 2 3 4 5 6 7 IBM Workload Simulator ~ User's Guide (PDF). Second Edition. IBM. October 2015. SC31-8948-01. Retrieved on January 13, 2015.
  2. ↑ IBM Corporation (2002). IBM Workload Simulator for z/OS and S/390 V1.1. Retrieved on October 1, 2015
  3. 1 2 3 4 5 6 IBM Corporation (1998). IBM TPNS—Teleprocessing Network Simulator (PDF). Retrieved October 1, 2015.
  4. ↑ IBM Corporation (1976). IBM TPNS—Teleprocessing Network Simulator . Retrieved October 1, 2015.
  5. 1 2 3 4 5 6 7 Chandler, D. Dale (July 23, 1992). TPNS History. Cary, NC: IBM Corporation.
  6. ↑ IBM TPNS Teleprocessing Network Simulator Version 3 Release 5 Function and Service Enhancements. First Edition. IBM. December 1997. SC31-8654-0.
  7. ↑ IBM Corporation (1998). IBM TPNS—Teleprocessing Network Simulator ~ Test Manager (PDF). Retrieved October 1, 2015.
  8. 1 2 3 IBM Teleprocessing Network Simulator ~ Function and Service Enhancements Version 3 Release 5 - 2001 (PDF). Second Edition. IBM. December 2001. SC31-8654-02. Retrieved October 30, 2015.
  9. ↑ IBM Corporation (2002). IBM Workload Simulator for z/OS and S/390 V1.1 . Retrieved October 1, 2015.
  10. ↑ IBM Corporation (2002). IBM Workload Simulator for z/OS and S/390 V1.1 ~ Test Manager (PDF). Retrieved October 1, 2015.
  11. ↑ IBM Corporation (2012). PM69087: Maintenance update for IBM Workload Simulator for z/OS and S/390 V1.1 . Retrieved July 26, 2021.
  12. ↑ IBM Corporation (2015). PI46383: Enhancements for TCP/IP support in IBM Workload Simulator for z/OS and S/390 V1.1 . Retrieved July 26, 2021.
  13. 1 2 3 4 5 6 7 8 9 10 11 IBM Workload Simulator ~ Script Guide and Reference (PDF). Second Edition. IBM. October 2015. SC31-8946-01. Retrieved on January 13, 2016.
  14. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 IBM Workload Simulator ~ Creating Workload Simulator Scripts (PDF). Second Edition. IBM. October 2015. SC31-8945-01. Retrieved on January 13, 2016
  15. 1 2 Feuerman, Melvyn (October 26, 2001). TPNS Prototyping (PDF). Retrieved on July 3, 2006
  16. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 IBM Workload Simulator ~ Utilities Guide (PDF). Second Edition. IBM. October 2015. SC31-8947-01. Retrieved on January 13, 2016
  17. ↑ "Informational log data set messages (400 - 499)". IBM Workload Simulator ~ Messages and Codes (PDF). Second Edition. IBM. October 2015. SC31-8951-01. Retrieved on August 1, 2021
  18. ↑ "PI46383: ENHANCE THE WORKLOAD SIMULATOR SUPPORT FOR TCP/IP". ibm.com. 2015. Retrieved 13 January 2016.
  19. 1 2 IBM Workload Simulator ~ Test Manager User's Guide and Reference (PDF). Second Edition. IBM. October 2015. SC31-8949-01. Retrieved on January 13, 2016.
  20. ↑ "High Performance Native Sockets". IBM TCP/IP Version 3 Release 2 for MVS/ESA. Announcement Number 296-317. IBM. September 10, 1996. Retrieved on October 29, 2015.
  21. ↑ "Chapter 2. Additional TPNS TCP/IP Support". IBM Teleprocessing Network Simulator ~ Function and Service Enhancements Version 3 Release 5. First Edition. IBM. December 1997. pp. 17–28. SC31-8654-00. Retrieved on October 29, 2015.

Bibliography

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.