About the KIDS installation, lets say that a process is not using a particular module -- say in my case the code to print out a progress note. The KIDS code can ensure that the process is not actively printing something out (perhaps), but even after the code is changed, the process still would need to be told to ZLINK the new code into its address space, right? Otherwise it would keep using the old code.
For something like CPRS printing out a progress note, it is not that big a deal -- just restart the client. But I wonder about the main core processes, like Taskman. Is the entire system supposed to be rebooted after an update? Kevin On 8/29/05, Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > Bhaskar, > > Thanks for the info. See below > > On 8/29/05, K.S. Bhaskar <[EMAIL PROTECTED]> wrote: > > 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.] > > So is this virtual memory maintained by by GT.M for its various > processes. Or is this something that is done at a Linux level? When > a processess is JOB'd off in GT.M, I think it is given a separate > process ID. But I assume that GT.M is coordinating it somehow. > > On the other hand, maybe this is more detail than I need to know. > > > > ... > > > > 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. > > Well, I took the original source file and backed it up. So I could > recover from an error. And I felt that if I had introduced a terrible > error, that the error trap could catch it. And I felt that the chance > of introducing a bad error were small, because I was just removing a > printout of time (while leaving the date) of a report. > > But your point is well taken. It would be better to have a practice > system. I guess I could have two such systems on the same server -- > or would I need a separate server. I am still used to Windows and > it's registry that requires "installation". But I think with GT.M, it > is just a matter of putting the code into a directory and then > executing it. So I guess I could have a separate code base in a > separate directory. But I wouldn't want them both listening on the > same port for CPRS connections. > > Thanks > Kevin > ------------------------------------------------------- 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
