Last week we started to look into XINDEX utility as a tool to characterize VistA Mumps codebase.
XINDEX is a Mumps routine which parses and analyzes all the routines in VistA install. The analysis includes a variety of useful information, including:
- Errors and warnings for the code based on Mumps language and SAC (The Department of Veterans Affairs M Programming Standards and Conventions)
- List of all calls to other routines
- List of calls within the routine
- Global and naked global usage in the routine
- Local variable usage in the routine
In addition to routines, XINDEX also looks into package specific VistA file items that store Mumps executable code termed as “faux routines” in XINDEX output. We are not sure yet if the items that XINDEX looks into are the complete list, but looking more closely into “faux routines” will need to be part of the characterization of the Mump codebase.
The main task we concentrated on this week was listing all module to module dependencies. XINDEX already provides a report containing the routines that other routines and faux routine call to; our task was to convert this information into a module dependency map.
For this, we did not use XINDEX output directly. XINDEX stores all its analysis internally in a global called ^UTILITY and this global is used to generate the actual output reports. In our case, the global was much more useful than the reports so our first step was to modify XINDEX code so that it became “silent” (no writes) -- we specified the input parameters programmatically to XINDEX and used ^UTILITY to extract the information we needed.
To be able to specify module dependency map, we needed to know which routines belong to which modules; for now we are using Package file in VistA (#9.4). We decided to go this route because XINDEX itself uses this file to identify faux routines. This file appears to include all the namespaces: the first few letters of the routine names which identify the package the routine belongs to. It is our understanding that Package file is kept up-to-date, but we need to better understand how the packages relate to modules as defined in the OSEHRA architecture document. In fact, there have been some discussions on weekly architecture meetings on the very same topic. It looks like some of the documented modules are not in the OSEHRA VistA release, but rather some of them are merged, etc. We will try to clarify this for VA before characterization is complete.
We ran our modified version of XINDEX for two modules. Oncology (ONC) and Problem List (GMPL). The results are as follows:
ONCOLOGY depends on: REGISTRATION, VA FILEMAN, PROBLEM LIST, DRG GROUPER, UNKNOWN, MAILMAN, KIDS, KERNEL
Nothing depends on ONCOLOGY.
PROBLEM LIST depends on: REGISTRATION, VA FILEMAN, HEALTH SUMMARY, INTEGRATED BILLING, DRG GROUPER, LEXICON UTILITY, ORDER ENTRY/RESULTS REPORTING, PAID, PCE PATIENT CARE ENCOUNTER, SCHEDULING, UNKNOWN, LIST MANAGER, MAILMAN, KIDS, KERNEL
The following depends on PROBLEM LIST: DIETETICS, HEALTH SUMMARY, NATIONAL HEALTH INFO NETWORK, ONCOLOGY, ORDER ENTRY/RESULTS REPORTING, PCE PATIENT CARE ENCOUNTER, CLINICAL CASE REGISTRIES, TEXT INTEGRATION UTILITIES
For Problem List the dependencies are similar to what is listed in the OSEHRA architecture document which has the same dependency information gathered directly from VistA documentation. There are some differences however, and Oncology dependencies are not listed in the architecture document at all. Once we clarify package/module namespace information, we will get back to these dependency maps and manually verify a number of them for quality assurance.
By the way, UNKNOWN refers to calls to or from routines that we could not automatically identify from Package file. There were about 500 of these routines and about 100 of them are routines that have names that start with “%” which we can classify as KERNEL for our purposes. Here is a sample set of other routines that our automated process could not identify to belong to a module: A1B2OSR3, A1CKC1, ALPBFRM1, AUPNPAT, AWCMCPR1, GMVBP0, VDCVAL, IMREDIT, MXMLDOM, and YTPXRM. Again, once we clarify package/module namespace, we will get back these routines.
In the next few weeks we will continue to characterize VistA Mumps codebase. This will also be in the context of module-to-module dependencies. These are some of the characteristics we are after:
- Usage of Mumps Goto from one module to another
- Assumed parameters for Mumps Do calls to other modules (Actual List vs Formal List)
- Direct global usage within modules and ownership of those globals
- Usage of Mumps Xecute command
- Usage of indirection
XINDEX provides a good foundation to explore these, but we will need to add some additional functionality. For example: XINDEX does not differentiate between Goto and Do for its analysis on calls from one routine to others…we will have to. Maybe XINDEX improvements can become our first contribution to codebase. Of course the third line of XINDEX says “Per VHA Directive 2004-038, this routine should not be modified”...but that is a discussion for the OSEHRA certification team.