I apologize if this has been discussed before and/or there are articles about this question, but I can't find any reference in searches.

On a Win98 client, AREV 3.12, Netware 5, IPX/Netware 1.5a NLM environment, what might be the cause of hangs on READNEXT lines? Either stepping through a program or breaking when it hangs, there's a noticeable pause when 'READNEXT ID…' lines are executed. The program will fly through reading records from a file using those IDs but it hangs for a split second on the READNEXT call every time.

Any hints or suggestions at what to look at that might be causing this?

many thanks,

dEVoN

I've not noticed this at any of my clients' AREV sites. A couple of questions, though:

1. Are using a RESOLVED select list to generate the READNEXT data. If so, have you checked your SYSLISTS table's size, etc. This can get very large and potentially fragmented with overflow frames.

2. Have you tried a benchmark on the READNEXT using an R/BASIC SELECT vs an R/LIST SELECT? This might point you in the right direction.

Don M.

I'm sorry, I should have been more clear about where the READNEXT ids were coming from. These are from R/Basic 'SELECT F.filevar', then 'READNEXT ID…'. It takes longer to execute the READNEXT id line than it does to read and write the record being read/modified/written.

dEVoN

Since you say that the "READNEXT" statement is slow, and you say that the "READS" and "WRITES" are fast… is it possible that there is a custom "MFS" being used?

The type of select you are using is the fastest. All it does is go thru each modulo to get a list of ids. Unless the file (or table) is corrupted. Have you verified that file (table)? Any GFE's?

There is no custom MFS code on the files this happens to. The files verify without any errors and we do not encounter any GFEs reading or writing to them. There are also very few empty groups in the file. One of the reasons we are looping through all IDs is because these files have so much data in them. We are archiving records off to other files that are not needed for realtime processing anymore.

It is quite frustrating to not be able to find an explanation for the pause on the READNEXT call.

dEVoN

Is the file in horrendous overflow? The SELECT you are using should just pass through the frames extracting keys on the fly. The READNEXT in this case should be running from MEMORY. Is EMS enabled? It's possible if the file is extremely large then the SYSTEMP table can be being used to hold the keys. What's the status of THAT table?

Very puzzling indeed …

Don M.

Since you are doing an RBASIC Select, the READNEXT statement is doing the resolving as well as the readnexting. I think you will find that if you do a perform 'select…' instead, your readnexts will go exceedingly quickly. Of course then the delay will shift to the select.

You say you are doing a SELECT F.Filevar. Are there any additional selection criteria? If not, you should be going in the natural order of the file. Any delay would then be a result of possible fragmentation of the file and/or caching considerations. Consider that with a readnext, you are requesting a portion of the file that has not recently been accessed (using your method). The read would then be reading the portion of the file just readnexted so would already be in cache on the server side, assuming you are using a server side networking product.

I've not got the answer, but may suggest an avenue of investigation. The problem you are describing does not occur on single user machines - and mostly not on networked machines. The problem clearly lies in the network domain.

Even with horrible overflow, the READNEXT doesn't present the problem that reading the record does.

Regardless, the raw SELECT (on a file handle) is still the fastest route, both because of ID extraction and because you only read the record once. A SELECT on CONDITION generally requires that a record be read twice. Once to determine if it meets the condition and once when you've readnexted the ID and need to deal with the record. Really small files are an exception and server caches may disguise some of the double hit.

Strange.

Just question:

Are the READNEXTs slow in worst case/in amortized (in average) sense.

(In comparison to READs/WRITEs).

(Worst case is normal, amortized is strange)

… If you have groups with high number of records in it (long overframe lists), the BFS READNEXT returns a lot of keys at once.

There are processed one ofter one by R/Basic READNEXT, so the first R/Basic READNEXT per group is slow, and remaining are very fast.

Check the status of write-behind caching on Windows 98 - it should be disabled (Right-click my computer - properties and seek it there under Filing System / Performance Options)

The problem suggests a file badly in overflow, (sizelock set??) and larger than available memory provides. We'd check this. If the file is indexed it also suggests an index rebuild may be in order. We'd check this.

There was one Novell version which required a patch to VIPX.EXE - check that you have the correct version of the client. I was also under the impression that the NLM for Novell 5 should be version 5, but again, you'd have to check.

I'd also try dropping back to the Advanced Netware drivers (backup REVBOOT volume first) and see if there is any difference in performance.

Some other diagnostics to try:

What happens if you create a new "dummy" file on the network and recordcopy all the records across into it and run your select on the dummy file? Any faster?

What happens if you create a new "dummy" file on a local drive and recordcopy all the records across into it and run your select on the dummy file? Any faster?

Is the Netware server reporting a large number of CRC errors? Is this count of CRC errors increasing when you run your process??

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

What do the keys look like to this file? Are they very long? All numeric etc.

View this thread on the forum...