I have a product called the PARSEC POS system specifically for Serial Numbered Cell Phones. The system has been running for about 4 years in a number of stores. Initially it was under DOS but now under DOS under Win98. There are several occurances where the various files are not updated. The occurance is about 1 in 1000 sales. I have gone through the update logic and it seems that if the invoice prints then the files MUST also be updated.

I wonder if W98 may be the problem in some sort of CACHING problem. Does anyone know of any CACHING settings in W98 that might cause loss of file updates in a no network stand-alone system?

Any ideas would be greatfully received. My clients are getting a bit annoyed with the problem.

Merry Xmas

Ted Archibald, Parsec Systems, Tsawwassen near Vancouver BC Canada

There may be a caching condition on the workstation under W98.

I would add flush statements after all your commit logic. Also, double post (eg. to a log file and also to the data file.)

Never discount the possibility that the PC is being switched off.

Steve

Ted–

There is a setting in Windows '98 for background cacheing.  I am at home and am working on a Windows '95 machine so I can not verify where it is exactly.  You should turn this background cacheing 'Off'.  

Good Luck, Merry Christmas,

Rob

Revelation

It is inthe same place on win98 as win95 namely

START] SETTINGS]CONTROL PANEL ] system]PERFORMANCE]FILE SYSTEM]TROUBLESHOOTING and check disable write behind caching for all drives

Key words:

WRITE BEHIND, CACHE, WRITE FAILURE, AREV, W98, W95

Thank you ED MANTZ, Thank you,

This is exactly what I was looking for.

However, The Resource Kit (W95)write-up suggests that this "should be checked only in rare cases where you are performing risky operations and must ensure prevention of data loss." Why would an ordinary program require this?

There must be a time factor where dirty buffers are written out as soon as possible. I would have assumed that in a simple POS system that the files would be updated immediately.

Several months ago I ran a W98 performance monitor and found that when AREV 3.12 was active the utilization was very high, taking as much cpu as possible. I think that this is because of the logic of cycling on an INPUT statement waiting for another character to be type in (the old world of single tasking). If this task is busy soaking up all of the resources of W98 maybe W98 just waits and waits until I don't know when to write the buffers. Maybe it waits until the application is stopped and W98 has some spare cycles to do some house cleaning like writing dirty buffers.

My hypothesis now is that AREV in Dos in W98 (W95) actually prevents the timely writing of dirty buffers and there is a time frame within which the data is not yet on the hard-drive. (30 seconds, 20 minutes, I have no idea)

Question: are there W98 parameters to set (other than turning write behind off) to speed up the writing of dirty buffers or is there something in AREV to "force" the writing.

I suspect that flushing of buffers in AREV will do nothing to tell W98 to flush it's buffers. I think that the problem is common to All DOS applications in W98 and it only occasionally is evident. I am guessing that in my POS systems that the hit rate is about 1 in 1000 or so invoices.

Any ideas on this? ED? Rob? Steve? Anyone?

Cheers to all

The proble arises because if a record spans the OV and LK physical file portions of the AREV table, and one half (LK or OV) is cached and the other half isn't, then there may be a condition where the record is half on the disk and half in RAM awaiting the physical commit. The next read causes the error.

If disabling caching on the Win 9x box proves unsatisfactory, there are several solutions by way of the Revelation network products - a NLM for Novell and the NT service for NT servers. Both these products manage the commits on the server itself, so both files (LK and OV) are written at the same time, in sync with one another. This prevents GFEs , and problems similar to that you describe.

Hope this helps,

Steve

However, The Resource Kit (W95)write-up suggests that this "should be checked only in rare cases where you are performing risky operations and must ensure prevention of data loss."

Isn't this something that you would want, prevention of data loss?

When ARev was initialy tested for compatibility under Win9x, the only way the system would work at all was to disable write behind caching. On some networks, disabling new file locking and semantics had to be done as well. Granted, neither setting is required with the NLM and NT Service, but the NPP requires at least disabling the write behind caching.

The server is doing plenty of caching, and the network driver is doing it's own caching, most likely. You really don't want Windows maintaining a third, independant cache.

The problem has nothing to do with the keyboard polling and resources, though setting the yield flag in the environment should minimise this some. The problem, as Steve pointed out, is your files are really two DOS files, the LK and the OV. You don't want you're workstation to cache one of the files locally and send the other back to the server. This is great way to get GFEs.

Personally, when dealing with caching, when I write some data back, I want it to go to the server straight away. The server can deal with all the caching and whatever it needs to do, but I want my changes to be available to everyone, not just to me.

akaplan@sprezzatura.com

Sprezzatura Group

View this thread on the forum...