VistA is a significant (>20000 source code modules) application that has been successfully ported from other MUMPSen to GT.M. There is an active VistA user community on the hardhats list (http://groups.google.com/group/hardhats).
Regards
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I'm not mistaken, VistA is based on the VA Fileman kernel. The VA Fileman kernel was, from the very beginning, designed to be portable across M implementations. I believe during installation (prior to support for DT.M) there were probably at least 3 implementations you could choose from. This isn't to say that there is no work in porting VistA from one implementation to another, just that it is much less than one might imagine a 20000+ module might involve.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure. Like many large M applications, VistA is architected so that dependencies on the individual M platform are encapsulated in lower software layers that provide platform independent services to higher level software layers. Tools like Re/parser from George James Software can also be used to to partially automate the conversion (caution: Re/parser is not like an office productivity software - it is a powerful tool to be wielded by a knowledgeable / trained user).
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Almost two years ago, I converted all of the Mayo Clinic's laboratory application code from DSM to GT.M. The laboratory application code base at that time was made up of about 3,000 routines. The KBase application, composed of almost 3,000 routines itself (for a total of about 6,000 routines), was also setup to run in GT.M (though no conversion was necessary for KBase as it is available from the vendor to run on GT.M). I setup GT.M on an AIX P-series machine. The conversion was a great success, and the laboratory system is currently running on GT.M.
I have found GT.M very easy to work with, and the support that is available is simply outstanding. Truthfully, I have never worked with a vendor that has been so responsive as the support team for GT.M.
After almost 20 years of coding in M, I can say with certainty that the GT.M product itself is an excellent implementation of standard MUMPS. For some users, it may be important to note that GT.M does not support list functions ($LI, $LB, etc.) or SSVNs. However, in each case, there are ways to work around these small issues.
GT.M is also remarkably fast. Recently I was doing some speed comparisons between GT.M and Cache. While Cache was faster with xecute code and indirection, read/write access to the database (the true bottleneck in any system) was much faster in GT.M on the hardware where I conducted my tests.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is interesting that you found that GT.M is faster than Cache writing data back to disk. I find GT.M quite nice but I also find that in Cache the write time is very close to the service time of the I/O subsystem.
<br><br>
Hmmm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to hear from someone who has successfully migrated a major application from Intersystems Cache to GT.M.
Let's hear your story!
VistA is a significant (>20000 source code modules) application that has been successfully ported from other MUMPSen to GT.M. There is an active VistA user community on the hardhats list (http://groups.google.com/group/hardhats).
Regards
-- Bhaskar
If I'm not mistaken, VistA is based on the VA Fileman kernel. The VA Fileman kernel was, from the very beginning, designed to be portable across M implementations. I believe during installation (prior to support for DT.M) there were probably at least 3 implementations you could choose from. This isn't to say that there is no work in porting VistA from one implementation to another, just that it is much less than one might imagine a 20000+ module might involve.
Sure. Like many large M applications, VistA is architected so that dependencies on the individual M platform are encapsulated in lower software layers that provide platform independent services to higher level software layers. Tools like Re/parser from George James Software can also be used to to partially automate the conversion (caution: Re/parser is not like an office productivity software - it is a powerful tool to be wielded by a knowledgeable / trained user).
-- Bhaskar
Almost two years ago, I converted all of the Mayo Clinic's laboratory application code from DSM to GT.M. The laboratory application code base at that time was made up of about 3,000 routines. The KBase application, composed of almost 3,000 routines itself (for a total of about 6,000 routines), was also setup to run in GT.M (though no conversion was necessary for KBase as it is available from the vendor to run on GT.M). I setup GT.M on an AIX P-series machine. The conversion was a great success, and the laboratory system is currently running on GT.M.
I have found GT.M very easy to work with, and the support that is available is simply outstanding. Truthfully, I have never worked with a vendor that has been so responsive as the support team for GT.M.
After almost 20 years of coding in M, I can say with certainty that the GT.M product itself is an excellent implementation of standard MUMPS. For some users, it may be important to note that GT.M does not support list functions ($LI, $LB, etc.) or SSVNs. However, in each case, there are ways to work around these small issues.
GT.M is also remarkably fast. Recently I was doing some speed comparisons between GT.M and Cache. While Cache was faster with xecute code and indirection, read/write access to the database (the true bottleneck in any system) was much faster in GT.M on the hardware where I conducted my tests.
It is interesting that you found that GT.M is faster than Cache writing data back to disk. I find GT.M quite nice but I also find that in Cache the write time is very close to the service time of the I/O subsystem.
<br><br>
Hmmm.