Best source for standalone FileMan?

[Matthew R. Wilson]

Hello,

What is the current best source for standalone FileMan to install in
GT.M/YottaDB?

From https://hardhats.org/fileman/FMrepairs.html, I see
https://hardhats.org/fileman/fm22.zip. However, that gives me version
22.0 which seems outdated at this point.

The best I've been able to find was via looking at the build file for
Ram Sailopal's Docker development environment
(https://github.com/RamSailopal/YottaDB-FileMan), which points to:
https://github.com/dlwicksell/fileman-22p2/raw/master/VA-FILEMAN-22P2.RSA

That gives me a version that identifies itself as VA FileMan 22.2, and
as an added bonus it restores into and seems to work (except a
Screenman-related bug) with DSM 6.3 on OpenVMS/VAX (don't ask...I'm
exceptionally nerdy when it comes to my hobbies) in addition to YottaDB.

However, that is several years old at this point and presumably there
have been at least some fixes since then?

The WorldVista tutorial at
https://tutorials.worldvista.org/open-source-databases-tutorial/FileMan/Install.html
has a link to the GitHub repository
https://github.com/OSEHRA/fileman-22p2
(with a direct link to a file named VA-FILEMAN-22P2V2.RSA), which seems
to be newer -- a VA FileMan V22.2V2.

However, that repository--indeed that whole OSEHRA GitHub account--is
gone. Looking at the history of the closing of OSEHRA, it looks like all
of their GitHub repositories were transferred to Logica's or
WorldVistA's GutHub accounts, but neither of them has a repository named
fileman-22p2. Is that VA-FILEMAN-22P2V2.RSA available anywhere?

Or... back to the original question... how do I get a current,
most-up-to-date, patched-with-latest patches VA FileMan for standalone
use?

(I also installed the free Community Edition of Intersytems Iris and
downloaded the latest FOIA release from foia-vista.worldvista.org, but
the IRIS.DAT file in recent releases exceeds the ~10GB size limit of the
Iris community edition so I can't try to export all the FileMan routines
from that as an up-to-date source.)

Tangentially related, are there any nice open-source or otherwise
freely-available projects out there (in healthcare or, perhaps even more
interesting, other industries) that are built on standalone FileMan?

Thank you,
Matthew

[Sam Habiel]

Hello Matthew,

> What is the current best source for standalone FileMan to install in GT.M/YottaDB?

It is https://www.hardhats.org/fileman/MSC.html. This version of Fileman is fully standalone. Follow the instructions here: http://flap.vistaexpertise.net/installation_guide/standalone.html. I (very minorly) assisted George Timson with MSC Fileman, and verified that it is completely standalone. I wrote the standalone install guide as well. If you have any questions, post here.

> VA-FILEMAN-22P2V2.RSA

I created that file, but for now, you can just download MSC Fileman.

> DSM 6.3 on OpenVMS/VAX

Oh it's too sad that Chirstopher isn't working in the VistA Community anymore. He had DSM running on a PDP-11 emulation running on a Raspberri Pi; the chassis was done by a talented engineer in Germany. But any version of Fileman today WILL NOT WORK on the old M's because the old M's lacked many features that Fileman uses today (e.g. Reverse $Order). David Whitten gave Christopher a copy of an old Fileman that did run. Christopher or David may have it lying around.

> https://tutorials.worldvista.org/open-source-databases-tutorial/FileMan/Install.html

I wrote this too!

> Tangentially related, are there any nice open-source or otherwise freely-available projects out there (in healthcare or, perhaps even more interesting, other industries) that are built on standalone FileMan?

George Timson told me that he supported a court system and a civil service program that both used Fileman. Like a lot of users, I think they most likely moved on. I do not think there are any open source projects using Standalone Fileman.  I wanted to do something in the past, but at this point, I am not that interested in computers that I would spend my free time on them.

--Sam

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/20220919205855.xwe5nlhhtvzobgu2%40mattwilson.org.

[K.S. Bhaskar]

On Tuesday, September 20, 2022 at 9:25:37 AM UTC-4 Sam Habiel wrote:

Hello Matthew,

> What is the current best source for standalone FileMan to install in GT.M/YottaDB?

It is https://www.hardhats.org/fileman/MSC.html. This version of Fileman is fully standalone. Follow the instructions here: http://flap.vistaexpertise.net/installation_guide/standalone.html. I (very minorly) assisted George Timson with MSC Fileman, and verified that it is completely standalone. I wrote the standalone install guide as well. If you have any questions, post here.

> VA-FILEMAN-22P2V2.RSA

I created that file, but for now, you can just download MSC Fileman.

> DSM 6.3 on OpenVMS/VAX

Oh it's too sad that Chirstopher isn't working in the VistA Community anymore. He had DSM running on a PDP-11 emulation running on a Raspberri Pi; the chassis was done by a talented engineer in Germany. But any version of Fileman today WILL NOT WORK on the old M's because the old M's lacked many features that Fileman uses today (e.g. Reverse $Order). David Whitten gave Christopher a copy of an old Fileman that did run. Christopher or David may have it lying around.

> https://tutorials.worldvista.org/open-source-databases-tutorial/FileMan/Install.html

I wrote this too!

> Tangentially related, are there any nice open-source or otherwise freely-available projects out there (in healthcare or, perhaps even more interesting, other industries) that are built on standalone FileMan?

George Timson told me that he supported a court system and a civil service program that both used Fileman. Like a lot of users, I think they most likely moved on. I do not think there are any open source projects using Standalone Fileman.  I wanted to do something in the past, but at this point, I am not that interested in computers that I would spend my free time on them.

[KSB] The late Tom Ackerman made a business out of writing and supporting Fileman based applications. If I remember correctly, they included:

• A jewelry wholesale business application.
• An application to manage parts inventories for aircraft management.

I seem to remember his telling me that the software that the Bangladesh Air Force used to track applications in its airspace was a Fileman application. Also, the first Fileman electronic medical record application was, I believe, the Finnish Musti system.

But all of this goes back several decades. I am a VistA newbie.

Regards

– Bhaskar

[Wolfgang Giere]

Looking back in FileMan history: I just had in my hand our German manual for FileMan Vs. 14 which we translated into German. (Remember: In those days FileMan was not yet silent.) We used it in many applications, p.e. our thesauri and for our medical record system BAIK.

 

Best regards to George!

 

Wolfgang Giere

 

 

 

-----Original-Nachricht-----

Betreff: Re: [Hardhats] Best source for standalone FileMan?

Datum: 2022-09-20T16:50:33+0200

Von: "K.S. Bhaskar" <ksbh...@gmail.com>

An: "Hardhats" <hard...@googlegroups.com>

 

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/a76d7dd2-7a9b-468f-9f6b-4255ae52d8den%40googlegroups.com.



[Matthew Wilson]

Hi Sam,

I figured I'd bump into you here :-). Thanks for your answers.

>> What is the current best source for standalone FileMan to install in GT.M/YottaDB?

> It is https://www.hardhats.org/fileman/MSC.html. This version of Fileman is fully standalone.

Ah, I should have mentioned MSC Fileman but my email was already getting long. Since you suggest it as the best approach, I revisited it this morning.

My main concern with MSC Fileman was that DIFROM didn't work. After getting somewhat through the process, it failed with the error:

  %YDB-E-GVUNDEF, Global variable undefined: ^DD("ROU")

                  At M source location M+1^DIFROM0

It appears ^DD("ROU") is supposed to be set to the upper bound of the routine size to be offered to the user. If I set it myself, then DIFROM does appear to work.

But I found it interesting that when I installed VA FileMan from VA-FILEMAN-22P2V2.RSA, ^DD("ROU") was set for me and DIFROM worked flawlessly. I also noticed the VA-FILEMAN-22P2V2.RSA ^DINIT routine sets up the PACKAGE file, but the MSC Fileman ^DINIT says "You do not have the Kernel 'Package' file (9.4). You cannot use VA FileMan's package export utility, DIFROM."

The reason I (think I) care about DIFROM is because if I define some files of my own and want to easily transfer their definitions to other systems, it seems like running DIFROM and saving out the xxxINIT routines is the way to do that. [However, I have also found the a6akit.rtn file which sets up new file definitions and populates them with sample data, so perhaps using that approach would be the preferred way to 'distribute' the necessary Fileman setup for applications built on top of it instead of exporting with DIFROM?]

My second concern with MSC Fileman was that the MSCFILEMAN_1062.RSA file doesn't load into OpenVMS DSM, giving "bad label" errors. I've tracked this down to the inclusion of extra metadata in the first line of each routine (e.g. "DDADISP^INT^1^65806,57900^0" instead of just "DDADISP"), but there might be another couple little problems too. I've found an easy way around that this morning, though: if I load into YottaDB with ^%RI, then export all of the routines with ^%RO, the version of the dump produced by YottaDB loads without error into the DSM ^%RR utility.

As an added bonus, MSC Fileman 1062 doesn't have the bug in ScreenMan that I hit with VA FileMan 22.2 in DSM. (The bug is that when I hit enter in a field after newly entering a value, the variable Y is undefined at PREAD+5^DIR01:1 I $C(Y)?1C,Y D).

So... it *appears* that with a tiny bit of juggling (defining ^DD("ROU") and re-exporting to get a DSM-friendly version and ignoring the lack of PACKAGE file, which I could recreate if it's really necessary for some reason), MSC FileMan should do the trick.

>> DSM 6.3 on OpenVMS/VAX

> He had DSM running on a PDP-11 emulation running on a Raspberri Pi; the chassis was done by a talented engineer in Germany.

I love it when people don't just emulate systems, but build actual replica or miniature chassis and things like that. Very cool! But yes, I've found that DSM for PDP-11 install tape floating around and have it up and running in the simh PDP-11 emulator. It's certainly an earlier, I think pre-ANSI M implementation. It's fun to go back and play with the idea that M was the entire operating system on the machine. But unfortunately I've not been able to find *any* documentation for the system; obviously the MUMPS language works as expected but I can't find anything on management of the system itself.

> But any version of Fileman today WILL NOT WORK on the old M's because the old M's lacked many features that Fileman uses today (e.g. Reverse $Order).

From what I can tell, MSC FileMan 1062 and VA FileMan 22.2 (with the exception of the ScreenMan bug) work great on DSM 6.3 for OpenVMS/VAX! This DSM is much more modern than that PDP-11 DSM. It does have, for example, $O(expr,-1) if that's what you mean by reverse $Order. I haven't extensively tested it, but I can define a new file, add entries to the file, and even ScreenMan seems to work fine in the MSC version.

The biggest limitation for me will be the character set -- it appears to be strictly ASCII; being able to properly enter accented characters in people's names would be nice, but I may have to stick to YottaDB on Linux for that, or figure out how to at least get a somewhat clean end-to-end ISO-8859-1 charset environment working with my VMS 7.3 and DSM instance. But... doing this on VAX instead of Linux is just a side-side-side project of what is overall very much a side-project to begin with.

Thanks again,

Matthew

[Sam Habiel]

Hey Matthew,

Comments inline.

On Tue, Sep 20, 2022 at 4:58 PM Matthew Wilson <mwi...@mattwilson.org> wrote:

Hi Sam,

I figured I'd bump into you here :-). Thanks for your answers.

>> What is the current best source for standalone FileMan to install in GT.M/YottaDB?

> It is https://www.hardhats.org/fileman/MSC.html. This version of Fileman is fully standalone.

Ah, I should have mentioned MSC Fileman but my email was already getting long. Since you suggest it as the best approach, I revisited it this morning.

My main concern with MSC Fileman was that DIFROM didn't work. After getting somewhat through the process, it failed with the error:

  %YDB-E-GVUNDEF, Global variable undefined: ^DD("ROU")

                  At M source location M+1^DIFROM0

It appears ^DD("ROU") is supposed to be set to the upper bound of the routine size to be offered to the user. If I set it myself, then DIFROM does appear to work.

Sam: When I worked with VEN on Fileman 22.2, we made extra special effort to make sure that DIFROM continues to work. Maybe that code never made it to MSC Fileman; but I can't remember anymore.

 

But I found it interesting that when I installed VA FileMan from VA-FILEMAN-22P2V2.RSA, ^DD("ROU") was set for me and DIFROM worked flawlessly. I also noticed the VA-FILEMAN-22P2V2.RSA ^DINIT routine sets up the PACKAGE file, but the MSC Fileman ^DINIT says "You do not have the Kernel 'Package' file (9.4). You cannot use VA FileMan's package export utility, DIFROM."

The reason I (think I) care about DIFROM is because if I define some files of my own and want to easily transfer their definitions to other systems, it seems like running DIFROM and saving out the xxxINIT routines is the way to do that. [However, I have also found the a6akit.rtn file which sets up new file definitions and populates them with sample data, so perhaps using that approach would be the preferred way to 'distribute' the necessary Fileman setup for applications built on top of it instead of exporting with DIFROM?]

My second concern with MSC Fileman was that the MSCFILEMAN_1062.RSA file doesn't load into OpenVMS DSM, giving "bad label" errors. I've tracked this down to the inclusion of extra metadata in the first line of each routine (e.g. "DDADISP^INT^1^65806,57900^0" instead of just "DDADISP"), but there might be another couple little problems too. I've found an easy way around that this morning, though: if I load into YottaDB with ^%RI, then export all of the routines with ^%RO, the version of the dump produced by YottaDB loads without error into the DSM ^%RR utility.

Sam: MV1/RSM has the same issue when I tested MSC Fileman on it. My solution is to edit the %RR routine; or repackage the code from another system, just like you did (I tend to use an OSEHRA written Python utility).

 

As an added bonus, MSC Fileman 1062 doesn't have the bug in ScreenMan that I hit with VA FileMan 22.2 in DSM. (The bug is that when I hit enter in a field after newly entering a value, the variable Y is undefined at PREAD+5^DIR01:1 I $C(Y)?1C,Y D).

So... it *appears* that with a tiny bit of juggling (defining ^DD("ROU") and re-exporting to get a DSM-friendly version and ignoring the lack of PACKAGE file, which I could recreate if it's really necessary for some reason), MSC FileMan should do the trick.

>> DSM 6.3 on OpenVMS/VAX

> He had DSM running on a PDP-11 emulation running on a Raspberri Pi; the chassis was done by a talented engineer in Germany.

I love it when people don't just emulate systems, but build actual replica or miniature chassis and things like that. Very cool! But yes, I've found that DSM for PDP-11 install tape floating around and have it up and running in the simh PDP-11 emulator. It's certainly an earlier, I think pre-ANSI M implementation. It's fun to go back and play with the idea that M was the entire operating system on the machine. But unfortunately I've not been able to find *any* documentation for the system; obviously the MUMPS language works as expected but I can't find anything on management of the system itself.

Sam: You should ask on comp.lang.mumps. Ask soon and document before people disappear! 

 

> But any version of Fileman today WILL NOT WORK on the old M's because the old M's lacked many features that Fileman uses today (e.g. Reverse $Order).

From what I can tell, MSC FileMan 1062 and VA FileMan 22.2 (with the exception of the ScreenMan bug) work great on DSM 6.3 for OpenVMS/VAX! This DSM is much more modern than that PDP-11 DSM. It does have, for example, $O(expr,-1) if that's what you mean by reverse $Order. I haven't extensively tested it, but I can define a new file, add entries to the file, and even ScreenMan seems to work fine in the MSC version.

The biggest limitation for me will be the character set -- it appears to be strictly ASCII; being able to properly enter accented characters in people's names would be nice, but I may have to stick to YottaDB on Linux for that, or figure out how to at least get a somewhat clean end-to-end ISO-8859-1 charset environment working with my VMS 7.3 and DSM instance. But... doing this on VAX instead of Linux is just a side-side-side project of what is overall very much a side-project to begin with.

Sam: You seem to forget how young UTF-8 is.  According to https://en.wikipedia.org/wiki/UTF-8#Standards, it seems that the oldest UTF-8 standard (1996) is more recent than the newest M standard (1995). So of course there was no other character set. But I don't think DSM will complain if you use the ISO-8859 encodings, which use the high bit to store non-ASCII in bytes 128-255.

Thanks again,

Matthew

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/a2814cb4-5cb3-4f99-b47f-97ea8945b46fn%40googlegroups.com.

[George Timson]

When you run ^DINIT, you are asked

 "Do you want to change the MUMPS OPERATING SYSTEM File? NO//"

If and only if you answer "YES" here, ^DD("ROU") will get set (in the DINIT6 routine).

Best regards back to Wolfgang, and best wishes for a very warm winter in Europe!   (We're still running the air conditioning here in Tucson AZ)

--George Timson

[Sam Habiel]

Thank you George!

--

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/8393c020-a9cb-4a5d-943d-9827ff394301n%40googlegroups.com.

[David Wicksell]

Sam,

I just wanted to correct one thing you mentioned, in your response.

Sam: MV1/RSM has the same issue when I tested MSC Fileman on it. My solution is to edit the %RR routine; or repackage the code from another system, just like you did (I tend to use an OSEHRA written Python utility).

Reference Standard M (RSM) doesn't have an issue importing Cache style routine exports anymore. I fixed it in V1.73.1 back in March of 2021, using a suggested fix that _you_ sent me. Here is the related entry in the RSM changelog:

=== v1.73.1 -- 2021 Mar 4

* Add fix to support ISC Cache routine export format, supplied by Sam Habiel

Thank you.

David Wicksell

Fourth Watch Software LC

[Sam Habiel]

> Reference Standard M (RSM) doesn't have an issue importing Cache style routine exports anymore. I fixed it in V1.73.1 back in March of 2021, using a suggested fix that _you_ sent me. Here is the related entry in the RSM changelog:

:blush: I stand corrected. Thank you David!

--Sam

--

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/335b6f35-7c73-4b63-a204-6b39f0ce98b2n%40googlegroups.com.

[David Wicksell]

My pleasure Sam. Thank you.

:blush: I stand corrected. Thank you David!

--Sam

[Matthew R. Wilson]

On 09.21.2022 09:08, Sam Habiel wrote:
>On Tue, Sep 20, 2022 at 4:58 PM Matthew Wilson <mwi...@mattwilson.org>
>wrote:
>

>> My main concern with MSC Fileman was that DIFROM didn't work. After
>> getting somewhat through the process, it failed with the error:
>>
>> %YDB-E-GVUNDEF, Global variable undefined: ^DD("ROU")
>> At M source location M+1^DIFROM0
>>
>> It appears ^DD("ROU") is supposed to be set to the upper bound of the
>> routine size to be offered to the user. If I set it myself, then DIFROM
>> does appear to work.
>>
> Sam: When I worked with VEN on Fileman 22.2, we made extra special effort
>to make sure that DIFROM continues to work. Maybe that code never made it
>to MSC Fileman; but I can't remember anymore.

Yep, I tested again and as long as ^DD("ROU") is set, DIFROM does appear
to function properly.

I saw George's note about ^DD("ROU") getting set automatically if you
answer yes to the "Do you want to change the MUMPS OPERATING SYSTEM
File? NO//" question. I've seen that question before... but if memory
serves, if I start with a completely fresh system and install only MSC
FileMan I don't think ^DINIT asked me that. But at this point I've mixed
and matched so many versions and approaches to installing I may be
losing my mind and misremembering. Good to know in any case.

>> The biggest limitation for me will be the character set -- it appears to
>> be strictly ASCII; being able to properly enter accented characters in
>> people's names would be nice, but I may have to stick to YottaDB on Linux
>> for that, or figure out how to at least get a somewhat clean end-to-end
>> ISO-8859-1 charset environment working with my VMS 7.3 and DSM instance.
>> But... doing this on VAX instead of Linux is just a side-side-side project
>> of what is overall very much a side-project to begin with.
>>
>Sam: You seem to forget how young UTF-8 is. According to
>https://en.wikipedia.org/wiki/UTF-8#Standards, it seems that the oldest
>UTF-8 standard (1996) is more recent than the newest M standard (1995). So
>of course there was no other character set. But I don't think DSM will
>complain if you use the ISO-8859 encodings, which use the high bit to store
>non-ASCII in bytes 128-255.

Nope, I didn't forget... hence why I said ISO-8859-1 :-). And yes, I'm
hoping I can just get terminal settings and everything working such
that, at a bare minimum, the full 8-bit values just survive a
round-trip.

And then pat myself on the back and switch to YottaDB on a modern OS
with UTF-8 mode enabled.

Thanks,
Matthew