Steve -- I don't have a good answer for what to do if a process is running a report that will take several hours to complete when operations wants to shut the system down. I guess that depends on the application logic for the process. [For example, in our banking application, with the use of TP, all "batch" processes are designed to be automatically restartable from the state of the database.] However, I do take a slightly different view of the others.
It seems to me that the typical / traditional deployment of Taskman occurs based on a model of computing that (a) CPUs are a scarce resource and (b) spawning processes is expensive. Thus, there is a pool of processes, and the demand for CPU resources is throttled by queuing tasks to processes in this pool. Perhaps this model may still be valid when deploying VistA at a large hospital - I just can't say for sure one way or another. However, in an era when one can and acquire a PC server that at least computationally* is as good as, and likely much better than, the biggest VAX that existed 10 years ago for a couple thousand dollars, and where even a low end Linux system can spawn hundreds - and maybe even thousands - of processes per second per CPU, this model of resource scarcity doesn't apply in the context of VistA deployed at a practice or a small hospital. It is possible to fire up a new process to handle a connection request when a CPRS GUI client needs service. For other tasks, instead of the traditional Taskman model, is it possible to just spawn a new process when a piece of work needs to be done, and then let the process just complete and terminate when it is done? That way, when the system has no work to do, there won't be any processes waiting for work that then need to be shut down. [At least with GT.M, there won't even be residual daemon processes. The first process - CPRS GUI connect, or interactive login - will set up whatever is needed, and the last one out cleans up and turns out the lights.] Thanx in advance for your comments. -- Bhaskar * Of course, IO subsystems are a different story. But that's not germane to this discussion. On Wed, 2005-08-31 at 14:16 -0500, steven mcphelan wrote: > There is no reason to start up these VistA processes using some > external > script except for Taskman. Once Taskman starts up he can start up > whatever > background process you desire. Most, if not all, of these background > processes already have VistA options to be run as scheduled tasks at > startup > from Taskman. Of course many of these options assume you have > properly > configured the corresponding files prior to trying to start up those > background processes. The Broker, HL7, Mailman, and others can all > be > started by Taskman. > > Stopping processes non-interactively is more of a problem as most of > them do > not have a silent way to stop the background processes. Taskman can > be told > to stop all processes when they finish. But this has always been > problematic. Some processes never get terminated, perhaps because > they were > not started by Taskman directly. Then what does Taskman do (or a > system > shutdown do) if a process is running, say a report, still has several > hours > to go before running to completion? Yes VistA tasked jobs can be > programmed > to look for a stop running request so that they shutdown gracefully. > The > truth is that most Taskman jobs are not programmed to even look for > these > stop requests. ------------------------------------------------------- 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
