|Read the Digest in
You need the free
Thanks to This Month's Availability Digest Sponsor
In this issue:
Browse through our useful links.
See our article archive for complete articles.
Sign up for your free subscription.
Visit our Continuous Availability Forum.
Check out our seminars.
Check out our writing services.
What Do We Mean By Legacy?
We often talk about legacy systems. "Banks Worldwide Suffer from IT Legacy," an article in this issue of the Availability Digest, explores the problems that many banks around the world are having with legacy. But legacy "systems" is not the term we should be using. It is the applications that are legacy.
Many applications still in use in critical areas were written decades ago in languages that are not so common today - Cobol, Fortran, PL1, and even C. The developers of these applications are long gone. Students today study Java, not Cobol. Often, the source code of legacy applications is missing or is incomplete. The structures of the programs are a mystery to those trying to maintain them. Yet there is a continuing need to add modern-day facilities to legacy applications to support online functions and new business initiatives.
Legacy applications typically run on modern-day servers under current operating systems. The applications are legacy, not the systems.
Legacy applications can present real challenges to an organization. The cost and risk to an organization to rid itself of these legacy applications often presents an insurmountable path. But the cost of facing these challenges head-on may be small compared to the costs of trying to maintain critical IT services with creaky old applications, as many banks are now learning.
Dr. Bill Highleyman, Managing Editor
On January 24, 1961, two nuclear bombs broke loose from a crippled B-52 bomber and fell on North Carolina. Three out of four safety mechanisms on one bomb failed. Only one safety switch prevented the bomb from detonating and creating a Bay of North Carolina. A secret document, recently declassified, reveals how close this disaster came to being a reality.
The bombs were two-megaton Mark 39 hydrogen bombs with a 100% kill radius of 17 miles. Radioactive fallout would have spread across the U.S. Eastern Seaboard, hitting Washington, D.C., Baltimore, Philadelphia, and New York.
The B-52 bomber was on a 24-hour alert mission designed to keep one-third of U.S. bombers armed with nuclear weapons in the air at all times so as not to be caught on the ground in the event of an attack. The B-52 suffered a wing failure during mid-air refueling and spiraled out of control to the ground. Its two nuclear bombs broke loose during the descent and partially armed themselves. It was only the redundant safety mechanisms that prevented a disaster. Yes – redundancy counts!
Critical IT services are typically protected by redundancy. Each production system is backed up by another system in the local data center or in a geographically remote data center. Should the production system fail, the backup is brought into service - maybe.
What if the backup applications won’t come up? Now you have two systems down. This is the dreaded failover fault. Failover faults are a major concern for services that must achieve high availability. Failover faults can easily reduce the availability of a redundant system by an order of magnitude.
To reduce failover faults, it is imperative that means be taken to ensure that the backup is truly in synchronism with the production system at all times and that failover be regularly and completely tested. Otherwise, the company will be relying on hope and faith that failover will work. Most systems have utilities that monitor and correct synchronization errors between production and backup systems.
The ultimate defense against failover faults is active/active systems. In these architectures, it is known that the backup is always available because it is, in fact, currently processing transactions. An additional advantage of active/active architectures is that no configuration synchronization is needed between systems.
Banks around the world seem to be experiencing outages at an ever increasing rate. Saddled with decades-old legacy applications designed for batch processing, they are reluctant to replace complex systems built in the 1960s and 1970s, systems that have been working fine for years. These systems are difficult to maintain since the developers have long since retired or died. Compounding the challenge is that today’s data centers tend to be a patchwork of dated systems cobbled together as a result of corporate mergers and acquisitions.
However, banks have to meet the growing demands for customer-facing applications for online banking and mobile services. They are building new systems to handle these tasks and are interfacing them to their legacy systems via middleware. Consequently, the systems are becoming more and more complex. At the same time, banks are cutting IT staff and are outsourcing more and more of their IT support overseas.
Many banks are struggling with modernizing their systems. Thus, banking customers for the next decade can expect regular outages of key banking systems as banks continue to struggle with system outages as they modernize their applications.
FileSync is a file-replication utility from TANDsoft, Inc. FileSync ensures that the configurations of two HP NonStop data-processing systems are kept synchronized by replicating Enscribe and OSS file changes between them. FileSync is useful to keep a backup system synchronized with its production system, to propagate upgrades between systems, and to migrate applications from one system to another.
Configuration drift is a major problem leading to failover faults when a production system fails and its backup won’t come into service. FileSync is a major utility to help prevent configuration drift. It automatically keeps Guardian and OSS files on the target system synchronized with the source system by replicating files that have changed, that have become corrupted on the target database, or that do not exist on the target system.
With Version 3.1, FileSync adds data deduplication. This greatly increases the efficiency of FileSync because only changed data must be sent to the target system rather than entire files. If a file does not exist on the target system, it is first replicated to the target system in its entirety. Thereafter, only changes to the source file need to be sent to keep the target file synchronized with the source file.
A challenge every issue for the Availability Digest is to determine which of the many availability topics out there win coveted status as Digest articles. We always regret not focusing our attention on the topics we bypass.
With our new Twitter presence, we don’t have to feel guilty. This article highlights some of the @availabilitydig tweets that made headlines in recent days.
Sign up for your free subscription at http://www.availabilitydigest.com/signups.htm
Would You Like to Sign Up for the Free Digest by Fax?
Simply print out the following form, fill it in, and fax it to:
+1 908 459 5543
The Availability Digest is published monthly. It may be distributed freely. Please pass it on to an associate.
Managing Editor - Dr. Bill Highleyman email@example.com.
© 2014 Sombers Associates, Inc., and W. H. Highleyman