Applying Service to OS/2 Warp

Applying Service to OS/2 Warp

Version 1.00

April 22, 1997

Copyright (c) 1997 by Frank McKenney
All rights reserved.

This document may be freely redistributed as long as it remains intact, including the Copyright notice, and no financial gain is realized from it.

Table of Contents

Statement of Purpose

System maintenance chores are a necessary evil, about on a level with cleaning out a stopped-up kitchen sink. The time spent preparing for them, installing them, and cleaning up afterwards is time most of us would rather spend doing something else (anything else (;-)). I have not been able to develop a technique for completely avoiding these chores, but I hope this document will help other users get some of them done a little faster, and with fewer complications.

Applying Service to OS/2 Warp was created to give OS/2 users and support personnel a brief introduction to the IBM PSP Service process as currently applied to the OS/2 operating system, and to point out common pitfalls one might encounter in applying service to an installed copy of OS/2. It also addresses some specific problems which may surface after Warp 4 FixPak 1 is applied, providing workarounds where available.

I should note that my interpretation of what constitutes a "problem" is somewhat more liberal than many vendors' definitions. For the purposes of this document, if a user experiences an interruption in his/her/its work, that's a problem. In one specific case, for example, it appears that a bug was fixed, but the fix rendered drives which were "adapted" to the bug inaccessible. In other words, when this fix was applied, users experienced an apparent data loss, as well as the loss of time and effort to correct the situation. To me, this is a problem, as is an inadvertent "Probable User Error" caused by unclear documentation.

Where links to other sites and resources appear I have used the address (URL) itself as the link text rather than hiding it behind a shorthand text description. This was deliberately done to ensure that a hard copy of this document would be almost as useful as the live 'web version.

[Return to Table of Contents]

Caveat

Much of the following material has been compiled from discussions with fellow OS/2 users, private e-mail, messages posted in public locations (e.g. Usenet newsgroups), and various sources of documentation, both online and offline. I do not have access to all (or even most) of the equipment and software mentioned, so I am unable to personally verify all of this document's details.

In all cases, you should use your own best judgement as to which of the following material applies to your situation.

[Return to Table of Contents]

The Service Process - an overview

It's easy to learn about the joys of computer ownership. Just pick up any magazine or newspaper these days and you'll see articles about how Your Computer Can Give You (choose several): Instant Access to Stock Market Information, Direct Ordering, "'Web Surfing", and, of course, The Latest in Real-Time 3D Multi-Player Gaming With Direct Video and Full-Surround Sound. It's a lot harder to find an article which talks about the "dark side" of computer ownership: the time, effort, and money it will take to keep all this new technology running smoothly. Some of these new responsibilities fall into the category of Software Maintenance.

Software does not, strictly speaking "wear out"; unfortunately, this does not mean that it will never need replacing. New ways of using a given piece of software may uncover previously unknown problems, or elevate a known problem from being "ignorable" to "requiring a solution". A change in the software environment, such as connecting a standalone desktop to a LAN, may uncover problems, as may replacing a disk drive with a "compatible" unit or upgrading the entire system.

For small, self-contained applications this "maintenance" may involve no more than copying one or two files onto a hard disk. Changes to large applications are somewhat more complex, since they may require updating many files in different locations. In the case of operating systems (OS/2, MSWinXX, Linux, etc.) not only may hundreds of files be involved, but some of the files needing replacement may be critical system files which cannot be replaced while the system is running.

Someday the computer industry may slow its headlong pace to the point where hardware remains stable for more than six months at a time, and even complex software applications and operating systems will ship with few or no bugs. In the meantime, as long as hardware and applications continue to change to meet new user demands, some form of operating system software maintenance will be required. I think J.M. Straczynski's words may express it best:

"It's an imperfect world, ...and we never get exactly what we want. Get used to it."

[Return to Table of Contents]

What does "Applying Service" mean?

In simple terms, applying service means updating your system with fixes from IBM.

Applying service to an IBM PSP program product, such as OS/2, is the process of making modifications to one or more components of that program product. This may involve any of the the following:

FixPaks exist for products other than OS/2 (e.g. "LAN" FixPaks). However, as I intend to focus on one specific group of PSP products (the OS/2 operating system) rather than PSP products in general, I will be treating the terms "system" and "product" as equivalent for the purposes of this document.

Further, while individual fixes and various types of FixPaks exist for OS/2 Warp 3 and 4, no ServicePaks have so far been released for any version of OS/2 Warp. In this document I will be concentrating on Warp Base FixPaks, the kind of service most OS/2 users are likely to encounter, and the PSP Corrective Service Facility (CSF), the means by which Base FixPaks are applied to a copy of OS/2.

All of the Base FixPaks released for Warp 3 and Warp 4 have been cumulative, that is, Warp 3 FixPak 26 includes all of the fixes from Warp 3 FixPak 17. This is good, because it removes one possible source of service-related problems: interactions between multiple FixPaks applied to the same system. However, since CSF was originally designed to handle multiple, independent FixPaks, some of its features may seem a little odd in terms of the current situation.

While each FixPak is given a unique identifier (e.g. XR0M001 for the English-US version of FixPak 1 for Warp 4), you will frequently encounter shorthand ways of describing a FixPak. Warp 4 FixPak 1, for example, is frequently referred to as Warp 4 FP1, W4FP1, FixPak 1 (where Warp 4 is assumed), or just FP1.

[Return to Table of Contents]

What happens when you apply a Base FixPak?

The Corrective Service Facility software will scan your system looking for copies of OS/2 to service. If more than one copy of the right version of OS/2 ("serviceable product") is detected, the user may be prompted to select where service should be applied. Next, copies of the current versions of files which are about to be replaced are saved in case they are needed later. Those files which can be replaced while OS/2 is running are updated, and the remaining files are queued for "locked file processing" so they will be replaced the next time the system is rebooted.

[Return to Table of Contents]

What are the Archive and Backup Directories for?

The key principles underlying the Corrective Service Facility (CSF) design are reliability and recoverability. The Archive and Backup directories maintained by the CSF software are designed to ensure that, as long as you play by the rules, your system can always be returned to a "known" state: the state the system was in prior to any service being applied. In the CSF documentation, this is known as the Base level of service. Since the files necessary to return the system to this state are stored by CSF in the Archive directory for this product, it is also referred to as the Archive level.

When a later FixPak is applied to the same system, a Backup directory can be created which will hold the "original" copies of files serviced by the later FixPak. This allows the system to be restored to its previous service level, rather than having to go all the way back to the Base service level. Either of these is preferable to a complete reinstallation of Warp and the accompanying loss of system configuration information and customization work.

Let me illustrate this with a hypothetical example using Warp 3. The system is first installed, then later FixPaks 10 and 17 are applied. Problems with FixPak 17 required its removal, and it is backed out. Later FixPak 22 is installed, then all applied service is removed (this is a Backout to Archive Level). Finally, FixPak 26 is applied.

Action Operating Level Archive level Backup level
Installation Base Level -- --
Apply FixPak 10 FixPak 10 Base Level --
Apply FixPak 17 FixPak 17 Base Level FixPak 10
Backout to Backup level FixPak 10 Base Level FixPak 10
Apply FixPak 22 FixPak 26 Base Level FixPak 10
Backout to Archive level Base Level Base Level --
Apply FixPak 26 FixPak 26 Base Level --

If a Backup directory had not been created and used, then when problems were seen with FixPak 17, the only choice would have been to Back out all the way back to the Base Level of service.

This process is described in much more detail in the CSF README.INF file.

[Return to Table of Contents]

How are Base FixPaks Installed?

Currently there are two general approaches to installing Base FixPaks. The first is to download diskette image files (or obtain them from another source) and create diskettes; the second is an automated procedure using an OS/2 'web browser such as Netscape/2 or WebExplorer.

Both methods require free space on a hard drive for the FixPak replacement files and for archiving the old copies of those files. The diskette-based methods involve more effort, since diskettes have to be created from the image files; the RSU method is more convenient but requires more disk space.

[Return to Table of Contents]

Installing a FixPak via Diskettes: SERVICE and FSERVICE

FixPaks for current Warp 3 and Warp 4 FixPaks are provided as a set of diskette images and related text files. These updates can be applied to a copy of Warp using the Corrective Service Facility software, also provided as a set of diskette images. Using the CSF diskettes, the updates can be applied through an interactive program run from an OS/2 command prompt (SERVICE.EXE), or by booting a mini-OS/2 system from a set of diskettes and using a script file (FSERVICE.EXE). These two methods are generally referred to as the SERVICE and FSERVICE methods for applying fixes.

Both sets of diskette images can be obtained from IBM-maintained sites on Compuserve, TalkLink, Internet, and Prodigy, and other locations. Full details on these sites, as well as a complete list of PSP products and current Service Levels can be obtained from http://ps.software.ibm.com/pbin-usa-ps/getobj.pl?/pdocs-usa/psprod.html. This page includes a 700-row table, so it may take a while for your browser to display it.

The diskette images can be obtained by using a 'web browser, or by anonymous FTP from one of the directories on the IBM PSP FTP site, such as:

For more information about the Corrective Service Facility, review the README.INF file on CSF Boot Diskette 1.

[Return to Table of Contents]

Remote Service Updates: FixPaks via the 'web

Alternatively, you can have a FixPak downloaded and installed for you over the Internet. This Remote Service Update feature applies the same set of fixes by adding a software management layer on top of the CSF software to automate the transfer and installation functions. RSU installation is available for the latest Warp 3 FixPaks and Warp 4 FixPak 1, and requires only an Internet link capable of FTP and 'web transfers and sufficient disk space.

From the user's point of view, this is a much simpler process: connect to a 'web site, step through a few 'web pages, and start the install. No diskettes to create and label, and you can view the README.1ST file while the FixPak files are being downloaded. If you get disconnected, just start the process over again; the transfer management software will be re-transferred, but it will detect any completely transferred FixPak files and not re-transfer them.

Dick Kurtz (IBM Fix Distribution) has put together a description of the Remote Service Update procedure and some suggestions on adapting it for use over a LAN, for example. You can extract a copy of the document (OS2SERV.INF) from the RSU support package at ftp://service.boulder.ibm.com/ps/products/os2/rsu/rsucsf.zip.

Note: Some Display Driver FixPaks are also available via an RSU update.

[Return to Table of Contents]

Other Ways of Applying Service

If you are already using IBM's Configuration Installation Distribution (CID) process, you can also use CID to install OS/2 FixPaks. Instructions for accomplishing this can be found in a file named README.CID on the first FixPak diskette.

Several users have found ways of using a diskette or a "virtual" floppy disk as a staging area for loading the FixPak diskette image files to a hard drive. This avoids having to actually create the diskettes, and speeds up the SERVICE / FSERVICE process considerably.

[Return to Table of Contents]

Common considerations

Regardless of the installation method you choose, you will have certain resource requirements to consider:

[Return to Table of Contents]

To Apply. or Not to Apply. That is the Question...

There are many attitudes toward applying Base FixPaks. Some people simply apply every FixPak they can find, released or unreleased, while others go to an opposite extreme and avoid even those FixPaks which have been recommended for all users. Your decision will also be affected by whether you're maintaining one lightly-used and well-backed-up system or responsible for a go/no-go decision which will affect ten machines... or a thousand.

Hardware is evolving, as is firmware (BIOS) and software. New combinations of each, of old and new, are created on a daily basis. The results of making a change (any change) to a given system cannot easily or completely be predicted. The best I can hope to do here is offer a way of approaching the problem.

Reasons For Applying:

Reasons to Avoid Applying, or to Proceed Cautiously:

If you are familiar with the FixPak installation process (including how to back one out), have some free time, and have a complete (and tested) system backup on hand - or the willingness to reinstall in the event of serious problems - then you may well install a FixPak "just to see if it feels better".

On the other hand, if you're new to OS/2 maintenance (or possibly new to OS/2), don't have a system backup, and have no access to any OS/2 technical expertise, I'd recommend not applying unless you have a strong reason to do so. For someone in this position, I'd consider "My system TRAPs twice a day and there's a confirmed fix in FP87" a strong reason. On the other hand, if the reason were more on the order of "My system seems a little sluggish and FP72 might make things better", I'd recommend not installing.

Look at what you have to gain, evaluate the possible risks, and make your decision.

[Return to Table of Contents]

Applying a FixPak

I have somewhat arbitrarily divided up the installation process into three phases: planning, application of service, and post-installation cleanup. Of the three, the planning phase is by far the most important.

[Return to Table of Contents]

Planning

Planning is a form of insurance. You invest some time and effort up front with the hope of avoiding a much larger investment of time and effort later. The following checklist is not as extensive as a pilot's pre-flight list, but it serves a similar purpose.

[Return to Table of Contents]

Apply Service via CSF Diskettes

There are two sets of diskettes required to apply service. The first are the CSF Boot Diskettes (also referred to as the Corrective Service Boot Diskettes or "kicker" diskettes). These diskettes contain all the files necessary for booting a copy of OS/2 plus the CSF software which will perform the required maintenance. These diskettes have machine-readable labels of SP DISK 1 and SP DISK 2 .

The other diskettes are the FixPak Diskettes (also referred to as the Corrective Service Diskettes or CSD Diskettes). These have machine-readable labels of CSF DISK 1 through CSF DISK n , and contain the files which will actually be installed on the serviced system.

Currently both sets of diskettes are provided as diskette image files, usually with a suffix of .DSK or .nDK. The LOADDSKF utility program, needed to create 3.5" diskettes from the image files, is found on your Warp CD. A copy can also be transferred from the IBM FTP site where the FixPak diskettes were found.

SERVICE and FSERVICE are described in more detail in the Installation Instructions file under Method 1: Install from booted OS/2 partition (SERVICE) or the section Method 2: Boot from Corrective Service Disk 1 (FSERVICE).

[Return to Table of Contents]

Apply Service via RSU

For Warp 4 users, the process starts with the Warp 4 Software Updates object in the Assistance Center folder, which starts WebExplorer v1.2 and takes you to the IBM Personal Software Product Service Listing (http://service2.boulder.ibm.com/pspfixpk). Warp 3 users can simply point WebExplorer at this URL.

Before using RSU for the first time you will need to update your OS/2 'web browser (WebExplorer/2 or Netscape/2) to handle Remote Service. Click on the Software Updates link on that page to obtain instructions and to download the appropriate files.

Once the changes have been made, select the appropriate FixPak link to begin applying service.

Notes:

[Return to Table of Contents]

Post-installation Cleanup

Check your service log (\OS2\INSTALL\SERVICE.LOG) to see if there are any errors you might have missed. If you were using the Remote Support Update method for applying your Base FixPak, you should also check \OS2\INSTALL\FTPINSTL.LOG and \OS2\INSTALL\RSUINST.LOG.

After a few weeks, if you have not experienced any problems, you can free up the disk space used by your CSF Backup directory (if one was created) by using SERVICE (or FSERVICE) to COMMIT the latest changes.

[Return to Table of Contents]

If You Experience Problems...

Backing out is the process of removing a set of fixes and returning the system to its pre-fix state. If you have followed the CSF rules, you can remove all service which has been applied to your system (Backout to Archive level), or just remove the latest set of fixes which were applied (Backout to Backup level).

All routes used to apply a FixPak update the same data structures in the same way, so theoretically you could use FSERVICE to backout fixes which were applied via an RSU, or use RSU to Uninstall fixes applied using SERVICE. However, there are some limitations you should be aware of.

[Return to Table of Contents]

Backout using SERVICE

To use this method for removing service, you will need the CSF Boot Diskettes, FixPak Diskette 1, and an OS/2 command prompt.

Start SERVICE.EXE as if you were going to install a FixPak and insert FixPak Diskette 1 when prompted. Once the system has been scanned for SYSLEVEL files, click on the [Change product list...] button and select either the Archived products list or the Backed up products list as appropriate. The list of available products will change, and the button in the lower left corner of the Corrective Service Facility window will change from [Service] to [Backout].

Select the correct product and click on the [Backout] button. After a pause you will see the Corrective Service Facility - Backout window appear showing your selected product. Click on the [OK] button to proceed with the backout. Backing out for files which are "locked" will be deferred until the next reboot, just as they were when the FixPak was applied.

[Return to Table of Contents]

Backout using FSERVICE

The SERVICE route for backing out service is appropriate when your system is basically operational. If you experience problems which prevent you from being able to boot your system, you will need to use FSERVICE instead.

This route requires that you have copies of the CSF Boot Diskettes and FixPak Diskette 1, but no OS/2 command prompt is needed. Instead, the CSF Boot Diskettes are used to boot a copy of OS/2 with a specialized CONFIG.SYS file which automatically starts FSERVICE.

By default FSERVICE takes its control input from a file named RESPONSE.FIL on CSF Boot Diskette 2. Assuming Warp 4 is installed on C:, a control file similar to the following would be used to back out service to the Archive level:

  * Response file to back out XR_M001 on C:

  :LOGFILE C:\OS2\INSTALL\SERVICE.LOG

  :TARGET ARCHIVE

  :BACKOUT

  :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2

Boot from CSF Boot Diskette 1 and insert CSF Boot Diskette 2 and FixPak Diskette 1 when requested.

Tecnical Note: The mini-OS/2 system on the CSF Boot Diskettes has a minimal set of hard disk drivers, but includes the BIOS Int 13h driver IBMINT13.I13. Since OS/2 cannot currently be installed onto, or booted from, a partition which is not Int 13h-addressable, this should not present a problem.

[Return to Table of Contents]

Backout using RSU

The RSU FixPak Installation window provides an Uninstall button which can be used to backout service. However, the current RSU implementation has several limitations which make this generally less desirable than using SERVICE or FSERVICE:

[Return to Table of Contents]

Frequently Asked Questions about FixPaks

Most of the following questions appear with amazing regularity every time a new Base FixPak is announced. Some may seem obvious to those who have already installed one or more FixPaks, but Usenet postings indicate that there are a large number of OS/2 users who have never applied service to their systems before. And even experienced users may appreciate a "refresher" if they have managed to successfully avoid applying service for a while(;-).

[Return to Table of Contents]

How can I find out what fixes are included in a Base FixPak?

Each FixPak includes a text file listing the APARs whose fixes are included. For Warp 4 FixPak 1, for example, this file is available for separate FTP as xr_m001.rm2, but it is also included on XR_M001 Diskette 1 as README2.

[Return to Table of Contents]

How do I know what FixPaks have been applied?

Check the contents of \OS2\INSTALL\SERVICE.LOG. This file is used by CSF to record its activity and any problems which are detected. For example, the following command will generate a list of Base FixPaks which have been installed through CSF:

FIND "OS/2" \OS2\INSTALL\SERVICE.LOG

You can also check the current internal revision level by using the VER /R command.

[Return to Table of Contents]

How much disk space will I need?

This information is usually provided in the Installation Instructions for a given FixPak (README.1ST, XRxxxxx.RM1). If your free disk space is limited, use the FSERVICE installation method, since it has the smallest requirements. The SERVICE method requires additional space for locked file processing, while RSU requires space for both the FixPak package files (ZIP) and their extracted components.

[Return to Table of Contents]

How can I recover the disk space used by my Archive directory?

You can free the space used by your CFS Backup directory by using the Commit feature. However, since the contents of the Archive directory are intended to be used to restore OS/2 to its state prior to any service being applied, Commit will not delete the contents of the CSF Archive directory.

You can move an entire Archive directory to another drive, either local or on a server. If you do this, be sure to use the SERVICE Redirect button for Archived Products or the FSERVICE :REDIRECT tag to update the pointer to the Archive directory. Details on Redirection can be found in the CSF README.INF file.

Alternatively, as long as you make sure the files are back in their original location before applying any further service, you can:

Finally, you can find instructions for deleting the FixPak Archive (and Backup) directories in the XR_W026.TIP file provided for Warp 3 FixPak 26. The instructions are preceded by a warning of the consequences of doing so.

[Return to Table of Contents]

Should I apply "controlled" and "prerelease" FixPaks?

PSP makes a distinction between "released" FixPaks, which have been given fairly heavy testing (often including a limited customer release for this purpose), and "controlled" FixPaks, which have not been as extensively tested. "Released" FixPaks are put up on PSP FTP sites, CompuServe, etc. and can be obtained by anyone with a connection to an IBM-supported site (or with a friend willing to obtain the diskette images for them). "Controlled" FixPaks, on the other hand, are only made available through OS/2 Support, and only to customers who report experiencing a problem which that FixPak addresses.

And there are "prerelease" versions of FixPaks which are provided to selected customers for testing purposes, but which occasionally escape. Several different versions of Warp 4 FixPak 1 "escaped" during the course of its evolution into a "released" version, for example.

My recommendation: Stay away from any FixPaks other than those which have been "released", and only apply those when you believe the payback will justify the risk and effort.

[Return to Table of Contents]

Can I pick up FixPak diskettes from Hobbes and other sites?

Over the years, sites such as Pete Norloff's OS/2 BBS and the NMSU Hobbes OS/2 file repository have provided invaluable support and assistance for OS/2 users. In many cases they have offered users access to files which were not available from any other source. However, and with absolutely no intent to criticize any of these sites, I strongly recommend against using FixPaks, or FixPak related files, from any location other than an IBM supported or IBM recommended site.

There are several reasons to always obtain your fixes directly from an IBM-supported site.

Finally, there is always the small but very real possibility of a virus being accidentally picked up as files are cross-loaded from one site to another.

[Return to Table of Contents]

What is the procedure for backing out part of a FixPak?

The saved copies of the various files replaced by the CSF software are stored using a utility called PACK, and can be retrieved using the UNPACK command. In order to back out one or more single files which were updated by a Base FixPak, you need to know the following:

Assume that Warp 4 is installed on D:, the Archive directory specified when XR_M001 was installed was F:\W4ARCHIV, that there is no Backup directory, and that you have an OS/2 command prompt already open.

For more information on how to use the UNPACK command, see the Warp online Command Reference.

[Return to Table of Contents]

Why can't SERVICE find my \OS2\ARCHIVES directory?

The quick answer is that you generally don't want it to.

The Archive directory used by the Corrective Service Facility is used to save old copies of OS/2 device drivers, DLLs, and other files which were replaced by newer versions when a Base FixPak was applied. The actual name of the CSF Archive directory is chosen by the FixPak installer or assigned by the installation software. The RSU default name for the Archive directory for Warp 4, for example, is \ARCHIVE\OS2\XR_4000.C.

\OS2\ARCHIVES, on the other hand, is used by the Workplace Shell to save copies of your WPS Desktop directory and certain critical system files (CONFIG.SYS, AUTOEXEC.BAT, etc.). As long as the Desktop Properties' Create archive at each system startup option is checked, a copy of the Desktop directory structure will be written to \OS2\ARCHIVES each time the Workplace Shell starts up.

Both directories are referred to as "archive" directories because they serve similar purposes. However, they are maintained by different software and their contents are very different.

[Return to Table of Contents]

How do I copy a DSK file to a diskette?

The diskette image format used for the CSF Boot Diskettes and the FixPak Diskettes cannot be directly copied onto a diskette. Nor will XDFCOPY work, since these are not in XDF format. You will need a copy of the LOADDSKF utility, either from your Warp CD or an FTP site, to create real diskettes from the image files.

The LOADDSKF (.DSK, .nDK) image format allows the transfer of the entire contents of a diskette, including the diskette label and boot sector. Other methods (e.g. PACK, ZIP) could theoretically be used to transfer the contents of the FixPak diskettes, but they would not be able to create a bootable set of CSF Boot Diskettes, for example.

[Return to Table of Contents]

OS/2 is installed on F:. Why does RSU need space on C:?

Regardless of where OS/2 is installed, if RSU thinks there is sufficient free space on C:, it will allocate the $RSUTMP$ and $PMTUSR$ directories there. If there is not enough space on C:, it will prompt the user for an alternate location. But OS/2 is a multitasking system; if other activity (e.g. print spooling, swap growth) uses space on the partition that RSU assumes is available, RSU may run out of space as it transfers the RSU support package or FixPak files.

Workaround: Free up space on the partition where RSU allocated its directories, then go back to the PSP 'web site and start the installation again. If one or more complete FixPak files have already been transferred, this will be detected by RSU.

[Return to Table of Contents]

How do I continue a SERVICE install after a CRC error on Diskette 8?

This is a nasty situation, since the FixPak has been partially applied, potentially leaving the system with out-of-step DLLs or other unexpected combinations of files. The results of this are difficult to predict, but odd errors or system failures (TRAPs, IPEs, etc.) are likely.

If you can reasonably avoid it, do not boot the partition where you are applying service. If you don't have the diskette image file available to recreate the diskette, find another system with Internet access, and re-transfer the image file for FixPak Diskette 8 and a copy of LOADDSKF.EXE. This would be a good time to get copies of all the remaining diskette image files as well.

Next, rebuild the bad diskette from the image file. LOADDSKF is written to run under DOS or OS/2 (the technical term is "VIO family-mode app"), so you can do the download and diskette creation from a system running DOS, MSWinXX, or presumably even an old Sun 386i using DOS emulation.

Edit the FSERVICE response file RESPONSE.FIL on CSF Boot Diskette 2 as necessary for your environment. This is a standard ASCII text file.

Finally, put CSF Boot Diskette 1 in the A: drive of the affected system and restart the system. FSERVICE will re-request the FixPak diskettes and completely reapply the FixPak. Once this process completes, you should have the FixPak fully installed and operational.

[Return to Table of Contents]

How do you back out a FixPak when the archive directory is corrupted?

The simple answer is, you can't. This is another case where having a current (pre-Service) system backup is critically important.

If you have a current backup of the partition, the easiest way to recover may be to restore the entire partition.

If you do not have a current backup available, and if all of the data files are present in the Archive directory, you could try using the CSF Redirect option to replace the pointers to the Archive directory.

If one or more files have been mangled or lost, the situation is a little trickier. Given time and some light programming skills, one could theoretically extract the FixPak file list from README.1ST and match it against a list of the Warp 3 or Warp 4 CD \OS2IMAGE files (including the contents of PACKed bundles). Using this list, one could then selectively restore all files affected by the FixPak from the Warp CD, which should restore the system to working order.

On the other hand, and depending on the available resources, one might also conclude that the time and effort involved to do this would be significantly greater than the time and effort to reinstall and re-customize the system.

[Return to Table of Contents]

My RSU update completed cleanly. Can I delete the $PMTUSR$ directory?

Yes. Even if you requested that the FixPak files be deleted after service was applied, the RXFTP.DLL might have still been seen as "in use" until the next time you rebooted your system. But once your install has completed, you can safely delete the directory; it will simply be recreated the next time you perform a Remote Service Update.

[Return to Table of Contents]

Is there a master list of SYSLEVELs?

Yes. http://ps.software.ibm.com/pbin-usa-ps/getobj.pl?/pdocs-usa/psprod.html.

[Return to Table of Contents]

FixPak Installation: Common Problems

The perceived "severity" of any given problem generally depends on how much time and effort has to be expended to correct it. All too often one small piece of information can make the difference between a two-minute correction and an extended exchange of messages or phone calls over days, or even weeks. The following items fall into this category.

[Return to Table of Contents]

Leftover traces of previous FixPak(s)
CSF0249: Error opening or creating archive file

Occasionally the CSF Archive directory will be deleted, either by accident or in response to a sudden need for disk space. Some time later, the user tries to apply a new FixPak and experiences problems because the CSF control files are still present, directing CSF to use a now nonexistent directory.

If the directory was simply moved to a new location, use the CSF Redirection feature to update the CSF control structures.

Otherwise, see the Recovering from problems section of the README.1ST (XRxxxxx.RM1) file.

If you see these problems applying your initial FixPak to Warp 4, it's a sign that this problem existed on the Warp 3 system you installed your copy of Warp 4 over. The pointers are still present, and will cause problems even if the Archive directory still exists. This situation is described in the FixPak README.1ST (XR_M001.RM1) file section Residual FixPak files from OS/2 2.11 or Warp 3.

[Return to Table of Contents]

"No products to service"

This error indicates that the CSF software has not been able to detect a SYSLEVEL.OS2 file which matches the product code it was intended to service (e.g. XR04000 for US Warp 4). Possible causes include:

To check your current product level, use the SYSLEVEL command. If you have multiple copies of OS/2 installed, be aware that SYSLEVEL will report all of them. Make sure that you are checking the Base Operating System level for the partition you are trying to service.

If you have verified that you have an incorrect SYSLEVEL.OS2 file, you can copy in a new one from a Warp Installation Diskette or from the product CD (e.g. \OS2IMAGE\DISK_2 for Warp 4). However, be aware that while inadvertently copying a Warp 4 SYSLEVEL.OS2 onto (say) a copy of Warp 3 Connect might let you install XR_M001 on that system, the result would be a non-booting system. At best.

Be sure to rerun SYSLEVEL after updating your SYSLEVEL.OS2 file to verify that the result is what you expected.

[Return to Table of Contents]

Running out of Disk Space

All methods for applying a FixPak check to ensure that sufficient disk space is available before starting. However, it is still possible to run out of space during the installation of a FixPak with SERVICE or RSU if there is just enough space at the start of installation and:

If you experience this problem, free up additional space as required and reinstall the FixPak. You may need to use FSERVICE to apply the FixPak if the failure left the system in an unusable state.

[Return to Table of Contents]

Back-level CSF Boot Diskettes

Like any software, the OS/2 Corrective Service Facility is updated from time to time. In fact, since Warp 3 was released, a revised set of CSF Boot Diskettes has been provided for every released (public) FixPak.

A number of users tried installing Warp 3 FixPak 17 (XR_W017) using back-level CSF Boot Diskettes which were still lying around from XR_W005 (almost a year earlier), or because a friend provided them, or a backlevel copy was picked up from a BBS or FTP site. The typical result was a partially-installed FixPak, leaving the system unable to boot.

Be sure you are running the latest copy of the CSF software, not only because of ongoing fixes but because a given FixPak may assume that you are running the current release.

[Return to Table of Contents]

Netscape/2 reports "unknown app type" for RSU update

If you see this message, the most likely cause is that you have bypassed the required Netscape/2 setup steps outlined on http://ps.boulder.ibm.com/softupd.html. If you have already downloaded the UNZIP.DLL and RSUINST.EXE files and verified that they are installed in the correct directories, check the General Preferences... item on Netscape/2's Options menu. In the Helpers section, you should see an entry for the following:

File/MIME type: www/unknown
Action: RSUINST.EXE
Extensions: rsu
Launch the Application: Enabled

[Return to Table of Contents]

SYS3175 in RSUINST.EXE when logged on to Netware server

If you are logged on to a Netware server when you start a Remote Service Update, you may see an almost immediate SYS3175 error indicating a problem in RSUINST.EXE/DOSCALL1.DLL.

Workaround: If you experience this problem, log out from the Netware server and restart the RSU service process.

[Return to Table of Contents]

FTP error during RSU file transfer across firewall

The RSU service is initiated by the 'web browser (Netscape/2 or WebExplorer/2), but later portions of the process initiate FTP transfers independently of the browser. These may be affected by firewall restrictions.

Workarounds:

[Return to Table of Contents]

Large number of windows opened "spontaneously" during install
Swap file grows beyond reasonable limits, may fill partition

This is not a common problem, but has been reported. In at least one case, the problem was apparently triggered by the presence of an alternate command processor (4OS2) in place of the usual OS/2 command processor (CMD.EXE).

[Return to Table of Contents]

Warp 4 FixPaks

As this document was being put together, two controlled FixPaks had been released for Warp 4 (XR_M000 and XR_M001) as well as a released version of XR_M001. Presumably this means that Warp 4 FixPak 2 (XR_M002) is being developed, but it may or may not be the next released FixPak.

[Return to Table of Contents]

XR_M000 and XR_M001 controlled releases

Warp 4 Base FixPak 0 and several prerelease versions of Warp 4 FixPak 1 were provided on a controlled basis. If you installed any of these controlled FixPaks, carefully review the documentation for the released version of XR_M001 before installing it. In particular, look for the section If you have installed FixPak XR_M000.

[Return to Table of Contents]

XR_M001: Warp 4 FixPak 1

The following problems have been reported by users after installing Warp 4 FixPak 1.

[Return to Table of Contents]

IDE partition(s) "disappear" after applying XR_M001

After applying XR_M001, partitions on drives attached to the secondary IDE channel may no longer be recognized.

If you experience this problem, it is very likely that the partition(s) are intact and can be made available through a simple workaround.

Recognizing a drive's geometry is not a simple task. There are multiple sources of information, not all of which may be available for any given BIOS/controller/drive combination, and those which are available may or may not agree. The IBM1S506.ADD driver supplied with XR_M001 is a little more sophisticated that its predecessors, and will recognize that the BIOS performs CHS (geometry) translation for drives on the secondary IDE channel in cases where it did not before.

This is a Good Thing.

The down side of this is that a drive on the secondary IDE channel which was partitioned and formatted using the older logic has address values on control blocks on the disk which assume no translation. Now that the driver detects that the BIOS is using translation, these values are no longer valid, and old partitions can no longer be recognized using the new scheme.

In the long run this is probably a Good Thing, but to the user of an affected system it is definitely an Aggravating Thing(;-).

Workaround: First, rename the FixPak 1 version of IBM1S506.ADD (to, say, IBM1S506.FP1) and restore the pre-XR_M001 version of the driver using the procedure outlined in the FAQ section. If this is the problem you are experiencing, restoring the older driver should make your partition(s) reappear.

Once you have determined that the new IBM1S506 driver is what is causing the problem, you may be able to use the XR_M001 driver by editing CONFIG.SYS to add a /GEO parameter with the drive's physical geometry (cylinders, heads, sectors). If you don't have this information readily available, you may be able to obtain it from your BIOS Setup screens or download it from the manufacturer's 'web site. Most drives now have this information written or stamped on the drive itself, but spending a few minutes on the 'web may be preferable to removing the covers from your computer.

In some cases you may need to use the undocumented "full form" of the /GEO parameter to provide the "translated" geometry seen by BIOS Int 13h. This information can be obtained from the IBM1S506 driver by adding a /V parameter and observing the driver's startup messages.

Fix: The "correct" long-term fix is to back up the contents of all partitions on the affected drive(s), delete all partitions on each drive, re-add them, FORMAT them appropriately, and restore their contents. However, this may be inconvenient for any of a number of reasons, including not having sufficient backup capability. If you have been able to get access to the drive(s) using one of the suggested workarounds, you should not see any adverse effects from continuing to use the workaround.

Technical note: The /GEO parameter full form (physical and translated geometry) is as follows:

   /GEO:(a,b,c),(d,e,f)     where



   (a,b,c) is the drive's physical geometry from the manufacturer's specifications:

      a: Number of physical cylinders (from manufacturer's specification)

      b: Number of physical "heads" (mfgr's spec.)

      c: Number of physical sectors per track (mfgr's spec.)    and

   (d,e,f) is the translated drive geometry (displayed using the /V parameter)

      d: Number of "cylinders" after translation (see Note 1 below).

      e: Number of "heads" after translation (BUT see Note 2 below).

      f: Number of sectors per track.

Assuming you have a drive such as a Western Digital AC2700 (1416 cylinders, 16 heads, 63 sectors per track) attached as Master device on the Secondary IDE channel, you would provide the physical geometry by coding your driver line in CONFIG.SYS as follows:

  BASEDEV=IBM1S506.ADD /V /A:1 /U:0 /GEO:(1416,16,63)

For the same drive, if a given BIOS "translated" the WD AC2700 physical geometry so that it appeared to have 707 "cylinders", 32 "heads", and 63 sectors per track, the full geometry specification would look like the following:

  BASEDEV=IBM1S506.ADD /V /A:1 /U:0 /GEO:(1416,16,63),(707,32,63)

Notes:

[Return to Table of Contents]

Intermittent TRAP, IPE errors on systems with APM or suspend feature enabled

A number of users reported that they started experiencing apparently random TRAP or IPE errors, including TRAP 000d and TRAP 000e, after installing FixPak 1. The errors did not seem to be related to any specific application or user activity, but they were frequently reported as occurring after the system had been idle for some period of time.

In many cases these errors ceased after automatic power-saving features were disabled.

Workaround: First, disable all power-saving features. If the TRAP/IPE errors no longer occur, selectively enable the features until the errors reappear.

[Return to Table of Contents]

Unable to start second "seamless" WinOS/2 session after applying XR_M001

A few users reported being unable to start a second seamless WinOS2 session after FixPak 1 had been installed. Some of these reported that reverting to the pre-XR_M001 version of SEAMLESS.DLL cleared the problem. Other users experiencing this problem report that this had no effect.

Workaround: If you experience this problem, try backing out \OS2\DLL\ SEAMLESS.DLL. Note that this older version may cause problems with Netscape/2 "plug-ins".

[Return to Table of Contents]

TRAP screens report version 9.024, but VER /R reports 9.025

The text for TRAP/IPE screens is embedded in OS2KRNL, and apparently was not updated to reflect the new release number. VER /R obtains its version number from a different source.

This buglet is not expected to have any effect, other than some possible user confusion and a slight added burden on OS/2 Support ("Internal Revision 9.024. Is that with FixPak 0, prerelease FixPak 1, or the publicly-released version of FixPak 1?")

[Return to Table of Contents]

System Editor (E.EXE) loses custom icon

The System Editor file (E.EXE) shipped with XR_M001 is missing the Extended Attributes containing its custom "pencil under waving OS/2 banner" icon.

Workarounds:

[Return to Table of Contents]

Loss of removable media support after XR_M001 installed
Loss of Beta driver capability after XR_M001 installed

At the time XR_M001 was released, the following driver packages were available from the OS/2 DDPak On Line for public Beta testing:

In all three cases, installing XR_M001 will replace one or more of the drivers from these packages, with varying consequences, including (for NEWDASD):

Workaround: If you are using one of these packages, be sure to keep a copy of the distribution package in an accessible location, such as on a diskette. After installing XR_M001, reinstall the Beta package.

[Return to Table of Contents]

Hang during WPS startup - blue screen, clock pointer

The IBM APAR describing this problem (JR09508) is listed as being fixed by XR_M001. After installing FixPak 1, several users reported that the problem was no longer present on their system. However, a few users reported its appearance following FP1 on systems where it had not previously been present.

Workaround: If this problem was present on your system and installing XR_M001 fails to clear it, or if the problem appears on your system after FP1 has been applied, see the list of possible workarounds in the Warp 4 Installation Notes at http://www.cincyteamos2.org/warp4install.html.

[Return to Table of Contents]

Erratic NumLock behavior in DOS sessions
Mysterious *FEP_MODE entry in DOS Properties list

See README file section If you have installed FixPak XR_M000. Note that this section also applies to those who installed the "controlled release" versions of XR_M001 supplied to users installing the new Lotus SmartSuite.

[Return to Table of Contents]

Credits

I would like to extend my thanks to all who have directly or indirectly contributed to this document. In particular, I would like to thank Dick Kurtz of PSP Fix Distribution for his patience in clarifying some of the finer points of CSF and RSU, and Aron Eisenpress for the weekend he spent working on the IBM1S506 problem. In all cases, however, the responsibility for any errors is mine.

[Return to Table of Contents]

Feedback

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

Applying Service to OS/2 Warp, Version 1.00, April 22, 1997
Copyright (c) 1997 by Frank McKenney, all rights reserved

Enter your email address below to automatically receive notification from the URL-Minder Service when this page is updated.

Your E-Mail address:

Home Membership
Application
User Group
Info Request
Meeting
Agenda
Our Mission Job Opportunities
Get Help! Search OS/2 Links Reviews/Articles Special
Offers
ISP Information
Master Update
List
OS/2
Vendors
Warp 4
Install Tips
Warp 4
Undocumented!
o
Applying
Service
to OS/2


Webspace donated by: Team OS/2 Cincinnati Users Group

e-mail: Webmaster@cincyteamos2.org.