In this Section, and the next, we turn to discrepancies between the two systems that are significant specifically to the MUMPS programmer. Non-programmers, therefore, may find this section particularly opaque.
CHCS FileMan's date-reading utility, '%DT', has been enhanced to accept Julian-format dates. Thus "J57033" is acceptible input for the date "February 2, 1957". "Zulu"-format dates (which include time in terms of Greenwich Mean Time) are also allowed as input.
Portability effect: Uncertain. One might call this a "user feature" rather than a "programming feature", but it is unlikely that a user would enter dates in this way, whereas it is possible that a CHCS programmer has taken advantage of this 'trick', sending an 'X' variable in the Julian (or, less likely, Zulu) form to the ^%DT routine in a silent call.
This programmer entry point, an Extrinsic Function, returns the time at the moment of execution in FileMan date format. If the single parameter of the Function is equal to the string "S", the date format includes seconds. In other words, the value of
is a numeric containing up to six decimal digits.
Portability effect: Requires conversion. The NOW^%DT entry point does not appear in DHCP FileMan, but an equivalent could be easily constructed. Cf. the VA entry point NOW^%DTC.
This programmer entry point converts a number, taken to be the number of seconds since midnight, into a fractional FileMan date.
Portability effect: Requires conversion. The X^%DTC entry point does not appear in DHCP FileMan, but an equivalent could be easily constructed.
CHCS FileMan's "^DIC" lookup routine functions differently from the DHCP FileMan lookup in some subtle respects.
The ^DIC routine in both CHCS FileMan and DHCP FileMan accepts input in the form
`N
where "`" is the literal "accent grave" character, and N is some existing canonic Internal Entry Number for the File specified by the variable 'DIC'. In CHCS FileMan, the ^DIC routine has an enhancement that is useful in looking up Entries in those Files whose Entries are Pointers to another File. For such Files, input can be in the form
``N
This means, "find an Entry (or Entries) which points to Entry Number 'N' in the pointed-to File." This feature, like the "`N" feature, is one that a user can take advantage of, but it is more commonly used by programmers.
Portability Effect: SERIOUS Any lookup of the form "``N" will fail if ported to DHCP FileMan. Unfortunately, this incompatibility can crop up in Input Templates (and straight call to ^DIE) as well as in calls to ^DIC, because the process of selecting a multiple to edit within an Input Template equates to a call to ^DIC. A CHCS programmer not uncommonly includes in an Input Template specifications like
EDIT WHICH FIELD: MULTIPLE///``45
meaning, "select the multiple whose pointer value is 45". MUMPS re-programming would be required to reproduce this same functionality under VA FileMan.
Another subtle discrepancy between the two versions of ^DIC is that, in CHCS FileMan, if the input variable 'X' is an alphanumeric string terminating with "?", then CHCS will strip off the "?", try to match the remainder of the string, and, even if an exact match is found, will go further to see if the string begins any other lookup value in the File. In other words, this feature is CHCS FileMan's way of forcing a lookup to be done in the way DHCP FileMan normally does lookups when the "O" parameter is not present in the 'DIC(0)' parameter string. Obviously, though, the two features are incompatible. Again, the "terminating question-mark" is a feature available to users, as well as to programmers, but it's doubtful that many CHCS users know of its existence!
Portability Effect: Uncertain. It is possible that a CHCS programmer could produce code that sends the input string 'X' to the ^DIC routine with a "?" suffixed to it.
Such a ^DIC call, when ported to DHCP FileMan would obviously fail, because DHCP FileMan would not strip off the suffixed "?". The difficulty would be to locate such a ^DIC call. It would be trivially easy to fix the problem once it was located: just remove the adding of the "?", since DHCP's lookup would work, by default, the way the CHCS lookup was being forced to work.
In calling the ^DIC routine, the input variable 'DIC("DR")' has always been treated by FileMan as a string controlling which 'Identifier' Fields will be asked or 'stuffed' when the ^DIC routine 'LAYGOs' a new Entry. In CHCS FileMan's ^DIC routine, DIC("DR") is allowed to be an array. Specifically, DIC("DR",2,N) can be set to control asking or 'stuffing' data at a Multiple level at LAYGO, where 'N' is the subfile number of the multiple.
Portability Effect: Requires conversion. Calls to ^DIC using an DIC("DR") input array need to be re-programmed in any code ported to DHCP. The workaround might be to have DIC("DR") name an [Input Template].
In CHCS FileMan, if 'DIC("PROMPT") is defined when ^DIC is called, the string value of 'DIC("PROMPT")' is used as the displayed name of the File into which ^DIC is doing its lookup. Thus, for example, the existence of 'DIC("PROMPT") defined equal to "GUARANTOR" will cause the
Are you adding a new PATIENT?
query to be displayed as:
Are you adding a new GUARANTOR?
DHCP FileMan's ^DIC routine does not offer this functionality.
Portability effect: Uncertain. 'DIC("PROMPT")' allows the developer to customize the ^DIC dialogue with the user in a way which might be called "cosmetic", since it has no effect on what the user is actually allowed to type, or on how data is stored. Nevertheless, CHCS developers have occasionally used this feature to make data entry more understandable to a user. To replicate such ease of use in a portation to DHCP might require creating a "special lookup routine" that mimics ^DIC, with captions changed.
CHCS FileMan offers the same functionality as does DHCP FileMan with the entry point 'MIX^DIC1'. However, CHCS FileMan includes an identical 'MIX^DIC' entry point, which has been documented. DHCP FileMan doesn't have this entry point.
Portability effect: Require conversion. Any occurrence of 'MIX^DIC' found in CHCS code needs to be changed to 'MIX^DIC1' to run in DHCP FileMan.
CHCS FileMan allows a programmer to call ^DIE with a specification that any data changes made during the call to ^DIE shall be "mirrored", as it were, in some array (Global or local) other than the actual data Global into which the changes are filed. When ^DIE quits, then, the calling programmer can more easily determine "what the user did", by examining the contents of the scrath array, which was named by the DIE("SAVE") variable when ^DIE was called. DHCP FileMan has no such feature.
Portability Effect: SERIOUS. Any (scrolling-mode) call to ^DIE made by a CHCS MUMPS routine would have to be examined if transported to DHCP. If the call were found to include a DIE("SAVE") variable, code subsequent to the call would surely be found to examine the array named by DIE("SAVE") in some way. Such code would have to be re-worked by a programmer, since in the DHCP environment, ^DIE would never set anything into the named scratch array.
CHCS FileMan recognizes the presence of a variable 'DIE("NOFILE")' when calling ^DIE, which simply tells FileMan to ask for data from the user as it normally would, but not to file that data in the database. This feature is often used by programmers in conjunction with the one just mentioned: with 'DIE("SAVE")' defined along with 'DIE("NOFILE")', the programmer can have ^DIE gather up answers, then examine those answers in the temporary "mirror of changes", and then either force those changes to be filed, by passing them back to ^DIE in a "stuff" mode, or else take some other action to elicit "better" input from the user.
Portability effect: SERIOUS. Since DHCP FileMan does not recognize the 'DIE("NOFILE")' parameter, and files all data it collects, any CHCS code using that parameter would have to be re-worked by a programmer before porting it to a DHCP environment.
CHCS FileMan recognizes the presence of a variable 'DIE("AUDIT")' when calling ^DIE, which forces all data-changes to be audited (using the ^DIAU and ^DIET Globals mentioned above on Page 9). This 'DIE("AUDIT")' flag thus overrides the normal 'audit' status of the File being edited.
Portability effect: SERIOUS DHCP FileMan has not equivalent feature. If a CHCS programmer goes to the trouble of "forcing auditing", it is likely to be because, after the ^DIE call, he intends to examine the ^DIET or ^DIAU globals, which of course do not exist in DHCP FileMan. A workaround to such programming is not, in general, obvious. Of course, it is possible that in some cases, a CHCS programmer "forces auditing" just as a kind of general security measure not intrinsic to the application itself. In either case, though, it is very important to realise that DHCP FileMan will ignore the 'DIE("AUDIT")' variable, thereby subverting some security-related intention of any CHCS programmer who has used it!
The ^DIP input variable "BY" has often proved difficult to use, because its delimiting character, the comma, often occurs within a desired Sort Field name, or Compted Expression. Also, the 255-character length limitation on a single MUMPS variable is constraining when a Sort specification is unusually complicated. For these reasons, CHCS FileMan allows the programmer calling ^DIP to pass sort values in an array called 'BY', alternatively to passing them within the single string called 'BY'. DHCP FileMan does not recognize the "BY array".
Portability Effect: Requires conversion. CHCS Code calling ^DIP with a "BY array" would fail to run (i.e, crash!) if ported to DHCP FileMan. Any CHCS code being ported to DHCP needs to be vetted for such ^DIP calls. The general work-around would be to create a Sort Template, and then replace the "BY array" with a "BY string" equal to the [bracketed] name of that Sort Template.
It should also be remembered that "BY" values containing ";1", ";2" and "^GLOBAL(" specifications will not work properly under DHCP FileMan. Such calls may need to be totally re-worked. See above, Page 14.
In CHCS FileMan, an optional input variable 'DIOBEGIN' is recognized. This variable is a string of MUMPS code which is executed before the printout begins. DHCP FileMan recognizes an equivalent input variable named 'DIOBEG'. However, as mentioned elsewhere, CHCS FileMan outputs a form-feed to a printer device after executing the code found in 'DIOBEG'.
Portability Effect: Requires conversion. Any CHCS code which calls ^DIP needs to be examined; if the optional 'DIOBEGIN' variable is set, it must be re-named 'DIOBEG' in code ported to DHCP, and the form-feed discrepancy mentioned above must be considered.
The 'TaskMan' module of CHCS Kernel has been re-written several times over since 1987. One modification introduced into CHCS TaskMan has signicance for programmers who call the CHCS FileMan 'DIP' output module. Specifically, the change involves any code that calls ^DIP:
1) with the possibility that the output job will be queued; and
2) passes local variables (other than FileMan parameters) to ^DIP
For example, a programmer might write
S MYVAR=3.14159,MYSTRING="SPECIAL",%IS="Q" .... D EN1^DIP
If the user then answers the
DEVICE: Q
prompt so as to invoke queueing to TaskMan, or if the '%ZIS' Device Handler forces queueing for some reason, the programmer probably intends that, when the 'DIP' output finally runs at the queued time, it will have access to the defined MUMPS variables "MYVAR" and "MYSTRING". In CHCS, this will not automatically be true. CHCS TaskMan has been modified so that a tasked FileMan output job does not "inherit" all the MUMPS local variables that were in the tasking job's 'partition' at the time the output was queued. This modification was made for the purpose of improving performance, but, unfortunately, it is not backwards-compatible.
Portability effect: Requires conversion. Code calling ^DIP that would work under DHCP FileMan may need to be modified to run under CHCS. Any non-FileMan local variables passed to ^DIP that need to be available for queueing must now be 'declared' by naming them in the MUMPS 'ZTSAVE' local array. For example, to make the code above work as intended, it would need the addition of
S ZTSAVE("MYVAR")="",ZTSAVE("MYSTRING")=""
or, more simply,
S ZTSAVE("MY*")=""
As a general workaround, the even more general
S ZTSAVE("*")=""
should be invoked before any questionable ^DIP call, to tell CHCS FileMan to save off all local variables to the TaskMan process.
CHCS FileMan uses the "DIJ" namespace for all routines and globals used by its ScreenMan module. As noted in the ScreenMan writeup (Section VII, above), a program invokes a CHCS ScreenMan editing session, not by a special entry point equivalent to DHCP's "^DDS", but rather by calling the time-honored data editing routine, ^DIE, specifying (in the input parameter 'DR') the name of an Input Template that exists as a ScreenMan screen on the current system. Note, therefore, that in CHCS, the exact same routine call
SET DR="[TEMPLATENAME]",DA=1 DO ^DIE
might, in one environment, present the user with a Screen, while elsewhere it might initiate an old-fashioned scrolling-mode dialog! The portability difficulties created by this 'alternate paradigm' as to the relationship of Templates to Screens have been presented in Section VII.
Most of the programmer calls to "^DIJ*"-namespaced routines in the CHCS application suite will be found within ScreenMan templates. The most common of these calls is
DO REFR^DIJE
which refreshes the Screenman screen, and is therefore equivalent to the
DO REFRESH^DDSUTL
call in DHCP ScreenMan, Version 21.
Some CHCS screens also contain the code
DO CB^DIJED or
DO CB^DIJUTL
These (equivalent) calls "clear the bottom" of the display screen so that the programmer can then use those few lines as a crude kind of "pop-up" window. The DHCP ScreenMan call
DO HLP^DDSUTL(...)
would provide the same functionality, if the intent were simply to WRITE some line or lines of text in what DHCP calls the "command area" of the screen. In some cases, though, the developer clears this bottom area and then programs a small MUMPS dialogue with the user; this kind of kludgy programming might be obviated in the DHCP ScreenMan environment through use of the "Form-only Fields" mentioned in Section VII.
A subset of the ScreenMan code, viewed as a separate programmer utility in its own right, has been dubbed "DisplayMan" in the CHCS terminology. DisplayMan, the "DIJD*" namespace of routines, allows the programmer to display to the user an array of information within a specified number of lines on the CRT screen. The user can then scroll through this array if it does not all fit in the available window, much as the DHCP user uses the so-called "Browser" that has been added to Version 21 of DHCP FileMan. The DisplayMan programmer, however, builds his own array (local or Global), rather than referencing a Word-Processing text, and he indicates, by array subscripting, which of the display lines of the array the user is allowed to cursor to. Furthermore, the MUMPS code that calls the ^DIJD utility can set parameters that allow the user to mark the displayed array, either just once, or in several places. An output local array returned from ^DIJD then tells the calling program if and where the display has been marked by the user.
Portability effect: SERIOUS. The DisplayMan utility is used in a great number of places within the existing suite of CHCS hospital applications, notably in the Order Entry module. Since no such stand-alone utility exists within DHCP FileMan, it must be stressed that to port any of the large CHCS application packages into a DHCP FileMan environment, some DHCP version of "DisplayMan" would need to be written. Such hypothetical new code could certainly borrow a lot from the "Browser" utility in Version 21, but the "marking" capability would need to be added.