Through IRMA to IMS

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 61

Introduction¶

This talk shows how the PC with an IRMA board can be programmed to act as an intelligent interface between separate applications running on a mainframe. We have succeeded in using a PC under function control to move between different parts of an ordinary IMS application; we were able to recognise sequences of various transaction screens and then read or update named fields in these screens. Instead of using terminal emulation programs (e.g. E78 or I78TERM) or file transfer programs we used APL to read and write to the IRMA buffer directly. To do this in a systematic and structured way we developed a data structure, a design tool and a high level syntax which we used with a function-alias file.

Our client was the Technical Director in a business with several mainframes. One of these was a large IBM 3090 designated the Production Machine to run the main commercial systems, while a smaller IBM 3081 was allocated as the End User machine, running SQL/DS, AS, APL2, PROFS etc.

What the director needed was an update to his resource requirements database using the projections about milestone events calculated in his Pert networked project planning database. But what his problem turned out to be was that the company’s resource requirement and planning system (MRRP) ran on the Production Machine under an IMS database, while the Pert planning system (IPLS) ran on the End User machine in a VM environment. There were no interfaces between them! Because Management Services had estimated that it would take 2 man years to build an interface between the IMS based MRRP system and IPLS on VM he thought it worthwhile to invite our suggestions.

Because the IPLS system had a module for moving data between the VM mainframe and PC using APL programs he said “Surely we can get the data we want out of MRRP, tweak it and then put it back. Aren’t we doing this already using PCs and IPLS every day ?”. Within a week this conversation was to lead to a spectacular row between Directors about which was the more important, production systems or End User computing!! More importantly, at least for us, it was the point of departure for work which led to the Programmable Irma Interface described below.

Outline Description¶

Data in MRRP about resource requirement plans was held in the IMS machine, and data in IPLS which was to be used to modify the resource plans was on the VM machine. Data in both systems was organised in corresponding work packets. The objective was to adjust the IMS data to reflect the current position as indicated by VM data.

Solution¶

The ‘intelligent terminal’ method was selected. A PC fitted with IRMA using the minimum of operator interaction and running under PC program control would do the following:

Step 1

download data from IMS into file A on the PC.

Step 2

download data from the VM machine into file B on the PC.

Step 3

use an APL*PLUS/PC workspace to combine the data in the two files and create file C with the adjusted resource requirements.

Step 4

upload the data from file C from the PC back into IMS.

The users would be management assistants with no special computer skills and they would need to be able to update individual work packets as selected. To protect the production system from unauthorised access the user would have to logon and logoff manually in the normal way; i.e. the PC programs would have to pass control to the user at logon/logoff.

We could modify an IPLS module to get the data we wanted, but we had to use the existing MRRP/IMS system exactly as it stood, i.e. we had to access the data required from the application’s existing transaction screens because no changes were allowed to MRRP!

Thus our technical requirement was to write APL programs so that the PC appeared to the IMS machine exactly as if it were a normal user doing the usual MRRP transactions. Simulating a normal user meant being able to recognise responses from the mainframe system. These responses are either expected or unexpected. Unexpected responses include messages from the operator (e.g. ‘closedown in 10 mins’), or from the IMS system (e.g. ‘record cannot be found’, or ‘input not a proper date’). If an unexpected response was received the programs had to pass control back to the user.

The system would have to be flexible enough to detect unexpected changes to the transactions screens caused by IMS maintenance programmers. It would also have to be very highly structured if we were to have any chance of tracing and debugging the programs. From our previous experience of building PC-mainframe links we knew that our greatest difficulty would be in actually getting things exactly right because, as with all inter-computer communications, even the slightest fault can bring everything to a grinding halt.

Communicating with VM and IMS¶

Access to the VM/IPLS data was done by incorporating an auxiliary processor for controlling data flow between APL workspaces on the PC and in APL2 on the mainframe. This auxiliary processor was written by adapting some of the IRMA APL*PLUS/PC Tools; The AP comprises about 15 APL programs on both mainframe and PC.

All communication with IMS was to be controlled entirely by programs on the PC. These programs comprised a Data Structure, a Design Tool, a high level syntax and a Function-Alias file.

The idea behind the function-alias file was the need for a self-documenting system. What we wanted was a scheme for invoking APL functions by comment or description rather than by function name. The function-alias file we developed also provided the mechanism for structuring the programs. The function-alias file worked alongside a high level syntax which consisted of about ten functions, e.g. OPENSCREEN, OPENVIEW, CLOSESCREEN etc.

Using the function-alias file and these functions, our APL driver for moving from the ‘MAIN MENU’ screen to details of the resource details looked like:

    ∇ DRIVER1
[1]  OPENSCREEN'MRRP100'
[2]  OPENVIEW'MAINMENU'
[3]  WAIT
[4]  CHECKERROR
[5]  CHECKMESSAGE
[6]  EXECUTE'Select Enquiry Mode'
[7]  PRESSSENTER
[8]  OPENSCREEN'MRRP200'
[9]  OPENVIEW'SELECTION'
[10] WAIT R ⋄ R←CHECKERROR R ⋄ R←CHECKMESSAGE
[11] EXECUTE'Select individual packages, not summary level'
[12] PRESSSENTER
    ∇

The functions OPENSCREEN & OPENVIEW refer to the function-alias file and collectively define a table of the names of APL functions (the ones with all the messy details) and a table of text, or aliases. In the above example ‘MRRP100’ refers to an IMS screen which had MRRP100 in its top left, i.e. it’s the name of the screen. ‘MAINMENU’ and ‘SELECTION’ are names we assigned to ‘views’ we had defined on the screens. Line 6 EXECUTE'Select Enquiry Mode' is an example of invoking an APL function by its description. (What this particular APL function did to get the character ‘E’ typed into the proper field on the screen).

To be able to read from or write to the IRMA buffer and the real fields on the 3278 we needed a method of allocating sets of fields to APL variables. To help us we made extensive use of the POWERTOOLS/PC processor, not only because it is well equipped to define and manipulate fields and matrices within larger matrices, but also because its other facilities for controlling user input at the field level made it invaluable for designing the data structures.

The term I3278 was coined to describe the Data Structure and an I3278 structure was defined for each screen (our application needed 10 such structures). Each I3278 is composed of several sections: a name to associate it with an application screen, the definition and location of special fields such as ‘signature’ and ‘message’ fields. These tell us where to look on the screen either for operator messages or to check that the screen is the one we expect to see. It also has definitions of ‘view’ substructures and the name of the function-alias file it uses.

The idea of a ‘view’ came from the fact that several of the screens in our application had more than one use; the use depending on the context. In our application we needed both the timespan and the details of the work package. The only way to measure the timespan was to set the scale to years and afterwards set it to months to get the details. Views are themselves defined as substructures consisting of a name, a table of field names which may be referred to within APL functions to get (or put) actual data and a format matrix specifying how ‘real’ fields on the 3278 screen are associated with each named field.

Conclusion¶

The idea of an intelligent interface between mainframe applications using PCs was successful and our choice of the technical design and system structures was instrumental in being able to complete a working implementation within timescales that were less than a quarter of those estimated by Computing Services. We think that the large differences in timescales continues to be a source of frustration to End User Directorates, and a source of threat to Computer Services. Our client, as far we know, has ended his battle with the other Directors with honours even; it was realised that the benefits of other necessary enhancements to the systems would justify the cost of a complete redesign of MRRP.

We are surprised at how reluctant management seems to be to grasp the genuine opportunities offered by coupling PCs to mainframes; opportunities for new types of applications, as well as for reducing operating costs by devolving significant amounts of processing to local high powered (i.e. 80386 based) PCs.