Owner`s manual

Failure Planning

• Plan for system failures. This includes hardware failures, software failures and operator failures. In order

to create an efficient application, you must put some thought into what you will do when different parts of

the system fail.

• Look for All Errors. Be sure your program is monitoring all possible error conditions that the Connection

Host may return to you. Error conditions are detailed in the next chapter. Don’t forget to program for

them; this is a common mistake. Failure to trap them can create unpredictable results and be difficult to

debug.

• Use the Test Program. Each Terminal come setup to use the default web-based test program. This is

hosted by Worth Data. The test program allows you to see how the system functions and whether you can

anticipate any system-wide problems. The test program can also be used as a response-time benchmark.

Hardware Failures

Let’s assume that each part of the system has failed. How are you going to know what has happened and

how are you going to recover?

• The most frequent failures are at the Terminal level. If a Terminal has a hardware failure, it will not be able

to SIGN OUT. It is possible for the Terminal operator to press the ON/OFF key or the F1 key by accident,

forcing the Terminal to SIGN OUT - sometimes in the middle of a transaction. This happens at battery-

charging time also. You need to plan for partial transactions - do you trash the data you do have and start

over, or pick up where you left off?

• Keep in mind that if a Terminal has SIGNED OUT in mid-transaction, the Connection Host clears any

pending message for that Terminal before it will allow it to SIGN ON again. Make allowances to re-send

messages or prompts that were cleared upon SIGN ON if necessary.

• If the Application Server or Connection Host has a hardware failure, the Terminal will not be able to

communicate with it. If the Application Server crashes and then comes back on-line, all terminals must

continue operating without re-signing-in.

Operator Errors

• Plan on your operator walking out of range and going to lunch in the middle of a transaction. What do you

do with the data you do have, and where are you going to start up again?

• Let’s say your operator is SIGNED ON and decides it’s time to take a break. Instead of pressing the F1 key

to SIGN OUT, he presses the OFF key. Pressing the OFF key is OK (it will SIGN him OUT) but there is a

delay until the SIGN OUT is acknowledged. Because of the delay, the operator might think he didn’t

press the key hard enough and press it again - this time actually powering down the Terminal before the

SIGN OUT was complete. If this happens, you need to plan to re-send the last prompt to the Terminal

when he SIGNs ON again.