The basic process used is to replace and add additional files to an OS/2 system. There is more than one way to do this, either with diskettes, remotely via the web, or over a LAN. This is can be done with very little intervention required by you, and safeguards are also enabled that will allow you to return the system to the prior state if you have determined there is a problem using the serviced system.

All this is covered within this document.

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

Applying service to an IBM 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:

• 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. This type if FixPak does not contain any device drivers.
• Device Driver FixPak. Similar to Base Operating System FixPak but contains only device drivers.
• 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.
  

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

This document will be concentrating on Warp Base FixPaks, the kind of service most OS/2 users are likely to encounter, and the 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 have been cumulative, that is, the latest Warp FixPak includes all of the fixes from prior Warp FixPaka. 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 (also known as the FixTool) 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, depending on how the FixTool was run. 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's 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. It is located on either the FixTool diskettes or in the FixTool EXE file when you expand it on your disk or diskette.

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.

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 (Remote Software Update) method is more convenient but requires more disk space.

Alternatively, you can have a FixPak downloaded and installed for you over the Internet. This Remote Service Update (RSU) 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 and Warp 4 FixPaks, 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

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? In addition, a re-boot may be required to complete service, will this be a problem if on a server?
• 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 different attitudes toward applying Base FixPaks. Some people simply apply every FixPak, 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 we 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 a 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.
• Apply new fuction included in a FixPak.

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, we'd recommend not applying service unless you have a strong reason to do so. For someone in this position, consider "My system TRAPs twice a day and there's a confirmed fix in FP 7" a strong reason. On the other hand, if the reason were more on the order of "My system seems a little sluggish and FP 7 might make things better", we'd recommend not installing.

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

We 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 checklist, 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 IBM provides an Installation Instructions file (README.1ST) and a list of APARs fixed in the FixPak (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 or get the latest FixTool file and either run it on a hardfile to expand it, or create a diskette to use from the file (it is a ZIP file as an EXE). Pick up a current FixTool located where you got the FixPak from.
• 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). Also read the READ.ME file with the FixTool for any changes that are not in the README.INF. If you plan to use the new Remote Service Update facility, also read OS2SERV.INF.
  

There are two items required to apply service. The first is the CSF Diskette (also referred to as the FixTool). This diskette is a self-extracting Zip file that you execute to create the Fixtool on diskette or a location on your harddrive.

When you use the FixTool, you are responsible for booting the system to the desired state to run service.

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

This is really very easy to do,

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.

NOTE:> Do not do this if you are using FixTool 1.38 or 1.39. There was a problem correct with FixTool 1.40. If you do this, you'll not be able to apply another FixPak. See the READ.ME in FixTool 1.40 how to get around this problem if you had done a COMMIT with FixTool 1.38 or 1.39.

The FixTool (also knows as the CSD Utility) is available in 2 versions. One is a set of bootable diskettes, and also know as the WKICKR.ZIP file. This corresponds to the 1.37B level. This version is still supported, and some FixPak's still require this FP. In general, when this is the case, the FixTool is also located with that FixPak.

The FixTool 1.37B was the last to be issued as a stand-alone set of diskettes. After this, a new format was switched to, one that was either a ZIP or an EXE file that when executed produced the individual FixTool files. It could be placed on the hard drive in a subdirectory and run from there, or placed on a single diskette and run from the diskette. If you wanted to avoid the handling of locked files, it was necessary for the user to boot to an alternate system, either another partition, or use a set of boot diskettes, to run service, and no booting capabilities are included.

See the READ.ME file included as part of the Fixtool for a list of changes made for each version.

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 or the FixTool, 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 ol OS/2 with a specialized CONFIG.SYS file which automatically starts FSERVICE.

If you are using the FixTool, you'll need to boot to another bootable partition or off of a diskette. Then you need to get to a command prompt and run FSERVICE in the FixTool directory if on a hard drive, or if FixTool is on a diskette, switch diskettes and run from the A: prompt 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. If you are using the FixTool, you will need to edit a response file to perform this operation. See the READ.ME file in the FixTool directory for more information.

  * 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. All you'll need to is use a website to perform a backout:

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 README2 text file on diskette 1 listing the APARs whose fixes are included.

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.

In addition, FixPaks since Warp 3 FixPak 32 and Warp 4 FixPak 4 or later update a SYSLEVEL.FPK (or create it if one doesn't exist) so that a SYSLEVEL command will show the installed FixPak version.

FixPaks applied with FixTool 1.38 or later will also update your SYSLEVEL.OS2 file to indicate the FixPak applied. The command 'SYSLEVEL' will display SYSLEVELs found, and if you look at the "Current CSD level" reported on products you've applied FixPak's with FixTool 1.38 or later will report the FixPak level you are at.

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 as more than one partition or LAN attached system might be using it. COMMIT will delete your BACKUP directory and LOG files though. If you no longer need the ARCHIVE directory, you may manually delete it after you perform the COMMIT.

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 README file provided in all FixPaks. The instructions are preceded by a warning of the consequences of doing so.

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.

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

In some instances, the FixTool may hang and not produce messages. We've determined this is because the FixTool session has run out of handles to open files, even report an error. This will occur mainly on LAN server type systems or Work Space On Demand systems with many RIPL clients. FixTool 1.40 and above have a new SET parameter, SET CSFDRIVEAPPLY= that would limit the FixTool searching to a single drive, thereby reducing the number of files it must open looking for products to service. There is also an undocumented SET variable, SET SHELLHANDLESINC= statement that will increase the number of handles to a session. Use 50 and it should work or produce and error. If it still doesn't complete, try increasing the number.

Frank Mckenney would like to extend his thanks to all who have directly or indirectly contributed to this document. In particular, he would like to thank Dick Kurtz of NCSD 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.