Debugging ACL Scripts

Basic Debugging Steps If the script failed, check the log. The log will tell you on what command the script failed. If knowing where the script failed is not enough information, then double click on the script. This will give you some information on why it failed. LEFT: The red X indicates that the command EXECUTE FIELDS failed. RIGHT: A brief description of the problem is provided when you double click the X above. Sometimes the information provided is very minimal.

Common problems If the script failed, it is usually due to one of several common problems: 1) Incorrect field types used. Check to make sure that functions are being used with the proper field type. For example: STRING(characterfield,2) SUBSTRING(numericfield,1,2)

Common problems cont 2) Unmatched parenthesis/missing closing string delimiter: Check the number of quotation marks/parenthesis. These errors are common when a () or “” or ‘’ are not balanced: STRING(fieldname, 2 MATCH(fieldname, “value ) ASSIGN variable = ‘value

Common problems cont. 3) STOP ON NUMERIC OVERFLOW: A numeric overflow error generally occurs as a result of one of three reasons: First, if a calculation is divided by ZERO, then a numeric overflow error will occur. Second, ACL will only compute values with a maximum of 22 characters. If the value is larger than 22 characters, it will error out. Third, ACL sometimes has problems with numeric’s with too many decimal places. Ten or more decimal places may cause errors. NOTE: ACL does have a command “SET OVERFLOW on/off. If you set it off, the script will not error out, but will truncate values from the LEFT.

Common problems cont. 4) Crashed due to a PRESORT This error often occurs on a script that otherwise works without a problem, but for some reason ceases working. It is the result of a bug in the system. Sometimes when a script crashes or is aborted, this error appears. The solution is simple, close and restart ACL.

The Script works, but produces the wrong results Most people have experience trouble shooting scripts that error out. Trouble shooting scripts that work, but produce incorrect or incomplete results is much more challenging to figuring out. There are several different techniques that can be used to identify problems when the code works, but produces the wrong results.

Limit Size of File When trying to debug scripts, it is generally better to limit the size of the file that you are working with. You do not need a file with 10,000,000 records when 10,000 would suffice. For this reason, when writing scripts, it is often advisable to perform an extract from data to obtain a sample population.

Step by Step One of the most powerful ways to test a code is to run the code manually on the COMMAND LINE of ACL. This can be time consuming process, but it allows the programmer to validate results at every step. If the command line does not appear on your ACL project select: WINDOWS> Show Command Line

SET FILTER/Quick Filter/ Quick Sort The use of a these commands can be a simple and quick method for evaluating the accuracy of a test or for determining the correct syntax for a piece of code. Using these commands can help the programmer determine if there are records that fit the expected criteria. Once records are identified, the programmer can use those identified cases to add logic to capture them.

Forcing Values Often when running scripts, one will have a variable that is utilized in the execution of the script. This might be a simple count, a computed value, or an item from a list. Often it is beneficial to over-ride this value and force a value into the system to see how it reacts. Does the script produce the same results or have they changed? Is the change appropriate?

Isolating subprocesses Often times the problem with a script centers around one step or one phase. If you can identify this step/phase, you can isolate it to test independently. This has two advantages: First, it enables you to see what happens with the section in question as you make minor tweaks. Second, you can bypass the section in question and see how the rest of the script behaves. This is an opportunity to force values into the script to test the results under a controlled situation.

WORKSPACES Workspaces are a powerful tool when trying to debug a script. It allows one to define a field on one table and then recreate the same field on another table. This allows for quick easy comparing of data/results between tables.

PAUSE Pause is a tool that can be utilized to explore the execution of a script. Using a PAUSE command will allow the programmer to know where the status is on a specific script. This is particularly helpful when exploring DO … WHILE or ERROR TRAP scripts to ensure that there is a working escape.

RELATIONSHIPS Relationships are a simple method to join two tables to determine what might be happening in a script. Creating a relationship can be done through the ACL GUI. Select DATA > RELATE TABLES

Creating a Relationship ACL will then pull up the parent table that is to be used in the relationship. You then select the specific table you want to connect to via the “Add Table” button. Then select the items to be matched via the relationship. Relationships can only be formed on primary key fields (no secondary fields). Note: A parent table can only have 17 related tables (either directly or indirectly.)

Using a related tables Once the relationship is created, one can add fields from the child table to the view. This allows for a quick comparison on how the fields are actually relating to one another. If there are no values, then that is an indication that the fields used in the relationship are not the same.

Using a related tables 2 If the fields are not the same, the first thing one should do is determine why are they different. Using the ACL Wizard to JOIN tables will allow for quick comparison between the table formats: NOTE: The AREA fields have a different length on these tables, thus would have to be edited to get a join/relation to work.

Using related tables 3 Once the relationship is working, you should determine if the script was properly written correctly or does it need to be modified. If the script was written correctly, the related fields can now be used to validate the results being generated. Are the values correct? Do they need to be refined?

REVIEW TEMP FILES The power of using the TEMP01 – TEMPXX convention is that it allows for easy review of the temporary files. The numeric presentation of these tables allows the user to determine which temp file was created first, then second. A quick review of the temporary files might indicate where a logic problem originates.

EXTRACT One of the best ways to determine why a script is producing incorrect results is through the increased use of EXTRACT commands. These extracts allow the programmer to review the data at various stages of execution. Using the FIRST parameter allows you to limit the number of extracts, thus minimizing the impact on the execution.

SET SESSION Allows for the creation of “Sessions” within ACL. These Sessions will tag the LOG with a title that can be used to determine when a new process is being run. This can be used to help identify where in the script errors occur.

SET LOG The use of a SET LOG command is very similar to the SET SESSION command. It is a means to identify the processing of a script at different points. The difference between a SET LOG and a SET SESSION command is that the SET LOG command is more appropriate when using a DO … WHILE combination or when the same script is repeated for different parameters.