Starting Out
Schema
Foundation Classes
Business Rules
demarc

Program Conversion - Mainframes


Unlike conversions that are from one language to another, mainframe migrations are more amorphous.  While the term is usually applied to data center computing platforms running COBOL, CICS, IMS, Natural, Adabas, and similar software products, it might also refer to 'mid-range' systems running RPG, or some flavor of Unix.  Common characteristics of these systems are 'green screen' character oriented terminals (3270s, 5250s, VT/100s), blocked record structures (fixed length records usually grouped in a constant multiple for efficient storage), heirarchical data storage (physically sequential master, detail, detail..., master, detail, detail... record order), and an operational emphasis on batch job execution.

Given that relational databases have been around on mainframes since the 1980s, there are many relational systems in production.  These include DB/2 and Oracle in particular.  These are often accessed though browswers on PCs, and the hosting environment is less obvious.  Both IBM and Oracle have made Java a centerpieces of their client/server computing environments, with the objective of achieving platform independence.

The primary cause of migration away from mainframes is expense.  These are often inappropriate platforms for operations that host hundreds rather than thousands of users, where response time in a few seconds is acceptable.  Mainframes remain the platform of choice for stock brokerages, airline reservation systems, and other applications where fractional second response times in high-load environments remains critical.

Mainframe software development is often slower and more expensive than one finds on PCs.  In cases where 'response' means the ability to deploy altered systems in response to changes in the business environments, mainframes are at a disadvantage.  These platforms are designed for high-availability, high speed, and extreme security, and the latter in particular creates a ponderous development environment.

One can chart the evolution of computing from core based systems (such as the IBM 1401) through the 32-bit mainframes of the 1960s to the clustered, 64-bit architectures of the late 1970s onwards.  The 1960s produced a raft of hilarious stories of people being sent bills for $0 and told to pay before their account is suspended, and stories about people opening windows in temperature controlled computer rooms and causing the machines to quit on the spot.  Many people whose first exposure to computers as adults in the 1980s was nothing but trial and tribulation might only be dimly conscious that the same mistakes were made in the 1960s, however in the earlier case by major corporations spending millions of dollars.

A lot of mainframe applications in production today have far deeper origins than systems designed around PCs.  Someone hired at age 25 as a programmer in 1965 is now (as of 2010) 70 years old, and might have a hard time remembering what they were doing in 1975, much less 1995.  Plenty of government systems are systems of record, which means that they attempt to save every transaction that has occurred since their inception.  One particularly noteworthy case is where records of US Air Force bombing runs in Laos were used to identify areas where unexploded ordinance might be found.  Such records have been used to find and remediate dangerous leftovers.

Mainframe conversion, in this context, involve quite a bit of archeology.  Many blocks of code were written to work around hardware faults or other quirks.  A lot of programs are either 'quick fixes' or contain one time quick fix code.  A lot of design considerations descend from constraints that existed in the far distant past.  Program design was oriented around project management and documentation environments with whiteboards, electric typewriters, and photocopiers.  Data centers in various parts of town would trade favors: you have a newer 9-track tape drive, I have an older card reader, if you need cards put on tape I'll trade you reading my incoming high density tape and writing out as a low density tape.  File and field naming conventions represented the culture and legal conventions of the time.  In one form or another, the conversion task is going to involve a lot of history lessons.

For those that feel like their system is way overdue for an upgrade, please call 210-734-5575 for free initial consultation.

Or, eMail us at Info@ResourceLogic.net