shabiel/kernel-gtm

Enhancements to the VistA Kernel for GT.M

kernel-gtm's Issues

VistA bug at ESET+2^XWBTCPM

There is a bug in VistA that I have been trying to get fixed for years. It's a one line fix (commenting out ESET+2^XWBTCPM), but no one seems to care enough to fix it.

Since the YottaDB/GT.M code base has both $ZTRAP and $ETRAP, the interaction between the two is that if you assign a value to one, it sets the other to the empty string (""). The entryref ESET^XWBTCPMclearly intends to set $ETRAP to "D ^%ZTER H", which ESET+1^GTMLNX does. But then in ESET+2^XWBTCPM, the code sets $ZTRAP in an attempt to clear it (and presumably avoid confusion between $ZTRAP and $ETRAP). The bug is that the side-effect of clearing $ZTRAP clears $ETRAP, which means that there is no error trap!

I believe the scenario in which this bug manifests itself is when CPRS GUI users close the CPRS GUI by X'ing the window, which closes one end of the TCP connection. When the server process attempts to write to its end of the TCP connection, it gets an error, and ultimately terminates the process, so there is no real harm done (other than the fact that errors are not logged, and hence likely to be missed). But it also floods the syslog with NOPRINCIO error messages, hundreds to thousands of them, making troubleshooting harder.

The following demonstrates the bug and the fix:

bhaskar@zomok:~$ mumps -run %XCMD 'zprint ^ETRAPTEST'
ETRAPTEST
	write "Before ESET: $ETRAP=",$ZWRITE($ETRAP)," $ZTRAP=",$ZWRITE($ZTRAP),!
	do ESETFIXED
	write "After ESETFIXED: $ETRAP=",$ZWRITE($ETRAP)," $ZTRAP=",$ZWRITE($ZTRAP),!
	do ESET
	write "After ESET: $ETRAP=",$ZWRITE($ETRAP)," $ZTRAP=",$ZWRITE($ZTRAP),!
	quit
ESET ;Set inital error trap
 S U="^",$ETRAP="D ^%ZTER H" ;Set up the error trap
 S X="",@("$ZT=X") ;Clear old trap
 Q
ESETFIXED ; Set initial error trap (fixed version)
 S U="^",$ETRAP="D ^%ZTER H" ;Set up the error trap
; S X="",@("$ZT=X") ;Clear old trap
 Q
bhaskar@zomok:~$ mumps -run ETRAPTEST
Before ESET: $ETRAP="Write:(0=$STACK) ""Error occurred: "",$ZStatus,!" $ZTRAP=""
After ESETFIXED: $ETRAP="D ^%ZTER H" $ZTRAP=""
After ESET: $ETRAP="" $ZTRAP=""
bhaskar@zomok:~$ 

Line 10 in ZOSVGUX comparison is incorrect: Need to fix.

This is a critical issue for olders versions of GT.M (<6.3)

^R in XTER doesn't work for GTM/YDB

ZTER Global Save for GT.M

^DIC(2343,1242342134 (e.g.)

ZSY: Only issue interrupt to M processes; not mupip or anything else.

Issuing an interrupt to mupip can apparently break replication.

%ZISH should be the Unix Version that will be obtained, not the VMS version

RPMS Routines use $$READNXT^%ZISH but don't pass a new parameter in

The MAX variable is not set and some routines don't send it. We added a new line and it resolved the issue.

READNXT(REC,MAX) ;
; ZEXCEPT: %ZA
N T,I,X,%
I '$D(MAX) S MAX=256
U IO R X:0 S %ZA=$ZEOF,REC=$E(X,1,MAX-1)

Support Read Editing in VistA for GT.M

DEL^%ZOSV2 did not manage the current $IO device properly

The Quality Reporting Tool lost its connection to the server because the report
was compiled (the Search Template and the Print Template). This meant when the report ran, FileMan had to delete the previous version of the routine, which required a call to DEL^%ZOSV2 to delete it.

The program DEL^%ZOSV2 did not manage the current $IO device properly, opening another device before saving the current one. So after the IO device was used to delete the old routine, it defaulted to making the $PRINCIPAL device into the current one, but the current device was supposed to be the HFS device for the printout.

When you have an RPC connection, the $PRINCIPAL device is the communication channel. So when FileMan printed the report to the communication channel instead of the Host File System device, it broke the RPC call mechanism protocol, and shut down the connection needed to print the report.

Fixed code:

DEL(RN)	; Delete Routine, VEN/SMH
	; Input: Routine Name by Value
	; Output: None
	;; BEGIN WVEHR LOCAL MOD DJW/WV 11/2019 Save Intrinsic Variables
	N %,%I,%R,%T,%ET S %I=$I,%R=$R,%T=$T,%ET=$ET
	;; END WVEHR LOCAL MOD 11/2019
	N CNT S CNT=0
DELLOOP	; Loop entry point
	I CNT>5 S $EC=",U-DELETION-FAILED,"
	N %ZR ; Output from GT.M %RSEL
	N %S,%O ; Source directory, object directory 
	; 
	; NB: For future works, %RSEL support * syntax to get a bunch of routines
	D SILENT^%RSEL(RN,"SRC") S %S=$G(%ZR(RN)) ; Source Directory
	D SILENT^%RSEL(RN,"OBJ") S %O=$G(%ZR(RN)) ; Object Directory
	;
	; BEGIN WVEHR LOCAL MOD DJW/WV 11/2019 Save Intrinsic Variables
	; Guarantee Intrinsic Variables are restored.
	;was; I '$L(%S)&('$L(%O)) QUIT
	; END WVEHR LOCAL MOD 11/2019
	I '$L(%S)&('$L(%O)) G DELX
	;
	S RN=$TR(RN,"%","_") ; change % to _ in routine name
	;
	N $ET,$ES S $ET="Q:$ES  S $EC="""" Q" ; In case somebody else deletes this; we don't crash
	;
	I $L(%S) D  ; If source routine present?
	. O %S_RN_".m":(newversion):0  ; Write out a new routine that's completely empty.
	. E  Q
	. ZLINK RN  ; Tell this process that that's the new routine. Other proceses that have the object linked be notified using the RELINK_CTL file.
	. C %S_RN_".m":(delete)  ; now delete
	. I CNT>3 N % S %=$$RETURN^%ZOSV("rm -r "_%S_RN_".m")
	;
	I $L(%O) D  ; If object code present?
	. O %O_RN_".o":(readonly):0
	. E  Q
	. C %O_RN_".o":(delete)
	. I CNT>3 N % S %=$$RETURN^%ZOSV("rm -r "_%O_RN_".o")
	S CNT=CNT+1
	;
	G DELLOOP
	; BEGIN WVEHR LOCAL MOD DJW/WV 11/2019 Restore Intrinsic Variables
DELX	;
	X "I $O("_%R_")" S $ET=%ET U %I I %T
	QUIT
	; END  WVEHR LOCAL MOD DJW/WV 11/201 

Add support for listing open devices in %ZTER

GTM/YDB: ZSHOW "D"

Cache: $SYS.ProcessQuery.OpenDevices

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.ProcessQuery#PROPERTY_OpenDevices

XTHC10: Intersystems Cache bug: XT8REQUEST.Location escapes URLS incorrectly

CACHEVISTA 4e1>W PATH 
/see/dhp-vista*?format=json
CACHEVISTA 4e1>W XT8REQUEST.Location
/see/dhp-vista*%3Fformat%3Djson

To replicate:

S XT8REQUEST=##class(%Net.HttpRequest).%New()
S XT8REQUEST.Port=80
S XT8REQUEST.Server="138.197.147.128"
S XT8REQUEST.Location="/see/dhp-vista*?format=json"
W XT8REQUEST.Location

MKDIR^ZOSVGUT3 test fails the first time it's run; ok subsequent times.

In MKDIR^ZOSVGUT3, you have a hard-coded path of "/tmp/foo/boo" as part of an 'rm -r' command. As far as I can tell, this isn't set anywhere prior to this test running and it certainly wasn't in the /tmp/ directory on my system. That means a new install of the system will always fail that test since the removal of something that doesn't exist returns 1. Once the file/folder exists, the tests finish fully and all 178 tests pass.

Import VistALink native MTL listener code into GT.M

https://github.com/shabiel/vistalink-gtm-mtl-support

XUSHSH replacement functions

GT.M ipv6 support in VISTA

GT.M already supports IPV6. Just need to make sure that VistA knows that.

Typos in release notes

I saw a place where "unit" was used instead of "unix"
and "decomission" instead of "decommission"

I would have submitted a pull request but I don't see how
to do so for the Release Notes

Port XU*8*657 to GTM/YDB

Do not assume default region is called "DEFAULT"

Affects various routines that call out to GT.M for information. Targeted changes for the next release.

References to ^$J need to be replaced with $ZGETJPI

XOBUZAP.m: FOR SET XOBPID=$ORDER(^$JOB(XOBPID)) QUIT:XOBPID="" DO
XQ82.m: I $D(^$JOB(X1))=0 Q 1 ; Job is DEAD

George Lily says:
I don't remember it ever being mentioned on the code convergence call.

I have a system where the ^TMP global is filling up and needs to be cleaned out..

I scheduled XQ CLEAN $J to run every hour... but it never does anything..

so I read the code and found out why.. it fails because of this bug...

How does everyone else get their utility globals cleaned out? because it's not with this routine.

gpl

Bug in XTHC10

Do block level incorrect on line 202 and 247.