I. INTRODUCTION

The FileMan DBMS used in the Department of Defense's CHCS Hospital Information System was derived from the same MUMPS system used in the DVA's DHCP program since 1982. The two "FileMen" began diverging in 1986, when CHCS development began. At that point, the version number of FileMan in the VA was Version 17.

The version of DHCP FileMan that will be studied in this document is denoted as "Version 20". It was fully deployed in the VA in 1994, when this study was begun. A more recent "Version 21", released early in 1995, will occasionally be mentioned here, when it differs from Version 20 in some way relevant to the discussion.

The current deployed version of CHCS FileMan, and the one discussed here, is denoted as "Version 25".

In many particulars, the two "FileMen" have evolved, as one could say, in parallel.

For example,

• "MUMPS" and "VARIABLE-POINTER" data types were implemented in both systems, in virtually identical fashion.
• Both systems have been changed to support a Print Header specification of "@@", which means "no page break at all".
• The FileMan module which is used to parse and validate strings of MUMPS code (the "^DIM routines") have been independently changed to support the 1990 MUMPS Standard syntax. (But note that neither system supports the "1995" syntax currently in preparation.)
• Certain Entry points, like MIX^DIC1, have been added to the programming-call repertoire in both systems.
• Certain programming variables, like the output variable 'Y(0,0)' in the ^DIC routine, have been added to both systems.
• Internal FileMan code has been "cleaned up", so that
• a. All occurrences of the MUMPS $NEXT function have been removed.
• b. Virtually every occurrence of the MUMPS READ command is a "timed" READ.
• c. Incremental MUMPS LOCK commands have replaced virtually all the earlier non-incremental forms of that command.

In general, however, the two systems, DHCP and CHCS, have evolved in a divergent, rather than convergent, fashion since 1986. Two different methods of data archiving have been devised. Two different modes of input auditing are in use. Most strikingly, two totally different "CHUI" screen handlers are used in the two systems for data entry and editing. Additionally, the many smaller-scale differences between the two systems (documented below) make the hypothetical task of moving a robust application from one system to the other a very problematic one.

How shall we describe and assess all these discrepancies? To quote the Statement of Work for this study, "the purpose of this study is to document the potential for application exchange between DHCP and CHCS." In all the following documentation, therefore, the focus will be on answering the question, "how does each discrepancy diminish the likelihood that a given DHCP application could be moved to CHCS, or a given CHCS application be moved to DHCP?" As each discrepancy is described, a separate paragraph will be presented, headed "Portability Effect". This will describe the "effect" of the discrepancy on portability from one system to the other. Five categories of effects are distinguished, from "Serious" (1) to "Nil" (5).

1. Portability Effects are flagged as "SERIOUS" when they would cause real (perhaps insuperable) problems in the transporting of functionality from one system to the other.
2. Portability Effects are flagged as "Requires conversion" when they must be attended to to preserve the application functionality from one system to the other, but when there is a straightforward (potentially automated) way of converting from one system to the other.
3. Portability Effects are flagged as "Uncertain" when they are unlikely to be problematic in any real-world porting between the two systems, and when, in any case, there is a straightforward workaround to the discrepancy.
4. Portability Effects are flagged as "Minor" when the functional difference between the two systems involves only "cosmetic" or "user-training" issues.
5. Portability Effects are flagged as "Nil" when the discrepancy causes no foreseeable impact on application transfer.

Since the focus of the present study is on application exchange, little will be documented here concerning the differences between the two systems in the process of creating an application. In other words, we shall not treat the differences in dialog involved in creating and editing Files, Fields, Screens, and Templates. In general, it can be said that if a programmer/developer is adept at doing these things in one of the systems, he can easily learn how to do them in the other. The creation and editing of "ScreenMan" screens is perhaps an exception to this rule, as will be pointed out in Section VII.

For the most part, the concern in this document is with MUMPS Global structures, and MUMPS code, that can be assumed to be already existant, and with the differences in the way that users, not developers, perceive the workings of the two systems.

In all these comparisons, it will be assumed that neither CHCS FileMan nor DHCP FileMan can themselves be modified to correct discrepancies. Of course, this assumption is not necessarily correct, and in a concluding section, we will make suggestions as to which unilateral enhancements would be easiest and most desireable to retrofit from one FileMan to the other. It is hoped, then, that the present work, besides treating the perhaps hypothetical issue of portability, may serve in the future as a catalogue of suggestions to either DHCP or CHCS FileMan developers who might be interested in what their counterparts have found useful to implement.

Finally, for ease of exposition, two conventions are observed in the current study:

1. Male pronouns are used in their generic sense to refer to antecedents like "the user" or "the programmer".
2. The computer language in which CHCS and DHCP FileMan are implemented is referred to as "MUMPS".