CL6 PURGE CACHES, REINDEX, RELOAD COMMANDS

[Tom Parsons]

On CL 6 re the commands

-Purge Caches (refresh a TABLE)

-Reindex (refresh a NEW TCL proc, after mktclindex)

-Reload (refresh an existing TCL proc)  

Do these commands have a LOCAL or GLOBAL effect ?

That is, does it affect ONLY the specific thread selected (LOCALLY)

OR

is the effect- GLOBAL

affects all threads within that process

or

affects all threads within all processes within the site ?

Thanks,

Tom

[]

Topic

[Jim Kosloskey]

If you execute them in the Gui for a thread then they are effective for that thread, if you execute at the process then they are effective for all the threads in the process.

As far as I know the commands cannot be global to a site or for many sites without writing some code.

This presents a challenge when global Tcl procs are used in a multi-site environment (such as we have).

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Tom Parsons]

Does the PURGE CACHES function work to refresh a TABLE called from a tps proc ?

Thanks,

Tom

[]

[Jim Kosloskey]

Yes assuming an engine proc and not a command line proc.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Charlie Bursell]

Not sure about that Jim.  Purge cache only purges what is in memory.  

If he is using tbllookup the table is not stored in memory but looked up when called.

It should be a moot point however.  If he updates the table while the proc is running any subsequent lookup will get new data whether you run purge cache or not

[Jim Kosloskey]

I just always did a purge caches when any Table used inside Cloverleaf but did not know how to check to see if the Table actually got updated or even if it was stored in memory.

My (somewhat faulty) long term memory seems to have recollection of my asking that question early in my use of Cloverleaf and I thought the answer was any Table referenced within the confines of the engine was loaded into memory. As I say my recall is tricky and the answer given then could have been incorrect as well.

First reference though does make sense so in any case it is moot as you say.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Belinda Sams]

Is there anyway to do purge caches from the command line or does it have to be done via the GUI?

I’m also hearing that there have been lots of problems with this function in the past. Is there any kind of proof that it is stable now?

[Jim Kosloskey]

What I do is to turn on the command output in the NetMonitor View then do a purge caches and in the Command Output will be the command and arguments.

You can then look the command up in help to see all the options or (in most cases) execute the command with a ? or -? I believe to see the syntax.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Kosloskey]

What I do is to turn on the command output in the NetMonitor View then do a purge caches and in the Command Output will be the command and arguments.

You can then look the command up in help to see all the options or (in most cases) execute the command with a ? or -? I believe to see the syntax.

As for reliability, I will let others respond as the release I have available is 6.0.0. While I have not had any issues I can recall (I use it in Test a lot) I can’t vouch there are none in this release.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Tom Parsons]

FYI…

I ran a test (CL 6.1.2.0) with an active thread using a tps proc that called a TABLE (tbllookup).  

Simply changing the TABLE itself DID NOT pickup the REFRESHED TABLE for any subsequent calls to the tps proc.  

Then I ran a PURGE CACHES (GUI) from the still active thread and then it DID pickup the REFRESHED TABLE.

Thanks,

Tom

[]

[Jim Kosloskey]

Thanks Tom!

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Charlie Bursell]

I think I stand corrected here.  Upon further inspection it seems reloading the proc and clearing out the interpreter has as much to do with it as anything.

Try this

run Tcl at the command line

tcl>

Then run a tbllookup

tcl>tbllookup cbtbl UHLB

MSH4

Now edit the table and change the value, in my case change to MSH5, and do again without exiting Tcl

tcl>tbllookup cbtbl UHLB

MSH4

Note I still get old value

Now exit Tcl and reenter (new interpreter)’

run Tcl at the command line

tcl>

tcl>tbllookup cbtbl UHLB

MSH5

So in apology it looks like you have to purge cache.  You learn new things all the time.  I still don’t know if it is a function of reloading the table or the Tcl proc.  I don’t know for sure if purge cache reloads the proc or not.

When I get time I would like to test it with just a reload command and see what happens.

With all that said I have never been a huge fan of the purge command.  I still prefer to recycle the process if at all possible.  I have seen occasions where the command thread in the process is busy and the purge does not get executed before timeout.  It may be better in newer versions, I don’t know.  But, if I cycle the process, I know double dog sure my changes will take effect,

[Charlie Bursell]

Tom:

Are you sure got changes to take effect with the purgex command? Maybe I am doing something wrong but it did not work for me using CL 6.1 on Windows.

I put a tbllookup command in a proc and echo’ed the results.  I ran the engine and saw the expected output in the log.

I then modified the table and tried several things

     Tried reload proc at both thread level and process level

     tried purgex at both thread level and process level

     Cycled the thread

I tried each of the above several times.  There were no messages queued up as I was only running one at a time through the engine and then KILL it right after the echo.

The output in the log from the echo remained the same

When I did a restart on the process, only then did my echo command show a different result.

Weird!  I never expected that.  Maybe its just me I don’t know

I enclosed a copy of the log file file prior to the restart showing the commands were executed.  The original table value was MSH4 and I changed it to MSH5 after the first echo.

Jim:

If you get a chance give this a try and tell me what you get.  Send me an e-mail

I still think the best thing to do to make changes take effect is a restart of the process.

[Charlie Bursell]

The attachment did not attach  😀

Evidently it does not like *.log files so I changed it to txt

[Robert Kersemakers]

FWIW I have never used purge/purgex, just restarted the whole process as soon as a table entry or Xlate changed.

I thought when changing the properties of a thread, you only needed to restart the thread. But ‘advanced scheduling doesn’t work that way, at least I have to restart the whole process to activate changes in advanced scheduling.

You can load tables yourself with TioLoad and then you’re always sure to always have the most current content. At least I hope so…

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Belinda Sams]

What is TioLoad? I’ve never heard of that. We are trying to find a way to cycle in table changes without causing a disruption in service. I know cycling a process only takes seconds but it’s still considered a disruption in service. That’s one reason we were looking at purge cache, but it sounds like that still isn’t very reliable. Any ideas?

[Robert Kersemakers]

TioLoad is an internal command to load a table into memory. Not sure how I found this; maybe from this forum.

What I wanted was to load a table because it contained rules, instead of a transformation.

For instance the ‘in’ would contain two lists of codes (A and B) and the ‘Out’ would contain a groupcode. If the order message that was processed contained a code from list A and from group B, then the groupcode would be set to what was in the ‘Out’. I couldn’t do this with a transformation and I wanted a way to adjust these rules easily without changing the translation every time, hence the table.

It is used like this in an Xlate:

Code:

@null -> @list_combinations

with tcl

Code:

set recid “Sap_aanvraagcode_combinaties_aparte_order.tbl”
TioReset $recid
TioLoad $recid Sap_aanvraagcode_combinaties_aparte_order.tbl
set xlateOutVals [list [TioGetValueLists $recid]]

Now that I look at it again, this piece of code looks weird to me. But it works so hands off.

Regarding the disruption of service: we don’t have such strict rules. Are they really necessary?

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Peter Heggie]

I also had the same experience with 6.0 – only a recycle of the process brought in the updated table value.

Peter Heggie

[Author]

Replies