AREV.INI read and write errors (B328 + B326) appeared on a system that has been stable for over 7 years.

No software changes of any kind had occurred for the past six months.

The landscape is Arev 3.12, All Networks driver, Win 98 workstations, NT 4.0 Server.

While being able to crash through the problem, the application was unusable due to lack of an appropriate environment (rollout file, sortwork area, ESC.TO.ATTR keystrokes, video attributes, …etc).

The problem existed whether Arev was run directly on the server or via the workstation.

This was true for both MEDI(Application Name) and SYSPROG.

I found that EDIT DOS FILENAME would always fail (FS133 Undefined Error during…), regardless of drive (local or network) and/or path.

However, OSREAD was usually (not always) successful for the same file (go figure ?).

RTP57 seemed to be OK, as I was successful in saving new and altered records to Linear Hash files.

I successfully ran LHVERIFY on all attached volumes.

That revealed a GFE in one of the application bang(!) files.

However, I could not rebuild or recreate that index.

While BTREE build started off OK and run as expected for a while,

it repeatedly failed with a very inelegant sprawl across the screen

"This device does not exist on the network. Reading drive E:"

(E: is where the target LH data files live). I had to kill Arev to escape this error.

I searched this forum and found what looked like a lot of relevant threads.

I worked through all of these one by one without finding a solution.

I also took advice from Steve Smith (thanks again).

After two days of trial and error, the AREVC.INI error went away, even after everything was set back to its initial state.

However, I continued to get the same failure when rebuilding indexes.

I also had other kinds of failures with ordered selects (perhaps when Arev used used sortwork).

I was aware that the system was giving very bad response.

I noticed that other windows applications (MYOB, MIMS, MS Office) were responding poorly, although never failing.

I started to investigate the general system response, and found that about one in thirty Pings failed (Workstation to Server).

The hardware guy came in and swapped network cards, fiddled with cables and changed hub ports.

Even though he is adamant that he could not isolate a fault, the problem has gone away.

I've rebuilt the indexes, and the application is flying again (hopefully for another seven years).

The only conclusion that I can draw from the foregoing is that DOS RTP?? is less persistent than LH RTP57 in the event of I/O error. I cannot understand the deal with OSREAD. Any thoughts ?

Chris,

You're more than welcome for the assistance…

I guess the OSREAD behaviour is consistent with the ping behaviour, as each call to OSREAD tries to *read* the file once only. RTP57A, in this case being the All networks driver, must retry a few times upon reads. The open causes no file I/O so the error must be triggered by the read. In the case of a bad network card the behaviour can indeed be unpredictable.

I wonder if the Revelation people (Pat??) can confirm the read re-attempt behaviour of RTP57A (All networks driver) in this case? Also, I wonder what error conditions are trapped and which extended errors from the OS are ignored? Once the CPU carry flag is set from a bad int 21h file I/O operation, which DOS errors map to which AREV reported errors?

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...