fis-gtm-core — Core team for GT.M

[Sanchez-gtm-core] Search over... data found!

[Stephen M. <mahespth@NdtLtd.com>]

SGksDQoNCkkndmUgZm91bmQgbXkgZGF0YWxvc3MgcHJvYmxlbSB3aGljaCB3YXMgbm90IEdU
TSBidXQgYSBwcm9ibGVtIHdpdGggdGhlDQp2ZXJzaW9uIG9mIFBIUCBJIHdhcyB1c2luZy4u
IFRoaXMgaXMgbm93IHJlc29sdmVkIGFuZCBpdCdzIGFsbCBsb29raW5nDQpnb29kLCB0aGUg
cGVyZm9ybWFuY2UgaXMgcXVpdGUgcmVhc29uYWJsZS4uDQoNCk9uIG15IGxpdHRsZSBvbGQg
MzAwbWh6IGxhcHRvcCAoMi4yIGtlcm5lbCkgd2l0aCBhYm91dCAxNSB3aW5kb3dzIG9wZW5l
ZA0KYW5kIGJvdGggY2xpZW50cyBhbmQgc2VydmVyIGluIGRlYnVnIG1vZGUgYSAxMDAwIGNv
bm5lY3Rpb25zIHRvIGd0bSB0b29rDQpqdXN0IDQuNSBzZWNvbmRzLg0KDQo+PiBDb25uZWN0
ZWQgOTk5IG91dCBvZiAxMDAwIGNvbm5lY3Rpb25zDQogPj4gMC45MyB1c2VyIDAuNzUgc3lz
dGVtIDA6MDQuNjQgZWxhcHNlZCAzNiVDUFUNCg0KTm93IEkgaGF2ZSB0aGUgY29ubmVjdGl2
aXR5IHNvcnRlZCBvdXQgSSBjYW4gbm93IHdvcmsgb24gdGhlIGFwaSAhIQ0KDQpSZWdhcmRz
DQoNClN0ZXZlIE1haGVyDQo=

Re: [Sanchez-gtm-core] Sockets.

[Jim S. <ja...@uc...>]

Stephen,
I have a partially working HTTP server which I put on hold in favor of first 
developing a CGI server. I experienced no data loss from the HTTP server so 
far, but I have only been testing one request at a time. I have not yet 
tried to close the multiple request loop of automatically putting the server 
job back into the state of waiting on the next request or of jobbing 
multiple server processes to ensure that there is no gap where incoming 
requests can get lost between "listens". Is that where you are having 
problems?

This reminds me of a related question I have intended to ask Bhaskar (or 
anyone who knows) for a while now. What is the effect and intended use of 
the "queuedepth" parameter in "WRITE /LISTEN(queudepth)"? Is that intended 
for services that will be handled in sequence by a single server job? Is 
queuedepth>1 compatible with a service, such as HTTP, which must be expected 
to frequently overflow a queue which is apparently limited to a depth of 5?

Stephen Maher wrote:
>Hi,
>
>has anyone a working example of a Sockets server serving multiple
>requests? I have build some code based on the manual pages, but I have
>data loss from the client.. (Which is not GTM).
>
>Any working examples would be most appreciated.
>
>Regards
>
>Steve Maher
>_______________________________________________Sanchez-gtm-core mailing 
lis...@li...http://lists.sourceforge.net/lists
/listinfo/sanchez-gtm-core

---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)

[Sanchez-gtm-core] Sockets.

[Stephen M. <mahespth@NdtLtd.com>]

SGksDQoNCmhhcyBhbnlvbmUgYSB3b3JraW5nIGV4YW1wbGUgb2YgYSBTb2NrZXRzIHNlcnZl
ciBzZXJ2aW5nIG11bHRpcGxlDQpyZXF1ZXN0cz8gSSBoYXZlIGJ1aWxkIHNvbWUgY29kZSBi
YXNlZCBvbiB0aGUgbWFudWFsIHBhZ2VzLCBidXQgSSBoYXZlDQpkYXRhIGxvc3MgZnJvbSB0
aGUgY2xpZW50Li4gKFdoaWNoIGlzIG5vdCBHVE0pLg0KDQpBbnkgd29ya2luZyBleGFtcGxl
cyB3b3VsZCBiZSBtb3N0IGFwcHJlY2lhdGVkLg0KDQpSZWdhcmRzDQoNClN0ZXZlIE1haGVy
DQo=

[Sanchez-gtm-core] Version control policy draft posted

[K.S. B. <k.b...@sa...>]

In the Docs section, I have posted a draft version control policy.
Please review and comment in the Developers forum as replies to my
posting there announcing the document.  Thanx.

-- Bhaskar

[Sanchez-gtm-core] V4.2-000 released

[K.S. B. <k.b...@sa...>]

Happy New Year.

The V4.2-000 production version of GT.M has been released and is
available on Source Forge.

-- Bhaskar

Re: [Sanchez-gtm-core] Re: Compiling GT.M

[Fred F. <ff...@ne...>]

----- Original Message -----
From: Emiliano <em...@ir...>
To: Fred Forester <ff...@ne...>
Cc: <gtm...@ir...>; Fred Forester <fre...@sa...>;
Lawrence Landis <ld...@ph...>;
<san...@li...>
Sent: Thursday, December 21, 2000 6:04 PM
Subject: Re: [Sanchez-gtm-core] Re: Compiling GT.M


> Fred Forester wrote:
>
> > [FF] Which source layout do you have?
> > src
> > inc
> > tools
> > ..
> > (OR)
> > sr_linux
> > sr_port
> > ..
>
> I just unpacked the sources as Bhaskar made them available to me, which
> had the inc,src,tools etc directories.

[FF] OK,
       so you have /usr/library/V42FTxx ?
       just trying to get a starting point. we may have to take this one
offline then repost.

>
> > > extract_signal_info.c: In function `extract_signal_info':
> > > extract_signal_info.c:194: `EIP' undeclared (first use in this
function)
> > > extract_signal_info.c:194: (Each undeclared identifier is reported
only
> > > once
> > > extract_signal_info.c:194: for each function it appears in.)
> > > make[1]: *** [extract_signal_info.o] Error 1
> >
> > [FF] it's a header file problem we found in RH6.2  It's been a while but
I
> > think
> > it had something to do with the location of ucontext.h ie sys/ucontext.h
> > maybe from gtmsiginfo.h
>
> I am indeed using RH 6.2. Is there a workaround? I have a Mandrake 7.2
> system
> I could use but the RH system is my main workstation.

[FF] Yes, the work around is to change the references in of
#include <ucontext.h>  to
#include <sys/ucontext.h>  or something very close.
(in gtm code of course, not linux).

If you look in usr/include and usr/include/sys and grep for EIP you should
find it.


>
> Emile
>
> _______________________________________________
> Sanchez-gtm-core mailing list
> San...@li...
> http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core
>

Re: [Sanchez-gtm-core] Re: Compiling GT.M

[Emiliano <em...@ir...>]

Emiliano wrote:

> > > extract_signal_info.c: In function `extract_signal_info':
> > > extract_signal_info.c:194: `EIP' undeclared (first use in this function)
> >
> > [FF] it's a header file problem we found in RH6.2  It's been a while but I
> > think
> > it had something to do with the location of ucontext.h ie sys/ucontext.h
> > maybe from gtmsiginfo.h
> 
> I am indeed using RH 6.2. Is there a workaround? I have a Mandrake 7.2
> system I could use but the RH system is my main workstation.

The mandrake system has the same problem. This is a rather current
system.

Emile

Re: [Sanchez-gtm-core] Re: Compiling GT.M

[Emiliano <em...@ir...>]

Fred Forester wrote:

> [FF] Which source layout do you have?
> src
> inc
> tools
> ..
> (OR)
> sr_linux
> sr_port
> ..

I just unpacked the sources as Bhaskar made them available to me, which
had the inc,src,tools etc directories.

> > extract_signal_info.c: In function `extract_signal_info':
> > extract_signal_info.c:194: `EIP' undeclared (first use in this function)
> > extract_signal_info.c:194: (Each undeclared identifier is reported only
> > once
> > extract_signal_info.c:194: for each function it appears in.)
> > make[1]: *** [extract_signal_info.o] Error 1
> 
> [FF] it's a header file problem we found in RH6.2  It's been a while but I
> think
> it had something to do with the location of ucontext.h ie sys/ucontext.h
> maybe from gtmsiginfo.h

I am indeed using RH 6.2. Is there a workaround? I have a Mandrake 7.2
system
I could use but the RH system is my main workstation.

Emile

Re: [Sanchez-gtm-core] Re: Compiling GT.M

[Fred F. <ff...@ne...>]

----- Original Message -----
From: Emiliano <em...@ir...>
To: K.S. Bhaskar <k.b...@sa...>; Thomas Good
<to...@ad...>; Fred Forester <fre...@sa...>; Lawrence
Landis <ld...@ph...>; <san...@li...>
Sent: Thursday, December 21, 2000 5:41 PM
Subject: [Sanchez-gtm-core] Re: Compiling GT.M


> "K.S. Bhaskar" wrote:
>
> > [KSB] OK.  Fred Forester will help you with getting GT.M built and
> > tested in your machines.  What I would request is that you in turn help
> > others when the sources are released.
>
> Still no word guys. I've been experimenting with the scripts, no luck so
> far.
> What I need to know is a) what variables to set, b) what scripts to run
> or
> source, and c) what directory layout to create.
>
> Alternately, I've been tinkering with Makefiles, and am stranded on

[FF] Which source layout do you have?
src
inc
tools
..
(OR)
sr_linux
sr_port
..
>
> extract_signal_info.c: In function `extract_signal_info':
> extract_signal_info.c:194: `EIP' undeclared (first use in this function)
> extract_signal_info.c:194: (Each undeclared identifier is reported only
> once
> extract_signal_info.c:194: for each function it appears in.)
> make[1]: *** [extract_signal_info.o] Error 1

[FF] it's a header file problem we found in RH6.2  It's been a while but I
think
it had something to do with the location of ucontext.h ie sys/ucontext.h
maybe from gtmsiginfo.h


>
> I can't find where this symbol or constant is defined.
>
> Emile
>
> _______________________________________________
> Sanchez-gtm-core mailing list
> San...@li...
> http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core
>

[Sanchez-gtm-core] Re: Compiling GT.M

[Emiliano <em...@ir...>]

"K.S. Bhaskar" wrote:

> [KSB] OK.  Fred Forester will help you with getting GT.M built and
> tested in your machines.  What I would request is that you in turn help
> others when the sources are released.

Still no word guys. I've been experimenting with the scripts, no luck so
far.
What I need to know is a) what variables to set, b) what scripts to run
or
source, and c) what directory layout to create.

Alternately, I've been tinkering with Makefiles, and am stranded on

extract_signal_info.c: In function `extract_signal_info':
extract_signal_info.c:194: `EIP' undeclared (first use in this function)
extract_signal_info.c:194: (Each undeclared identifier is reported only
once
extract_signal_info.c:194: for each function it appears in.)
make[1]: *** [extract_signal_info.o] Error 1

I can't find where this symbol or constant is defined.

Emile

[Sanchez-gtm-core] Re: Some questions left on Mumps

[Emiliano <em...@ir...>]

K.S. Bhaskar wrote:

> [KSB] Correct.  In a more traditional architecture with pessimistic
> concurrency control (read locking), using transactions does slow things
> down.  While GT.M's advantage is speed, the disadvantage is that GT.M
> doesn't have two phase commit.  Of course, two phase commit is so slow
> in Oracle and DB2 that no one uses it anyway!

pondering... does GT.M support nested transactions? Could not those be
used to emulate 2-phased commit? I'm not likely to ever need 2-phased
commits, just curious.

> > I don't, but you mentioned 'multiple of'. I am trying to get an
> > understanding of the nooks and crannies of GT.M. I come from a very
> > different world (client-server RDBMS stuff) and this all is somewhat
> > alien to me. Asking these dumb questions helps me map the terrain.
> 
> [KSB] The only reason to go to a larger block size is if there are
> global variables too larger to fit in a block, and which you don't want
> to chop up into multiple globals.  Larger block sizes can have more
> transaction collision, but more efficient I/O, so this is the line that
> you have to walk.

The data that I'm going to store is typically going to be very small,
0.2 - 5kb. The size of the larger objects is unpredictable, could be
10k, could be 200M, so these will have to be chopped up anyway.
Besides, the documents will need to be served out over a network
connection; I would chop them even if I could store them in one piece
since chopping them up has the large benefit of being able to
fetch and deliver the chunks without the need to have the entire
object in core.

Emile

Re: [Sanchez-gtm-core] GT.M V4.2-FT10 released

[K.S. B. <k.b...@sa...>]

On Wednesday, December 13, 2000 at 16:39:48 (GMT-0500), K.S. Bhaskar wrote:
 > More regression test failures, and also fixes so that Jim Self's MVTS

[KSB] Read: More [fixes for] regression test failures...

-- Bhaskar

[Sanchez-gtm-core] GT.M V4.2-FT10 released

[K.S. B. <k.b...@sa...>]

More regression test failures, and also fixes so that Jim Self's MVTS
tests don't die with a Signal 11 (error messages for unsupported
features are OK; signal 11s are rude).

Hopefully, this is the last field test release before the general
release, after which we will get the source out.  Any millenium now!

-- Bhasakr

Re: [Sanchez-gtm-core] Who's the arbitrator

[K.S. B. <k.b...@sa...>]

I have posted this from Emile, and my response in the Developers
discussion forum on Source Forge.

There is also a new document on GT.M security.

-- Bhaskar

On Wednesday, December 13, 2000 at 20:43:58 (GMT+0100), Emiliano wrote:
 > OK, so I'm getting to grips with the fact that there isn't (or doesn't
 > need to be) an active server-type application in a mumps installation.
 > 
 > But who manages the transaction? How do two different Mumps programs
 > know about each other? Disk-block locking?
 > 
 > Emile
 > _______________________________________________
 > Sanchez-gtm-core mailing list
 > San...@li...
 > http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core

[Sanchez-gtm-core] Who's the arbitrator

[Emiliano <em...@ir...>]

OK, so I'm getting to grips with the fact that there isn't (or doesn't
need to be) an active server-type application in a mumps installation.

But who manages the transaction? How do two different Mumps programs
know about each other? Disk-block locking?

Emile

[Sanchez-gtm-core] DAL

[Emiliano <em...@ir...>]

I'm ready to get my hands dirty with the DAL. Most things look not
too hard, given the examples in the chapter. But I'd need some
examples, or more info, on what things like gtm_order return.

Also, gtm_init doesn't specify a database to connect to. How is
the database used determined? And how is the actual connection
made? TCP/IP, rpc, other?

Also, how would I determine the max size of the data I can store
in a node (for when I want to store chunked blobs)?

Emile

Re: [Sanchez-gtm-core] Application field

[Emiliano <em...@ir...>]

Terry Wiechmann wrote:
> 
> Only the client development environment is Windows. The object
> implementation runs on ANSI MUMPS server side. That makes it independent of
> any OS. It currently runs on most MUMPS implementations. We hope to port it
> to GT.M as soon as it moves closer to the 95 ANSI standard.
> 
> There is a 36 page white paper on it at http://www.esitechnology.com (under
> Library) if you are interested.

OK, I finally had (took) the time to read through this. Very, _very_
interesting. So whose arms must I twist to get this a) released, and
b) to run on GT.M?

A few questions left: will all of what I read in the whitepaper
be released under the GPL? Including the CORBA and the ODMG bits?
And does the latter include OQL? Those would be major enablers
for me.

And while we're on the topic: does Mumps have any native
searching/indexing facilities? Or is Mumps more about persistance
then datamining? How about data discovery? Do you have to know
what's in a Mumps database to be able to access it, or can one
discover format and content as I would be able to in an SQL
database? I guess what I'm asking is, is meta-information available
automatically?

Emile

Re: [Sanchez-gtm-core] gtm and VistA

[Georg L. <jor...@gm...>]

Hello!

Thank you all for your help and explanation.

On Mon, Nov 27, 2000 at 11:16:33AM -0500, K.S. Bhaskar wrote:
> As noted in the Source Forge forum in response to the postings about
> VistA migration, this is a feature and not a bug.  At startup, each
> GT.M executable checks that $gtm_dist points to the directory from
> which it was invoked.  Since a machine may have multiple versions of
> GT.M installed, this is a safety check (so that, for example, a mumps
> process will invoke the gtmsecshr from its version rather than another
> version).

The "alias" feature is explained now, on unices with symlinks however
I suppose that you could install the executable in one place and
symlink to it from other names and places, then check inside, though
have not thought to it into detail.

Now I could also read in the whole FM22.MSM file with "DO ^%RI",
however I had to convert MS-DOS CR-LF secuences to Unix CR only line
terminators so it would recognice the lines.

I would suggest to put an automatic line-terminator recognize facility
on the todo list, with a low priority.

Of course the duplicate labels have gone, what is left over is the
missing MERGE and $EXPECT() on left side of equations.

It seems to me that there are workarounds for these (anybody can tell
me more?) but of course there is the question, when, how and who will
implement it.

Best Regards,

	Jorge-León

Re: [Sanchez-gtm-core] gtm and VistA

[K.S. B. <k.b...@sa...>]

As noted in the Source Forge forum in response to the postings about
VistA migration, this is a feature and not a bug.  At startup, each
GT.M executable checks that $gtm_dist points to the directory from
which it was invoked.  Since a machine may have multiple versions of
GT.M installed, this is a safety check (so that, for example, a mumps
process will invoke the gtmsecshr from its version rather than another
version).

Bob's solution would work.  Alternatively, you can ensure that
$gtm_dist points to the directory in which the shell finds the "mumps"
and other programs when you execute them.

-- Bhaskar

On Monday, November 27, 2000 at 09:44:22 (GMT-0600), Bob Isch wrote:
 > >   $ mumps -dir
 > > %GTM-E-GTM_DIST, $gtm_dist should point to the current directory mumps
 > resided i
 > >
 > 
 > This seems to be a bug.  I have found that using an alias that includes the
 > path solves this problem.
 > I typically use:
 > 
 > alias gtm='$gtm_dist/mumps -dir'
 > 
 > Although the following would probably work too:
 > 
 > alias mumps='$gtm_dist/mumps'

<...snip...>

Re: [Sanchez-gtm-core] gtm and VistA

[Bob I. <bob...@em...>]

>   $ mumps -dir
> %GTM-E-GTM_DIST, $gtm_dist should point to the current directory mumps
resided i
>

This seems to be a bug.  I have found that using an alias that includes the
path solves this problem.
I typically use:

alias gtm='$gtm_dist/mumps -dir'

Although the following would probably work too:

alias mumps='$gtm_dist/mumps'

>
> Second I have to rename FM22.MSM to FM22.m for mumps to recognise
> it.

As Jim pointed out, it looks like FM22.MSM is a "routine save" format file.
You
can use MUPIP to convert it into separate files (check the docs for
specifics).
This will solve your multiple label problems too.

Good Luck.

Re: [Sanchez-gtm-core] gtm and VistA

[Jim S. <ja...@uc...>]

Jorge,
Georg Lehner <jor...@gm...> wrote:
>Hello!
>
>I downloaded the VistA kernel and made a first try on the
>Filemanager-module FM22.MSM

I wish you luck and will help if I can. I think Fileman is a good start for
porting VistA but a daunting task in itself. My personal preference is to
concentrate first on systematic testing of GT.M to see how it compares to
the standard and to other MUMPS.

>First I have to say, that Fileman Ver. 22 requires 1995 Standard M per
>Documentation. I did not check the docs, if gtm claims to be
>compatible to this standard, but my test seems to say that not.

You are correct for the present, however that is a goal.

>First issue has been with useing gtm. If I want to invoke mumps I
>have to define:
>
>  $ gtm_dist=/usr/local/gtm
>
>but this is not enough, I have also to
>
>  $ cd /usr/local/gtm
>
>if I do not I get the following error:


This is not necessary. I run gtm from my home directory. You do need to set
up your own mumps.gld - Bhaskar and others left instructions on sourceforge. 

>  $ mumps -dir
>%GTM-E-GTM_DIST, $gtm_dist should point to the current directory mumps
resided i
>
>My environment shows:
>
>  gtm_dist=/usr/local/gtm
>  gtmgbldir=mumps.gld
>
>
>Second I have to rename FM22.MSM to FM22.m for mumps to recognise
>it.


This won't work very well since FM22.MSM is a list of routines that must be
separated out.

>Now, I'm a complete newbie to Mumps, so I can only interpret the error
>messages given.
>
>First there are several:
>
>$EXTRACT =  ... on left side of asignations in the module, which is
>seemingly not allowed in gtm. (But in the 1995 Standard as per Mumps
>by Example).
>
>Second, the MERGE command is not known to gtm.

Yes. These should be listed as bugs or as missing features relative to 1995
standard.

>Third there is some kind of duplicate labels, I suppose to define
>modules or namespaces or whatever, which are signalled as duplicate
>labels. On the other hand there are a lot "OUT" routines, each in its
>separate section, I suppose separated normaly by this
>module-duplicate-labels, example:
>
>------------
>Saved by %RS from [VCC,FMA] on  5-SEP-2000 13:47:29.76
>FILEMAN VERSION 22 WITH PATCHES 1-17, 19-40, 43-48, 50, 51, 53, 54, 56, &
57
>DDBR
>DDBR    ;SFISC/DCL-VA FILEMAN BROWSER ;NOV 04, 1996@13:46
>        ;;22.0;VA FileMan;;Mar 30, 1999
>        ;Per VHA Directive 10-93-142, this routine should not be modified.
>EN      N DDBC,DDBFLG,DDBL,DDBPMSG,DDBSA,DDBX,IOTM,IOBM
>...
>------------
>DDBR is signalled as duplicate label.

The routine name standing on a line by itself is part of the multiple
routine listing format. It is not part of the routine. The first line of
each routine generally begins with a label identical to the name.

>Of course the first and second line also raise errors, I would not be
>surprised if someone told me that I stupidly have not used a commonly
>know tools which splits this file into several chunks and reads them
>in individually thus solving all the problems at once.
>
>If VistA Fileman is not know to Sánchez yet, let me tell you from the
>manual (as I have never seen it running by myself):
>Fileman provides a database interface, reports, line- and
>screen-editor, and some programmers utilities used throughout the
>whole VistA Core and Aplications.

Fileman is indeed foundational to VistA. I hope to see it running on GT.M
very soon, provided that we can get the missing features added. 

>Now, about postings:
>
>On Sat, Nov 25, 2000 at 09:39:58AM -0500, K.S. Bhaskar wrote:
>> Georg --
>> 
>> In order to prevent going over the same ground, would it be OK to request
>> that you post this to one of the Discussion forums?  I will reply there,
and
>> we will have a record for future inquirers.
>...
>
>I have looked again at Sourceforge. To post to a Discussion forum
>requires me to make a login and submit the post online.

I think this is a problem for many people. It would be best if we could
reply via email and only access the forum as an archive. This would be
mitigated somewhat if the forums had a richer capability for incorporating
html formatting and editing messages.

>In my case I have to pay quite a money for the connection and for the
>telefone too because of the slow dialup-line (There is nothing faster
>available in Nicaragua) and therefore until now have always very
>apreciated the use of mailing lists in the groups where I am
>participating.
>
>It is not feasable for me to spend sufficient time online to make
>postings via a Web-based interface, moreover, that I have to do it at
>home, because at work I do not have access to Internet at all.
>
>In the GNUe project, for example, it is somewhat frustrating, that
>aparently most of the discussion goes over IRC, while this is
>impractical for me. The chatters do seldom distill their discussion
>into a post to the list and we "only-posters" are out.
>
>Another point I noticed with GNUe was, that at some moment discussion
>was split "systematically" into one mailing list for each mayor
>module. This has lead - in my opinion - that most of the people
>subscribe to all the lists, so the deal is: more administrative work
>for everybody.
>
>I would have preferred a small number of mailing lists and a split-off
>only if various continuos threads about different themes with active
>developers behind them evolve.

I generally agree with this idea.

>On gtm's Sourceforge account I see also a lot of different "what is if
>they ask for it" Discussion forums, but by now only two of them have
>postings. This could tend to confuse someone "passing by" the Web-site
>as she would not know where to begin to read, and causes more work for
>die-harders, as they read anyway everything.
>
>Intelligent Mailreaders can do a lot for the individual to manage
>intelligently bulks of mail, and they do have the advantage, that the
>user decides how to sort mail, not "the group".
>
>Best Regards,
>
>        Jorge-León
>
>P.S.: I herewith apologize for posting a too long mail, and for
>adressing two different subjects in one posting.
>_______________________________________________

---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)

Re: [Sanchez-gtm-core] gtm and VistA

[Georg L. <jor...@gm...>]

Hello!

I downloaded the VistA kernel and made a first try on the
Filemanager-module FM22.MSM

First I have to say, that Fileman Ver. 22 requires 1995 Standard M per
Documentation. I did not check the docs, if gtm claims to be
compatible to this standard, but my test seems to say that not.

First issue has been with useing gtm. If I want to invoke mumps I
have to define:

  $ gtm_dist=/usr/local/gtm

but this is not enough, I have also to

  $ cd /usr/local/gtm

if I do not I get the following error:

  $ mumps -dir
%GTM-E-GTM_DIST, $gtm_dist should point to the current directory mumps resided i

My environment shows:

  gtm_dist=/usr/local/gtm
  gtmgbldir=mumps.gld


Second I have to rename FM22.MSM to FM22.m for mumps to recognise
it.

Now, I'm a complete newbie to Mumps, so I can only interpret the error
messages given.

First there are several:

$EXTRACT =  ... on left side of asignations in the module, which is
seemingly not allowed in gtm. (But in the 1995 Standard as per Mumps
by Example).

Second, the MERGE command is not known to gtm.

Third there is some kind of duplicate labels, I suppose to define
modules or namespaces or whatever, which are signalled as duplicate
labels. On the other hand there are a lot "OUT" routines, each in its
separate section, I suppose separated normaly by this
module-duplicate-labels, example:

------------
Saved by %RS from [VCC,FMA] on  5-SEP-2000 13:47:29.76
FILEMAN VERSION 22 WITH PATCHES 1-17, 19-40, 43-48, 50, 51, 53, 54, 56, & 57
DDBR
DDBR    ;SFISC/DCL-VA FILEMAN BROWSER ;NOV 04, 1996@13:46
        ;;22.0;VA FileMan;;Mar 30, 1999
        ;Per VHA Directive 10-93-142, this routine should not be modified.
EN      N DDBC,DDBFLG,DDBL,DDBPMSG,DDBSA,DDBX,IOTM,IOBM
...
------------
DDBR is signalled as duplicate label.

Of course the first and second line also raise errors, I would not be
surprised if someone told me that I stupidly have not used a commonly
know tools which splits this file into several chunks and reads them
in individually thus solving all the problems at once.

If VistA Fileman is not know to Sánchez yet, let me tell you from the
manual (as I have never seen it running by myself):

Fileman provides a database interface, reports, line- and
screen-editor, and some programmers utilities used throughout the
whole VistA Core and Aplications.


Now, about postings:

On Sat, Nov 25, 2000 at 09:39:58AM -0500, K.S. Bhaskar wrote:
> Georg --
> 
> In order to prevent going over the same ground, would it be OK to request
> that you post this to one of the Discussion forums?  I will reply there, and
> we will have a record for future inquirers.
...

I have looked again at Sourceforge. To post to a Discussion forum
requires me to make a login and submit the post online.

In my case I have to pay quite a money for the connection and for the
telefone too because of the slow dialup-line (There is nothing faster
available in Nicaragua) and therefore until now have always very
apreciated the use of mailing lists in the groups where I am
participating.

It is not feasable for me to spend sufficient time online to make
postings via a Web-based interface, moreover, that I have to do it at
home, because at work I do not have access to Internet at all.

In the GNUe project, for example, it is somewhat frustrating, that
aparently most of the discussion goes over IRC, while this is
impractical for me. The chatters do seldom distill their discussion
into a post to the list and we "only-posters" are out.

Another point I noticed with GNUe was, that at some moment discussion
was split "systematically" into one mailing list for each mayor
module. This has lead - in my opinion - that most of the people
subscribe to all the lists, so the deal is: more administrative work
for everybody.

I would have preferred a small number of mailing lists and a split-off
only if various continuos threads about different themes with active
developers behind them evolve.

On gtm's Sourceforge account I see also a lot of different "what is if
they ask for it" Discussion forums, but by now only two of them have
postings. This could tend to confuse someone "passing by" the Web-site
as she would not know where to begin to read, and causes more work for
die-harders, as they read anyway everything.

Intelligent Mailreaders can do a lot for the individual to manage
intelligently bulks of mail, and they do have the advantage, that the
user decides how to sort mail, not "the group".

Best Regards,

	Jorge-León

P.S.: I herewith apologize for posting a too long mail, and for
adressing two different subjects in one posting.

RE: [Sanchez-gtm-core] gtm and VistA

[K.S. B. <k.b...@sa...>]

Georg --

In order to prevent going over the same ground, would it be OK to request
that you post this to one of the Discussion forums?  I will reply there, and
we will have a record for future inquirers.

Thanx and regards
-- Bhaskar 

-----Original Message-----
From: Georg Lehner
To: san...@li...
Sent: 11/24/00 10:59 PM
Subject: [Sanchez-gtm-core] gtm and VistA

Hello!

I would like to know few things:

- Is anybody on the list involved or known to the VistA medical
  software? Is an effort underways to port it to gtm? Where can I
  join?

- When will sources for gtm be available? It seems to me, only until
  then it would be GPL.

- If Sánchez is making available the sources for gtm, what point will
  it make to maintain the other platforms propietary? Do you have
  so different codebases for the different platforms? Well, I suppose
  that if there is a lot of assembly-code in it, it would be difficult
  to port it to another platform, but if it is in C???

Best Regards,

	Jorge-León
_______________________________________________
Sanchez-gtm-core mailing list
San...@li...
http://lists.sourceforge.net/mailman/listinfo/sanchez-gtm-core


*************************************************************************** 
This electronic mail transmission contains confidential and/or privileged 
information intended only for the person(s) named.  Any use, distribution, 
copying or disclosure by another person is strictly prohibited. 
*************************************************************************** 

[Sanchez-gtm-core] gtm and VistA

[Georg L. <jor...@gm...>]

Hello!

I would like to know few things:

- Is anybody on the list involved or known to the VistA medical
  software? Is an effort underways to port it to gtm? Where can I
  join?

- When will sources for gtm be available? It seems to me, only until
  then it would be GPL.

- If Sánchez is making available the sources for gtm, what point will
  it make to maintain the other platforms propietary? Do you have
  so different codebases for the different platforms? Well, I suppose
  that if there is a lot of assembly-code in it, it would be difficult
  to port it to another platform, but if it is in C???

Best Regards,

	Jorge-León

[Sanchez-gtm-core] New forums at Source Forge

[K.S. B. <k.b...@sa...>]

As the discussion with Emile continued, I realized that it would be
preferable to have the discussions in the Source Forge forums so that
they are more easily preserved for the future (yes, I know that this
mailing list is archived, but the archive is not tied to Source Forge).
So, I have created a bunch of forums, hopefully along somewhat rational
lines.  Please choose the "Monitor forum" option for your favorites,
and any posting there will be immediately e-mailed to you.

-- Bhaskar