Alpha4v8 - Maximum number of windows search handle

[alexwi]

Hi,

I'm evaluating vdos and am hitting this error when running a stress test I've designed.

I wrote a script that opens table1.dbf (dbf file) runs a search for a random record and copies that record to a temporary table (temp.dbf), then the script switches to table2 and appends the contents of temp.dbf.

The idea is to run this in a loop, on several workstations, and "pound" table2 with insertions. However, after 254 of these iterations, I get the same message as someone was getting with clipper.

My guess, based on the explanation on that discussion, I'm maxing out those handles due temp.dbf being opened and closed with every iteration.

Is there a way to preemptively clear this buffer? Or if this fails, what kind of delay could I add between each run of 200 iterations (to be safe) that would allow vDos to do some garbage collection in the background?

Thanks!

Alex

[Jos]

Don’t think your problem is directly related to the essence of your test: Search for a record in table1, copy that to a temporary table, and append the contents of that to table2.

In your test will be as many inquiries for the presence/existence of one of those tables. DOS testing for a file has to be translated to the Windows equivalent. But those methods differ a lot, vDos does its best to keep track of what’s going on with DOS testing.

The next version will use another strategy to keep DOS and Windows file search operations in-sync. You’ll have to wait for that, or for now modify your test to actually show the process of searching and copying records.

Jos

[alexwi]

Hi Jos,

Thanks for getting back to me so quickly.

After deployment, I'm pretty sure that users would be switching between tables well over 254 times during their normal work day.

I'm going to write another script to do just that and see if I hit a wall. I'm pretty sure that the culprit is the append, because that's when a table is actually opened, so the file search takes place. When the scripts switches between table1 and table2 there's no file opening involved, as those two remain open throughout the test.

I'll test later today and let you know. (And then it's probably back to the drawing board to figure out other test approaches.)

Again, thanks!

Alex

[alexwi]

You were right. Same result.

Opening the two tables and switching back and forth also crashes vDos after 254 iterations (255 once).

I guess I have to work on the testing strategy itself.

Alex

[Jos]

To elaborate on this error:

If a DOS FindFirst() is performed, it is translated to a Windows FindFirstFile() operation.

DOS FindFirst() fills the current DTA with the found data, or returns an error code. Windows FindFirstFile() fills a data structure that is passed on, and a search handle if a match is found.

DOS FindNext() uses the current DTA contents for a subsequent find, while Windows FindNextFile() requires the (open) search handle of a previous FindFirstFile() operation. So you can have multiple concurrent search operations in Windows by using search handles. If a DOS app needs that also, it sets the current DTA to another address, or swaps the DTA content directly.

If a DOS FindFirst() pattern contains a wildcard (? or *) and a match was found, vDos has to consider a FindNext() can follow. So the Windows search handle can’t be closed yet, instead vDos maintains a table that links Windows search handles to DOS FindFirst()/FindNext() operations. Though that’s not that straightforward since the DOS app can mess with the DTA content. That reference table is limited to 255 entries, if it would overflow, you get the “Maximum number of Windows search handles exceeded” exception. Mind, this is unrelated to opening and closing files.

Your DOS app will use many (at least 255) FindFirst() operations with a wildcard. But also first ‘initialize’ the DTA content, so vDos has no idea if and what Windows search handle it should close (so release resources), or what corresponding entry to eventually remove from the reference table.

The next vDos version has another strategy to maintain that table. It only has 16 entries, if that number is exceeded, the oldest entry is removed and the Windows search handle closed. Anticipating a maximum of 16 concurrent search operations by a DOS app.

Jos

[alexwi]

Thanks Jos!

I was concerned about this, as I would invariably hit the limit after 254 switches when doing it from a script, however, when I tried to do the same manually, vDos didn't crash.

I'll leave it as an exercise for the unemployed to figure out the timing to use when doing it automatically, as I don't see this issue coming up in a live scenario (fingers crossed).

Alex