Death of the green screen

As classic mainframe subsystems, such as IMS and CICS, start planning what to do for their 50th birthdays, it comes as a bit of a surprise to not only find that so many green screens are still in use within organizations, but, perhaps even more surprisingly as I found at a recent technical conference, so many sysprogs were saying that they felt happier using green screens. For them, anything else was just a fancy add on. They liked working close to the bare metal (as it were). Well, I have some bad news for them. I predict the death of the green screen in 2014!

Ignoring the fact that many mainframe experts have a 5 or a 6 as the first digit in their age, ignoring the fact that they are completely familiar with the green screens they use, and they have been using them for the greater part of their working life. I believe that mainframe display screens will start to look modern – as though they were designed in 2014 and not 1964 – because that’s what most people will want.

Think about your life style for the moment. You expect to get online and do banking at any time – that’s using a mainframe. You expect to be able to book a flight whenever you want – that’s another mainframe. You simply expect to be able to work at any time that suits you on any device that’s to hand – a laptop, tablet, smartphone. And large organizations want to be able to continue enjoying the benefits of their mainframe. So let’s put those together.

For many people, they simply want to use their browser to ‘see’ what’s going on inside the mainframe. And that browser could be on any of a number of platforms. People just want it to work. It’s got to be platform agnostic, and it would be really be useful if the display took into account the screen size of the device being used to run the browser software.

One way to do that is for the mainframe application to use JSON to send information to an HTML server (also on the mainframe) that then sends out pages to the browser. Using, for example, knockout.js it’s possible to take JSON data and format it with sophisticated client-side interactivity. In other words, it makes it look very modern – and is very useful.

Another solution is to create mobile apps. Software AG has webMethods, which offers, they claim, secure, high-performance communication infrastructure that combines message-queueing capabilities with built-in support for synchronous request/reply and conversational communication. It provides wrapping technology and programming interfaces that can turn existing application functions into business services. Business logic and security functions can be applied to information before it is supplied to a mobile app and before information from the mobile app is applied to the target (core) database.

Software AG suggests that this approach is ideal for managing interactions for tightly-coupled, time-critical user applications. Their examples are a sales representative wanting to check a buyer’s credit or a consumer looking for an insurance quote for their car. Any activity that requires the mobile user to enter information that is sent back to the core application for processing and which then returns a result would benefit from this approach.

Of course, once you go down the app route, you need an app for Android, and app for Windows 8, and app for Blackberry, an app for Apple IOS, etc.

The other reason that I predict the death of green screens is the growth of younger developers who expect a graphical interface. They want programming to be a drag-and-drop activity. It shouldn’t be any harder to use a mainframe than it is to use a games console, or a tablet device, or anything else. It should be intuitive. The software should ‘nudge’ you towards doing whatever task you appear to be doing. That’s where skeuomorphism comes in – making on-screen icons look like real world devices, so using them is more intuitive. And the software should display results in a way that makes drilling down for more information quick and intuitive. And it may be that the software is designed for touch screens.

There’s a very old Star Trek film (Star Trek IV: The Voyage Home) where Scotty sits down in front of a current computer (it was 1986) and talks to it – nothing happens. Someone gives him the mouse to use, and Scotty speaks into the mouse! We’re used to Siri and other voice interfaces. Maybe soon things like Nuance’s Dragon NaturallySpeaking will be available for everyone to use. But, for the moment, I’m simply predicting coloured screens everywhere (and the green screens will be gone).

If you do celebrate Christmas – have a great one. And if you don’t, have a great time anyway!

DB2 goes big and mobile

So where’s all the excitement in computing these days? If your answer is Big Data and mobile apps then you’ll be fascinated by the latest DB2-related news.

Let’s start at the big end. IBM announced DB2 Version 10.5 recently and included in it are a set of acceleration technologies code-named BLU – apparently standing for Big data, Lightning fast, and Ultra easy! BLU is a bundle of new techniques for columnar processing, data deduplication, parallel vector processing, and data compression – everything you’d need if you were working on Big Data in memory.

So, BLU enables databases to be “memory optimized” – which means that they will run in memory, but not everything has to be put in memory. BLU has also removed the need for hand-tuning SQL queries to optimize performance.

IBM is saying that this new version of DB2 can speed up data analysis by over 25 times. That means databases don’t need to be sized so they everything fits in memory, and there’s no need to purchase separate in-memory databases for fast data analysis and transaction processing jobs. IBM has been showing an example of a 32-core system using BLU technology executing a query against a 10TB data set in less than a second.

This kind of processing ability makes DB2 a better choice in some cases than using Hadoop. The data is compressed in the order in which it is stored, allowing predicate operations to be executed without decompressing the data set. The software also keeps a metadata table that lists the high and low key values for each data page or column of data. The advantage of this is that when a query is executed, the database can check whether any of the required values are on the data page.

IBM is using BLU in its DB2 SmartCloud IaaS (Infrastructure as a Service) to add power for data analysis and data reporting jobs.

Meanwhile, DB2 and MongoDB are getting together to announce a new standard to make it easier for organizations to implement data-intensive apps for the Web and mobile devices. MongoDB, you say, what’s that? MongoDB is owned by 10gen and utilizes NoSQL database technology. It’s used for lots of mobile and Web apps.

Developers will be able to use Eclipse tools with IBM Worklight Studio to integrate MongoDB APIs using the MongoDB query language. That allows developers to more easily query JSON (JavaScript Object Notation) documents in DB2. JSON documents are frequently used for storing Web-based data. A NoSQL database allows data to be added without a predefined schema and allows a wider range of choices when scaling up.

The plan is that later this year developers will be able to combine the WebSphere eXtreme Scale data grid platform with MongoDB, and they’ll be able to run MongoDB apps directly on DB2. Developers will be able to write apps using MongoDB’s query language to interact with data stored in DB2 and WebSphere, making the vast amount of data in IBM data stores available to modern application environments. IBM hopes to broaden the API and is already working on open source code for security, extended transaction support, and extended join support, among others.

So DB2 is growing at the big end of the database world and the little (mobile) end. Interesting!

Putting it all together

I was chatting to Tony Amies, product architect at William Data Systems, about the best way to get information from a mainframe (and about what’s happening on that mainframe) out to someone who has access to a browser. He had a number of nifty techniques that I’d like to share with you.

Assuming you want to get the information from your mainframe to a browser, your first really big decision is do you want to go with two-tier architecture, or do you want to go with three-tier architecture? Tony’s advice was that two-tier was enough.

That leads to the second really important decision to be made, which is where should the processing take place? You’ve got to look at what needs to be done and then make a choice about which platform does that work best on. So, for example, and perhaps quite obviously, if you want to monitor what’s going on with IP, FTP, or EE (Enterprise Extender) on your mainframe, you want that processing to take place on the mainframe. That all seems fairly easy!

But what do you want to do with your results from those different monitors (and indeed any other monitoring software you have running)? Do you want to look like mission control and have a 3270 screen for each monitor that’s running. Now, I remember how impressed visitors used to be when they saw something like that, but if my plan is to get the information to laptop or tablet device running a browser, then I probably need to consolidate the different feeds first. And, again, I want to do that on the mainframe, in the same LPAR (Logical PARtition) that the monitors are running in. It makes sense because much less work has to be done than if I choose to send that data somewhere else for processing.

If you’re familiar with WDS products, you know about their ZEN monitor for their other products. They’re written in Assemble and C and they use a little DLL inside each product that talks to a DLL in ZEN and you can see a nice display of what’s going on – on everything. As a side note, using the DLLs allows the products to talk to each other, so that if the IP monitor spots something, then the IP trace tool can be used to investigate further.

So, using the two-tier architecture, ZEN is logically split into two parts. One part is mainframe friendly and one part is Web friendly. Associated with the Web-friendly part of ZEN are the necessary JavaScript libraries and JQuery libraries, and the usual HTML bits. If you’ve not come across JQuery before, it’s like a lot of clever JavaScript that’s been already written that you can use to make your Web site look very modern. Lots of sites use the jQuery lightBox plugin to show photos.

There’s always a problem with busy Web pages in that lots of information has to come from the server to the browser, resulting in lots of network traffic – and if you’re monitoring your mainframe’s network from a browser there can be even more. So the first technique they’ve used is AJAX (Asynchronous JavaScript and XML), which means that only the parts of the Web page that have changed are sent, the rest of the page stays the same. They also use JSON (JavaScript Object Notation) as a lightweight data-interchange format.

But there’s always an issue with any User Interface and that’s how to separate the actual user interface itself from the business logic behind it. In technical terms, these are known as the view model and the data model. To make this work as effectively as possible, they’re using MVVM (Model View ViewModel), which is a framework or architectural pattern coming originally from Microsoft, but now extended to include JavaScript MVVM. You can get a clearer idea of the sorts of things they’ve done – and perhaps the sorts of things you could do from knockoutjs.com. The site describes itself as “simplifying dynamic javaScript UIs by applying the Model-View-ViewModel (MVVM) pattern”. The WDS developers also familiarized themselves with prototypejs.org, a site describing itself as “a foundation for ambitious web user interfaces”. They go on to say: “Prototype takes the complexity out of client-side web programming”.

For WDS, basically an object is requested from the browser by the user. This goes up to ZEN. Using JSON, a data object comes down and binds with the layout defined in the MVVM skeleton. As a user, you see dynamically updated information in your browser. If one new value affects other values, those other values are automatically update appropriately.

I’m not endorsing WDS’s products, I’m saying that they have very effectively made use of the very latest technology at the browser end to make their product work very efficiently. I’m suggesting that the two-tier architecture with really clever stuff on the browser side is definitely worth taking a look at.