DRJ's Spring 2019

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 31, Issue 4

Full Contents Now Available!

Time is running out to fix the millennium bug. What will happen to your company if it is too late to fix every system, or you are not certain that everything will work properly in the new millennium? If you are responsible for business continuity, then you need a contingency management plan to protect against Year 2000 (Y2k) failure.

A Y2k contingency plan cannot take the place of fixing and testing your systems. Develop your Y2k contingency plan in parallel with any Y2k efforts. Communication must be synchronized between projects to leverage data collection, resources, preparation, response and recovery strategies.

A Y2k contingency plan is different than a traditional business continuity plan. It is written into any existing plan(s) to enhance protection from the Y2k crisis, viruses, failed upgrades, and software bugs. This methodology attacks the Y2k problems through failure identification, monitoring, alternate processing, upgrading, and litigation.
Failure Identification

Similar to regular contingency plans, Y2k contingency plans demand a business impact analysis (BIA) to specifically address date sensitive critical systems. Working with any existing Y2k planning team(s) will help identify which systems have been Y2k tested. To reduce redundancy, use the BIA as a template. Make sure the BIA is updated and modify it to include date sensitive systems and interdependencies.

A quick crosscheck of the world’s largest Y2k compliant systems is being maintained by EDS and can be reached free of charge at the website, www.eds.com/vendor2000. Containing over 125,000 items, Vendor 2000 is a powerful compliment to the "Good Samaritan" legislation now in Congress, which encourages organizations to share Y2k information with the public. Compare your inventory and versions with this database to identify system failure.

Emphasize systems that calculate the date, or systems that would fail if the date were incorrect. Year-end batch processing systems are most critical because they occur during the rollover. Do not overlook other critical dates (Julian Calendar: 4/9/1999; Gregorian Calendar: 9/9/1999; seven digit date field: 1/10/2000; leap year 2/29/2000; eight digit date field: 10/10/2000, and so forth) when performing the BIA.

Interdependent systems are a commonly overlooked Y2k single point of failure in a BIA. A non-compliant system can cause a Y2k tested system to fail if they are connected. Two Y2k compliant systems may use different solutions to fix the bug. Both work separately, but may cause the other to fail when linked. A typical error is using both a 100-year sliding window technique (recalculating a date by subtracting X-years from the date and then adding X-years to process the post-2000 date) and increasing the date field (increasing the date field from 2 to 4 digit places and adding 1900 to all dates) in two systems that talk to each other. This commonly happens in large corporations with multiple sites and separate Y2k teams.


Prepare several months before January 2000 for systems failure by taking the necessary precautions. Determine who will monitor the systems during the rollover, helpdesk preparation and Y2K "swat team" training.

Freeze vacation schedules during the winter holidays. If you decide to keep people onsite during the rollover, announce this at least a year in advance. Recognition of team members through bonuses, compensation time and hazard compensation will help maintain moral.

Train your help desk in handling Y2k problems and escalation procedures. Prepare written scripts for them to respond to outages. Communication between organizations is crucial in a disaster. Be sure alternate forms of communication are available to the help desk like fax, internet, and wireless.

Assemble a Y2k swat team to be onsite during the rollover. The team must consist of system operators, programmers, help desk staff, managers, and a single point of contact. Train them on executing the plan, using reactive solutions on failed systems, escalating problems, manually resetting systems, implementing workaround processes, and communicating with vendors and customers.

Alternate Processing

Developing an alternate processing method depends on the environment. A possible manufacturing alternate processing solution might not be applicable in a financial institution. Strategies suggested include stockpiling, outsourcing, powering down the system, manually processing, using hot site vendors, preprocessing systems, increasing production, and rolling back the clock. Any combination of these alternate-processing strategies can be used to recover.

Reduce the risk of your supply chain depleting by increasing the critical components, which may not be available due to a Y2k outage. Several months before the new millennium, stockpile items that only one vendor can provide. With a surplus of critical components, a Y2k interruption can be avoided.

Find third party suppliers to temporarily fill the void of the failed system. Competitors may not have a Y2k interruption. They could be subcontracted to fill the void until you are able to recover your systems. The key is not to give market share away during a crisis, even though it might cost you more in the short term.

Shutdown non-Y2k compliant systems before midnight, December 31, 1999 and schedule a phased power up in the new millennium. Train staff how to bring up the systems, prioritize the boot order, adjust the system clocks, test the systems, and escalate any problems.

Manually process automated systems that fail. A manual alternative normally requires hiring and training additional staff. Do this several months before the planned outage to reduce their learning curve. This strategy can be used to replace all or part of a failed automated process.

Hot site vendors may have Y2k compliant hardware to use during your outage. If a replacement part won’t be available for some time, but your hot site vendor has a Y2k compliant system, declare a disaster. Be warned that some hot site vendors don’t consider a Y2K outage a disaster and this solution will not work if your software is not Y2k compliant. Your hot site hardware will fail if the software is not fixed.

Pre-process your batch systems before the rollover. Include financial, sales, and other critical components identified in your BIA. Cut your paychecks in advance of the new millennium. Decide how many checks to write and validate the accuracy of the checks. Create invoices and any billing in advance of the new millennium. Run financial reports, forecasts, and sales reports before January 1, 2000. This will also help validate your systems by comparing the same batch processes executed before and after the millennium.

Increase your production output before the new millennium, in anticipation of a failure. This will give you additional time to fix the system before your surplus runs out. This will buy you some insurance at the cost of warehouse space.

Spin the clock backwards. Recover a failed system by tricking it into thinking the date is pre-2000. This procedure must be done carefully. Some date-sensitive systems may make faulty calculations that can compound your Y2k outage. Databases can become corrupt from bad calculations and be propagated to other Y2k compliant systems. Choose the rollback date carefully. A financial system may calculate interest over a hundred-year period, instead of a month. A system that performs seemingly minor functions could have serious consequences. What if the automated security system thinks it’s a weekend, even though it’s a workday? The system may lock employees inside, turn off the lights, and then shut off the heat.


Upgrade hardware, suppliers, software, and operating systems to Y2k compliant levels. A complete inventory is needed to help procure the failed components. Partnerships with several distributors that quick-ship components will help get the upgrades in the shortest amount of time. Overlooked components can be a single-point-of-failure. Failure of routers, controllers, and firmware can cause work stoppage for a complex system.

Upgrade non-compliant software to an off-the-shelf Y2k compliant commercial package. The disadvantage of using a standard version of the software is that some functionality may be lost. Software customization can occur once the Y2k crisis is over.

Replace any non-Y2k compliant suppliers with vendors that have fixed their systems and can prove that they’re Y2k ready. Get a written guarantee that they are compliant and have Y2k contingency plans.

Upgrading systems might not be possible because the vendor may be out of business, or may not have an upgrade to the system. Reverse engineering the system or scrapping the entire system and looking for another solution are the only long-term solutions.

Contract Y2k consultants to fix systems that fail. It is important to have an existing contract before the systems fail; otherwise, hiring consultants –at a high cost and short supply — is necessary to put out Y2k fires.


Remember to get legal support to review license(s), service level(s), and vendor agreements. Attorneys are preparing for a windfall of lawsuits in the new millennium. Anticipating widespread failure of systems, lawyers are attending Y2k seminars that specialize in suing companies that suffer Y2k disasters. Y2k may be more lucrative than medical malpractice. Lawyers may not wait to file their lawsuits after the crisis is over, expect them to file Monday, January 3rd. To protect your company, consult your legal department or hire a Y2k lawyer.

Criminal laws prohibit marketing a destructive system. These laws were originally used to protect from Trojan horses, time bombs, and other viruses. The Y2k bug could be interpreted as another type of destructive product that disables systems.

Forced switches to the latest or more expensive product may be illegal. If the only way to fix the Y2k outage is through upgrading a relatively new system but it costs more than the original product, then this may be grounds for a possible lawsuit against the manufacturer.

Sue for any misrepresentation by software and hardware companies that certified their product as Y2k compliant. Misrepresentation lawsuits can be used against vendors that say their systems are Y2k compliant, but fail in the new millennium.

Business interruption insurance may include Y2k disruption. This can help fund your recovery efforts and offset any litigation. Again, review your insurance policy with your attorney.

Countersue any lawsuits based on the industry standard defense. The industry standard decades ago was to conserve as much valuable system space by reducing the date field from four characters to two. Since this practice is common, the entire industry accepted this hazard in the expectation that these systems would be retired by the millennium.

Sue any maintenance vendors to absorb the cost of Y2k. The Y2k bug can be considered a part of maintenance depending how your contract was written. Unless the contract has a clause that specifically excludes Y2k bugs, you might be entitled to vendor assistance.

Watch for new legislation and precedents that may effect your industry. Protect your company and minimize any damage from a lawsuit by keeping detailed documentation before, during, and after the crisis. Y2k contingency plans help prove that your company used a high level standard of care.

Comprehensive Continuity Plans

In addition to any Y2k benefits, these plans address hazards similar to Y2k threats, such as viruses, failed upgrades, and software bugs that were typically ignored. These planning efforts are valuable after the millennium crisis is over. Systems will fail in the new millennium- is your organization prepared to face this crisis?

Peter Slintak, CBCP has written business continuity plans for the United States Postal Service, Electronic Data Systems, General Motors, and Hitachi Data This email address is being protected from spambots. You need JavaScript enabled to view it.