INTEGRATING DATAFLEX WITH NETWARE
WORKING WITH
DIVERSE NETWARE CLIENTS
January 31, 1997
OVERVIEW:
It is beyond the scope of Data Access Corporation's technical support staff to become involved in the particulars of installing or configuring Novell networks. Such issues should be reviewed by the site network installer and the DataFlex application developer. We defer to NetWare certified installers, vendors and CNE's as well as official documentation accompanying NetWare regarding what settings should be changed and their effects on the overall system. This paper has been published to provide DataFlex developers, NetWare installers and IS personnel with useful supplements to Data Access Corporation's normal technical support. It does not represent an exhaustive coverage of the subject of DataFlex on NetWare and is subject to change without notice, as the products involved and our understanding of their interrelationships changes.
THE CUSTOMERS' AND USERS' PERSPECTIVE:
There appear to be three main issues with networking and the database applications that are supported by network services:
If the customer believes there is a problem with one or more of the above issues, changes will need to be made by the IS personnel or the DataFlex developer or both. Trouble shooting can be an extensive task when the customer's installed system is composed of various configurations of workstations, network interface hardware and client software. Today's networking layouts may consist of not just a local area network with a single server and identical workstations with the same configurations, but rather a conglomeration of 386, 486, and Pentiums operating under different o/s, networked to multiple file servers, servicing a wide area network, using multiple topologies and protocols. Making it all work together and transparently to the user is a challenge. Typically, all the user wants to do is login, select an application from a menu or folder, and begin processing.
HISTORY:
Often, what makes or breaks this functionality is
the networking client software. In the past there was NetWare 2.x and a single client
program, net3.com (or net4, net5). There were very few options and no settings at the
client end. Novell even developed its own frame type for the Ethernet topology while
waiting for IEEE to finalize its 802 standards. It used its proprietary transmission
protocols IPX and SPX. This worked fine as long as the network was to remain a local area
network. With the advent of the Internet, wide area networks for PCs and a variety of
operation systems at the workstations, it became clear that Novell would have to join the
rest of the world and adopt more universal standards and protocols.
With the introduction of NetWare 4.0 and NetWare Directory Services (NDS) Novell made the change to interconnectivity. The client software therefore had to change and yet still be compatible with older Novell networks. Novell adopted the 802.2 Ethernet frame type as its default and changed the client software to be modular, and modeled after the ISO's Open Systems Interconnection 7 layer reference model. For the client software, Novell introduced the Open Datalink Interface (ODI) which allows the client software to support other protocols besides IPX and SPX. With ODI, the ipx.com was replaced by 3 new programs: lsl.com, the network card interface driver, and ipxodi.com. In addition, the client software could be alternately reconfigured using a text file Net.cfg instead of having to regenerate the ipx.com in earlier versions. The DOS shell program netx.com (and later netx.exe) were replaced with a DOS requester designed to work with NDS. The DOS requester is characterized by the collection of Virtual Load Modules (VLM) and a VLM manager, VLM.EXE.
In 1990, Microsoft introduced Windows V3.0 and we witnessed the decline of DOS as we had known it. Making Novell client software work successfully with Windows became a major issue for administrators and DataFlex developers. It still is today.
With the introduction of Microsoft Windows 95, a mostly 32 bit o/s, the Novell client software and its 16 bit drivers are on their way out. Novell introduced its NetWare Client32 for Windows 95 (NC32W95) and Client32 for DOS and Windows v3.1 (NC32W3). Since the Client32 for DOS and Windows is still in Beta Testing as of this paper, it will not be included in the discussion.
FILE HANDLES:
DataFlex developers often take advantage of the power of having many files open at once. The real limiting factor in the number of open files is the o/s. MS DOS from versions 2.0 through 6.22 and its rival DOSs from Novell and IBM were written to handle a maximum of 255 open files. Early versions of NetWare's client DOS Shell software (net3.com through netx) were set to allow a defaulted maximum of 40 open files. The DOS Requester client software (VLM's) also had a default value of 40 for open files but included the FILES= setting in config.sys as long as the total didn't exceed 255.
Windows 95 handles file sharing automatically, so
share.exe or vshare in system.ini is not needed. Windows 95 defaults to FILES=60 if there
is no setting in config.sys. Some older software installation programs may cause problems
since they may not recognize the default is 60. Instead, they assume the older value of 8
and will add a FILES= setting in config.sys overriding the default value of 60 (e.g.
FILES=30). It is suggested that you set your FILES=255 (unless you are using Novell
Client32) in the config.sys file of a Windows 95 workstation regardless of how many files
are expected to be open at one time. If you use NC32W95, it doesn't seem to matter what
the setting in config.sys is. NC32W95 will use 255. The Novell FAQ documentation says that
Client32 will have available 255 file handles less the number in config.sys. Therefore, if
config.sys FILES=60 then 195 file
handles will be available for clients using Client32. It has been tested on a NetWare V4.1 server with various FILES= settings from 5 to 250 and the results are always the same. DataFlex running on the network should have enough file handles running under Client32 without modifications. The older Net.cfg file is not used by NC32W95. There is a bug in the 8/30/96 version of Client32.nlm that doesn't properly allocate file handles. The 8/21/96 version of Client32.nlm may work better with DataFlex.
BINDERY VS. NDS:
The bindery in NetWare prior to version 4.0 was basically a flat file database. Each server had its own bindery. This made adding users, printers, volumes, etc. a tedious task when there were multiple servers on the network. Each bindery had to be updated by manual effort using Syscon, Pconsole, and other NetWare utility programs. In addition, a user had to be authenticated (login and password) for each server individually.
NDS, NetWare Directory Services, beginning with NetWare V4.0 is a hierarchical database. It is also distributed. Parts of the NDS tree may exist, and usually do, on multiple servers. It is not a server based file. It is a network based file. Users, printers, volumes, servers, queues, etc. are entered into NDS as a single entry but network wide. From a single workstation logged in to NDS, an administrator may add, edit, and delete these objects and their properties once for the entire network. Also, a user logs into the NDS and not to any particular server. NDS then allows that user rights to other objects (printers, queues, volumes, servers, etc.). PC's must be using NDS aware client software to access the NDS tree.
To be compatible with clients still using NETX.EXE, which is not NDS aware, part of the NDS tree can be set to emulate a bindery similar to the bindery in earlier versions. This has limited functionality, however. Bindery emulation limits the client to only parts of an NDS tree so if, for instance, a printer & its queue are "located" in another branch of the tree, they will be unavailable for that client. Prior to NetWare v4.1, the bindery emulation was limited to one container object, a severe restriction. With NetWare v4.1 bindery emulation was expanded to include up to 16 container objects. However, this is just a temporary fix. Novell wants NDS to become the defacto standard and will most likely drop bindery emulation for NETX clients in the near future. NETX.EXE itself is no longer supported officially by Novell since January, 1994. Windows 95's client for Novell Networks is a bindery based client and is not NDS aware.
Windows 95 includes Microsoft's Client for NetWare.
This is a bindery based client (for NetWare versions prior to 4.0) and cannot access the
NDS tree. What this means is that the MS client for NetWare is functionally the same as
netx.exe but is a 32 bit shell. MS has an updated NetWare client available for download
that supports some features of NDS but will not support NDS aware software like
NWADMIN.EXE. To be able to support and administer the NDS network you are limited to the
Novell 16 bit DOS Requester client (VLMs) or the newer Novell Client32 for Windows 95. If
you wish to access NetWare 4
servers through bindery services you will have some severe limitations. Version 4.0 through 4.02 of NetWare allowed only a single container object in NDS to be used for bindery emulation. This will work fine for small single server networks. What that meant was all the leaf objects that were going to be accessed by a user logged into bindery services had to be located inside a single container object. With NetWare 4.1 the bindery services can be extended to include up to 16 container objects. Still, bindery services is a solution for networks that still have either a mixture of NetWare servers (i.e. 3.12 and 4.1) on the same network, and/or workstations that are not configured to the newer client software. Those workstations are still using the older netx.exe, or are running under Windows 95 using the Microsoft Client for NetWare.
NETWORK INTERFACE CACHING AT THE CLIENT:
NETX did not support any i/o caching on the network. The result was that the NIC had to reject (drop) packets if it was busy. Likewise, all requests from the o/s to access the network had to wait if the NIC was busy. With the introduction of the DOS Requester (VLM), NIC caching was added. For the IPX protocol, the buffer size is fixed at 1500 bytes and the BUFFERS= setting in LINK SUPPORT is ignored. There are 2 other settings that may be safely changed in LINK SUPPORT: MAX BOARDS and MAX STACKS. The default for each is 4. If you are only using a single frame type (EtherNet802.2) then try setting these 2 parameters to 1. This will save RAM overhead. In the DOS REQUESTOR section of Net.cfg, setting the CACHE BUFFERS= ### will control the cache. If you don't specify, the default is 5 buffers. In addition, the CACHE BUFFER SIZE=### can be set but you should refer to the NIC manufacturer's documentation for suggested settings.
Search modes in Net.cfg can be set to control the search for files beyond the current directory in search drive mappings. There are 5 settings from 1 to 7 where 1 is the default and 4 and 6 are not used. The command FLAG /MODE= (or SMODE in NetWare 3x) sets the type of search. If FLAG /MODE= is not set or set to 0 (zero) then the search mode is that set in Net.cfg. So, the default is FLAG /MODE=0 (refer to Net.cfg) and if Net.cfg doesn't specify a SEARCH MODE= then the default ends up being 1. Data Access has recommended in the past that the FLAG /MODE=0 and the default in Net.cfg be left at 1.
1-Search if path is not specified for the data file.
2-Never search.
3-Search if path not specified and request is to read a file but not to modify it.
5-Always search.
7-Always search if request is only to read the file.
PRINTING ISSUES:
Since a few years ago, with the introduction of NetWare 3.12 there have been some problems with printing using DataFlex. Many of the issues revolve around printing at workstations with local printers attached. Error messages such as Device Not Found, Error Writing To Device, and Device Not Ready are confusing when other non-DataFlex applications appear to print just fine.
Some of these problems are caused by directory path settings, drive mappings, device names, and configuration settings in the client software.
Some notes:
Device name LST: (the default in DataFlex) no longer works as an output device name after DOS v3.3. PRN: and LST1: do work. If you do not have access to the source code, then setting DFPRINTER=LST1: will change all the outputs directed to LST: to LST1:
DFPATH must end with a semicolon.
MAP Root should not be used for the executables subdirectory.
In NET.CFG the LOCAL PRINTERS=0 cannot be used.
Use the most recent client software.
Set the first drive in DFPATH to a local drive.
With Windows 95 and NetWare there are some reported problems with using the Microsoft Client in that when capture is used with the Time Out parameter (TI=) the time out doesn't seem to work. Only a DCE (device close endspool) will trigger a close of the capture queue file and initiate printing on the network.
Suggested reading: Novell's NetWare 4.1 Administrator's Handbook, Kelly J. P. Lindberg, Novell Press 1995.
NETWARE V4.X VOLUME AND TTS:
If you become involved in setting up a NetWare V4.x
file server consider creating more than one volume (sys:). If you create a 2nd
volume, it is recommended that you place the spool directories there. This is a new option
in NetWare 4. Previous versions of NetWare only allowed spool directories on the Sys:
volume. Placing the spool directories on a volume other than Sys: protects the Sys: volume
from becoming full by a very long print job. When the Sys: volume becomes nearly full, TTS
is shut down automatically and, if
DataFlex is set to Server Atomic, you will lose the benefits of TTS in your DataFlex application.
NOVELL CLIENT32 FOR WINDOWS 95:
This client is a big departure from previous Novell NetWare client software. It is no longer a TSR, but instead a group of drivers integrated into Windows 95. It uses the Windows 95 registry instead of Net.cfg, Shell.cfg, or system.ini files to control configuration parameters. In addition, many of its parameters are dynamic (i.e. self modifying) to obtain optimization. This Client32 also makes use of the NLM (NetWare Loadable Modules) technology instead of the older VLM technology. There are several new speed enhancement parameters that DataFlex developers should be aware of and, if necessary, adjust for data integrity over performance. These are listed below. But first, why use Novell's Client32? What is wrong with the VLM's your customer/employer is now using? What other choices do you have when using Windows 95 with NetWare? Before you look for answers to these questions one must look at where NetWare is heading.
The LAN used to be a server, perhaps two, with several workstations attached to it for file and printer sharing. But this is very limited. Larger companies wanted to use Novell for their WAN and be able to administer it effectively. The introduction of NetWare Directory Services (NDS) with NetWare v4.0 was the first step in that direction. Interconnectivity with the Internet has now become a priority also and NDS is well suited to that task. So, where does that leave NetWare versions prior to 4.0? Novell has announced that V3.12 is the last version of NetWare 3.x. It is time to move on. NetWare 2.2 was the last version of 2.X and was discontinued in 1993. So, NDS is the future of Novell Networking and quite possibly the future of Windows NT Server as well. The client software you choose can either support NDS or it can't. If you are now using NDS for your network or foresee NDS in your immediate future you will need to choose a NetWare Client that supports NDS. Your choices for Windows 95 when supporting NDS are: 16 bit VLM's as TSR's, 32 bit MS Client for NDS, or Novell Client32 for Windows 95. Since the computer industry is moving away from 16 bit software (32 hardware has been around since the introduction of the 386 in 1987) at a rapid pace, the real choice is between the two 32 bit clients. There are advantages and disadvantages to both.
MS 32 Client Novell Client32
Vendor Windows author NetWare Author
Product Included with Windows Included with NetWare
Properties Few choices Many choices
Dynamic Properties NO Yes, most are self modifying
Networked Printers NO Yes, Nprinter
Remote Program Load Yes, diskless w/s support NO
Auto reconnect Yes, but limited Yes, multi-level choices
Caching Read/Writes More extensive
32 bit ODI driver support NO, 16 bit is supported Yes, & 16 bit drivers as well
32 bit NDIS driver support Yes Yes
Packet signature/encryption NO Yes
Full NDS support NO, e.g. can't run NwAdmin.exe Yes
Windows 95 policies Yes, stored on server/disk Yes, part of NDS
Automatic Frame Type Detection NO Yes
Caching may be a problem for database applications like those developed with DataFlex. While caching increases performance by delaying writes and reading ahead, there is the possibility that data may be lost or corrupted. Caching at the workstation means that the server and the workstations must be in constant touch with one another for the following situations: data at the workstation has changed but has not been sent to the server and another client is requesting that same record, the client has locked the file exclusively and another workstation attempts to lock the file, data at the server was changed by another client but the data cached at the workstation is unaware that the data has been changed. On a busy network these situations may increase network traffic, but most importantly, if the communication is broken, data loss or corruption may be the result. This may not be a problem with client/server applications like DataFlex for Btrieve, but for other applications it is disastrous. Consider whether caching is needed for the workstations processing data. Remember, this setting is for each workstation. Those workstations that are only querying data and not writing to the data files, or are involved with non-database applications will most likely benefit from caching. The following is a list of caching properties, their defaults and suggested settings for Novell Client32 for Windows 95 for use with DataFlex:
OPPORTUNISTIC LOCKING: Default = ON. It is suggested
that this property be set to OFF. There is not much information on the use of this
property. It is supposed to lock the file and then cache it for a single client to the
exclusion of other users. It is supposed to
unlock under certain circumstances. But further information is not available on this property. With the most recent NC32W95 Opportunistic Locking is not included.
CACHE WRITES: Default = ON. It is suggested that this property be set to OFF. ON improves performance but decreases data integrity.
CLOSE BEHIND TICKS: Default = 0. It is suggested that this property be left at 0. It is the delay from the close of a file until the file is flushed from cache and written to the server disk which usually takes place on a close file or application exit.
DELAY WRITES: Default = ON. It is suggested that this property be set to OFF. This property specifies whether at the close of an application or overlay (DLL) the files may be delayed in writing back to the server. For word processing and presentation software it can speed up processing but for database applications it may decrease data integrity.
FILE CACHE LEVEL: Default = 3. It is suggested that this property be set to 0, file caching is off and no extended memory is used. Other settings: 1. Read first before processing writes. Also, read ahead. 2. Short-lived caching. Files are cached until the file is closed. Reopens are always read from the server. 3. Long-lived caching, which is the same as level 2 above but reopens are not read from the server. 4. Warehouse caching, which includes level 3 above plus local disk caching where instead of all caching in memory, the client writes to local disk for caching.
MAXIMUM CACHE SIZE: Default = 0 (which is not true, 0 means use ¼ of available memory for caching). This could be 2mb if the workstation's free memory is 8mb. It is suggested that this parameter always be set to conserve memory. Values are in kilobytes. If you want caching for 64 kilobytes then use 64. If File Cache Level is set to 0 then all caching is turned off regardless of the Maximum Cache Size.
TRUE COMMIT: Default = OFF. It is suggested that this property be set to OFF unless your data is extremely important. True commit forces the server to write immediately to disk all writes from the workstation without buffering them in the server's file caching. Setting to ON will noticeably affect file server and workstation performance. Actually this forced save rarely happens. What does happen is that the server will not acknowledge a successful save until it has written the data to server disk.
Other properties worth taking a look at in NC32W95 are:
LARGE INTERNET PACKETS: Default = ON. It is suggested that this property be left to ON. Otherwise, the client will use 576 bytes for the packet size.
LARGE INTERNET PACKET START SIZE: Default = 65535
bytes. This is a dynamic property and the client will adjust this as it communicates with
the server. You may need to adjust this if you are operating over slow network links to
reduce the negotiating process time.
PACKET BURST: Default = ON. It is suggested that you leave this property set to ON. Packet burst increases performance and reduces overall network traffic.
Relative speed or response time of a networked PC is often an issue when administrators are dealing with users. Sometimes after installing a new client software, the PC's speed is reduced. Check to see which NIC driver is being used. If the client is a 32 bit client, is the NIC driver 32 bit? Was the ODI driver used in the past, and the NDIS driver is being used now? Is the driver the latest from the NIC manufacturer? If you remove the older 16 bit ODI driver you used with VLM's when switching to the Client32, the Client32 may use the MS NDIS NIC driver instead. On the other hand, if the MS NDIS NIC driver is not installed, Client32 defaults to using the NDIS NIC driver if present but you may use the 16 bit ODI driver that was used previously by the VLM software.
Multiple Client Protocols:
Mixing networking protocols becomes a problem under Windows 95. The use of Novell Client32 for Windows 95 will prevent the use of Microsoft Client for Novell Networks, although it doesn't preclude the use of Microsoft Client for Microsoft Networks. For some administrators and developers this means that you will not be able to share CD-ROM drives disguised as NetWare servers using SAP (Service Advertising Protocol). This was a convenient feature in the Microsoft Client for Novell Networks which allowed the administrator or user to map to a shared drive as though it was a Novell file server/volume.
With NC32W95, a user can easily view which client modules are installed and active by creating a DOS box and from within the DOS box type MODULES to list the current modules. It is similar to the MODULES command on the server console.
Novell's Client32 has no support to Target Service Agents (TSA) on the PC. Some server backup software for Novell Networks offer workstation backup if a TSA is active on that workstation. This will not work with the current version of Client32.
If you have a mix of NDS servers and v3.11 or v3.12 servers on the network and you are using Client32 you must load SHORTAFX.NLM on the v3.x servers or Client32 workstations may not be able to perform MAP INSERT in login scripts and may not be able to "see" all files.
Client32 supports the use of the @ sign (in place of the # sign) in login scripts which will spawn a command task as a separate task and let the login script continue at the same time.
Finally, make sure, no matter which client you
choose, that all the Novell update patches have been installed both for the server and the
client software. This is extremely important. Often, administrators say they won't install
the patches until they detect a problem. However, the patches keep the risk of failures,
lost data, and problems to a minimum. For the most part they are fixes based upon
information received from other administrators and
installers using Novell Networks. The most recent
version of the Novell Client32 for Windows 95 is 95enu_n2.exe and is available from Novell
on Compuserve or www.novell.com. There are some reported problems with the purchase of new
PCs with Windows 95 already installed. These PCs have a version of Windows 95 referred to
as OSR-2 (Operating System Release 2 for Windows 95). This OSR-2 version along with
Novell's Client32 for Windows 95 appears to not work correctly with Btrieve files.
About the author:
Jim Albright is president of Wizard Systems, Inc. of Port Orange, Florida, an application development company. Jim is a graduate of the University of Florida and holds a BSBA degree. He has developed exclusively in DataFlex since 1984 from versions 2.0 through 3.1 both in OOP and procedural programming. He is a Novell Authorized CNE-4 and CNE-3 and a member of the Networking Professionals Association and the NetWare Users International.
You may contact him via the Internet: wizsys@ix.netcom.com, AOL: WizardCNE, Compuserve: 70033,3224. Web page: http://ourworld.compuserve.com/homepages/wizardsystems.