Rehosting: can be useful against "the stomach-ache"?

Here the steps to leave the mainframe towards cheaper platforms opened to the future technologies.

Inside, the reader can find the first of four articles that set a way to follow for who has decided to leave the mainframe platform, too expensive and hardly to manage nowadays.

Together with a specialist, we?ll analyze all aspects of re-hosting, not only the technical ones.

For many users, the TCO problem on mainframe needs a urgent solution: power and reliability provided by mainframe can be nowadays obtained on more convenient platforms which have many skills, applications and tools.

Leave the mainframe. Why do we try the rehosting?

A path to better move the IT system toward a new technological platform

Nowadays the mainframe is the bittersweet tool for many IT managers.

Many companies still execute on it their core applications, but its management causes many problems about costs, management and IT evolution.

The most important problem is TCO (Total Cost of Ownership): the same power and reliability can be provided by different architectures and at lower costs, thanks also to a hard competition on the market. The monopoly of mainframe doesn ™t give any chance to the CIO to operate.

Furthermore, there are some other problems: on one side about the legacy technologies (out-of-date tools, wanting of skills, difficulty of integration with new technologies); on the other side, Company ™s needs to be satisfied, preserving the acquired know-how about the applications and maintaining the quality of the offered service

More and more It Managers are looking with a greater interest to Unix, Linux, and Windows server both to provide more and more evolved services and to knock down the costs.

But there are also many questions about this passage. First of all, that we encounter is the difficulty in defining the passage of the IT system to a new technological platform, with a right evaluation of costs, risks and times.

The manager, who is going to undertake this passage, will not have any problems in analyzing the singular aspects but in having a clear vision of the project which need to be the right medium between evolution, innovation, maintaining of the quality and lower costs.

Who usually deals with migration already knows that the main question is not "if" the mainframe can be left but "how".

And then, is it better re-write? Replace? Or migrate?

If the IT is out-of-date for the business process and there are availability of money and time, the better solution is "re-write". If the IT functionality can be replied with packages, if we intend to reduce the competences and we have funds and time, then the better solution is "replace".

In all other cases, the answer is "migrate" or, in other word, an "as is" moving of the application towards new platforms, without many structural changes and leaving the same interface and functionality.

Rehosting is perfect for companies where the applications are still good for the company's needs, thus lowering down costs and risks, time of migration, evolved applications, preservation of the know-how and quality of the service.

Why rehosting?

Rehosting has lower costs, both during the passage and the management. During the migration step, the costs of analysis and codification are very low as the written or modified parts will be very few. Also test ™ costs will be lower than other processes (such as the "re-writing") because the test is executed on an already existing code.

Furthermore, also time of execution are reduced and, consequently, the returning of the investment is more rapid.

The management will have lower costs both for mainframe or other processes of substitution.

The "re-hosted" application maintains the features of mainframe, stability and good management of the resources, so that cheaper systems are required. It can be easily proved that the use of mainframe-like architectures requires fewer resources than other "modern" architectures, such as Java or Net. The using of the same interface, same software and fluxes, allows maintaining the precious know-how previously obtained and reduces the time of training of the IT team and users, thus getting more economic and human relationships advantages. On this side, the IT manager ™s problems are both technical and human, both inside the IT team and the final users. The first ones are divided into two groups, the first one looks at the migration as a Panacea, the second as a Pandora ™s vase. The final users are always opposing to changes.

The main advantage of being similar to the start point is joined to the guarantee that rehosting can work on modern systems and has a optimal integration with new technologies, commercial ones and open sources, and the possibility to reduce the times and costs of management.

Rehosting is furthermore a strategically passage for the development of the IT system that allows savings and innovation, easily proved. In Italy, about 30 great Companies, such as Snaidero and TFS (FS group) has experienced the rehosting and have reports that show the validity of the decision, both on economic and innovative side.

As we said, the rehosting is the migration of the mainframe applications toward a LUW system (Linux, UNIX or Windows), thus lowering down costs, risks and changes.

Postponing to the next part the discussion about data, now we will see how the logic of our SW can be run on a target platform, leaving unchanged the codification, the structure and, most of all, the functionality.

How is it possible that a software for mainframe can run on a different system? We have to consider our application as a group of rules and tools: the first ones are created from the origin, such as software maps, jobs and so on; the latter are represented by OS, compilers and tools.

It being understood that we 'll not change the "rules", and we need to identify all the "tools" that can be used also on the target platform. It's a commonplace among the operators on mainframe that typology and quality of the available tools are unparalleled. The market is showing the opposite and is offering compatible mainframe products for LUW which have, as competitors, excellent qualities and are in steady evolution.

But that ™s not so easy : there are many suitable tools for the great part of our software but there are also some codes that do not fit on target platforms, such as some software coded with assembler. In these cases we should operate a change of the origin (a re-codification) to allow the execution on alternative tools but leaving the logic unchanged. Even if this solution could be an increasing of the obsolescence on the target platform, actually all the available "traditional" tools for the new platforms have both a high compatibility on the back, and excellent features of integration and evolution, mixed with efficient technologies well known for years. COBOL for example: many people think that it is obsolete and has a bad integration with LUW system. But in 30 years of utilization and highly evaluated functionalities, it is still the best platform for business application and has a compatibility that other "most evolved" languages barely reach.

Let's try to analyze the possible solutions to replace the main mainframe tools.

First step is, obviously, the H/W and the operative system. UNIX/Linux machines have already the potency and reliability to replace the big mainframe systems, with a greater flexibility and lower costs.

Even if they are not suitable to replace bigger systems than 100 MIPS, Windows systems are also a valid alternative to the medium-low mainframes.

For the most common languages, such as COBOL, PLI, FORTRAN and C, the market offers a great choice of compilers for LUW platforms, both commercial (ACUCOBOL, Microfocus, Liant) and open-source (GNU, OpenCOBOL), with a high, if not complete, compatibility with IBM world.

About 4GL (ex. Easytrieve, CSP, etc.) and Assembler, it ™s better to convert the origin in C or COBOL, just to avoid the obsolescence, unify the software and solve the supplying of the skills.

In most all cases, the online software use a TP monitor, such as CICS or IMS/DC, a sort of middleware which checks the execution and provides a great number of functionality. Many vendors nowadays offer CICS implementation for UNIX/Linux, largely if not completely compatible with the mainframe version (for ex. XFRAME, MTP, TX/Series and others).

For IMS/DC there is not a so large choice of solution but this is interesting in each case (XFRAME e SIM DB/DC).

About batch, we have to consider JCL and its management. Even if it has differences between z/OS and VSE, it still remains a powerful tool of checking of the operative fluxes.

For the target platforms we can find both interpreters, such as a run-time for the dynamic interpretation of JCL, and converters, such as tools which automatically convert JCL into native scripts.

Leaving out the details, it is interesting to underline how each mainframe component can find a correspondent one on the LUW platforms, thus generating only minimal costs for the necessary little adjustments and positively acting on the test length, the saving and reducing the most significant risks.

After the analyzation of the logic, let ™s now have a look to the data. We ™ll firstly proceed on a classification and look for an efficient system for a faster and painless migration. Let ™s remember that we need to find a correspondent system on the target platform and rightly convert from EBCDIC mainframe into ASCII of the LUW systems (Linux, Unix and Windows).

In the most of instances, data on the mainframe can be stored on three kinds of database: relational, hierarchical and index/consecutive.

The relational data bases, the DB2 in 99% of cases, give less troubles for their migration.

As destinations, we can choose among the commercial databases, well known for the efficiency, such as Oracle or UDB, which can reproduce the performance and functionality of DB2 mainframe, and Open Source databases, such as MySQL or PostgreSQL which can give good results at low costs, if not migrating from a DB2 particularly œhard .

The hierarchical databases, on the contrary, have not a correspondent on LUW. We have two possibilities. The first one is a recodification in Sql of the software: on the market there are some tools which automatically make this passage, but you need to remember that this codification can have a hard impact on the logic of the software and the costs of testing can slightly increase.

The second one is the utilization of transparent gateways, tools that act as DL/I and use a relational database. So data is easily migrated, for ex., from DL/I to Oracle and access stubs are provided thus leaving unchanged the software.

It ™s obvious to say that files, both consecutive and index, can be used on LUW system. The first ones are directly managed from the system, and the latter ones can be managed with ISAM libraries. There are different versions of these libraries with functionality that goes from a simple index management to a complete emulation of VSAM.

Data migration, even if relational, hierarchical or consecutive/index, is not finished with the identification of the target tool and the translation from a codification to another one, but it is an elaborate process which has to reckon with the different kind of data and permits "the jump" in satisfactory times.

It is important to remember that not all data have to be converted from EBCDIC to ASCII, but only the character type. The others, such as the numerical ones, need a different treatment or, sometimes, remain the same. So the tool for conversion will not be only a processor of codification but carefully operate together with the structures of data. The definition of this process is very thorny because, but for relational DB which are strongly typical, the others, stored on hierarchical system or SAM/VSAM, have a structure whose definition is possible only in the documentation of the codification, if available, or in the codification of the software with access, sometimes with heterogeneous pattern.

Obviously, in this case too, what could seem very difficult and risky, it is, on the contrary, well supported by tools and companies which can automatism of this process. Suitable tools, together with the know-how of people which well know the application to migrate, strongly reduce the percentage of error.

About the compatibility of the data migration with a satisfactory "down-time" during the switch-off, we need to underline that the conversion has to be 100% batch, so it can be tested various times, it is possible to identify and correct the errors and the times can be valued and optimized.

We need to value the length of the whole process (download, conversion and upload) and the maximum time we generally have. If the process should be too long, it will be reduced with some strategies such as a simple parallelism or an incremental migration, thus arriving to a flux completely repeatable without any error in the fixed times.

By the way, we are talking about the most difficult cases: actually a Terabyte of data, with suitable machines and without any particular optimization, can be migrated from DB2 to Oracle in 48 hours. So the problem is very imitated.

After the data, in the next article we ™ll see how we can utilize all the described activities in a unique process and how we can organize a flux which permits a migration with the lowest costs and risks.

After having analyzed the singular problems about the rehosting, now let ™s try to make a complete fluid process which can permit a migration at low costs and risks.

The first step is the analyzation of the object of the migration. It will be necessary to draw a map of used software, just to make an inventory of the functionalities, compositions, relationship between the applications and cataloguing the used tools.

During this passage, together with the œnormal  activities of analyzation and S/W mining, it will be very useful an interview to the IT staff which can bring to light some hidden problems and pay more attention to the outbound communication. Our experience says that behind a 99% of standard fluxes, there is a 1% of personalization which satisfies the customer, the supplier or the end-user and which is too often forgotten. The knowledge of these little particulars during the planning period will help us to avoid the problems and try to normalize them

After designing the complete map of our software, we could define what has to be migrated. This could sound a little strange. How should I migrate only a part of the applications?

The answer is simple, even if articulated. First of all, there could be some "dead branches", obsolete or not utilized.

Secondly, there could be some applications that can be managed with software suites present also on LUW and they could be more operative than their migration. For ex., the suite "salary and wage" can be provided both for mainframe and Linux.

Thirdly, we could experience a surrounding: the goal is not the whole and immediate ceasing of the mainframe ma the reduction of costs with a partial rehosting, or its progressive ceasing, very common for the big dimensioned calculation centres, (over 1000 MIPS).

Let ™s now analyze the consumption of a migration and its composition, just to define the suitable H/W structure and the necessary software stack on the target system

It is being understood that LUW machines can equal, if not pass, a mainframe about potency and reliability, but we however should rightly adjust the destination machines to the consumptions, paying a particular attention to the number and type of CPU. We shouldn ™t just compare the MIPS “ TPM/C charts, but also consider some important parameters, such as number of transactions, of connected users (daily, hourly and the peak), response time, number of batch and dimension of the nightly window. The mainframe is a system which works with few but very powerful CPU, with I/O under-systems which lighten the process so that our applications can be written just to exploit this kind of architecture. So, when defining the H/W target, it will be important to value both the potency of the machine and its distribution on the single CPU, advantaging the systems which permit an inferior number of processors with a hard batch surcharge.

About the composition, we ™ll proceed as already describe in the previous articles. We ™ll define the software's which are suitable for our application to run and define what we can move without any modification because tools are equivalent, and what is necessary to be converted (and how).

Once we decided where to go and how, it is necessary to build up a roadmap of the migration, with steps, times and necessary resources.

In the planning period, many activities can be made parallel, such as the conversion of the software and data migration, thus arriving lined up to the test, which will be faster than a re-writing or re-engineering because it is executed on pre-existing functionalities.

Montreal's Speedware offers mainframe migration

By: Rafael Ruffolo - ComputerWorld Canada (06 Nov 2008)

With Xframe, Speedware is promising North American users the ability to move their legacy applications off the big iron and onto platforms such as Unix, Linux and Windows. Re-hosting revisited

Montreal-based Speedware Ltd. is offering a software tool that can migrate mainframe applications to Unix, Linux and Windows-based platforms. But while smaller companies might see the benefit in moving a few legacy apps off their mainframes, at least one analyst says the solution might not resonate with larger IT shops.

With Xframe, programs written in COBOL, PL/I and C languages can be ported over to a variety of operating platforms. The software tool also contains a transaction server that can execute CICS and IMS/DC applications, as well as, run mainframe batch processes from z/OS and VSE systems. It supports migration to Unix, Linux and Windows platforms.

œIt takes your JCL and automatically converts that to the platform in question, so that might be a Windows scripting language or Korn shell or another scripting language, Garry Ciambella, head of research and development at Speedware, said. He added that Xframe offers full VSAM emulation supporting KSDS, ESDS, and RRDS files.

Along with its customer delivery partner Lead Point Inc., based in Detroit, Speedware is introducing the XFrame re-hosting tool to U.S. and Canadian customers. As an XFrame reseller, Speedware will provide mainframe customers with integration services. The software was developed by Italy-based HTWC S.r.l.

Ciambella said that re-hosting your mainframe apps on open systems can offer significant cost savings and add more flexibility for enterprises down the line.

Speedware estimated that about 1,500 companies use IBM mainframes in Canada alone. These systems can range anywhere from small scale 100-MIPS (millions of instructions per second) mainframes to large scale 1,000-MIPS machines. The fact that Xframe offers a fully automated migration path will be of particular interest, Ciambella said, to enterprises of all sizes.

"The information we've gleamed from market analysts has shown us that upwards of 80 per cent of mainframes are running things like DB2, IMS, VSAM, CICS and COBOL, which is really the a perfect fit for the Xframe product" he said.

But according to Charles King, a principal analyst at Pund-IT Research Inc., most mainframe re-hosting solutions have had a pretty spotty track record over the years.

"Where these tools tend to find success is with companies that have a few applications running on the mainframe, but are not really pursuing any kind of growth strategy with their mainframe environments," he said. Smaller companies running an application or two on ancient mainframe systems might be wise to consider the migration option, King added.

The companies that have made significant investments in mainframe computers, King said, are continuing to work dynamically with those systems and don ™t see the benefit of migrating from them. This is especially the case with large enterprises in the financial sector.

"The big banks wouldn ™t touch this stuff with a 10-foot pole" he said. œThe move really isn't quite as simple as the re-hosting folks would like it to sound. Usually there's a good deal of service work involved in either writing or customizing the applications and moving everything over so it works properly. It's not an exercise for the faint of heart.

Large enterprises such as banks, King added, typically have environments so complex that even if they were considering a migration, it would probably be shot down by upper management for being too expensive.

"The other thing, and in transaction computing especially, as good as Wintel and Unix systems are, if you need absolutely top-end and reliable computing, there's  no systems in the world that can match the mainframe" he said.

Ciambella admitted that while a whole box migration might run into some challenges because you have to replace the technology in the entire machine, for clients looking to migrate a select number of applications, there ™s no better option.

"It's only the largest segment in terms of MIPS that is still seeing modest year-over-year growth in the mainframe market" he said. "If you're looking at machines that are greater than 1,000 MIPS that I'd agree IBM is still moving those at about eight to 10 per cent a year. But analysts believe that by 2010, that's going to stabilize and then start sliding down"

In the smaller machines, he added, the industry has seen declines anywhere from 10 to 15 per cent depending on the MIPS segment.

Speedware is a subsidiary of Livermore, Calif.-based Activant Solutions Inc.