Evangelizing Mainframe
Print Email

Fat Clients Ride Again

Let’s suppose that your organization writes software for the mainframe. Let’s say it monitors something. And let’s suppose that you’ve been happily writing 3270 green-screen interfaces to it for years. Then, one day, you find that your users would like to access their monitor information from a browser–perhaps on their laptops, or even on tablets or smartphones. What do you do?

 

Well, I would guess, as a mainframe software developer, you write a GUI interface and plug it into your mainframe software. It might make your software a bit bigger, and it might use mainframe MIPS so have a running cost, but you’d have full control over what was going on and you’d be writing for an environment that you completely understood.

 

Even better, if you had more than one piece of monitoring software, you could pretty much use the same GUI software on each of them. That would save development time. But as a user, you might wonder why you had a little bit of overhead with each piece of software. And as a developer, you might wonder why you needed to put the same piece of code in two or more applications. The solution is to have a single program that runs the GUI software that plugs into the monitoring applications.

 

That would work, for example, if the monitoring software were to produce XML-based output, and the GUI software (it would be an HTML server sitting on the mainframe) were to produce HTML that could be sent to the client’s browser. The user could turn the page or click on buttons and send their page back to the mainframe’s GUI software, and it could process the request and send back more HTML.

 

That seems to work, but we are using mainframe MIPS and creating a lot of network traffic–even if we use techniques like Ajax. What if there was an even better way than this? What if, when you wanted to drill down or re-sort a display, or whatever, there wasn’t a need to send lots of network traffic. And therefore, we didn’t use mainframe MIPS. What if we could use something other than XML to send information from the monitoring software to the mainframe GUI-creating software? What if there was something that resulted in much less traffic and much less overhead?

 

For a start, you could use JSON instead of XML. JSON is a bit like XML in that it is more-or-less human readable. In fact JSON offers all of the advantages of XML, but “without the fat.” In this situation, there’s no need to use any of XML’s display capabilities.

 

Now, the HTML server, located on the mainframe, needs to hold page templates and style sheets and a little bit of JavaScript (for example for validation). Using, for example, knockout.js it’s possible to take JSON data and format it with sophisticated client-side interactivity.

 

You could use AngularJS, which makes development and testing easier. It uses custom tag attributes that bind input or output parts of the page to a model represented by standard JavaScript variables, and the values of those JavaScript variables can be retrieved from JSON resources. You could also use moment.js to format dates for different countries.

 

So now the page formatting happens at the client end. If they drill down or re-order a list, it happens at the client end. It’s using the processing power of their laptop, tablet or smartphone rather than mainframe MIPS. But what makes it so clever is that it looks modern–HTML5 and CSS3–and it doesn’t require very much processing power on the client end to produce sophisticated displays.

 

There’s much less network traffic involved–which has got to be a good thing. And there’s less work required on the mainframe end–which could show up as a MIPS saving. So although the client has code associated with it–it is quite a lean client after all.

Posted: 12/16/2013 6:00:00 AM by Trevor Eddolls

Print Email

Join Now!