
                                    FYI

(Note: The origin of this information may be internal or external
to Novell.  Novell makes every effort within its means to verify
this information.  However, the information provided in this
document is FOR YOUR INFORMATION only.  Novell makes no explicit or
implied claims to the validity of this information.)

          TITLE:        Troubleshooting Memory Conflicts with DR
                        Multiuser DOS
   DOCUMENT ID#:        FYI-M-1906
           DATE:        28DEC92
        PRODUCT:        DR Multiuser DOS
PRODUCT VERSION:        5.x
     SUPERSEDES:        04JUN92

        SYMPTOM:        Memory Conflicts after upgrading or adding
                        memory to system. General Memory issues such
                        as TSR compatibilities

SOLUTION

GENERAL RECOMMENDATIONS

If the version of DR Multiuser DOS being used is 5.0, make sure it
has been upgraded with the DR Multiuser DOS Business Update of
September, 1991.

If new memory has been installed, check the memory count upon
bootup, to verify that the system recognizes all the memory
available to it.

To minimize memory fragmentation, users could exit applications
frequently (e.g., before breaks, and at lunch time). Be sure to
turn the computer off daily. (If 1k is used each time a program is
loaded, eventually the total of these 1k pieces will equal all the
available memory.)

Be aware that loading something (e.g., a TSR) in CCONFIG.SYS or
AUTOEXEC.BAT will load it globally, and detract from the available
memory system-wide. If a TSR is only needed in one session, it's
best to load it via (a) a START file, or (b) a conditional line in
AUTOEXEC.BAT testing for the value of the console number (%1, e.g.,
IF "%1"=="4" CALL TSR.BAT).


APPLICATION PROBLEMS

In order to increase the free memory available to all sessions, you
can limit applications' access to memory in one of two ways:

1.    To limit access for ALL applications on the system, lower the
value of "Maximum memory per process" in SETUP. 
2.    To limit access for just one application, lower the value of
"Maximum memory desired", on the PIFED screen for that application.

To use the second approach, one first needs to determine how much
memory the application needs to run. This information is generally
available from the application documentation, or from the
manufacturer. If the user is not sure how much memory is needed, 
use the MEMSIZE command to limit the memory available. Work with
the program for a while, then limit the memsize some more. Work
with the program some more, and so forth, until the lowest limit
that will allow the program to run comfortably has been reached.
Thorough testing at this stage is essential, as an application with
too little memory available to it may load and run for a while, but
not be able to execute its more memory intensive modules.

Once the maximum amount of memory needed for an application has
been determined, run PIFED on the executable file that runs the
application. (For example, to alter the specifications for wp.exe,
one would type PIFED WP.EXE.) Each field in PIFED is explained on
pages 15-8 to 15-13 of the DR Multiuser DOS User Guide. The most
important steps would be to (a) reduce the value of the Maximum
Memory Desired field, to get it closer to the amount demanded by
the application, (b) set the Interrupt Vector Range from 0 to FF,
so that all interrupt vectors are banked out and in with the
application, and (c) alter the setting of the Program Waits in Idle
Loop field; try "NO" first, then "YES."

For large multiuser systems, the value of the Additional System
Memory Pool field in SETUP should be increased to allow for the
additional system structures required.

When an application appears to be having memory problems, here are
a few fields to check in SETUP:
- increase the system memory pool
- decrease the maximum memory per process
- choose NOT to set all upper memory to AUTOSCAN, then manually   
  disable some of the blocks which are next to blocks disabled by 
  Autoscan


TERMINAL HANGING PROBLEMS

Hanging terminals can be a result of memory shortages. The
following changes may alleviate the situation:

- In the BIOS setup, reduce the speed of all possible parameters.
- In CCONFIG.SYS, set FILES=100 and FCBS=16,16.
- In SETUP, disable those memory blocks which are next to memory  
  blocks that have been disabled by Autoscan.
- In AUTOEXEC.BAT, alter the setting of NETDRIVE. Try Remote first; 
  if that doesn't help, try Local.
- In AUTOEXEC.BAT, use MEMSIZE to reduce the memory allocation for 
  each session.
- PIFED the application, making these changes:
       -    set memory allocation down closer to amount needed.
       -    set the interrupt vector range to 00-ff, so all interrupt
vectors are swapped out with the application.
       -    answer NO to "Program waits in idle loop."  If that
doesn't help, reset it via PIFED to YES.


NOT ENOUGH MEMORY

Occasionally, when a user moves from an application in one session
to another session, anything command issued by the user will result
in a "NOT ENOUGH MEMORY" error. To determine the amount of memory
available in the TPA (Transient Program Area), type SHOW /M at a
prompt, and note the amount of DOS Free Memory. This is the maximum
amount of conventional memory that is available for any one
session. If SHOW /M shows no memory available after the user has
switched from one session to another, the user ought to (a) verify
that all existing memory is being recognized at boot time, then (b)
run PIFED on the application in the first session.


PC TERM

Occasionally, PCTERM, upon exiting back to its menu on a PC
terminal, will hang. In this case, the path is probably getting
lost on the 286/terminals, which means that the environment
variables are somehow being affected when they're stored in the
memory of the host machine. To correct this problem: 
- In SETUP: increase system memory pool; decrease maximum memory  
  per process (to about 512k).
- In CCONFIG.SYS: increase FILES and buffers (a lot); increase FCBS 
 to 16,16.


