Skip to main content

Mainframe Connectivity: What’s Missing?

GateWAY z/OS allows multi-factor authentication of users, offers mainframe website hosting and client-side scripting and comes with development services. Learn more from Trevor Eddolls.

Red and gold systems and gears against a dark green background

We can, perhaps, all remember a time when a simple 3270 terminal emulator was all we needed to access the mainframe without needing a directly-connected terminal. And we were really pleased that we could work from anywhere using this simple solution to our communication problem. It worked and our expectations were not very high.

Next, we decided that we wanted our mainframe applications to take part in the API economy. We wanted to be able to use parts (microservices) of our applications with other microservices that could be anywhere—mobile, cloud, etc. And IBM gave us z/OS Connect, with the idea of having a consistent way for mobile devices to access mainframes using RESTful APIs and JSON. And, depending on what you had and what you wanted to do, you might also need WAS and a Liberty profile. But it worked and we were all pleased. Our mission-critical mainframe apps were no longer part of a mainframe silo, they were now part of the bigger world of computing.

Accessing the Mainframe With a Browser

Meanwhile, the rest of the world was using simple web interfaces using a browser (which just about every digital device has) to access everything. I could sit at my laptop, phone or tablet and shop, watch videos, post on social media, and just about everything else except access my mainframe. Wouldn’t it be great to be able to get to your mainframe easily from a web browser anywhere? Isn’t that the part of mainframe connectivity that’s missing? I know there are some solutions to do this for CICS, and there are browsers at the user end of 3270 emulators, but wouldn’t it be brilliant to get to any part of the mainframe using a browser?

​Let’s imagine that there was some software that simply allowed z/OS applications to interoperate with apps that live on Linux, Windows and in the cloud in real time and allowed users to interact with a mainframe in the same manner as those other platforms. There would be standard interfaces such as XML, HTTPS and REST APIs—which plenty of people are familiar with and could use easily.

And let’s, in this scenario, assume that everything actually runs on the mainframe (apart from the browser on your local device), so there’s no need to login to Linux of Windows server first before accessing the mainframe. There’s also no need for any new hardware, or support or repackaging. You’d simply install a piece of software on the mainframe and everyone who is authorized can access CICS or IMS or whatever they want from a browser.

The software wouldn’t affect anything else—3270 emulation would still work as it did before. People using this new software from their browser would still have to go through RACF or other security software to ensure when they logged in, they really were who they said they were and they could only do what they were allowed to do. This new software would connect easily with Linux, Windows, and UNIX—and it would connect with tools in the cloud.

Adding a Web Interface to a Mainframe Application

Let’s have a look at another advantage of using this new web-based software compared with our current situation where we don’t have this new software installed. If you’ve ever been through the process of trying to add a web interface to a mainframe application, you know that you can end up going through the following steps:
  1. Adding a Windows or Linux machine to handle communications, which means that you’ll need to involve people with server and web development experience as well as your mainframe experts
  2. Agreeing with these other experts on a design that’s secure. Unfortunately, it may require that REXX is replaced and your ISPF tables have to go. They’re just too mainframey! And, that means you’ll have to rewrite parts of your mainframe application.
  3. Setting up the server and testing. Once the server is set up, the web developer needs to ensure that everything works at their end. Then everything needs to be tested. And, hopefully, that will show that the concept works.
  4. Rolling out the new web version of the application and packaging up support for the new users
It’s all going to take a very long time and require people with specialist skills to make it work. 

Or a much faster way would be to use a mainframe browser that would allow you to use REST APIs to talk to cloud-based services in real time—for example ServiceNOW, Remedy, Splunk, QRadar, etc. And wouldn’t it be great if such a product also came with built-in services that just worked? It would mean that no retraining would be necessary, no rewriting of mainframe applications would be required, no extra people with non-mainframe-based skills would be needed to help. And, everything could be installed and set up in a day!

Not a Hypothetical: A z/OS-Native Web Server

I was very interested when I stumbled across just such a product, and I wanted to share the news about it. The product really is a z/OS-native web server, it needs no intermediate servers, it allows multi-factor authentication of users, it offers mainframe website hosting and client-side scripting, eg, Java, JSON, XML, HTML support and it comes with development services.

I’m certainly not saying that you should rush out and buy this product. What I am saying is that it’s interesting that something that many people have felt is missing from mainframe communications is now available. And the company supplying it offers all sorts of support to get sites using it up and running very quickly. If you want to find out more, the company is MainTegrity, the product is called GateWAY z/OS, and the website is here.
Webinars

Stay on top of all things tech!
View upcoming & on-demand webinars →