Configuration for Site Specific Setup and Characteristics

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.

The values in the code provided apply to sample code from an ERP package called Integrity/Solutions which was based on Varnet and which has not been maintained for 10 years. In some ways, this makes it a good "bad" example, including source files with no extensions and a lot of trash in the source tree which would have been cleaned up if maintained by modern standards. The code for this application is located on my system in \work\IS with the database under the DB directory and the code under ISRel. It uses two databases.

Variables in Launcher
The tailorings should be fairly self-explanatory, but here is an explanation of the variables:

Variables for selecting files from source directories

Database and Schema Variables:

Propath for compile

Source Variables

Other variables

Note that for the directory lists, there is a positional correspondence. I.e., the first source directory will be compiled into the first run directory with the xref in the first xref directory and so on.

Menu, Menu Item, and Functional Unit Files
The mechanism for menus is inherently specific to the code base, but provides an important clue as to the functionality of the application because it is the mechanism by which a user accesses that functionality (or most of it). To make it easy to load the menu structure, ABL2DB uses three text files in export format to load the menu structure.

The first file is a list of all menus, not the items on the menu. This consists of

For batch programs and other functions not accessed by a user menu per se, pseudomenu entries should be created.

The second is a list of menu items, i.e., things that appear on a menu (or, in the case of pseudomenus, the items in that category). This consists of:

The link name is either the name of a menu (submenu), as in the prior file, or of a functional unit (see below).

The third file is a list of functional units. In our UML Profile for ABL, a Functional Unit is all code which can be reached from a particular menu selection. That is empirically constructed here by associating a name with the compile unit which is run by the menu item. We can identify the full Functional Unit by following the links from the initial compile unit to all include files and compile units run from or by all those compile units. This is obviously a natural unit of study when making changes to any menu item functionality. The file consists of:

This compile unit path is then used to find the previously loaded compile unit and link to it.

For any application with a data driven menu system, it should be reasonably straightforward to export files in the desired format. It may be necessary to supplement this automatic list with some manual entries to cover batch functions and the like which do not appear on a menu. For an application which has hard coded menus in the code (shame, shame) manual or other automated procedures will be required to create these input files. While one may start using ABL2DB with empty files, users are encourage to create valid input by whatever means since a functional unit is the basic unit for analysis in many cases and one will have to manually identify the appropriate compile unit instead, if no functional units are defined.

Program Descriptions
If they are available, it can be very handy to have even a short description of source code units. With some frequency (though varying quality), then is some kind of description at the top of some or all source code disk files. The exact position and the label, if any, identifying this description varies. The GetDescription.cls has been provided to extract these descriptions when they are available. The customizable portion is in the method ExtractDescripiton which takes a source file as input. It copies the source file into a longchar variable where its lines can be accessed with entry() using a newline delimiter. The supplied version looks for a comment on the first line and extracts everything following an initial argument and a space, which works for Varnet style code. This is easily adapted to look for a particular line or to search through the initial lines for a keyword such as "Purpose:" or "Description:".

SchemaUtilities.cls
This class has two methods which are appropriate for site customization. MassageMetaDBName is called when there is a table reference in which the table name begins with an underscore, i.e., a metaschema table. When these occur in code unqualified, the cross reference will indicate Analysis as the database since that is the first connected database. The standard version converts this to a reference to DICTDB to indicate that it might be any database. Qualified references to other databases are left alone. One might wish to change this default.

The other method is FindTableForBuffer which is intended to use local naming conventions to convert a buffer name to a table name. How easy this is to do depends on the adherence to standards in the code and the nature of the standards. The sample code illustrates a number of prefix and suffix standards. In the worst case, one might have to create a lookup table.

Not Yet Implemented Features
Note that there are a number of features, particularly related to schema, which are not yet implemented because I have no sample .dfs incorporating them to work from. Generally, these are things that are trivial to implement if I just have a sample, so let me know if you run into something with your own code base. In particular, on the schema side is support for non-OE databases and LOB fields.