ISSUE:

A NetWare NLM Btrieve application running on local server A can access Btrieve files on remote server B. The Btrieve calls from the NLM go to the BROUTER NLM on server A which establishes an SPX session with the BSPXCOM on server B. The BSPXCOM on server B forwards the Btrieve calls to Btrieve on server B for processing. In a multi-server NetWare environment with hundreds of NetWare servers, the establishment of the SPX session from the local BROUTER to the remote BSPXCOM NLM can fail with a Status Code 96 ("A communications environment error occurred"). This Status Code 96 is generated by the way BROUTER NLM identifies NetWare servers that are running the BTRIEVE NLM.

SOLUTION:

BROUTER NLM maintains two internal tables to track Btrieve servers. They are the File Server Table (FST), which lists server names and addresses, and the Server Routing Table (SRT), which lists servers known to be running Btrieve. Each of these tables has a hard-coded size of 256 entries. Prior to the 11/94 release of BROUTER.NLM, these tables were populated as follows:

1) BROUTER NLM obtains the name of the server on which it is running and puts it in the FST as
the first entry.

2) BROUTER NLM reads the NetWare Bindery to obtain the names and SPX address of the remote NetWare servers and puts as many names as will fit into the FST. If more than 256 NetWare servers exist on the network, BROUTER NLM will not be able to access all of them. The postion for a particular server name in the FST is simply the order in which the name is returned from the Bindery, thus, there is no predictive method to determine a priori whether or not the server name will be included in the FST.

3) BROUTER NLM reads the NetWare Bindery to obtain the names of the remote NetWare servers that are running BSPXCOM NLM. For each of the returned names, BROUTER NLM checks the FST to see if the NetWare server name is known to BROUTER NLM. If it is known, BROUTER NLM puts that name in the SRT. If the NetWare server name is not in the FST, BROUTER NLM discards the Btrieve server name and will return a Status Code 96 when an application attempts to access that server.

4) BROUTER NLM waits for an application NLM to make a Btrieve Open or Create request to a remote server. At that time BROUTER NLM will check the SRT to see if the server is already known. If it is, BROUTER NLM will reuse an existing SPX to access that server, or establish a new SPX connection as needed. BROUTER NLM can maintain up to three simultaneous connections to  any server, based on thread requirements. If a connection exists, but is in use by another thread, BROUTER may establish a second or third connection to the server for the thread making the Open or Create request.

Starting with the November 1994 release of BROUTER NLM (which would be v6.l0e from Novell, or v6.15 from Pervasive Software), BROUTER NLM populates these tables as follows:

1) BROUTER NLM obtains the name of the server on which it is running and puts it in the FST as the first entry.

2) BROUTER NLM waits for an application NLM to make a Btrieve Open or Create request to a remote server. At that time BROUTER NLM will check the SRT to see if the server is already known to BROUTER NLM and if so will use an existing SPX connection. If the server is not in the SRT, BROUTER NLM will read the NetWare Bindery to determine if the the remote server is running BSPXCOM NLM. If it is, and if BROUTER NLM has an available slot in the SRT, BROUTER NLM puts the server name and address in the SRT and FST, and establishes an SPX connection. If there is no room in the SRT, BROUTER NLM returns a Status Code 96.

The FST and SRT are cleared when BTRIEVE NLM is unloaded.

This information is from the Pervasive Software Tech Tips Database.

ArticleID: BTRTT-97070801
Title: Status 96 from a NetWare NLM Application
Reference ID:
Creation Date: 8 July 1997
Document Revision: 1

Product: Btrieve for NetWare
Version: 6.x

Environment: NetWare

Category:

Status: Verified
Access: Public

Keywords: Status 96, BROUTER, NLM SUPPORT