First, step back from the machine and take a deep breath. Better yet, go get a cup of coffee, or even take a walk around the block. If you skipped supper to get an early start, go eat.
After you finish your break, skim back over the documentation one more time. No, it hasn't changed, but <you> have. You now have more experience to relate to those dry words on paper; now they make a little more sense, and sections you skipped before suddenly take on new relevance.
Re-read your IRQ & IOA list. If you didn't already create one, now is the time; it could save you several hours on the telephone talking to IBM OS/2 Support and several days' delay before Warp is installed and ready to run. If the installation process is mysteriously hanging, and none of the problem descriptions in this document seem to fit, an IRQ conflict is always a possibility.
Re-read Chapter 14 of the "User's Guide to OS/2 Warp". This was
specifically written to address installation problems and how to
address them.
Tools and Techniques
The new boot Alt-F1 (boot to a command line) and Alt-F2 (display
drivers being installed) are not available during the initial phase
of installation. However, if you boot from the installation floppies
you are given an opportunity to exit to an OS/2 command prompt via
the F3 key. This will let you run:
I'll assume that you are already familiar with CHKDSK, FORMAT, and
FDISK. If your experience with these utilities is solely under DOS,
be aware that the OS/2 versions have additional features.
TEDIT is a text-mode line-oriented ASCII file editor. It is small
(TEDIT.EXE and TEDIT.HLP together weigh in at about 25K), but has all
of the features you need for performing emergency edits to CONFIG.SYS
from an OS/2 Full Screen session. Press F1 to open the Help file.
RMVIEW is new in OS/2 Warp, and its use as a problem determination
tool (together with the RESERVE.SYS pseudodriver) deserves an entire
section to itself, but that will have to wait for version 1.2 at
least.
Disk Partition Listing
If your problem involves disk partitioning, or is related in any way
to hard disk access, having a current and complete description of your
partition layout is esssential. The simplest way to do this is by
using FDISK to dump a complete report to a file, as in:
FDISK /QUERY >layout.rpt
You can then print a hard copy of layout.rpt to examine at your leisure, or include it in in e-mail messages to IBM or others. Be sure to add a description of how <you> plan to use the partition as well.
For example, here's part of the FDISK /QUERY report from my current setup, with comments:
Drive Name Partition Vtype FStype Status Start Size ** Boot Manager ** 1 : 1 0a 2 0 1 ** OS/2 2.11 and MS-DOS 5.0 (Dual Boot) ** 1 os2-211 C: 1 06 1 1 80 ** Warp! (no longer Gamma!) ** 1 os2-warp D: 2 07 1 81 80 ** swap partition ** 1 E: 2 06 0 162 50
Translation for undocumented flags:
Vtype: 1=Primary, 2=Logical Drive FSType: 06=FAT, 07=HPFS, 0a=Boot Manager Status: 0=Non-bootable, 1=Bootable, 2=Startable
With very few exceptions (I'll ignore my experiences with the ISA Stealth 24 under OS/2 2.1), adapters will run properly in VGA mode. This isn't the best and most colorful mode, but it will let you get work done. Warp has specific boot-time support for switching your adapter back to VGA mode; all you have to do as you are booting up is press Alt-F1 when you see the white rectangle (the "boot-blob").
If, after loading adapter-specific drivers, your display acts oddly, goes completely black, or suddenly becomes covered with randomly- colored snow and fails to respond in any recognizable way to Ctl-Esc or mouse clicks, then shut down and re-boot. As OS/2 comes up, wait for the boot-blob, press Alt-F1, and follow the instructions for switching back to VGA mode.
Can you do a clean shutdown with a mangled display? The answer, as usual, is "it depends". If the machine is completely locked up, or in a tight loop in the display driver with interrupts disabled, probably not. If OS/2 is still running underneath that odd screen, and it frequently is, try RMB-clicking on where the Desktop should be to bring up the System Menu, then pressing the D key to select the Shut<d>.own entry and pressing the space bar to answer [OK] to the WPS prompt for confirmation.
If you have DOS or OS/2 command prompts or DOS or MSWin programs
running, you'll need to press the "Y" key for each to let it complete
the shutdown process.
Other Driver-related Problems
Many of the drivers in CONFIG.SYS were supplied with a /Q ("quiet")
parameter, apparently because IBM prefers a message-less boot. If you
are experiencing problems that may be related to one or more of your
OS/2 drivers, this is not very useful.
Try adding a /V to any driver that you think might provide additional information. If it has a /Q parameter, replace it with a /V. Details for many driver parameters are listed in the Warp online Command Reference in the Information object on the WPS Desktop, but this can be difficult to reach if you are in the middle of an installation.
Problems with WinOS/2
If MSWin applications fail to start, and/or the Win-OS/2 Full Screen
object cross-hatches briefly, but nothing further happens, there may
be a simple problem with one or more of the object's drivers or one
of the MSWin DLLs.
To narrow down your search, you need more information. The text messages displayed by a WPS-started Win-OS/2 session are thrown away, but these may contain information critical to problem determination. To see the messages, do the following:
WINOS2 /B
This will create a text file containing the startup messages you may have missed. After WINOS2 exits, examine the contents of this file for additional information.
For example, I re-installed MSWin 3.1 after formatting my Warp Gamma partition. I had previously modified the OS/2-created AUTOEXEC.BAT file by adding several lines, including my own PATH setting. When I ran Warp's Selective Install to add WIN-OS/2 suport, it modified the OS/2 AUTOEXEC.BAT file to add my C:\MS-WIN31 directory to the PATH. All very reasonable...
Except that SI modified the <first> PATH statement it saw, which was
the original supplied at Warp installation. My <customized> PATH
statement, ten lines further down the file, was left untouched.
Result? I couldn't start any WIN-OS/2 sessions of <any> kind until I
went back and added C:\MS-WIN31 to my own PATH statement.
Removing Adapters
If you experience problems that appear to be hardware related, IBM
OS/2 Support may ask you to remove all non-essential adapters and
devices from your machine. I have heard remarks from several people
to the effect that doing this was pointless, since without those
adapters or devices (e.g. a tape backup unit) up and running their
system was useless, and they might as well just throw in the towel...
er, CD.
The rationale behind pulling all that hardware is not to force you to work that way forever. It is intended as a temporary measure to help get a handle on what is causing your problem. There are simply too many things that <could> be causing a given problem to allow each and every one to be explored.
A smart problem solver will try to use a divide-and-conquer aproach. If the problem is still present with all the extra hardware removed, then it is probably not contributing to the problem. If it <does> go away, then the adapters can be replaced, one by one, until the problem resurfaces. As a result, less time is spent (by both IBM and you) chasing down dead-end paths, and in most cases your problem can be resolved much more quickly.
It's all a question of getting specific information that is solid enough for you as a user to make decisions with. It's the difference between "Warp won't install" and "Warp won't install on your system as long as that 8-bit antique 9600-baud modem is installed". You may not even care about <why> the two can't co-exist if you were planning to replace it anyway. If the adapter <is> critical, you and IBM can concentrate your efforts on figuring out how to re-jumper it (manual long since lost) to make it work properly instead of trying to replace every OS/2 driver in sight.