Low invasive strategies for reducing Mainframe MIPS consumption

Reducing Mainframe MIPS consumptionTop

MIPS consumption is a concern for big organizations using IT systems based on Mainframes. High costs and particularities of the contracts mechanisms push IT manager to look for alternatives.

But Mainframe substitution means a deep change in the IT organization and moreover in the whole IT culture. It is a medium-term project, which must be planned and approached with the maximum care.

While considering and preparing the Mainframe progressive replacement, it is possible to start saving MIPS consumption by means of low impact, no risk strategies. Looking inside the Mainframe, in the batch processes, there are many opportunities for that.

The general idea is simple: to move processes currently performed in the Mainframe, to an external system. After that, restore the processed data back in the Mainframe. The concept can be described as “to plug a processing device” into the Mainframe system.

The most effective way is to convert Mainframe processes to Java, and therefore have the freedom to run it anywhere.

Caravel technology offers a complete suite for Mainframe conversion to Java, which includes specialized tools for these “low impact” approaches, covering from the analysis and discovery to the conversion and the testing phase.

A specific certification tool will guarantee the result of the Mainframe process and external system process produce exactly the same results.

The Mainframe, how does it work?

The Mainframe is the absolute champion in the transaction execution race. In addition, the Mainframe-based systems are designed to use this capacity with an intensive execution of huge lots of transactions. It is known that after many years of activity, Mainframes still process an elevated percentage of total world transactions. But even accepting the Mainframe is very effective, the counterpart is that all these tasks increase the MIPS consumption and so the MIPS bill. On the other hand, this situation is becoming less acceptable in a world where IT technologies are increasingly gaining power and lowering costs.

Batch mainframe processes

The batch processing

The Mainframe systems have clearly separated the real-time applications from the batch ones. And definitely, it is in batch mode where Mainframe gives its best (mainframes were not designed as real-time platforms. For performing these tasks have been introduced somehow “artificial” mechanisms like CICS).

Batch applications are sequences of processes (or JOBs) controlled by a procedure written in JCL language. Once launched, the procedure will run until the total complexion. Commonly several procedures are run one after other.

Typically these transactions, by means of the sequence of JOBs (1, n, m, ...) transform the DB from the initial situation (A) to the final one (Z). Even if the structure looks simple, consider that during these activities an ele-vated number of MIPS is consumed (once identified and isolated from other systems activities, it is possible to measure accurately this consumption).

Partial process migration

The “partial process migration” is a simple strategy that will reduce sharply the MIPS consumption, while having a negligible impact on the IT organization.

According to real cases, reduction up to 50% of the MIPS consumption can be achieved in a short time, by means of well controlled and limited actions. The key point is to address processes that are well defined and therefore can be isolated from the rest of the system. Depending on architecture these processes could be found in different parts of the system. In a phase of analysis using Caravel Insight, it is easy to identify these isolable subsystems components. And once identified they can be deeply analyzed to verify the interfaces (if any) with the rest of the systems (interfaces with data or with other processes), their characteristics and how to deal with them.

Typically there is a well-identified group of subsystems that have these characteristics among the batch applications. Procedures including transactions those run during the low activity hours, usually in an unattended way. In most cases, those only interface with the rest of the system through the data.

Saving MIPS: extracting workload from the Mainframe

All these processes offer an opportunity for saving MIPS due that they can be converted to Java and deployed on an external server (“the processing device”) without interfering the rest of subsystems. The conversion to Java can be achieved in a precise and effective way by means of Caravel technology. Two options can be selected: Automatic Conversion or/and Rewriting. Automatic Conversion is a fast, low risk process, performed by means of the Caravel Converter tool, while rewriting is performed using Caravel Express tool. Rewriting has the advantage of producing a well-structured 100% pure Java code and the ability of including various enhancements.

Batch Java Processes

All the processes involved in the DB transformation (from DB situation A to Z) can then be performed in this external platform, without modifying the Mainframe contents neither charging the MIPS consumption. Once the processes are deployed on the external platform, the mechanism is simple: we copy the Mainframe database in a certain situation (let’s say A) to the external server. Then the processes are executed in the external server transforming data from situation A to Z and lastly the external database is copied back to the Mainframe. The result in the Mainframe database is the same that we would obtain using the Mainframe CPU to perform these processes. But without any Mainframe MIPS consumption.

The advantages

This strategy offers several advantages:

Testing the converted system

Complete testing the conversion using this approach is easy. Just to compare on a progressive journey the results of the successive DB stages. Both systems, Mainframe and converted, are run in parallel reading and comparing at every stage the DB situation in both platforms.

After a number of successful comparisons, it can be guaranteed the exact functional behavior, between original and converted.

The number and level of comparisons can be increased or decreased along the testing phase.

After JOB 1, JOB n… etc., comparisons among DB status (M, N..,) can be verified. The distance between two successive statuses of the DB for comparison can be narrowed to perform an exhaustive verification.

Batch Test Processes

Considering performance

Extracting processes to be deployed in an external Java system requires a previous consideration about performance. In many cases, these processes have a limited time to be completely executed in the Mainframe. So the new platform must accomplish with the same exigency.

In a first approach, moving from a compiled language such COBOL to an interpreted one, like Java seems a back step that could erode the speed execution. To use an Open platform, in principle less powerful than the Mainframe, can also be a cause of anxiety.

Open platforms, a deeper look

The Open platforms now offer improved cost to power ratio. Small, inexpensive systems can benefit from multicore, multithread CPUs with sophisticated L1, L2 and L3 cache memory architectures, extended amounts of fast memory and the most efficient disks. And all these features packed at the lower prices ever. Different technics can profit from these powerful hardware features.

A first technic to speed execution is a massive use of cache mechanisms. Everything that can be saved in a cache, avoiding disk access, must be done. Open platforms offer huge amounts of fast memory.

Open Architectures can also be a huge leverage for gaining speed, using adequate programming techniques. The ability to run several simultaneous processes shows a path to effective parallelization of converted systems. Java offers a whole set of characteristics to control multiple threads efficiently.

Batch processes that usually include many iterative processes can be parallelized. Consider splitting a process into several sub-processes (let’s say an iteration of 1.000 steps, can be reorganized as 10 iterations of 100 steps each). Every small subprocess is then executed in a separate threat (on a different CPU) multiplying the total throughput of the platform.

The journey overview

Analyze the Mainframe system.
Identify isolable sub systems or processes.
The analysis tool Caravel Discovery helps to detect isolable subsystems.
Verify type and number of interfaces.
Once identified the isolable subsystems must be analyzed to locate and describe every interface and its impact with the rest of the system.
Convert selected sub systems to Java.
The conversion to Java, can be achieved by means of Caravel Converter or Caravel Express.
Deploy in an Open platform, external to the Mainframe.
100% pure Java classes, deployable on any standard platform with Tomcat or JBoss.
Complete a test and verification phase.
Deploy in production.

The process

Copy the Mainframe DB to in the Open platform DB.
This can be performed by means of a direct Java process or using any tool.
Execute all the processes in the Open platform.
Execute verification procedures.
Finally the external data base is copied back to the Mainframe.