Hello,

We have many tables here and are having an issue where some AREV OPENs fail and sets @FILE.ERROR to 100 or FS1100 "Resource not initialized error" is returned, after which AREV freezes.

We are pretty sure its to do with running out of DOS file handles and we already have files set to the maximum of 255.

Is there anyway to determine how many handles remain and a way to flush unused handles without logging out of AREV?

Thanks in advance

We have seen FS1100 at a small number of our sites. The error message always lists some system level table, like SYSOBJ, that cannot be initialized. You know the table was initialized as some point because you would not be able to log in without that table.

For us, this error occurs with programs running on Windows Server 2003. We have a program that spins in a loop that accesses both Linear Has file and OS files. We have made sure that every OS open statement has a close, and we have even gone to opening and closing an OS file for each individual I/O operation. None of this helped.

However, I have found at least two scenarios that trigger FS1100:

1. A memory leak on the server is consuming non-paged memory, resulting in insufficient non-paged memory for the requested operation. Specifically, we have seen this error caused by an HP printer driver on a server, but it could be caused by any process with a memory leak. You can view non-paged memory from Task Manager, View, Select Columns.

2. Incorrect installation of a SCSI tape drive, where the tape drive is installed on the RAID controller instead of its own SCSI controller. This is a hardware level error. Some I/O requests get routed to the tape drive instead of the hard drive due to conflicts and incompatibilities between hardware devices.

However, we still have a couple of sites with occasional FS1100 errors that are not explained by either of these things.

I have also just started encountering problems in BTREE.EXTRACT/IDX_SETS at one site (FS445) that appears to be similar in nature. The temp work files from btree.extract do not get cleaned up automatically. Don't know for sure, but it also looks like a problem with DOS file handles.

Many thanks for your reply, we shall start down this track.

Sounds to me like the operating system is caching writes (thereby keeping file handles active).

Another option would be to try a FLUSH statement after your OSCLOSEs.

I'd also experiment with PERFORM "SUSPEND EXIT NUL" and see if this helps. Reloading CMD.EXE or COMMAND.COM as a shell implicitly closes the file handles from the parent shell session (AREV under the DOS shell). You can VIDEO.RW ahead and behind the shell call to save and then reinstate the screen appearance for cosmetic considerations.

May not be relevant, but recall that DOS reserves the first five or so file handles for "devices" like AUX, CON, PRN, NUL etc.

We tried all of these suggestions but they did not solve our problem. We ended up working with Revelation on this. FS1100 errors are thrown in 4 places, two were relevant to our situation:

1. When the Service is unable to get a spinlock on a system resource.

2. When the handle table for the Service is full.

We tested and found two specific things, and a solution for each:

1. One customer had installed McAfee anti-virus software and had it set up for scanning "on access". FS1100 errors stopped when the REV files were excluded from scanning. It would appear that McAfee is/was placing spin locks on a system resource (file?) that was competing with the Windows Service for access to a table.

2. Regarding the handle table, we learned that arev cannot open a large number of files if the open files have locks on them. The presence of a lock prevents the database from closing files in the background to allow for the appearance of an unlimited number of open files. There appears to be a limit of around 40 files/tables that can be open at any one time if there are locks on those tables.

However, we found that this limit can be greatly expanded by setting MaximumOpenLHFiles in revparam. We now set it to 100 for our production systems, but in testing we could get as high as 180 files to work. The MaximumOpenLHFiles is documented in the readme files for the 1.5 and 2.1 Windows Service. It is not documented in the Universal Driver, but it does work with 4.5 and 4.6 (and perhaps other) versions of the UD.

So, my recommendations would be:

1. If your application sets simultaneous locks on 30 or more tables and you are seeing FS1100 errors, use a version of the Windows/UD Service and set MaximumOpenLHFiles to a large number.

2. If you do not do a lot of locking in multiple tables, look for some external application that is competing for a system resource.

Did you try upping the FILES= to 60 in the CONFIG.NT file?

Yes, and way more. We have chased every suggestion, guess, innuendo, and piece of convention wisdom on this web site. Nothing worked.

But, eventually with the help of Revelation staff (Jared and Bob Carten) we did find out what the underlying problem was, then we discovered the solution on our own. I am just passing this along in case someone else runs into the same problem.

Basically, Bob helped us find all of the things in the environment that throw an FS1100 error, and Jared advised us of some previously unknown (to me) limits in the environment. We tested, found the boundaries, and the only thing we found that addressed the problem was MaximumOpenLHFiles.

Well 60 is the max. Anything larger causes an error and you either end up without UMB or less than the default 40 handles.

I think Dan's assessment of the situation is on the mark. It sounds very similar to the situation he throughly investigated. Thanks for sharing your findings.

To add to the conversation, the MaximumOpenLHFiles option in the REVPARAM file only applies to the AREV client driver. From what I can tell it doesn't affect OpenInsight. The LinearHash service would be unaffected because it doesn't process REVPARAM files - only the clients access REVPARAM files.

The AREV 4.6 UD client driver is largely based on the UD 3 client driver where the MaximumOpenLHFiles option is found.

View this thread on the forum...