THANKS! We have two kinds of this, those we create/delete programagically, and those that our users create. Our programs don't use apostrophes, quotes or spaces but users do anything/everything/nothing, I'll let em know!

Our problem starts with this error message

Fatal Error Deleting NEXTPORTGPS*2 in table LISTS

—-FS104————————————–

General write error in the operating system file

"\\FS9\V1\VP\REV41001.OV".

---

ESC to terminate, Break to debugger?

This halts the batch job processing until the user presses "B" and "G" and resumes process. It APPEARS that everything is going along fine. The messages are killing us since we run pretty close to 24/7 and batch jobs will sit for a few minutes to overnight before someone checks it and "BeeGee's" it.

We can't easily clear the LISTS table due to 24/7 and so it contains good lists we need (along with those mysterious SKnnnnn:hex LISTS keys which I wonder about). When the LISTS table is smaller, we don't get the error messages.

Our servers are Novell 5 SP5, workstations a mix of Win98, NT and W2K, Arev 3.12 and NLM 1.5. All other operations are good, stable and pretty fast given our 5+million record tables sizes.

Our LISTS table LK is 735MB and the OV is 1610MB. We have a sizelock of 2 on the LISTS Table, which I have been told allows the table to resize upwards, but prevents the 'resuffling' of keys into new frames as the table grows.

Do you think we can safely delete the SKnnnnn:hex LISTS keys?

Any ideas about our error messages?

Ralph

To answer that directly and indirectly. Yes we know exactly what the error is and what causes it. Regretfully the explanation forms part of a report recently prepared and paid for by a client in the US. As the study took two weeks it would be inappropriate to answer here without their permission. Suffice to say the error CAN be ignored in this instance so you need to devise a way not to display the message. This problem SHOULD be fixed by an upgrade to the Universal Driver.

The Sprezzatura Group

World Leaders in all things RevSoft

Ralph,

Two things…

1) A sizelock of 2 does not allow the file to shrink or grow!!! A sizelock of 1 allows for growing and does not allow for shrinking.

2) Your LISTS file is way abused. Too much too often. I would get with your developer or programmer to resolve this. You might consider to delete the LISTS record once it is done being used. Although some do design their software to reuse saved lists. Your LISTS file reminds me of someone with a very messy bedroom. You really need to get a handle on it and organize it and clean it up. You might check your SYSTEMP file also.

Richard

Remember that the mysterious "SKnnnnn:hex" LISTS keys are being inserted into our LISTS table by something. I am an Arev programmer, and I know to 99.99% that we have no process that puts them into the LISTS table. We do routinely delete our active lists and hence the concern about 'delete list' error messages stopping processing. When we select and savelist from tables with 5 million++ rows, the saved list can be quite large.

There are 50,000 of these of these mysterious "SK" rows in our LISTS table, and more added all the time. They account for 60% or more of our disk space.

Because there is rarely a time when no one is logged in and using our Arev system. 24/7 and all. So we are hesitant to just delete them, which are in use, which are not??? We don't even know what they are (except that they are lists of keys to our tables).

Do you have any idea where these mysterious "SK" lists come from, or if they are expendable?

Thanks for the they can be ignored info and let Andrew know we'll come a-beggin!

Ralph,

You could always put an MFS on the LISTS table to at least track the List Key, @USERNAME, and date/time when they were written. This might give you a little more information.

msorrel@greyhound.com

Greyhound Lines, Inc.

To deal with the problem (as opposed to understanding it) can you write a simple program to traverse the LISTS file and move every record that is older than N days to an archive file? Delete records from the archive file after X days have passed.

THANKS! I appreciate all your help.

Since we are working on upgrading to the Universal Driver, I think I like the ignore it reply from Sprezz! Maybe I'll put a wrapper around FSMSG and suppress it when FS104 on delete-lists…nothing like a good work-around to get your blood flowing….

You can ignore FS104 in the context of deletes on files with large overflows. A generic ignore is a bit more risky.

The Sprezzatura Group

World Leaders in all things RevSoft

Ok. Thanks.

Would an FS104 error on WRITES to a file with large overflows, also be ignorable?

Too many variables to say sorry. But likelihood is probably. Go to the Universal Driver and if you still have problems then don't ignore it!

The Sprezzatura Group

World Leaders in all things RevSoft

The problem is that not all LISTS entries have an obvious way to determine when they were created. One way round this is to use a Modified Filing System on LISTS to record the date/time/user info every time a root entry is written, storing this in a parallel table with the same key as the LISTS entry itself. It is then a relatively simple housekeeping job to select all (say) LISTS_INFO rows created more than "n" days ago, and then use this list to delete the actual LISTS themselves.

Cameron

PS If anyone feels masochistic enough to actually do this (it IS quick, honest! remember to have the MFS deal with deletions as well. And it's also an idea to have an override to allow you to save lists you DO want to keep for longer (e.g. by starting the list name with KEEP_ or some such…)

I did this a few years ago and may have even posted the code to the forum here.

And I undoubtedly stole it (the idea, if not the code.

View this thread on the forum...