Is there a way to flush the routine buffer for a cached routine?

Question

Question

George Hodder · Oct 14, 2022

I am having an issue where a routine that is changed is at times still running the old version of code. The routine is compiled after the change.

I am wondering if it is possible that the routine code is still in the routine buffer cache. Is there a way to force a flush or reload of the buffer for a given routine?

Product version: IRIS 2020.1

$ZV: IRIS for UNIX (Red Hat Enterprise Linux for x86-64) 2020.1 (Build 217_1_20000U) Wed Jun 10 2020 21:40:24 EDT

Discussion (4)1

Log in or sign up to continue

Robert Cemper · Oct 14, 2022

This is intentional behavior.
If the routine you changed calls some subroutine it is kept "on the stack"
This is a requirement to have a save return and continuation after the call.

The new version only becomes active after you have left the previous one by QUIT or RETURN.
simpler: if it is gone from the return path.

1 0

Michael Davidovich · Oct 17, 2022

I'm just poking around here to gain some knowledge. When you say routine to you mean a compiled MAC file? I'm curious to know how ZR would work if you've compiled the routine and, as Robert said, it's not on the stack. Any time I've run a routine from the CLI and do a zprint, there's nothing there, so I'm not sure what ZR would remove it ZP isn't showing in the buffer. When you call an entry point and there's a quit, isn't there an inherent ZR to get the routine out of the buffer?

I guess I'm simply asking: did ZR solve your issue?

0 0

score 0 · Answer 1 · 2022-10-17T08:53:38-04:00

Benjamin De Boe · Oct 17, 2022

Try the zremove (or zr in short) command without arguments.

0 0

score 0 · Answer 2 · 2022-10-18T02:33:00-04:00

I guess it would not as ZRemove / ZLoad / ZIinsert / ZSave commands are mostly used as tools for the legacy way of editing routines (using routine buffer) rather than for code execution. Of course, one can execute the code inside the previously loaded routine: `zload routine do sub(...)`, but this looks strange if compared with the normal way of doing the same using `do sub^routine(...)` or `set sc=$$fun^routine(...)`. In short, virtually nobody runs code this way.