VOICE Home Page: http://www.os2voice.org
Newsletter Index
< Previous Page | Next Page >
Feature Index
|
VOICE Home Page: http://www.os2voice.org |
September 2004
Newsletter Index
|
| By Bob Mclellan © September 2004 |
Unfortunately, one of OS/2's few weaknesses is in the Workplace Shell's handling of its ini files (os2.ini and os2sys.ini). Maybe it is because OS/2 systems do not often require frequent or spontaneous refreshing that ini problems have time to show up. And because these files are so important to the operation of the system, problems in these files can result in an unusable system.
This article discusses a technique to address some of the problems that arise with ini files. The solution is not suitable for all users but many people may benefit from using it. Essentially, the idea is to always boot using the clean ini files which are created at the time the system is installed. The benefits and drawbacks of this are:
[+] Any errors that are introduced during a session are discarded at the end of the session
[+] We don't end up with very large ini files that are prone to breakage
[+] The problem of frequent, extended updates to the ini's which slow the system does not occur
[-] The main drawback is that any changes to the Workplace Shell configuration and various other items are lost at the end of the session
These benefits can also be achieved by using tools like Checkini and Peter Fitzsimmons' fix for the ini file updates. But this technique of starting with clean ini's avoids the need for these tools.
Because many of the Workplace Shell features like Program Objects, Printer Objects, FTP-PM Objects, desktop layout and more, are kept in the os2*.ini files, changes to these are lost at the end of the session. This means that any such changes should be made in a short session which updates the original ini files. That is inconvenient for systems which make frequent changes to the Workplace Shell or system configuration, so this technique is not appropriate for those systems. On systems where the configuration is stable, this process works well.
The implementation of this is quite simple. The system gets told which files to use as its ini files by two entries in the config.sys:
SET USER_INI=c:\os2\OS2.INI
SET SYSTEM_INI=c:\os2\OS2SYS.INI
These entries can point to any location where the ini files are, it does not have to be in the \os2 directory of the boot disk. If the reference ini files are stored elsewhere and copied to these locations before the Workplace Shell starts up, the integrity of the original files is preserved. This copy is achieved by a simple command file (INISWAP.CMD) which contains three lines:
ATTRIB -s -h -r c:\OS2\*.INI >NUL
COPY c:\bob\OS2.INI
c:\os2\OS2.INI >NUL
COPY c:\bob\OS2SYS.INI c:\os2\OS2SYS.INI
>NUL
The first line allows you to copy over any existing files. The 'c:\bob' directory is any directory where you permanently store the original ini files. The command file is initiated by a call in the config.sys:
CALL=c:\OS2\CMD.EXE /C c:\bob\INISWAP.CMD >NUL
You can make the commands more generic (to use on different partitions) by dropping the 'c:'. Just make sure the source files are set up for that partition.
But what if you need to permanently add a Printer Object to the system, or a Program Object, or install a new application (many of which make ini file changes), or make some other configuration change which affects these files? This introduces an interesting twist. In case something goes wrong we need to keep a backup of our starting point for a while because a problem may not show up immediately. This is done by some simple steps.
ATTRIB -s -h -r c:\bob\OS2\*.INI >NUL
COPY
c:\bob\OS2.INI c:\bob\buOS2.INI >NUL
COPY c:\bob\OS2SYS.INI
c:\bob\buOS2SYS.INI >NUL
COPY c:\OS2\OS2.INI c:\bob\OS2.INI
>NUL
COPY c:\OS2\OS2SYS.INI c:\bob\OS2SYS.INI >NUL
Put these commands in a file, SAVEINI.CMD. Additionally, because the working ini files for the system are not refreshed immediately, the best time to do the backup is on reboot after the configuration changes have been made. The backup needs to happen before the INISWAP.CMD runs and the easiest way to do this is to put another line in the config.sys. REM the line and unREM it when you want to save the ini files on the next reboot.
CALL=c:\OS2\CMD.EXE /C c:\bob\SAVEINI.CMD >NUL
CALL=c:\OS2\CMD.EXE /C c:\bob\INISWAP.CMD >NUL
Once you are confident about the changes, the backup files become less important. Maybe you will keep each generation of backups so you can revert to any level at any time. The main thing to watch for is any changes made to the config.sys that tie in with ini file changes.
I have set up a virtual disk (using ramfs) to copy the ini files into and the config.sys entries point to this ram disk. This was mostly an experiment for some other things I am doing, but it does lead to faster shutdowns, a guarantee that any changes made during the session are discarded and no need for the ATTRIB command in INISWAP.CMD. However, in this configuration it is more difficult to get the SAVEINI process to work, so it may not be suitable for everybody.
I did this using ramfs at Hobbes and the following lines in the config.sys
SET USER_INI=w:\OS2.INI
SET SYSTEM_INI=w:\OS2SYS.INI
....
IFS=C:\BOB\RAMFS.IFS /S4M /M:4M /R /CLU:8
RUN=C:\BOB\RAMDISK.EXE W:
Notice that the ini file assignments have changed. The switches on the first ramfs line are detailed in the ramfs package and are not critical to this situation. I have used them to limit the virtual disk to 4MiB and to keep the files in memory (not paged out). The second ramfs line assigns the virtual disk to partition W:. You can probably use any virtual disk driver if you want to try this variation.
This has been working well on my system for some months now.
With a couple of simple command files we can make our OS/2 system more stable. The filenames and directories that I have used here are just by way of example. Feel free to use your own naming and directory structure.
Most OS/2 users will be afflicted by ini file problems at some stage. By taking positive action from the start to minimize these problems we can ensure a long and reliable life for each OS/2 installation.
References:
|
Bob Mclellan (known to some as The Little Blue Kiwi) has been an OS/2 user since the Version 2.0 beta. He first worked on computers when they were steam driven and has since worked with many operating systems, languages and hardware types. He is interested to note that open source has returned to computing after a 30 year absence, but doubts that anyone wants the hardware 'source' also open as it used to be.
Feature Index
editor@os2voice.org
< Previous Page | Newsletter Index | Next Page >
VOICE Home Page: http://www.os2voice.org