I have a customer whose production is down and need immediate help.

They are building a table which may involve sort and/or index checks.

They are receiving the message

"Insufficient disk space reading device NETWORK"

NETWORK is the name of their hardware device. The disk space

shows there are gigs left on both the local and NETWORK device.

So either the message is faulty or AREV is trying to grab a

LOT of memory.

They are running Version 2.12 on a Win 3.1 machine with a

server running Novell Netware. I have recently been doing

some fixes caused by the addition of NT client machines

without installing the NLM. (Basically restoring some

corrupted files.) One of the files was the LIST file which

is a system file, but that has been restored.

Please help!! They have been down for 2 days already with

the previous problems and are not looking forward to more.

Mark

Mark,

1) If the partition has ]2gb free space you should reduce the partition size. Dos/Win95/NT will all report differing sizes on large partitions. You can trap this call by stubbing dspace, but this would prevent valid low disk space errors from being reported which can cause other significant problems so this would be a drastic solution.

2) make sure all the files you are accessing have valid owners (Admin/Supervisor) and that the user in question has rights to the directory.

3) If you are going to have Win95/NT machines accessing AREV on the lan you should install the NLM. If you do not have it you should contact customer service at (800) 262-4747

John Revelation

AREV experiences a DOS bug (due to DOS partition limits ] 2.1 gB)

in its drivespace ($DSPACE) routine which returns a negative

value for large partitions, network or local.

The following is a substitute routine I issued on

Compuserve for the same problem affecting the AREV

2.12 FILECOPY TCL command.

You don't have to re-partition your Netware server.

(John from RTI - please enter this in your support database)

FILECOPY CALLS $DISKSIZE

$DISKSIZE CALLS $DSPACE

DSPACE works out the disk's formatted information.

This turns "negative" / highest bit set on signed

32-bit number for large drive sizes (] 2 gB=2^32 / 2).

Here's what you might consider doing:

Replace $DISKSIZE in your verbs file.

Save the original with the TCL statement:

COPY VERBS $DISKSIZE TO:(VERBS $DISKSIZE.ORIGINAL (O)

Now we edit our own DISKSIZE routine.

At TCL:

EDIT VERBS DISKSIZE

Then enter the following:

SUBROUTINE DISKSIZE(DRIVELETTER)

DECLARE SUBROUTINE DSPACE

FREEBYTES=0

A=0

B=0

TOTAL.ALLOCATION.UNITS.ON.DISK=0

DSPACE(DRIVELETTER,FREEBYTES,0,A,B,TOTAL.ALLOCATION.UNITS.ON.DISK)

DRIVE.SIZE.IN.BYTES=TOTAL.ALLOCATION.UNITS.ON.DISK * A * B

REPLY= DRIVE.SIZE.IN.BYTES

REPLY=ABS(FREEBYTES)

RETURN REPLY

* Next hit shift-F9 to compile.

* Either A, B or the TOTAL.ALLOCATION.UNITS.ON.DISK will probably be

* negative or even zero, and this is causing your problem.

* The ABS() around FREEBYTES will fix any negative.

* If this is not a network drive then A*B should equal what CHKDSK *

* reports as the bytes per allocation unit.

* TOTAL.ALLOCATION.UNITS.ON.DISK should match what CHKDSK reports

* as total allocation units on disk.

Hope this helps,

Steve

This may be a bit late but -

If it's not AREV getting the Partition Size wrong then it's possible that Novell Netware has either a Volume or Directory Space restriction for the Netware User logged in.

Try typing CHKVOL or CHKDIR (Netware 3.1x) at a DOS Prompt

or for Netware 4.x I think you can use the NDIR command. I think the system will tell you the correct command if you try CHKVOL anyway.

If restrictions are in place then ask to have them lifted or set to a value you can guarantee will more than cover the maximum size of the database.

Mike Jeremy

LLES Sydney

Steve;

I have encountered the same problem with FILECOPY. Please note the following that I have observed in Arev 2.12 on a Novell 3.12 fileserver with a 7+ Gb volume.

The Dos Function Call returns the correct freespace, up to a max of 2Gb's free, not a problem from my point of view.

The FILECOPY will work if the Windows 95 Version is 95a or 95b

The FILECOPY will NOT work if the Windows 95 Version is SR2

My guess is that Microswift (typo) has changed something in the filesystem or network driver that has altered the way the DSPACE gets its information.

Your patch to the DISKSIZE routine does not fix the problem in this case, we are currently creating an assembly routine to replace the DSPACE original code. It will use a DOS function call that works properly. I am not sure were the best place is to post it if we get it working properly. Compuserve? does any one still use the Revelation forum?

Bruce

View this thread on the forum...