Worth Data 7000 manual Failure Planning, Command without an ID, Hardware Failures, Operator Errors

Command without an ID

All of these error conditions are detailed in the next chapter. Don’t forget to program for them; this is a common mistake. Failure to trap them will give create very strange, unpredictable results.

Even though you don’t think your code will ever make a mistake, take advantage of feedback that the Base Station provides. Failure to do so is a common mistake that eventually results in serious program failure, sometimes due to hardware problems that go undetected.

•Parse the Returned Strings thoroughly. Don’t assume anything about the next response from the Base to your program and look only for the partial string such as the ID only; parse the string returned completely and be sure you are examining every possibility. Failure to do so is a common mistake.

•Plan for expansion. You may start small (1 base/1 Terminal) but try to create an application that will allow for easy expansion and addition - especially of Terminals.

•Use the Demo Programs. The demo programs can at least allow you to see how the system functions and whether you can anticipate any system-wide problems. The demo programs should also be used as a response-time benchmark.

Failure Planning

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 Base Station 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 a Base Station has a hardware failure, neither the Terminal nor the host computer will be able to communicate with it. When the Base Station comes back on-line, it sends a “Base Station Initialized” message back to the host, letting the host know that it must re-initialize all Terminals and pick up any incomplete transactions.

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-sendthe last prompt to the Terminal when he SIGNs ON again.