Pat and/or RTI,

I got the Universal Driver (our first) for a new AREV to OI conversion.

We have a routine that will copy data tables in AREV to their corresponding data tables in OI. When used in the past, it has worked flawless and is very fast. We depend on it.

We discovered (after some lenghty hair pulling debugging on a Friday night) that our conversion routine was failing and it was failing because of the new Universal Driver.

The failure occurred when the ALIAS_TABLE command executed. We would get an FS109 error message. See code below:

Set_Status( 0 ) Alias_Table( ARevVol, "SYSPROG", "REVMEDIA", "REVMEDIA" ) If Get_Status( AttachError ) Then * error!!!! End Else * do some stuff End

As proof, we uninstalled the Univeral Driver. We then installed the Windows 2.1 driver and the conversion routine worked. We were no longer getting the FS109 error message.

Can this be fixed? Will I get a replacement for my UniversaL Driver?

Thanks,

Ray Chan

P.S. I need a brew

Sorry for the improper formatting. I thought it looked okay when I was typing it, but now that I see it you would think that was I partaking before I should . Hmmm….

Ray

Ray,

Just because your scenario works without the Universal Driver, it does not mean that your setup with the Universal Driver is correct. Chances are it is something about your installation that is in error, although there certainly is a very remote possibility that the problem is on our end!

I have seen this very situation when the Universal Driver client is unable to open with write access (or is unable to create) the REVLOCKS file in the volume you are accessing. This REVLOCKS file is used for coordinating between seperate processes access to all files in that volume.

If that doesn't explain it, the Universal Driver client has the ability to trace to a log file all requests made of it. To enable, create a file called LH3.LOG in your working directory and start OI or AREV. Recreate the error and then post the results here. Ideally you just need to post the request where it is trying to open the volume that is failing.

Don't forget to delete this log file when you are through, because it really, really slows things down.

Pat

Pat,

Just because your scenario works without the Universal Driver, it does not mean that your setup with the Universal Driver is correct. Chances are it is something about your installation that is in error, although there certainly is a very remote possibility that the problem is on our end!

What can be wrong with our installation? The setup is relatively simple and looks very similar to 2.1. According to RTI, I need to put the REVPARAM wherever we have OINSIGHT.EXE. Therefore, I put one in our DEVELOP and RUNTIME folder as we have a split environment.

As to what else we did to test this, we copied our App with the Universal Driver to a PC with no NT Services, removed the revparams, ran as is, still "bomb" on ALIAS_TABLE. Then we changed the driver from 3.0 to 2.1 (via NetDrv), still no go.

I then deleted all references to the Universal. Deleted the DEVELOP and RUNTIME folder. Restored from a backup of OI prior to installing the Universal, Applied 2.1, and voila our conversion routine worked. Alias_Table behave as expected.

I have seen this very situation when the Universal Driver client is unable to open with write access (or is unable to create) the REVLOCKS file in the volume you are accessing. This REVLOCKS file is used for coordinating between seperate processes access to all files in that volume.

Could there be something in the Universal Driver that prohibts it from seeing files in an AREV 2.0x environment?

If that doesn't explain it, the Universal Driver client has the ability to trace to a log file all requests made of it. To enable, create a file called LH3.LOG in your working directory and start OI or AREV.

For clarification, we are using OI 413 and the AREV app that we are converting is based on AREV OS/2 v2.01.

Recreate the error and then post the results here. Ideally you just need to post the request where it is trying to open the volume that is failing.

I appreciate your help, but it may be a while before I can spend much time on this again. As is, I have already spend more time than I wanted and should have on this problem ;-( I'm somewhat hesitatant at this point to put 3.0 on knowing that I will have to remove it. Not just for the problem that we are discussing, but also because of the CAVEAT of not being able to share files between 2.1 and 3.0 systems. This may not be a major problem for some, but it is a nuisance for us.

I'm stumped and tired .

Thanks again,

Ray

View this thread on the Works forum...