This group exists to provide targeted notifications for those interested in ABL2DB or ABL2UML.
Bugs and Feature Requests
Please post report bugs and feature requests on the ABL2DB & ABL2UML Forum rather than adding comments here.
Membership
Join the group by using the My Membership link at the bottom of the second set in the right margin.
Contents
The following topics are related to this group:
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.
0.50 - Initial Release
0.51 - Parameterize overall log location in variable
0.52 - Clean up GetDescription logic
0.53 - Fix separator bug in BuildRunLinks.cls
0.59 - Add M support for LOB-SIZE and LOB-BYTES
- Support TABLE-TRIGGER
- Support N separate DBs with their own schema
- Support DB in table links
- Support DB Connect params (including live DBs)
Having started to use Proparse as a part of ABL2DB, I have created several utilities for Proparse, either to call from ABL2DB or to provide information to use in development of ABL2DB. Since these utilities might be useful to someone doing other development with Proparse, I am documenting them here. For now, they are available as a part of the ABL2DB distribution. If there was demand, I could package them separately. All are published in the com.cintegrity.Proparse package.
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.
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.
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.
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.
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.
This page is intended to provide recognition for people who have contributed to the development of this utility. I will probably forget someone, for which apologies are offered, but I will try.
This section is intended to provide information on various questions which have come up in the use of this tool.
In addition to targeted queries related to specific enhancement or maintenance projects, we will be exploring a number of possible analysis functions including:
Some of the items on the roadmap include:
See below for pre-1.00 log
1.01 - Initial Proparse release. Includes tracking of shared variables
1.02 - Convert to case insensitive GUID keys
1.03 - Add all shared object types - buffer, browse, dataset, frame, menu, query,
stream, temp-table, variable, and work-table.
1.04 - Change compilable test to look for XREF
1.05 - Add Proparse buffer tracking to BuildBlocks to resolve buffer names to
tables
1.06 - Bug fixes in BuildBlocks
To run ABL2DB one runs launcher_abl2db.p whose configuration is discussed in the Configuration section. it sets up the overall log (one can add additional tracking if desired for debugging), creates the Driver class, initializes the Driver class with the configuration values, and then executes the Initialize() method which tests some preconditions, and the Process() method which does the actual work.
The primary tailoring occurs in the launch program, abl2db_launcher.p which is found at the top of the src directory. At the top of this program you will find a section of variable definitions labelled Application Specific Definitions. You need to edit the initial values for these definitions to match your application.