While it is possible that fancier and more sophisticated reports and inquiries will arise on top of ABL2DB over time, not the least of which is its possible role as the front end for ABL2UML, it is likely that the bulk of analytical report for ABL2DB will be specific, project oriented programs. Fortunately, they are also likely to be quite simple. Therefore, the samples presented here are not fancy works of art, but very simple little programs designed to get the desired information with as little development effort as possible. In particular, they are all simple .ps so they can just be run, modified quickly, and run again. In all cases the relevant parameters are at the top of the program so one can easily pick different functions or schema elements or whatever to report on without altering the program. But, if any different information is desired for any particular report, then adding the information should be simple as well.
I hope that users will contribute their own reports so that we will build up a library to make it easier for people to get started with ABL2DB.
We all know how important buffer and transaction scope can be to the proper operation of an ABL program. We have COMPILE LISTING to show us these scopes, but many programmers are either unaware of the tool or seem to forget to use it to check their work. But, this information is critical to understanding many issues of many problems. Here is a program which starts with a particular FunctionalUnit, i.e., one menu selection or batch program which performs some function in the application, links to the main compile unit which is run to perform that function, and then follows the links to all of the compile units reached by those compile units. For each compile unit, it shows the blocks which either have transaction or buffer scope and what that scope is.
The report function and some sample output is provided.
Build a calltree starting with a diskfile record. Only procedure calls are logged, currently (oe 11.5.1) xml-xref does not provide nodes for function calls like 'RUN' for procedures. The report has a .p extension, purpose is to provide clickable links to files. Of course the propath has to make the clickable link possible.
Contributed by Stefan Houtzager.
With the advent of the INT64 datatype, there can be the desire to change the datatype of an existing database column of type integer to type INT64. When this is done, it is desirable to examine the code where this column is referenced to see if there are local variables which also need to be changed.
This report starts with a designated database column and finds all of the references in code where that column is used.
The ABL code and a sample report are provided. The IntRefs_James sample is from James Palmer examining the proposed change of their customer number to INT64.
One of the common tasks in modernization is replacing the use of shared variables with explicitly passed parameters or references to persistent procedures or objects.
This report starts with a particular FunctionalUnit, i.e., one menu selection or batch program which performs some function in the application, links to the main compile unit which is run to perform that function, and then follows the links to all of the compile units reached by those compile units. In each of the compile units it shows all the shared variables and whether they are declared new. The report shows when the variable is assigned to or assigned from and flags any that are neither as unused.
The ABL report and a sample output are provided.
In the course of evolving an application, it is not uncommon for database columns to be added in anticipation of some change that never happens or for once used column to be replaced by other schema or even for whole tables to be abandoned because the functionality they supported is no longer needed or relevant. These columns present no actual harm, but may be confusing since one assumes they are used, especially since they may contain legacy data from when they were used.
This report starts with a particular database and examines all of the columns of all of the tables and looks for references in compile units. If there are more than a specified number of references, the column is skipped. If there are no references or less than the specified number, the column is reported. In the sample report, a limit of 1 is used on the theory that a column which is only referenced once may not be useful
The ABL report and sample output are provided. The UnusedDB_James is from James Palmer.