As with the VACs, careful program flow planning ensured that there should always be enough free core sets for the running programs to do their jobs-except when suddenly there wasn’t. The second alarm that appeared, 1201, was of the same type-this time, it was "Executive overflow-no core sets." Somewhat similar to VACs but simpler, the core set area of the guidance computer was used to store all the necessary information about each running program in the guidance computer. This proved enough to deal with the problem. This restart included a flush of all the temporary storage areas (like the VACs), and at the same time the computer made sure to continue tracking the LM’s state vector-that is, its position and velocity relative to its current reference point. The "BAILOUT" restart routine killed all of the computer's running jobs, then had the Executive call up its prioritized table of what it was supposed to be doing and automatically picked back up its tasks, one by one. When the 1202 alarm went off, the Executive initiated the first and least-disruptive of its three restart modes to try to fix the problem: a "BAILOUT" restart. The guidance computer’s program flow was carefully designed so that it was ordinarily impossible to run out of this kind of temporary storage-and yet, because the computer was busier than should have been possible, it happened, and the alarm sounded.
The first program alarm was 1202, which translated to "Executive overflow-no VAC areas." "VAC" in this context means "vector accumulators," which are unswitched memory areas that store temporary variables for interpretive instructions.
0 kommentar(er)
