Instructions provided by VistA Community Members
K.S. Bhaskar, Lloyd Milligan Sea Island and Christopher Edwards
I will provide a copy of the emails we exchanged during this process.
Email information posted will keep the newest one on the top, please go to the bottom if you are interested on following the whole discussion about this topic.
---------- Thanks for your support!
All I did was confirm the packaging is correct, but sure, Fabian. Thanks. Regards -- Bhaskar
Yes, okay with me Fabian. I have added a few notes about 2013.0 to the vxVistA ‘How to’ page at Sea Island Systems.
Are you ok if I publish your findings and work on vxVistA.org? Also referencing to Lloyd’s notes on his website.
Please let me know
Fabian Lopez, PMP, CSM
Access/verify codes were encrypted in the exported Cache database. However, I unencrypted the Admin user codes, thinking that implementers might prefer to substitute a different encryption than MD5. Perhaps that was not the best idea!
CPRS will require the change to %ZTLOAD1 that we discussed. The other GUIs should work.
From: Christopher Edwards
Subject: Re: vxVista 2013.0
I've imported the routines and globals Lloyd produced and worked through the first part of his notes. One minor thing encountered so far is that the admin access/verify code is stored unencrypted in the extract and won't work when the md5sum implementation is implemented in GT.M (I fixed this by just resetting the access/verify code and logging in again).
I haven't tested CPRS, etc. but it looks like everything should work.
Just a note. The routine save was from GT.M using ^%RO. GT.M’s ^%RI will restore to .m files.
From: Christopher Edwards
Subject: Re: New vxvista
Fabian I should also be able to try it.
As a side note OSEHRA has some tool that help with exporting from Caché, ZGO.m/ZGI.m which creates ZWR files and can import/export them on Caché/GT.M (ZGI = ZWR Import, ZGO = ZWR output).
We also have a tool that will read a .ro and convert it to .m files for GT.M's use and also take .m files and create a .ro for it (PackRO.py and UnPackRO.py)
All are available here: https://github.com/OSEHRA/VistA/tree/master/Scripts
Fabian, I pulled the vxVistA documentation from your site--it was part of the zip. That is where the admin access/verify codes were.
There is no additional documentation for the GT.M adaptation, except the old 'How to' page that I made for the 2010 vxVistA adaptation at http://www.seaislandsystems.com/vxVistA/HowToPort.html.
Of course, there is a lot of relevant information pertaining to VistA and GT.M in general (some cited by Bhaskar in earlier replies).
One other thing. I recommend not posting the tar.gz until somebody exercises restoring its contents. Unzipping and extracting should yield a
vxVistA-2013.0 parent folder containing g, r, and q subfolders, each with one file.
The file in the g folder vxVistA-2013.0.GLO gets loaded with mupip; the file in the r folder allRoutines.RO gets loaded with ^%RI; and the YTT global in the q folder also gets loaded with mupip. -- all this after the target GT.M database and related environment variables (gtmroutines and gtmgbldir) have been created or defined (as documented in multiple sources elsewhere).
Please let me know of any problems found.
I used the following for the vxVistA 2013 database globals -
$ mupip extract -nolog vxVistA-2013.0.GLO
mupip is very fast! The tar archive consists of one large routine set (%RO), one large mupip extract (above), and YTT.zwr.
-rw-rw-r-- 1 vxvista vxvista 321797855 Feb 26 15:58 vxVistA-2013.0.tar.gz
Here are the file sizes of the files that should be in the tar.gz.
-rw-rw-r-- 1 vxvista vxvista 2124924929 Feb 26 15:40 vxVistA-2013.0.GLO
-rw-rw-r-- 1 vxvista vxvista 100159535 Feb 26 15:52 allRoutines.RO
-rw-rw-r-- 1 vxvista vxvista 12559086 Feb 26 15:25 YTT.zwr
In your other Email reply you mentioned using an external utility for the login hash. Something similar is needed for the TIU signature block
One very positive feature of vxVistA is that these things can be hooked in via file entries without modifying any vxVistA routines. It is only necessary to supply execute code for the implementation-specific APIs to perform ONE-WAY HASH, ENCRYPT STRING, and DECRYPT STRING.
This procedure was illustrated in step 36 of my 2010 vxVistA 'How to'
Next I need to push the tar.gz somewhere so that it can be retrieved it for testing. --Will send another reply when that is done.
Or maybe I should extract all the globals to one file (using mupip as illustrated in the manual)?
[KSB] Yes, that makes sense. The file is not that large.
I forgot a couple of things in the summary below. TIU signature block encryption also used Cache-specific functions. I bypassed this and removed the rhBlowfish global. This global is not needed. Also I quarantined the YTT global because in the past this global caused trouble with key length violations. It will be included in the final tar.gz in a separate folder from the rest, so that the implementer can decide what to do with it.
[KSB] As GT.M now supports keys to 1,019 bytes, which I think is longer
than Caché's 512 bytes, key length should no longer be a concern.
Before I summarize the modifications, a question please. Heretofore I have only imported globals to a GT.M database (using mupip). I am not sure of the best way to export globals. Would %GO be appropriate? Or should it be a mupip extract? If the latter, how would one traverse the global names to create separate files?
I have not exported globals from GT.M before. My SISZWR routine exports FROM Cache. When I modified it to export from GT.M, the file sizes were not the same so I do not trust it. In worst case I can study the difference and make it work, but you can probably suggest a quicker or better way.
[KSB] The %GO format is not appropriate for VistA data. This is because although VistA is supposed to have only printable characters (including spaces, but not control characters) in the database, there are (or were, at least in FOIA VistA once upon a time) control characters in global variables, and these have undesirable effects such as causing line breaks where none are intended.
The GT.M ZWR format was designed to be universal in that small, simple, programs in all MUMPS implementations can export & import globals, even binary data, in ZWR format. Maury Pepper wrote the Caché program
to export in ZWR format, and, if I remember correctly, Cameron Schlehuber wrote a routine for VistA in standard MUMPS to export in ZWR format.
The main change that I made was to bypass the hashing of access verify codes because the hash function calls a Cache $Z function that is not known to GT.M -
ACCESS CODE <Hidden>: ******
%GTM-E-INVFCN, Invalid function name
After bypassing the hash (by creating a VFD IMPLEMENTATION-SPECIFIC API entry to override the default) I reentered the published access / verify codes of the admin user. (I did not reenter any other login codes, just the admin user.) Thus the admin user's codes may be used to logon via ^XUS or ^ZU or (presumably) CPRS etc.
The burden of substituting another hash will be on the implementer. My old
2010 "how to" page suggests one way to do this.
[KSB] Also, John Leo Zimmer has posted code to use an external program to compute hashes that works for both Caché and GT.M (https://groups.google.com/d/msg/hardhats/f69HItG8wSM/Z9upJ041paQJ)
Other changes: Substituted the correct ZU routine (was the Cache version).
Substituted the correct NULL and HFS devices. Removed auto-start of the broker listener (Cache version).
I think that is all. I ran ZTMGRSET so that I could test other things, and of course tested login. I did not do anything to Taskman because that is implementation-specific anyway (the box name part).
Please let me know your thoughts on global export format. I will use ^%RO for the routines.
[KSB] %RO for routines makes sense.
From: Bhaskar, K.S
Sent: Tuesday, February 25, 2014 10:58 AM
To: Lloyd Milligan ; Fabian Lopez
I think your plan is sound, Lloyd. I would be interested in the modifications you make - when I have re-released FOIA VistA and WorldVistA EHR, I have basically just run ZTMGRSET and then DINIT.
I'll take a look at XUMF5AU (actually, I will along with others on the OSEHRA code convergence calls).
Thank you very much.
My plan, such as it is, would first convert globals to ZWR format (your suggestion), then import to a GT.M database, make some modifications, then re-export the globals.
As released by DSS, vxVistA has Cache-dependent code in the user login authentication part. VA VistA Kernel routine XUMF5AU calls Cache $ZBOOLEAN functions and vxVistA login authentication uses this routine. vxVistA has another similar dependency in the TIU note signing part (but in this case it is not a VA routine).
Alternatively, and easier, would be to release the 2013 routines and globals as they are, and let somebody else work out the necessary changes. Indeed somebody could take on the project of making routine XUMF5AU platform independent. I think that GT.M also includes one or more $Z functions for bitwise AND, OR, XOR, and NOT.
I do not want to undertake the latter project myself, but someone might be interested.
Sent: Tuesday, February 25, 2014 9:36 AM
Let me know if / how you want me to help in any way.
Is there any reason that vxVistA is released as a cache.dat file? Why not release it as a zip file with an extract of globals in text form (for example, see Maury Pepper's program ZWR.r1 at https://sourceforge.net/p/fis-gtm/patches/2/ and also, I'm told VistA itself has a routine that can do the dumping) and a directory of routines? That would make available to everyone - including Caché users
- in a non-proprietary format.
Powered by a free Atlassian Confluence Open Source Project License granted to vxVistA - Open Source Comprehensive Hospital Information System. Evaluate Confluence today.