By Frank McKenney

About The Warp Installation Notes

Caveat: the material included has been compiled from verbal comments, e-mail messages posted in public locations (e.g. the Internet NewsGroups), the occasional manual, and my own interpretations of all of the above. I do not have access to all (or even most) of the equipment and software described (I had to sell my favorite 486DX 33&1/3 with 6.7 Mb RAM, two 4300 Baud serial ports, an ESDI adapter using IRQ1, and a 108 Mb RLL+ drive), so I am unable to personally verify all of its content. While I have tried to avoid excessive jargon whereever possible, describing an OS/2 installation is a technical topic and requires a certain number of technical terms. I also make the occasional typographic eror...

...and the occasional TELEPHONE NUMBER ERROR: Hints v1.1.2 is being sent out specifically because the telephone number I supplied for the Aztech BBS in Area code (501) is NOT repeat NOT the Aztech BBS, but a (now harassed) Southwestern Bell customer in Arkansas who has been receiving odd calls that abruptly hang up. PLEASE DO NOT USE THIS NUMBER. If I obtain a correct number I will include it in v1.2.

In all cases, you should use your own best judgement as to which of the following material applies to your situation. Corrections, more detailed explanations, and additional material will be welcomed. If, for example, you see a BBS telephone number mentioned but know of an FTP site for the same information, please let me know. We're all in this together.

Note re changes: I started marking the 1.1 changes with a vertical bar at the left margin. This would have added a nice touch, but it turned out to be impractical. When I finally realized that I'd need to mark more than 75% of the document, I went back and removed them. Maybe the changes for v1.2 won't be as extensive (;-).

Note re v1.11 release: Short form: oops! Long form: I posted Hints v1.1 without realizing that I had not completed revision on a section about pausing CONFIG.SYS processing so that device driver messages could be seen. As it turns out, the technique I had used under 2.1 and 2.11 for doing this turned out (a) to be narrower in scope that I had realized, and (b) to work differently under Warp. I have removed the text, but the need for such a facility is still there. Suggestions for a workable technique would be welcomed.

One of the changes I hope to make for v1.2 is to break out a separate section for new drivers. As many of you have noted, there are a large number of problems related to drivers, and it might be easier to simply include a section devoted to driver-related problems.

Let me mention that my purpose in putting this document together was to get users operational under Warp as soon, and as easily, as possible. Consequently, I'm not concerned with making sure I have the description and location of the absolutely latest and greatest driver for the IBM XVXGA adapter. I'm perfectly willing to leave that task to others.

What I do want is to be able to provide driver information for driver-related problems that might prevent an installation or cause serious performance problems under Warp. I'll settle for any driver that will let the user successfully install and run without significant errors and with reasonable performance.

Changes, additions, and comments should be directed to rrs0059@ibm.net or mailed to:

                             Frank McKenney
                           McKenney Associates
                          3464 Northview Place
                        Richmond, Virginia  23225
                             (804) 320-4887

General Hints, Suggestions, and Warnings

I have several pieces of "non-standard" (e.g. not officially supported) hardware in my system. As a result, I had always needed to do some tweaking after an OS/2 installation before everything was running smoothly (and the Warp betas were just as bad). I did not look forward to installing Warp GA; in fact, I set aside a whole day to do it.

I was <almost> (but not quite!) disappointed when OS/2 Warp GA installed from its CD with no problems. Instead, I spent the rest of the time playing with the IBM Internet Connection software, IBM Works, and the other BonusPak applications. Result? The installation <did> wind up taking all day (;-).

However, certain configurations do run into problems installing Warp GA. I have listed a number of known problems and workarounds in the following pages to help those of you already stuck, and to forewarn those of you who might need new drivers prior to starting up. I'm hoping that this will result in more people wasting(;-) their time <running> OS/2 Warp and fewer people wasting their time pounding on walls or flaming on the Usenet newsgroups because of snags in installing Warp (;-).

Read the Documentation

Before starting your installation, read the documentation. I know, you've all heard it before. It's a pain, it takes time, and the computer and OS/2 Warp are just <sitting> there when they could be multitasking their little hearts out. I'm still going to recommend it, especially for those of you who are installing OS/2 for the first time. Specifically, you should make sure you cover: Before starting your installation, read the documentation. This includes:

The new "User's Guide to OS/2 Warp", and in particular,

  Chapter  1 - Before You Begin
  Chapter  2 - Using Easy Installation
  Chapter 14 - Solving Installation Problems
  Chapter 15 - Solving System Problems
  Chapter 16 - Video Procedures
  Chapter 17 - Using Advanced Installation
  Chapter 18 - Setting Up a Hard Disk
  Chapter 19 - Special Hardware Considerations
  The README file      (root drive of the OS/2 Warp V3 CD)
                       (Diskette ?? for the Diskette version)
  The README.INS file  (Warp Installation Diskette)
  The README.CID file  (Warp Installation Diskette)

Manufacturers' README files for any device drivers <not> included with the OS/2 Warp GA package.

(other suggestions will be welcomed).

Hardware-Specific Information

If you have owned a computer for any length of time, you're probably aware that it has internal quirks that tend to show up an the most inconvenient times. You install your new SuperFast! display adapter, it doesn't work, and you suddenly discover the world of "IRQs" and "I/O Addresses" that had remained hidden under your computer's covers for <years>... (and you wish it would go back again (;-)).

A complete description of each part of your computer is a useful thing to have around. It helps in insurance claims, and it can help you see possible sources of conflict if your machine sudddenly freezes up during Warp installation. Such a list would include descriptions of the System Board (processor, chipset, RAM, BIOS type and date), disk drives (manufacturer, model, size, interface), monitor (manufacturer, model, suported frequencies and resolutions), and adapters (manufacturer, model, IRQs used, I/O addresses used).

An organized person has this list in a word-procesing document, keeps it up to date, and periodically prints out a copy and files it. This is not the only approach; for example, many of us compile this list by waiting until we have a problem, then opening up the computer, pulling each adapter, and then searching desperately for the manual to tell us whether the IRQ is set by jumper J12-A or J16-A.

Just keep in mind that if you do run into a problem, this information will be requested by IBM OS/2 Support, and will be appreciated by anyone else you ask for assistance. Warnings

1. Before performing ANY OS/2 maintenance, including the installation of OS/2 Warp GA, be sure to have a CURRENT backup of ALL of your programs and data.

2. Before performing ANY OS/2 maintenance, including the installation of OS/2 Warp GA, be sure to have a CURRENT backup of ALL of your programs and data. This is not a typo; it is a redundant copy of my text for backup purposes (;-).

3. Have a set of <tested> OS/2 bootable diskettes ready with the usual system utilities (FDISK, FORMAT, TEDIT, etc.). Be aware that a set of (e.g.) 2.11 bootable diskettes created with BOOTOS2 will not be able to run some of the system utilities <from> an installed copy of Warp due to version level differences.

Beta Testers

Remember that warning when you received your Beta code that you would have to re-format your Beta partition before installing Warp GA? Yes, it's a pain to do. Yes, it would be nice if IBM would dedicate the resources to testing all possible combinations of Beta1, Beta2, Gamma, and Gamma+ systems with GA installed over them, but lazy as I am, I'd rather see the time spent on improving the base operating system.

It's not that GA-over-Beta is guaranteed to fail. It's that mixing various levels of similar-but-not-identical code creates an incredibly large set of possible combinations of software, and the problems that result are likely to (a) be subtle, (b) remain hidden for some time after Warp GA is installed, (c) be difficult to pin down, and (d) be highly individualized (one of a kind).

Imagine the long-term results of (say) an OS/2 INI file mangled by the Warp Beta code being passed on to Warp GA. Result: much time could be spent, both by IBM and you, in tracking down a problem that could have been avoided by a clean install. There are already enough possibilities for conflicts, don't add new ones.

Have Someone To Talk To

Finally, if you're only moderately technical but know someone who is familiar with OS/2, it doesn't hurt to let them know that you're about to start an installation and <might> be calling on them for help if you encounter problems.

And even if you <are> intimate with all the idiosyncracies of OS/2 Warp, it still doesn't hurt to have someone else to share your problems with - or to whom you can announce that you did the whole thing in 45 minutes flat (;-).

General Problem-Solving Hints

Okay, in spite of your careful reading and pre-planning, you discover that your OS/2 Warp installation is not proceeding as you expected. What should you do?

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:

   * RMVIEW (Installation Diskette)
   * TEDIT (Installation Diskette, Diskette 1)
   * CHKDSK and FORMAT (Diskette 2, or in \OS2IMAGE\DISK_2 on the CD)
   * FDISK (Diskette 1, or in \OS2IMAGE\DISK_1 on the CD)

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

Display Driver Problems

This is one of those nasty Catch-22 situations, since it's hard to do much under OS/2 if your display is not operational.

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.

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:

Start a DOS Full Screen session.
Switch to the MSWin directory (generally \WINDOWS, but mine happens to be \MS-WIN31).
Type: WINOS2 and watch the messages that appear.
If you fail to see any usefule messages, but WINOS2 exits without giving you a full screen Win-OS/2 session, start it up again, adding a /B parameter:

           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.

One common problem is having critical DLL directories left out of the active DOS PATH setting. This can be a user error or the result of an improperly modified PATH statement in the OS/2 AUTOEXEC.BAT file.

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.

Reporting Problems to IBM

The Notes...

         o Unable to find CD-ROM during install
         o Various odd symptoms with PTI IDE drive
         o Install from CD-ROM locks up
         o No sound from PAS-16
         o Unable to create OS/2 bootable partition
         o Hard Drives using OnTrack Disk Manager
         o Mouse pointer displaced - Dell
         o OS/2 hangs after installation
         o System stops booting because of problem with COUNTRY.SYS
         o Problems recognising various CD-ROM drives
         o Message - HDD Controller Failure *
         o Installation of Warp fails with SYS3175 typically around diskette 1 *
         o #9GXEPRO - problems with display esp. with Windows sessions *
         o Canon Bubblejet - unable to find printer drivers *
         o Boot message - "line ?? is unrecognizable" following MM uninstall *
         o Trap 0003 trying to use certain types of CD-ROM *
         o Warp Installation from CD fails - no matching driver found *
         o Problems using MS Windows communications programs *
         o Printer does not print *
         o Floppy drive does not recognize when a diskette is replaced *
         o Performance - Warp boot seems to take longer than expected *
         o NCR SCSI adapter not recognised *
         o MIRO 20SD - S3 864 - unable to use higher screen resolutions *
         o Various OS/2 Error Messages *

Warp Installation Notes v1.1.2