- First of, there is a bunch of info here

So just read the symptoms section for an overview of the problem.

- This seems like a bug in the LH.NLM when resizing large .OV files

( ] 1GB) for very active files, but I wonder if we have the 

correct version? (we have diff client 1.5a version from 

tradeup disks).

- I have seen others on this forum with both the fatal error

writing and setfilesize msgs, but there was never any solutions.

- We have tried increasing the retries on the lhipxtsr (/r:xxx),

but that did not help.

clients : Arev 2.12

server : Novell 6.0,

NLM : 5.5, client 1.5a

---

Symptoms:

---

Clients are stuck reporting the following error when writing a record.

Fatal Error Writing in file

 FS104

General write error in the operating system

file "GDATASHR\REV72159.OV".

LH.NLM is reporting the following error on the file server console.

"SetFileSize failed with newsize=1019600896"

we have found that this is the size of a large .OV files

on the server

---

Other information

---

Server is Novell 6.0, with the NLM version 5.5

Clients are all running Arev 2.12, and are DOS, WIN95B, WIN98

- Only occurs on Novell 6.0 with NLM v 5.5

this problem only started since we recently upgraded from 

Novell 4.1 w/nlm version=1.12

- Only occurs on files where the .OV size is ] than

1GB  (1073741824)

for some other large .OV files the SetFileSize report numbers like :

 SetFileSize failed with newsize=1106684928 

 SetFileSize failed with newsize=-1150244864   

 SetFileSize failed with newsize=-494203904 

these negative numbers correlate exactly to some of our 

.OV files if you add or subtract 1gb, 2gb, 3gb, etc.

- Seems to only occur on very active files

where many stations are adding records often..  the .OV file 

is growing every few minute from around 5 to 20 clients.

- LH.NLM version - which do we really have ?

we have 3 different trade-up versions disks with different dates

we are currently using the version with date 3/19/1999

(see LH.NLM version info below)

- We do have a handful of stations running in true client-server mode

accessing all file via the REVELATION account.

---

LH.NLM version info for all tradeup disks we have

---

diskset1

RTP57A.IPX 44,229 Bytes 1:50 am Wed Feb 18 1998

LHIPXTSR.EXE 3,964 Bytes 1:50 am Wed Feb 18 1998

LH.NLM 48,773 Bytes 1:50 am Wed Feb 18 1998

LHIPXSER.NLM 24,381 Bytes 1:50 am Wed Feb 18 1998

diskset2

RTP57A.IPX 44,233 Bytes 2:47 pm Fri Feb 19 1999

LHIPXTSR.EXE 3,964 Bytes 2:47 pm Fri Feb 19 1999

LH.NLM 52,226 Bytes 3:56 pm Fri Mar 19 1999

LHIPXSER.NLM 26,411 Bytes 3:56 pm Fri Mar 19 1999

diskset3

RTP57A.IPX 44,233 Bytes 3:50 pm Fri Mar 19 1999

LHIPXTSR.EXE 3,964 Bytes 2:55 pm Fri Mar 19 1999

LH.NLM 52,226 Bytes 11:22 am Wed Jun 6 2001

LHIPXSER.NLM 26,411 Bytes 11:22 am Wed Jun 6 2001

Jeff

It's a known bug fixed in later releases. We brought it to Pat's attention about 2 years back and it affects row deletions on OV files of over 1GB. It is "harmless" - non destructive, but annoying.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I hope that you are correct that this problem (SetFileSize msg and Fatal Error Writing FS 104) is harmless. But I have some concerns

1. I noticed you said this was a problem when "deleting" rows. For us, this happens when adding rows (that is all we ever do to most file). Is this problem for both adding and deleting rows using the LH.NLM 5.5 on files with .OV greather than 1 GB ?

2. Was this problem fixed by Pat and if so can I get this patch/upgrade to the NLM 5.5 without moving to the universal driver? It seems strange that others on this forum are not seeing the same problem. There was one other post, but there must be others using Novell 5.5 nlm and using files ] 1gb.

3. The scenario does however cause is some problem for us. When clients get this error, they are essentially stuck and continue to keep any locks open. Also, the rbasic WRITE command does return an error ( from the STATUS() function). This error status will cause logic and error control to behave incorrectly. I know that I can either replace or hook the FS104 file write SYS.MESSAGES / SYSMESSAGES, but I would rather see a fix for the problem.

Thanks for your response.

Jeff

Apologies - we were describing a "logical" delete. The row is written and the driver determines that the OV can be made smaller. This fails. As for "fixes" you'll need a RevSoft response. Easiest way of getting this is to call them :)

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the Works forum...