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.

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.

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:

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:

• Individual fix. This is a fix for a specific problem, and the packaging and installation method will vary.
• FixPak. A FixPak is a collection of related fixes which are to be applied to a product at the same time. I'm currently aware of the following types of FixPaks for OS/2:
  
  • Base Operating System FixPak. These are the largest and most complex FixPaks, generally applied using a specialized software package called the Corrective Service Facility . These will typically replace one or two hundred files, many of which may be in use at the time.
  • Display Driver FixPak. These are updates to a video driver supplied by IBM, generally one or two diskettes..
  • Printer Driver FixPak. Printer driver updates, generally installed using a Printer object's Printer driver Install option.
    
• ServicePak. A major update which will replace most or all of the components of a given product, and which will serve as the base level for any future service.
  

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.

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.

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.

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.

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.

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.

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.

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

• Disk space: If this is the first FixPak applied to your system, an Archive directory will be created. Where should it go? If this is not the first FixPak applied, there may be a need to create a Backup directory. Where should it go?
• Machine availability: Assume that the machine being serviced will be unavailable for general use while service is actually being applied. Will there be a problem with scheduling this?
• Human resources: Someone will have to start the service. Depending on the installation approach, someone will have to spend time downloading the FixPak diskette images, creating the diskettes from them, and feeding them to the machine as requested.
  

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:

• You need a fix for a specific current problem (e.g. ATM font fixes in Warp 4 FixPak 1)
• You want fix for a source of serious aggravation. (e.g. Synchronous Input Queue fix in Warp 3 FP17)
• You need the device support provided by a new release of a driver.
• There are fixes which are prerequisites for other software (e.g. Lotus SmartSuite and Warp 4 FP1)
• OS/2 Support recommends it as a way of fixing a problem you reported.
  

Reasons to Avoid Applying, or to Proceed Cautiously:

• Your system serves a critical business function, and downtime must be avoided at all costs.
• You are not in a position to make a system backup.
• Your system has been basically (or completely) reliable.
• Your hardware has not changed.
• Multiple machines, and users, will be affected.
• You support a variety of hardware configurations.
  

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.

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.

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.

• Read this document all the way through before starting.
• Obtain copies of the README files for the FixPak and review their contents. Currently PSP provides an Installation Instructions file (XRxxxxx.RM1, README.1ST) and a list of APARs fixed in the FixPak (XRxxxxx.RM2, README2).
• Review the list of files in the Installation Instructions to see if there are any conflicts with non-IBM drivers or files with the same name. If you are a Beta tester using prerelease drivers, programs, or DLLs, make sure that you have copies of these in case they are overwritten by files from the FixPak.
• Use the OS/2 SYSLEVEL command to verify that your system's current SYSLEVEL matches the one at the front of the installation instructions (e.g. XR04000 for the US version of OS/2 Warp v4). There are still OEM display driver packages which will incorrectly alter this, and it's much easier to correct this before you start installing.
• If you will be using a diskette-based installation (SERVICE or FSERVICE), download the diskette images and use LOADDSKF to create diskettes. Pick up a current set of CSF Boot Diskettes (for W4FP1, use F.133 or later).
• Check your partitions for free disk space. You will need space for the old copies of any replaced files, and you may be prompted for a location for an Archive or Backup directory. It's easier to make these decisions before you start.
• Run CHKDSK on all partitions, booting from a set of Utility Diskettes where necessary.
• Make a complete system backup, and verify the contents.
• While not absolutely essential, it may be helpful to review the Corrective Service Facility documentation (README.INF). If you plan to use the new Remote Service Update facility, also read OS2SERV.INF.
  

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

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.

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.

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.

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.

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:

• The RSU [Uninstall] button is not available unless a complete FixPak exists on the machine being serviced. If the FixPak was applied and the files deleted afterwards, you will not be able to initiate an Uninstall (or even see the button) until you transfer a complete copy of a FixPak onto the system. This will generally take much longer than picking up copies of the required image files from an FTP site and creating diskettes with LOADDSKF.
• Due to a bug in OS2SERV.EXE, RSU cannot currently be used to backout service to the Archive level when only one FixPak has been applied. This will apply to most Warp 4 systems, and any Warp 3 system which has only had service applied once.

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(;-).

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.

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.

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.

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:

• Dump the Archive directory (and Backup directory, if any) to tape.
• Copy the Archive/Backup directories to removable media.
• Compress the Archive/Backup directories into a ZIP or PACK package.
  

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.

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.

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.

• The "ripple effect": files you pick up from a non-IBM site may not be current. Sites which are kept up to date through voluntary efforts may not receive copies of FixPaks set up by PSP Fix Distribution for some time after release. If PSP re-releases a FixPak (as occasionally happens), it will take time for the updated files to reach other sites, and they may or may not replace the earlier version.
• FixPak files at other sites are, on occasion, packaged differently or given new names because of conflicts with existing files at the site. This can cause problems when the documentation refers to a specific file by name.
• It may be difficult to tell whether the file you have picked up is even close to the current version. For example, when FixPak 17 for Warp 3 was released, many users assumed that the copy of the CSF Boot Diskettes they obtained from an FTP site (or in one case, a local BBS) was the most current version available, and experienced some nasty installation problems as a result.
• Pre-release versions of FixPak files are occasionally uploaded to sites with no clear indication of their status. They may also lack a warning that, because it is not an officially-released version, this "FixPak" will not be supported by IBM.
  

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.

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:

• File name
• Location of the FixPak copy of the file
• Location of the pre-FixPak copy of the file (Archive or Backup directory)
• Whether any other files need to be backed out at the same time

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.

• To restore the pre-XR_M001 version of the IDE Base Device Driver (IBM1S506.ADD), you would issue the following commands:
  
  D:
  CD \OS2\BOOT
  MOVE IBM1S506.ADD IBM1S506.FP1
  UNPACK F:\W4ARCHIV\IBM1S506.ADD D:\OS2\BOOT
  
  
• To restore a copy of the pre-XR_M001 version of the System Editor (E.EXE) to D:\TMP, you could simply type
  
  UNPACK F:\W4ARCHIV\E.EX_ D:\TMP
  

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

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.

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.

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.

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.

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.

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.

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.

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.

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:

• An OEM display driver installation loaded a backlevel SYSLEVEL.OS2
• SYSLEVEL.OS2 was accidentally restored from, or copied from, a different version of OS/2
• A FixPak is being applied to the wrong system
• The wrong FixPak is being applied to the right system (e.g. XR_M001 on Warp Connect)
  

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.

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:

• Many locked files are detected, requiring extra copies of FixPak files to be stored on disk (DLLs, other system files).
• Another process consumes space on the drive.. Typical causes are swap growth and spool files.
  

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.

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.

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.

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:

• "Socksify" the TCPIP stack so FTP transfers can succeed.
• Use one of the diskette-based methods for applying service (SERVICE or FSERVICE).

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

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.

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.

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

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:

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.

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

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?")

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:

• Save a copy of the System Editor prior to applying XR_M001.
• Recover the icon from the pre-FP1 E.EXE and apply it to the new file.
• Ignore the problem.
  

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

• New Support for Removable Media (newdasd.exe)
• Updated IDE Drivers (ideupdte.exe)
• Updated CD File System (cdfs.exe)
  

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

• Loss of IDE busmastering capability
• Loss of PCMCIA removable drive support
• Loss of HPFS support for removable media
• Possible TRAP errors
  

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.

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.

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.

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.

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