PxPlus User Forum
Main Board => Discussions => Programming => Topic started by: Lawrence_Leavell on April 15, 2019, 11:58:24 AM
-
We have witnessed program caching on three systems, all Linux, using ProvidexPlus. We make a change to a program, SAVE it, then moments later we LOAD the same program and it is the PREVIOUS version, NOT containing the new changes.
We have turned off parameters 'CC', 'PC'=0, -'+C', all to no avail.
If we drop out of Providex and re-enter, we get the new version of the program, so it seems that Providex is causing the issue.
What are we missing?
Lawrence Leavell
-
Don't ADDR programs that you are going to edit ?
-
Lawrence,
We see the same issue with editing objects, and some graphical programs. It is not 100% but few can be edited in session after running. Have eliminated the cache as well. Appears that the objects or programs are triggering a condition that locks them into memory. For instance on our progress bar objects, after running a report, I remember
the graphic animation object could be edited in session, but the widget window object could not. Think perhaps it could be windx related, or com interface related as I added pdf and excel object interfaces to ones I can remember the session issue with.
-
Lawrence, generally caching should not be enabled during development when programs are changing.
This is especially important when doing any sort of Global Functions or Objects as these definition lock versions of the code into memory so any changes may NOT be reflected after a Save.
Caching is provided to improve system performance by maintaining the copies of previously loaded program in memory for re-use. By definition it should be avoided when these programs are changing.
-
We have carefully reviewed the Parameters and we are not ADDR'ing any programs, yet some programs seem to be locked in memory, very frustrating during a development cycle. All caching is turned off yet still happening.
Lawrence Leavell
-
Lawrence
The system automatically locks program in memory if there are any active references to them. Apart from the ADDR directive, here are some other examples of why programs will be locked:
- The program is part of an object definition
- The program defines a global function
- The program issues a CALL, PERFORM or method/function call thus the return location is on the CALL stack
Also the program editors may update the program files however depending on how you launched the editor the current program may not be updated to reflect the program changes. For example if you use the NOMADS designer and have it launch a editor session, the updates will not update the current program as they occur in a separate process.
Also the 'PC' system parameter will cause the system to cache programs to improve performance so make sure this is not set.
-
We've set up a separate program to contain all of our global functions, in anticipation of making changes in the future without having to modify our standard startup program. Now that I want to make a change, I can't save the program under the same name; I get Error#0: Record/file busy.
Is there a way around this? Or do I need to have everyone get to a point of not using any of the global functions?
Thanks!
-
Unless you have locked the program down you should be able to change it as generally the system only keeps a copy of the program file in memory.
-
That's what I would have thought. Evidently, as soon as a global function is used, the program that contains that function is loaded into memory as an open file. And since it's an active loaded file, it seems to lock out re-saving the file, as if it's trying to create a new file but can't delete the old one first since it's open.
PxPlus v13.10 on Linux RedHat 5.11 with WindX through *nthost/*ntslave
-
I think I figured it out, though it does lead to another question.
In our menu program, I test fin(Prog_FNC$,"LCL_MTime") against a previous global value. This seems to 'open' the (program) file, but not close it. The new question: How can this "file" (Prog_FNC$) be closed?
-
I've worked around doing this in a single statement (though I'd like to get back to that).
It's now an OPEN INPUT; Var$=fin(); CLOSE to get the date/time info for the comparison. Works fine, but a little more than I'd like.
-
Hi:
Couldn't you just add ;close(lfo) after your test fin(Prog_FNC$,"LCL_MTime")?
Regards
Dave Fullerton
-
Probably so, but the situation is more like:
if nul(Prog_FNC$) or fin(Prog_FNC$,"LCL_MTime")>%FNC_Time$ then perform "Update_Prog"
A close(lfo) after the perform is probably not appropriate. As an 'else', perhaps, but the whole thing starts getting very messy-looking for future maintenance, especially with the nul() test.