Problem solve Get help with specific problems with your technologies, process and projects.

The Lazy Coder: Disaster recovery programming

Take steps now, while you have power, to make sure the company and users are able to function in the event of a disaster.

As I sit here watching hurricane after hurricane (after hurricane!) bear down on the state of Florida, I wonder what could I be doing to ease my disaster relief within my programs? This isn't just a game of keeping the UPS going, testing the generators, making sure the backups are kept off site or merely boarding up the building as is the need with a Hurricane looming. That stuff is KID stuff. What can I do to prepare my PROGRAMS? The game is trying to survive WITHOUT a computer, then update it when the lights come back up. So, how do I do that WITH a computer?!?!

Life in horse and buggy times

My reports are a CROWDED mess. I cram as MUCH as I can on one page, making sure the eyes are strained, so the printout looks like one big black sheet of paper. Now the problem: THAT report may be the ONLY one I have while waiting days or potentially weeks for my electricity to turn back on. What can you do to ensure your survival? Make sure you have accurate information.

In this day and age of paperless this and paperless that, I may need that paper because planning for life without power is HARD. Say I'm a company that has inventory that could be sold after the danger has passed and customers knock on my door and I need to reopen. Now what? How do I maintain inventory without a computer? Well, what did we do before we had computers? This stuff may need to be kept in PHYSICAL form! Computer archives are great, but frankly without power they become hard to work with. And when the power loss can be hours or even weeks, sometimes both the UPS and the generator may run out of juice.

More Information

One thing to do is assign one person as your point person for specialized information on that report. Contact that person and say, "Update such and such with the new information." Great, now you've got that covered. But remember you crammed everything into that report. OK -- SPACE, the final frontier -- open up that report so you can jot things down, highlight lines and eventually update your backend system with that information.

But we're not done yet. You may have other recovery jobs you need to do, such as transferring customers to other sections of the company or merely keeping accurate information of the accounts affected. You'll need to write many reports to gather up customer information. Those reports need to be easy to update by hand, but you may need to store those subsets of information for later recall by programs. These "disaster work files" will need tons of additional information within them, including MANY flags per customer so you can indicate if certain activities have been completed.

You may also need to give translation information within these files. I had an instance in which I had to transfer hundreds of customers from ONE disaster to another store. That was a unique computer, with a unique set of files. All of the customer numbers were going to change, but luckily they never knew that information. My file was as follows:

       TYPEINF                 text               Type of Information Translating
        INFOOLD               Varied          Keyed Information OL
        INFONEW              Varied          Keyed Information NEW
        FLAG001                2 Alpha        Flag 001
        FLAG002                2 Alpha        Flag 002

I created an index over the TYPE of information and INFOOLD -– and a logical file over TYPEINF and INFONEW -– so now, I can look up the OLD and translate to the new or lookup the NEW and translate to the old. It's a SIMPLE solution to a complex problem.

We're NOT done with our recovery, though. When the power comes back up, we have things we need to update from records that were MANUALLY entered using the world's OLDEST word-processor -- the pen. Your programs need to have a RECOVERY mode. This mode will allow you to enter data that was, up until this point, provided to the users. This will need to be a secured function, and VERY few people should be able to do this. So, you assigned a unique number of transactions while your power was out. "Hey," you say, "How did you do that without a computer?" I'll give you some ideas; however, this will need to be a "salt to taste" procedure, as is the case with any recipe.

How to generate a unique number when there's no power

  1. Counting machine –- These are devices that require no power that simply add one to a number. Want to go even lower tech? Assign one person as the "unique number" person. That person needs to keep track of what numbers were assigned. Tick marks on a page work as long as there's ink! This number needs to be big enough to handle your requirements for a few days -- 1,000, 10,000 100,000 -- whatever the amount of numbers you need to keep free for a few days of unique numbers. Maybe longer!
  2. Place the following information on the LEFT or the RIGHT side of the equation (your preference!):

    1. Office ID
    2. Department ID
    3. Date
    4. Time
    5. That Unique Number we created in the first step

Once there, you now have something to assign that may not interfere with existing information stored. When the power comes back up, enter this information where the computer would have assigned it automatically. "Hey! This is going to take more planning -– my fields aren't big enough," you say. Yup! Plan now while the power is up, the coffee is hot and the adrenaline isn't flowing. You'll need to plan while you're calm and react with a plan in hand when the chips are flying.

Now, isn't that the height of laziness? Plan NOW so you don't have to waste energy when you don't need to. And now back to my 2,000th game of bridge while I wait for the power to return.

About the author: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is often a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.

Dig Deeper on iSeries disaster recovery and business continuity

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.