Invisible Software

Tips for Setting Up Network Applications for DOS and Windows 3.X

 

When setting up software applications to run on InvisibleLAN, there are a number of items that must be considered. The most important of these and, thus, the ones that will be dealt with in this Support Document, are Compatibility, Common Drive Letters, File Sharing, and File Handles.

The information is this document applies to setting up applications that run under DOS or Windows 3.X. All references to the InvisibleLAN software refer to the DOS and Windows 3.X version of InvisibleLAN.

Compatibility

The most important issue when attempting to ascertain whether or not an application will be compatible with InvisibleLAN is whether or not the application supports NetBIOS (Network Basic Input/Output System) networks. NetBIOS is a network protocol that is specified by IBM. Applications that are NetBIOS-compatible (the majority of network applications are) will work with InvisibleLAN.

There are some applications that are written only for certain networks; the most common are those written only for Novell Netware . At times, the application manufacturer will claim the application only works on Novell, when in fact it will indeed operate in a NetBIOS environment. If the application makes Novell-specific calls, it will not function properly in a NetBIOS environment and will not work on InvisibleLAN. If considering an application that may be "Novell-only" for use with InvisibleLAN, check with the manufacturer's technical staff.

Some application manufacturers will make statements such as "we've heard it runs on NetBIOS, but we don't support it" or "we haven't tested the product on InvisibleLAN, but it runs fine on LANtastic". In the former case, some applications will have been tested by their manufacturers only on non-NetBIOS networks, such as Novell. Though their product makes no Network Operating System-specific calls and would indeed run properly in a NetBIOS environment, they have only tested their product with non-NetBIOS operating systems and, thus, often cannot provide proper assistance in setting up the application for use on InvisibleLAN. If you encounter one of these comparatively rare applications, consider your own expertise in the network arena, as well as the recommendations of the manufacturer, before proceeding. As to the latter statement, the general rule is "if it runs on LANtastic (or other NetBIOS network), it will run on InvisibleLAN."

The majority of single-user applications function quite well on InvisibleLAN. An understanding of, and compliance with, the guidelines set forth in the rest of this Support Document is generally all that will be required to have them up and running with a minimum of effort. Certain single-user applications, many of which are older, will make hardware-specific calls or cause other conflicts that will make them inoperable in a NetBIOS environment (a notable example being the Quicken family of products). Remember: making a single-user application function properly on a network, even by more than one person simultaneously, does not necessarily make the data files shareable. File sharing will be discussed later in this Support Document. Concurrent access of the same single-user database, accounting, or other data files by more than one individual may damage or even destroy the integrity of the file - check with the manufacturer of the application.

The ability to make a single copy of an application simultaneously accessible to more than one user does not constitute an abatement by Invisible Software of the licensing policies of the application's manufacturer. It is your responsibility to ensure that use of an application on a local area network does not violate the terms and conditions of the application's software licensing agreement.

Common Drive Letters

Many applications, in order to function properly in a network environment, require the existence of a common drive letter. By common drive letter, we mean that all computers in the network, the file server for this particular application included, must access the application using the same DOS drive letter, such as F:.

The necessity for this is as follows: suppose you install an application, such as Peachtree Complete Accounting , on your file server. During the installation process, you instruct the Install program that the various files are located on the C: drive of the server. After the installation process, you run Peachtree on the server and all runs fine. Now you go over to one of your workstations to run the program. The workstation maps to the server's C: drive using the drive letter F:, so you change to the F: drive, change directories to the directory Peachtree is installed in and attempt to load the product. You will receive an error because, although you are sitting in the proper directory to run the program, Peachtree's internal drive pointers all say "look at the C: drive for data" and it cannot find the operating files on the C: drive - your C: drive! This is the reason a common drive letter is required.

The solution is actually quite simple. Before beginning installation of any application that requires a common drive letter (even those that don't will operate properly if installed in this manner), simply create a virtual drive on your server. A virtual drive is one that exists by reference only - the drive does not physically exist on the system. This involves the use of the DOS SUBST command.

First, decide which drive letter you'll want to be the one used as the common drive letter network-wide. It is a good idea to select a letter that will never exist as a physical device on any machine. Since the largest number of physical hard drives you are likely to put in a single machine will be three (drives C:, D:, and E:), a good choice is often F:. To create this virtual drive on the server, place the following command in the file server's AUTOEXEC.BAT file on a line prior to the NET30 command line:

C:\DOS\SUBST F: C:\ (this assumes DOS is in the \DOS directory)

The next time the server is booted, the SUBST command will be executed prior to the execution of the network software, which will create a virtual drive on the server called F: that is identical to the server's C: drive. Now that the common drive letter has been established, simply install Peachtree to the F: drive. Now when the server or the workstations attempt to load the program, they'll all be accessing Peachtree on the F: drive and everything will run smoothly.

File Sharing

Most network-ready applications (and many single-user ones as well) can be installed with only one actual copy of the program files on the network, which are installed to a file server (again, this assumes that such an installation is within the constraints of the manufacturer's licensing agreement). Everyone on the network "shares" this single copy of programs when using the application.

NetBIOS networks use the DOS SHARE command for record and file locking. In many cases, the SHARE command itself creates a problem - it places a file lock on the program, or executable, files of an application. Once the executable is locked by SHARE, a second person cannot also load and run the program file - errors such as "Sharing Violation" or "Error Reading..." or "General Failure..." will occur. This is an easy situation to rectify, and involves the use of the DOS ATTRIB command to flag, or mark, the executable files "read-only".

Flagging a file as read-only prevents the SHARE command from locking the file as follows: Normally when you open a file in a SHARE environment, the SHARE command assumes that you will later be writing to the file. SHARE is not aware of the difference between program files and data files, so it places this lock on all files it opens (note that when a network application opens a data file such as a database file, it does so in a special "shared" mode so that only individual records need to be locked rather than the whole file - this bypasses SHARE's locking). Data file locking is done for a simple reason: if a file, such as a word-processing file, were allowed to be opened by two people simultaneously, the last person to save the file would overwrite the changes made by the first person to save the file. Program files, however, do not need the protection SHARE offers against this sort of problem, so we use the ATTRIB command to flag these files read-only. When a file is flagged read-only, SHARE knows that the file cannot possibly be written to, thus eliminating the need to lock the file.

Before starting, you must first ascertain which of the files associated with the application are program files. Program files with extensions such as .EXE, .COM, and .OVL are common, but there are often other program files associated with the program that have other extensions or filenames. This information is often contained within the documentation of the product, but might only be available through the technical support department of the manufacturer. Invisible Software cannot identify which are the program files for your particular application. Once you have compiled the list of program files, we are ready to use DOS' ATTRIB command.

To flag the list of program files you have compiled as read-only, use the SHARE command as follows: Type the following command at the DOS prompt, replacing <filename> with the name of the file (or files -- wildcards such as *.EXE or *.DLL are allowed here) to be flagged:

C:\DOS\ATTRIB +R <filename> (assumes DOS is in C:\DOS)

Repeat as many times as are necessary to properly flag all of the applicable files. This will eliminate the possibility of a program failing to load properly because a program file has been locked by another user.

File Handles and Locks

By far the most difficult aspect of configuring the network for a particular application, and one of the most misunderstood aspects of the network software as a whole, is providing for a sufficient number of File Handles for the application.

Aside from the special considerations for Ultra Server (which are covered later) there are five places where File Handles items are set: the CONFIG.SYS FILES Parameter, the Redirector OPEN FILES Parameter, the Server FILES Parameter, the Server SPOOL FILES Parameter, and the Share OPEN FILE NAMES SPACE Parameter. These five parameters will be covered as they apply to each of the three possible machine-configuration scenarios: A Redirector (machine that does not load the File Server portion of the network software), a Server (one that does) and an Ultra Server (a machine that loads our Dedicated File Server product).

Considerations for a Redirector

A Redirector is a machine that does not load the File Server and does not share its drives or printers, but can share the drives and printers of machines configured as Servers elsewhere on the network.

The CONFIG.SYS FILES Parameter

This is the maximum number of files that can be opened on the machine's own local drives. When this value is added with the value in the Redirector OPEN FILES Parameter (below), the total cannot exceed 250.

The Redirector OPEN FILES Parameter

This is the maximum number of files that can be opened on other computers. When this value is added with the value in the CONFIG.SYS FILES Parameter (above), the total cannot exceed 250.

Example: In CONFIG.SYS, there is a FILES = 100 statement. In the Redirector Parameters of the Advanced Configuration in the SETUP30 program, the OPEN FILES parameter is set to 50. The sum of the two parameters is 150, which is well below the 250 limit. This machine can open 100 files on its own drives plus another 50 files on other computers.

The Server FILES Parameter and The Server SPOOL FILES Parameter

NOT APPLICABLE - A Redirector machine is not configured as a File Server.

The Share OPEN FILE NAMES SPACE Parameter

This is applicable only if SHARE is being loaded on this machine (which is not necessary on a Redirector, but may be required by certain applications). OPEN FILE NAMES SPACE is sized in relation to the maximum number of files that can be opened locally. Each open file name requires an average of 40 bytes of space, so in a Redirector with a CONFIG.SYS FILES=100, the OPEN FILE NAMES SPACE parameter should be sized at at least 4000.

Considerations for a Server

A Server is a machine that is capable of sharing its drive(s), printer(s) or both with the machines on the rest of the network. It may also load the Redirector, which allows it to access other machines' drives and printers, but this is not required unless this functionality is desired.

Server machines have an option called Private Files, a parameter that is set in the Server Parameters of the Advanced Configuration in the SETUP30 program. If set to "Yes", the CONFIG.SYS FILES statement does not limit the number of files that can be opened on the Server by other machines - this is then limited by the Server Parameters FILES Statement. CAUTION: If Private Files is set to "Yes", the Server will be unable to Run Windows in 386-enhanced mode.

The CONFIG.SYS FILES Parameter

The proper value for this parameter is a combination of the following:

If the Server has Private Files as "Yes", the number of files that can be opened on the Server by other machines on the network will be governed by the Server FILES Parameter (see below).

The Redirector OPEN FILES Parameter

This is the maximum number of files that can be opened on other computers. When this value is added with the value in the CONFIG.SYS FILES Parameter, the total cannot exceed 250 [identical to the Redirector OPEN FILES Parameter listed under Considerations for a Redirector (above)].

The Server FILES Parameter

This is the maximum number of files that the server can open on behalf of other network users. The maximum value of this parameter is 250, unless Private Files is "Yes", in which case it can be set as high as 1000. See the caution in the opening narrative of Considerations for a Server.

The Server SPOOL FILES Parameter

This is the maximum number of files that the server's print spooler can have open. Note that even print jobs sent to the spooler by the server itself are included in this value.

The Share OPEN FILE NAMES SPACE Parameter

On a File Server it is required that the DOS SHARE command be run. This can be accomplished in two ways. The easiest way is to have the network software load it as a part of the execution of the NET30 command. This is accomplished by setting the "Load SHARE" parameter to "Y" in the General Network Parameters screen of the Advanced Configuration of the SETUP30 Program. The Share Parameters screen contains the OPEN FILE NAMES SPACE parameter which is sized according to the instructions below.

It is also possible to simply load SHARE by placing the command in your AUTOEXEC.BAT file. If loaded in this fashion ("loading high" using DOS' LOADHIGH [or LH] function is permissible), the OPEN FILE NAMES SPACE value is specified using the /F: parameter (refer to your DOS manual for further information on loading SHARE in this manner). The /F: parameter is sized according to the following:

On machines that have large CONFIG.SYS FILES or Server FILES values, the OPEN FILE NAMES SPACE value can be quite large. For example: A server on your network has a CONFIG.SYS FILES value of 150 and a Server FILES value of 500 with a private file table. 650 total files multiplied by 35 average bytes per filename yields 22750 bytes of space that SHARE will allocate for its lock table. This means that some 22K of memory will be lost to the SHARE command. If this is a problem on this machine, you can try setting the parameter at a lower value on the assumption that 650 files would never be opened simultaneously.

Considerations for an Ultra Server

Ultra Server, our 32-bit protected mode high-speed dedicated file server, has its own FILE HANDLES parameter. This parameter is the maximum number of cached files that the server can open on behalf of other network users. On an Ultra Server, any uncached files are accounted for in the Server FILES Parameter.

Cached Files and Uncached Files are defined as follows:

In Ultra Server Parameters (in the Advanced Configuration of the SETUP30 Program), drives can either be set as uncached or cached. Cached drives are either fixed disks, which are cached as read/write devices, or as CD-ROMs, which are cached as read-only devices. Files located on cached drives are handled by the Ultra Server, whereas files on uncached drives are handled by the standard server.

A special exception to these rules is that Ultra Server establishes a special cache blackout zone in the network directory on the drive the network boots from. This is usually C:\NET30, but could be something else if, for instance, your network software loaded from the D: drive in the directory \NET. The blackout zone includes the contents of any subdirectories underneath the network subdirectory as well.

Cached Files are those files that are contained on drives, be they fixed or CD-ROM, that are marked as cached drives in the Ultra Server Parameters.

Uncached Files are those files on drives marked as uncached, files on floppy drives on the Ultra Server, and files contained in the blackout zone of the Ultra Server.

 

Notices: Copyright 1994 by Invisible Software, Inc. Invisible Software, InvisibleLAN, and Ultra Server are trademarks of Invisible Software, Inc. Other trademarks are the property of their respective holders.

This document was prepared on 03/01/93, and was believed to be accurate as of that date. Procedures, specifications, and compatibility may change without notice, and therefore this document may be out-of-date and/or inapplicable to current product versions. Invisible Software provides this document "AS IS" and without warranty of any kind. Under no circumstances shall this document be construed as creating or expanding any warranty of product performance.

 

Go back to Support FAQ.