Teleprocessing Network Simulator (TPNS) ist ein von IBM lizenziertes Programm, das erstmals 1976 als Testautomatisierungstool zur Simulation eines oder mehrerer Netzwerkterminals auf einem Mainframe-Computersystem für Funktionstests, Regressionstests, Systemtests und Kapazitätsmanagement veröffentlicht wurde. Benchmarking und Stresstests. Im Jahr 2002 packte IBM TPNS neu und veröffentlichteWorkload Simulator für z / OS und S / 390 (WSim) als Nachfolgeprodukt.
Zusätzlich zu seiner Verwendung als Testtool für den Austausch von Nachrichtenverkehr mit einem zu testenden System wurde TPNS / Wsim bereitgestellt:
Version 1 Release 1 (V1R1) wurde im Februar 1976 als Programmprodukt 5740-XT4 eingeführt. Zwischen 1976 und 1981 lieferte IBM vier weitere Releases aus, die in V1R5 gipfelten.
TPNS unterstützt die Simulation einer Vielzahl von Netzwerkprotokollen und -geräten: SNA / SDLC, Start-Stopp-, BSC-, TWX-, TTY-, X.25-Paketvermittlungsnetzwerk, Token Ring Local Area Networking sowie TCP / IP- Server und -Clients ( Telnet) 3270 amp; 5250, Virtuelles Netzwerk im Telnet- Leitungsmodus, FTP und einfache UDP- Clients). TPNS kann Geräte auch mithilfe der Airline Line Control (ALC) und der HDLC- Protokolle simulieren. Die vollständige Implementierung von SNA in TPNS ermöglicht die Simulation aller LU- Typen (einschließlich LU6.2 und CPI-C ), PU- Typen (einschließlich PU2.1) und SSCP- Funktionen. Schließlich bietet TPNS auch einen umfassenden User-Exit- Zugriff auf seine internen Prozesse, um die Simulation von benutzerdefinierten (selbst entwickelten) Leitungsdisziplinen, Kommunikationsprotokollen, Geräten ( Terminals und Druckern ) und Programmen zu ermöglichen.
TPNS ist daher das geeignete Testwerkzeug für Installationen, die getestet werden müssen:
WSim unterstützt eine Teilmenge von TPNS-simulierten Geräten und programmierten Ressourcen vollständig: CPI-C, TCP / IP- Server und -Clients ( Telnet 3270 und 5250, virtuelles Terminal des Telnet- Leitungsmodus-Netzwerks, FTP- und einfache UDP- Clients) und SNA LU- Simulation. WSim verwendet ausschließlich Softwareschnittstellen, um mit dem zu testenden System zu kommunizieren.
WSim ist daher das geeignete Testtool für Installationen, die Anwendungssysteme und deren Hardware- und Softwarekomponenten testen müssen, von der API für Netzwerkzugriffsmethoden (entweder die VTAM- API oder die TCP / IP- API für High Performance Native Sockets oder Makros) bis zur Subsystem (CICS, IMS, DB2, TSO / ISPF usw.), die Anwendung und schließlich zum Datei- oder Datenbankdatensatz (Festplatten-E / A) und zurück; Das heißt, ohne dass Netzwerkhardware- und -softwarekomponenten mit Ausnahme der Netzwerkzugriffsmethode (VTAM oder IBM TCP / IP für MVS) installiert werden müssen, die bereits auf dem Hostsystem (Server) ausgeführt wird oder bereits mit dem Netzwerk verbunden ist. im Test.
TPNS stellte zunächst eine eigene 'TPNS-Sprache' bereit, eine Makro-Assembler- ähnliche Hochsprache mit Programmieranweisungen und Operanden, mit denen ein Testprogrammierer Folgendes definieren würde:
Nach der Definition werden diese Testskripte während des Simulationslaufs ausgeführt, wenn das TPNS-Programm ITPENTER (der Simulator) die übermittelten Anweisungen verarbeitet und Datenströme in den erforderlichen Formaten und Protokollen erstellt, bevor sie an das zu testende System gesendet werden stammt von realen Benutzern, die reale Terminals bedienen. Die Zielanwendung (en), die in dem zu testenden System ausgeführt werden, reagieren wiederum auf die simulierten Terminals. Wenn die Simulation erfolgreich ist, werden diese Austausche fortgesetzt, bis die programmierten Skripte das Ende des Simulationslaufs erreichen. Zu diesem Zeitpunkt wird ITPENTER vom Testprogrammierer beendet.
Während der Simulation führt ITPENTER ein Protokoll (auf Band oder Festplatte) aller Nachrichten, die zwischen den simulierten Geräten und den tatsächlich getesteten Anwendungen ausgetauscht werden. Nach Abschluss der Simulation kann der Testprogrammierer daher eines der drei von TPNS bereitgestellten Dienstprogramme zur Protokollanalyse ausführen, um den Datenaustausch im Detail (ITPLL) aufzulisten und zu überprüfen, Antwortzeitberichte (ITPRESP) zu berechnen und zu drucken oder den 3270 zu vergleichen Bildschirmbilder, die während zweier Simulationsläufe desselben Skripts protokolliert wurden, und Berichte über Unterschiede zwischen ihnen (ITPCOMP).
Als TPNS 2002 neu verpackt und in "WSim" umbenannt wurde, wurde der Begriff "TPNS-Sprache" in den Produktpublikationen in "WSim-Sprache" geändert. Alle in WSim neu gepackten TPNS-Komponenten, wie z. B. die TPNS-Programmnamen (ITPxxxxx), behielten jedoch ihre Identität bei, und die vorhandene Nomenklatur wurde beibehalten.
Mit TPNS V3R1 (1989) fügte IBM die Structured Translator Language (oder 'STL') hinzu, eine TPNS-Skriptsprache auf hoher Ebene mit einer auf REXX basierenden Syntax, um das Schreiben von Testskripten durch Programmierer zu erleichtern, die mit REXX oder ähnlichem vertraut sind strukturierte Programmiersprachen. STL ermöglichte es daher, Testskripte nicht nur für die übliche Aktivität simulierter Terminalbetreiber zu schreiben, sondern auch für den Austausch zwischen TPNS-simulierten Programmen und realen Anwendungsprogrammen oder zum Beispiel für Prototypelemente eines gemeinsam genutzten ATM- Netzwerks. In STL geschriebene Skripte müssen vor dem Simulationslauf in die TPNS-Sprache übersetzt werden, und zu diesem Zweck wird ein Übersetzungsdienstprogramm (ITPSTL) bereitgestellt.
Eine andere Möglichkeit, STL zu definieren, wäre die Verwendung einer Sprache zur Skriptgenerierung. Die Programmierklauseln sind identisch mit REXX, müssen jedoch in die TPNS-Sprache übersetzt (dh "Skript generiert") werden, damit sie während des Simulationslaufs ausgeführt werden können.
Beide Skriptsprachen bieten umfassende Codierungsfunktionen, mit denen der Testprogrammierer:
WSim unterstützt dieselben Skriptsprachenfunktionen wie TPNS, außer dass für die Netzwerkkonfigurationsdefinitionen (NTWRK) nur die Anweisungen erforderlich sind, die für CPI-C-, TCP / IP- Server und -Clients bereitgestellt werden ( Telnet 3270 und 5250, Telnet Line Mode Network Virtual Terminal, FTP und einfache UDP- Clients) und SNA LU- Simulation.
Einer der Vorteile der Verwendung von Testskripten besteht darin, dass sie während des gesamten Testzyklus wiederholt ausgeführt werden können, da Funktionsfehler und / oder systemweite Fehler im Laufe der Zeit schrittweise behoben werden, um die Zuverlässigkeit, Kapazität oder Leistung von oder zu verbessern alle Hardware- oder Softwarekomponenten im zu testenden System. Für Funktions- und Regressionstests definieren Testprogrammierer normalerweise ein Netzwerk von nur einem simulierten Terminal, das Testskripte ausführt, die darauf zugeschnitten sind, einen umfassenden Satz von Transaktionen (Datenbankabfrage oder Dateneingabe) seriell und mit langsamen oder durchschnittlichen Nachrichtenverkehrsraten auszuwerten. Für Systemtests, Leistungs- / Kapazitätstests, Stresstests und Benchmarking definieren dieselben Testprogrammierer große Netzwerke von Dutzenden oder sogar Tausenden von simulierten Terminals, auf denen beispielsweise eine Reihe dieser Funktionstestskripte ausgeführt wird, die jetzt zu Übungszwecken zusammengefasst sind so viele Systemkomponenten wie möglich bei hohen Nachrichtenverkehrsraten.
TPNS bietet eine Reihe von Lösungen zur Automatisierung der Erstellung von Testskripten. Die in den nächsten drei Abschnitten beschriebenen Funktionen zur Skripterstellung sind auch in Workload Simulator für z / OS und S / 390 (WSim) verfügbar.
Der IDC-Skriptgenerator ( Interactive Data Capture) ist eine VTAM-Anwendung (Pass-Through amp; Data Intercept) (ITPIDC), die vom Testprogrammierer von einem realen 3270-Bildschirm in einer Sitzung mit einer Zielanwendung gesteuert wird, für die ein Skript erforderlich ist. ITPIDC verwaltet zwei SNA-Sitzungen gleichzeitig: eine primäre LU-Sitzung mit dem vom Testprogrammierer betriebenen realen 3270-Terminal und eine sekundäre LU-Sitzung mit der Zielanwendung. Während der Datenerfassungs- oder Aufzeichnungssitzung protokolliert ITPIDC den Datenverkehr, der zwischen dem realen 3270-Gerät des Testprogrammierers und der Zielanwendung ausgetauscht wird, und generiert anhand dieses Protokolls das entsprechende Skript in einer der beiden Skriptsprachen (TPNS) Sprache oder STL).
Da das IDC-Protokolldatensatz genau das gleiche Format hat wie das Protokolldatensatz, das TPNS während eines Simulationslaufs erstellt, kann es als Eingabe für die TPNS-Nachbearbeitungsdienstprogramme verwendet werden, um seinen Inhalt zu drucken, die Antwortzeiten der IDC-Sitzung zu berechnen oder Vergleichen der Bildschirmbilder der Datenerfassungssitzung mit dem TPNS-Protokoll, das durch Ausführen des IDC-generierten Skripts erhalten wurde.
Bei der Erfassung der Aktivität eines Produktionsnetzwerks, das aus einem oder mehreren 3270-Geräten besteht, verarbeitet der 3270-Trace-Reformatter und der Skriptgenerator das Trace-Dataset, das vom VTAM PIU-Protokoll (FNMVLOG) des IBM Network Performance Monitor (NPM V1R4 oder höher) oder vom IBM VTAM (V4R1 oder höher) Full Buffer Trace. Wenn die Ablaufverfolgungsaktivität abgeschlossen ist, formatiert ein Dienstprogramm (ITPLU2RF) das Ablaufverfolgungsdatensatz in ein Protokolldatensatz in dem Format um, das als Eingabe für den IDC-Skriptgenerator erforderlich ist (siehe vorherigen Abschnitt), der auch Skripts im Stapelmodus (ITPLSGEN) erstellen kann. Dieses neu formatierte IDC-Protokoll kann auch von den drei Nachbearbeitungsprogrammen analysiert werden (Listen Sie den Inhalt des Protokolls auf, berechnen Sie die Antwortzeiten oder vergleichen Sie Bildschirmbilder).
Der Skriptgenerator verarbeitet das vom IBM Network Performance Monitor (NPM) oder vom IBM VTAM Buffer Trace in Verbindung mit der IBM Generalized Trace Facility (GTF) erstellte Trace-Dataset, wenn ein Produktionsnetzwerk mit einem oder mehreren 3270-Geräten verfolgt wird sowie Geräte verschiedener Typen und Protokolle, einschließlich LU0-, LU1-, LU2-, LU4-, LU 6.2- und CPI-C- Ressourcen. Für die CPI-C-Skriptgenerierung kann auch das vom OS / 2 Communications Manager (CM / 2) oder vom IBM Communications Server erstellte LU 6.2-Trace-Dataset verwendet werden. Verschiedene von TPNS bereitgestellte Dienstprogramme formatieren eines dieser verschiedenen Trace-Datasets in ein Single-Format-Dataset um, das als Eingabe für den Skriptgenerator (ITPSGEN) verwendet wird, der Skripte erstellt:
Der TCP / IP- Skriptgenerator ist einzigartig für WSim und wurde im Dezember 2015 eingeführt. Er verarbeitet ein TCP / IP-Trace-Dataset, das vom von WSim bereitgestellten TCP / IP-Trace-Dienstprogramm (ITPIPTRX) erstellt wurde und den z / OS Communication Server real aufruft. Zeitgesteuerte, anwendungsgesteuerte TCP / IP-Ablaufverfolgung Network Management Interface (NMI) zum Erfassen von TCP / IP-Datenablaufverfolgungsdatensätzen. Diese Trace-Datensätze enthalten HTTP- Nachrichten (Pakete und Daten), die zwischen einem Server und einem Client ausgetauscht werden. Der TCP / IP-Skriptgenerator (ITPIPGEN) verarbeitet dann dieses Trace-Dataset und erstellt ein Skript in der STL-Sprache, das die Kommunikation zwischen Server und Client repliziert. Nach der Übersetzung von STL in die WSim-Sprache und beim Ausführen der Simulation (ITPENTER) sendet das generierte Skript die aus dem Trace erhaltenen Client-Nachrichten an den Server-Port und wartet auf den Empfang einer Nachricht vom Server. Ein separates Dienstprogramm (ITPIPFMT) wird ebenfalls bereitgestellt, um den Inhalt des vom TCP / IP-Trace-Dienstprogramm (ITPIPTRX) erstellten Trace-Datasets zu formatieren und zu drucken.
Es ist gängige Praxis, dass ein von einem Skriptgenerator erhaltenes Skript anschließend von Testprogrammierern bearbeitet wird, um solche Skripte allgemeiner wiederverwendbar zu machen. Dieser Bearbeitungsprozess besteht darin, erweiterte Skriptprogrammierklauseln hinzuzufügen, die Skriptgeneratoren nicht bereitstellen können, z. B. das erneute Auffinden fest codierter Daten in Benutzerdatentabellen, die dann beispielsweise um weitere Testdaten erweitert werden können. Diese Bearbeitung kann direkt in den NTWRK und MSGTXT Datensätze durchgeführt werden, oder durch die Dienste der TPNS Test Manager (oder mit ihrem verbundenen WSIM Test Managern), die wie TPNS (und WSIM), läuft auch unter TSO / ISPF. Der Test Manager ist ein wissensbasiertes, interaktives Usability-Tool, mit dem die Produktivität des Testpersonals gesteigert und der Testzyklus optimiert werden kann, indem Testprojekte während der Entwicklung und Ausführung von Testfällen sowie bei der anschließenden Analyse methodisch organisiert werden können Testergebnisse.
In seinen frühen Versionen wurde das TPNS-Programm ITPENTER (der Simulator) als MVS- Prozedur ausgeführt, die über die MVS-Bedienerkonsole gesteuert wird. Seine erzeugte Datenverkehr wurde von seiner MVS übertragen Adreßraum, zuerst über einen Kanal-Adapter auf seiner TPNS Control Program (TPNCP) in einem eigenen Lauf IBM 37X5 Communications Controller, und dann über Datenfernleitungen verbunden sind Rücken an Rücken zwischen den TPNCP und Das Ziel des IBM 37x5-Kanals, das an das zu testende Hostsystem und seine Anwendungssubsysteme ( CICS, IMS, DB2, TSO / ISPF usw.) angeschlossen ist.
Mit TPNS V1R5 (1979) wurde ITPENTER so erweitert, dass es von einer TSO- Befehlsliste (im TSO-Benutzeradressraum) ausgeführt werden kann und daher Simulationen von einem Remote-Anzeigeterminal im VTAM- Netzwerk anstelle der MVS-Systemkonsole ausgeführt werden können.
Mit TPNS V2R3 (1985) wurde ITPENTER für die Ausführung als VTAM-Anwendung erweitert, wodurch der von seinen simulierten Terminals oder programmierten Ressourcen (jetzt als logische VTAM-Einheiten definiert) erzeugte Datenverkehr über die VTAM- API an die zu testende Anwendung gesendet wird. Dadurch wurde die Notwendigkeit einer 37x5- und anderer dedizierter Teleprocessing-Hardware beseitigt, wenn TPNS zum Testen von Anwendungssystemen verwendet wird, die unter VTAM ausgeführt werden, z. B. CICS, IMS, DB2, ISPF und andere Online-Transaktionsverarbeitungssysteme.
Mit TPNS V2R4 (1987) wurde ITPENTER mit dem Display Monitor erweitert, sodass die Bildschirmbilder eines simulierten 3270-Displays auf ein reales 3270-Terminal ausgelagert werden konnten, sodass das Testpersonal die laufende Live-Ausführung eines Skripts während des Simulationslauf in Echtzeit. Es wurde auch möglich, TPNS über die NetView- Konsole zu bedienen und TPNS-Simulationsläufe von NetView mithilfe von TPNS-bereitgestellten NetView- Befehlslisten zu automatisieren.
Mit TPNS V3R3 (1992) konnten alle TPNS-Programme und -Dienstprogramme (ITPxxxxx) vollständig über ISPF auf Panel-gesteuerte Weise anstatt über die TSO-Befehlszeile oder über diskrete JCL- Jobströme betrieben werden.
Mit TPNS V3R5 (1997) wurde ITPENTER so erweitert, dass es als TCP / IP für MVS-Anwendung ausgeführt werden kann. Dadurch wurde der von den simulierten Terminals und / oder programmierten Ressourcen (Clients) generierte Datenverkehr an die zu testenden Anwendungen (Server) gesendet über die HPNS-API (IBM TCP / IP V3R2 für MVS High Performance Native Sockets), die anschließend in "Makro-API" umbenannt wurde.
Mit TPNS V3R5 (1998) führte IBM den TPNS Test Manager ein, der umfangreiche Automatisierungsfunktionen hinzufügte, die viele sich wiederholende Aufgaben im Zusammenhang mit der Planung, Vorbereitung, dem Betrieb und der Analyse eines TPNS-basierten Simulationslaufs rationalisieren und es dem Testprogrammierer optional ermöglichen, die volle Aufmerksamkeit zu behalten in Echtzeit über die Ereignisse, die sich bei jedem Schritt abspielen, und gegebenenfalls einzugreifen.
Während der Simulation führt ITPENTER ein Protokoll (auf Band oder Festplatte) aller Nachrichten, die zwischen den simulierten Geräten und den tatsächlich getesteten Anwendungen ausgetauscht werden. Nach Abschluss der Simulation kann der Testprogrammierer daher eines der drei von TPNS bereitgestellten Dienstprogramme zur Protokollanalyse ausführen.
Das Protokolllisten-Dienstprogramm (ITPLL) wird verwendet, um den Datenaustausch detailliert aufzulisten und zu überprüfen.
Der Antwortzeitrechner (ITPRESP) wird zum Berechnen und Drucken von Antwortzeitberichten verwendet.
Das Dienstprogramm zum Vergleichen von Protokollen (ITPCOMP) wird verwendet, um die 3270 Bildschirmbilder zu vergleichen, die während zweier Simulationsläufe derselben Skripte protokolliert wurden, und um Unterschiede zwischen ihnen zu melden.
Das Echo- Programm (ITPECHO) wird mit TPNS (und WSim) als vorgefertigte VTAM-Anwendung geliefert, die im zu testenden System als Ziel für Nachrichten ausgeführt wird, die von realen oder simulierten 3270-Anzeigegeräten gesendet werden. Durch die Verwendung von ITPECHO können Netzwerkkonnektivität und Lasttests durchgeführt werden, ohne dass eine Kopie einer Anwendung auf Produktionsebene und ihrer Datenbanken eingerichtet werden muss. Dadurch erspart das Testpersonal den Aufwand, Skripte zu schreiben oder Speicherplatz für eine solche Anwendung und ihre Datensätze zuzuweisen. Wie der Name schon sagt, gibt ITPECHO genau die Nachricht zurück, die es gerade erhalten hat (beim Senden mit der Eingabetaste), kann aber auch die Datenmenge zurückgeben, die in der vorherigen Nachricht angefordert wurde (beim Senden mit dem PF5). Taste) von realen oder simulierten Anzeigegeräten. Die letztere Funktion ist nützlich, um Testbedingungen zu erstellen, bei denen die Nachrichten "Senden" und "Empfangen" unterschiedliche und variable Längen haben müssen. Um die angeforderte Datenmenge bereitzustellen, füllt ITPECHO seine Nachricht mit so vielen Vorkommen des Alphabets wie nötig oder einem Bruchteil davon, wenn die angeforderte Datenmenge weniger als 26 Zeichen beträgt.
Anstatt TPNS als Testtool anzuwenden, ist AVMON (AVailability MONitor) eine TPNS-Implementierung, mit der die Verfügbarkeit und Leistung realer Netzwerksubsysteme überwacht werden soll, die in der Produktion ausgeführt werden (NetView und TSO). Die von TPNS bereitgestellten AVMON-Beispielskripts überwachen nur NetView und TSO. Eine Benutzerinstallation unterstützt jedoch möglicherweise die Überwachung weiterer Subsysteme (CICS, IMS, DB2 usw.) und ihrer Anwendungen, indem die AVMON-Skripts möglicherweise durch geändert oder erweitert werden die Verwendung des oben erwähnten Interactive Data Capture- Skriptgenerators zum Erstellen der neuen Skripte. Während des TPNS-Simulationslaufs aktualisiert AVMON den TPNS-Protokolldatensatz, der daher von den drei TPNS-Dienstprogrammen zur Protokollanalyse (Protokollliste, Antwortzeitrechner und Protokollvergleich) verarbeitet werden kann.
AVMON überwacht die Verfügbarkeit, indem es einen einzelnen Terminalbenutzer in einer Sitzung mit einem realen Subsystem simuliert, regelmäßig eine kurze Prüfnachricht sendet und erkennt, wenn das Subsystem nicht mehr verfügbar ist. Wenn der simulierte Benutzer eine Nichtverfügbarkeit feststellt, sendet er eine Nachricht an die Bedienerkonsole, um den Bediener auf das Problem aufmerksam zu machen. AVMON verfolgt auch die Zeit, die das überwachte Subsystem benötigt, um eine Antwort zurückzugeben, und meldet, wann immer ein benutzerdefinierter Leistungsschwellenwert überschritten wird. Mithilfe des Dienstprogramms TPNS Response Time können die Leistungsstatistiken des gesamten Überwachungslaufs in einem einzigen Bericht zusammengefasst werden. Auf diese Weise wird eine Installation mit Nachweisen für die End-to-End-Antwortzeiten der Endbenutzer des Subsystems bereitgestellt. Für automatisierte Vorgänge kann AVMON auch so geändert werden, dass Bedienerfunktionen ausgeführt werden, wenn festgestellt wird, dass eine reale Ressource nicht mehr funktionsfähig ist und daher ein Bedienereingriff erforderlich ist, z. B. ein Neustart der Ressource.
