GFEs, exploding LK with 4K Frame size and NLM (Networking Products)
At 12 APR 2002 09:14:54PM Matthew Crozier wrote:
Very curiously last week, two different client sites had the same problem reading some of their records. A GFE message "FS493: Group Format Error! Group #xxx The group contains an invalid frame type value." comes up and the record entry is blank. However, Verify_LH reports no GFEs in the file! But then, performing a Fix_LH on the group rectifies the problem with no loss of data!, ie. the records are visible again.
Both sites are using the NLM on Netware (one has NW 4.11 + NLM 1.5, the other NW 5.0 SP5 + NLM 5) with ServerOnly=True in REVPARAM. Novell Client32 versions are generally 2.2, 3.21, or 3.32 (which was released a month ago, it seems).
They are also getting a GFE in group 0, 'Size of .LK divided by Frame size is not equal to modulo.'. The .LK file had 59342 x 4kb frames of straight ASCII 0's (no group header) appended to the file! Chopping this stuff (232 Mg of it) right off with a hex editor fixed the problem.
Both sites are using a frame size of 4Kb. Is there anything to look out for what using 4Kb frames with the NLM?
Thanks, M@
At 13 APR 2002 05:32PM Don Miller - C3 Inc. wrote:
Did the file start out with a 1K frame size and had the size increased to 4K? If this is true and the file is relatively static, then dynamic resizing can take a long time. I don't recall whether this occurs immediately upon remaking the file nor not. The problem sounds like the free-frame list was expended to an arbitrary large size at the end of the file. I've seen this in files without the NLM controlling it, but never with it. Maybe somebody else can shed some light.
Don
At 14 APR 2002 09:32PM Matthew Crozier wrote:
Don,
The file did originally have 1K frames. Even though the modulo was nowhere near 32K, we did a remake_table with a 4K frame size to delay a problem with phantom GFEs that occurs when the modulo exceeds 32K. (Resizing to 4K frames reduces the modulo which will increase at a slower rate as records are added). (I know this happened with NT service/NPP combo, not sure whether NLM/IPX had the same problem though).
Anyway, the result of the remake_table seemed to be an optimised file with primary load 79% and no free frames - and no Megs of crap on the end! That seemed to happen afterwards.
I've resized the file back to 1K frames to see if the problem goes away and hence whether I'm barking up the right tree.
Thanks for you help,
M@
At 19 JUN 2002 12:13AM Matthew Crozier wrote:
I've resized the file back to 1K frames to see if the problem goes away and hence whether I'm barking up the right tree.
I'm barking up the wrong tree! The error has just occurred again and with the 1K frame size. However, problems with the NLM have also occurred so it may be a result of that not running correctly.
M@