I am beginning an OI conversion and am trying to set up a shared arev 3.12/OI 7.2 system on a Novell 5.1 SP6 network. (I know, I should have done it years ago…).

our win XP pcs are using the Novell 4.83 client.

arev 3.12 is using the IPX/advanced netware v1.5a driver.

I'm told the compatible OI driver is the Netware NLM multiuser driver v1.5c.

Loading OI with this driver results in the following msg:

Open Engine

File System Install Failed

REPOS_BFS FS

"Open Engine Cannot Continue"

OI appears to run fine with the 'all networks driver' but I need to coordinate locking with AREV 3.12

The last discussion I find regarding this error was back in 1999.

Does anyone have more recent experience/feedback on fixing this problem?

Although it's all working for ARev, you might want to try the basic suggestions that have been posted. These are ensuring the frame types are explicitly defined, you are accessing the drives through mapped letters, and you have a supported Novell client.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I have checked the following:

frame type is set to 802.2

novell client 4.83 sp2

novell server is assigned drive letter g:

whenever I switch OI from the all networks driver to the

Netware NLM multiuser driver v1.5c OI just won't run.

I'm using the 5.0 NLM

would the 5.5 NLM make a difference?

thanks for the response!

any other ideas?

Maggie

One of my client's is running Netware 6.0 with the 5.0 NLM, Arev 3.12 and OI v7.11. OI should work with the v1.5c driver. The attaches in the DB Manager should be mapped to the same drive letter as ARev or strange things happen. It probably wouldn't hurt to have OI mapped to the same drive also.

What are your revparam files settings?

I installed a fresh trial OI version 7.2.1 to try and isolate our problem. I placed a REVPARAM file (SERVERONLY=1) in every directory containing LK files. Using the all networks driver, I accessed the sysprog account and verified that there were no database files attached. When I switch to the "netware nlm driver 1.5c" I get the REPOS_BFS FS error- none of our xp pcs can log in.

we recently began running the IP protocol alongside the IPX on our Novell server. Could this be the culprit?

It's encouraging to find out that this works somewhere!

Maggie Shinn

maggie,

The NLM/IPX technology has always been very finicky. You have to have the frame types matching and IPX has to be the protocol used. It is possible that having IP enabled is "confusing" the communication between OI and the server. I do know that a customer of ours went through a similar upgrade scenario. They were an AREV customer using NLM on Novell 4.x. They then upgraded to 6.0 and upgraded their NLM to 5. Arev continued to work however the speed was about 300% slower when using 2000 or XP workstations. Since they were upgrading to OI it isn't possible to stay on the "fast" 98 computers. (OI would work but just as slooow as AREV).

Finally, the decision was made to try the UD and that resolved the problem. No longer were they using IPX and the speed improved dramatically. Now the only problem was since the UD will not work on 98 they had some legacy systems to upgrade…but at least it provided a way forward.

HTH,

John

Reorder the protocol stack in the Netware Client settings so that IPX is first.

I don't recall which version of Netware has a true TCP/IP implementation, either 5+ or 6. Before this TCP/IP is encapsulated within IPX packets (kludge).

NLM v5.5 specifically addresses speed problems with OI on Win2K stations. ARev speed problems with XP (as well as W2K) can usually be addressed by changing the Netware Client 32 version. v4.83 SP1+ seems to be the versions most successful although there have been one or two reports of v4.9+ working fine speedwise.

I have also heard the reports but unfortunately no matter what version we used the speed was unbelievably slow. I even received a the vipx.dll patch and it didn't make a difference. It was just the combination of IPX, XP and the Novell Client that ground things to a halt! Kind of ironic but communication over IP turned out to be much easier to deal with. Although if memory serves me, I think we had to reference their Novell server by IP rather than a name as Novell did not handle the DNS…

We have been running arev 3.12 with Dell Optiplex XP pcs using novell client 4.83 sp1 and sp2. it is surprisingly fast overall, although some routines need to be run in full screen mode to match the speed of our old win 98s.

I will unload the IP from the Novell server and see if that helps the driver issue.

thanks

maggie

I have been working with Kevin at Rev to solve this driver issue but so far we have had no luck. Kevin has examined my setup and we've covered all the basic possibilities. We're hoping you may have some 'insight' since your client is running a configuration very similar to ours. Any suggestions on what else to look for?

thanks Warren-

Maggie

How is the LHIPXTSR being loaded? Is the /p switch set and is it unloaded after ARev is shut down (with the /u switch)? Is the TSR running on the workstations that you're running OI on?

Have you tried stopping/restarting the NLM or the server? The NLM sometimes acts strangely at startup if the TSR is loaded on a workstation. It's best to make sure all the workstations that access the TSR do not have it loaded when you start the NLM up (power them down).

Try shutting down all the ARev stations, restart the NLM/Server and start an OI connection only (make sure the TSR is not loaded on the OI station). If OI loads and connects properly then try an ARev session from another station with OI still connected.

thanks for the response Warren-

all of our workstations are running AREV so all are running the TSR loading with – G:\AREV\LHIPXTSR.EXE /P /C:30 /R:50

I reinstalled the NLM 5.0 when our server was idle (mine was the only connection) and restarted it (LHSTOP/LHSTART). OI still errors on start up (when using the netware 1.5c driver).

I rebooted my PC and OI will still not run (verified TSR not loaded on workstation).

what else to try?

Maggie

These are XP Pro workstations? Home Edition does not (at least prior to SP2) support Netware.

The only thing I could think of is to uninstall the Netware client and reinstall it, maybe trying another version. If you have no need for TCP/IP, install it without it. I always do a custom install and leave out TCP/IP (IPX only), printer server/sharing, and review the NDIS options.

These are all XP Pro workstations.

I have uninstalled and installed several versions of Novell client and also the MS netware client.

I also just removed all protocols and services from the XP workstation except for the Novell client and IPX/SPX.

still same error msg after reboot.

what are we missing?

please don't give up on me yet!

Maggie

Confirm the following:

A.3.4 Drive Mappings Automatically Root Mapped

In Windows, all drive mappings made using the NetWare Login are root mapped. Because of this, programs cannot access directories above the directory that the drive is mapped to. This feature affects only MAP commands performed in a login script. After Windows has been started, Windows allows you to map only to the root.

You can turn off the default by adding SET MAPROOTOFF=1" as the first line in the login script. This globally forces all workstations using the login script to not map root drives.

Or, you can perform the following procedure on a local workstation:

 1. Right-click My Computer.

 2. Click Properties ] Advanced ] Environment.

 3. Click New to create a new variable.

 4. Type MAPROOTOFF as a variable.

 5. Set the value of the MAPROOTOFF variable to 1.

 6. Click OK ] OK.

Note: Set as a system/global variable so you don't have to do this for each and every user on the XP workstation

As I recall using the "SET MAPROOTOFF=1" in the login script didn't work properly (at least with Novell 3.x), thus having to set it in the workstation evironment.

Driver problem solved!

Many thanks to those who offered input.

This was the posting that really helped - thanks to Don Bakke

http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&KEY=7334DF2373EF480085256D520060D724&KEY1=7334DF2373EF480085256D520060D724

the REVPARAM file is VERY touchy and had to be exactly 14 bytes long to work correctly. That was one of the problems-(mine looked correct but did not have the necessary CR so was only 12 bytes long.)

The second issue I discovered purely by accident had to do with the length of the directory names. My Novell server is set to accept long file names, so I'm assuming this is an OI issue?

G:\Revsoft\OpenInsight\Development\OINSIGHT.exe does not work

G:\Revsoft\OInsight\Development\OINSIGHT.exe does!

It only seems to matter on the first 2 levels of the directory. Strange.

Both of these situations caused the 'REPOS_BFS FS' error with the 1.5c Netware driver.

Anyway, two very simple fixes once the problems were identified.

I hope this saves someone the many weeks of frustration I had fooling around with this.

Thanks again for all the hints.

Maggie Shinn

Great. That's not something that readily comes to mind even though I have it drilled into my head to always make sure there is an extra crlf at the end of the REVPARAM file. Or use Sprezzatura's wonderful REVPARAM utility.

]]the REVPARAM file is VERY touchy and had to be exactly 14 bytes long to work correctly. That was one of the problems-(mine looked correct but did not have the necessary CR so was only 12 bytes long.)

«

Is this still an issue with OI7.1 and LHService 2.1

Barry,

I don't think so. I just checked my Revparam and it's 37 byte.

Ray Chan

I meant where you only have ServerOnly=1 and no , where the size is 12bytes.

It used to be REVPARAM had to end with a CRLF or the last line would be ignored. I have not tested if this still holds true for the NT Service 2.1, just as matter of practice I always make sure to end with one or more CRLF. The NLM v5.5 still requires the CRLF.

View this thread on the Works forum...