Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 13 JUL 2009 02:14:08AM Colin Rule wrote:

Can anyone suggest the appropriate use of these program functions.

We have a client with memory problems, and these indicate they may have some impact, but until I understand their role I am unhappy about using.

Thanks

Colin


At 13 JUL 2009 09:05AM Richard Hunt wrote:

My experience of FLUSH and GARBAGECOLLECT are that they are pretty much 100% automatic. When they are needed they are used by the system automatically. It is extremely rare that a programmer has to call these two routines manually.

I do use GARBAGECOLLECT when I install a new program or upgrade to a program. I post a message forcing a GARBAGECOLLECT for all current users so that the new program or upgrade is used rather than the cached version of the program. This replaces having the users to close OpenInsight.

I have never had to use FLUSH. Maybe someone might use it for a custom MFS.

If you mean memory problems as in "out of memory" then I would suggest that you check to see what item you have that is eating up memory. Maybe too much usage of Common variables or not freeing them.


At 14 JUL 2009 01:27AM Barry Stevens wrote:

*Richard*

…"I post a message forcing a GARBAGECOLLECT for all current users…"

May I ask how you achieve that.

*Colin*

If there is a certain program that is give problems, then I would insert FLUSH followed by GARBAGECOLLECT in appropriate places. I remember having to do this in arev for IDX_SETS problems.


At 14 JUL 2009 01:49AM Richard Bright wrote:

Colin,

In the distant past I had problems with Detach / Attach of Volumes where tables where similar. I found that running Flush (the program stack) and garbagecollect solved this. I understand that this is (now) superfulous, but … I guess I have Ludite tendancies.

Richard Bright

BrightIdeas New Zealand


At 14 JUL 2009 09:12AM Richard Hunt wrote:

I have a LOGINS table that each logged in user creates a row similar to the SYSLOGINS table. The LOGINS table has fields set aside for sending messages to each individual user. Each logged in user then checks periodically that field in the LOGINS table for messages either thru the TIMER event or thru a COMMAND routine that I created. It is very similar the the POSTMESSAGE. This allows the System Admin to control users.

Basically there are only two ways that a user can do things within my system. One: menu item, which executes a command and is very similar to the START button and taskbar in Windows. Two: command, very similar to a TCL command and also similar to the RUN item in Windows.


At 14 JUL 2009 09:43PM Barry Stevens wrote:

Cool, thanks for sharing.


At 17 JUL 2009 04:39PM Leon Shaffer wrote:

*We have a client with memory problems*

Colin, Can you please be more specific about what "type" of memory problems. Our application was "crashing" for 9 months before it was discovered (by Revelation) that the use of the command

inlist

was causing all of the issues with the "crashing" and "memory problems".


At 19 JUL 2009 08:02PM Colin Rule wrote:

The errors were 'The instruction at 0x00000000 referenced memory at 0x00000000. The memory could nto be read.

This be before I implemented the Flush and Garbage collect.

Leon, I would be very interested in understanding the errors you had and the solution to see if they concur.

Thanks

Colin


At 20 JUL 2009 07:06PM Richard Bright wrote:

Colin,

I believe the InList abend was version(s) specific, and fixed in later OIv8x - someone may wish add the specifics.

Richard Bright


At 21 JUL 2009 07:32AM [email protected] wrote:

Richard,

Inlist() has always been broken right back from OI4 (maybe even OI3) from what I can see. It's fixed in 9.1. It was a very subtle bug that could take a long time to appear depending on what string you were searching and the precise conditions of the process memory heap at that time. I eventually tracked it down due to some fine work by Jared in setting up an automated testing scenario to be able to replicate the issue under debug conditions.

I'd be surprised if Colin's error was the inlist one however - it's signature was quite different IIRC. The interesting thing here though

is that the Instruction Pointer is at 0x00000000 which usually means a problem that's more low level - I've seen this with DEP, various IE toolbar conflicts, and some device drivers - basically anything thats hooked low into the OS - not always easy to tell without running it under a debugger and seeing the call stack…

[email protected]

Captain's Blog

Battlestar Sprezzatura - BSG 77

Colonial leaders in all things RevSoft


At 21 JUL 2009 08:37AM John Bouley wrote:

I've also seen similar messages when windows automatic update are corrupted. There is a Microsoft KB article describing how to reset and clear out the update store on the worksation. I wish I could remember the article number…

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/0c5f9c5433c5ad68852575f20022410a.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1