Mumps to Java

[suchi karuna]

Hi All,

I have downloaded the code from Software revolution to convert the
openVistA Mumps Code to Java.
But i dont find the required files like Tsrilib.* and Mumps Package.
Can anyone help me to get those files.
Thanks for Any Help.

Thanks,
Suriya

[Suriya.K]

Hi All,

Thanks,
Suriya.K

[David Whitten]

I'm sure several people on this mailing list have opinions about this,
however, could you share download information for the Software Revolution
site that you have mentioned so other folks can download it as well?

David

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

To unsubscribe, reply using "remove me" as the subject.

[Ben Mehling]

http://www.softwarerevolution.com/open-vista/

M to Java/RDBMS conversion software, same concept as Cav Systems. I
have a *strong* negative opinion about this approach. Just take a
look at the online documentation of a converted VistA instance!
Unreadable, Unusable and Unmaintainable all spring to mind.

Extend the system with Java, do not convert it to Java....

- Ben

[MGW-Discussions]

I agree with the response, below.

I have not had a chance to get further into my investigation of the
MUMPS implementation for Vista, however,
I do see the benefit of simply utilizing the jstls that are out there,
to augment the Vista engine. I like to think of it as using Vista as a
"kernel" if you will, for further extension using java, where java would
be considered the "user-land" interfacing component.

However, as I indicated, I have not had a chance to extend my project,
or rather experimentation, into further java-based EHR development, and
this is all in theory.

--
Respectfully,

Martes G Wigglesworth
M. G. Wigglesworth Holdings, LLC
www.mgwigglesworth.com

[Steven McPhelan]

As CAV systems state, you can't fix the logic or coding style within a M application, all they can do is translate it.  It is the case of GIGO.  However, it is difficult to counter their main argument.  If one has made the business decision (for whatever reasons) to convert a M application, especially a large one, to the Java/SQL framework, then this is not a bad approach.  You now have the source code in Java for which one has presumably ramped up for instead of M code.

 

The VA has taken the other approach.  Review the M code and then write all new code on another platform.  Look has long it has taken them and they still do not having a working prototype for ALL of VistA.  How many companies have the resources, time, and luxury to take this approach.

 

I do not know which approach is better if you have made the decision to migrate away from M.  I will let the first wave of attempts work their way through to see which approach ended up being the better decision.

 

Remember my first assumption, one has made the decision to migrate off of M.

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

To unsubscribe, reply using "remove me" as the subject.

--
Steve
Dreams will get you nowhere, a good kick in the pants will take you a long way - Baltasar Gracian

[Ben Mehling]

On Sat, Apr 3, 2010 at 4:56 PM, Steven McPhelan
<smcp...@alumni.uci.edu> wrote:
> As CAV systems state, you can't fix the logic or coding style within a M
> application, all they can do is translate it.  It is the case of GIGO.
> However, it is difficult to counter their main argument.  If one has made
> the business decision (for whatever reasons) to convert a M application,
> especially a large one, to the Java/SQL framework, then this is not a bad
> approach.  You now have the source code in Java for which one has presumably
> ramped up for instead of M code.

I suppose you may have the code converted -- put the proof is in your
ability to expand upon and maintain that new codebase. The conversion
system mentioned in this thread has published extensive (automatically
generated) documentation showing the code conversion in detail (see
the link). I would be interested to hear opinions from Java developers
(M, too -- but more so from the folks that would have to maintain the
codebase) on how workable they felt the solution was...

> I do not know which approach is better if you have made the decision to
> migrate away from M.  I will let the first wave of attempts work their way
> through to see which approach ended up being the better decision.

I would add a third approach -- extension of the platform. I think
the model of building upon the foundation is just as valid (and
obviously, I think will be more successful in the long run -- now that
I think about it, has either of the other approaches been
successful?).

- Ben

[Steven McPhelan]

One of the premises is that you have more talent in Java than M or your business plan is to migrate to Java.  It would be reasonable to unravel the Java code with your staff than trying to do that with the M code for which your business decision is to not support M.

 

Obviously many have made the business decision to stay with M in which case my IF statement is invalidated and thus the THEN conclusion is of no consequence.

On Sat, Apr 3, 2010 at 8:41 PM, Ben Mehling <ben.m...@medsphere.com> wrote:

 

I suppose you may have the code converted -- put the proof is in your
ability to expand upon and maintain that new codebase.  The conversion
system mentioned in this thread has published extensive (automatically
generated) documentation showing the code conversion in detail (see
the link). I would be interested to hear opinions from Java developers
(M, too -- but more so from the folks that would have to maintain the
codebase) on how workable they felt the solution was...

> I do not know which approach is better if you have made the decision to
> migrate away from M.  I will let the first wave of attempts work their way
> through to see which approach ended up being the better decision.

I would add a third approach -- extension of the platform.  I think
the model of building upon the foundation is just as valid (and
obviously, I think will be more successful in the long run -- now that
I think about it, has either of the other approaches been
successful?).

- Ben

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

To unsubscribe, reply using "remove me" as the subject.

[I, Valdes]

Re factor.

See Joel on Software 'Architecture Astronauts'
http://www.joelonsoftware.com/items/2008/05/01.html

-- IV

On Apr 3, 7:59 pm, Steven McPhelan <smcphe...@alumni.uci.edu> wrote:
> One of the premises is that you have more talent in Java than M or your
> business plan is to migrate to Java.  It would be reasonable to unravel the
> Java code with your staff than trying to do that with the M code for which
> your business decision is to not support M.
>
> Obviously many have made the business decision to stay with M in which
> case my IF statement is invalidated and thus the THEN conclusion is of no
> consequence.
>

> On Sat, Apr 3, 2010 at 8:41 PM, Ben Mehling <ben.mehl...@medsphere.com>wrote:
>
>
>
>
>
> > I suppose you may have the code converted -- put the proof is in your
> > ability to expand upon and maintain that new codebase.  The conversion
> > system mentioned in this thread has published extensive (automatically
> > generated) documentation showing the code conversion in detail (see
> > the link). I would be interested to hear opinions from Java developers
> > (M, too -- but more so from the folks that would have to maintain the
> > codebase) on how workable they felt the solution was...
>
> > > I do not know which approach is better if you have made the decision to
> > > migrate away from M.  I will let the first wave of attempts work their
> > way
> > > through to see which approach ended up being the better decision.
>
> > I would add a third approach -- extension of the platform.  I think
> > the model of building upon the foundation is just as valid (and
> > obviously, I think will be more successful in the long run -- now that
> > I think about it, has either of the other approaches been
> > successful?).
>
> > - Ben
>
> > --
> >http://groups.google.com/group/Hardhats

> > To unsubscribe, send email to Hardhats+u...@googlegroups.com<Hardhats%2Bunsu...@googlegroups.com>

[I, Valdes]

As well as:

http://www.joelonsoftware.com/articles/fog0000000018.html

[K.S. Bhaskar]

Here's my personal two bits' worth for what they're worth.

The real problem with automated conversion of VistA source code from
MUMPS to Java is that it converts some tens of MB of expert-friendly
code into hundreds of MB, perhaps even GB, of unfriendly-even-to-
experts code.

The real business opportunity with automated conversion of VistA
source code from MUMPS to Java is to persuade people who have more
money than sense (those that think they know enough about software to
believe that Java is not just a programming langunage, but is the next
great innovation after the computer controlled flush toilet) to part
with it. After all, the conversion tools have to be developed and the
translated software has to be tested and corrected (just think of
Xecute commands and indirection). Once you have the software
converted, you have an opportunity to seek funding to reverse engineer
the code, make it readable and maintainable. And there's no need to
deliver anything that is deployable in production for years. D-r-o-o-
l!

Regards
-- Bhaskar

P.S. I learned MUMPS and Java around the same time, in 1995, and for a
while was equally (un)comfortable in both. I have nothing against
either - they're both fine programming languages and each has its
strengths and weaknesses. But they're programming languages, not
religions.

[Uri Schor]

CAV Systems Ltd ceased engaging in discussions that take place in
Hardhats and other MUMPS-related forums some time ago despite the fact
that we are one of the few remaining companies in the world with an
unbroken 3 decade history of successful profitable organic growth as a
vendor of MUMPS-based solutions in an increasingly competitive market
… and we continue to be successful – not because of MUMPS but despite
it. What was once a competitive advantage for us has turned into an
albatross, not because we became less competent or because MUMPS
regressed. It’s because the world around us changed – and MUMPS (and
its derivatives) no longer answered the needs of that changing world.
These changed circumstances dictated that CAV Systems likewise change
or pay the ultimate price – a slow and agonizing corporate death by a
thousand cuts. Unlike the US Federal government and its agencies, CAV
Systems cannot afford the luxury of throwing tens or hundreds of
millions of dollars at a problem – and fail. As a private company, we
get one shot at succeeding – and the key to success is paying
attention to the market and what it is saying. And the message was
loud and clear: IT’S THE DATABASE THAT IS THE STRATEGIC ISSUE – NOT
THE PROGRAMS. The market (i.e. our customers and, more importantly,
our prospective customers) were clearly saying to us “It’s the
database, stupid” (with apologies to William Jefferson Clinton!).
Their reasons had very little to do with the technical merits of one
type of database versus another. They themselves were reacting to and
responding to their market dynamics. To make the point as clear as we
possibly can, if we had somehow come up with an approach whereby the
programs were converted from MUMPS to elegant Object-oriented Java or C
++ but the database was still MUMPS, we would probably be today in the
final stages of “death by a thousand cuts”. Fortunately, we are not
and the reason is simple – we have a roadmap to the future that we,
and more importantly, our customers appreciate and fully understand –
and, the remarkable and unexpected surprise for us has been that most
of our installed base is remaining with MUMPS for the time being
precisely because they now feel reassured [comment: an example of “The
Law of Unintended Consequences].

So, you may well ask “What is the relevance of all this to VistA?”.

The main problem with VistA's infrastructure is not MUMPS the
PROGRAMMING LANGUAGE – it’s MUMPS the DATABASE. Until and unless the
underlying database is one of the prevailing relational databases –
proprietary or open-source – it is our view that VistA will never be
able to gain traction outside of the VA to the level – the critical
mass – that any such system needs in order to become “sustainable” –
and “sustainable” encompasses many elements, the most important of
which is IT professionals who can see some future in becoming
involved.

The reason we ceased participating in the various blogs and forums
related to MUMPS is simply because they tend to generate more heat
than light – and degenerate from there. So rather than once again
become a catalyst for another such discussion of the technical merits
of MUMPS or of CAV Systems’ approach to migration to Java/Relational
(JUMPS), I’ll close with the following hard (and verifiable) facts:

TATRC funded a pilot project back in April 2008 to evaluate JUMPS by
converting DoD/MHS's CHCS Radiology module. The prime contractor
evaluating the technology was a well-known player supporting both
VistA and CHCS. During 8 work days, 2 CAV engineers who had never seen
CHCS before, demonstrated a fully automated migration of the CHCS
kernel and the Radiology module to a functionally equivalent
application running on Java/Oracle [note: in the interests of full
disclosure, I was one of those CAV engineers]. On the basis of that
success, the prime contractor recommended that TATRC fund further
evaluations in greater depth including the potentially significant
ramifications that this very different approach to MUMPS migration
would have when scaled up to organizations the size of DoD/MHS and VA.
Unfortunately (i.e. for the US taxpayer), vested interests felt
threatened and Beltway politics ensured that these recommendations
were killed stone dead. You can read more here:
http://waysandmeans.house.gov/Hearings/Testimony.aspx?TID=7843.

When JUMPS is being discussed, everyone seems to focus on the code
quality. We have never claimed that the generated code is meant to be
edited directly, because it's not a beautifully-crafted Object
Oriented Java code. Every IT professional understands that you can't
achieve both that AND a fully automated conversion. You have to make a
choice – and we chose “fully automated conversion” because the real
enemy is “time”. In the case of VistA, the original code (from the
little I've seen) is not very pretty either. It was developed over
many years by many people, and due to wide usage of Xecute command in
the VistA kernel, it has low readability and therefore low
maintainability and extensibility. Since we are not in the healthcare
solutions field, I'll take your word that VistA delivers the goods in
terms of functionality, but the code itself cannot be considered state-
of-the-art elegant software that will somehow be made ugly and less
maintainable by automated conversion… this is particularly true in the
case of JUMPS since our approach allows the current team of VistA
MUMPS professionals to continue maintaining and enhancing the system
using MUMPS for as long as the powers-that-be choose. Amazing but
nevertheless true.

Since I'm sure that you're all sincerely committed to the goal of
promoting VistA's adoption outside the VA, perhaps the time has come
for some out-of-the-box thinking by some open minds. We don’t claim to
have a “silver bullet” solution. We do claim that there is enough
verifiable evidence to evaluate further a very different “roadmap to
the future” for VistA than any that has so far been considered.

It’s the database that’s the strategic issue – not the programming
language.

Uri Schor
CTO
CAV Systems Ltd.
uri (at) cav (dot) co (dot) il

[rtweed]

Whilst not suggesting that what Uri has been seeing hasn't been a
common commercial reaction to the Mumps database, the growing momentum
of the NoSQL movement could soon filter down, making management-level
decision-makers less certain that a mainstream relational technology
is really what they need. The trick will be to ensure that GT.M is
firmly up there in the list of recognised NoSQL databases.

Of course we may, instead, then see pressure to move from Mumps to, eg
MongoDB, CouchDB or some such......

Don't pretend the database world isn't changing out there - NoSQL is a
force to be reckoned with.

Personally I'm looking forward to the inevitable need for people
saddled with relational databases to have them ported to a NoSQL one.

[Vipen Mahajan]

Having been into IT for a few decades, I would say that MUMPS definitely has many strengths, as compared to a bloated RDBMS. It is lean, mean, hungry, and sips computing resources. I understand that there are tools/frameworks that can use Python and MUMPS database. Python is increasingly being used for enterprise level programming, like what Java was in the late 1990's. Google is using Python extensively.There is a rich and well developed ERP system, OpenERP, (openerp.com), with a lot of tools for developing using objects, a UML diagrammer, etc.besides a very functionally rich ERP system. The also have developed a Medical module, which I have studied briefly. I was wondering if we could take the proven and rich data-model of VistA, and move it to the OpenERP/Python framework, we may get the best of both worlds. A lean mean database, VistA data-model, and a "modern" object oriented language along with a complete development and modeling environment. Python takes a fraction of the code. OpenERP has taken much of the functionality of Compiere, an Open Source ERP, and was written in about 25,000 lines of code. Compiere , an open SOurce ERP/CRM etc., written in Java and an Oracle database (also ported to Postgres), has a much larger code base.
The OpenERP-Medical has rich practice management functionality as well as EMR a little of the EMR/stuff. It uses the ERP functionality of OpenERP for other things, including billing, accounting, material supply chain, purchasing, HR etc. It has a slick user interface, all GUI, and can be accessed either through a GTK Client, remote or LAN based, or a browser. It might be a good thing for smaller health care setups, and if the datamodel is compatible with VistA, or it can use the VistA MUMPS database itself, it will be an interesting development.

Any takers ? I am studying OpenERP and its Medical module. Some links:
http://medical.sourceforge.net/
http://linuxmednews.com/1252069102

Vipen

  

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

To unsubscribe, reply using "remove me" as the subject.

--
Vipen Mahajan

Principal
Leo Systems
Chicago/Boston/Munich/New Delhi.

Skype - vmahajan
US +1-630-303- 9881. with voice mail facility EMail/Skype/US Phone numbers are the best way to contact me.
Blog/Wiki at www.indiaahead.net/tikiwiki

[fred trotter]

I can understand CAVs reluctance to debate this, since it does get heated.

Happily I can claim neutrality on the technical merits of the
approach. However, so far, I am dubious that any compiled-MUMPS
application, including WebVistA compiler, the CAV compiler, or JANUS,
(which has re-sparked this discussion) can be legitimately can meet
the "free software" definition. To the letter or in spirit.

From http://www.gnu.org/philosophy/free-sw.html

"Obfuscated “source code” is not real source code and does not count
as source code."

Now is the compiled code "obfuscated" or is it merely "dense".

My sense is that unless the automatically generated code does not
count as source code unless:

A. The compiler itself is Free Software, in which case the relevant
"source code" is compiler + original MUMPS.
or
B. The results of the conversion can be modified and maintained as an
ongoing project, and released under a FOSS license.

As far as I know, none of these compilers are themselves FOSS.
ClearHealth, at least, has no intention of releasing the compiler
code. They do not have the resources to support such a compiler (which
would be unlikely to ever make money) and it would be useless without
support. They do, however, claim to fall into the second case. They
are willing to release (if not publish) the results of their
compilation (which are gigabytes of C code) under a FOSS license.
Moreover, they themselves actually modify and maintain that sourcecode
directly. The have written patches at the C level.

ClearHealth is willing to release the C code -results- of the
compilation and at least is willing to take on the code of maintaining
the C code itself as an internal project. But I still feel that this
is problematic. It seems to me that there is nothing that meets the
requirements of many licenses regarding source code: from the GPLv3:

"The “source code” for a work means the preferred form of the work for
making modifications to it. “Object code” means any non-source form of
a work."

The problem with the ClearHealth approach is that it seems to me that
there -is no- preferred form of the work for making modifications.
Moreover, without a FOSS compiler, it may be that the "preferred"
place to make modifications is, in fact, inside the compiler itself.

ClearHealth is treading on a fascinating middle ground for both the
spirit and letter of Open Source with their WebVistA project. But they
contribute some of the results of that process back to the community
as valuable and reusable components (that too few people know about
really), including lots of new components found in ClearHealth 3.0
(which is their php-only clinical project). They are doing good even
if you dubious (like I am) of their WebVistA approach.

Without an Open Source compiler I lump both CAV and JANUS simply into
the "proprietary" camp. The results of the their development are black
boxes, no different, better or worse than any other proprietary EHR
company. I am against proprietary software in healthcare, and chose to
largely ignore what these kinds of companies produce as a result. I
would encourage others to do the same.

Having said that, it is important to also acknowledge that their
technical approach -may- have merit. If they ever chose to release
their compilers as FOSS software, it would be possible to do tests
that would move this discussion from a religious discussion (as
programming language discussions too often are) into the realm of a
scientific discussion. Until that happens, please join me in paying
attention to the hybrid approach that ClearHealth is employing, but
ignoring the other obviously non-free solutions as
yet-another-fine-way to screw up health IT.

Let me know if you would like me to make this a blog post... since it
kinda feels like one.

-FT

--
Fred Trotter
http://www.fredtrotter.com

[Robert M. Witkop]

Converting code from MUMPS to another language, although possible,
is not recommended for the following reasons:

1. The resulting cannot exceed the quality of the original code
2. The resulting code does not capture the intent of the original code
3. The resulting code will not have the same side effects as the
original code.
4. Automating the conversion still requires between 5 snd 10 percent to
be
done manually, and is expensive.

Although I can convert MUMPS code to C++, I have always been successful
in convincing clients that is is better to reverse engineer their code
than to convert their systems.

Especially for medical systems, MUMPS (Cache) would be the language of
choice. It was developed for medial systems, it is very easy to write.
The reason Vista is so great is that it was developed by people in the
medical profession and it contains their domain knowledge.

The only reason I could see for converting to JAVA would be for the web
interface. Here I have to confess. My experience is more with Cache than
MUMPS, but Cache Object Script is backward compatible with MUMPS. (no
flames please).

It is not difficult to write web interfaces to update data or
generate reports, and what about the data base. Has anyone tried to
convert a multi-dimensional data base to a relational data base; that
would waste a lot of money.

A computer language is simply a tool. A computer is only a conveyor that
moves data from one place to another, Although it it more like an
assembly
line since it can manipulate the data along the way.

The best approach is to use what I often refer to as
"Separation of Concerns".
MUMPS/Cache have have proven that they are the tools for providing
good medical care. Java is good at presenting data in a platform
independent manner.

Use the right tool for the job.

My views are not always shared, so please do not use valuable band width
flaming me on this list. I will gladly accept flames at
ju...@rwitkop.com
and they will be handled. If anyone would like a link
to see what MUMPS looks like when converted to C++ enter
Conversion Link as the subject. I will read those and forward the link.

[Branden Tanga]

Heh, the problem when talking about Mumps is that when you talk about
the db, the conversation steers towards the programming language or
runtime, and when you talk about the programming language or runtime
the conversation steers towards the db =P. I guess that's the nature
of having your language, db and runtime rolled into one "thing".

In any case, I don't think that most NoSQL databases out there are
appropriate for medical data because most of them use the idea of
eventual consistency, where an update to a record on one node on a
cluster does not lock the same record on other nodes. The idea being
that the update will "eventually" propagate out to the other nodes.
This is only appropriate if your application does not require real
time access to the most up to date data. Being non-ACID, NoSQL
databases are extremely scalable, but of course, they're not ACID
compliant. I know that Cassandra has settings which can change the
consistency behavior of the database, but I haven't looked to closely
at it in particular. Indeed, many NoSQL projects will state up front
that their db's are not appropriate for financial systems. I'd think
that the database requirements for complex financial systems and
complex healthcare systems would be pretty similar (although I'd
imagine that complex financial systems probably deal with larger
datasets).

GT.M on the other hand, is schema-less like other NoSQL databases, and
is also ACID compliant. A GT.M cluster has replication and failover
capabilities, but does not have load sharing. Being ACID complaint but
not having load sharing also means that GT.M does not use the idea of
"sharding" like other NoSQL databases. So I guess GT.M does fall under
the general heading of NoSQL, but it follows different rules than what
most people typically think of in the NoSQL movement. Also, GT.M does
have an entry in the Wikipedia NoSQL page, but the information up
there is pretty sparse.

Branden Tanga

On Apr 7, 8:57 am, rtweed <rob.tw...@gmail.com> wrote:
> Whilst not suggesting that what Uri has been seeing hasn't been a
> common commercial reaction to the Mumps database, the growing momentum
> of the NoSQL movement could soon filter down, making management-level
> decision-makers less certain that a mainstream relational technology
> is really what they need.  The trick will be to ensure that GT.M is
> firmly up there in the list of recognised NoSQL databases.
>
> Of course we may, instead, then see pressure to move from Mumps to, eg

> MongoDB,CouchDBor some such......

[Branden Tanga]

Also, a quick fact that might be interesting: By default, MS SQL
Server actually stores data in a binary tree, and only the
presentation of the data to other systems is in the table format.
Handy to know, in case there's ever an IT version of Jeopardy =P.

> > > > source code from MUMPS to Java is to persuade...
>
> read more »

[kdt...@gmail.com]

I think you mean "B tree", not binary trees. The differance being
multiple branches at each node, not just two ("binary").

When I first started with mumps, it was represented to me that the
speed of mumps came from it's use of B-trees. But Bhaskar confirmed
that many/most SQL databases also do this too. So it seems the speed
of Mumps come from less middleware, ie all the security stuff etc that
mumps is "missing."

Kevin

> ...
>
> read more »

[Branden Tanga]

Oops, you're right, B tree, not binary.

> ...
>
> read more »