I have a customer who has suddenly (in the last several days) started to get GFEs with our RevG application. It has been my experience that GFEs result from hardware problems (network card, dirty power, etc.) 90% of the time and perhaps competitive software catching 10% of the time. He says that he has not installed any new software and I had him change out his network card. We have addressed GFEs numerous times over the years usually on Networks but this has be baffeled.

The user states that he is able to reproduce the problem from a clean set of datafiles (no-GFEs) upon demand. He can do it on different machines and from the network drive OR HIS LOCAL C DRIVE! He has experienced the problem in several specific spots in the application but one area which he can repeat it with 90% regularity involves a routine we have tied to a function key to free up the conventional memory by using the CHAIN command to return to the software's main menu thereby garbage collecting and flushing all the accumulated data that is no longer in use. The file that gets corrupted is a temporary scratch file that we use through out the application.

Any ideas?

Tom

Tom,

If this is an older computer, a couple of things I would look at. First, the easy one, make sure the computer fan is working. If the fan isn't working, the computer will heat up and funny things will happen to the computer memory (i.e., GFEs etc.) Memory chips are made in layers and when the temperature gets too hot the memory chip becomes unstable. This can cause GFEs, indexing problems, etc. This problem is reproducible just clogg the air-circulation into your computer or stop the fan and see what happens when users start banging away . When your user swapped out the card, he might have notice that the card is a bit warm (if the fan isn't working), but then he may not have noticed it for a number of reasons.

The other thing could be bad memory. There are memory checkers, but they may cost more than to replace the memory if you don't already have one or access to one.

Don't know if any of this will help, but hope you get this problem resolve. I know how you must feel. It's no fun. Good luck.

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Tom,

I heartily agree with Ray on the memory (RAM) issue. I've seen that sooo many times it's not funny.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don / Tom:

Since the problem can be made to happen on DIFFERENT machines, I would tend to discount the possibility of memory or hardware issues. Since it can be made to happen on a local (C:) drive as well, that pretty much rules out the network as well.

About the only thing I can think of is that the temporary file that you use has a corrputed header (assuming it's a .LNK file). My guess is that you do a CLEAR-FILE on the temp file before you use it. What would happen if you used a DELETE / CREATE sequence? I assmume that you don't need much in the way of a dictionary if it's a temp file that is used in various ways thoughout your app.

Other than that, I'm stumped too.

Don Miller

C3 Inc.

A CLEAR-FILE will often correct some GFEs but not Frame Header corruption. It is best to delete/create the file in question as Don has suggested.

Is the modulo of the file a prime number? A file modulo that is an even number can, in certain circumstance, cause GFEs. It is also possible that the file is grossly undersized for the amount of data that is being pumped into it.

Don,

Your point is well taken, however, it just so happens I've seen an entire fleet of machines all have bad RAM. Usually this could be traced to the machines all coming from the same source.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks to everyone for the comments.

When this temp file becomes corrupted we DELETE-FILE to remove it and replace it with a clean one. The file is dynamically resized depending on the database. For this customer the file is a link file with a modulo of LNK112. I am particularly intrigued with Warren's comment about the file size but I don't believe it is an issue. I will try resizing the file and see if that helps.

I will also have them to a RAM test. I am convinced it is a hardware related problem especially since it just suddenly started happening.

Tom

Just peeked at your original message:

I take it they are running under Novell 3.x with DOS workstations?

Has anyone changed transaction tracking or any of the network caches and buffers on the server (even though the problem can be reproduced locally)?

Are they using a disk caching program such as smartdrive?

Have they scanned for a virus recently?

Do they have a virus scanner installed? Was it updated recently? Are the .lnk files excluded from the scanner?

I thought I should report the progress in my investigation of this weird problem with GFE's.

Following Warren's idea concerning the possiblity that the file was just way too small I had the user resize the file to be 2.5 times larger (700K to 1.8M). The result was that when he hit our special "CHAIN" function key to IMMEDIATELLY garabage collect and flush, he no longer had a GFE instead he obtained an "Out of Memory" error!

I had him repeat the exercise and to check the amount of conventional memory available (remember this is RevG), which is another function key feature built into this application. He had 280K going in (which is low, I generally have about 390K).

So now you geniuses out there, let's hear a dissertation as to exact what is happening here!!!

I'm no genius. I don't even know what RevG is…I was just making guesses

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Tom ..

REV-G's filing system for .LNK files could buffer some data, but not nearly as much as you described. In REV-G you couldn't make a frame size any larger than 1,024. The CHAIN statement should have released the memory used by the code and descripter tables (unlike a call) and should force a GARBAGECOLLECT to compact string space. You observe that there is only 290K available vs. an expected 390 or so on your machine. What could have claimed the memory? Can you examine the program stack for any clues? Is it possible that some piece of code is using curly-braces dictionary calls? My recollection is that the CHAIN statement preserves all labeled common blocks and all @ variables (@RECORD???).

Big head scratch…

Don Miller

C3 Inc.

What are the FILES and BUFFERS setting in config.sys?

BUFFERS=20

FILES=200

works best with REV G.

"What could have claimed the memory? Can you examine the program stack for any clues?"

Yes I asked the customer to have his System Manager fine tune his RAM What could have claimed the memory? Can you examine the program stack for any clues? in the conventional memory segment using EMM386 or other tool. My guess is that he has some junk in there. I was going to have him do a MEM /C ] LPT1 to print a report showing the contents of the conventional memory but I didn't and figured I would wait until I was contacted by their System Manager to see how DOS-savy he was.

"Is it possible that some piece of code is using curly-braces dictionary calls?"

No, none of the code is using curly-braces dictionary calls. Some of other code, but not directly this one, uses the PERFORM statement on TCL commands which may utilize dictionary names, e.g. PERFORM "SELECT INVOICES BY CUSTOMER" etc.

"My recollection is that the CHAIN statement preserves all labeled common blocks and all @ variables (@RECORD???)."

I believe that is correct which effectively clears everything out except the global items you want to retain.

Thanks for your comments.

Tom

I dimly recall there was a way to affect or disable file caching in Rev G - is there a PARAMETERS record in the VERBS or SYSOBJ file or something like that? It wasn't fun to do on a floppy based system or an old XT but with todays fast drives and networks it probably won't make much of a difference.

Where are the Sprezzies when you need 'em?

Set STORAGE to zero I seem to recall …

The Sprezzatura Group

World Leaders in all things RevSoft - especially the trivia

The user resized the file a second time to somewhat smaller values and now there is no GFE nor "Out of Memory" error! It appers that the file size somehow impacts the available memory when one is trying to clear the file.

What os's are your clients machines running?

Specifically what did they add to every PC most recently?

Suggestions could be Virus Scanners, new network drivers, or an upgrade to a newer version of DOS.

Paul,

As discribed in some of the earlier correspondence on this topic, the user is running Win98. He is able to get the GFE's when running from his NT network as a workstation or running stand-alone from his c:\ drive. When we resized the file to be twice as big the GFE problem disappeared and was replaced by a "out of memory" or "out of string space" error (I don't remember which) when we made the file somewhat smaller, the memory error disappeared.

The message is that there is some interdependence between the amount of RAM, file size and GFE's.

It is probaly going to get down to how his DOS prompt is configured in Win 98. It could be that his Virus scanner has recently been updated which could have disastorus results in a DOS box on Win 98. As I recall, earlier version of ARev and I think RevG as well would only recongnize ram above 640 when an Expanded memory driver was loaded. Under Windows this would be EMM386 with the RAM switch. You need to create a CONFIG.SYS file. You would then need to launch Rev with the /m switch.

This might be pretty basic for you, and if it is I apologize, but I am thinking this out as I compose.

I had to do some extensive DOS box configuration for another app I ran that wouldn't conform to the Windows memory configuration. It was very nasty. If I still had a copy of the config.sys file I came up with I would forward it. The site was using Windows with a Novell client and Norton AV. I was able to get 620 kb of low memory very consistently. I was able to do a loadhi for some of the DOS pieces which helped out quite a bit. On the load high you need to plug the DOS programs into memory regions.

My thinking would be the file size has fixed the GFE creation problem, now you are looking at a DOS configuration issue. I found Microsoft's MSDN Knowledge base extremely helpful in this.

Good Luck.

View this thread on the forum...