I agree. Think about it this way: many people can link to the same program without stepping on one another. It's really not that differnt from pointers in Fileman. On the other hand, if you modify code to which a running process links, THAT is a problem. That's why you can get what are sometimes informally called "clobber" errors when you don't disable options when installing patches (or if you don't shut down Taskman when patching parts of Kernel, etc.) Different implementations have different names for this kind of error, but I always thought "clobber" was a great name.
--- [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 > === Gregory Woodhouse <[EMAIL PROTECTED]> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery ------------------------------------------------------- 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
