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...

Regards
-- Bhaskar

---

GT.M's $ZROutines search path consists of a series of "chunks", each of which is of one of the following forms:

1. A directory, e.g., /opt/lsb-gtm/V5.3-002_i686
2. A directory followed by another directory in parentheses, e.g., myVistA/gtm_V5.3-002_i686/o(myVistA/r)
3. A directory followed by a parenthesized list of directories, e.g., myVistA/gtm_V5.3-002_i686/o(myVistA/p myVistA/r)
4. 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.M to find a routine, e.g., D ^XYZ or ZLink "XYZ".  GT.M 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:

1. It will look for both in the same directory.
2. It will look for the object routine in the directory outside the parentheses, and the source routine in the directory inside the parentheses.
3. 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 object 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 the first directory inside parentheses.

There are three cases:

1. Adding a new routine.
2. 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 this).
   
3. Deleting a routine.

When adding a new routine, it should simply be placed in the first source directory.

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 command 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
        ZMESSAGE 150374338:$PIECE($ZPOSITION,"^",2)
        QUIT
kbhaskar@bhaskark:~/demo$ mumps -run ^XYZ
%GTM-E-FILENOTFND, File XYZ not found
                At M source location +1^XYZ

GTM>

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, kdtop3@gmail.com wrote:

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
write 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

Kevin


On Sep 21, 5:06 pm, Nancy Anthracite <nanthrac...@verizon.net> wrote:
> For patching with GT.M, all the routines need to be in the same directory and
> the environment variables need to be set up to reflect that when patching.
>
> 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 can get
> > my system up to patch eventually.
>
> > I have automated getting the next relevant patch for a given package
> > from the VA ftp server.  So all I have to do is tell it what package
> > and version to work on, and it will determine the last sequence
> > number, find the next available patch, download it, and then pass that
> > 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, it
> > STRONGLY recommended that I turn off taskman and inhibit logins, which
> > 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 printer.
> > Then the page got cleared, and the error was gone.  I noticed that I
> > 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 in were
> > unsuccessful.  Now what to do?  I finally used my debugger to trace
> > through ^XUS, until I found that it was looking at the VOLUME SET
> > file, and that there was a field in there that stored the flag to
> > inhibit logins.  So a fileman edit fixed that problem.  I'm not sure
> > how I was supposed to figure that out without tracing through the
> > code.  It seems to me that KIDS should have allowed logins again even
> > after an error was encountered.  I found that the error was a
> > permissions problem when saving the new files to the HFS.  But that
> > wasn't easy to find either.
>
> > When was the last time that KIDS had any work on it?  I am taking the
> > 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 either UNIX
> > or DOS end-of-line format.  One I want to work on is allowing for
> > GT.M's setup for different directories for user vs. system files.  It
> > keeps wanting to put the new patches in the user directory instead of
> > the system directory.  Then one has two copies of the code floating
> > around.
>
> > Here is my questions:
>
> > When I select the option for "Display Patches for a Package", I get
> > 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                  TOPPENBERG,KEVIN S
> >    133              SEP 20, 2008                  TOPPENBERG,KEVIN S
> >    135              SEP 21, 2008                  TOPPENBERG,KEVIN S
>
> > Notice that the three I have added don't display a SEQuence number.
>
> > Looking at the DD for the INSTALLATION file, I found field 42001 that
> > returns sequence number.  It is a computed field that pulls from the
> > File Comment field, as far as I can tell.
>
> > So I can print a Fileman report showing the fields: .01 NAME, 42001
> > SEQUENCE, and FILE COMMENT, and it will display the proper sequence #.
>
> > 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