Network Planning and Configuration
Questions and Answers

(revised April 7, 1997)

 

Q. Is Artisoft's Lantastic networking software a good choice to run network version of SOS programs?

A. Lantastic is a very popular networking system and, provided it is configured correctly and you use high speed ethernet interface cards, it will provide quite satisfactory performance. Configuration can be tricky, so it is essential that your network be installed by an experienced network technician. In spite of the advertising, this is definitely not a do-it-yourself undertaking. In general, we recommend that you consider a Windows for Workgroups or Windows 95 network instead of Lantastic for installations of up to 5 workstations. Larger installations should use a Novell or Windows NT file server.

Q. If we are using another network program besides our SOS software, would it be advisable to configure a second server on our peer-to-peer network and install the other program there rather than on the server we use for SOS?

A. Configuring a computer as a server as well as a workstation uses considerably more conventional memory, compromising its use as a fully functional workstation. Since servers have to tend to network activities at the same time as they are handling "foreground" applications that you might be running, performance of both the network and the application will be diminished.

Except in unusual circumstances, we would suggest that you put both programs on a single, dedicated, high performance file server. A dedicated server is one that is not used to run applications. Lantastic includes a program called "ALONE" that should be the only program running on the dedicated file server. It provides a constant display of network activity while dedicating all of the server's computing power to network function. Because you do not have to worry about saving memory to run foreground programs, you can configure the Lantastic buffers and other server settings for optimum performance.

High performance file servers are characterized by large, fast hard disks (SCSI or local bus IDE, with several megabytes of system RAM configured as disk cache or a caching controller with several megabytes of RAM), lots of memory, and fast processors. A Pentium is preferred, but a dedicated 486DX may be adequate for many small networks. The hard disk system and disk cache size and speed will make more difference in performance than whether the processor is a 486, or Pentium. You can save money by using an inexpensive video card and monitor (monochrome VGA), since for the most part no one will be interacting with the machine directly. At this point in time, our recommended server would be a 486DX or low-end Pentium with at least 16 megabytes or more system memory (RAM), a PCI or other local bus network interface card, and the fastest hard disk system you can afford. SCSI interface drives are better choices than IDE for server usage because they are faster at processing simultaneous requests for data.

If you are using a so-called peer network, there is nothing preventing you from using the server as a workstation in an emergency, but with the price of a spare 486 workstation (no hard disk) being under $600, it would be much better to just have an extra station on the network to begin with.

In this type of configuration, all other computers are configured as workstations ONLY. Do not be tempted to set up every computer as both a workstation and server; it will make drive mapping a challenge and adversely affect performance.

 

Q. Is is necessary for all the computers on the network to be modern 486 or faster computers?

A. The speed of each workstation will determine the speed at which applications run on that specific machine, but have no impact on the performance of software on other, faster workstations on the network. An old 386 can still be quite useful to run applications like text-based word processors. You should not even rule them out for many types of activities in DOS-based SOS programs, such as Office Manager daysheet entry, checking balances, and adding new patient information. You would not want to do month-closing, or insurance or statement runs on the slower machine, however, if a faster workstation is available. Neither OM4 nor Case Manager for DOS software should be run on anything less than a 33 MHz 386DX with 4 MB of RAM or more.

All SOS Windows-based programs require at least a 486DX with 8 MB of RAM.

 

Q. We are having a real hard time freeing up enough RAM to run SOS programs. Is there any way to release more conventional memory, or reduce the amount of RAM needed by the SOS applications?

A. If you are using OM4 and all of your network workstations are 386 or better with at least 4MB of RAM, you should install the "Extended Edition" of OM (included on OM4.13 and later installation disks). This edition of the software loads in extended memory and requires no more than 535K of conventional RAM. Use the MEM command to be sure that each workstation has at least 2MB of available XMS at the DOS prompt if you intend to use the extended edition of OM4.

Those running CM, older versions of OM, or using equipment that cannot take advantage of the extended edition should review the basics of RAM management are covered in the manual in Appendix R. Beginning with Version 3.14 of OM and 1.22 of CM you can immediately reduce conventional RAM requirements quite substantially if you have expanded memory available in your computer. Most 386 and faster computers use memory managers such as DOS's EMM386.EXE loaded in the CONFIG.SYS file. Providing this line does not contain the parameter "NOEMS", you should be able to use the first method below. It will never do any harm to try. The other methods are available with all versions and you may combine methods if you like. They are listed in order of impact on performance, method 1 being the least impact:

Method 1: Add the following line to your AUTOEXEC.BAT file:

SET SOSEMS=ON

to save approximately 62K of RAM with OM, and approximately 50K of RAM with CM.

Method 2: Be sure that you have loaded all possible network drivers into high memory. DOS's MEMMAKER utility will not configure these programs for high memory unless they are loaded in the AUTOEXEC.BAT file. If you load your network with a separate batch file, such as STARTNET.BAT, you will have to add the appropriate LoadHigh commands in that file, or copy the contents to your AUTOEXEC.BAT file so that MEMMAKER can do it for you.

Method 3: Create a RAM disk (see your DOS manual) and use it for virtual memory. If your RAM disk is addressed as D:, for example, you would add the following to your AUTOEXEC.BAT file:

SET CLAVM0=D:\,128,M

The "M" at the end of this line specifies that the virtually memory drive is a RAM drive rather than a standard hard drive.

Method 4: A hard disk may also be used for virtual memory, but it will result in slightly degraded performance. You may notice, for example, a slight delay when screens and windows display. To configure for hard disk virtual memory, add the following line to your AUTOEXEC.BAT file:

SET CLAVM0=C:\OM,128

Be sure that the directory you specify actually exists on your hard disk! The program will immediately lock up your machine if you specify a non-existant drive or directory! In addition, note that there is no "M" at the end this time.

Method 5: There is a final possibility if you are using Novell Netware: upgrade your workstations' DOS to Novell DOS 7. This operating system offers many advantages over MS-DOS, including the loading of all network drivers in extended memory, freeing conventional memory for use by application programs. Alternatively, you could try using Novell's Client 32 for DOS and Windows. If you are using Win95 workstations, you MUST use Novell's Client 32 for Windows 95.

 

Q: What can be done to increase performance in network installations?

A: The first place to look is the type and size of disk cache you are using. A high performance disk cache is essential for decent performance on both standalone and network systems. There are good, mediocre, and bad disk caching programs. The good ones include SuperPCKwik and HyperDisk; the mediocre include SMARTDRV and PCTools' PC-CACHE (versions 8 and later); the bad include Artisoft's LanCache, as well as any of the others if the write-caching option is on! Dedicate as much extended memory as possible to your disk cache. On even a small network, the cache should be at least two megabytes. (Note: Caching is pretty much automatic on Novell Netware, Windows NT Server, and IBM LAN Server dedicated server installations, so the above comments are not relevant to those using these network systems, though you should be sure that you have plenty of RAM in your fileserver).

After you get your disk caching software working, there are still some other things that you may be able to do. Basically, what you are striving for is to minimize the amount of data that must pass through the cable between your workstations and your fileserver. In order to do so, you must have local hard disks or extra RAM that can be configured as a large (two megabytes or more) RAM disk on each of your workstations. Providing that you have a local workstation hard disk or RAM disk, you can use the following settings in each station's AUTOEXEC.BAT file to assure that temporary files are written to the local machine rather than back across the cable on the file server's drive.

The example below assumes that there is a local hard drive or RAM drive, and that the letter by which that drive is addressed is C:. If it is D: or G: or M: or something else on your system, then make the appropriate substitutions. The first line just assures that there is a directory named SOS on the drive we are using for the temp files. If you are using a hard disk, there may be an error message to the effect of "Cannot create directory" after the first time, but it will do no harm to leave it in. On a RAM disk, it is necessary to create the directory again after every reboot, so the line is required:

MD C:\SOS
SET OVL_SWAP=C:\SOS\$$SOSTMP
SET CLATMP=C:\SOS

Some extremists may want to put a copy of the program files on each workstation's hard disk, including the local program directory in the workstation's PATH command, but the performance gain will not be substantial and it greatly complicates program updates. For this reason, we do not recommend that you take this step.

 

Q: How do I go about accessing my network from home or a remote site?

A: You must use a a pair of high speed modems and a product such as PC-Anywhere from Symantec or Reach Out from Stac Electronics. These programs allow you to essentially use one of the computers on the network by hooking your remote keyboard and monitor to it over a telephone line. The important thing to understand is that the computer you dial into can generally not be used for other purposes while you are connected to it. When you hang up, it can go back to its normal use as a local workstation. The remote access software puts additional demands on the available RAM, so you will almost surely have to resort to one or more of the tricks detailed above to liberate as much conventional RAM as possible on the workstation into which you will be dialing.

 

Q: All this is rather confusing. What kind of network do you recommend?

A: As of this date (March 7, 1997) we are recommending Microsoft Windows for Workgroups or Windows 95 for small networks of two or three workstations. This network system is among the easiest to install, is (by definition) capable of running the next generation of Windows-based products from SOS without modification, and current SOS products can easily be installed to run as DOS programs under Windows. Local consultants are readily available to help you set up and maintain a Windows-based network and performance is quite acceptable.

If your network should grow or you should want higher performance, it is very easy to add a Windows NT Server to the network to give you "big network" performance and features. Our primary network at SOS is based on a Windows NT Server, with workstations running, Windows 95, Windows for Workgroups, and OS/2 Warp. Performance is excellent and the network is easy to maintain. Windows 95 can be a little tricky, particularly with regards to printing, but we can almost always resolve whatever problems come up. You may want to check our fax-on-demand document 711 for details.

Novell Netware 3.1x or 4.1x is always a good choice. Novell is the standard in high performance, large scale networks, and SOS products run very well on this platform. Installation and maintenance absolutely require that you hire and make friends with a Certified Novell Engineer (CNE), however. Setting up Windows workstations on Novell can be especially tricky.

 

Q: OM and CM both require special environment and path settings. Is there any way to set this up so that I don't have to manually adjust the startup files on each and every workstation?

A: Assuming that all your workstations have local hard disks and map the fileserver's drive to the same drive letter, you can create a single BAT file on your server containing almost all the needed settings. Thereafter, you can make adjustments in one place that will affect all workstations. All users should start the program using the BAT file rather than typing the program name to automatically configure the environment, set the path, and start the program. The only SET you would need to include in the local workstation's AUTOEXEC.BAT is SET OMWS=n, where n is a numeric indicating the workstation number.

Here is an example for use with OM. The lines starting with rem are there only to explain what the BAT file is doing. You do not have to include them in your own BAT file. This example assumes that OM is installed in F:\OM:

@Echo off
CLS
rem save original path
SET SPATH=%PATH%

rem add om program directory to path
PATH=F:\OM;%SPATH%

rem create temp directory in case it does not exist
MD C:\SOSTMP > NUL

rem set all environment variables
SET OM=F:\OM
SET CLAVM0=C:\SOSTMP,128
SET CLATMP=C:\SOSTMP
SET OVL_SWAP=C:\SOSTMP\$$SOSTMP
SET TEMP=C:\SOSTMP

rem start program
F:
CD \OM
OM

rem reset to original path
PATH=%SPATH%

Q: How can I set up a Windows for Workgroups or Windows 95 peer network so that the drive letters are the same for all stations?

A: There is no question that it is desirable to have SOS products on the same drive letter for all stations, including the server. Here are some ways to do this on small Windows peer networks:

Leave the network and hardware as is. Instead, remove all drive letter references from OM's "location" fields, such as the locations of sheduling program and wordprocessing program (setup menu) and the locations of sublicenses. For example, change the location of the scheduling program from "C:\OM" to just "\OM". This change will allow each workstation to access the files on the current drive, whatever the drive letter may be.

On very small peer networks (two stations), you can use the SUBST command to alias the C: drive on the server to an alternate drive letter, eg: SUBST F: C:\ would allow you to access the contents of the physical C: drive as if the drive letter were F:. Note that the SUBST command is not compatible with Windows 32 bit file access in Windows for Workgroups, so you will have to turn that option off. Doing so will limit you to 255 simultaneously open files on the network. That is why this solution will not work with more than two workstations.

Assuming no workstations have a D: drive already, you can partition the server's hard drive into two partitions and install SOS programs on the second partition. That drive letter on the server should be mapped as D: on the other stations.