[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Packaging fis-get

On Sat, Jan 28, 2012 at 07:15:47PM -0500, Luis Ibanez wrote:

> Bhaskar was quick reply to recommend the way
> to test the package so far.   (Thanks Bhaskar !)
> First, we tried the command
> $ /usr/lib/fis-gtm/54002B-initial/gtm
> that launches GTM, and since it is the
> first time it runs, it creates a directory
> under $HOME/.fis-gtm

I am EXTREMELY likely to wake sleeping lions here but this
seems to hint at a fundamental - what shall we call it -
issue ? of how VistA operates.

I truly hope I am misunderstanding and I'm sure Bhaskar will
set me right.

Since running


	(which should probably be /usr/lib/gtm symlinked to
	 /usr/lib/fis-gtm/54002B-initial/gtm by way of the
	 alternatives system, no ?)

as $USER creates a $HOME/.fis-gtm I blatanly assume that the
gtm demon (?) will start storing data in the DEFAULT (?)
area under that directory - which is user-local.

Hence one of the tasks might be to figure out the way to run
gtm as a system demon (PostgreSQL may provide) hints here.

The first question would be - how does gtm allow/manage
concurrent connections from other users/machines ?

> To further test, Bhaskar indicated that
> when running the command a second
> time it should have a cleaner output like:
> $ /usr/lib/fis-gtm/54002B-initial/gtm
> GTM>write $zversion
> GT.M V5.4-002B Linux x86
> GTM>halt

This looks very much like running psql from PostgreSQL:

	$> su - postgres		# PostgreSQL system demon account
	$> psql					# connects to DB "postgres" on port "5432" via Unix domain sockets
	postgres=> select version();
	 PostgreSQL 9.1.2 on i686-pc-linux-gnu, compiled by gcc-4.6.real (Debian 4.6.2-4) 4.6.2, 32-bit
	postgres=> \q

This PostgreSQL thing connects to a PostgreSQL instance
running systemwide, providing services to all users.

I hope running gtm is not more like running Python:

	$> python
	>>> import sys
	>>> print sys.version
	2.7.2+ (default, Dec  1 2011, 01:55:02)
	[GCC 4.6.2]
	>>> exit()

which runs a *user-local* instance of the Python interpreter
blithely unaware of the wants and needs of (and unreachable
for) *other* users of the system (who can, of course, run
their *own* instance of Python).

Just food for thought. Analogies often help me to understand
complex matters.

GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Reply to: