IBM System i (aka AS / 400) - How we did auto tests for green screen applications
Hello! My name is Anton Vorobyev, I am responsible in Alfa-Bank for developing applications for a centralized banking system.
In this post I will tell you about what green screen applications are, why they are needed and how we did autotests for them by writing our own solution for this, which allowed us to speed up autotests by 11 times.
')
The AS / 400 platform (Application System / 400) was born in 1988. The first OS for this platform is OS / 400, later renamed to i5 / OS and even later to IBM i. Not so long ago she celebrated her thirtieth birthday.
Plunging into the world of development under the IBM i operating system, you understand that this is actually no “legacy” in the classic sense of the word. This is a different, completely different environment, which has little in common with familiar Windows or Unix systems. The main task of this OS is to be as productive as possible on the hardware with which it works, and not to be user friendly.
IMHO, this OS can make you crazy how familiar approaches to writing C ++ code are ineffective on it (up to a dozen times CPU loss), that some antipatterns shown in textbooks are the best-practice of effective code, and the source code with the date of writing For 1978, they are not just assembled without problems, but also work as designed! All this makes a new look at modern approaches to software development.
The issue of improving the quality of the developed software is worrying the minds of each development team. Not bypassed this moment and one of our credit teams, whose task is to develop and develop the Back part of the module for the automated banking system Misys Equation. The peculiarity of this ABS is that:
IBM i (logo)
We develop applications for this ABS (ABS options) in accordance with the Misys ITP developer standard - Integrator's Technical Package, which stipulates that the option should consist of an interactive program for terminal interaction with the end user and implement the API using the set interface for background execution .
Such interactive programs developed under the IBM i operating system are historically called green-screen applications and are the only UI with which the user of this ABS interacts.
The simple answer is an application that looks like this:
Or so :
Historically, the only interactive applications running on the low and mid-range systems of the AS / 400 family and other IBM meinframes that allowed you to request any user input are green screen applications. Installation, administration, configuration, and development on the IBM i operating system (and its predecessors, i5 / OS and AS400) were conducted (and are still under way somewhere) exclusively using green screen applications.
The green screen application has two sizes - 24x80 and 27x132 characters and 16 possible colors. Within these scales, most of the work of the developers and users of this operating system is performed.
These screen sizes are the result of the evolution of “workstations” that connected to the mothers of the AS400 from the low-end and mid-range segment of the IBM System / 32, System / 34, System / 36 and System / 38 computers. These workstations were called terminals and were a screen in a metal case with a keyboard and additional equipment in the form of a light pen. Initially, only two colors of the screen were supported - it is green and bright green, which is why the well-established phrase “green screen application” came about. In the 1970s, the number of colors supported increased to 16.
5251 Display Station Model 11
The most common terminal options were 5251 Display Station Model 1 (960 characters on the screen) and Model 11 (1920 characters on the screen) with dimensions Width / Depth / Height equal to 530/400/400 mm, respectively, and weighing 34 kg. The screen resolution of the Model 1 was 12x80, the Model 11 was 24x80. The terminal was connected directly to the host system.
Also, 5251 Display Station Model 2 terminals (960 characters on the screen) and Model 12 (1920 characters on the screen) with large dimensions and weighing 45 kg were quite common. They are distinguished from Model 1 and Model 11 by the possibility of “forwarding” upstream connections through themselves to the host machine from cheaper clients in the form of Model 1 terminals (or 11) with desktop printers or a separate outdoor printer. Thus, models 2 and 12 acted as a hub that proxied the connection to the host from devices that require direct connection to the host machine, and cost significantly more.
The 5252 Dual Display Station terminals will also look unusual to the average consumer.
Advertising image from the IBM System / 38 Equipment and Programs brochure (5252 Dual Display Station)
The price of one set of terminal with a printer connected to it could reach several thousand US dollars.
The terminals were connected via a twinax cable to a host machine with a topology of the “bus” type in half-duplex mode with a transmission speed of up to 1 Mbit / s. A maximum of twinaxial supports connection up to 6 terminals, and the maximum distance from the host terminal should be located at a distance of no more than 1500 meters.
The number of each terminal is set when it is installed with three switches, this is how the unique address within the bus is determined. If there is an existing coaxial network, it is possible to use adapters from a twinax cable to a coax cable and an appropriate set of cable ends for crimping. With this scheme it was possible to connect only two devices on the bus with a maximum segment length of up to 30 meters. The total number of connected devices varied from dozen to several dozen, depending on the model.
As Desktop-systems and access networks evolved, bulky terminals were supplanted by workstations, where various third-party expansion cards were used to access the host machine, supporting direct connection via twinaxial. After IBM developed the Token Ring technology in 1984, software solutions for accessing the machine appeared, including through this interface.
5250 adapter to ISA bus (manufacturer unknown)
Blackbox 5250 Adapter Cards (PC470C, PC471C, PC472C, PC473C, PC478C)
Emulators appear under MS-DOS and MS Windows from both IBM and third-party vendors, including the OpenSource implementation (for example, tn5250j.sourceforge.net). In the mid-90s, the TCP / IP stack comes to the world mid -range and low-end business machines. To support access to host machines using the new protocol, IBM is developing software emulators for the 5250 series.
In order to create an exchange protocol with the host system, IBM is developing
Telnet protocol extensions (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), collectively referred to as Telnet5250 (TN5250), which describe the process of receiving and transmitting streams 5250 data (5250 data streams) on top of the standard Telnet protocol.
IBM Client Access / 400 for Windows 3.1 Installer
A feature of the IBM 5250 terminals (and, accordingly, the TN5250 protocol) is block-oriented, in contrast to the usual * nix-terminals, which are character-oriented . This means that the 5250 data streams, in which the host communicates with the terminal, are transmitted by data blocks, and the separate character in it without the context of the transmitted block does not make sense.
For example, the host machine transmits to the terminal a data block in which the displayed static information is located on the screen along with the attributes and coordinates of the input fields and an indication of the offset in this block, where to write the result of user input in the fields. After that, the host machine waits for messages from the terminal and no longer participates in the user input process.
Login screen on IBM i hoster RZKH.de (pub400.com)
The next task of the terminal emulator is to interpret the data block from the machine and form the input screen for the user, where he is given the opportunity to enter any information in the allowed fields. Also, the tasks of the terminal emulator include reaction to user actions. The F1-F24 keys (F13-F24 are simulated via SHIFT + Fx), Enter, Home, End, PageUp, PageDn, and some other special keys that are missing on modern keyboards are considered to be the host keys. This means that by pressing this key, the stream buffer with information from the input fields and the position of the cursor on the screen, previously filled by the terminal emulator, will be sent to the host for processing.
WIreshark 5250 Data Stream dump login attempts on pub400.com
The host receives the buffer, parses it, and the result of the input is transferred to the program that requested the user's reaction for further data validation and application continuation, while the application is passed the code of the pressed host key.
We thought about automating manual testing of green screen applications when we faced the need to test hundreds of screens of a module under development, where up to eighty different business checks (validations) could fall on one screen.
The particular pain that the team faced was the almost complete absence of auto-testing of green screens for 2017, except for the proprietary solution of the UIPath . Even today there are not many such solutions, the author knows Automate from HelpSystems and the JMeter extension for BlazeMeter (I will be glad to receive information on other similar products).
The standard emulator of the TN5250 terminal installed at workplaces in the bank is IBM Personal Communications for Windows 6.0 (PCOMM 6.0). Colleagues found that this product has the standard means of automating its management in the form of a diverse API, namely:
The first three interfaces are the oldest and are supported since DOS and 16-bit versions of Windows. Work on the EHLLAPI interface is implemented through a call to a single function using the following prototype:
where the first parameter is a pointer to the numeric number of the function being performed, the other two are its arguments that are context-sensitive to the function being called, and the last is the result of the function’s operation. That is, to request the connection status 'A' (the sessions in the emulator are numbered with a Latin letter from 'A' to 'Z'), you need to run the following code (taken from the IBM documentation):
The number of functions available in a similar way to call is about 60.
The WinHLLAPI interface slightly extends this functionality with several additional functions that allow registering callback functions for an asynchronous call in order to notify about connection establishment events with the host, disconnecting from the host, changing data on the terminal screen, etc.
The Host Access Client Library (HACL) interface seemed more user-friendly because, unlike the “one name function” call, a version of the object-oriented class hierarchy was provided, allowing you to completely simulate any user action.
Class Hierarchy Emulator Class Library from HACL (C ++)
There are HACL implementations for C ++, Java, LotusScript and COM automation server for Windows (convenient for Visual Basic and .NET).
Due to the enormous complexity of the 5250 data flow protocol and the extremely scanty information about its internal structure with references to IBM's closed paid literature, it became obvious that developing your own emulator is extremely nontrivial and time consuming. In this connection, an idea arose to use the middleware layer, which will allow you to control the terminal emulator within the minimum required functionality, in particular, “enter a value in the field,” “check part of the screen with the standard” or “press the host key F22”.
Colleagues who had previously used HACL interfaces claimed (and confirmed a search on StackOverflow) that the COM object has stability problems and could hang after executing a certain number of commands. Only restarting the automation server process helped. A quick analysis of the Java version showed that Wrapper is being used over the C ++ interface via JNI. Therefore, the choice fell on the C ++ interface. The corresponding header files and .lib files were found in the installation directory of Personal Communications For Windows itself.
The first prototype was based on Qt5, where it was possible to execute JavaScript code through QtScript. In the environment of the executable script, the object was registered with a small number of methods that allowed to execute commands in the terminal emulator as if they were performed by a person (entering a field, pressing the host keys, waiting for a string to appear on the screen). We demonstrated a live "demo" where a custom case was run by launching a green screen application from ABS Equation with checking the application's response to incorrect input in the fields. The demonstration showed that the prototype is successful and you can move on.
Simultaneously with the demonstration of the first prototype, colleagues from another department assembled a bundle of Ruby + Cucumber + Quick3270 + Ruby module ( cheeze / te3270 ). In the proposed version, a Ruby-module is used, which interacts with the DN-Computing Quick3270 terminal emulator through its specialized COM objects (incompatible with HACL interfaces). It was a complete solution for auto-testing BDD-style green screen applications, with a small number of steps previously described. However, in the proposed solution, we were alarmed by the following:
Quick3270 terminal emulator
Based on the prototype, we decided to try to implement our own automation server in order to connect Cucumber with Personal Communications for Windows and develop the steps so that the idle time between actions on the emulator screen was minimal.
Lyrical digression . Despite the fact that there are a huge number of technical tasks around the alleged “legacy” of IBM, which, it would seem, should have already been solved for medium and enterprise-level systems, the relevance of adapting and transferring existing technical solutions is very high simply because their absence on the platform. Often the absence is related to the features of the work of this OS, which is fundamentally different from the current * nix, Windows or MacOS X, which requires a significant optimization of software for a given stack.
As our own solution, we created an automation server as a development of the previously demonstrated prototype. This server executes commands for automation of interaction from consumers through an RPC server (Qt5 WebSocket). It interacts with Personal Communications for Windows, included in the image of the corporate Windows OS, and allows you to:
Starting an automation server
However, with all the advantages of the HACL API, it has one drawback - it does not know how to work with the DB2 for i embedded in the OS and does not allow to execute commands that are vital for building a mock environment where the test script would run. If the DB2 client for Ruby exists from IBM, then the client for the remote command server “Remote command and distributed program call server” is only for Java as a JTOpen library: The IBM Toolbox for Java (also known as jt400 ). We "spied" the solution to this problem at IBM itself by analyzing the behavior of its products with similar functionality (in particular, Personal Communications for Windows Data Transfer, iSeries to PC / PC to iSeries Transfer, etc.). It turned out that these products in their implementation run IBM JRE 6 or 8, depending on the version of the application, and use the jt400 library.
For the automation server, we decided to do the same. The JNI runs the IBM JVM that comes with Personal Communications for Windows. Using special wrapper methods, incoming commands from the outside of the RPC server are executed by proxying them to the calls of the necessary jt400 functionality. Since the latter also contains the JDBC driver for DB2, it was decided to use it to access the DBMS on IBM i.
It is important to note that when using HACL you cannot use Oracle JVM. If you run a terminal emulator session, then an attempt to create a virtual machine instance will lead to a crash. Similarly, if you run an Oracle JVM in the address space of a process that interacts with a HACL, then the latter hangs up without explanation.
Over time, the solution was introduced to an increasing number of jobs. It worked faster with Quick3270. Popularity increased as the number of autotests. However, additional difficulties arose during the operation:
By analyzing the trace logs of numerous autotest launches, searching for bottlenecks in the performance of frequently used steps, the total time for performing regress was reduced to 4-5 hours. But it was clear that using the middleware layer in the form of an RPC automation server in conjunction with the HACL interface, which, among other things, has “floating” errors accumulated with the duration of the entire system, will not help to improve the performance of the solution.
On the other hand, as an alternative to IBM Personal Communications for Windows, the vendor provides a cross-platform solution called IBM i Access - Client Solutions.
IBM i Access - Client Solutions
An analysis of its internal structure on Saturday and Sunday mornings over cups of coffee showed that its code base is based on another IBM product called IBM Host on-Demand (IBM HOD). This is a complete solution for accessing IBM i, developed in Java 6, which not only has a complete implementation of various communication protocols used in IBM machines (TN3270, TN5250, VTxxx, etc.), but also high-level java-swing UI components, used to build your own terminal emulators in the form of a constructor, which can be assembled from the meager IBM documentation . A more detailed study of IBM HOD showed that the UI components are based on the Java implementation of the HACL interface, whose documentation is open. Their behavior coincides with only minor differences from the C ++ HACL documentation.
IBM Host On-Demand (logo)
Next, we created a Java library for internal use, which implements the same interface as the C ++ RPC automation server, but completely uses the IBM HOD internally. To reduce the overhead of executing AutoTest steps, we migrated from Ruby Cucumber to cucumber-jvm with reimplementation of all steps, similar to Ruby variants. With a software interface similar to the RPC server, this was not a big deal, especially since we tried to control the uncontrolled growth of the number of steps and we had this value in the region of 30 units.
As a result, we achieved the performance of all autotests without changing them, and the speed of work became so great that we had to introduce an artificial delay between steps so that when developing an auto test, we could monitor its work, otherwise the UI did not have time to draw the screen to the end.
Already existing 180 autotests with more than 16,000 steps with a set delay of 60 ms between steps began to run about 30 minutes versus 5 hours 30 minutes, which corresponds to an eleven-fold increase in the performance of the regression bench.
The results exceeded all expectations. We came close to the physical limits of the TN5250 protocol.
To date, the decision has been published for the entire bank, and colleagues from other cities have joined in the improvement. Of the latest changes, colleagues are integrating the solution with Jenkins, in the test version, testing of the launch on the Linux server with Xvfb is completed and the pilot operation stage of launching the autotests on it begins.
Thank you for reading to the end!
Successes to all!
PS In December 2018, the regular IBMi Developer Conference was held, at which, among other things, a presentation was made on the topic of this article.
So far, we have annually held a conference only for Bank employees. From 2019, we will invite participants from other companies. It is very interesting to expand the circle of professional and personal communication, to share emotions, knowledge and experience.
In this post I will tell you about what green screen applications are, why they are needed and how we did autotests for them by writing our own solution for this, which allowed us to speed up autotests by 11 times.
')
The AS / 400 platform (Application System / 400) was born in 1988. The first OS for this platform is OS / 400, later renamed to i5 / OS and even later to IBM i. Not so long ago she celebrated her thirtieth birthday.
Plunging into the world of development under the IBM i operating system, you understand that this is actually no “legacy” in the classic sense of the word. This is a different, completely different environment, which has little in common with familiar Windows or Unix systems. The main task of this OS is to be as productive as possible on the hardware with which it works, and not to be user friendly.
IMHO, this OS can make you crazy how familiar approaches to writing C ++ code are ineffective on it (up to a dozen times CPU loss), that some antipatterns shown in textbooks are the best-practice of effective code, and the source code with the date of writing For 1978, they are not just assembled without problems, but also work as designed! All this makes a new look at modern approaches to software development.
Introduction
The issue of improving the quality of the developed software is worrying the minds of each development team. Not bypassed this moment and one of our credit teams, whose task is to develop and develop the Back part of the module for the automated banking system Misys Equation. The peculiarity of this ABS is that:
- the first versions of the ABS worked under the predecessor of AS / 400 - the IBM System / 38 platform (appeared in 1978) under the CPF OS - “Control Program Facility”;
- it has been developed since the 70s of the twentieth century, and you can come across code written before you were born (a lot of old code);
- features of working with ABS are due to the close integration with IBM i, and due to the enormous backward compatibility of the latter, it seems that you are working as an archaeologist at the excavations of the Great Pyramid.
IBM i (logo)
We develop applications for this ABS (ABS options) in accordance with the Misys ITP developer standard - Integrator's Technical Package, which stipulates that the option should consist of an interactive program for terminal interaction with the end user and implement the API using the set interface for background execution .
Such interactive programs developed under the IBM i operating system are historically called green-screen applications and are the only UI with which the user of this ABS interacts.
What is a green screen app?
The simple answer is an application that looks like this:
Or so :
Why do we need green screen apps?
Historically, the only interactive applications running on the low and mid-range systems of the AS / 400 family and other IBM meinframes that allowed you to request any user input are green screen applications. Installation, administration, configuration, and development on the IBM i operating system (and its predecessors, i5 / OS and AS400) were conducted (and are still under way somewhere) exclusively using green screen applications.
The green screen application has two sizes - 24x80 and 27x132 characters and 16 possible colors. Within these scales, most of the work of the developers and users of this operating system is performed.
These screen sizes are the result of the evolution of “workstations” that connected to the mothers of the AS400 from the low-end and mid-range segment of the IBM System / 32, System / 34, System / 36 and System / 38 computers. These workstations were called terminals and were a screen in a metal case with a keyboard and additional equipment in the form of a light pen. Initially, only two colors of the screen were supported - it is green and bright green, which is why the well-established phrase “green screen application” came about. In the 1970s, the number of colors supported increased to 16.
5251 Display Station Model 11
The most common terminal options were 5251 Display Station Model 1 (960 characters on the screen) and Model 11 (1920 characters on the screen) with dimensions Width / Depth / Height equal to 530/400/400 mm, respectively, and weighing 34 kg. The screen resolution of the Model 1 was 12x80, the Model 11 was 24x80. The terminal was connected directly to the host system.
Also, 5251 Display Station Model 2 terminals (960 characters on the screen) and Model 12 (1920 characters on the screen) with large dimensions and weighing 45 kg were quite common. They are distinguished from Model 1 and Model 11 by the possibility of “forwarding” upstream connections through themselves to the host machine from cheaper clients in the form of Model 1 terminals (or 11) with desktop printers or a separate outdoor printer. Thus, models 2 and 12 acted as a hub that proxied the connection to the host from devices that require direct connection to the host machine, and cost significantly more.
The 5252 Dual Display Station terminals will also look unusual to the average consumer.
Advertising image from the IBM System / 38 Equipment and Programs brochure (5252 Dual Display Station)
The price of one set of terminal with a printer connected to it could reach several thousand US dollars.
The terminals were connected via a twinax cable to a host machine with a topology of the “bus” type in half-duplex mode with a transmission speed of up to 1 Mbit / s. A maximum of twinaxial supports connection up to 6 terminals, and the maximum distance from the host terminal should be located at a distance of no more than 1500 meters.
The number of each terminal is set when it is installed with three switches, this is how the unique address within the bus is determined. If there is an existing coaxial network, it is possible to use adapters from a twinax cable to a coax cable and an appropriate set of cable ends for crimping. With this scheme it was possible to connect only two devices on the bus with a maximum segment length of up to 30 meters. The total number of connected devices varied from dozen to several dozen, depending on the model.
As Desktop-systems and access networks evolved, bulky terminals were supplanted by workstations, where various third-party expansion cards were used to access the host machine, supporting direct connection via twinaxial. After IBM developed the Token Ring technology in 1984, software solutions for accessing the machine appeared, including through this interface.
5250 adapter to ISA bus (manufacturer unknown)
Blackbox 5250 Adapter Cards (PC470C, PC471C, PC472C, PC473C, PC478C)
Emulators appear under MS-DOS and MS Windows from both IBM and third-party vendors, including the OpenSource implementation (for example, tn5250j.sourceforge.net). In the mid-90s, the TCP / IP stack comes to the world mid -range and low-end business machines. To support access to host machines using the new protocol, IBM is developing software emulators for the 5250 series.
In order to create an exchange protocol with the host system, IBM is developing
Telnet protocol extensions (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), collectively referred to as Telnet5250 (TN5250), which describe the process of receiving and transmitting streams 5250 data (5250 data streams) on top of the standard Telnet protocol.
IBM Client Access / 400 for Windows 3.1 Installer
What is special about the IBM 5250?
A feature of the IBM 5250 terminals (and, accordingly, the TN5250 protocol) is block-oriented, in contrast to the usual * nix-terminals, which are character-oriented . This means that the 5250 data streams, in which the host communicates with the terminal, are transmitted by data blocks, and the separate character in it without the context of the transmitted block does not make sense.
For example, the host machine transmits to the terminal a data block in which the displayed static information is located on the screen along with the attributes and coordinates of the input fields and an indication of the offset in this block, where to write the result of user input in the fields. After that, the host machine waits for messages from the terminal and no longer participates in the user input process.
Login screen on IBM i hoster RZKH.de (pub400.com)
The next task of the terminal emulator is to interpret the data block from the machine and form the input screen for the user, where he is given the opportunity to enter any information in the allowed fields. Also, the tasks of the terminal emulator include reaction to user actions. The F1-F24 keys (F13-F24 are simulated via SHIFT + Fx), Enter, Home, End, PageUp, PageDn, and some other special keys that are missing on modern keyboards are considered to be the host keys. This means that by pressing this key, the stream buffer with information from the input fields and the position of the cursor on the screen, previously filled by the terminal emulator, will be sent to the host for processing.
WIreshark 5250 Data Stream dump login attempts on pub400.com
The host receives the buffer, parses it, and the result of the input is transferred to the program that requested the user's reaction for further data validation and application continuation, while the application is passed the code of the pressed host key.
Why is there autotest
We thought about automating manual testing of green screen applications when we faced the need to test hundreds of screens of a module under development, where up to eighty different business checks (validations) could fall on one screen.
The particular pain that the team faced was the almost complete absence of auto-testing of green screens for 2017, except for the proprietary solution of the UIPath . Even today there are not many such solutions, the author knows Automate from HelpSystems and the JMeter extension for BlazeMeter (I will be glad to receive information on other similar products).
First research on the problem
The standard emulator of the TN5250 terminal installed at workplaces in the bank is IBM Personal Communications for Windows 6.0 (PCOMM 6.0). Colleagues found that this product has the standard means of automating its management in the form of a diverse API, namely:
- High-level Language Application Program Interface (HLLAPI);
- Enhanced HLLAPI;
- Windows HLLAPI;
- Host Access Client Library (HACL).
The first three interfaces are the oldest and are supported since DOS and 16-bit versions of Windows. Work on the EHLLAPI interface is implemented through a call to a single function using the following prototype:
long hllapi (LPWORD, LPSTR, LPWORD, LPWORD); where the first parameter is a pointer to the numeric number of the function being performed, the other two are its arguments that are context-sensitive to the function being called, and the last is the result of the function’s operation. That is, to request the connection status 'A' (the sessions in the emulator are numbered with a Latin letter from 'A' to 'Z'), you need to run the following code (taken from the IBM documentation):
#include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling }
The number of functions available in a similar way to call is about 60.
The WinHLLAPI interface slightly extends this functionality with several additional functions that allow registering callback functions for an asynchronous call in order to notify about connection establishment events with the host, disconnecting from the host, changing data on the terminal screen, etc.
The Host Access Client Library (HACL) interface seemed more user-friendly because, unlike the “one name function” call, a version of the object-oriented class hierarchy was provided, allowing you to completely simulate any user action.
Class Hierarchy Emulator Class Library from HACL (C ++)
There are HACL implementations for C ++, Java, LotusScript and COM automation server for Windows (convenient for Visual Basic and .NET).
First prototype
Due to the enormous complexity of the 5250 data flow protocol and the extremely scanty information about its internal structure with references to IBM's closed paid literature, it became obvious that developing your own emulator is extremely nontrivial and time consuming. In this connection, an idea arose to use the middleware layer, which will allow you to control the terminal emulator within the minimum required functionality, in particular, “enter a value in the field,” “check part of the screen with the standard” or “press the host key F22”.
Colleagues who had previously used HACL interfaces claimed (and confirmed a search on StackOverflow) that the COM object has stability problems and could hang after executing a certain number of commands. Only restarting the automation server process helped. A quick analysis of the Java version showed that Wrapper is being used over the C ++ interface via JNI. Therefore, the choice fell on the C ++ interface. The corresponding header files and .lib files were found in the installation directory of Personal Communications For Windows itself.
The first prototype was based on Qt5, where it was possible to execute JavaScript code through QtScript. In the environment of the executable script, the object was registered with a small number of methods that allowed to execute commands in the terminal emulator as if they were performed by a person (entering a field, pressing the host keys, waiting for a string to appear on the screen). We demonstrated a live "demo" where a custom case was run by launching a green screen application from ABS Equation with checking the application's response to incorrect input in the fields. The demonstration showed that the prototype is successful and you can move on.
Appearance of a neighbor
Simultaneously with the demonstration of the first prototype, colleagues from another department assembled a bundle of Ruby + Cucumber + Quick3270 + Ruby module ( cheeze / te3270 ). In the proposed version, a Ruby-module is used, which interacts with the DN-Computing Quick3270 terminal emulator through its specialized COM objects (incompatible with HACL interfaces). It was a complete solution for auto-testing BDD-style green screen applications, with a small number of steps previously described. However, in the proposed solution, we were alarmed by the following:
- We used a third-party paid emulator not from IBM (all emulators work a little differently, but we need to check the work on the ones used in the bank, the cost of the error is incredibly high);
- Implementing Cucumber steps for Quick3270 used a lot of sleep to wait for a response from the machine;
- The very poor performance of Quick3270 through the automation interface (working with HACL in the prototype through C ++ interface looked much more dynamic).
Quick3270 terminal emulator
Based on the prototype, we decided to try to implement our own automation server in order to connect Cucumber with Personal Communications for Windows and develop the steps so that the idle time between actions on the emulator screen was minimal.
Lyrical digression . Despite the fact that there are a huge number of technical tasks around the alleged “legacy” of IBM, which, it would seem, should have already been solved for medium and enterprise-level systems, the relevance of adapting and transferring existing technical solutions is very high simply because their absence on the platform. Often the absence is related to the features of the work of this OS, which is fundamentally different from the current * nix, Windows or MacOS X, which requires a significant optimization of software for a given stack.
Own decision
As our own solution, we created an automation server as a development of the previously demonstrated prototype. This server executes commands for automation of interaction from consumers through an RPC server (Qt5 WebSocket). It interacts with Personal Communications for Windows, included in the image of the corporate Windows OS, and allows you to:
- start / stop the terminal emulator session;
- perform screen scraping green screen;
- search input fields on the screen;
- control the cursor and simulate keystrokes (including host);
- and etc.
Starting an automation server
However, with all the advantages of the HACL API, it has one drawback - it does not know how to work with the DB2 for i embedded in the OS and does not allow to execute commands that are vital for building a mock environment where the test script would run. If the DB2 client for Ruby exists from IBM, then the client for the remote command server “Remote command and distributed program call server” is only for Java as a JTOpen library: The IBM Toolbox for Java (also known as jt400 ). We "spied" the solution to this problem at IBM itself by analyzing the behavior of its products with similar functionality (in particular, Personal Communications for Windows Data Transfer, iSeries to PC / PC to iSeries Transfer, etc.). It turned out that these products in their implementation run IBM JRE 6 or 8, depending on the version of the application, and use the jt400 library.
For the automation server, we decided to do the same. The JNI runs the IBM JVM that comes with Personal Communications for Windows. Using special wrapper methods, incoming commands from the outside of the RPC server are executed by proxying them to the calls of the necessary jt400 functionality. Since the latter also contains the JDBC driver for DB2, it was decided to use it to access the DBMS on IBM i.
It is important to note that when using HACL you cannot use Oracle JVM. If you run a terminal emulator session, then an attempt to create a virtual machine instance will lead to a crash. Similarly, if you run an Oracle JVM in the address space of a process that interacts with a HACL, then the latter hangs up without explanation.
Over time, the solution was introduced to an increasing number of jobs. It worked faster with Quick3270. Popularity increased as the number of autotests. However, additional difficulties arose during the operation:
- Episodic terminal hangs;
- The inability to work on the regression bench due to the fact that the terminal emulator refused to start if the desktop of the user under which the emulator is running is blocked or its RDP session is inactive;
- Windows-only;
- Complicated installation, configuration and updating tools (via msi-package);
- Our regression cycle for 130 autotests (about 4,000 steps) began to take 7-8 hours.
Need to do something ...
By analyzing the trace logs of numerous autotest launches, searching for bottlenecks in the performance of frequently used steps, the total time for performing regress was reduced to 4-5 hours. But it was clear that using the middleware layer in the form of an RPC automation server in conjunction with the HACL interface, which, among other things, has “floating” errors accumulated with the duration of the entire system, will not help to improve the performance of the solution.
On the other hand, as an alternative to IBM Personal Communications for Windows, the vendor provides a cross-platform solution called IBM i Access - Client Solutions.
IBM i Access - Client Solutions
An analysis of its internal structure on Saturday and Sunday mornings over cups of coffee showed that its code base is based on another IBM product called IBM Host on-Demand (IBM HOD). This is a complete solution for accessing IBM i, developed in Java 6, which not only has a complete implementation of various communication protocols used in IBM machines (TN3270, TN5250, VTxxx, etc.), but also high-level java-swing UI components, used to build your own terminal emulators in the form of a constructor, which can be assembled from the meager IBM documentation . A more detailed study of IBM HOD showed that the UI components are based on the Java implementation of the HACL interface, whose documentation is open. Their behavior coincides with only minor differences from the C ++ HACL documentation.
IBM Host On-Demand (logo)
Next, we created a Java library for internal use, which implements the same interface as the C ++ RPC automation server, but completely uses the IBM HOD internally. To reduce the overhead of executing AutoTest steps, we migrated from Ruby Cucumber to cucumber-jvm with reimplementation of all steps, similar to Ruby variants. With a software interface similar to the RPC server, this was not a big deal, especially since we tried to control the uncontrolled growth of the number of steps and we had this value in the region of 30 units.
What is the result
As a result, we achieved the performance of all autotests without changing them, and the speed of work became so great that we had to introduce an artificial delay between steps so that when developing an auto test, we could monitor its work, otherwise the UI did not have time to draw the screen to the end.
Already existing 180 autotests with more than 16,000 steps with a set delay of 60 ms between steps began to run about 30 minutes versus 5 hours 30 minutes, which corresponds to an eleven-fold increase in the performance of the regression bench.
The results exceeded all expectations. We came close to the physical limits of the TN5250 protocol.
To date, the decision has been published for the entire bank, and colleagues from other cities have joined in the improvement. Of the latest changes, colleagues are integrating the solution with Jenkins, in the test version, testing of the launch on the Linux server with Xvfb is completed and the pilot operation stage of launching the autotests on it begins.
Thank you for reading to the end!
Successes to all!
PS In December 2018, the regular IBMi Developer Conference was held, at which, among other things, a presentation was made on the topic of this article.
So far, we have annually held a conference only for Bank employees. From 2019, we will invite participants from other companies. It is very interesting to expand the circle of professional and personal communication, to share emotions, knowledge and experience.
Source: https://habr.com/ru/post/446332/
All Articles