Enhance DEL^ZOSV2GTM to fix bugs and for more intelligent deletion
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenVista/GT.M Integration |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The existing entryref DEL^%ZOSV2 - _ZOSV2.m is copied from ZOSVGTM.m as part of switching VistA to GT.M, I believe by ^DINIT - has some problems.
1. It deletes a source file if that source file exists in the directory returned by $$RTNDIR^%ZOSV, and doesn't handle the case where that source file may be in a directory upstream.
2. It attempts to delete an object file in the directory returned by $$RTNDIR^%ZOSV. This works only if that directory contains both source routines and object routines. Otherwise, attempting to delete from the directory where the source file exists is a bug because that's the wrong directory for the object code.
3. It attempts to delete a file with a .obj extension. GT.M on UNIX does not generated files with a .obj extension, and deleting them may delete other files. This is a flat out bug.
The attached ZOSV2GTM fixes these issues. Note that excepting comments, the change replaces 4 lines of code with 11 lines of code. The enhanced version:
1. Is upward compatible with the old in the case where the old entryref works correctly and deletes both source and object are in that same first directory of $ZRO.
2. In the case where the first bit of $ZRO is of the form www(xxx ...) and the object is in www and the source is in xxx or a directory upstream, the new routine attached deletes the source and object file from the correct directories. This fixes the bug in 2. above.
3. It does not attempt to delete any file with an extension of .obj. This fixes the bug in 3. above.
4. In the case where the routine to be deleted is upstream, e.g., $ZRO is of the form www(xxx ...) yyy zzz and the routine is in yyy or zzz, deleting files in yyy or zzz can impede the operation of another environment that may be using the same files. In this case, the new routine creates a new routine in xxx with the single line " ZM 150374338:
Refer to example below.
I disclaim all claim of copyright to this code change.
Regards
-- Bhaskar
-------
$ mumps -dir
GTM>w $zro
. /opt/lsb-
GTM>zsy "cp ../demo/hello.m . ; ls -l hello*"
-rw-r--r-- 1 gtmuser gtm 24 2009-04-13 13:32 hello.m
GTM>d ^hello zsy "ls -l hello*"
Hello,Universe
-rw-r--r-- 1 gtmuser gtm 24 2009-04-13 13:32 hello.m
-rw-r--r-- 1 gtmuser gtm 317 2009-04-13 13:32 hello.o
GTM>d DEL^ZOSV2GTM(
GTM>zsy "ls -l hello*"
ls: cannot access hello*: No such file or directory
GTM>s $zro=". ../demo "_$ZTRNLNM(
. ../demo /opt/lsb-
GTM>zl "hello"
GTM>d ^hello
Hello,Universe
GTM>d DEL^ZOSV2GTM(
GTM>zsy "ls -l hello*"
-rw-r--r-- 1 gtmuser gtm 32 2009-04-13 13:34 hello.m
GTM>zl "hello"
GTM>d ^hello
%GTM-E-FILENOTFND, File hello not found
At M source location +1^hello
GTM>zsy "ls -l hello*"
-rw-r--r-- 1 gtmuser gtm 32 2009-04-13 13:34 hello.m
-rw-r--r-- 1 gtmuser gtm 329 2009-04-13 13:34 hello.o
GTM>h
$ diff ZOSV2GTM.m~ ZOSV2GTM.m
41c41,46
< N %N,%DIR,
---
> ; Since the actual routine may be somewhere in a search path, and may be shared
> ; with other environments, this places a routine in the first source directory in
> ; the search path, which, if executed, generates an error to the effect that the
> ; called routine doesn't exist (i.e., it's a way to effect a deletion without
> ; actually deleting the routine).
> N %N,%DIR,
43,44c48,55
< S %I=$I,%
< O %F:(NEWVERSION) U %F W " ZM 150374338:
---
> D SILENT^%RSEL(RN) S %S=%ZR(RN) ; %S now has the directory of the source
> D SILENT^
> S %DIR=$$RTNDIR^%ZOSV ; %DIR now has the first source directory in $ZRO
> S %N=$TR(RN,"%","_") ; %N now has the file name for RN (sans extension)
> I $ZPARSE(
> .S %I=$I,%
> .O %F:(NEWVERSION) U %F W " ZM 150374338:
> E ZSY "rm -f "_%S_%N_".m "_%S_%N_".o"
$
-------
Related branches
Changed in openvista-gtm-integration: | |
milestone: | none → phase-1-alpha |
Changed in openvista-gtm-integration: | |
status: | Fix Committed → Fix Released |
I realized the TEST^ZOSV2GTM entry also needs to be updated. I
replaced four lines with two. Note that the diff shows the changes
previously submitted as well as the new ones.
Regards
-- Bhaskar
------- ------- ------- ------- ------- ------- ------- ------- ------- -- EHR/VOE10/ r/ZOSV2GTM. m ZOSV2GTM.m %I,$ETRAP, %F,%O,% S DIR=$$RTNDIR^ %ZOSV,RN= $TR(RN, "%","_" ) %DIR_RN_ ".m",244) ) ZSYSTEM "rm -f "_%DIR_X_".m" %DIR_RN_ ".obj", 244)) ZSYSTEM "rm -f "_%DIR_X_".obj" %DIR_RN_ ".o",244) ) ZSYSTEM "rm -f "_%DIR_X_".o" %RSEL(RN, "OBJ") S %O=%ZR(RN) ; %O now has the directory of the object %S)'=$ZPARSE( %DIR) D F=%DIR_ %N_".m" $P($ZPOS, ""^"",2) Q",! U %I C %F %ZOSV() _$TR(RN, "%","_" )_".m" "X.X",245) ,%X=$ZSEARCH( %F,245)
$ diff /opt/WorldVistA
41c41,46
< N %N,%DIR,%I,$ETRAP
---
> ; Since the actual routine may be somewhere in a search path, and may be shared
> ; with other environments, this places a routine in the first source directory in
> ; the search path, which, if executed, generates an error to the effect that the
> ; called routine doesn't exist (i.e., it's a way to effect a deletion without
> ; actually deleting the routine).
> N %N,%DIR,
43,46c48,55
< S %I=$I,%
< I $L($ZSEARCH(
< I $L($ZSEARCH(
< I $L($ZSEARCH(
---
> D SILENT^%RSEL(RN) S %S=%ZR(RN) ; %S now has the directory of the source
> D SILENT^
> S %DIR=$$RTNDIR^%ZOSV ; %DIR now has the first source directory in $ZRO
> S %N=$TR(RN,"%","_") ; %N now has the file name for RN (sans extension)
> I $ZPARSE(
> .S %I=$I,%
> .O %F:(NEWVERSION) U %F W " ZM 150374338:
> E ZSY "rm -f "_%S_%N_".m "_%S_%N_".o"
80,83c89,90
< N %F,%X
< S %F=$$RTNDIR^
< S %X=$ZSEARCH(
< Q %X
---
> D SILENT^%RSEL(RN)
> Q $G(%ZR(RN))
$ mumps -dir
GTM>w $$TEST^ ZOSV2GTM( "foo")
GTM>w $$TEST^ ZOSV2GTM( "ZOSV2GTM" ) vista/ ZOSV2GTM( "%GO") gtm/V5. 3-003_i686/ ------- ------- ------- ------- ------- ------- ------- ------- --
/home/gtmuser/
GTM>w $$TEST^
/opt/lsb-
GTM>h
$
-------