|
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
|
|