Program Caching

[Lawrence_Leavell]

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

[EVa]

Don't ADDR programs that you are going to edit ?

[Peter.Higgins]

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. 

[Mike King]

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.

[Lawrence_Leavell]

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

[Mike King]

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.

[James Zukowski]

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!

[Mike King]

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.

[James Zukowski]

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

[James Zukowski]

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?

[James Zukowski]

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.

[Dave Fullerton]

Hi:

Couldn't you just add ;close(lfo) after your test fin(Prog_FNC$,"LCL_MTime")?

Regards

Dave Fullerton

[James Zukowski]

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.