Medsphere’s “%” routine contains a dozen APIs to help programmers with routine transfer and version control. All these APIs are intended to work in any Kernel environment -- VA, IHS, or Medsphere. A routine extract of the % utility is attached to this document for convenience.
A. Routines in “.m” format
OUT^% Sends MUMPS routines out to a file directory (“path”) in GT.M format, as individual “.m” files. User specifies path and routine set.
COMPARE^% Compares routines as stored in a file directory (“path”) in either GT.M or Cache format with routines on file in the current namespace, in side-by-side ‘diff’ format. If the same path contains both kinds of routine saves, the user is asked a question like this:
INPUT PATH: D:\R\
Select one of the following:
1 CACHE FORMAT (.RSA)
2 GT.M FORMAT (.m)
When comparing GT.M routine files, the user can list individual routines, or use wildcards (e.g., “DI*”). When comparing Cache routines, the user simply chooses the “.rsa” file that holds all the routines.
IN^% Reads in and files MUMPS routines from a file directory (“path”). Routines are expected to be in GT.M format, as individual “.m” files. User specifies path and routine set. User can list individual routines, or use wildcards (e.g., “DI*”)
B. Patch numbers on second lines of routines
ONE^% Looks for an individual patch number on the second lines of a specified set of routines. Patch “number” can be non-numeric, like “MSC”. User specifies routine set, and output is a list of the routines on file in the current namespace that have that patch number.
VER^% Looks at all the patch numbers on the second lines of a specified set of routines. Patch “numbers” can be non-numeric, like “MSC”. User specifies routine set, and output is a list of “numbers” (e.g., “1-3,8-22,24-888,MSC”)
C. Comparison across namespaces
ROUCI^% (or simply ^%) Asks for a list of routines, and compares them from the current namespace to another one, in side-by-side ‘diff’ format.
DD^% Asks for a range of File numbers, and compares those files from the current namespace to another one, in side-by-side ‘diff’ format. Comparison can be either:
DATA DICTIONARY ONLY
FILE ENTRIES ONLY
DATA DICTIONARY AND FILE ENTRIES
MSC FileMan offers this same functionality as sub-option 3 of the TRANSFER Option.
BUILD^% (or B^%) Asks for a KIDS Build in the current namespace, and uses the definition of that Build to compare routines, files and file definitions from one namespace to another one, in side-by-side ‘diff’ format. The two namespaces being compared can both be different from the current namespace. Thus, for example, two unmodified FOIA releases can be compared with respect to the components of a particular Medsphere Build.
TEMPLATE^% Does the same thing that BUILD^% does, but for an aggregated group of Builds, rather than a single Build. The Builds must be stored in a pre-existing SEARCH TEMPLATE for File 9.6. User is asked to select the Template.
INSTALL^% (or I^%) Asks for a loaded KIDS Install in the current namespace and uses the definition of that incoming Build in the same way as BUILD^% (above) does.
FIND^% asks for a routine name, and looks at all namespaces on the machine to see whether that routine exists in any of them, and, if so, howmany bytes big it is in each instantiation. If your current namespace does not contain the routine, you’ll be switched to one that does.
KIDS^% is intended to facilitate the updating of databases with new patches from the VA.
The premise is that the patches are loaded into a patched-up “Gold” account (namespace). The goal is to select a recent, needed, patch from there, and see how much work there will be to integrate that patch into a target system that has been customized with Medsphere fixes/enhancements.
Example Use Cases
The FOIA namespace used in the examples below, represents the “Gold” – pure VistA unmodified. The MIDLAND namespace represents a target system. A third namespace, MFOIA, represents the version of FOIA VistA distribution originally used when creating the MIDLAND namespace.
First example: we go into FOIA to investigate a recent patch called “IB*2.0*309”
KIDS^% confirms that this patch is not already in MIDLAND. Then it tells us that two of the REQUIRED BUILDS for this Patch are NOT installed in MIDLAND. Note that there are actually 18 Required Builds defined by this patch, but 16 of those 18 exist over in MIDLAND already. So the prospective job is just to install IB*2.0*260, IB*2.0*287, and then the desired Build IB*2.0*309.
Now we can check the “delta” for these three builds, the difference between MFOIA and MIDLAND, just with respect to the routines, data dictionaries, Options, etc that these three patches bring in.
The screenshot shows an ideal situation, which is that none of the components of these three Builds have been modified from their state in MFOIA. This verifies that we can go right ahead and apply the three patches into MIDLAND without worry that we would be clobbering modifications done in MIDLAND.
Second example: we do the same thing for a different Patch, PSJ*5.0*112.
Here the screenshot shows that we have a slightly more difficult situation. PSJ*5.0*112 presupposes only one other patch that is not already in MIDLAND, ‘PSS*1.0*86’. However, when we look at these two patches, we see that they include the routines PSGOEE and PSGOETO, and these two routines have been changed since “MIDLAND” was modified from “MFOIA”. That means that when we install PSS*1.0*86 and PSJ*5.0*112 in MIDLAND, we are going to have to then retrofit these changes into those two routines.
