As Y2K is not an unplanned interruption, event or condition, with few exceptions, there is nothing a contingency planner can do for you on January 1, 2000 or beyond. Your company will either be ready or not ready. It's a binary ready or not, here it comes. If your operating system is not at a current release, your applications not yet converted, your hardware not tested as Y2K ready or your internal network is not compliant, you'll simply have nowhere to go. That is, declaring a disaster and rolling to a recovery center will not solve your dilemma(s). You'd simply be moving the problems to a new location, which in itself creates even more problems to intermix with the ones you falsely think you can solve.
Furthermore, most recovery service providers contain within their contract a definition of a "disaster". It is a simple clause that essentially stipulates that you have the right to declare a disaster and use their recovery facility in the event of an "unplanned interruption" or "unplanned event or condition". Remember, we've all known that the year 2000 was coming since the conception of the Gregorian calendar (ample warning of pending date). What's more, the two position date problem was born immediately after the first compiled program went into production (a few + decades ago). And finally, the Y2K articles have increased exponentially in the last 4 years, each identifying the problems and offering solutions. In summary, you have had ample warning of a decades-old date problem which has been identified in countless articles with solutions being provided. Not quite an unplanned interruption, event or condition.
The good news is that for those businesses who are facing reality now, and taking appropriate action, their chances for survival are rather good. For those who still have their heads down, they are on a long walk down a short pier and can't see it. So, how can we as contingency or business planners contribute to the common objective of being Y2K Ready? Furthermore, what can we do when the clock clicks to 2000? Let's take a look at each of the two areas.
1. To start with, if not already under taken, a project must to be opened, sponsored by your corporate management and functioned to address each of the foregoing major tasks:
- Operating Systems Software;
- Program Products;
- Business Applications, Both Internal & Outside Feeders;
- Mainframe And Mid-Range Hardware;
- Internal Telecommunications - Hardware & Software;
- Internal Environmental Support Systems: HVAC, Electrical, Fire Suppression, Timers, Security;
- External Suppliers Of Service: Electrical, Fuel, Gas, Communications Carriers, Maintenance Providers of Hardware, etc.
As a footnote for those of you who have ever managed projects, this is the only project which you will ever run where the target date will not slip.
2. Inventory components in your business which utilize dates and take remedial action as appropriate. This process aligns well with the charter and role of a contingency planner. Particular attention should be given by you to internal environmental support systems and external suppliers of all services.
3. Ensure that both your disaster and/or business recovery plans are current and tested. If you do not have a recovery plan, develop one (see DR Journal, or visit their web at www.drj.com, click on vendors and then click on PC Based DR Planning Software).
4. Schedule your environmental support systems to have annual maintenance performed and tested prior to December. Fuel tanks should be filled and an agreement in place to receive emergency shipments within a predetermined period after notification.
5. Contact your suppliers of services and obtain written confirmation that they are in a Y2K ready condition, both internal and from their suppliers.
6. Read and understand the recovery service agreements you have in place with your recovery service provider(s). Understand what constitutes a disaster declaration and how that wording may restrict your ability to respond to situations commencing on January 1, 2000.
7. Verify that each and every volume is being backed up and rotated offsite, at least weekly.
8. Gain corporate acceptance that when your production cycle ends on the morning of December 31, 1999, that all systems remain inactive in a non-production mode. That is, no online systems come up and no batch. In essence, it is a non-processing day for your company, or worst case, a half day. During this time two (2) complete sets of backups should be taken of 100% of all disk volumes in your business. That includes: Mainframe, mid-range systems, servers and PC's. Hint: Order tapes.
I realize that this may be, at best, difficult to sell. However, I suggest to you that without these backups you have absolutely no sync point to go back to. The backups represent a snapshot of your business at the end of the century and is your security blanket. It is your corporate time capsule. Your ace in the hole. Should unforeseen date related problems permeate your application systems, it is the only collection of bits which will enable you to:
- Stop your processing
- Analyze the point(s) of failure
- Take corrective action
- Restore your system to pre-millennium status
- Give it another shot
9. Develop a strategy for bringing up your system after midnight and starting production. Do you want to power down before midnight, dry the system up or let it go full steam through the millennium barrier? Do you really want an automated scheduler to start firing off jobs?
10. Develop a plan to monitor the commencement of the new century as it rolls your way. Remember, with one exception, no matter what time zone you are in, date problems will manifest themselves elsewhere first. In the US, Easterners will hear from Europe and Westerners will hear 3 hours early from the Easterners.
11. Look at the benefits of having internal users in on January 1 or 2, 2000 to check the prior night's production runs, and to verify the onlines. Bluntly put, if any problems exist, I want to find them before my customers colorfully point them out to me on Monday. It's a far more attractive choice.
12. Ensure that both you and your management fully understand that, as a contingency planner, you are extremely limited in your ability to respond to internal date related issues come January.
Prepare For, Be Ready To Respond, And Rapidly Recover From, Unforeseen Events ( Y2K ).
After you have taken the aforementioned proactive steps, you now need to understand the conditions which could actually warrant a disaster declaration, and actual recovery, due to Y2K date related events. I suggest that there may be just two situations:
1. An external supplier of power or fuel is unable to do so because of a Y2K problem they have experienced (date related or not).
2. Your telecommunications carrier is unable to provide data circuits because of their Y2K problem or that of their supplier (date related or not).
The above two generalizations are offered as a wakeup call, and sanity check, on what your possible limitations could be. Furthermore, realizing that all recovery service agreements vary, and your business is unique to all others, you must work with your recovery service provider directly for clarification of potential limitations on your ability to declare a disaster.
The bottom line is:
- Ensure an active Y2K project is underway in your organization
- Be proactive in risk avoidance
- Understand potential limitations in declaring a disaster starting January 1, 2000
- Convey limitations to your management
- Take full volume backups
Far from a fatalist, I don't run with the optimists. I'm simply a realist who believes that long walks down short piers can either be ugly, or avoided. I suggest that avoidance in this case is far superior to the invigorating chill of the splash on the first, followed by the life of your company flashing before you as your business goes under. To that end: be proactive, understand the scope of your endeavor, identify risks and exposures, plan and take action, realize your capabilities, know your limitations, communicate and then communicate some more.
Norm Koehler, CRP, is Director of Recovery Services for Systems Management Specialists, Inc., a Technology Services Company. He is responsible for disaster recovery for eight (8) data centers, and other locations nationwide.