Menu
▾
▴
#37 %RCE deletes routines
I've been trying to use GT.M's %RCE to make changes to a set of routines, but each time it makes a change to a routine, it deletes it. This problem may be related to how the environment is configured, though as far as I know, I have not violated any rules with my configuration. For example, if I create an empty directory, execute "mumps -direct" from within that directory, and then use %RCE on routines I create there, it works as expected, but when my routine path is more complex, it generates an error for each change it makes and then deletes the routine it changed.
Along with deleting the routine, it also generates an error message: reof^%RCE,%SYSTEM-E-ENO18, Invalid cross-device link. I've searched GT.M's Message and Recovery Manual, but I cannot find this message. So I'm at a loss.
Before I start tearing apart the %RCE code, I'm wondering if anyone else has had this issue, and if so, how did you correct it?
I've provided some details below, but if more is needed, please let me know, and thanks for your help.
Version: GT.M V6.3-001A Linux x86
O/S: Ubuntu 16.04.3 LTS
$zroutines: /gtm/LVA/SPF/code/o(/gtm/LVA/SPF/code/r /gtm/util/dev/code/r /gtm/vista/pro/code/r) /opt/fis-gtm/v63001a_i686
Note: The Linux account that's running the GT.M process has read/write access to all of the directories in $zroutines except, of course, for /opt/fis-gtm/v63001a_i686.
Sample run:
GTM>zedit "test"
test ;
write !,"hello"
quit
GTM>d ^test
hello
GTM>d ^%RSEL
Routine: test
test
Current total of 1 routine.
Routine:
GTM>zwrite %ZR
%ZR=1
%ZR("test")="/mnt/gtm/var/gtm/LVA/SPF/code/r/"
GTM>d ^%RCE
Routine Change Every occurrence
Routine: test
test
Current total of 1 routine.
Routine:
Old string: hello
New string: world
Replace all occurrences of:
hello<
With:
world<
Show changed lines <Yes>?:
Output device: <terminal>:
Was: write !,"hello"
Now: write !,"world"
reof^%RCE,%SYSTEM-E-ENO18, Invalid cross-device link
Total of 1 routine parsed.
1 occurrence changed in 1 routine.
GTM>d ^%RSEL
Routine: test
Current total of 0 routines.
Routine:
Note: A subsequent search of the O/S confirms that the routine was indeed deleted. If I run the routine before I use %RCE, the object version (e.g., test.o) is not deleted.
HI, Alan!
Just a wild shot in the dark, but are your routines perhaps on a USB flash
drive on a FAT file system? Where does /mnt/gtm/var/gtm/LVA/SPF/code/r/
come from?
Regards
– Bhaskar
On Fri, Feb 2, 2018 at 10:23 AM, Alan O'Neill aoneill5@users.sourceforge.net wrote:
Related
Support Requests: #37
Alan:
Please try adding this line (the one with the "+"):
diff --git a/sr_port/rce.mpt b/sr_port/rce.mpt (aka RCE.m)
index 3d9a072..bb92289 100755
--- a/sr_port/rce.mpt
+++ b/sr_port/rce.mpt
@@ -75,6 +75,7 @@ work s %ZR="",r=$zsearch("__")
scan s r=%ZR(%ZR)$tr($e(%ZR),"%","")$e(%ZR,2,9999)_".m",o=$zsearch(r),fnd=0
u $p i out,%ZD'=$p!'outd w:$x>70 ! w %ZR,?$x\10+1*10
i outd u %ZD w !!,r
+ s tf=$zparse(r,"DIRECTORY")_tf
o:%ZC tf:(newversion:exception="s fnd=0 g reof") o o:(readonly:record=2048:rewind:exception="g rnoopen")
u o:exception="g reof"
s cnt1=cnt1+1
One or more of your routine directories must be on a different mount point than your working directory (which results in the rename getting the errno 18).
The above change places the temporary file in the same directory as the original file to avoid the issue.
Thanks,
Bill
Thanks a million! That did the trick.
To answer Bhaskar's question: All of the mounted partitions are ext4 file systems. I configure my systems with one "local" partition for the O/S plus a few (the number is dependent on the system) that are replicated via DRBD to a secondary location for disaster recovery purposes. Of course, to any application running on the system, it should perceive all partitions as residing on the local machine, and strictly speaking, the data is stored on the local machine (as well as the remote machine where it is being replicated), albeit different partitions. It is likely that my working directory while running ^%RCE was /home (one replicated mount point), and it was operating on routines stored on /mnt/gtm (a different replicated mount point).
I really appreciate your kind (and swift!) attention.
As a follow-up, I found that adding the suggested line had two negative outcomes. One was that ^%RSE failed with an undefined error. The other was that when multiple routines needed to be changed by ^%RCE, the O/S path in the tf variable grew continuously until the string exceeded 256 characters and an error occurred. To address these issues, I altered the line to read as follows.
i %ZC,tf'["/" s tf=$zparse(r,"DIRECTORY")_tf
The second test (i.e., tf'["/") may be less than ideal. It works for me since I'm running GT.M on Linux, but I don't know what it might need to be for different operating systems. I also wonder what might happen if routines being updated are spread over multiple partitions.
I'm happy with the update as it stands. I'm writing to let you know in case you intend to incorporate it into future releases.
Thanks again!
Thank you for the feedback.
We will consider this when making the update for future releases.
Thanks,
Bill