GT.M vs Cache

[stuffduff]

Hi,

One of my recent (though currently abandoned projects is
http://sourceforge.net/projects/pygtm/ so I'm not quite a neophyte.

The last time I was a professional Mumps programmer was '79 through
'93 and my personal preference during that time was DSM-11.

I have looked on the internet but whet I've read has left me with
little feeling for how to represent the human cost of implementing a
large project single-handedly with either product.

Not here to bash anything, or anyone, but need the opinions of some
more recently experienced hands to guide me in this next step.

My boss, who needs help making popups in Powerpoint went to an
Intersystems presentation and now he is convinced that Cache is the
way to go. I'd prefer a more direct approach as offered by GT.M.

I have met, know and trust the people behind GT.M, but I need some
information on a comparison of tools, performance and learning
curves.

From the cache literature it seems that there may be dozens of things
like 'initial learning curve' + many 'short and rapid learning curve'
+ 'Shorter Learning Curve" etc. My impression is that cache really
offers everything, jalapeno, basic, etc but I haven't found a plain
old mumps interface that I feel comfortable with.

I'm concerned that the sum of the many learning curves and the
multiplicity of products and language extensions/transmogrifications
for other languages/programmers will actually make it difficult for a
single programmer to use cache effectively. I'm really not sure that
I need all that stuff and am leery of a product that promises to be
everything to everybody.

I'd like some information on where I can find some realistic
comparisons of learning curves, training costs, class availabilities,
support, and per seat/server costs etc.. My goal is to come up with a
well documented presentation to indicate that one of the two will
offer significant benefits.

One concern is that we will be interacting with an EPIC system, but
I'm hoping that that communication is made via some protocol and not
strictly through a cache add-on.

Any 'Boss-Talk' pointers or other 'managerial propaganda' may be of
some help. However what I believe will be most valuable are the
results and insights of individuals who have used both products.

But if you've only used one and really believe it is the right choice
please chime in.

All help sincerely appreciated

Sean

[OldMster]

Sean,

The first thing to determine is if the project requires any 'Cache Specific' features, like direct access to Cache database files through namespace mapping, or through ECP networking connections.  If all the interactions are at 'arms length' through a defined API using TCP/IP or someother 'standard' protocol, then Cache has no significant advantage over GT.M.  I like Serenji better than Studio, and after making a big committment to Cache objects a few years ago, I'm now unwinding all the code that uses them to use 'standard' M globals.  For me, they have just gotten to 'heavy' and the overhead is now noticeable.

If you need to provide SQL access to data created/Stored in the system you are developing, you can look at KBase/SQL - it provides SQL mapping of globals on all platforms.

Mark

[VistAuser]

Sean,

We are currently implementing a big size VistA implementation project
on GT.M and did lot of comparison work for GT.M versus Cache in the
begining of project.

Both databases have different philosophies and are better in their own
ways. Cache provide lot of cache specific features as Mark mentioned
on top of what MUMPS offers. It has well developed code studio,
debugger, portal for system management tasks , SQL ODBC connectivity,
Java and Dot Net projections classes, unified data dictionary,
database level security controls . provide ECP classes for active
active load balancing etc.

GT.M on the other hand is an open source database which works with
Native OS tools to manage all DB management and administration tasks
and in some manner it provide some flexibility as any Linux supported
tool could be used to monitor DB. A simple TOP command in Linux shell
can tell all about GT.M MUMPS process running in memory.

We did load testing with VistA on GT.M and it supported a very good
performance with over 1500 concurrent users on a high end server class
machine. It support replication with up to 16 secondary nodes for a
primary and a very reliable DR solution can be designed using GT.M.

GT.M 64 bit provide mechanism to create shareable code libraries with
routine image loaded once in shared library could be accessed in all
concurrent processes accessing it thus a high performance.

On the lower side, GT.M database management and administartion has to
be done at Linux OS level and no DB tools or portal available to
manage these tasks. Linux editors to be used for code writing or
debugging. Although there are tools e.g. Serenji that could be used
with it for debugging tasks. It does not work in active active load
balancing cluster and only support active passive mode.

GT.M does not provide ODBC connectivity with relational
databases .KB_SQL provide SQL mapping for all globals as Mark
mentioned if SQL access is required in any application.

VistA was originally developed in cache in VA and GT.M does not
support UCI or namespace in VistA and many of the routines in VistA
had to be changed to work with GT.M although most of them are
available thanks to the hard work done by contributers in this forum.

cost wise there is whole lot of difference between GT.M and Cache. IMO
there is a good choice between the two variants of MUMPS platform and
actual project requirements should be the deciding factor to go in
either's favour.

Regards
Krishan

[Joseph Dal Molin]

"VistA was originally developed in cache in VA" .... original development of VistA not on Cache, it didn't exist back then.... :-)

[r...@rcresearch.us]

Here are some of the history of the VistA technology;

VistA was originally called DHCP (1977 thru 1985, or so) and was developed
on DSM-11 (there may have been DSM-15, prior to the DSM-11), later is was
running on M-11-plus (Intersystems), then Datatree, and then Micronetics
MUMPS, then Cache and GTM. In there, somewhere was M-Global, and a couple
of other MUMPS implementations were ported. VistA is very portable and
easily adapted to other environments. There are core routines in the
Kernel that supply most of the services that the other 160 application
areas depend upon. Most new interfaces are implemented into the Kernel so
that they can be made available as services to the rest of the
applications without modification of the application code.

> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>

[dwarika singh]

we are also planning to take up VISTA EHR on GTM and EWD and looking for some agency/individual for collaboration on long term basis to customize the product for indian hospitals.....   let me know if any one can help for the same......

[John Bertoglio]

Agree with Mark on all points. Something he mentioned in passing is the formal object model in Cache. While fairly well implemented, it REALLY puts you at arms length from your data. And, for reasons I do not fully understand, you cannot specify an index for SQL...you have to take what the internal "optimizer" decides is best. Of course, SQL is one of those sneaky technologies that make easy things really easy (compared to filtering globals) and complex things really hard. GT/M does not have all the refinements that have been added to Cache over the years. And if you perceive that your system may require the occasional visit from an ISC SWAT team...that is also a consideration. Otherwise, GT/M makes a lot of sense. Especially as a back end for Rob Tweed's new EXT.js stuff. Perhaps someone more sophisticated than myself will write a management portal for GT/M using EWD.js and Node that will eliminate Cache's advantage there!

Note that all the "cool" features like class projection pretty much require the use of Cache objects. This is a BFD if you are used to working with raw globals.

[Budy]

Mark,

I'm the opposite. When we moved from M to Cache Object, I don't want to go back. 

Sean,

I suggest you play with Cache Object. Use OOP paradigm, use Method, property, extend rather than just calling procedures from ClassMethod to another ClassMethod.

it's unfortunate that many programmers are using the old procedural rather than OOP technique even the language has that capability. This is true not just Cache Object, some  Delphi or C#, developers also still think in term of procedures.

SQL is another huge advantage. You can easily map your old globals to SQL tables. I have to say the performance is amazing and Cache has a good SQL analyzer tool.

You won't believe how easy it's to create a webservice or Cache Server Page.  I can see it, our frequent group contributer the genius Mr. Tweed (EWD founder) is the brain child for those technologies.

[OldMster]

Budy,

I love programming in objects, I just find the Cache Object implementation too poorly done.  I was done with it when  a save of  a minor change kicked off a recompile of virtually every object in the system, for no reason I could fathom, since that object was not embedded in nor did it embed any other objects.  This brought down or cause virtually all the running processes to error with an 'object recompiled' error.

Javascript objects on the other hand, are real, dynamic objects that require no 'compiling' and are wonderful.

Mark

[Budy]

I don't think we can judge how they implemented Object because they know their product or limitiation better than us.

Regarding recompilng, there is a switch to just compile your class.

I did remember experiencing your recompile issue in the older version (but it was usually because object dependancy - never the entire objects in the system) and also we usually worked on development namespace where no background processes were running so I didn't have your issue.

For me at least, maintaining cache object codes is much easier than straight M.

[Nancy Anthracite]

If a developer or company has an interest in being part of the open source community, Cache Objects in the code essentially cut out a large chunk of the community from making use of the code. MOCHA caused a huge headache because it uses Cache Objects, among other things.

 

If a developer or company had its own version of VistA and no interest in sharing code, and have little interest in writing code that will be usable by those who can't afford to use Cache, then it matters little whether Cache Objects are used or not.

 

--

Nancy Anthracite

[Budy]

Agree with you 100% except with "no interest in sharing code". I don't think choosing one programming technique over another has anything to do with "interest of sharing code".

For me, maintainability is priority one and OOP helps manage complexity. Beyond that I hope Cache or even GTM extends their tecknology to give developers tool for Interface based design (IOC).

Don't get me wrong, I'm not prefering one M implementaion over another. I just want M to flourish and we should embrace evolution of M.

[Kekoa]

InterSystems did what they needed to do as a company... they evolved for the betterment of it's customers. Having said that I never understood why the MDC fell apart; it would have been nice to see the standard enhanced to support OOP; similarly as C did with C++. Typically when someone asks for SQL support in M, folks refer them to KB_SQL. When someone wants web development in M, folks refer them to EWD. So guess what? This thread basically tells me there is a business opportunity to create a Cache Objects run time environment for GT.M. After all - Cache Objects when compiled are cross compiled into M... the whole business idea reminds me of EsiObjects.

Sooo as Nancy has previously mentioned, other packages are using Cache Objects and that number is rising... just look at the new IHS Scheduler - Cache Objects all up in it yo! As the VA and IHS continue to release packages that contains Cache Objects we can choose to rewrite and maintain yet another fork? 

Speaking of affordability - is it cheaper to buy KB_SQL + EWD + M vs Cache? Don't forget to calculate how much money you save by going with Cache and not having to reverse Cache Object packages such as MOCHA and IHS Scheduler. Yes - I'm asking because I have no clue how much any of the M vendors cost.

[Bhaskar, K.S]

In addition to EsiObjects, there is also FIS PIP (http://fis-pip.com) which comes with a lightweight OO language (which is compiled into M for execution), and also a SQL engine with a JDBC driver.  The main reason I recommend KB_SQL for use with VistA is that it has a tool to map Fileman files into SQL tables, which PIP lacks.  There is also Medsphere's FM Projection (https://launchpad.net/fm-projection) which is a proof of concept waiting for someone to take it further.  It maps Fileman files to MySQL (presumably now MariaDB) tables, allowing the use of the MySQL SQL engine and ODBC/JDBC drivers.

So, there are lots of free / open source tools (and by free I mean libre, not gratis - see http://en.wikipedia.org/wiki/Gratis_versus_libre).

Regards
-- Bhaskar

--

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Arya Rasouli]

Hey Dwarika,

I'm a part of a group of professionals working for Johns Hopkins Hospital Oncology Information system. We have maintained and developed MUMPS based EHR for more than 3 decades. We've done thick client, thin client and cloud applications for desktop, mobile and kiosks. If you still are looking for a great pool of talent for collaboration make sure you you contact me.

[amjad.s...@gmail.com]

Dear Mr K.S. Bhaskar 

We have MUMPS GT.M Database , any good document to setup FM Projection or any free tool to access GT.M using ODBC/JDBC , i didn't find FM Projection Setup File or any installation document .

Thanks 

Amjad

[Sam Habiel]

Amjad,

http://bazaar.launchpad.net/~fm-projection+team/fm-projection/trunk/view/head:/INSTALL

Did you read this before asking your question?

--Sam

[K.S. Bhaskar]

Amjad --

Sam's advice is good.

In addition to GT.M, there's also YottaDB (highly common code base - check out http://yottadb.com). As I'm no longer at FIS, you can reach me at bha...@bhaskars.com or bha...@yottadb.com.

Regards
-- Bhaskar