All patches and version updates to VistA in VA are handled via KIDS (or at least they're supposed to!) One of the capabilities KIDS offers is to lock out users of selected options related to the code being changed. Other users then can continue their merry way during what in some cases may be lengthy installation processes. Rather than VistA being like a car (a system), it's more like a fleet (a system of systems), where we even have the equivalent of floating dry-docks to do repairs while engaged in active maneuvers.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of K.S. Bhaskar Sent: Monday, August 29, 2005 1:37 PM To: [email protected] Subject: Re: [Hardhats-members] Re: GT.M and user/memory/object code space Kevin -- In response to the first implicit (e.g., Do PQR^XYZ for a routine that is not currently linked in the process address space) or any explicit request to access a routine (e.g., ZLink "XYZ"), GT.M will search for that routine as specified by the $ZROutines search path, compile the routine if needed (if the .o file is older than the corresponding .m file), bring it into the process virtual memory and link it into the process address space. [Tangential side note for the technically curious: if the routine is placed in a shared library on Proprietary UNIX platforms where this is supported by GT.M, or in a shared .EXE file on OpenVMS, GT.M still links it into the process address space, but the virtual memory is shared and so overall memory usage is more efficient than GT.M on x86 GNU/Linux.] For all subsequent activations of that routine (Do ANYTHING^XYZ) GT.M will simply use the in-memory copy and not go back to the file system to re-link the routine. Thus, a process that already has the routine linked will be unaffected by any subsequent changes to the routine in the file system. This is called clobber protection, and it's a feature. How many psychiatrists does it take to change a light bulb? Just one, but the light bulb has to want to change. In much the same way, once a routine is linked into a process address, a GT.M process must make an explicit decision to change by executing an explicit ZLink command. So, if you change a routine on disk, and want a GT.M process to use the new version, you have to get the process to perform an explicit ZLink. While GT.M does not have a pre-packaged mechanism to implement such a feature, it does have the hooks to implement such a feature at the level of the application code. [A philosophy of GT.M is to provide the underlying enabling technology and to let the applications create and package functionality the way that best meets the needs of each application.] You can send an asynchronous signal to a process, and the process can implement a handler for that signal (you must be authorized to send the signal by the operating system). Out of the box, for ease of debugging, the default GT.M behavior is to provide a dump of useful debugging information, but you can easily provide code so that the process looks for routines to ZLINK (or whatever else you want it to do). So, if you change a routine, existing GT.M processes that have already linked that routine will not automatically relink it. You can shut down the processes, and when you restart them, the new processes will automatically pick up the new code. But let's change the topic. Why are you changing code in a production environment? In order to maintain a robust production environment, it should be "locked down" and there should be a somewhat formal process of change control by which changes are migrated from a testing environment to a production environment. It is not generally recommended to change code in a production environment as that code is being used, just as it is not considered a good idea to flush the radiator when driving your car. -- Bhaskar On Mon, 2005-08-29 at 14:47 -0500, [EMAIL PROTECTED] wrote: > > OK. That helps. And I guess that all XWBTCP sessions (i.e. > > connection from CPRS) are given a separate job. So if I do a ZLINK > > from a command-line shell, it wouldn't change the CPRS session. > > > > Thanks Dave, > > Kevin > > Your analysis matches my understanding. > XWBTCP sessions are given a separate MUMPS job. > ZLINK from a command line shell will only affect the MUMPS job for > the command line shell. > > > > > > On 8/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >=20 > > > >=20 > > > > I don't know quite how to ask this question: > > > >=20 > > > > If I have my server up and running, and I make a change to one of the > > > > modules (in this case it was the module that prints out progress > > > > notes), then the changes won't become apparent until the user that was > > > > using the old code closes out and reconnects. > > > >=20 > > > > So my question is, does GT.M keep a complete copy of the code base > > > > for every different process? And how can I tell if everyone has > > > > switched over to using the new code (other than just watching to see > > > > how the new progress notes get printed out?) > > > >=20 > > > > Kevin > > >=20 > > > I'm not Bhaskar, but I can answer part of this. > > > Yes, GT.M keeps a complete copy of the code base for each different > > > process, if what you mean is that it looks at the program (.m) file, > > > compares it to the intermediate language (.o) file, if they are both > > > up-to-date, it then creates an (in-memory) Just-in-time compile of the > > > .o file into a native code file (x86 machine language) and then > > > just uses the compiled copy until the process ends. > > >=20 > > > If a process knows it needs to update its copy, the ZLINK command will > > > force it to replace the native code file/machine language in its memory > > > space. > > >=20 > > > A year or so ago, at one of our community meetings, we did a bit of=20 > > > analysis about using the same mechanism used by the ^ZSY and ^ZJOB code= > > =20 > > > to tell a running process to update (ZLINK), but I don't think the analys= > > is > > > turned into real code. It shouldn't be very hard, you would just use > > > a flag in a global. > > >=20 > > > David Whitten > > > (713) 870-3834 > > >=20 > > >=20 > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= > > es > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= > > A > > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Hardhats-members mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
