In early 2007, I wrote up a proposal for a small enhancement to Fileman
to allow GT.M installations of VistA to take full advantage of GT.M's
flexibility with using search paths for routines. I reproduce it below
in the hope that someone will find it worthwhile to make the change.
The change will be especially helpful to people trying to run VistA as
a service where a large number of clinics / institutions share most of
a common set of routines, but each may need to be patched separately.
I think the changes should run to no more than a dozen or so lines of
VistA (ah, but knowing which dozen is the magic, isn't it).
If you have questions, you know where I hang out...
search path consists of a series of "chunks", each of which is of one
of the following forms:
- A directory, e.g., /opt/lsb-gtm/V5.3-002_i686
- A directory followed by another directory in parentheses, e.g., myVistA/gtm_V5.3-002_i686/o(myVistA/r)
- A directory followed by a parenthesized list of directories,
- On some platforms, but not 32-bit Linux, a shared library file
name, e.g., myVistA/routines.so
The chunks form a search path for GT
to find a routine, e.g., D ^XYZ
looks for XYZ in the first chunk, then the second chunk if it can't
find it in the first chunk, etc. Except in case 4, it will try to find
an object routine and a matching source routine:
- It will look for both in the same directory.
will look for the object routine in the directory outside the
parentheses, and the source routine in the directory inside the
- It will look for the object routine in the
directory outside the parentheses, and the source routine in the first
directory inside the parentheses, then in the second if it is not in
the first, etc. - i.e., for that object directory, the directories
inside the parentheses form a search path for source routines.
If GT.M finds an object routine, and no matching source
routine, it will just link it (this is what happens with a shared
library, on those platforms on which this is supported). If it finds a
source routine but no object routine, it generates an object routine,
places it in the object
directory and links it. If it finds both a source routine and an
routine: if the object routine is newer, it links it; if the source
routine is newer, it is recompiled to generate a new object routine
which is then linked.
Behavior of the current VistA patching code
Current VistA patching
code handles $ZROutine
chunk types 1 and 2, but not 3 and
4. Of course, it cannot handle type 4 (which must be handled by a
system utility program such as ld
Recommended behavior of the patching routine
Let me introduce the concept of the "first source directory" - the
first directory in $ZROutines
which can contain source routines, which will be in the first chunk.
If the first chunk is case 1, it is just that directory. If it is case
2, it is the sole directory inside parentheses. If it is case 3, it is
first directory inside parentheses.
There are three cases:
- Adding a new routine.
- Modifying an existing routine, possibly giving it a new name
(copying an existing routine, e.g., ZOSVGUX.m
to _ZOSV.m is a special case of
- Deleting a routine.
When adding a new routine, it should simply be placed in the first
When modifying / copying a routine the original source should be
located with the aid of SILENT^%RSEL (see http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.1-000_Release_Notes.html#ch.hi.id.03
and description of ^%RSEL in the Programmers Guide), and the modified
routine should be saved in the first source directory.
This way, even though the old source continues to exist, any program
will simply link the new one.
When deleting a routine, a stub routine of the same name as the
one being deleted, but which generates an error if called should be
placed in the first source directory. You can use the ZMessage
to generate an error. If a routine XYZ is being deleted by a patch,
simply create a 2-line routine called XYZ.m
as below in the
first source directory. Any attempt to run XYZ (e.g,. D ^XYZ
will generate an error that XYZ.m does not exist (yes, I know this is
insufferably cute, but it is very useful!):
kbhaskar@bhaskark:~/demo$ cat XYZ.m
kbhaskar@bhaskark:~/demo$ mumps -run ^XYZ
%GTM-E-FILENOTFND, File XYZ not found
At M source location +1^XYZ
This is a simple, but relatively general purpose, behavior
that will work for a simple production environment as well as for more
complex development environments.
On 09/21/2008 05:20 PM, email@example.com
The issue is that there is essentially a path that
GT.M will search
on. But when it comes to writing out files, VistA just picks one to
Options to handle this are:
1. Put all the routines into one folder.
2. Have a special script that launches GTM with special environmental
variables setup when planning to use KIDS
3. Modify the KIDS system to make it smarter.
Of course, I am for option #3
On Sep 21, 5:06 pm, Nancy Anthracite <nanthrac...@verizon.net>
> For patching with GT.M, all the routines need to be in the same
> the environment variables need to be set up to reflect that when
> On Sunday 21 September 2008, kdt...@gmail.com wrote:
> > Fun with KIDS patching, including a question:
> > Well, I am trying to become more familiar with patching, so I
> > my system up to patch eventually.
> > I have automated getting the next relevant patch for a given
> > from the VA ftp server. So all I have to do is tell it what
> > and version to work on, and it will determine the last
> > number, find the next available patch, download it, and then
> > file name into the KIDS system to start the loading of the
> > distribution.
> > The first 2 fileman patches went OK. Then on the third one,
> > STRONGLY recommended that I turn off taskman and inhibit
> > I did. I then installed the patch, and got an error flashed
up on the
> > screen. I had told it to ouput errors to the screen, not a
> > Then the page got cleared, and the error was gone. I noticed
> > had an alert, so tried to view it. I was told that login were
> > inhibited, and dropped to a GTM prompt! Attempts to log back
> > unsuccessful. Now what to do? I finally used my debugger to
> > through ^XUS, until I found that it was looking at the VOLUME
> > file, and that there was a field in there that stored the
> > inhibit logins. So a fileman edit fixed that problem. I'm
> > how I was supposed to figure that out without tracing through
> > code. It seems to me that KIDS should have allowed logins
> > after an error was encountered. I found that the error was a
> > permissions problem when saving the new files to the HFS.
> > wasn't easy to find either.
> > When was the last time that KIDS had any work on it? I am
> > code as I go, copying it to my namespace, and then tweaking
it to make
> > it better, but being sure to not make any fundamental changes.
> > One I have done so far is to allow the text file to be in
> > or DOS end-of-line format. One I want to work on is allowing
> > GT.M's setup for different directories for user vs. system
> > keeps wanting to put the new patches in the user directory
> > the system directory. Then one has two copies of the code
> > around.
> > Here is my questions:
> > When I select the option for "Display Patches for a Package",
> > back this...
> > PACKAGE: VA FILEMAN Sep 21, 2008 3:06 pm
> > PAGE 8
> > PATCH # INSTALLED INSTALLED BY
> > 129 SEQ #120 MAR 02, 2004 IRM,MGR
> > 136 SEQ #121 MAR 02, 2004 IRM,MGR
> > 138 SEP 20, 2008
> > 133 SEP 20, 2008
> > 135 SEP 21, 2008
> > Notice that the three I have added don't display a SEQuence
> > Looking at the DD for the INSTALLATION file, I found field
> > returns sequence number. It is a computed field that pulls
> > File Comment field, as far as I can tell.
> > So I can print a Fileman report showing the fields: .01 NAME,
> > SEQUENCE, and FILE COMMENT, and it will display the proper
> > SEQ# NAME FILE COMMENT
> > 114 DI*22.0*122 Released DI*22*122 SEQ #114
> > 119 DI*22.0*123 Released DI*22*123 SEQ #119
> > 117 DI*22.0*128 Released DI*22*128 SEQ #117
> > 120 DI*22.0*129 Released DI*22*129 SEQ #120
> > 2 DI*22.0*13 Released DI*22*13 SEQ #2
> > 118 DI*22.0*131 Released DI*22*131 SEQ #118
> > 123 DI*22.0*133 Released DI*22*133 SEQ #123
<-- notice SEQ
> > is OK
> > 124 DI*22.0*135 Released DI*22*135 SEQ #124
<-- notice SEQ
> > is OK
> > 121 DI*22.0*136 Released DI*22*136 SEQ #121
> > 122 DI*22.0*138 Released DI*22*138 SEQ #122
<-- notice SEQ
> > is OK
> > 4 DI*22.0*14 Released DI*22*14 SEQ #4
> > 7 DI*22.0*15 Released DI*22*15 SEQ #7
> > So, can anyone tell me why the first report above doesn't
show the SEQ
> > #? Where is that pulling from that it empty?
> > Thanks
> > Kevin
> Nancy Anthracite
The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.