ISTR Meditech ran on VMS. Thoughts?
"... On Thursday morning, staff at the Health Sciences Centre in St. John's were told the system used to manage patient health and financial information at the hospital is back online. The system -- called Meditech -- only has information from before last weekend, and will need to be updated. ..."
-- https://it.slashdot.org/story/21/11/05/219213/nl-health-care-cyberattack-is-worst-in-canadian-history

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of plugh via Info-
>vax
>Sent: November-06-21 5:42 PM
>To: info-vax@rbnsn.com
>Cc: plugh <jchimene@gmail.com>
>Subject: [Info-vax] Meditech in the news
>
>ISTR Meditech ran on VMS. Thoughts?
>"... On Thursday morning, staff at the Health Sciences Centre in St. John's
>were told the system used to manage patient health and financial
information
>at the hospital is back online. The system -- called Meditech -- only has
>information from before last weekend, and will need to be updated. ..."
>--
https://it.slashdot.org/story/21/11/05/219213/nl-health-care-cyberattack-
>is-worst-in-canadian-history

Quick google of "Meditech platforms" results in:

"In addition to its primary market of acute care hospitals, MEDITECH also
serves home healthcare agencies, large healthcare systems, physician
offices, and clinics. MEDITECH's HCIS is available on two platforms: a
client/server-based Microsoft Windows setup, or the company's proprietary
MAGIC operating system."

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On Saturday, November 6, 2021 at 3:30:07 PM UTC-7, kemain...@gmail.com wrote:
> >-----Original Message-----
> >ISTR Meditech ran on VMS. Thoughts?
> >"... On Thursday morning, staff at the Health Sciences Centre in St. John's
> >were told the system used to manage patient health and financial
> information
> >at the hospital is back online. The system -- called Meditech -- only has
> >information from before last weekend, and will need to be updated. ..."
> >--
> https://it.slashdot.org/story/21/11/05/219213/nl-health-care-cyberattack-
> >is-worst-in-canadian-history
>
> Quick google of "Meditech platforms" results in:
..
..
..
That's nice. A longer search while "flogging my memory" for lived experience results in
https://www.academickids.com/encyclopedia/index.php/MUMPS

Cheers,

plugh <jchimene@gmail.com> wrote:
> kemain...@gmail.com wrote:
>> [...]

> That's nice. A longer search while "flogging my memory"
> for lived experience results in
> https://www.academickids.com/encyclopedia/index.php/MUMPS

It's not Mumps, an extension of it developed by the creator
of the Mumps language.

I once helped someone with a MicroVAX II running their software,
and it booted up as "Magic Kingdom" - it's own O/S. As Mumps was
originally, as well - I believe in the PDP-11 world in that case.

He had a question about installing a tape drive, I think. I had no
way of making any sense of it, though. Guess I could have borrowed
some books. They had to have their own terminal servers, as I recall -
special firmware that was not present in the standard ones.

I've also helped decommission a DEC Alpha that was running Meditech.
By that time they may have been on running VMS, I'm not sure. All I
did was cannibalize some peripherals from it as it was going out the
door.

George

> Cheers,

On Wednesday, January 5, 2022 at 2:36:01 AM UTC-7, George Cornelius wrote:
> plugh <jchi...@gmail.com> wrote:
> > kemain...@gmail.com wrote:
> >> [...]
> > That's nice. A longer search while "flogging my memory"
> > for lived experience results in
> > https://www.academickids.com/encyclopedia/index.php/MUMPS
> It's not Mumps, an extension of it developed by the creator
> of the Mumps language.

It's not MUMPS? maybe M? Maybe Mumps? maybe MUmphSsss?

Jesus God, talk about damning with faint praise. I appreciate the DECusEerve addr, but really? It's Mumps, errr M.... errr...
Those of us who actually write software for a living know MuMPS when they smell it. One of the founders of the friggin' company actually helped develop the language.
I had a contract at Kaiser to help maintain their lab interface written in

wait for

it

MUMPS!!!!

I just love cov

On Wednesday, January 5, 2022 at 6:13:18 AM UTC-7, plugh wrote:
> On Wednesday, January 5, 2022 at 2:36:01 AM UTC-7, George Cornelius wrote:
> > plugh <jchi...@gmail.com> wrote:
> > > kemain...@gmail.com wrote:
> > >> [...]
> > > That's nice. A longer search while "flogging my memory"
> > > for lived experience results in
> > > https://www.academickids.com/encyclopedia/index.php/MUMPS
> > It's not Mumps, an extension of it developed by the creator
> > of the Mumps language.
> It's not MUMPS? maybe M? Maybe Mumps? maybe MUmphSsss?
>
Sure smells like Mumphis to me. But then again, I can't tell the difference between Farenhiet and Smentigrade

https://www.99-bottles-of-beer.net/language-meditech-magic-385.html

plugh <jchimene@gmail.com> wrote:
> On Wednesday, January 5, 2022 at 2:36:01 AM UTC-7, George Cornelius wrote:
>> plugh <jchi...@gmail.com> wrote:
>> > kemain...@gmail.com wrote:
>> >> [...]
>> > That's nice. A longer search while "flogging my memory"
>> > for lived experience results in
>> > https://www.academickids.com/encyclopedia/index.php/MUMPS
>> It's not Mumps, an extension of it developed by the creator
>> of the Mumps language.
>
> It's not MUMPS? maybe M? Maybe Mumps? maybe MUmphSsss?

Actually, I was on the Mumps standards committee when it first accepted M
as an alternative name to Mumps. Along with Mark Berryman.

> Jesus God, talk about damning with faint praise.

My faint praise was reserved for Meditech. Never touched the thing -
I suppose I should have since my organization eventually expanded to
include quite a few health care entities that were using it, at least
until we developed a new standard organization wide - but by then
I was a VMS system manager only and not a programmer, Mumps or
otherwise.

The person I did talk to about it described it as "weird". Not a
programmer but someone on the team which had chosen the lab system
we were using at the time - running DSM - so I presume he was
describing Meditech as being an organization odd in that it tended
to hold its cards close to the chest.

Anyway, their extensions may have been a big improvement. But it
was not Mumps.

Now Mumps suffers from an image problem. None other than Edsgar
Dijksta described it as a "child's disease". Not being a native
English speaker, he could have just been referring to what it
was named for, but I don't think the quote would have stuck if
he didn't have deeper concerns regarding the language.

I don't go anywhere near that far. Its developer was an MIT engineering
student, after all. And he built it as an extension of RAND Corporation's
JOSS, which I have quite a bit of familiarity with having cowritten an
interpreter for it back in the late 60's. I was impressed with what
he had morphed the language into.

And I point out to people that it is one of the few languages with a
mod function that operates in a way that is mathematically correct
for negative numbers - the remainder r from what mathematicians call
the division algorithm (no, not long division itself).

The problem with Mumps was that you were stuck without a concept
equivalent to a RECORD declaration. So you tended to use delimited
data. Or even multiple levels of delimiter, which you eventually
saw showing up in HL7 and ASTM standards for medical data exchange.

Yes, I know, you can do this

SET ^PA(patno,"FNAME")="John"
SET ^PA(patno,"LNAME")="Smith"
SET ^PA(patno,"DOB")="1/7/1917" ...

but this has its drawbacks as well.

Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
Intersystems refused to port to newer versions or to Itanium, and by
that time they owned Digital's DSM as well as their own (M/VX or ISM).

Somewhere I have licenses but no system to run it on.

When Tom McIntyre and his father were associated with DECUServe
we ran DSM but it's been quite some time since we have even
had it there.

> I appreciate the DECusEerve addr, but really? It's Mumps, errr M.... errr...
> Those of us who actually write software for a living know MuMPS when they smell it. One of the founders of the friggin' company actually helped develop the language.
> I had a contract at Kaiser to help maintain their lab interface written in
>
> wait for
> it

> MUMPS!!!!

Thanks for the support. Too bad Intersystems withdrew theirs for VMS.

George
> I just love cov

On 1/5/2022 10:46 PM, George Cornelius wrote:

> Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
> Intersystems refused to port to newer versions or to Itanium, and by
> that time they owned Digital's DSM as well as their own (M/VX or ISM).
InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1

--
-- Rob

On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:
> On 1/5/2022 10:46 PM, George Cornelius wrote:
>
> > Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
> > Intersystems refused to port to newer versions or to Itanium, and by
> > that time they owned Digital's DSM as well as their own (M/VX or ISM).
> InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1
>
> --
> -- Rob
"InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"
That's good but do they plan to support current VSI VMS V8.4-2L3 ?

On 1/6/2022 4:40 AM, Ian Miller wrote:
> On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:
>> On 1/5/2022 10:46 PM, George Cornelius wrote:
>>
>>> Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
>>> Intersystems refused to port to newer versions or to Itanium, and by
>>> that time they owned Digital's DSM as well as their own (M/VX or ISM).
>> InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1
>>
>> --
>> -- Rob
> "InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"

> That's good but do they plan to support current VSI VMS V8.4-2L3 ?

Ask InterSystems.

--

-- Rob

On 1/6/2022 10:27 AM, Robert A. Brooks wrote:
> On 1/6/2022 4:40 AM, Ian Miller wrote:
>> On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:
>>> On 1/5/2022 10:46 PM, George Cornelius wrote:
>>>> Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
>>>> Intersystems refused to port to newer versions or to Itanium, and by
>>>> that time they owned Digital's DSM as well as their own (M/VX or ISM).
>>> InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1
>>>
>> "InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"
>
>> That's good but do they plan to support current VSI VMS V8.4-2L3 ?
>
> Ask InterSystems.

If someone really wants to know then that is the obvious route.

But the question and the other question whether they will support VMS
x86-64 are interesting.

One may not like MUMPS and its variants. But the healthcare sector
got money. That makes it an interesting market for VMS and VSI.

There are lots of markets that are extremely price competitive
and where VSI's VMS price will be compared to RHEL and various
no-cost Linux distros and every hundred dollars count.

But for a big hospital chain that spend hundreds of millions
of dollars on IT every year, then VMS Licenses and 24x7 VMS
support will be white noise in the budget.

Potentially very good customers.

But only potential customers if the application software is there!!

Arne

On 1/6/22 10:46 AM, Arne Vajhøj wrote:
> On 1/6/2022 10:27 AM, Robert A. Brooks wrote:
>> On 1/6/2022 4:40 AM, Ian Miller wrote:
>>> On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:
>>>> On 1/5/2022 10:46 PM, George Cornelius wrote:
>>>>> Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
>>>>> Intersystems refused to port to newer versions or to Itanium, and by
>>>>> that time they owned Digital's DSM as well as their own (M/VX or ISM).
>>>> InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1
>>>>
>>> "InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"
>>
>>> That's good but do they plan to support current VSI VMS V8.4-2L3 ?
>>
>> Ask InterSystems.
>
> If someone really wants to know then that is the obvious route.
>
> But the question and the other question whether they will support VMS
> x86-64 are interesting.
>
> One may not like MUMPS and its variants. But the healthcare sector
> got money. That makes it an interesting market for VMS and VSI.
>
> There are lots of markets that are extremely price competitive
> and where VSI's VMS price will be compared to RHEL and various
> no-cost Linux distros and every hundred dollars count.
>
> But for a big hospital chain that spend hundreds of millions
> of dollars on IT every year, then VMS Licenses and 24x7 VMS
> support will be white noise in the budget.
>
> Potentially very good customers.
>
> But only potential customers if the application software is there!!
>

And, as far as I know, The VA is still running VISTA which is
also an ANSI-M (otherwise known as MUMPS) application. I wonder
if any of them are on VMS? If not, what are they running on and
could VMS find away into that rather lucrative niche.

As a side note, because it is freeely avaialble to anyone who wants
it VA VISTA has been turned into a lot of other EMR systems including
things like Dentists and even Veterinarians. Could be a lot more
business in this niche than most people think.

bill

Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 1/5/2022 10:46 PM, George Cornelius wrote:
>
>> Oh, and as a VMS guy I was eventually stuck back at VMS 7.3-2 because
>> Intersystems refused to port to newer versions or to Itanium, and by
>> that time they owned Digital's DSM as well as their own (M/VX or ISM).
> InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1

Thanks, Rob. Now that I think about it, they probably made an announcement
at some point, anticipating the release of Cache', and stating that ISM and
DSM themselves would not be ported going forward, and it was misconstrued
in some quarters.

We do run on Cache' for a medical records system that went into place just
a few years ago, but our then-new CIO insisted that it be on the vendor
site and managed by them, so our people have no direct involvement. We
also sold them a brand new data center, from which we then lease back
a certain amount of space, and in that way have assured they have a
local failover site as part of their fault tolerance strategy.

To the original poster: I apologize if I gave short shrift to
Meditech in my first post. As an O/S environment it was opaque to
me, and it was vendor supported so I never saw the development
environment or the language. All my knowledge of it was 2nd hand.

With regard to the standards committee: my organization had a seat
on the Mumps Development Committee, which became an ASTM standards
committee because the VA wanted their environment to run on a
standardized language, and this was eventually elevated to a CCITT
standards committee. I just rotated through that position, but I
was unusual in that I actually had been a developer, but of an
interpreter for a different language, Mumps precursor JOSS.

More name games: the original name proposed for the language was
Joss-7.

George

On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
> One may not like MUMPS and its variants.

For those with an strong desire to try MUMPS aka M on VMS, then:

https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/

should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
6.3 or 7.0).

I have not tried it myself.

Arne

On 1/6/22 6:15 PM, John Dallman wrote:
> In article <j3ohkpFrqsqU1@mid.individual.net>, bill.gunshannon@gmail.com
> (Bill Gunshannon) wrote:
>
>> And, as far as I know, The VA is still running VISTA which is
>> also an ANSI-M (otherwise known as MUMPS) application. I wonder
>> if any of them are on VMS? If not, what are they running on and
>> could VMS find away into that rather lucrative niche.
>
> Probably not:
>
> "In May, 2018, the VA awarded a contract to Cerner Corp to replace
> VistA with the commercial off-the-shelf EHR, Cerner Millenium.
> Pilot implementations took place in the fall of 2020, and by November,
> 24 million veteran health records had been migrated to the new
> platform. The projected completion for migration of all VA sites
> is 2028.[5]"
>
> https://en.wikipedia.org/wiki/VistA
>
> John
>

Interesting. Oh well, there are still all the places that picked
up VA Vista at the reasonable price it was going for :-) and still
use it. I understand it has users pretty much around the world
today. Although I doubt anyone is calling it VA Vista. Especially
in places that don't really like us even when they get stuff for
free.

bill

On Thursday, January 6, 2022 at 6:16:57 PM UTC-5, John Dallman wrote:
> In article <j3ohkp...@mid.individual.net>, bill.gu...@gmail.com
> (Bill Gunshannon) wrote:
>
> > And, as far as I know, The VA is still running VISTA which is
> > also an ANSI-M (otherwise known as MUMPS) application. I wonder
> > if any of them are on VMS? If not, what are they running on and
> > could VMS find away into that rather lucrative niche.
> Probably not:
>
> "In May, 2018, the VA awarded a contract to Cerner Corp to replace
> VistA with the commercial off-the-shelf EHR, Cerner Millenium.
> Pilot implementations took place in the fall of 2020, and by November,
> 24 million veteran health records had been migrated to the new
> platform. The projected completion for migration of all VA sites
> is 2028.[5]"
>
> https://en.wikipedia.org/wiki/VistA
>
> John
There was a version of Cerner Millenium that ran on OpenVMS VAX and Alpha. It has since been rewritten and I don't know if there is an OpenVMS version.
The version that did however, was actually a CLI that replaced DCL. It was one of 2 in the world that VMS engineering knew about. Fun times porting that to Alpha as much of the code was in MACRO-32. Found a bunch of bugs in the image activator and other VMS routines on that project...

Dan

Curious.

How big are the differences between standard M, DSM/Cache and GT.M?

Is it like ANSI Fortran, DEC Fortran and IBM Fortran? Or like ISO
Pascal, Delphi and VMS Pascal? Or like Original Basic, VMS Basic and
Visual Basic?

Arne

On 1/6/2022 5:21 PM, Forster, Michael wrote:
> FYI and FWIW, GT.M is totally different variant than ISM and DSM versions of MUMPS.
>
> Not knocking Arne's sharing.
>
> M/11, ISM and DSM morphed into Intersystems' Cache which has morphed into Iris.
>
> M/11 is the PDP-11 version that your boot tape was a combination of OS and MUMPS.
>
> VIST/A is a presentation and abstraction layer between MUMPS and the programmers. Seems that they have dropped the "/" in the acronym for "Veterans Health Information Systems and Technology Architecture (VistA)". Or I might be confusing and "VA FileMan" being the data abstraction layer. You can search and find active use and versions for InterSystems Cache/IRIS on Linux at this point mostly.
>
> Read or don't:
> https://www.politico.com/agenda/story/2017/03/vista-computer-history-va-conspiracy-000367/
>
> Michael Forster
> Enterprise Database Administrator III
> (Formerly Enterprise Storage and IDX Architect)
> InterSystems Cache/ISM/DSM System Architect
> Clinical Practice Services | Medical College of Wisconsin
> O: (414) 955-4967 | mforster@mcw.edu
>
> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via Info-vax
> Sent: Thursday, January 6, 2022 2:01 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] Meditech in the news
> Importance: Low
>
> ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
> ________________________________
>
> On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
>> One may not like MUMPS and its variants.
>
> For those with an strong desire to try MUMPS aka M on VMS, then:
>
> https://urldefense.com/v3/__https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/__;!!H8mHWRdzp34!t6BI6Bb6H_N2g3j0rvTJbFkIucWmmwhF4Cnmqg21hGo-2jK3-h2nQNfkopWjOmU$
>
> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
> 6.3 or 7.0).
>
> I have not tried it myself.
>
> Arne
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> https://urldefense.com/v3/__http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com__;!!H8mHWRdzp34!t6BI6Bb6H_N2g3j0rvTJbFkIucWmmwhF4Cnmqg21hGo-2jK3-h2nQNfklCqeOyY$

On 1/6/22 3:40 AM, Ian Miller wrote:
> On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:

> "InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"
> That's good but do they plan to support current VSI VMS V8.4-2L3 ?

In this five-year-old statement, they are quite explicit about not
committing to support future releases or future architectures:

<https://www.intersystems.com/support-learning/support/openvms-itanium/>

Doesn't mean they won't do it if the demand is there. Since v8.5 and 9.x
for Alpha and Itanium were canceled, the question of new release support
and new architecture support are really the same question.

There is a table of supported platforms here:

<https://cedocs.intersystems.com/ens20171/csp/docbook/Doc.View.cls?KEY=ISP_technologies#ISP_platforms>

They don't say they support V8.4-2L3, but they do say they support VSI
V8.2-2L1 and that they do not separately test roll-ups or patches but
instead rely on the OS vendor to preserve quality when the base release
number does not change. They give the example of Windows Server 2008 R2
being considered supported even though it is not explicitly listed in
the table.

Note: I have never used the M thing but this is what I could find in 5
minutes of web searching.

On 1/7/22 10:42 AM, Craig A. Berry wrote:
>
> On 1/6/22 3:40 AM, Ian Miller wrote:
>> On Thursday, January 6, 2022 at 4:08:27 AM UTC, Robert A. Brooks wrote:
>
>> "InterSystems supports Cache on IA64 on VSI's VMS V8.4-1H1"
>> That's good but do they plan to support current VSI VMS V8.4-2L3 ?
>
> In this five-year-old statement, they are quite explicit about not
> committing to support future releases or future architectures:
>
> <https://www.intersystems.com/support-learning/support/openvms-itanium/>
>
> Doesn't mean they won't do it if the demand is there. Since v8.5 and 9.x
> for Alpha and Itanium were canceled, the question of new release support
> and new architecture support are really the same question.
>
> There is a table of supported platforms here:
>
> <https://cedocs.intersystems.com/ens20171/csp/docbook/Doc.View.cls?KEY=ISP_technologies#ISP_platforms>
>
>
> They don't say they support V8.4-2L3, but they do say they support VSI
> V8.2-2L1 and that they do not separately test roll-ups or patches but
> instead rely on the OS vendor to preserve quality when the base release
> number does not change.  They give the example of Windows Server 2008 R2
> being considered supported even though it is not explicitly listed in
> the table.
>
> Note: I have never used the M thing but this is what I could find in 5
> minutes of web searching.

It may be a moot point. Intersystems is in the process of phasing out
Cache in favor of their Iris product. As far as I can tell, this
product only supports Windows and Linux (and MacOS for development).

Mark Berryman

On 2022-01-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
>> One may not like MUMPS and its variants.
>
> For those with an strong desire to try MUMPS aka M on VMS, then:
>
> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>

After a 5-minute read of the Mumps language syntax, I have come to
the conclusion that it makes TECO look user-friendly. :-)

The total of my Mumps knowledge has been acquired over the last few
minutes and is based on the following:

https://en.wikipedia.org/wiki/MUMPS#Summary_of_key_language_features

I really don't like the dynamic nature of variables and the dynamic
way they are created when first referenced. It makes Mumps look more
like a scripting language than an application programming language.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/7/2022 1:57 PM, Simon Clubley wrote:
> On 2022-01-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
>>> One may not like MUMPS and its variants.
>>
>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>
>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>
>
> After a 5-minute read of the Mumps language syntax, I have come to
> the conclusion that it makes TECO look user-friendly. :-)
>
> The total of my Mumps knowledge has been acquired over the last few
> minutes and is based on the following:
>
> https://en.wikipedia.org/wiki/MUMPS#Summary_of_key_language_features
>
> I really don't like the dynamic nature of variables and the dynamic
> way they are created when first referenced. It makes Mumps look more
> like a scripting language than an application programming language.
>
> Simon.
>

Some people may prefer to have the computer do as much of the work as possible.
While you may prefer something like Ada, many do not agree with you.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/7/2022 1:57 PM, Simon Clubley wrote:
> On 2022-01-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
>>> One may not like MUMPS and its variants.
>>
>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>
>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>
>
> After a 5-minute read of the Mumps language syntax, I have come to
> the conclusion that it makes TECO look user-friendly. :-)
>
> The total of my Mumps knowledge has been acquired over the last few
> minutes and is based on the following:
>
> https://en.wikipedia.org/wiki/MUMPS#Summary_of_key_language_features
>
> I really don't like the dynamic nature of variables and the dynamic
> way they are created when first referenced. It makes Mumps look more
> like a scripting language than an application programming language.

Once upon a time script languages must have gotten the name because
they were used for scripts.

Probably around the same time when DEC was one of the worlds biggest IT
companies.

But today script languages are widely used for applications.

Python and PHP must be the two big ones. But there are plenty
of other.

One may not like it, but it is reality.

Slightly related:

https://thestack.technology/supercomputer-files-deleted-kyoto-university-hpe/

<quote>
A Japanese university inadvertently wiped a colossal 77TB of research
data from its supercomputer after a software update pushed by Hewlett
Packard Enterprise (HPE) caused a script to go rogue and delete backups.

Kyoto University said 34 million files from 14 research groups had been
deleted – and nearly a third of them will not get their data back after
the incident which it blamed squarely on the HPE supercomputing system.

A software update error meant the Cray/HPE system deleted almost all
files older than 10 days held in large capacity disc storage backup
rather than just log files. It had initially feared up to 100TB was
permanently lost.

Hewlett Packard said in a letter published by Kyoto University on
December 29, 2021 that it took “100% responsibility” for the issue
....
HPE said: “The backup script includes a find command to delete log files
older than 10 days. In addition to functional improvement of the script,
the variable name passed to the find command for deletion was changed to
improve visibility and readability.”
....
The company added: “However, there was a lack of consideration in the
release procedure of this modified script. We were not aware of the side
effects of this behavior and released the [updated] script, overwriting
[a bash script] while it was still running,” HPE admitted. “This
resulted in the reloading of the modified shell script in the middle of
the execution, resulting in undefined variables. As a result, the
original log files in /LARGE0 [backup disc storage] were deleted instead
of the original process of deleting files saved in the log directory.”
</quote>

Arne

On 2022-01-07, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Some people may prefer to have the computer do as much of the work as possible.
> While you may prefer something like Ada, many do not agree with you.
>

When you are writing critical applications, you don't take the
quick approach but you take the robust approach.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-01-07, Arne Vajhøj <arne@vajhoej.dk> wrote:
> ...
> HPE said: ?The backup script includes a find command to delete log files
> older than 10 days. In addition to functional improvement of the script,
> the variable name passed to the find command for deletion was changed to
> improve visibility and readability.?
> ...
> The company added: ?However, there was a lack of consideration in the
> release procedure of this modified script. We were not aware of the side
> effects of this behavior and released the [updated] script, overwriting
> [a bash script] while it was still running,? HPE admitted. ?This
> resulted in the reloading of the modified shell script in the middle of
> the execution, resulting in undefined variables. As a result, the
> original log files in /LARGE0 [backup disc storage] were deleted instead
> of the original process of deleting files saved in the log directory.?

There is absolutely no excuse for that disaster whatsoever.

Bash has a setting that stops execution of a script when an undefined
variable is encountered. I know this because it is at the top of every
single bash script that I write.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/7/2022 2:46 PM, Simon Clubley wrote:
> On 2022-01-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Some people may prefer to have the computer do as much of the work as possible.
>> While you may prefer something like Ada, many do not agree with you.
>>
>
> When you are writing critical applications, you don't take the
> quick approach but you take the robust approach.
>
> Simon.
>

Are you implying that computers cannot be robust?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486