PC World Komputer 1995 November

home *** CD-ROM | disk | FTP | other *** search

/ PC World Komputer 1995 November / PCWK1195.iso / pbd / doc / tn9507.asc < prev next >

Wrap

Text File | 1995-06-22 | 22.1 KB | 382 lines

Tech Note: TN9507 Date: 20 June 1995 Revision: 1.0.0 Subject: Palindrome 4.0 Workstation issues. Scope: PBD and PSM 4.0a and 4.0b, how to set up various configurations with Windows 3.1 and 3.11. Sections: Proper Windows Workstation setup: Beyond "Workstation Requirements" Product Architecture/Windows networking troubleshooting primer. Installing 4.0 products if Windows is installed on a network. Setting up other workstations to run Control Console. Setting Console up to run off a workstation's hard drive. Assumptions: This document assumes you have read and understand the Palindrome 4.0 product manuals, especially the Installation Guide, and the Release Notes. You should also be familliar with how to set up a standard Palindrome software installation. You should also have a general knowledge and understanding of Novell NetWare, and networking DOS/Windows workstations. Proper Windows Workstation setup: Beyond "Workstation Requirements" ------------------------------------------------------------------ Overview: Workstation Requirments. In the product documentation's, Installation Guide, on page 2-4, Palindrome recommends the following workstation requirments be met for running our 4.0 software: - Windows version 3.1 or 3.11, running in enhanced mode. - 386sx w/ 4mb RAM (minimum) - 486 w/8mb RAM (recommended) - NetWare Shell version 3.32 or higher - IPXODI (not monolithic IPX) (v 3.01 recommended) - VLM shell REQUIRED if installed on NW 4.x server In addition, the following requirements must also be met: - VLM clients MUST have the NETWARE.DRV version intended for VLM clients, NOT the NETX version! - NETX clients MUST have the NETWARE.DRV version intended for NETX clients, NOT the VLM version! - Windows must have Novell networking installed/enabled. (NOT Microsoft Network) - Windows should be using the default shell (PROGMAN.EXE), NOT a third-party shell. Also also also - Tech Support has been tracking some problems with upgrades and database translation, and they are thought to be related to the use of NETX as a shell, instead of VLMs. If you are having problems of this nature, we recommend you try the upgrade proceedure from a workstation running VLMs. Product Architecture/Windows Primer: -------------------------------------------------------------------- The client side of our software works like any other Windows application. The icon launches the actual executable. The executable is PALMON.EXE, and it is located in what we refer to as "the installation directory", which by default, is \PAL. Like almost every other Windows program, the instructions in PALMON.EXE are not entirely self- contained. They "refer" to other instructions contained in a file called a DynaLink Library, or DLL. These DLLs usually have an extension of .DLL, some DLLs have an EXE extension. When PALMON.EXE is launched, it asks Windows if the required DLLs are loaded in memory, and if they aren't, Windows tries to find them and load them. This is an important concept to understand. SOME of the DLLs Palindrome uses are common to many other programs, and probably already exist on your system, and are very likely already loaded by other applications by the time you run Palindrome. The conflicts arise when the wrong DLL is loaded in memory, perhaps an older version of the file that doesn't contain code that supports a function we require, or perhaps an older version that implements a function incorrectly, or differently, or perhaps a newer version that implements a function in a way our program doesn't expect. All of these situations can cause everything from error messages, network connection failures, apparent malfunctions of the software, crashes on your Windows machine, or problems with operations on the Palindrome Databases. The incorrect modules can be present if the Palindrome install program finds that they already reside on your system, and therefore doesn't copy the version we require, or if another application has an older copy of the DLL in it's own directory, and that gets loaded before you start Palindrome. This is why it's vitally important that if you are having some of the above problems with running Palindrome on your Windows client, that you know what modules are being loaded, their versions, and which directories they came from. It's also important for you to know how our software works, and the modules we require. Some of the modules we require are shipped with our product, but some that we require should already be on any Windows machine, and some should already be on any Windows machine running on a Novell network. To say that they should be there, is not to say that they are there, and to say that they are there is not to say that the right versions are there. When Windows loads a DLL, there is a "search order" that is commonly followed when Windows is looking for the disk file to load into memory. I have found that this search order can be expected to run as follows: 1. The "current working directory" or the directory that contains the application that is launching. (in our case, this is the \PAL directory on the network) 2. If the requested DLL is not found in the current directory, the \WINDOWS directory is next, followed by - 3. \WINDOWS\SYSTEM, and then - 4. The DOS search path. You can determine the DOS search path by typing PATH at a DOS prompt, but be sure you are logged into the network, and all your search drives are mapped, and that you are looking at a "global" representation - Windows allows you to disable NWShareHandles, which means that you can set up different DOS search paths in different DOS sessions. (this doesn't have anything to do with running our software, just with making sure you see the correct search path. . .) Below is a list of DLL files we require, that ship with our product. palrsc.dll - library of Windows dialogs and text strings unique to our SW, common to our executables. pallib.dll - Palindrome resource library of functions common across our executables. pfc200.dll - another library of common functions. These DLLs ship with our product, but are also available elsewhere. smdr.dll - Novell's library supporting calls to SMS. tli_spx.dll - Novell library of TLI and SPX communications functions. tli_win.dll - Novell library of TLI functions as they apply to Windows. Other DLLs we require, these do NOT ship with our product. nwcalls.dll - These four DLLs are standard Novell libraries for networking functions. nwipxspx.dll- nwlocale.dll- nwnet.dll - For specific version information on third party files, please refer to our document: 3PFILES.ASC, which is a general listing of all files which interact with Palindrome software, where they can be obtained, how to identify them, and what to do with them. This list is constantly being up- dated, so the filename may remain the same, but it refers to a dynamic list of files that are constantly being updated by their vendors. Two of these, palrsc.dll, and pfc200.dll should be located in the same directory as the executables. If they are not in the same directory, the software may run, but not properly. Most notably, if palrsc.dll is not present in the same directory, dialog boxes may not be redrawn properly. The rest of the DLLs we require can be anywhere Windows can find them. There are, of course other files that we require, that all Windows applications require, and checking these would really be splitting hairs, they are included in Windows: olecli.dll, olesrv.dll, commdlg.dll, shell.dll, etc. NETWARE.DRV is not a DLL, it is a driver that is loaded when Windows starts up, and should only be located in the \WINDOWS\SYSTEM directory. It is absolutely essential that you have the correct NETWARE.DRV loaded for proper NetWare support in Windows. All of the above, listed DLL files are needed by our software. If they are not available our software will either not run properly, or not at all. To make sure they are available, they need to present in one of the directories listed above in the paragraph about Window's search order. If you have multiple copies in multiple directories, the copy that Windows finds first will be loaded. Two scenarios happen that can result in an incorrect DLL being loaded. In the first scenario, say APPLICATION X needs a certain version of NWCALLS.DLL, and it was installed in APPLICATION X's directory. If you run APPLICATION X, it loads NWCALLS.DLL in memory. When you run Palindrome after that, Windows will not load the correct version you checked on and confirmed was in \WINDOWS. In that case, you need to check to see what's in memory first. Novell has provided a nifty little utility called NTSWD.EXE. It's currently available in WINDR2.EXE. It is capable of displaying all the modules, drivers, and tasks running on a Windows machine, and printing out, or saving to a file, all the information. This will indicate wether the correct version of any file is loaded in memory. If you are working on a problem with Palindrome Tech Support, they may ask you for a printout or a copy of the text report from this program. The other situation that can load the wrong module is more difficult to detect, and takes some work to discover. For example, say your workstation has an old copy of TLI_WIN.DLL sitting in your \WINDOWS directory, but you are not running any software other than Palindrome that would use it. Say you also have copied the correct version of TLI_WIN.DLL into your \WINDOWS\SYSTEM directory. When you attempt to load Palindrome, Windows will look for TLI_WIN.DLL, and load it from \WINDOWS, because of the search order. If this load fails outright, then there is no way to detect which version was being loaded, other than to look into every directory in the search order for any files that we may have requested, and check the file dates to make sure they are the correct ones. If you are working with Palindrome Tech Support on a case, they might also ask for printouts of directory listings of \PAL, \WINDOWS, \WINDOWS\SYSTEM, and the rest of your directories in the DOS search path. This is where troubleshooting Windows can get a bit extreme, and the purpose of this tech note becomes a bit more clear. . . If an older version of a file is found earlier in the search order, try to resist the urge to simply delete it. It's possible some other application you run requires it. All you need to do is make sure the version of the file Palindrome needs, is copied into the \PAL directory. This will ensure that the correct version is located by Windows first, and loaded into memory. To confirm wether a file is the correct version or not, again, please refer to the 3PFILES.ASC file on our BBS and Compuserve Library. It is an up to date list of the latest files we've run across. Another factor very important to how well Palindrome 4.0 runs is the NetWare Client support for the Windows workstation. Generally, on the DOS side, this consists of Link Support Layer program (LSL.COM), followed by your MLID, which is specific to your PC's network card, followed by IPXODI.COM, followed by the shell. It's important that the LSL.COM and IPXODI.COM are as up to date as possible. Refer to our 3PFILES.ASC for the latest version information. Next comes the shell, and how this works is perhaps one of the most important factors. For 3.x networks, and mixed 3.x/4.x networks where Palindrome will be installed on a 3.x server, your shell is NETX.EXE. We require version 3.32 or later. You can determine this by logging into the network, and typing NVER <enter> at the DOS prompt. The shell version will be displayed at the bottom of the output. If Palindrome is installed on a NetWare 4.x server, we require that the workstation be running the newer generation of shells, the DOS requestor, also known as the VLM. There are several versions of VLM out there, and not all of them offer correctly, the functionality Palindrome needs. If you are protecting any NW 4.x servers, you should have NDS login enabled on your workstation. If you are protecting any NW 3.x servers, you should have Bindery login enabled. For more information, please refer to your Novell documentation. On the Windows side of networking, it gets a little more complicated. Windows 3.1 needs to install a driver called netware.drv. Which version of netware.drv is appropriate depends heavily on which type of shell you are using. If you are running Windows for Workgroups 3.11, not only do you need to have the correct netware.drv loaded, but you should not have support for Microsoft networking enabled. This, you can tell by using the Windows setup program. For example, if you are using VLMs, go into Windows setup. The fourth line should read: Network: Novell NetWare (v4.0). If it reads "No network installed", you should select the options - Change network settings. The window that comes up after that will give you several setup options for network, sharing and drivers. Select the "Networks. . ." button. The next window has more setup options, and these are the critical ones. You need to click on the radio button that says "Install support for the following network only:", and choose the appropriate Novell NetWare Network for your shell version (VLMs are v4.0). You should not select the "Install Microsoft Windows" network, and Install Windows support for additional network and have the Novell NetWare listed in the "other" box. This would make Novell support as a secondary network on that workstation, which interferes with Palindrome's ability to function properly with it's compnents on the NetWare server. You do not have to disable other WFW workstations running Microsoft Windows networking, only the workstation running Palindrome. Other workstation configuration issues: In the past, Palindrome software has been rather sensitive to the amount of conventional RAM available. With 4.0, Windows hands us as much memory as we need to get "the job" done. However, 4.0 is still a very memory intensive application, and The memory Windows hands us tends to include a large chunk of your conventional DOS memory, even though it's a Windows app. Typically, when the DOS memory starts to get too low, application launches, (our own, or other applications) will fail with a dialog box saying that system resources are very low, or low memory. Also, dialog boxes may come up with no text, or incompletely drawn. You can check Program Manager, Help-about, all you want, Windows may have tons of extented/virtual memory available, and plenty of resources left in the heaps. What the problem is, is the amount of DOS memory available. Windows requires something like 800 bytes of DOS memory to be able to launch programs. There are several things you can do to help this situation, you can use a third party memory manager to maximize the amount of conventional RAM available to programs. QEMM, or 386Max are good. MS-DOS 6.x comes with MEMMAKER, which is usually better than nothing. In Windows, you can try to keep as few other applications running as possible, eliminate any unneccesary drivers, use the "generic" Windows Super VGA driver to drive the display, rather than a display driver taylored to the specific video card. Some third-party video drivers can be real resource hogs. You can also try eliminating Windows wallpaper, and uninstalling unnecessary fonts, and probably as a last resort, start eliminating unnecessary program groups and icons. Enabling virtual memory is also a good idea. While it's best to use a permanent swap file for this, you could also try setting the swap file to NONE, then exiting and re entering Windows, and setting up a new permanent one. This will reinitiallize a corrupt swap file. Over time, a permanent swap file can become fragmented, and allocate space inefficiently. Periodically resetting the swap file may enhance performance. Using a temporary swap file eliminates the need for this, but Microsoft suggests a permanent file. Finally, there is another shareware tool, and there are many others out there like this, that try to force Windows to load it's drivers above the first meg, which keeps more conventional RAM free. This shareware utility is available on the Palindrome BBS, as filename FIXMEM.ZIP. Installing 4.0 products if Windows is installed on a network. ------------------------------------------------------------------ If your Windows installation is installed on your network, instead of on the individual workstations, this will cause problems during the install process. Generally, you'll see an error, setup cannot locate pallib.dll. There is a way around this. Before you install, determine which directory you will install into. If it's a new directory, create it ahead of time, and set up a SEARCH map to that directory. ex. MAP INS s16: = FS1/SYS:\PAL Then run the install as you normally would. That should allow you to install normally. Setting up other workstations to run Console. ------------------------------------------------------------------ There may be cases where you would like to run the Palindrome Console on more than one workstation. All you need to do is make sure all the DLL files are available to load on that other workstation. The trick here is that our install copies one of our proprietary files to \WINDOWS\SYSTEM, and that file is pallib.dll. If you simply copy that to the \PAL directory, and make sure that the rest of the DLLs and executables are available to load, and the proper versions, then this should work fine. Setting up the Console software to run from a workstation drive. ------------------------------------------------------------------ You may want to have the software copied to a workstation's local hard drive, for better performance. Here are some simple guidelines for this. Create a subdirectory on your workstation, could be any name, but best off being \PAL (the same name as the directory on the server). From the server directory containing the Palindrome installation, copy the following files to the workstation. entrndx.pac and entrdat.pac all executables, help files and dlls, (*.exe, *.hlp, *.dll) Now, create an icon for the local copy of the file PALMON.EXE, but make sure the working directory is defined as the drive letter and directory on the server where the software was installed. The entr*.pac files need to be on the workstation so that when the console is launched, it knows which installation to open. If these files are NOT on the workstation, PALMON will launch, with no installation open. If you use the File Open Installation dialog, PALMON will create two new entr*.pac files on the workstation. The arnadat.rsf and arnandx.rsf files are specific to that installation, and must be located on the server so the NLM processes can access them. The rest of the PAC files are the installation's control database and file history databases. These need to stay put, for the same reason. The NLM processes can't access them on the workstation. There will also be two or three subdirectories. \DB contains the file histories, and must stay on the server, \ATTACH contains connection information, and needs to be on the server, and \JOBS stores your custom jobs, and needs to be available on the server. The EXEs, DLLs and help files can be on both the workstation and server. Just make sure that if you have deleted the files from the server, that all the necessary DLLs are available to load when needed. Bibliography ---------------- 3PFILES.ASC - Palindrome Tech Support document listing the latest versions of third-party files our software is interdependent on. FIXMEM.ZIP - Shareware utility for optimizing Windows' use of DOS memory. NTSWD.EXE - NetWindowsStationDiagnostics, in WINDR2.EXE on our BBS and NetWire. Sources for files and information: ---------------------------------- Compuserve - GO PALINDROME Palindrome corporate Bulletin Board - 7085053336 8n1. FTP - http://www.seagate.com/software/palindrome Minor disclaimer: As of this date, Palindrome 4.0 has been shipping for about a month and a half now. This Tech Note is the compilation of the results from several investigations of some initial Tech Support Cases. These suggestions may not fix all problems and issues, however, the vast majority of new, unidentified problems seen in Tech Support over the last few weeks were found to be related to these environmental factors. If you are experiencing problems with a 4.0 software installation, and were asked to download/obtain this tech note, you should try checking as many of these factors as possible. If that does not resolve your problem, you may, of course, continue working with our tech support. Please be prepared to provide as much information as possible about your system to our representatives, so that the problem can be quickly identified and resolved. The kinds of information we generally need would be, workstation type, types of installed hardware, configuration, memory configuration, other types of software running, type of network, versions and dates of all Windows modules. Please understand that if this is a problem we have not encountered before, or that we have not yet found a cause or a solution for, that Windows on a Novell network can be an extremely complex environment to troubleshoot in, and that we will do everything in our power to make sure your problem is resolved as quickly as possible.