Mumps - Versioning and Migration

[TI HRTGB]

Hi, I'm new to the MUMPS/MSM universe and I have some questions about MUMPS.
Is there any way to work with versioning in mumps with github/gitlab?
We are thinking of migrating our MUMPS system to a relational database, what is the best way to do this? Has anyone gone through this and suggest a way?

Thank you so much friends.

[TI HRTGB]

We are having problems with drops on the MUMPS workstation, due to the amount of accesses and the limitation of licenses, when we use stations with about 900 connections, the system works normally, however, when it gets close to 1200 connections, the problems begin. We have about 1220 licenses and that's why we're thinking of a way to migrate the MUMPS system to a relational database. Anyone suggest anything?

[K.S. Bhaskar]

What is the application? Perhaps someone on this list is familiar with the application and make suggestions.

Can you document the schema? If you can document the schema and the schema is relational, then it MAY be possible to migrate the application. Otherwise, migrate it to a MUMPS implementation that does not have a license limit.

Regards
- Bhaskar

[TI HRTGB]

Good morning, this is an application that was developed in a large hospital here in Brazil. The application was developed internally and maintenance is carried out by the institution's own employees. However, the size of the software is huge and is causing some problems as I mentioned above. From what I've read so far, I've seen that MUMPS is not relational. Is it possible to migrate this version of MUMPS to one that has no license limit? Is it possible to export globals, routines and windows ? Here's a code example of a routine for people to view.


APODISCO
S EMP=1
S DAT="01/04/15" D ^%pDY S DTINI=DAT
K ^|"DAT,REL"|APODISC1,^|"DAT,REL"|APODISC2,^|"DAT,REL"|APODISC3
S GL=$Q(^|"DAT,GCD"|DISPXCON(EMP,DTINI))
LER I GL="" G GERAREL
I $QS(GL,5)'=1 G PROX ; 1=retirada 2=devolucao
S DISPX=$G(@GL)
S CODMED=$P(DISPX,"^",2),CODMED=$P(CODMED,"c:",2)
;I CODMED'=15&(CODMED'=1336)&(CODMED'=75)&(CODMED'=1378)&(CODMED'=29994)&(CODMED'=5038) G PROX
I CODMED'=4104 G PROX
S REG=$QS(GL,3)
S QUANT=$P(DISPX,"^",3),QUANT=$P(QUANT,"q:",2)
S (DAT,DATADISP)=$P(DISPX,"^",1)
D ^%pDT
S MES=$P(DMY,"/",2)
;B
S APO=$G(^|"DAT,REL"|APODISC1(CODMED,MES)),APO=APO+QUANT,^|"DAT,REL"|APODISC1(CODMED,MES)=APO
S APO=$G(^|"DAT,REL"|APODISC2(CODMED,REG)),APO=APO+QUANT,^|"DAT,REL"|APODISC2(CODMED,REG)=APO
S APO=$G(^|"DAT,REL"|APODISC3(CODMED,DATADISP)),APO=APO+QUANT,^|"DAT,REL"|APODISC3(CODMED,DATADISP)=APO
PROX S GL=$Q(@GL)
G LER
;-------------------------
GERAREL
;Q
S arq="C:\temp\APODISCO.txt"
O 51:(arq:"W")
U 51
S GL=$Q(^|"DAT,REL"|APODISC1)
APO1 I GL="" G D2
S CODMED=$QS(GL,1),DESMED=$G(^|"DAT,GHC"|XTABSIS1(CODMED))
S MES=$QS(GL,2)
S QUANT=$G(@GL)
W CODMED_"^"_DESMED_"^"_MES_"^"_QUANT,!
S GL=$Q(@GL)
G APO1
D2 S GL=$Q(^|"DAT,REL"|APODISC2)
APO2 I GL="" G D3
S CODMED=$QS(GL,1),DESMED=$G(^|"DAT,GHC"|XTABSIS1(CODMED))
S REG=$QS(GL,2)
S QUANT=$G(@GL)
W CODMED_"^"_DESMED_"^"_REG_"^"_QUANT,!
S GL=$Q(@GL)
G APO2
D3 S GL=$Q(^|"DAT,REL"|APODISC3)
APO3 I GL="" G FIM
S CODMED=$QS(GL,1),DESMED=$G(^|"DAT,GHC"|XTABSIS1(CODMED))
S DAT=$QS(GL,2) D ^%pDT
S QUANT=$G(@GL)
W CODMED_"^"_DESMED_"^"_DMY_"^"_QUANT,!
S GL=$Q(@GL)
G APO3
FIM C 51
q

[Jens]

ti.h...@gmail.com schrieb am Freitag, 20. Mai 2022 um 14:05:48 UTC+2:
> Em quinta-feira, 19 de maio de 2022 às 17:55:13 UTC-3, K.S. Bhaskar escreveu:
> > On Thursday, May 19, 2022 at 3:29:04 PM UTC-4, ti.h...@gmail.com wrote:
> > > Em quinta-feira, 19 de maio de 2022 às 14:18:22 UTC-3, TI HRTGB escreveu:
> > > > Hi, I'm new to the MUMPS/MSM universe and I have some questions about MUMPS.
> > > > Is there any way to work with versioning in mumps with github/gitlab?
> > > > We are thinking of migrating our MUMPS system to a relational database, what is the best way to do this? Has anyone gone through this and suggest a way?
> > > >
> > > > Thank you so much friends.
> > > We are having problems with drops on the MUMPS workstation, due to the amount of accesses and the limitation of licenses, when we use stations with about 900 connections, the system works normally, however, when it gets close to 1200 connections, the problems begin. We have about 1220 licenses and that's why we're thinking of a way to migrate the MUMPS system to a relational database. Anyone suggest anything?
> > What is the application? Perhaps someone on this list is familiar with the application and make suggestions.
> >
> > Can you document the schema? If you can document the schema and the schema is relational, then it MAY be possible to migrate the application. Otherwise, migrate it to a MUMPS implementation that does not have a license limit.
> >
> > Regards
> > - Bhaskar
> Good morning, this is an application that was developed in a large hospital here in Brazil. The application was developed internally and maintenance is carried out by the institution's own employees. However, the size of the software is huge and is causing some problems as I mentioned above. From what I've read so far, I've seen that MUMPS is not relational. Is it possible to migrate this version of MUMPS to one that has no license limit? Is it possible to export globals, routines and windows ? Here's a code example of a routine for people to view.

In general it is possible to migrate from your MSM-System to a Database like YottaDB. But there are some things to consider:
1. mumps dialects differ in some expressions. For example; your code has a line 'O 51:(arq:"W") U 51'. This has to be converted to 'O arq:NEWVERSION U arq'
2. It looks like this System runs on a windows machine while YottaDB normally lives on a LINUX machine. So filenames and system-calls have to be adapted
I've migrated an application from DSM to GT.M a long time ago and it was possible but took time. How much time it is belongs to how many routines have to be reviewed and your M-Knowledge.

You can also export all data into a relational database but the you have to rewrite all application logic. The time amount also belongs to the size of the application.

Can you tell how many routines are in you application?

Jens

[TI HRTGB]

The system runs on Unix - AIX.
The amount of routines is absurd, in just one UCI called MWS,MED we have about 6,722 routines, 790 global ones, 1,748 windows and 192 applications.

MSM client image.
https://postimg.cc/LnC30NDR

[Amir Samary]

Hi!

It depends. Are you using MSM Workstation?

When InterSystems bought MSM, they incorporated a lot of its technology and protocols into InterSystems Caché.

In a simplified way to explain, InterSystems Caché is a relational database that uses globals to store the data. And as far as I know, it was possible to have MSM Workstation applications to connect to Caché databases. You will continue to use globals as storage but you will be able to start mapping these globals to tables, build REST services to work with these globals or tables, build a new modern UI that uses these REST endpoints, have it operating maybe in parallel to your old MSM Workstation application until you can retire it and use just the modern web UI.

Caché allows you to use VSCode to edit code. So your tables, REST endpoints, etc. could all be saved in git.

InterSystems also provides a better version of Caché, called IRIS, that runs in containers. But I don't believe IRIS supports the MSM Workstation protocols. IRIS supposedly sheds many legacy technologies like MSM Workstation while Caché is still maintained and users are slowly migrating from Caché to IRIS. So I believe if you take this approach, you should eventually be able to upgrade from Caché to IRIS as well.

On the other hand, if you don't use MSM Workstation, then it is much easier! You could actually migrate directly to IRIS and start building your new modern UI while mapping your globals to IRIS SQL Tables.

I hope that helps.
AS

[K.S. Bhaskar]

Porting the application from MSM Workstation to YottaDB (https://yottadb.com) is certainly feasible, as Jens notes. How easy or how difficult it will be depends on how close to standard M the application is and how well structured it is (some things, like device parameters and anything starting with Z will usually be M implementation dependent). Your best bet is to hire an expert M programmer (there are many in Brazil, and many on this list). A tool like Re/parser (https://www.georgejames.com/reparser) may help with the analysis and conversion.

Regards
– Bhaskar

[OldMster]

I recently completed converting our lab system from Caché to YottaDB. The conversion was about 7300 routines, and 300 gigabytes of data. Working on it by myself, it took about 9 months total, including testing by the users before we went into production. Obviously I wrote a lot of automation to convert the obvious things like any Z commands or $Z functions, and the IO utilities. It can be done, and with a large team can probably be done quicker.

For the data, I did an early mass conversion, then kept the yottaDB databases up to date by reading the journal files from Caché and applying the changes to the yottaDB databases. The lab system makes extensive use of extended references (and '%' globals), which complicated the conversion quite a bit, especially since we wanted to use replication. We couldn't map globals from multiple global directories to the same database because of replication limitations, but I came up with a solution that works using extended references for all '%' references - also automated.

All that is not to brag, just to show it can be done, and completed in a reasonable amount of time, even with limited resources.

Mark

[TI HRTGB]

Is there any way to migrate from MSM that has routines, globals and windows to free Mumps where there is no limitation of licenses per connection?

[Flávio Fornazier]

Hi!

You're in safe hands with these M developers and I agree with all of them, they are the best!

I'm from Belo Horizonte and I have a lot of experience with MSM Unix as well others M implementations and relational databases.

Feel free to contact me if you need help or exchange ideas.

Regards,

[K.S. Bhaskar]

Yes, that is how open source software works: no license fees. You don't have to pay anything to use it as much as you want, but if you have production applications, you can buy support on commercial terms with assured service levels, or you can hire your own talent and support it yourself.

Regards
– Bhaskar

[OldMster]

The windows, which I suspect use the MSM proprietary window system, would be the most troublesome, but it can be done. YottaDB is an open source Mumps, no license fees, no license limits, and it is rock solid, mission critical production capable. It has database replication, which I don't think MSM every fully had, so your database can be duplicate realtime to any location with an IP connection. The routines are O/S level files, not stored in the database, so industry standard version control/change control software and procedures work.

Mark

[K.S. Bhaskar]

Interesting point, Mark. I don't know whether the window system is text-oriented or graphical, but if it is text-oriented, there are a number of interesting text-based rich user interfaces. Here is a list that a friend sent me recently:

https://github.com/ArthurSonzogni/FTXUI
https://github.com/ggerganov/imtui
https://github.com/fdehau/tui-rs
https://github.com/redox-os/termion
https://github.com/charmbracelet/bubbletea
https://github.com/gizak/termui

Regards
– Bhaskar

[OldMster]

Bhaskar,
I believe it is actually a GUI - sort of an early MS Visual Basic competitor. If it was me, I'd migrate it to a web based front end using Rob/Chris's connection tools and something like Vue, which is what I did for the Flex/Flash player front end I'd done for the lab. But, depending on their developer base, MS Visual basic might make more sense, and more closely mimic the MSM Window environment. The web environment doesn't always mirror the desktop app user experience. User training time has to be part of the equation when deciding things like this.

In any case, going to a relational database would require a complete rewrite of the entire system, would require significantly more time, and be much higher risk.

Mark

[Flávio Fornazier]

Mr.Bhaskar, Mr.Mark...

Now I've seen the picture at https://postlmg.cc/LnC30NDR

Those are just MSM-Workstation "graphical windows" definitions".

A lot of MSM-Workstation clients executables connected to MSM Unix Server(s).

Regards,

[K.S. Bhaskar]

Thanks Rob. I have never used any M except YottaDB/GT.M. Yes, the M/Gateway tools would be good for a browser based GUI. For a non-browser GUI, an X11 based application would make sense, using toolkits and frameworks like GTK (https://gtk.org/) and wxWIdgets (https://wxwidgets.org/). A GUI can run as an X11 client on a headless server, and be accessed from a desktop. Using a tool like Xpra (https://www.xpra.org/) which has an HTML5 client, a browser can also provide the XServer.

Lots of options...

Regards
– Bhaskar

[K.S. Bhaskar]

Sorry, I meant Thanks Mark! That's what comes of typing and editing back and forth. Apologies.

Regards
– Bhaskar

[Alex]

Hi and welcome,

Its been about 20 years since migrating from MSM to Cache but from what I recall:

MSM uses routine names upto 8 characters long.
In Cache these names are more flexible longer.

Review the usage mapping of globals beginning with "Z and z". As these may become transactional.
Cache / IRIS has a "process private" syntax using "^||variablename" instead of ^Zvariable and is more explict this is a temporary storage.

In MSM you can redefine a routine line label (code entry point).
In cache / IRIS the compiler will help identify where these are to ensure they are not duplicated.
Cache / IRIS allow a longer line lengths.

Cache / IRIS have the concept of Macro-routines and Int-routines. If you wish to enhance existing code with SQL macros then suggest import the routines as Mac-routines to allow this capability in future.
Cache / IRIS supports the "dot syntax" but also more modern brackets like "if (xyz) { do something } else { do somethingelse }
An advantage of the new bracket syntax is that it doesn't add levels to your process stack. So is more efficient.

I like that cache / IRIS supports long strings variables. So instead of getting MAXSTRING error going over 32K you can go up to somewhere like 2MB for in memory variable.

In addition, to the point made on renaming how to open a file device, Cache / IRIS also has a more explicit modern object oriented syntax you could use:
Set dev=##class(%File).%New("MyFileName.txt")
Do file.Open("WSN")
Do file.WriteLine("This is a line of text")

See: https://docs.intersystems.com/irisforhealth20221/csp/documatic/%25CSP.Documatic.cls?&LIBRARY=%25SYS&CLASSNAME=%25Library.File

Reasons to go the Cache / IRIS route might include:

1) Support for complex SQL structures from existing global data.
When moving from MSM to Cache an immediate benifit was reportability.
Was able to define "Classes" with storage mapped to existing globals.
This gave a SQL projection against which modern SQL reporting tools could be run against existing data.
2) High Availability. IRIS provides Mirroring.
This allows you to have two nodes. A current primary member, and a backup failover member that is kept up to date and ready to AUTOMATICALLY take over.
3) Reporting. You might not need one, but will mention with Mirroring you can also have async mirrors. These are up to date copys of data on seperate instances available to run big SQL reports, to insulate that processing from busy user application experience.
4) Consolidation. A big customer had a recent upgrade going from Cache 2010 to IRIS 2019. They originally had a scaled out database with 3 application database instances in front of a master database instance, with additional seperate database instances to process laboratory instrument integration.
Performance has improved so much with IRIS we only needed a single IRIS Database Instance to do all that same work.
5) XML processing and generation
I had a need to process doctor payment data in XML files. With Classes was able to define XML SAX parser handler for REALLY FAST custom import of XML streams.
6) Streams. In MSM and Cache there is a limit for how long a stored string node can be.
However with a stream data type you can read & write much larger data in globals.
The new version of IRIS supports stream compression so for XML could save you 60-80% of storage.
7) REST application support. If you want to create new web apps to enhance aspects of you existing application one option is REST API to support single page applications. For example Typescript with Angular and Material.
8) Web Services. Either to provide services or consume external services.
9) Language bindings. There are many supported (Java / DotNet). The new IRIS even has Embedded Python.
This means you have to option to implement new IRIS classes with the Python language methods to run alongside existing code in the database.
10) FHIR app integration, FHIR repository, FHIR SQL
11) If you like SQL you might also like the IntegratedML feature in IRIS.
12) Container Virtualization is supported if you desire to move away from Physical hardware. IRIS is a cloud-first focused platform.

A better understanding of what you want to achieve may give opportunity to highlight further specific features from the myriad of options available.

Kind regards,

Alex

[Coriolis]

четверг, 19 мая 2022 г. в 20:18:22 UTC+3, ti.h...@gmail.com:

Hi! Ple

I've had migration experience, but I can't distribute info (NDA). But if you write to me, I can give you some good advice.
Please mail me at coriolis dog inbox dot ru

[Alex Maslov]

Hi,
Mark, it seems that we are sharing the same field )

> I did an early mass conversion, then kept the yottaDB databases up to date by reading the journal files from Caché and applying the changes to the yottaDB databases

I read journal files on Caché side and apply the changes to YottaDB through in-house TCP based protocol. What about you?

> We couldn't map globals from multiple global directories to the same database because of replication limitations

Why did you want it?
Having rather complicated global mapping in Caché, we just duplicated it in YottaDB, including subscript mapping. We were happy enough not to mess with ^%globals in our App, so I'm not aware of possible caveats in YottaDB.

Alexey

[OldMster]

On Saturday, May 21, 2022 at 7:23:02 AM UTC-4, Alex Maslov wrote:
> Hi,
> Mark, it seems that we are sharing the same field )
> > I did an early mass conversion, then kept the yottaDB databases up to date by reading the journal files from Caché and applying the changes to the yottaDB databases
> I read journal files on Caché side and apply the changes to YottaDB through in-house TCP based protocol. What about you?

Pretty much the same. For the initial mass conversion I also used an in-house TCP protocol that allowed multiple processes per database to run simultaneously. On process per global was the maximum limit. The 300 gigabytes only took a few hours to convert with this method.

> > We couldn't map globals from multiple global directories to the same database because of replication limitations
> Why did you want it?
> Having rather complicated global mapping in Caché, we just duplicated it in YottaDB, including subscript mapping. We were happy enough not to mess with ^%globals in our App, so I'm not aware of possible caveats in YottaDB.

Our application uses extended syntax references extensively. The system originated in the dark ages before ethernet, and before single machines could handle even a modestly large laboratory. The system was broken up in to logical groupings, and configured on multiple machines (up to 4 at the time) using a proprietary DEC networking system. That network (speed in K, not M or G) and the machines were very slow (a smartwatch today is several orders of magnitude faster), so a lot of data moved back and forth in the background to make sure it was available when and where the users needed it. It worked, and at the time allowed us to handle very large labs. That design proved advantageous even after hardware caught up, as it made interfacing/integrating the lab system into mixed environments very easy. % globals, however, were expected to be in a database that was inherently mapped by the Mumps implementation (DSM-11, Datatree, Intersystems Caché was the migration path for our app) and available from every UCI/Namespace/Whatever. Replication doesn't allow that, and replication is required for our disaster recovery process. It was much easier/faster to modify the routines to use extended references for % globals, and easy enough to automate those modifications.

The caveat for YottaDB is that replication won't start if it detects a mapped global that is also mapped in another replication instance. And that makes sense for a daemonless system, the replication process needs exclusive access to the database updates that in DSM/Cache/MSM/Whatever would be handled by the write daemon. Because of that, we couldn't just map the % globals in each of the global directories we created to emulate a UCI/Namespace/Whatever.
Mark

>
> Alexey

[Alex Maslov]

On Saturday, May 21, 2022 at 5:45:45 PM UTC+3, OldMster wrote:
> That network (speed in K, not M or G) and the machines were very slow (a smartwatch today is several orders of magnitude faster),
> so a lot of data moved back and forth in the background to make sure it was available when and where the users needed it.

That was apparently one of beautiful solutions inspired by poor hardware configs of the past )

Our HIS/LIS/RIS/etc qMS takes its roots from the early 200x, so it's easier to port it to YottaDB, while currently we have a stopper for really large configurations: our largest site of ~ 6000 concurrent users is deployed on 20 application servers connected to a data server using Enterprise Cache Protocol (ECP). No chances to replace ECP with GT.CM as its network caching feature looks unbeatable nowadays.
The only possible way for this case seems to be a migration from horizontal scaling provided with ECP to vertical scaling to some [super] server. Not a great solution as it raises the need for at least two such servers for failover.

Alex

[OldMster]

ECP (a newer version of Datatree's networking) is indeed a great system. We used Datatree to run 256 concurrent users (all on hardwired terminals - still no TCP) on MS-DOS 286 & 386 machines. The 4 application servers were 386's, and the two database servers were 286's. The client's IT department fought us on that - they were sure the database servers needed to be the 386's, but I convinced them to do it right. Almost all the processor intense tasks were on the application servers, the database servers needed IO, not processing power. The system ran great for 6 years until we migrated it to Caché on Windows Servers.

These days I'm focused on migrating the front end to a browser, which again offloads a significant part of the processing to the workstation. Using YottaDB as the database server and REST interfaces to the browser, modern hardware should easily handle thousands of browser clients. With YottaDB replication, any 'expensive' report generation processes could be offloaded to a replicated database on a different server, so tens of thousands of browser clients for interactive activity seems possible to me. The system on YottaDB/Linux is much faster than the old Caché/Windows system, but to be fair that was on 2007 hardware, so not a fair comparison.

Good time to be configuring new systems! I certainly don't miss configuring MS-DOS machines to get the maximum amount of memory for Datatree and the RS232 buffers needed for the 64 serial ports!

Mark

[Alex Maslov]

On Sunday, May 22, 2022 at 8:35:16 PM UTC+3, OldMster wrote:
> Using YottaDB as the database server and REST interfaces to the browser, modern hardware should easily handle thousands of browser clients.

Agreed, we have deployed sites with thousands thin or browser clients running a single server. Scaling such a system is its potential problem. E.g. we are running 2000 users, and we need to add extra 500: usually no problem. And what if we need a 1000 more? How high can it grow, depends on many factors, and if the hardware becomes the stopper, it needs upgrade, and as all we know, it's usually difficult to upgrade even 5 years old server. So, we need a new one, plus another one for failover.

> With YottaDB replication, any 'expensive' report generation processes could be offloaded to a replicated database

This approach looks advantageous. We have an initial version and plan to improve it to achieve transparent report start on report server and returning the results to database server.

Alexey

[TI HRTGB]

I'm new to the MSM area, I see that people suggest many things, however, I don't have the knowledge to adopt these suggestions.
Does YottaDB work with routines, globals and windows in the same way as MSM? Here at the institution we have clients working with windows and clients working directly on the terminal.
Is it possible to migrate from MSM to IRIS? Does it work with windows too? I'm confused and lost..

[OldMster]

Simple answers this time:

Routines - yes - the same with minor adjustments due to non-standard extensions that might have been used (Z* & $Z* commands/functions)
Globals - yes - the same
Windows - no - these were entirely an MSM 'thing', and no equivalent in any other M system exists that I'm aware of (including IRIS). Multiple options to migrate to, but would be the biggest development effort to migrate to any M except MSM

Mark

[TI HRTGB]

Does the cache itself which is the evolution of MSM not have the window system?

[OldMster]

Not that I'm aware of. Caché 'inherited' the least from MSM. In fact, I don't know of a single feature in Caché that came from MSM, but someone more familiar with MSM might have better information. Most of the inheritance was from Datatree (DCP which became ECP, namespaces), and Intersystems original mSQL (.INT, .OBJ, .INC, compiler, SQL mapping which morphed into part of the basis for Caché Objects).

[OldMster]

You might find this page hosted by George James Software (Thanks George and company!) useful. I'd forgotten it was an implementation of the M Windowing API (MWAPI). AFAIK it was the only implementation of MWAPI to make it to production.

https://www.georgejames.com/ws

Mark

[OldMster]

Ack! That caused another old brain cell to wake up! Ouch!
I believe John Murray who is now with George James Software was the main developer of MSM Workstation. It was good stuff, but it didn't do well enough in the marketplace to get the funding it needed to be maintained.

[TI HRTGB]

Hello, follow msmlog logs when the crash problem occurs

[Jun-01-22 10:03:41] And mumsm ended (proc=#20316374, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:41] very ended (proc=#14221630, status=0)
[Jun-01-22 10:03:41] very ended (proc=#8257564, status=0)
[Jun-01-22 10:03:41] very ended (proc=#64749588, status=0)
[Jun-01-22 10:03:41] very ended (proc=#44957844, status=0)
[Jun-01-22 10:03:41] very ended (proc=#64684234, status=0)
[Jun-01-22 10:03:41] very ended (proc=#42401856, status=0)
[Jun-01-22 10:03:41] very ended (proc=#65405012, status=0)
[Jun-01-22 10:03:41] very ended (proc=#39125020, status=0)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#61014236, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#32571450, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#27132320, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#33685614, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#23789816, status=90009)
.................... And ...abnormal termination, signal # = 9
[Jun-01-22 10:03:44] And muserver ended (proc=#4194584, status=90009)
.................... And ...abnormal termination, signal # = 9