During the earliest phases of VA MUMPS development, the software consisted solely of MUMPS routines and MUMPS globals. Simple routines were developed for exporting and importing routines, and for exporting and importing globals.

Once the system was given official status, and development could begin in earnest, VISTA's Fileman application became available to all parts of the system. From this point on, the software could be defined as MUMPS routines plus Fileman files. “Files” in this context mean any sort of program element that is not a routine: a data structure or field, the contents of a structure or field, or a combination of both structure and contents.

In order to deal with the new, more powerful structures supported by Fileman, a new program was created: DIFROM. DIFROM routines package up files into routines called INITs - self-extracting files. Even then, some basic parsing was allowed - decisions could be included indicating what to do if the receiving system already had data, or behaved differently than the sending system. Pre-inits and post-inits could be created and transported, but had to be manually coded.

The key factor necessitating the introduction of KIDS was the limitation of using routines for transport between systems. Routines had limitations of both name and size. KIDS provided a new framework, still using DIFROM functionality at its heart, but packaging routines into globals, which had no limitation in name or size. It also added strong built-in capabilities for adding instructions on both ends of the transport. KIDS is a logical part of the Kernel (hence its name, Kernel Installation and Distribution System). The Kernel package is where options, protocols and remote procedures reside within VISTA. KIDS fully supports transport of 24 different types of program element, and manual programming using KIDS allows for ad hoc transport of unsupported program element types.

The key take-away is that the output of KIDS - the complete, exported transport global, called a distribution - is designed solely for the use of a receiving KIDS module. There is much that does not need to be explicitly stated in a distribution, since the packaging, sending, receiving and installing logic is built into the VISTA system. A distribution is no more meaningful, outside of the context of the system it is meant for, than a series of directions would be, without knowing the intended starting and ending street addresses.

The current deficits of KIDS:

  • Transportation of elements that do not fall into the current 24 defined types still requires manual intervention.

  • KIDS does not currently capture information about distributions created. An install log records distributions received, but no matching outbound distribution log exists.

  • Currently, distributions are created in two formats: Mail message or OS file. The two are not identical.

  • At its current state of evolution, VISTA only supports the backing out of routines after transport and install, but not other program elements. This prevents full recovery to the prior state if an upgrade does not perform correctly in the target environment. This turns what could be a minor administrative task into a major undertaking.

  • VISTA does not currently support output of package elements in version-control friendly formats.

Recommended improvements to KIDS (upgrading KIDS, adding SKIDS):

  • Create standardized human-readable output formats for package elements, beginning with those that are currently handled programmatically by KIDS. These could be output on demand for version control.

  • Institute a distribution log (a counterpart to the existing install log). Create a standardized human-readable format for automatic log entries in both the distribution and install log.

  • Create a standardized human-readable output format for the build file, to be output upon creation of a distribution.

  • Standardize the process for output of distributions to remove differences between Mail and OS versions.

  • Add extensibility for KIDS, so that additional functionality for transport of globals can be added dynamically.

  • Add the capability of backing out package elements, to allow for full recovery from an upgrade install failure.

Important terminology:

A KIDS “build” is just the “shipping manifest” dictating which program elements are to be transported, including some screening and parsing. A copy of this is included in the distribution. The build all by itself is only a recipe for the total information to be exchanged.

A KIDS “distribution” is the completed and exported transport global. This will include the build, the program elements specified in the build (many extracted and packaged using difrom routines), plus the environment check routine, and the pre- and post-install routines. The pre-transportation routine, which is executed in the sending system, is not incorporated in the distribution.


© 2011, Carol Monahan and Frederick D. S. Marshall.

This draft is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License (




What about taking a semantic web approach to SKIDS?

Tom Munnecke's picture

A bit of additional history, somewhere between DIFROM and KIDS, I worked on a notion called PackMan, that communicated via FileGrams.  I used this over the SMTP link for the March AFB/Loma Linda VA integration system, which was very similar to the Direct program today.  

Maybe this has already been done, but have you considered taking a semantic web approach to managing the metadata we are talking about?  This would entail defining things in RDF which would also give us the ability to use SPARQL to query and manage them, perhaps as a Triplestore data repository.

It would be good to start incorporating more sophisticated metadata/semantic web technologies in our thinking, and this might be a way of dipping our toes in the water...