Data communication.

Research and development in data communication is permanently needed while it's always a moving target. Our activities in this area have resulted in some products like the TP monitor MTPM, the connection of remote printers MOAP and a Data Distribution System.

Remote printers and MOAP.

In many cases remote printers were connected to hosts by a connection which supported 7 bits per byte. It was common practice that data was transported over such networks in ASCII code, not only the data to be printed but also the printer commands. The resulting problem were the codes not present in ASCII. Customers didn't always understand the lack of solutions.

To print data on local and remote printers in the world of the mainframe computers spool systems were used, which sent the printer commands and the text to be printed to the associated printserver . Sources for those spool systems weren't available, so no solution in that direction was possible. Thus we decided to develop a preprocessor and a postprocessor. The preprocessor runs on a Siemens BS2000 mainframe. It scans the data to be printed and "translated" the non-transportable characters. Those "translated" characters were reverted by the postprocessor on the printserver.

In order to make these scan and translate processes efficient these were developped in the Assembler languages of the server (preprocessor) and the client (postprocessor). This application is working since 1990 under the name of MOAP in environments with many remote printers.

Transaction monitors.

Transaction Processing Monitors are programs to create communication between Transaction Processing Routines (TPR's) and remote systems like terminals and other computers. In case sources are available this software is even handy to develop quickly communication systems. However, sources weren't available, we knew only of commercial TP monitors.

So we decided to research this area also. The first "quick and dirty" version was named TPBASE. It was indeed a base for further study, a COBOL source of about 17,000 lines. Also important was the support of TPR's generated by DP2.

The next step was the study of subsystems like Inter Task Communication (ITC), Memory Pools (MP) and Eventing, related to security, stability, reliability and performance. We opted for ITC in combination with MP. Later we learned that also others had preference for this combination.

The creation of a nearly complete library with standard functions for this area proved that the building process of transaction monitors had been made easy. A main program of about 200 lines of Assembler code (without comment lines) with some additional specific functions for the application did the job. In this way the base product MTPM came into being and also some derived products like a Data Distribution System and an Accounting System for data centers.

Transaction Processing Monitors consist of a run-time component, which when linked with the TPR's offer the complete functionality. The program created by this link process has to be started in a given user environment of the operating system. In case TPR's are needed in more than one user environment those TPR's must be linked with the run-time component and the created program must be started in another user environment.

To lower the overhead of multiple loaded run-time components and for the ease of use of the end users MTPM works differently. MTPM consists of two components :

• the central communication component, which processes all local components and all data coomunication,
• the local component, which is loaded with the needed TPR's in the user environment.

The more features, the more problems. Not so many features in MTPM thus. We have implemented a dump facility for problem analysis. And also a REP system to correct (if need be) errors in the object code in a running system. Which results in less down time.