Background

One of the biggest challenges in writing and maintaining Model 204 User Language applications is isolating and correcting coding errors or bugs. Many simple bugs are caught by programmers at the time of development or can be easily reproduced by a programmer in a development environment. These types of bugs can be isolated and the cause determined interactively by a programmer. Interactive debugging by a programmer is sometimes called ad hoc debugging. Ad hoc debugging can be done using simple PRINT and AUDIT statements or it can be done using an interactive debugger such as SoftSpy made by Information Technology Systems.

Unfortunately, many complicated bugs aren't caught in the development cycle and are difficult if not impossible to reproduce in a development environment. For these types of bugs, ad hoc debugging is essentially impossible and post hoc debugging must be used. Post hoc debugging is the technique of trying to determine what went wrong in a program after it has gone wrong with no possibility of interacting with the program at the time of the error. SirFact is a tool that greatly simplifies the task of post hoc debugging for User Language applications.

SirFact: Post Hoc Debugging for Model 204

SirFact essentially consists of three "components" ;

1. A component that aids in detecting errors as early as possible so it is easier to work back to the root cause of the error.
2. A component that collects extensive diagnostic information at the time an error occurs.
3. A component that allows post hoc viewing of the data that was collected at the time of an error. The collected data can be viewed any time after the error occurred and, in fact, can even be viewed in a different Online.

Detecting Errors Early

The earlier one determines that there is a programming error in a block of code, the easier it should be to determine the cause of the error (since the cause will be closer to the error) and the less likely it is that a bug can cause more severe problems such as data corruption. SirFact provides two mechanisms for detecting errors early.

The first mechanism is the "SIRFACT CANCEL" command that allows the trapping of return codes from $functions that are indicative of programming errors or severe environmental problems from which it is not worth trying to recover. For example

The second mechanism SirFact provides for catching errors early is a new User Language statement, the ASSERT statement. The ASSERT statement allows testing of environmental conditions inside a block of code to make sure that the code will operate correctly. Essentially, the ASSERT statement can be used to validate assumptions within a block of code. For example, a subroutine called UPDATE_CUST might require an 8 character customer ID and an update action between 1 and 6. A few simple ASSERT statements can validate these assumptions.

SIRFACT CANCEL and the ASSERT statement provide two simple ways to catch programming errors early and to eliminate the need to add User Language code to applications to deal with situations that shouldn't happen.

Collecting Diagnostic Information

Should an error occur in a production region, whether an error caught as a result of a SIRFACT CANCEL command or an ASSERT statement or a "standard" Model 204 error such as a SUBSCRIPT RANGE ERROR, SirFact has facilities to create SirFact dumps that contain the values of %variables, global variables, images screens, the location of the error and much more.

SirFact dump's are collected to Model 204 procedure files and are collected asynchronously, that is users other than the user that encountered the error can continue to run while the dump is being taken. Even the user for whom the dump is taken will only have to wait a few seconds for the dump to be taken since the SirFact dump mechanism is quite fast.

Analyzing Diagnostic Information

Once a SirFact dump has been collected it can be examined by a programmer to determine the cause of the error. An APSY subsystem is provided with SirFact that can be used off-the-shelf to examine Sirfact dumps. The $functions used to access SirFact dump data are also available to SirFact customer so that customized dump analysis utilities could be written in User Language as necessary.

Using either the provided subsystem or the $functions, a programmer can examine %variables, global variable, screen items, image items, $list items, the location in the procedure of the error, the error message that caused request cancellation and much more.

Summary

User Language bugs in production applications incur a huge cost at most sites that use Model 204. These costs include

• Lost end-user time because of incorrectly working applications.
• Lost support staff time trying to assist end-users in working around bugs.
• Lost or incorrect information in databases caused by application errors.
• Wasted support staff and programmer time trying to isolate the cause of an error with little or no information to work with.