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
Note: A parent table can only have 17
related tables (either directly or
indirectly.)
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).
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.