PC World Komputer 1995 November/PCWK1195.iso/pbd/doc/tn9507.asc

Text File | 1995-06-22 | 23KB | 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.