Bridging Two Worlds: Mainframes and Clients

In Application Architecture: an Evolutionary View I wrote of the way that computers have evolved from the mainframe era of the 1970’s to today’s interconnected world, where mainframes and other servers communicate with PC’s and mobile devices to provide services that weren’t even imagined in the 1970’s. Mainframes are perceived as a relic of last century, programmed in languages like COBOL that nobody wants to learn any more, yet they remain the mainstay of banks, insurance companies, and government departments. Not only is it difficult to migrate software built for the mainframe platform, the mainframe’s massive I/O capability and the very high OLTP capacity are difficult to match. Migration projects can be risky and disappointing, and for companies like banks and insurance companies with large OLTP loads mainframes remain the most cost-effective platform.

Client devices, designed to serve one user, not thousands, excel at tasks where a user interacts with data through a rich interface, like spreadsheets, word processing, CAD, and applications like email and web browsing where a rich interface is combined with communication. To make all this happen requires a lot of client programming. Developers will use tools and languages like Java, C#, VB.NET, Python, … that have been developed outside of the mainframe environment and can be used on their PC. Traditional data processing will be managed by database interfaces, sometimes SQL, often with a proprietary layer like LINQ. One thing that you can be sure of: client developers will NOT be using COBOL, PL/I, or Fortran, the traditional languages of mainframes.

Now consider on line shopping. From your PC you search the web for something you want. You find it, and with a click you’ve bought it. Money is transferred from your bank account to the vendor’s, and the goods are scheduled for pick-up and delivery. Almost certainly this will have involved mainframe systems, as well as the client systems that displayed the web pages, so we’ll need to develop systems that combine mainframe and client technology. We have to develop solutions across two worlds that use different languages and concepts. There are many issues.

The mainframe world

In the mainframe world we’ll need to develop web services that will manage the data for the payment, checking that you have the money in your account to pay for your purchase, and moving this from your account to the vendor’s. None of the issues that were relevant in the days of classical CICS have gone away. It is still necessary to ensure that both records are effectively locked over the whole update process, yet without bringing the systems to a halt because of lock contention. CICS pseudo-locking was a good solution to this, but web services are strictly atomic and so you can’t simply save a copy in COMMAREA. An equivalent pseudo-locking approach uses a checksum hash total, passed to and from the service in its messages. As I wrote previously, you’ll need to write web services in COBOL or PL/I for this.

But where do you find developers who understand these languages? You’re faced with training a new generation of COBOL programmers. Who wants to work with a language that you can’t run on your PC, using an IDE like Visual Studio? Well, you don’t have to: Micro Focus Enterprise Developer can partner with either Visual Studio or Eclipse to provide a modern development environment supporting COBOL, allowing the same step-thru debugging as with VB, C#, and Java.

Even so, writing web service update programs is not easy. Fortunately, there are a small number of code generation solutions available in the mainframe ecosystem that can actually write COBOL for you (MANASYS Jazz is one of them). With a few clicks it will generate a high-quality COBOL web service program using checksum pseudo-locking to update a single record or a collection of records.

Of course, it isn’t just COBOL. A web service has to communicate via JSON so that the client world of Java, C#, VB etc can understand the data sent from the mainframe. With the right code generation solution configured to use z/OS directly, the JCL submitted to compile your web service program will include steps to automatically develop the binding file and JSON message descriptions from the COBOL program and its message descriptions. With Micro Focus a few dialog clicks achieves the same result.

These solutions provide easy solutions to mainframe issues – shortage of COBOL programmers, nobody wants to learn COBOL, COBOL is slow to write and difficult to use.

The client world

They continued to develop enough that, in only a few minutes, a simple COBOL web service with its supporting objects (WSDL and binding file) could be generated, compiled, and the service proven to work with a test utility (SOAPUI). But it took me well over a week per web service to write the ASP.NET programs used in this video to demonstrate them on our web site. Solutions continued to develop, and by the time of last year’s article the service generated in those few minutes might provide single-record or record-group updating of VSAM or DB2 data, and communicate with JSON instead of WSDL. But writing the client programs remained very difficult, especially as the complexity of the interaction increased with rules like “Update must follow enquiry, and must return the enquiry’s checksum value”.

Client developers use different languages (C#, Java, … ) not just because of their different availability and the developer’s experience, but also because object oriented languages are better suited to the client world. The language differences reflect different concepts: Objects and Properties are a bit like the Records and Fields that COBOL and other mainframe programmers think of, but they’re also a lot different. For example, Objects and Properties can’t be redefined as Records and Fields can be in COBOL. A client-side array is more like a list than the fixed-size repeating area of memory that a COBOL programmer understands an array to be. All this creates issues when a client programmer has to communicate with mainframe developers or to deal with mainframe-originated web service data.

From the data definition and generation dialog, software can generate a web service. It therefore has all the information it needs to generate a client-side interface to communicate with this service, encapsulating the rules of the service and its data, and simply presenting properties and methods to the client program. Our next challenge was obvious.

Client Service Interfaces

Since November we have been able to demonstrate proof-of-concept implementation of interface generation. Having generated a web service like program JSPG2, updating Employee records from IBM’s Sample DB2 database, two more clicks generate interface JSPG2Client: –

With the service rules encapsulated in the interface, client development is very easy: simply assign data to an interface and it is immediately validated. The client doesn’t need to know the message formats and transaction rules, it need only invoke an appropriate interface method with appropriate parameter values. All the information the client program needs is discoverable with Intellisense.

The client interfaces are generated in C#. Why C#? By targeting .Net Core and using C# the interface can be compiled for Windows, Unix, Linux, Android, and IOS. The actual client programs might be written in a wide variety of languages, including VB and Java as well as C#.

Where Next?

This development already shows exciting results. In this video example 18 lines of DB2 table definition produced 77 lines of Jazz program and message definition, which became 2500 lines of COBOL, 320 lines of JSON, 854 lines of C#, all of which compiled and worked correctly first time. This is a huge productivity gain compared to any other way of developing web services and related clients. No other software generates mainframe web services and integrated client-side interface code based on the data’s definition.

Now, with the ability to quickly and easily generate related client interfaces from a shared data model it becomes possible to implement a web service/client interface and demonstrate the service and client working together in a few days. Then a few days later demonstrate version 2. As the web service evolves, the interface is automatically regenerated with a few clicks, and the actual client doesn’t even need to be changed unless to take advantage of new data. Agile development realizes its potential as weekly sprints become possible. Compare this with the situation of most mainframe users, where business analysts and system architects have to prepare specifications for separate mainframe and client programming teams using different and incompatible programming technology, and changing an interface is a significant development, not just a few minute’s work.

The potential is huge, and we’re keen to roll out a stream of future enhancements as we implement the ideas that we already have, but we’re especially looking forward to working with real users who will suggest even more ideas and help us to prioritize them. And we’d welcome approaches from companies already active in the mainframe market willing to market our software so that we can focus on making the product even better.