VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Features Index]

July 2000
editor@os2voice.org

How to Supercharge OS/2 Warp -
Part 2

By Christian Hennecke ©July 2000 
    The OS/2 Files: http://www.os2world.com/os2files/

Hopefully last month's tips already boosted your machine's performance to Warp speed. There is still a lot more to improve. This month we will look at increasing OS/2's responsiveness and stability and also see what can be done in case of crashes.

This article is part of a series on improving your OS/2 system that is published in the VOICE Newsletter. Last month's article covered CD-ROM and hard drive performance. All the tips can be viewed at my homepage at http://home.foni.net/~chennecke/index_e.html by selecting the tuning link.

Again: These tips apply for the most part to all versions of Warp, unless otherwise noted. They also take into account that you might be running an old, slow machine. There may be errors or omissions that might lead to your machine blowing up. I strongly advise you to make a backup before fiddling around with your system's settings. You've been warned.

For credits please see "How to Supercharge OS/2 Warp - Part 1" in the June 2000 issue of the VOICE Newsletter.

3. Responsiveness and stability

In the following some changes to your CONFIG.SYS and the OS/2 INI files are suggested. Remember that you have to reboot (or restart the WPS in case of the INI files) for the changes to take effect.

3.1 Multitasking

The MAXWAIT=x 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 typing this file in the IBM Works word processor in the foreground, the word processor gets priority to access the hard drive. In reality, the download should be getting priority access to 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 it out and see.

3.2 Access privileges

The IOPL=YES 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 seems to require privileged access is TeX. At least emTeX's installation guide contains a CONFIG.SYS example that lists IOPL=YES.

3.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. This will only restart programs that are in your startup folder, and only upon rebooting, not when the Desktop resets itself.

3.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 inconsistencies 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 beforehand. Otherwise WPS classes that are still needed could get 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 today's 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.

3.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 tool 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.

3.6 Motherboard BIOS

OS/2 has some built-in mechanisms to cache the BIOSes of your hardware. If your motherboard's BIOS is setup to do this caching/shadowing there might be conflicts leading to an unstable system. So try to turn shadowing off in your motherboard's 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.

3.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.

So we have come to an end again. Next month we will look at quite some opportunities to reduce RAM usage and get back some bytes.

Christian Hennecke is a student of geography from Germany and has been working with OS/2 for five years now. Two years ago he started an OS/2 informational homepage that meanwhile also contains an extensive XFree86/OS2 section called "The X11-Files" as well as information about e.g. emulation on OS/2.

Features
editor@os2voice.org
[Previous Page ] [ Index] [Next Page ]
VOICE Home Page: http://www.os2voice.org