Mark --
Comments below.
-- Bhaskar
Mark Street wrote:
On Tuesday 07 June 2005 06:44, K.S. Bhaskar wrote:
> >>4. Network services can now be written in GT.M and deployed under
> >>inetd/xinetd.
>
> [KSB] This will allow the new "direct connect" CPRS GUI to be used more
> easily. Effectively, it means that VistA can be packaged & deployed
> like other network services under inetd/xinetd, which is a standard way
> of deploying network services on UNIX/Linux.
StandAlone vs xinetd/inetd superserver. Can it still be run stand alone?
[KSB] Nothing that existed previously in GT.M has been taken away, so if
it worked for you before, it will continue to work for you now. With
each new GT.M release, the GT.M team tries awfully hard to not break any
application that used to work (with the exception of an application that
somehow relies on the presence of a bug).
In a busy institution what would the benefits of using a superserver rather
than standalone process? Ease of configuration? System Resources?
Connection control?
Usually less often used services are run under xinetd/inetd to save system
resources and fine tune security and connection control.
[KSB] You are correct. However, I do think that on Linux vs. operating
systems like Windows, OpenVMS, z/OS (used to be called OS/390) or even
some other flavors of UNIX, process invocation is cheap, and this tends
to swing the pendulum towards deployment under inetd/xinetd and the
benefits of being able to fine tune things that it allows.
In the case of GT.M, since there is no daemon to startup or shut down
(the first process to open a database file sets up the shared control
structures; the last one out turns off the lights), one of the benefits
of deploying a service under inet/xinetd is that when there is no
activity, everything is just shut down (i.e., no files open, no
processes active). So, it's just a little cleaner.
In the case of VistA on GT.M specifically, the new ability to deploy a
service under inetd/xinetd allows the new direct connect CPRS GUI to be
served by a GT.M process that is started up when the connection request
comes in, rather than, for example, a pre-existing process from a pool
of processes. This is especially appropriate for deployment under
inetd/xinetd because it is a relatively long-lived connection.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
