I realize there is little interest in updating the MUMPS standard
right now (ignoring, for the moment, the administrative details of
how that could be done), but I wonder if a more modest approach might
be considered. We all know that existing limits (string length,
routine size, etc.)
I think there is plenty of interest in doing those two things at least I
gather from the afternoon meeting about it in Boston. There seems to be
uniform agreement on those items, so there should be virtually no opposition
to including them in the standard.
I think Rick was planning to do
Perhaps the way to pull this off is to get the major VistA stakeholders to
agree on a VistA-MUMPS Standard. If the VHA along with most of the following:
IHS, CMS, DOD, WorldVistA, VSA, and the MUMPS vendors agreed to extend the
portability standards to the existing lowest common limits, then I
Maury's proposal would not need the acquiescence of the M vendors - for
example, if the standards were extended to allow the use of longer
names, longer strings, $Increment(), etc., that are already supported by
both major commercial implementations of MUMPS.
Where things get sticky is the use
On Jun 13, 2006, at 3:11 PM, K.S. Bhaskar wrote:Maury's proposal would not need the acquiescence of the M vendors - for example, if the standards were extended to allow the use of longer names, longer strings, $Increment(), etc., that are already supported by both major commercial
On Jun 13, 2006, at 3:11 PM, K.S. Bhaskar wrote:...features defined in the standard but not supported by one or another MUMPS implementation (e.g., ACID transactions),... This goes beyond the scope of what I initially had in mind, but it seems to me that a major advantage of high level languages
