Main text
Responsiveness and stability
1. Multitasking
The MAXWAIT= setting in the CONFIG.SYS file determines how many seconds a process will be put
on hold before OS/2 will raise its priority on its list of things to do. To make your system more responsive, you
should try changing this number. This change may speed things up at the expense of more program overhead, because
the scheduler has more work to do. The optimum is dependent on how much CPU power your machine has. So if you have
a slow machine decreasing the parameter might as well slow your machine down even more.
For Pentium class machines beginning with about a P90 the minimum of 1 is the way to go. A 486DX2/80 or 486DX4/100
should fit into the category of 1-2. If you have a 486DX2/66 or slower try 2 or three. In some cases, e.g. slow 486
or 386 machines, increasing the number to 4 or 5 might actually help. Try it out for yourself, since every case is
different.
The PRIORITY_DISK_IO=YES statement in your CONFIG.SYS file will give hard drive access priority to any program running in the foreground. What this means is that while I am doing a download in the background from Hobbes, for example, and saving a file in the IBM Works word processor in the foreground, the word processor gets a priority boost for a short time after accessing the hard drive. My experience has been that setting this parameter to NO makes my system multitask more smoothly than with the default of YES. Try and see.
2. Access privileges
The IOPL= parameter of the CONFIG.SYS file apparently gives certain older devices privileged
access to the input/output of OS/2 if they need it. This might lead to situations where OS/2 becomes unstable and
crashes. Unless you have an older Laserjet printer, you can probably change this line from its default of
IOPL=YES to IOPL=NO. This will make your OS/2 system more stable and crash-proof.
In some cases you might want to set it to IOPL=FXPRINT, to use the FaxWorks program as an example, if you
have just certain software that requires privileged IO. Many people have said that for FaxWorks to run properly it
needs the IOPL parameter set to FXPRINT. I personally have set IOPL=NO and it works just fine. Other
software that claims to require privileged access is emTeX. At least emTeX's installation guide contains a
CONFIG.SYS example that lists IOPL=YES. Further investigation reveals that his is only necessary
if you want to use dviscr or if dvipm is configured to change the VGA- or 8514/A-palette for better greyscale
display. On today's machines this is obsolete.
3. At system startup
The reason that programs that were running when you shut down restart when you reboot is because IBM setup the
default OS/2 configuration to do just that, on the assumption that people always use the same applications on every
restart. While this is a good thing if you do use the same software, it also brings up a potential dangerous issue.
Imagine that a program crashes so hard that the system also goes down. If that program gets started again upon
reboot it will be restored with the same settings. Now, if these settings create the situation that lead to the
programs initial crash OS/2 will be caught in a vicious circle.
You can bypass this by pressing Left Ctrl/Left Shift/F1 as soon as you see the alarm clock when your Desktop starts
to load. Keep holding the keys until all the icons have appeared on the Desktop, and then you can let go. If you
find that you don't like having your programs restart at every reboot, then you will have to add the line
SET RESTARTOBJECTS=STARTUPFOLDERSONLY,REBOOTONLY
to your CONFIG.SYS file. Then reboot for this change to take effect. This will only restart programs that are in your startup folder, and only upon rebooting, not when the Desktop resets itself.
4. INI files
You may have noticed an increasing slowdown in the WPS's behaviour after having worked with it a while,
deleting and moving objects as well as installing and de-installing programs. A "while" will generally
last weeks or months in this case. The reason is that the WPS creates a so-called object handle in the
OS2.INI file for each object that is created, but if you delete an object the WPS forgets to purge the
related object handle from the file again. (Note: There is a difference between Warp 3 and 4 in this case. Warp 3
only creates handles for certain objects.) Also lots of programs either don't come with a de-installation
routine at all or they simply forget to remove entries they added to the INI files on installation. That leads to
myriads of dead, obsolete entries clobbering up the INI files that get bigger and bigger.
Luckily, help is near. Get Henk Kelder's WPTOOLS
package (there is also a commercial package available called UniMaint that also contains other desktop maintaining
tools). The contained tool CHECKINI is able to detect all the dead handles and several unconsistencies and
errors and to correct them. Try CHECKINI /C. (Note: In case you are using multiple CONFIG.SYS
files and you are uncertain about used WPS classes, reboot to a maximum configuration before. Otherwise WPS classes
that are still needed could be deregistered.)
To get rid of superfluous INI entries you have to open OS2.INI with an INI file editor like
REGEDIT2 that comes with Warp 4 or one of the several others you can find at Hobbes or LEO. Then scan the file for entries you suspect to be related
to de-installed programs and delete them.
WARNING: Always be sure to backup your INI files before editing them. Note that they
are hidden system files.
OS/2 has a habit treating the INI files that can get very annoying, as it periodically leaves the system in an
unresponsive state. Since OS/2 2.1 the INI files OS2.INI and OS2SYS.INI are kept in swapable
memory. Now if you make any changes to the WPS or some system entries an update becomes necessary. Every 2-5
minutes these changes are committed by writing the entire INI files to disk. These write operations bypass the file
cache and are done in chunks of 32K or less. With an INI size of 1.2MB about 40 write operations are needed.
Additionally the way they are done forces a complete update of all disk structures after each write operation and
all this is done with very high priority. Originally this design intended to decrease the risk of data loss, but
the sheer size of todays INI files makes it very ineffective, also in terms of security.
This is where a patch by Peter Fitzsimmons' comes in. This patch is
applied to PMMERGE.DLL and redirects the calls normally made for opening the INI files to a new DLL. This
new DLL intercepts those calls, filters out the "don't use the cache" flag and hands them on to
DOSCALL1. Now the files will be written in a single operation using the cache and the disk structures will only be
updated once, too. Since I have applied the cache I have never seen the system get blocked by INI writes again.
There is no runtime performance penalty, only a very slight load time impact.
5. Countermeasures against hanging processes
Since fixpak 17 for Warp 3 IBM has implemented some additional crash protection features. To activate for Warp 3 them you need to add a
SET PM_ASYNC_FOCUS_CHANGE=ON x
statement to CONFIG.SYS with x being an optional parameter that specifies the time that is waited for a focus change in milliseconds. The default value is 2000. If you have Warp 4 open your System object, go to the User interface tab and activate Activate asynchronous focus change. The number below corresponds to the x parameter, but this time in tenths of a second.
If an OS/2 program runs into a problem and will not respond, you should always try the Ctrl-Esc key combination to try and bring up the window list. Doing this, in many cases, will detect a failed application and give you the option to terminate it. Sometimes it might take as long as 1 minute for the system to respond. If this fails, try cycling between Ctrl-Esc and Alt-Esc, as this combination will get a higher priority from the operating system than Ctrl-Esc will. If all else fails,try a "warm boot", which is the Ctrl-Alt-Del key combination (computer version of the Vulcan Neck Pinch <grin>). OS/2 will intercept this key combination and try to close as many open files as it can before actually rebooting. If you reach over and just flick the reset button on your PC instead, then you stand a good chance of corrupting data files, or even worse, corrupting your precious OS2.INI and OS2SYS.INI files. You will also have to endure a CHKDSK upon rebooting.
An even better alternative is to use WatchCat. This program can be used to terminate badly behaving processes. However, WatchCat in its raw form isn't capable of much more than standard OS/2 itself. But it is extensible with one of the freely available extension DLLs (archives WKILL9 and WNICE on Hobbes and LEO) that interface the XFree86/OS2 support driver and facilitate its extended access capabilities. Of course you will have to install the driver. To use it with Warp 3 you will need at least fixpak 17. This will allow you to kill even some badly crashed programs.
6. BIOS
OS/2 has some built-in machanisms to cache the BIOSes of your hardware. If your motherboards BIOS is setup to do this caching/shadowing there might be conflicts leading to an instable system. So try to turn shadowing off in your motherboards BIOS.
If you note frequent hard crashes where only pressing the reset buttons helps and data gets corrupted, you may be experiencing RAM problems. OS/2 is very picky about hardware. Try to lower the settings for memory access in your motherboard's BIOS and see if that helps. It also might be a good idea to exchange the RAM cards.
7. Miscellaneous
If you ever need to pause the screen when booting up Warp to see something, you can insert bogus device drivers at strategic points along the way. A simple DEVICE=STOP should do it.
Many people have told me that their systems ran more smoothly, and that they had more available RAM, after they de-registered the IBM Works package from the Work Place Shell. You can try this yourself by using a CMD file provided with the Works program. At an OS/2 command prompt, change to the IBMWORKS directory. In this directory are two related CMD files. One is named IBMWDESK.CMD, and will register the IBM Works programs with the WPS. The other file is called IWDEREG.CMD, and will de-register all the IBM Works component programs with the WPS. After de-registering you will still be able to use the Works programs, but you will find that their inter-operability will be hampered. If you use these programs as stand-alone software, and don't need to use drag-and-drop between them, then this might be an easy way to speed up your system. If you decide later on that this was not a good idea, then you can always reverse the process by running the IBMWDESK.CMD file, which will restore all the proper links between programs. Please note that after running either file, that it will be necessary to shut-down and reboot in order to finalize all the changes that were made.