I was actually working on projects of my own at home and was pleasantly surprised on how easy it was to import a non-openvista set of routines using the ovimport tool included in the Ubuntu APT repository. I used WorldVista as a test subject--I wasn't able to successfully import the .dat file using the -g command, although it recognized the dat file as a "GO" type instead of a "ZWR" type, after the import was over the database wasn't complete, so I just copied the whole mumps.dat file to the globals dir and renamed it default.dat and that worked fine.
Yea, a .dat file is a GT.M database file -- ovimport expects a global extract from a GT.M database. The difference being that GT.M databases are GT.M-version specific, while global extracts are not. (Actually, global extracts aren't really even mumps-platform specific.) We ship OpenVista Server as global extracts; I guess WorldVistA must be shipping GT.M databases?
I have filed a bug on Launchpad regarding the incorrect file type detection -- ovimport should have thrown a more descriptive error.
I also had to switch the RPC listener to original from new style because even though ZSTART.M does start taskman and the listener after the first RPC connection is over the listener dies, it doesn't happen with my OpenVista vanilla install though, only when using the WorldVista routines and .dat file.
The RPC broker is written such that a main mumps process listens for connections, then JOBs off child processes for each connection. Native GT.M lacks the ability for the parent mumps process to pass the socket onto the JOB'd child. The official GT.M answer to this problem is to use a daemon dedicated for the purpose such as xinetd instead of the mumps listener process. While this makes a ton of sense from a UNIX point of view (do one thing and do it well, right?), it makes managing a VistA system much more complicated because now the RPC broker file (where VistA admins are used to configuring things) doesn't really do anything, and the RPC broker menus don't do anything, either. The VistA admin must know to go out to the Linux system and start/stop/reconfigure xinetd, and he requires root access to do so.
So, as part of the OpenVista/GT.M integration project, we wrote a small C library for GT.M that allows the socket passing. With a minimal code change to the RPC broker (call our C library instead of JOBing directly), the broker now functions exactly as it does on Cache, so all the configuration files and menus still work.
WorldVistA doesn't use this library; it expects you to set up xinetd. That's why the RPC broker dies after 1 connection in WorldVista if you start it the VistA way.
The original-style RPC broker "calls back" (it starts a new connection to CPRS), so no socket passing is required, and that works for just about any VistA distribution, but OpenVista CIS doesn't support the old-style broker.
I was most impressed with the detail of the project site, you guys are doing a superb job breaking down this ancient mumps monster into steps that most people will be able to follow. VistA is complicated enough, then you add Linux underneath it and you can definitely confuse a lot of people out there, your scripts/tools are making these tasks a piece of cake.
Thanks for the kind words -- that's exactly what we're trying to accomplish with this project.
