GT.M D ^%GI vs MUPIP load

[Rob Kellock]

I'm trying to install the stripped down version of Vista from https://lloydm.net/Kernel/reduced_VistA.html on Ubuntu 22.04.4 LTS

As part of that process, I need to import a whole bunch of globals, each one stored as a *.zwr file.

I have followed the Acculturation Guide from YottaDb and I'm sourcing an environment file before proceeding.

Weirdly, I can import a global using yottadb -dir and D ^%GI, but am unable to do the same using mupip load.

I keep getting the error:

rob@Satellite:~/.yottadb/VAFileman/g$ mupip
MUPIP> load DD.zwr

Global: DD Jul 17, 2015@07:11:50 ZWR
%YDB-E-MUNOFINISH, MUPIP unable to finish all requested actions

Any ideas?

[Nancy Anthracite]

At one point the header needed to be exactly right format or it would not
work.

--
Nancy Anthracite

[K.S. Bhaskar]

Which version of GT.M or YottaDB are you using? In any case, try mupip load DD.zwr from the command line and see whether that behaves differently.

Regards

– Bhaskar

[Sam Habiel]

Rob, I took a quick look and I am firing up GDB now to see the exact issue. It's almost certainly the structure of the first two lines.

--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/88b15e33-7fba-457b-8957-2e1e0f778463n%40googlegroups.com.

[Sam Habiel]

sr_unix/mupip_cvtgbl.c

163 if ((BADZCHSET == utf8) || (0 >= line1_len))
164 mupip_exit(ERR_MUNOFINISH);

The part highlighted in bold is the problem. Your first line is empty.

When Lloyd M first wrote this article, this used to work. I did a git blame and this line was added in GT.M V6.3-007. It doesn't have a corresponding release note (http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.3-007_Release_Notes.html).

To fix the problem, use sed to add a first line. I did the following to fix and load:

for i in *.zwr; do sed -i '1cKERNEL FILES' $i; done

for i in *.zwr; do $ydb_dist/mupip load \"$i\"; done

--Sam

[Rob Kellock]

Hi Bhaskar,

I'm using your latest release, I think.

YottaDB release:         r2.00
Upstream base version:   GT.M V7.0-001
Platform:                Linux x86_64
Build date/time:         2024-02-19 17:21
Build commit SHA:        d87c9140bf6c3928925d4c842a396676f1f48989

Anyway, it looks like it's the blank line thing in the top of the *.zwr files.  Thanks all.  I'll export and re-import first to see how that process works, then proceed with the fix.

Cheers for the prompt assistance,

Rob.

[Rob Kellock]

After applying the fix (thanks Sam), I got loads of GVSUBOFLOW errors, but worked out I had to increase the record size to 4000 bytes or thereabouts and the key size to 512 bytes. Then there were two records in the ^XUTL global that wouldn't load.  Looked like line feeds might have been the problem? Since I doubt very much I'll be hitting those records I changed them to \n as a marker. That worked.

Now, I've got to figure out how to use this thing!  Clearly... I've got to be a user of some kind to do anything, but these beginner topics have been covered many times on this list. There'll be instructions either here or on the Hard Hats site.  I'll do some digging...

[Sam Habiel]

https://www.hardhats.org/projects/PROJECTSmain.html

Enjoy... Should have enough instructions together with Lloyd's stuff.

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/882bd8f6-3db6-413c-8486-a54e2e95d718n%40googlegroups.com.

[Rob Kellock]

^%ZIS(14.5,0)="VOLUME SET^14.5^1^1"
^%ZIS(14.5,1,0)="ROU^N^N^N^N^VAH^1^^14^G^1^12"
^%ZIS(14.5,"B","ROU",1)=""
^%ZIS(14.5,"LOGON","VISTA")=0

From XWBTCPM.m

NEWJOB() ;Check if OK to start a new job, Return 1 if OK, 0 if not OK.
 N X,Y,J,XWBVOL
 D GETENV^%ZOSV S XWBVOL=$P(Y,"^",2)
 S X=$O(^XTV(8989.3,1,4,"B",XWBVOL,0)),J=$S(X>0:^XTV(8989.3,1,4,X,0),1:"ROU^y^1")
 I $G(^%ZIS(14.5,"LOGON",XWBVOL)) Q 0 ;Check INHIBIT LOGONS?
 ;I $D(^%ZOSF("ACTJ")) X ^("ACTJ") I $P(J,U,3),($P(J,U,3)'>Y) Q 0

 Q 1

I have the feeling I'm playing with completely out of date code trying to get Lloyds VistA reduction going, but I'd like to understand a couple of things in the above fragments.

1. It seems to me that I $G(^%ZIS(14.5,"LOGON",XWBVOL)) Q 0 could never be True?

2. I have commented out the line below, because I believe this code had something to do with Cache licence restrictions?  On GT.M no such restrictions exist. I can now create jobs when I run D CHECK^XWBTCPMT

3. I don't believe that FileMan could edit or even create ^%ZIS(14.5,"LOGON","VISTA")=0. That data has been created directly from code?

Thanks,

Rob.

[Rob Kellock]

YDB>S DUZ=.5 D ^XUP

Setting up programmer environment
This is a TEST account.

Terminal Type set to: C-VT100

Select OPTION NAME: XWB LIST
     1   XWB LISTENER EDIT       RPC Listener Edit
     2   XWB LISTENER STARTER       Start All RPC Broker Listeners
     3   XWB LISTENER STOP ALL       Stop All RPC Broker Listeners
CHOOSE 1-3: 2  XWB LISTENER STARTER     Start All RPC Broker Listeners
Start All RPC Broker Listeners
          Task: RPC Broker Listener START on VAH-ROU:Satellite, port 9000
%YDB-E-TPLOCK, Cannot release LOCK(s) held prior to current TSTART

I'm getting the above message about locks, but there are no locks according to GT.M's LKE utility, so it seems the code is trying to release a lock that hasn't been created?

[Rob Kellock]

Way back... in 2011, Bhaskar wrote this... and that was what my problem was!  Again, I'm not certain what I'm achieving playing with this old code, but if nothing else, I guess I'm learning about coding in Mumps and getting a feeling for how VistA hangs together.

Bhaskar, K.S

Feb 6, 2011, 5:01:33 AM

to Hardhats

I am trying to configure the latest FOIA VistA to run on GT.M.  After running ZTMGRSET and ZUSET to switch the underlying MUMPS system to GT.M, I try running DINIT to reinitialize Fileman.  The session is captured below.  I get the error GTM-E-TPLOCK in SCHED+4^%ZTLOAD1, because it is trying to release a lock inside a transaction that it acquired prior to the TSTART that started the transaction (according the standard, inside a transaction, a process cannot release a lock that acquired outside.  The relevant code is:

GTM>zprint SCHED+4^%ZTLOAD1:SCHED+5
 L -^%ZTSK(ZTSK) S ZTSK("D")=ZTDTH
 TCOMMIT  ;

I believe that a simple correction that will get me past this point is:

 S ZTSK("D")=ZTDTH
 TCOMMIT
 L -^%ZTSK(ZTSK)

Can someone who knows please confirm that this is also an appropriate fix from the point of view of program logic?  Also, would the right person please feed the fix back to the VA?

For what it's worth, I didn't know that FOIA VistA had started to use transaction processing.  As I noted in my presentation at the 22nd VistA Community Meeting in Seattle last month, there are some interactions between Locks and TP to watch out for as an application transitions from Locks to TP.

Thank you very much, in advance, for any assistance.

Regards
-- Bhaskar

[Rob Kellock]

Success!  I'm now looking at all these cool menus in D ^ZU and thus far have managed to send an email to myself through MailMan.

[Sam Habiel]

I am catching up on emails.

I worked on making sure that the Kernel Routines properly run on GT.M/YottaDB: https://github.com/shabiel/Kernel-GTM.

You probably want to use https://github.com/shabiel/Kernel-GTM/releases/download/XU-8.0-10003/virgin_install.zip and use these routines.

--Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/1ba183bd-0959-4557-8118-48f786f7c5fdn%40googlegroups.com.

[Rob Kellock]

Thanks Sam.  It turns out that the only Kernel routines, I actually needed to change were those TCOMMIT ones, that Bhaskar noted back in 2011. Everything else works... so far. What I'm quite excited about right now, is my discovery that a GT.M/YottaDb administrator can create a logical database spread over many machines by choosing which globals, go where and that he/she can also create unjournaled memory only globals and... that both these things are invisible to the M programmer.

Automatic compilation of M routines into object code (I presume this object code is platform dependent machine code? I haven't checked), journaling for durability and now a logical database spread over many machines. This is cool stuff!  Once again, I haven't checked, so I don't know whether VistA organises it's 'Files' into Globals such that transactions are confined inside the same Global rather than being spread all over the place, but based on my understanding of the Data Dictionary that should be possible as long as the global is being accessed using the FileMan API (in practice, there's probably many applications that don't).

First it was FileMan only, now Lloyd's cut-down version of VistA, soon I'll go the whole hog with the complete FOIA distribution (I've noticed mention of FixIT in the Diamond distribution. Do you know if that is Delphi source code or just binaries. If it's source code, I might take a look).  I browsed the VA's RPC Broker's documentation the other day. From reading that, it appeared that VA's RPC broker is tightly bound to Delphi. I was hoping for an RPC Broker API that was independent of Delphi. If you were going to build a Web app on top of VistA, how would you do it today (subject to the proviso that there is to be miniscule use of another language. I'd prefer that all the logic is confined to server side M code and just the display uses HTML, CSS & Javascript which is stored inside FileMan files)? YottaDb has several foreign function interfaces (again, not enough research from me! I don't know how these FFI's attach to Mumps). I'm wary of FFI's because in the past I've found that they block the green threads present in other languages, Smalltalk, Python, Factor etc. Since Mumps seems to use processes rather than threads, I'm guessing these FFI's won't block. To be honest, I don't even see the need for a web interface for internal users, just a large budget for proper training, but.., from a sales perspective, I'd never convince anyone to use VistA without something flashy. Even so, I think the only way I will gain any traction is by showing a senior clinician that we could jointly build something quickly that fulfilled their need and getting VistA into NZ that way.

Anyway, I've ordered "The Best Care Anywhere" from Amazon. I'm hoping it will be a good read.