On Mon, 2005-08-29 at 16:36 -0500, Kevin Toppenberg wrote: [KSB] <...snip...>
> 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. [KSB] The operating system maintains virtual memory, and makes it available to processes via a number of primitives. This is more detail than you should need to know to use GT.M. I would be happy to try to explain more details, but am somewhat pressed for time just now. Maybe a topic for over a pitcher at the next VistA Community Meeting? > > 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. [KSB] You can have an unlimited (except by disk, RAM, and CPU horsepower - GT.M imposes no limits) number of application versions,database files, GT.M versions, etc. all on the same machine. Each process only needs to have $gtm_dist, $gtmgbldir and $gtmroutines set appropriately. For our banking application, we routinely have tens of environments on the same machine. In the classical implementation of the CPRS GUI, you would have each environment listening at a different TCP port. With the "direct connect" CPRS GUI and GT.M V5.0-000, as long as you can tell from a client where it wants to connect (e.g., if this can be determined from the IP address of the client by xinetd), you can actually have them all listening to the same TCP port. -- Bhaskar ------------------------------------------------------- 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
