PxPlus User Forum

Twitter Twitter Twitter

Author Topic: Program Caching  (Read 3406 times)

Lawrence_Leavell

  • Silver Member
  • ***
  • Posts: 49
    • View Profile
Program Caching
« 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

EVa

  • Gold Member
  • ****
  • Posts: 54
    • View Profile
    • EDIAS
Re: Program Caching
« Reply #1 on: April 16, 2019, 03:23:24 AM »
Don't ADDR programs that you are going to edit ?

Peter.Higgins

  • Diamond Member
  • *****
  • Posts: 124
    • View Profile
Re: Program Caching
« Reply #2 on: April 19, 2019, 08:22:17 AM »
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

  • Diamond Member
  • *****
  • Posts: 3811
  • Mike King
    • View Profile
    • BBSysco Consulting
Re: Program Caching
« Reply #3 on: April 21, 2019, 01:33:28 PM »
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.
Mike King
President - BBSysco Consulting
eMail: mike.king@bbsysco.com

Lawrence_Leavell

  • Silver Member
  • ***
  • Posts: 49
    • View Profile
Re: Program Caching
« Reply #4 on: May 05, 2019, 12:07:11 PM »
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

  • Diamond Member
  • *****
  • Posts: 3811
  • Mike King
    • View Profile
    • BBSysco Consulting
Re: Program Caching
« Reply #5 on: May 06, 2019, 10:14:46 AM »
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.

Mike King
President - BBSysco Consulting
eMail: mike.king@bbsysco.com

James Zukowski

  • Diamond Member
  • *****
  • Posts: 297
    • View Profile
Re: Program Caching
« Reply #6 on: December 16, 2019, 09:49:41 AM »
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!
James Zukowski
Sr. Developer - J&E

BRAND>SAFWAY
Brand Industrial Services

Mike King

  • Diamond Member
  • *****
  • Posts: 3811
  • Mike King
    • View Profile
    • BBSysco Consulting
Re: Program Caching
« Reply #7 on: December 16, 2019, 02:28:06 PM »
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.

Mike King
President - BBSysco Consulting
eMail: mike.king@bbsysco.com

James Zukowski

  • Diamond Member
  • *****
  • Posts: 297
    • View Profile
Re: Program Caching
« Reply #8 on: December 16, 2019, 03:43:22 PM »
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
Sr. Developer - J&E

BRAND>SAFWAY
Brand Industrial Services

James Zukowski

  • Diamond Member
  • *****
  • Posts: 297
    • View Profile
Re: Program Caching
« Reply #9 on: December 19, 2019, 12:15:33 PM »
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
Sr. Developer - J&E

BRAND>SAFWAY
Brand Industrial Services

James Zukowski

  • Diamond Member
  • *****
  • Posts: 297
    • View Profile
Re: Program Caching
« Reply #10 on: December 20, 2019, 11:49:08 AM »
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.
James Zukowski
Sr. Developer - J&E

BRAND>SAFWAY
Brand Industrial Services

Dave Fullerton

  • Silver Member
  • ***
  • Posts: 35
    • View Profile
Re: Program Caching
« Reply #11 on: December 20, 2019, 12:08:20 PM »
Hi:

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

Regards

Dave Fullerton

James Zukowski

  • Diamond Member
  • *****
  • Posts: 297
    • View Profile
Re: Program Caching
« Reply #12 on: December 20, 2019, 12:34:49 PM »
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.
James Zukowski
Sr. Developer - J&E

BRAND>SAFWAY
Brand Industrial Services