The State Table provides a persistent memory method of recording and retrieving information associated with and organized in terms of the steps of analysis. As the user makes choices or answers questions, “user response” variables, either string, integer, or real, are stored to the State Table. The contents of the memory State Table are typically written to the database at the conclusion of each analysis step by means of the AASTATE.store_objectives() call. This allows a restoration of the current modeling state upon closing down and then reopening of a database.

State Table recorded values are used for logic control of the analysis workflow. Step completion indicators are stored as the single character string variable “complete” for each step. The processing of automated link rules on the XML “drive pages” uses the State Table.

The state table is designed to organize stored data in terms of two sorting parameters (1) an analysis process step ID (4 characters or less), and (2) a string character name designated as a “variable name”. In general, this scheme serves well for a Tutorial applications because the analysis process itself is organized in terms of steps. It is advantageous to use a common “variable name” such as “complete” as the step completion indicator for each step. Storing many of these values under the same “variable name”, but for different “Step IDs” keeps them all separate and unique.

A difficulty arises when PCL automation functions that make use of data values read in from the state table are targeted for reuse in other separate Tutorial applications. The key process steps that store the values required for subsequent use in the automation functions may not have the same IDs from application to application.

Two simple techniques have been employed to resolve the automation function reuse difficulty: (1) use of a fictitious Step ID, and (2) storage and use of a pointer value to the required Step ID.

To use the first technique, simply store the particular values as required by an automation function to a “Step ID” that does not correspond to any real process step. The state table does not care whether or not the ID corresponds to any real process step. It simply stoes and retrieves by the ID name that you give. To do this, use the AASTATE.overwrite_ur... type call functions as opposed to the AASTATE.record_ur... type functions. The only difference is that the overwrite_ur... type functions take an explicit input call argument for the Step ID. The record_ur... type functions do not take a Step ID argument. Instead, they automatically use the current process Step ID when storing data for convenience.

The second approach is more elegant. The application is written so that certain Step ID pointer values are initially stored in an agreed upon Step ID, say “1.”, or in a fictitious Step ID name like “ids”. Stored in association with this special agreed upon Step ID are variables holding the particular Step ID values where certain key operations take place. Subsequent execution of the key process steps then results in State Table storage of the particular data variables naturally associated with those process Step IDs as programmed by the application author. After finding the key Step ID pointer values stored associated with the special agreed upon Step ID, any subsequently executed automation functions will know which Step ID to retrieve their required data from.

For example, initially store the string Step ID value of “3.” in the variable name “meshstep”, and the value of “4.” in the variable name “loadstep”, both associated with fictitious Step ID “ids”. Having accomplished this, any subsequently called PCL automation function can call the State Table to obtain the values assigned to “meshstep” and “loadstep”, associated with the fictitious Step ID “ids”. The reuseable function then knows to retrieve the required storage values from Step IDs “3.” and “4.” for this application. When the very same PCL function is reused in a different application, the Step ID value retrieved from the “meshstep” variable could be something different like “7.”, and the value from “loadstep” might be “10.”.