finding a non-zero invoice number on the screen corresponding to a zero entry in the table, and so forth, a change (cont.)
might be indicated by finding the same invoice number on the screen for its corresponding table entry, but with other (cont.)
values on that line altered from what was in the table.
## Beware - Avoid a Deadly Embrace
A potential problem in any multi-tasking systen you should be aware of is called "Deadly Embrace". Here is what it (cont.)
means: a task is waiting for a resource that is held with exclusive control (i.e. read for update) by another task that (cont.)
is waiting for a resource that the first task is holding, As a result both tasks are in an endless wait status. Both (cont.)
tasks may even be the same program. MAGEC generates MMP's With a keen awareness of this classic danger and a problem (cont.)
like this may never, or very rarely, occur among MAGEC applications. But, your ability to do virtually unlimited (cont.)
customization--including calling non-MAGEC programs--makes it impossible to eliminate every possibility for (cont.)
error.
The tasks may be MAGEC-generated MMP(s), other programs, or any combination. The resource being held may be a file, a record, an element, or any other resource.
The best way to make it as unlikely as possible for the problem to occur is some simple standards.Obtain exclusive (cont.)
condtrol (i.e. read for update) as late as possible in your procedureRelease it as early as pssible after no longer (cont.)
neededAlways do either an implicit (i.e. UPDAT) or explicit (i.e. RELES) Process in a predictable order (i.e. key (cont.)
sequence) in all tasks
Of course, a task can get exclusive control over other types of resources (i.e. main memory storage) that you might (cont.)
have little ability to control, but file or database I/O is the type you will most likely be involved with and these (cont.)
simple standards might afford you the luxury of *never* being involved at all.