Porting Mumps?

Hi all

Newbie here, dev background but know very little about MUMPS/M.

We have a large scale healthcare application running in MUMPS/M. It has both
a patient admin and financial system that is based on MUMPS/M. Its a
McKesson product based around their HBOC product line using MSE which is a
bespoke MUMPS/M environment that McK own. I could have all this wrong as I'm
an MS platform tech and all this UNIX based stuff looks like voodoo to me.

They are discontinuing support for the product in a little over a year and I
have been asked to investigate the practicality of porting this stuff to
another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
into something more accessible and which would be easier to interface with
other systems ideally through real time messaging via HL7 or XML? We already
do heaps of real time integration using both HL7 and XML.

Any advice on places to look? Companies to contact? Anyone have any
experience at doing this? Is this a good idea or not? Sounds like a lousy
idea to me personally but I'm biased as porting VB6 to VB.net makes my eyes
bleed and don't even get me started on migrating SQL Server and BizTalk to
new product versions... And that's stuff on the same platform and the same
product.

I should mention we're based in the UK.

I'd be most grateful for any pointers/advice


Many thanks

Steve

..

Hi Steve

Porting to Caché would be the most obvious and easiest option. Caché
is based on Mumps and is backwards compatible with Standard Mumps and,
since ISC bought Datatree Mumps, DSM and MSM in the 90s there is good
support and/or conversion help for many proprietary features.
I do not know your particular flavour of Mumps but in all probability
your application will make use of non-standard features that would
need to be converted. While this is not exactly rocket science you
could do worse than contact UK based George James Software
(www.georgejames.com) who have both the tools and expertise to help
you with such an effort.

Porting to Caché would enable you to project your Mumps globals to
objects and relational tables, thereby totally opening up your
environment to the outside world and giving you a diverse choice of
interfaces (odbc / jdbc, .Net, Java, COM, SOAP, XML, perl, python etc
etc.)

Wolf

On 5 Aug, 20:57, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me..
>
> They are discontinuing support for the product in a little over a year and I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .

On Aug 5, 3:57*pm, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me..
>
> They are discontinuing support for the product in a little over a year and I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .

Hi Steve:
Is your system the HBOC Star product by McKesson?
Thanks
Dave

I would echo what Wolf said and add the following. Yes, conversions can be
horrendous, but the alternatives can be worse. Purchasing an entire new
package from another vendor is not only expensive but hell on the staff.
Trying to rewrite a complex application in a new language is just simply
foolish. If support for your app is disappearing, then you are not alone
and others will be doing the same convertion. Talk to the various MUMPS/M
vendors/consultants and reach out to the other HBOC users. For sure talk to
your local InterSystems rep. You may find out that they already have a
program in place to help with your situation. There are likely to be
consultants who (if not already) will become skilled at performing exactly
the conversion you face.

One thing you should be warned about if you have any serious thoughts of
migrating from M to a relational platform. Time after time it has been
found that M out-performs relational by huge factors -- like 10 or 20 x.
You can "slip" in Cache and probably see an increase in performance.
Otherwise, expect to make a big investment in new hardware.

In addition to George James (www.georgejames.com), talk to M/Gateway
(www.mgateway.com).


"wolfkoelling" <wolf.koelling@slaughterandmay.com> wrote in message
news:c5b19c28-94aa-4666-b52f-0a871e046cc6@a70g2000hsh.googlegroups.com...
Hi Steve

Porting to Caché would be the most obvious and easiest option. Caché
is based on Mumps and is backwards compatible with Standard Mumps and,
since ISC bought Datatree Mumps, DSM and MSM in the 90s there is good
support and/or conversion help for many proprietary features.
I do not know your particular flavour of Mumps but in all probability
your application will make use of non-standard features that would
need to be converted. While this is not exactly rocket science you
could do worse than contact UK based George James Software
(www.georgejames.com) who have both the tools and expertise to help
you with such an effort.

Porting to Caché would enable you to project your Mumps globals to
objects and relational tables, thereby totally opening up your
environment to the outside world and giving you a diverse choice of
interfaces (odbc / jdbc, .Net, Java, COM, SOAP, XML, perl, python etc
etc.)

Wolf

On 5 Aug, 20:57, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has
> both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as
> I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me.
>
> They are discontinuing support for the product in a little over a year and
> I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We
> already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my
> eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .

On Aug 5, 1:57*pm, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me..
>
> They are discontinuing support for the product in a little over a year and I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .

I have mostly used products from Intersystems (maker of Caché) for the
last several years. In my last company we successfully migrated from
an older system (Alpha/OpenVMS/Digital Standard MUMPS) to newer ones
(X86/Unix-Linux-Windows/Caché). One benefit we realized was lower
cost: Older hardware and systems software maintenance fees tend to be
high, while the newers ones we migrated to were much lower, I believe.

I know that there is another MUMPS vendor: Fidelity National
Information Services. I don't know much about them, but you can
review http://www.fidelityinfoservices.com/...ealthcare/GTM/
and perhaps contact one of their staff who posts here regularly (K.S.
Bhaskar - ksbhaskar at gmail dot com)

Finally long ago one of the companies I was employed with was looking
at a conversion of some of our software from a non-standard version of
MUMPS to a standard version. I believe that they were working with a
firm by the name of Polylogics. Perhaps this is their URL:
http://polylogics.com/



Steve Graham

If you are looking for M beyond just Cache, then as Steve mentioned, there
is Fidelity's product, GT.M, and it is most definitely an industrial
strength version of M. It is available for most platforms including Unix
and Linux. Likewise, a UK company M21 has a Unix product which you might
want to look at. (www.m21.uk.com)


"Steve Graham" <solitary.wanderer52@gmail.com> wrote in message
news:c04ad21d-3c2c-44ee-beeb-79daaa77759f@c65g2000hsa.googlegroups.com...
On Aug 5, 1:57 pm, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has
> both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as
> I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me.
>
> They are discontinuing support for the product in a little over a year and
> I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We
> already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my
> eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .

I have mostly used products from Intersystems (maker of Caché) for the
last several years. In my last company we successfully migrated from
an older system (Alpha/OpenVMS/Digital Standard MUMPS) to newer ones
(X86/Unix-Linux-Windows/Caché). One benefit we realized was lower
cost: Older hardware and systems software maintenance fees tend to be
high, while the newers ones we migrated to were much lower, I believe.

I know that there is another MUMPS vendor: Fidelity National
Information Services. I don't know much about them, but you can
review
http://www.fidelityinfoservices.com/...ealthcare/GTM/
and perhaps contact one of their staff who posts here regularly (K.S.
Bhaskar - ksbhaskar at gmail dot com)

Finally long ago one of the companies I was employed with was looking
at a conversion of some of our software from a non-standard version of
MUMPS to a standard version. I believe that they were working with a
firm by the name of Polylogics. Perhaps this is their URL:
http://polylogics.com/



Steve Graham

Steve,
here in the US McKesson sells its' Star application in a locked down
state. By that, I mean the customer does not have access to the
maximumps source code. I know of only two customers in the US that do
own/can modify their maximumps code. Does your site own its' source
code? If so, are there maximumps programmers employed by your
organization? If so, maybe they can help you. If you don't have the
source code, porting is probably not an option. Even if you do have
source code, I'm guessing a port to cache is way more time consuming
( if possible ) than for example a dtm, msm or dsm application (other
varieties of mumps). Intersystems purchased those varieties of mumps
and added support for some of their unique features into the cache
mumps environment, making porting from those environments easier.
Also, if you don't have maximumps programmers on staff, have you
considered who would support the ported application?
Hope this helps,
Maurice

In article <4b3d3dda-79bc-4023-8343-339e3c97a2df@k13g2000hse.googlegroups.com>,
Maurice <hearmr@yahoo.com> wrote:
>here in the US McKesson sells its' Star application in a locked down
>state. By that, I mean the customer does not have access to the
>maximumps source code. I know of only two customers in the US that do
>own/can modify their maximumps code. ...

The original post stated

>They are discontinuing support for the product in a little over a year

so it may be possible for them to get the source code as compensation
for discontinuing support. Or not, depends on their contract and
honorable McKesson chooses to be.

--
-- Rod --
rodd(at)polylogics(dot)com

Assuming you have source code and the license allows you to port it,
certainly the first step to moving forward with the application is to
move to a modern, supported, MUMPS implementation, of which there are
at least two. GT.M (http://www.fis-gtm.com) on x86 GNU/Linux gives
you a commercially supported, widely used, industrial strength MUMPS
that is licensed under a free / open source license (i.e., you don't
have to pay to license it, but support with service levels is
available on commercial terms, as is training). Once it is ported,
there are multiple options to modernize the application, including
providing it as a service with an API.

If you don't have the source code and/or you are stuck with a
restrictive license that doesn't allow you to port it, work through
that with the vendor first. Had your employer used software available
under a free / open source software license, they wouldn't be in this
pickle, locked in to a vendor.

Write to me off-line if you have questions. I am on vacation this
week, but will be back online next week.

Regards
-- Bhaskar
ks dot bhaskar at fnis dot com <-- note e-mail domain

On Aug 5, 3:57*pm, "all newsgroups" <st...@powell.net> wrote:
> Hi all
>
> Newbie here, dev background but know very little about MUMPS/M.
>
> We have a large scale healthcare application running in MUMPS/M. It has both
> a patient admin and financial system that is based on MUMPS/M. Its a
> McKesson product based around their HBOC product line using MSE which is a
> bespoke MUMPS/M environment that McK own. I could have all this wrong as I'm
> an MS platform tech and all this UNIX based stuff looks like voodoo to me..
>
> They are discontinuing support for the product in a little over a year and I
> have been asked to investigate the practicality of porting this stuff to
> another version of MUMPS/M? Intersystems Cache? or off MUMPS/M altogether
> into something more accessible and which would be easier to interface with
> other systems ideally through real time messaging via HL7 or XML? We already
> do heaps of real time integration using both HL7 and XML.
>
> Any advice on places to look? Companies to contact? Anyone have any
> experience at doing this? Is this a good idea or not? Sounds like a lousy
> idea to me personally but I'm biased as porting VB6 to VB.net makes my eyes
> bleed and don't even get me started on migrating SQL Server and BizTalk to
> new product versions... And that's stuff on the same platform and the same
> product.
>
> I should mention we're based in the UK.
>
> I'd be most grateful for any pointers/advice
>
> Many thanks
>
> Steve
>
> .