This paper was produced to assist you in improving the performance of your OS/2 system by providing information on OS/2 Warp 4, its various subsystems, and practical performance tuning tips and techniques. It begins by familiarizing you the new features and enhanced functions of OS/2 Warp 4. It will then introduce you to the concepts and terminology needed to successfully tune an OS/2 system. You will learn to recognize the symptoms of many common performance problems. You will also learn how to create and use a repeatable process for analyzing a system's performance problem and understand the many tuning parameters and techniques used to fully optimize your system. The tuning tips and techniques are divided into 3 sections targeted to different levels of complexity: basic OS/2 tuning, advanced OS/2 tuning, and tuning tips for a networked OS/2 workstation.

This paper documents the procedures used and knowledge obtained from performance evaluation and measurement activities. Some procedures have been recorded in documents previously published by OS/2 development and support groups within IBM. It should be considered a working document subject to forthcoming changes without notice as additional information is obtained.

The information contained in this paper represents the interpretation of IBM on the issues discussed based on the measurement results as of the date of publication. Since the results are applicable only to the system under test, IBM makes no commitment nor guarantees the accuracy of any data measured after the date of publication.

The authors wish to express their sincere thanks to the comments, suggestions and reviews made by Michael Martino, Cyndi Kubich, Rich Wahl, Robert Paulsen, Jimmy DeWitt, Ivan Eisen, Bob Russell, Steve Woodward, Lannes Robinson, Valerie Jackson, and many others that have involved with OS/2 Warp products.

For further references, please refer to the following documents.

[1] OS/2 Warp 4 Readme

[2] OS/2 Warp 4 Reference and Commands

[3] OS/2 Warp 4 Tasks

[4] "Performance Tuning OS/2 Warp," Ron Cadima, ISV Development Assistance, IBM Boca Raton, FL, 1995.

[5] "OS/2 2.1 Performance Tuning for End Users," IBM, May 1993.

[6] "OS/2 Warp Performance Pentium Pro P6 Performance Benchmark Guide," Duc Vianney, IBM TR54.915.

[7] "OS/2 Client Tuning Worksheet," Tony White, IBM, Personal Systems Competency Center, May 1996.

The following terms are trademarks or registered trademark of the IBM Corporation in the United States or other countries

OS/2, OS/2 Warp, OS/2 Warp Connect, OS/2 Warp Server, OS/2 LAN Server, DB/2, LAN Server 4.0, Bonus Pak, Personal Communications/3270 , Visual Age and Visual Builder, ThinkPad, NetFinity, OpenDOC, WebExplorer, SOM/DSOM, DIVE, System Performance Monitor/2 (SPM/2)

The following terms are trademarks of other companies:

TRADEMARK OWNER

All other marks are the property of their respective companies.

References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any of IBM's intellectual property rights or other legally protectable rights may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, programs, or services, except those expressly designeated by IBM, are the user's responsibility.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood NY 10594, U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you.

This publication could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time.

It is possible that this publication may contain reference to, or information about, IBM products (machines and programs), progamming, or services that are not announced in your country. Such references or information must not be construed to mean that IBM intends to announce such IBM products, prograaming, or services in your country.

Requests for technical information about IBM products should be made to your IBM authorized reseller or IBM marketing representative.

(C) Copyright International Business Machines Corporation 1996. All rights reserved.

Note to U.S. Government Users. Documentation and programs related to restricted rights - Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.

1.3 Software prerequisites 10

1.4 The software configuration menu 10

6.2.5 Settings for Windows applications 54

6.2.10 Tuning tips for games 58

6.3.5 Video settings 68

6.3.6 Mouse and touch sensitive settings 71

6.3.7 Settings affecting communications applications 72

IBM's goal is to provide a more responsive OS/2 that is simpler and more intuitive to use, and provides easy connectivity. To achieve that end, OS/2 Warp 4 addresses three major issues:

• Ease of use - changes to the Workplace Shell interface
• Voice Navigation and Dictation
• Ease of connecting to whatever networked environment you wish

OS/2 Warp 4 contains the following new features and functions:

• Voice Navigation and Dictation - Combining speaker independence and continuous speech, OS/2 Warp voice-enabled the operating system to navigate OS/2 and macros can be created to simplify repetitive tasks.
• Internet-Aware Desktop - New desktop objects for HTML, URL, Java class and FTP servers. These objects enable drag-and-drop from the Internet to the desktop and vice versa. The FTP object provides a folder view of a FTP directory.
• 256-color Exploitation - Visuals use more colors to give the user a 3D experience using texture, shadowing and curved edges.
• More System Fonts - A new condensed font style is added that uses less desktop real estate while improving legibility.
• File and Print Services Client - Converge LAN Requester and Peer for OS/2 to provide a single administration workstation. Users can share peer resources and administer peer and LAN resources. Objects on the desktop will inherit peer functionality in their context menus. The File and Print Client can connect to IBM-compatible networks such as:
• OS/2 Warp Server
• OS/2 LAN Server
• Windows NT Server
• PC LAN Program
• OS/2 Warp Connect
• Windows NT Workstation
• Windows 95
• Windows for Workgroups
• LANtastic for OS/2
• LANtastic for DOS
• PCOM Lite - Personal Communications/3270 (PC/3270) and Personal Communications/5250 (PC/5250)-- TCP/IP Entry Level 4.1 are replacements for TN3270, TN5250 and PMANT. The new emulators feature 32-bit code, full font set and automatic font sizing, custom color palette, improved cut and paste, APL support, command line (IND$FILE) file transfer, context sensitive help, popup keyboard, hot spots, PCMCIA and support problem determination aids. Users are limited to two sessions.
• Support for JAVA(tm) Applications - Full support for the Java language, Java runtime and Java applets.
• TrueType Engine - New support for TrueType, a ready source of inexpensive fonts.
• OpenDoc(tm) - Runtime support for cross-platform compound documents.
• Open32 Support - Support for subset of a Win32 APIs and messages to ease the porting of Windows applications.
• OpenGL - A high quality, portable 3D graphics API that will primarily enable technical and engineering applications (CAD/CAM) to be ported to OS/2 Warp.
• DPMI 1.0 Subset - Enablement for support of Win32s 1.25a compatibility and support of Borland 4 tools.
• Plug-and-Play (PnP) Support - Automatic detection and resource allocation for enabled devices as well as legacy ISA devices. An application is provided to view resource assignments. The framework has been established for more sophisticated operations in future releases. OS/2 Warp's PnP support does not include dynamic installation and configuration.
• Warm Plug/Warm Docking - Support for docking/undocking and the swapping of diskette drive and CDROM drive in specific models of IBM ThinkPad 755 series.
• Infra-red (IR) Support - ThinkPad-specific support for IR supporting the IrDA interface.
• Graphics Device Driver Model (GRADD) - New device driver model that reduces the IHV development effort and improves time-to-market.
• Device Driver Pak (DDPak) - A collection of OS/2 device drivers available from IBM and third-parties offered as-is for customer convenience.
• Display Data Channel (DDC) Support - DDC2 support for automatic enabled-display recognition and refresh rate setting.
• Realtime Musical Instrument Digital Interface (MIDI) - Framework and API for delivering high quality, realtime relative MIDI applications.
• Security Enabling Services (SES) - Enablement for operating system security services.
• System Dump Formatter - Utility to read and format system dump information.
• First Failure Support Technology (FFST) Probes - Capture all data relevant to the error at the time it occurs.
• DMI Interface - Support for the Desktop Management Interface, an industry standard way to manage Pcs.
• TME NetFinity - Software to allow administrators to view, monitor and initiate actions to ensure the smooth operation of PCs.
• Software Registration (ART) - Online registration tool to encourage customers to register the software electronically via a modem or the Internet, FAX, mail or even the telephone. Users are gently reminded periodically until registration is completed.
• Retrieve Software Updates - Automatic software retrieval and install of fixes and upgrades via the Internet.
• XPG4/ULS Support - Provide ability for easier application adaptation of international requirements such as native languages, local customs and coded character sets.
• Bonus Pak Changes - Collection of personal productivity applications including word processor, spreadsheet, charting, report writer, database, calendar, monthly planner, appointment book and phone book. IBM Works 3.0 contains fixes, memory management improvements, updated help, HTML support, updated word processor and graphics filters and a button bar for commonly used features.
• Remote Support for OS/2 - Allows IBM service representative to dial into your system to assist with problem determination and resolution.
• HyperACCESS Lite - Async communications program to access bulletin board services. The update includes maintenance and other refinements such as user-defined modem strings and more colorful icons.
• CompuServe Information Manager - Provides access to the CompuServe online service. CIM 2.03 includes fixes and removes the OS/2 registration requirement.
• HP JetAdmin and MarkVision for OS/2 delivers an advanced network printing solution that enables you to easily install, configure, query, and troubleshoot network-attached printers from your OS/2 Desktop.
• FaxWorks - Allows FAXes to be sent and received. Includes features of a basic answering machine. Supports drag-and-drop. FAX/data integration through a new interface for data applications to pass answered call to FaxWorks.
• AskPSP - AskPSP consists of an expert system with a natural language interface. It can be used to resolve customer problems on OS/2 Warp. This tool is also used by IBM Service and Support. The technical database, updated monthly, is available by subscription to the OS/2 Technical Connection CDROM.

The following features and functions have been updated in OS/2 Warp 4:

• Integrated install - Updated for OS/2 Warp, the install program gives the user an easy and an advanced path. The user can also selectively install, re-install or uninstall components.
• Controls and Visuals
• Visuals - Use more colors to give the user a 3D experience using texture, shadowing, and curved edges.
• Dialogs - File Open and Close dialogs provide tree views of directories and allow for filetype selection.
• Horizontal Style Notebook - Notebook settings add a horizontal tab option. This new style allows information to be presented more concisely without taking up much space.
• Close Button - Close applications with a single click.
• Folder Menu Bars - Menu bar access for common operations within folders. Users can also utilize the context menu (Mouse Button 2) for these same operations.
• User Interface Redesign
• Background Bitmaps - Bitmaps with texture and color schemes. Exploit use of more colors for higher degree of texture and depth.
• Arrange Options - Desktop and folder icon alignment according to user preferences.
• Pointers - Greater selection of pointers for user customization.
• Font Palette - System-defined or user-defined selection of fonts for text
• Color Palette - System-defined or user-defined selection of colors for visual controls.
• Scheme Palette - System-defined or user-defined selection of fonts and colors.
• Sound Schemes - System-defined or user-defined selection of sounds for system events.
• System Tutorials Update - Designed to help users get up-to-speed, with a focus on getting connected. Also includes a section on speech.
• Help System Updates - Enhancements to give the help author more control over content, presentation, and navigation.
• Migration Database - Database of optimal settings for popular OS/2, DOS and Windows applications. The database is used during install to migrate previously installed applications. Includes additional Windows and new Win32s applications.
• Async Read-Ahead - File system studies disk read patterns, anticipates a disk read and makes it available in memory to improve system throughout.
• Network Transports - NDIS device driver support for a variety of LAN adapters.
• Netware Client 2.11+ for OS/2 - This is the same level of code that was shipped in OS/2 Warp Connect 3.0 and OS/2 Warp Server 4 with fixes.
• TCP/IP
• DHCP/DDNS Client - Dynamic Host Configuration Protocol eases network administration by dynamically allocating and reusing IP addresses. Dynamic Domain Name Service simplifies network access, operation and change with dynamic resolution of IP addresses to IP hosts.
• Socks Security - Permits TCP/IP applications to access the Internet through many standard firewalls.
• FTP and TFTP Client and Server - File transfer to and from a remote host.
• Telnet Client and Server - Logon to and from a remote host. Client is now based on PC/3270.
• REXEC and RSH Client and Server - Execute command on and from a remote host.
• SNMP Agent and Manager - Communicate and obtain status information and manage network resources.
• WebExplorer - WebExplorer 1.1a supports HTML 3.0 and contains numerous fixes and updates.
• Remote Access Client - The Remote Access Client provides LAN access via dial connections (asynchronous, synchronous, ISDN or X.25). The Remote Access Client can dial into either a LAN Distance Connection Server or OS/2 Warp Server. In addition, a Remote Access Client can dial directly to another Remote Access Client to establish a virtual network.
• Mobile Office Services - Mobile Office Services transparently caches files while connected to an IBM-compatible or NetWare network and allows the user to continue using these files even when disconnected. When the network connection has been re-established, Mobile Office Services detects the differences between the cache and the files on the network and prompts the user for resolution.
• Win32s 1.25a Support - Win32s 1.25a application support.
• SOM/DSOM - Provides a language independent, cross platform architecture for sharing objects.
• Device Driver Update - Updates of many device drivers shipped in previous versions of OS/2.
• PCMCIA Enhancements - The latest level of code that supports IBM PCC and other OEMs. This consists of card and sockets services, cardbus and multi-function card support, an enhanced user interface as well as updates to warm docking.
• Advanced Power Management 1.1- Update to support suspend, resume and device management and control.
• Enhanced IDE Support - Enhanced to support the SMART standard for hardware failure alert and DMA capabilities for PCI IDE hard drives.
• Printer Support - New printer device drivers included.
• Multimedia Support - Direct Audio Routines (DART) used by speech navigation and dictation.
• DIVE Enhancements - Enhancements for hardware video accelerators, video capture, MPEG playback and full-screen support for applications needing high frame rates.

Some of the changes that gave OS/2 Warp 3 better performance than previous OS/2 versions are as follows.

• A new link parameter, /EXEPACK, which was used on many system files when OS/2 Warp was compiled, compresses resource and message files by 20 to 30%. These files load 2 to 3% faster, on average.
• Some page frames are "zero compressed" (similar to PKZIP) and put in areas of memory that is already allocated but that has extra space. This allows a page frame to be swapped from RAM to RAM (which happens in nanoseconds) versus swapping from RAM to the hard disk (which takes milliseconds). Up to 250 of these pages can be moved to different areas of RAM instead of the SWAPPER.DAT file.
• Many system DLLs (dynamic link libraries) are now being swapped out to the hard disk. This makes it much quicker to recall them. A lot of overhead is required to load a shared DLL from the file system versus saving it and its associated system data in the SWAPPER.DAT file.
• The SWAPPER.DAT file, when initialized, is put in the largest contiguous space of the FAT file system. Previously the system was not concerned with swapper fragmentation.
• The internal file system in the SWAPPER.DAT file now has a 4 KB cluster size instead of 2 KB. This change makes swapping a 4 KB page more efficient.
• Some system DLLs have been merged, so less overhead is needed to load them into memory and notify all tasks of their locations. For example, PMMERGE.DLL contains three old system DLLs: PMGRE.DLL, PMSHAPI.DLL, and PMWIN.DLL. Although these DLLs are still in OS/2 Warp, their function is simply to forward their calls to PMMERGE.DLL. Some other DLLs that are merged are DOSCALL1.DLL and MMPM.DLL.
• A method of addressing called basing puts some system DLLs at an absolute address to reduce the overhead of finding them in memory.

OS/2 Warp 4 contains all of the aforementioned changes as well as enhancements to the FAT file system (FAT deserialized and optimized asynch read ahead), CD-ROM asynch read ahead, page tuning many system DLLs, single input queue, as well as changes to the memory caching default size and system loader fixup scheme. Furthermore, there are changes made to improve TCP/IP throughput and faster response time for network administration commands.

OS/2 Warp 4 can be installed over the following systems.

• OS/2 1.3
• OS/2 2.0 and 2.1
• OS/2 for Windows
• OS/2 for Windows plus Service Pak
• DOS 3.1 or greater with Windows 3.1, 3.11
• DOS 3.1 or greater with Windows for Workgroups 3.10 or 3.11
• OS/2 Warp V3.0
• OS/2 Warp with WIN-OS/2 V3.0
• OS/2 Warp Connect V3.0
• OS/2 Warp Connect with WIN-OS/2 V3.0
• over itself
• in a totally empty partition

• OS/2 Warp 4 shipped at the equivalent of OS/2 Warp 3 with Fixpak 20 level.

Many OS/2 parameters can be modified during or after installation. This section overviews those paramters that can be modified during the installation process. Each of these tunable parameters will be discussed in greater detail later in this document. From the OS/2 Setup and Installation panel, there will be three menus: Options, Software Configuration, and Help.

• From the Options menu bar choice, you can:
• Install the selected features
• Format other drives
• Access an OS/2 command
• From the Software Configuration menu bar, you can specify the location for the swap file. You can also change the OS/2 and DOS configuration settings of your system.
• The OS/2 parameters that you can change are:
• Printer monitor buffer size
• Buffers
• Disk cache
• Maxwait
• Swap Minfree
• Threads
• Memman Protect
• Memman Swap
• Priority
• The DOS parameters that you can change are:
• Break
• Open FCBS
• Protected FCBS
• RMSize

The OS/2 operating systems, in particular OS/2 Warp 4, have evolved to take advantage of new technologies and strategies, such as client/server, voice navigation and dictation, internet aware desktop, JAVA support, etc. The resulting changes in the software infrastructure and system platforms require careful system planning to ensure OS/2 Warp 4 performs as a cost-effective information technology platform.

Personal computers have limited resources to handle increasingly complex operating systems and applications. Resources such as CPU, disk, and memory must perform well together and deliver adequate response times to satisfy a user's requirements. Hence, capacity planning becomes an important issue when determining the impact of OS/2 Warp 4 on your system. To ensure the correct level of resource to meet and support your computing needs, you need to:

By employing validated performance analysis and tuning methodologies and systems tools, you can accurately measure the utilization of your computer resources. This will the smooth integration of OS/2 Warp 4 into your existing environment.

Your system performance depends largely on how OS/2 Warp 4 and the underlying hardware work together. The 32-bit OS/2 Warp 4 operating system exploits the Intel 32-bit X-86 architecture through the flat memory model, native protected mode and virtual 8086 mode though paging and multiple virtual DOS machine sessions. The flat memory model allows for a very large (4 GB) single address space referred to as flat memory. Call/return times are reduced by eliminating the need to switch segments manifested in a typical 16-bit application.

While all previous 16-bit APIs are still completely supported, the remaining OS/2 Warp 4 APIs are now 32-bit, thus improving performance and enhancing function. In addition, OS/2 also provides support for advanced disk hardware, Direct Memory Access for its parallel port, and many industry standard audio and video devices. Like previous versions of OS/2, OS/2 Warp 4 supports all existing 16-bit and 32-bit OS/2 applications, most DOS applications including those that use EMS, XMS or DMPI memory in the full screen or windowed virtual DOS machine session. Windows application support is also included in OS/2 Warp by providing both Windows 3.1 and Win32s environments for running Windows applications seamlessly on the OS/2 workplace shell, in concurrence with DOS and OS/2 applications.

Several of OS/2 Warp 4's new features and enhanced functions require a powerful processor, more physical memory, and a larger hard drive. If you experience sluggish response time after installing OS/2 Warp 4 you can use some of the performance tools shipped with OS/2 Warp 4 to determine the cause of the problem and apply the following guidelines to obtain the best performance out of OS/2 Warp.

Without Voice Navigation and Dictation:

• Intel 486 DX 33MHz or higher processor
• 12MB to 16MB of RAM
• Installation by selecting options requires 100MB-300MB disk space
• Easy Installation (OS/2 Warp preselected options) requires 200MB disk space
• 640x480 resolution display with 256 colors recommended (SVGA monitor)
• IBM compatible mouse is required
• OS/2 compatible CDROM drive and 1.44MB 3.5" diskette drive "A"
• 14.4K or higher modem or network connection for Internet access
• OS/2 supported sound card for multimedia

With Voice Navigation and Dictation, OS/2 Warp 4 requires

• For speech navigation, Intel Pentium 75MHz or higher with 4MB additional memory
• For speech navigation and dictation, Intel Pentium 100MHz or higher with 8MB-12MB additional memory
• Installation by selecting options requires 100MB-300MB disk space
• Easy Installation (OS/2 Warp preselected options) requires 200MB disk space
• 640x480 resolution display with 256 colors
• IBM compatible mouse is required
• diskette drive A and CDROM driver
• 14.4K or higher modem or network connection for Internet access
• Sound card for multimedia or speech
• High quality microphone for speech (requires Active Noise Cancellation feature, ANC, for optimal performance.)

There are three areas where performance can be constrained: memory, disk, and processor.

• Memory constraints occur when you attempt to run more programs in memory than there is actual memory. The hardware allows OS/2 to execute beyond the real memory by allowing paging or swapping, i.e., to allow code and data to be moved from memory to disk. As memory becomes scarce, system performance degrades as access time to code or data written to disk now includes the disk access time required to read back into memory information that was moved out. It probably also required moving off to disk some information to make room for the returning information. This activity can cause extremely poor performance.
• Disk constraints occur when your application requires large number of disk accesses quickly. Since the hard disk must complete one I/O request before starting the next request, multiple requests can start to queue, causing poor performance. Between I/O requests, the hard disk must move the head from one location to the next. Thus a hard drive with slow seek time will become a major bottleneck if the support for high I/O rate is required.
• The processor constraints occur when processor-bound instructions and multiple concurrent tasks require heavy processor time. Since OS/2 is a true multitasking system, the likelihood of becoming CPU constrained is increased as the number of concurrent task execution increases.

The CPU plays a vital role in system performance. It is responsible for processing the millions of instructions necessary to produce work. The speed of the microprocessor (and also the amount of installed memory) typically has the largest effect on the performance of the computer system. The microprocessors system clock rate, measured in millions of clock steps per second, or Megahertz (MHz) dictates the speed at which the system runs. The faster the clock rate, the faster the performance.

Most CPU's in today computer systems are at least 80486 chips. The 80386SX, SL and SLC, as well as the 486SLCx have an external data path of 16 bits while 80386DX and 486DX and above processors have an external data path of 32 bits. This distinction becomes significant as the shift towards 32-bit software begins to proliferate the market. 32-bit instructions, processing on a 16-bit CPU must become two 16-bit instructions in order to be processed. The processor with a 16-bit external data path can result in about 10% lower performance than an identical processor of the same speed with a 32-bit data path. The following charts illustrate the various processor chips, their respective speeds and their cache option.

Feature 386SX 386SL 386SLC 386DX

Speeds available (MHz) 16 20 20 25 16 20 16 20 25 33

Internal Processor Cache N/A N/A 8K N/A

Internal Processing (bits) 32 32 32 32

External Data Path (bits) 16 16 16 32

Feature 486SLC 486SLC2 486SLC3 486SX 486SX2 486SL 486DX 486DX2 486DX4

Speeds available (MHz) Numbers represent both internal and external processor speeds. 25 40/20 50/25 60/20 66/33 75/25 100/33 20 25 33 50/25 25 33 25 33 50 50/25 66/33 75/25 100/33 100/50

Internal Processor Cache 16K 8K 8K 8K 8K 16K

Internal Processing (bits) 32 32 32 32 32 32

External Data Path (bits) 16 32 32 32 32 32

Note: The 486SLC2 processor runs internally at twice the speed of the rest of the system, such as 40/20MHz producing performance faster than a 25MHz 486DX, but less than a 50MHz 486DX. It is up to 271% better than a 20MHz 386SX, up to 99% faster than a 20MHz 386SLC, up to 53% faster than a 20MHz 486DX and up to 20% faster than a 25MHz 486DX. The 50/25MHz 486SLC2 is faster than an Intel 33MHz 486DX.

Feature Pentium P5 Desktop Pentium P54C Desktop Pentium P54LM Notebook

Speeds Available (MHz) Numbers represent both internal and external processor speeds. 60 66 75 90 100 120 133 150 166 200 75 90 100 120 133 150

Clock Multipliers (e.g., 2X = 133/66MHz) 1X 1.5X, 2X, 2.5X, 3X 1.5X, 2X

Internal Processor Cache 16K 16K 16K

Internal Processing (bits) 32 32 32

External Data Path (bits) 64 64 64

The Pentium Pro processor (also known as the P6 processor) is the latest generation processor family from Intel. The Pentium Pro processor includes significant architectural innovations and enhancements, like Dynamic Execution, multiple branch prediction capabilities, 256K L2 cache in the package, etc. The result is a significant boost in system performance -- especially with 32-bit software. Since OS/2 and especially OS/2 Warp 4 is a 32-bit operating system, the Pentium Pro processor delivers optimal performance with 32-bit OS/2 applications.

A summary of the performance data between P6 and P5 is given below. The experiment was done on a P6 processor running at 150 MHz, 256 KB Level 2 cache, 32MB of physical memory, 1.28 GB IDE hard drive, Matrox PCI display adapter card. All measurements were done with the display resolution set at 1024x768x256 except where it is noted. The P5 system is from Micron Technologies. It has a P5 processor running at 133 MHz, 256 KB Level 2 cache, 32 MB of physical memory, 1 GB SCSI hard drive, and Matrox PCI display adapter card. Again, all measurements were done at 1024x768x256 resolution except where it is noted. OS/2 Warp Connect was used on both systems with no special options or setup. OS/2 Warp was installed with multimedia support using the default installation options. The FAT file system was used in the study with default dynamic disk cache size.

There are five types of benchmarks used in the study:

In general, the average ratio of performance improvement for P6 over P5 is 1.63. In particular, the ColorWorks and DIVE benchmarks seem to gain the most, more than 2X improvement, while others tend to gain somewhere around 50%. The BRender 3-D library from Argonaut Tech which is built upon DIVE seems to take the full advantage of the P6 floating-point performance. Its ratio of performance is around 1.88, almost twice of that P5. It is also observed that applications that are computational intensive such as 3-D graphics rendering in the MicroStation benchmark gain about 1.5X on the P6 platform. The industry standard graphics test from GPC using the CDRS and DX viewsets also scores well on the P6, around 1.5 times over P5. The legacy OS/2 applications benchmark which is a mix of 32- and 16-bit code ran only 30% faster on the P6. The chart below illustrates the average measurements and the performance ratio between the two systems.

Processor: P6-150 P5-133 P6/P5

Manufacturer: Intel Micron Ratio

Memory Configuration: 32MB 32MB

Display Resolution: 1024x768x256 Improvement

Display Adapter: Matrox Matrox for P6

Applications Metrics

BYTEmark 2.0 iterations/sec 1.49

OPENGL - CDRS frames/sec 2.23 1.51 1.47

OPENGL - DX frames/sec 0.89 0.58 1.53

VISUAL AGE - Visual Builder seconds 80.4 104.4 1.3

MOVIE PLAYER - Bundy seconds 13.78 20.01 1.45

SAS seconds 16.4 27.84 1.7

Argonaut - Robot frames/sec 64 34 1.88

ColorWorks seconds 14.06 31.02 2.21

MicroStation seconds 31.55 46.94 1.49

Legacy Apps (Describe, Amipro, L123, IBM C++) seconds 61.5 80.5 1.31

DIVE frames/sec 273 128 2.13

Average 1.63

Geometric Mean 1.61

NOTES: 1. ColorWorks was run at display resolution 1024x768x16M

• Industry Standard Architecture (ISA) bus, often referred to as "AT bus". This bus is the 16-bit bus initially developed for IBM's AT (Advanced Technology) computers. The bus includes 8-bit slots for downward compatibility with earlier adapters, but includes 16-bit slots for improved, AT-compatible adapters such as 16-bit VGA adapters. It supports data rates of 8MB/sec.
• Micro Channel Architecture (MCA) bus. A proprietary 32-bit bus used in IBM PS/2 computers. This bus operates at 10MHz with burst data rates of up to 80MB/sec.
• Enhanced Industry Standard Architecture (EISA) bus. A 32-bit bus that, unlike the MCA bus, is backward compatible with ISA adapters.
• Peripheral Component Interconnect (PCI) bus. A 32-bit bus standard used in most new computers. This bus provides the greatest performance of all the above, operating at 33MHz with burst data rates of up to 132MB/sec.

The system bus plays an important role in balancing system performance. If you have a high speed CPU and video adapter on an ISA bus system, this system is not well balanced. The CPU is a great deal faster than the system bus. For example, if your processor is a 486DX 33MHz CPU and you have an ISA bus VGA video adapter (remember, ISA is 16-bit), the system has the capability to transfer data at speeds greater than 33MB/second but the ISA bus can only transfer data at 8.33MB/second. While this isn't a very practical example, it illustrates the potential for an imbalanced system caused by a system bus that is slower than the processor, particularly when running I/O intensive applications such as databases.

Memory, often referred to as random-access memory (RAM), is the computer's primary storage space used to execute instructions. Memory is generally available on the system board and/or on adapter cards. The speed of the memory is expressed in nanoseconds, with the lower the value the better.

Memory speed is important in that faster memory provides faster access to the information stored there. Memory location is also important. Memory on the system board (motherboard) can generally be accessed by the processor faster than memory located on an adapter card. The adapter card memory requires access through the system bus, slowing down the time from processor to memory.

Having adequate memory in a system will also reduce the disk access because paging or swapping is decreased. If the operating system does not have to handle paging I/O requests, system performance will improve. If the swap file is large, and changing from one application to another results in I/O requests, the system would benefit from additional memory or performance tuning.

It is important to note that the number of unique pages accessed during a sliding window of 12 snapshots (1 minute) taken on the same system but with 40MB of memory (unconstrainted memory scenario) is as follows.

OS/2 Warp 4 Connected 25.27MB

Fixed disk performance is important to the overall performance of a computer. The performance of a fixed disk refers to the rate at which information can be located and transferred between the fixed disk and the memory. The disks average seek time, average latency and data transfer rate determine how the disk subsystem will contribute to or hinder overall system performance. These disk performance statistics are generally available from the disk manufacturer.

Data on a fixed disk is stored in concentric rings, or tracks, on the disk surface. To read from a fixed disk, the actuator must first move the read/write head to the proper track. The average time it takes for the actuator to move the read/write head over the proper track is called the average seek time - usually expressed in milliseconds.

Once the read/write head is located over the right track, it must wait until the disk rotation brings the right part of the track under the read/write head. The average time it takes for this to happen is the average latency of the drive - also expressed in milliseconds.

Finally, after the proper track and proper part of the track are positioned under the read/write head, the information is transferred between the disk and the disk controller circuitry, one bit at a time in a continuous stream as the disk surface passes underneath the read/write head. The speed at which this is done is called the data transfer rate and is expressed in millions of bytes per second (MB/second).

It is important to consider the disk drives performance statistics when purchasing a computer system. These statistics play an key role in the overall performance of the system. The shorter the seek time and latency the better. The higher the data transfer rate the better. All of these factors determine how the disk subsystem will contribute to or hinder overall system performance.

OS/2 Warp 4 provides significant new function compared to OS/2 Warp Connect. Depending on the selections you make during installation, this version will require a maximum of 350 megabytes of hard disk space. The following table indicates how much disk space is consumed by each selectable component. It will be very useful in planning your installation.

• If you have a very large partition (> 1 GB) formatted for FAT, the install will require 550 MB due to the large cluster size required by the FAT file system.
• Failure to provide sufficient hard disk space will result in installation failures and will require re-installation.

During the installation process, you will be asked to select which of the following install options: Advanced Install or Easy Install.

If you selected the Advanced installation option then you would see the OS/2 Setup and Installation screen which enables you to configure the software. The list of software that you can select in OS/2 Warp 4 is as follows.

Disk Space Default

Assistance Center 10.03 MB

OS/2 Tutorial 4039 KB

OS/2 Command Reference 825 KB Yes

REXX Information 768 KB Yes

OS/2 Warp Guide User Interface Agent 4,367 KB Yes

Fonts 2.42 MB Yes

Courier 273 KB Yes

Helvetica 629 KB Yes

System Mono-Spaced 86 KB Yes

Times Roman 596 KB Yes

Courier (outline) 320 KB Yes

Times New Roman (outline) 259 KB Yes

Optional System Utilities 2.29 MB Yes

Backup Hard Disk 27 KB Yes

Change File Attributes 36 KB Yes

Display Directory Tree 33 KB Yes

Manage Partitions 233 KB Yes

Label Diskettes 33 KB Yes

Link Object Modules 450 KB NO

Picture Viewer 122 KB Yes

PMREXX 146 KB Yes

Recover Files 45 KB Yes

Restore Backed-up Files 35 KB Yes

Sort Filter 31 KB Yes

Installation Utilities 419 KB NO

Create Utility Diskettes 192 KB Yes

Service/Diagnostic Aids 542 KB Yes

Optional System Components 2.30 MB Yes

OpenDoc 5,842 KB NO

Voice Type 23,753 KB NO

Security 496 KB NO

Bonus Pak 36.42 MB NO

CompuServe 2,736 KB NO

HyperAccess Lite 656 KB NO

IBM Works 14,411 KB NO

Fax Works 1,266 KB NO

VideoIn 467 KB NO

AskPSP 4,008 KB NO

Remote Support Tool 1,441 KB NO

Printer Utilities

JetAdmin 560 KB NO

JetAdmin Port Driver 1,645 KB NO

MarkVision 4,879 KB NO

MarkNet Port Driver 5,238 KB NO

Tools and Games 24.19 MB

Enhanced Editor 1,933 KB Yes

Search and Scan Control 68 KB Yes

OpenGL 1.0 3D Library 4,905 KB NO

Optional Bitmaps 10,073KB NO

Solitaire-Klondike 2,762 KB Yes

Pulse 43 KB Yes

Chess 2,828 KB Yes

Mahjongg Solitaire 2,151 KB Yes

OS/2 DOS Support 1.54 MB

DOS Protected Mode Interface 29 KB N/A

Virtual Expanded Memory Management 19 KB

Virtual Extended Memory Support 9 KB N/A

WIN-OS/2 Support 6.11 MB

Readme Files 136 KB Yes

Accessories 1,039 KB Yes

Screen Savers 73 KB Yes

Sound 115 KB Yes

Multimedia Support 22.41 MB

Base Multimedia Support 19,294 KB Yes

Multimedia OpenDoc Support 2,929 KB NO

Software Motion Video 728 KB Yes

High Performance File System 470 KB Yes

Network Services

File and Print Client 13 MB

TCP/IP Services 28 MB

Remote Access Client 4 MB

System Management Client 7 MB

Netware Client 6 MB

Mobile Office Services 3 MB

• Selecting All Features During Advanced Install - A Full install requires approximately 275 megabytes for code and data, 25 megabytes for SWAPPER.DAT, and 50 megabytes for any additional programs and applications.
• Deselecting Features During Advanced Install - A single 350 megabyte partition is the least complex environment. You can deselect some features or install some features to partitions other than the OS/2 boot partition. The following features allow partition selection during install:
• Speech
• BonusPak
• Connect
• Java
• Multi-Media
• Windows Emulation
• Using Easy Install - Easy install selects a subset of OS/2 features for installation on the C: partition. This selection is based on the hardware configuration. For example, Multi-Media is installed if a sound device is detected. Some features that are not installed during Easy Install are:
• Opendoc
• Java Toolkit and Samples
• BonusPak
• Security
• Some optional BITMAPS
• Some documentation for Command Reference and REXX
• The selection panel for Connect allows installation of features consistent with the connection hardware and software. Easy install requires between 150 and 200 megabytes depending on your selections and hardware configuration.

Computers can provide video support on the system board or on an adapter. Video support is identified by the mode and resolutions that they can support. The greater the resolution and number of colors, the better the picture. Unfortunately, better resolution and more colors usually translate into slower system performance.

VGA (Video Graphics Array) was introduced in 1987 and soon became a popular video standard. VGA systems are capable of displaying 16 colors at a resolution of 640x480.

SVGA (Super VGA) refers to a group of high-resolution analog video adapters. SVGA provides higher resolutions and more colors than VGA adapters. Most SVGA adapters with 1MB of video memory are capable of displaying 256 colors in a resolution of 1024x768.

XGA (Extended Graphics Array) was introduced by IBM in 1990. It is an accelerated analog video adapter which uses a coprocessor to provide hardware-assisted drawing functions. XGA-2 is a newer version of XGA which includes performance improvements, higher refresh rates, non-interlaced mode and support for resolutions of 1360x1024 with 16 colors.

Many new video adapters are coming available that can't be classified as VGA, SVGA or XGA. They are using new and more powerful chipsets that show improved performance over SVGA by using on-board processors for some graphics functions. These chipsets are called accelerators. They include previously discussed XGA chipsets, as well as new accelerated SVGA chipsets such as S3, Weitek P9100, Mach 8/32 and Tseng W32i.

Two main features on your graphics card affect video performance—the first, the card's onboard memory, and the other the card's accelerator chip and bandwidth.

There are three common types of onboard memory found on graphics cards, Dynamic RAM (DRAM), Window RAM (WRAM), and Video RAM (VRAM). DRAM is cheap, but its single-ported design requires a system clock cycle to reset the chips before each refresh of screen data. VRAM is dual-ported, able to deliver data and reset in a single clock cycle for inherently faster performance. It's also more expensive than DRAM. WRAM is a form of VRAM that does faster fills and accellerates video playback and animation. WRAM is not only dual-ported, but also requires fewer transistors than VRAM, hence lowering costs while providing a few graphics-specific speed-ups such as support for aligned bit-block transfers (BitBlts).

The type of graphics memory you choose is almost as important as the amount. DRAM is the least expensive, but its single-ported design makes it relatively slow; dual-ported VRAM is more costly, but much quicker for true-color work. A variety of other single-ported (such as EDO DRAM and SDRAM) and dual-ported (such as WRAM) variations fall between the two on

the price/performance scale.

The graphics accelerator cards architecture, or more specifically, it's bandwidth also plays a crucial role in graphics subsystem performance. Bandwidth is defined as the amount of information that can move along the cards data path. The bandwidth between the graphics card's accelerator chip and its display memory can be as wide and quick as graphics card manufacturers care to make it. Over the last several years, 32-bit graphics accelerators have yielded largely to 64-bit accelerators, with 128 bit cards becoming more and more common. To keep refresh rates high, team a fast 64-bit or 128-bit accelerator with dual-ported display memory to handle the volume of data that true-color and multimedia applications demand.

Machines with a buffered UART (Universal Asynchronous Receiver/Transmitter), for example the 16550A will have better communications performance than machines without buffering, for example the 16450. The performance of DOS communications programs is particularly impacted by using systems with these buffered communications chips on their COM ports. The MODE command can be used to determine whether your system has this buffered UART. A buffered UART at level 16550A or equivalent is nearly essential for high speed communications. Use the command: MODE COMx, where x is the communications port number. If you see "BUFFER=N/A" then you do not have a buffered UART for that port.

HPFS has two limitations. Native DOS applications can't see HPFS formatted disks (although DOS programs running in OS/2 Warp can and there exists a driver to read HPFS disks from plain DOS), and the HPFS driver takes approximately 264KB of memory.

• Install only the file system needed by the operating system accessing your data. If you plan to boot a DOS or Windows system natively (via the dual boot option), then any data that will be accessed must exist on a FAT disk partition. However, If you will only be running DOS and Windows applications in an OS/2 Warp VDM (Virtual DOS Machine), then the file system can be either HPFS or FAT. Also, when accessing a file on a server, and the server file system is HPFS, you do not need to install HPFS on your local client machine. HPFS only needs to be installed on a computer when a partition on a local hard disk is formatted as HPFS.
• FAT is best suited for disk partitions that are 80 MB or less in size or that have a limited number of files installed. Usually, 256 files is a good target, with up to 500 acceptable. The number of files become important because FAT files are allocated based on a cluster size. The cluster size is determined by the size of the disk partition and can be 2K, 4K, 8K or higher. Since most file sizes are not an exact multiple of the cluster size, disk space is not optimally used. For example, installing DOS, Windows and OS/2 Warp on a 100MB partition resulted in 2.2 MB of disk space that could not be used. A 100MB partition will use a 2K cluster size. If you were to use a 540MB partition size, then your cluster size would be increased to 16K and a significantly greater amount of disk space will be lost.
• HPFS files are allocated based on a 512 byte granularity instead of a cluster size, therefore fragmentation is greatly reduced. Also HPFS is especially efficient when handling large partition sizes, > 100 MB, and large numbers of files, > 500. One thing you should look out for is to not allocate more than 5000 files in a sub-directory or directory. Allocating more than 5000 files can lead to degraded performance. The HPFS file system shipped with the OS/2 Warp product has a cache limit of 2 MB.
• It is recommended that HPFS be installed on systems with 16MB of memory or more and large disk partitions. If HPFS is not being used, you should remark the HPFS driver from the CONFIG.SYS file. This driver uses 264KB of RAM. If the HPFS statement configures a HPFS cache, the maximum amount of RAM consumed by the cache and the driver could be at much as 2312KB (264KB for the file system driver + 2048KB for the max cache size = 2312KB). Even if there is no HPFS partition on your system, it will cost between 200 and 250K in working set memory, as well as the space for the HPFS cache. If you are installing OS/2 Warp on an existing DOS and or Windows system, you should not install HPFS. When your system is up and running, you can check the working set of your system. If there is enough free memory and you wish to create a HPFS partition, then you can use selective install to install the HPFS support. Remember that any data stored in the HPFS partition can not be accessed if you boot your machine under DOS.
• Use HPFS if your application uses many small files or a very large data file like in database applications.
• Both FAT and HPFS file systems have disk caching, lazy writing and read-ahead. File system parameters can be changed after installation. The default values set by the installation procedure are good for average users.
• It is recommended that when you set up your hard disk, you create a minimum of 3 partitions. One will be for the operating system(s), one for your applications and static data files, and another for dynamic data files and temporary files. Decide whether you want to use Boot Manager or Dual Boot. If you select Dual Boot, then OS/2 must be installed with the FAT file system.

Response time is the key indicator used in measuring and tuning a system. It can be defined as the time interval from when a user initiates a process until that process has completed. For example, response time can be measured as the interval of time from when a user presses the enter key to initiate a database query until the data is displayed on the screen.

The productivity of a OS/2 Warp 4 user is largely dependent on adequate system response time. The user should be able to interact freely with the application without having to wait for the system to respond. Response time requirements may vary among users and even among applications. A three to fifteen second response time may be adequate for a complex inquiry application that is only run occasionally, but a sub-second response time may be required for more frequently used applications such as word processors or spreadsheets.

This section introduces the concept of performance monitoring, measurement, and tuning. It also covers performance tools shipped with OS/2 Warp 4 as well as tools available from external sources.

Monitoring the performance of critical system resources is invaluable in identifying the cause of performance problems. Performance monitoring is the first step to take in solving performance-related issues. There are numerous performance monitoring tools that measure response time, disk activity and other variables that impact the performance of the system. These tools will assist in understanding possible causes and subsequent resolution of the problem. Once the problem has been identified, the process for alleviating it can begin. This process, or tuning methodology, needs to be well thought out and documented through to resolution.

A benchmark is a test that measures the performance of a system or subsystem on a well-defined task or set of tasks. Test scenarios, or benchmarks, are designed to achieve consistent repeatable results during the tuning process. Benchmarks are necessary for creating an effective, systematic approach to performance tuning your system. The benchmark should represent a work environment very similar to the one being tuned. Benchmarking is essential for measuring progress while tuning a system.

Characteristics of a good benchmark include:

• Each test is repeatable.
• Each iteration of a test is started in the same system state.
• There are no functions or applications active in the system outside the ones being measured unless the scenario includes some amount of other activity going on in the system. Do not even have them started and sitting idle, since this will use up RAM resources and increase the likelihood of swapping.

Benchmarks can also be used as monitoring and diagnostic tools. By running a benchmark and comparing the results against a known configuration, you can potentially pinpoint the cause of poor performance. Similarly, a developer can run a benchmark after making a change that might impact performance to determine the extent of the impact.

The OS/2 WarpCenter provides a CPU monitor utility that shows the system activity and a disk space monitor program that shows the amount of disk space available in all partitions. In addition, there are many other operating system utilities that you can use to check your system integrity if you perceive a performance degradation has occurred. They are as follows.

• CHKDSK - disk integrity checking
• HDMON - hard disk monitoring
• PROFILER - file repairing
• PSTAT - process monitoring
• RMVIEW - resource allocation monitoring
• SYSLEVEL - operating system and corrective service level analyzing
• TRACE - events tracing

CHKDSK can detect lost clusters on your disk. These are parts of files that the system did not save completely and that take up space on your disk. If CHKDSK finds these, it prompts you with a message asking if you want to convert lost chains to files. If you type a Y (yes), CHKDSK converts these parts into files that you can examine and delete to save space on your disk. If you type an N (no), CHKDSK deletes these parts of files from your disk. The files CHKDSK creates from lost chains follow this naming convention: FILEnnnn.CHK (nnnn is a sequential number starting with 0000).

• To start chkdsk, type the following command in any OS/2 window.

• Type this command at a DOS command prompt to produce a memory storage report.
• CHKDSK gives accurate information only when a hard disk is not in use.
• CHKDSK does not work in DOS sessions on drives that have an ASSIGN, JOIN, or SUBST command in effect. Also, CHKDSK does not work on network drives.
• You should run CHKDSK occasionally on each disk to check for errors. If errors are found, CHKDSK displays the error messages and produces a status report. If you enter a file name after CHKDSK, the OS/2 operating system displays a status report that gives the number of noncontiguous areas occupied by the file. CHKDSK also produces a storage report.
• To search for and recover lost file clusters on the drive that is the hard disk from which you normally start the OS/2 operating system, follow these steps:

• To recover lost clusters on the drive that contains CHKDSK, you can also copy CHKDSK to another drive and run it from that drive by specifying the drive and path.
• If the /F parameter is not specified and there are open files, CHKDSK may report lost clusters on the disk. This happens when open files have been written to but the file allocation table (FAT) is not updated. If many clusters are reported as lost, use the /F parameter to search the disk.

The Hard Disk Drive Monitor uses Self-Monitoring, Analysis, and Reporting Technology (SMART) to monitor the status of physical drives in the system. A hard disk drive must be SMART-compatible for the Hard Disk Drive Monitor to be able to detect potential failures in that drive.

• To start the monitor, type the following command in an OS/2 window.

• The Hard Disk Drive Monitor program periodically checks the status of the SMART-compatible drives being monitored. In the Configuration screen, you can specify how frequently the status is checked. To view the Configuration screen, click on Options from the menu bar, and then click on Configuration. The value shown in the Configuration screen is the monitoring interval, in minutes. Click on the up-arrow or down-arrow button, or type a new value, to change the monitoring interval to any value from 1 to 60.
• The Hard Disk Drive Monitor checks status only if disk activity has occurred during the monitoring interval. The APM Scan option, which is enabled and disabled in the Configuration screen, allows the Hard Disk Drive Monitor to monitor drives while the computer is in an Advanced Power Management (APM) reduced-power state. If the APM Scan option is enabled, the Hard Disk Drive Monitor will check the drives every four hours, even if the computer is in a reduced-power state and no disk activity has occurred. If the APM Scan option is disabled, monitoring will occur only if disk activity has occurred during the monitoring interval. To enable the option, click on the radio button that reads, "Enabled."
• If the Hard Disk Drive Monitor indicates that a drive has a potential failure condition, you should back up that drive immediately, to avoid losing valuable software and data if the drive actually fails. However, the Hard Disk Drive Monitor is not to be used as a substitute for regular backups of the drive and may not detect all predictable failure conditions. Hard drives will also fail for reasons that are not predictable through use of SMART. In some situations, the Hard Disk Drive Monitor will not detect a potential failure condition soon enough to allow you to back up the drive before it fails.
• The main Hard Disk Drive Monitor screen displays a Drive icon for each hard disk drive being monitored. The colored indicator on each Drive icon indicates the status of that drive, as follows:
• Green indicator - OK

• Flashing red indicator - Alert

• Grayed-out indicator - Not SMART-compatible

Analyzes files on the specified drive and displays information about unusually fragmented files that do not meet the multimedia format requirements. You can use the PROFILER utility to correct files that do not meet multimedia requirements.

A fragmented file, although logically intact, is divided into blocks that are stored in different physical locations on the disk. Fragmentation is often necessary for the efficient use of disk space, but unusually fragmented files (those divided into small, scattered blocks) are not well suited for multimedia applications.

• To start the utility, type the following command in an OS/2 window.

• The PROFILER utility fixes a file that fails to meet the multimedia format requirements by copying it to a temporary file, deleting the original file, and then renaming the temporary file. This process reduces the amount of fragmentation in the file. The amount of fragmentation that is reduced depends upon the fragmentation of the drive's free space.
• If the 386 HPFS Local Security is installed, ADMIN privilege is required to execute the PROFILER utility.
• To capture all of the information displayed by the PROFILER utility, redirect its output to a file (for example, PROFILER /V D:\DIR > C:\PROFILER.OUT).

PSTAT displays process status information, such as current processes and threads, system semaphores, dynamic-link libraries, and shared memory. PSTAT helps you determine which threads are running in the system, along with their current status and current priorities.

• This command also aids you in determining why a given thread is blocked (waiting for a system event), or why the thread's performance is slow (low priority compared to other threads.) Moreover, it displays the process ID that has been assigned from each process. The process ID can then be used as input to the TRACE utility program for tracing on a per-process basis.
• To start PSTAT, type the following command in an OS/2 window

• Enter this command without a parameter to display information about the following:

This utility displays operating-system service level

• To start the program, type the following command in an OS/2 window.

• The following message will appear while SYSLEVEL checks the current corrective service level of your system

• Once the corrective service level has been determined the following will be displayed on your monitor.

• An example of the information displayed and an explanation of the displayed items follows:

This utility displays the allocation of the hardware resources in your computer.

• This is useful when resolving resource conflict or when installing a new piece of hardware on your computer.
• Type this command at an OS/2 prompt followed by any of its optional parameters. If no parameters are entered, RMVIEW defaults to the physical view which can also be specified with the /P parameter. This is useful when resolving resource conflict or when installing a new piece of hardware on your computer.
• RMVIEW Command: /P Parameter

• RMVIEW Command: /P1 Parameter

• RMVIEW Command: /D Parameter

• RMVIEW Command: /DA Parameter

• RMVIEW Command: /D1 Parameter

• RMVIEW Command: /DC Parameter

• RMVIEW Command: /DP Parameter

• RMVIEW Command: /L Parameter

• RMVIEW Command: /IRQ Parameter

• RMVIEW Command: /IO Parameter

• RMVIEW Command: /IOA Parameter

• RMVIEW Command: /DMA Parameter

• RMVIEW Command: /MEM Parameter

• RMVIEW Command: /HW Parameter

• RMVIEW Command: /SO Parameter

• RMVIEW Command: /R Parameter

The System Trace facility is used to record a sequence of system events, function calls, or data. The record is usually produced for debugging purposes. After the trace data is recorded, the System Trace Formatter is used to retrieve it from the system trace buffer and format the data to your display, printer, or file.

• This command is intended to be used with the assistance of your technical coordinator.

• The OS/2 operating system processes TRACE statements in the order in which they appear in the CONFIG.SYS file; the effects of the statements are cumulative. If any part of a statement is incorrect, the OS/2 operating system ignores the statement.
• If you do not specify TRACE in the CONFIG.SYS file, events are not traced. However, if you have a TRACEBUF statement in CONFIG.SYS, this allocates a trace buffer. Then, you can trace events by entering the TRACE command at the OS/2 command prompt.
• If TRACE=OFF or TRACE=ON appears in the CONFIG.SYS file without a TRACEBUF statement, the system allocates a 4KB trace buffer.
• If you do not specify TRACE or TRACEBUF statements in the CONFIG.SYS file, OS/2 does not allocate a trace buffer and system tracing is not available.
• If a system problem can be duplicated without a system failure, the TRACE OFF function allows tracing to be stopped after the problem has been re-created. This allows the state of the trace buffer to be preserved from the time the TRACE OFF command is processed.
• The tracing mechanism is performance critical; therefore, no statistical processing of recorded data is performed by the tracing routines.
• If you need to use the System Trace facility, your technical coordinator will provide the buffer size. When the trace is complete, you can use the trace formatter (TRACEFMT) to organize the data into a report. This helps you isolate causes of problems in the OS/2 system by formatting the information placed in the trace buffer by the Trace facility.
• An OS/2 enhancement to the Trace utility program allows you to trace a given process or set of processes, so that you can focus on the events of the specified process without intermixing events from other processes in the system. This reduces the possibility of trace-buffer overflow by minimizing the number of events which are recorded. Analyzing the formatted trace data is quicker and easier because only events of the specified process are recorded and displayed.
• You use the TRACEFMT utility program to format the information placed in the trace buffer by system trace. TRACEFMT is a Presentation Manager application running in a window. TRACEFMT can capture the current contents of the trace buffer, or can read an unformatted trace file. This trace entries can be searched, or a subset can be chosen to narrow the displayed entries to only those of interest. The TRACEFMT application provides choices on the menu bar. Your technical coordinator will analyze the formatted data to help diagnose your problem. You can use TRACEFMT as many times as required to diagnose a problem without having to restart the system.

TRACEGET is used to capture the contents of the trace buffer into a file. This file can then be loaded into the trace formatter, or sent to your service coordinator. A technical coordinator will analyze the formatted data to help you diagnose problems.

There are several useful external tools for monitoring and tuning the performance of an OS/2 system some of which are discussed in the following.

SPM/2 2.0 is an integrated package of powerful facilities that enable you to monitor resources such as CPU, RAM and disk on your local and remote OS/2 systems. SPM/2's ability to graph this resource information enables you to look at real-time data as well as saved data for any monitored workstation on the LAN. SPM/2 performs the following tasks:

• Collects critical resource utilization data from the CPU, memory, file I/O, swap file, FAT and HPFS cache, physical disk, printer, and communication ports.
• Records performance data to disk for processing at a later time.
• Provides a real-time or historical graphical representation of how system resources are being used (CPU, disk, RAM,and swap activity); it also has the ability to play back previously recorded data.
• Produces detailed resource utilization reports from recorded data that can be summarized by workstation, application, process or thread.
• Provides in-depth OS/2 memory analysis information that includes the working set and a view of OS/2 control blocks.
• Monitors remote OS/2 LAN Requesters and servers.

This tool, excellent for novice users, is a simple aid for tuning your system. It provides a way to change the CONFIG.SYS file and remove unnecessary files to free disk space.

CPU Monitor offers a selection of performance and analysis tools for OS/2 users. Using Presentation Manager graphics, CPU Monitor displays real-time information for estimated CPU utilization, OS/2 process relationships, and more. CPU Monitor enables you to dynamically suspend and resume execution for individual threads and helps you detect and stop runaway, invisible, and background programs.

This integrated group of applications is designed for real-time tracking and performing capacity planning functions for system resources including CPU, disk, memory, and applications. OSRM/2 monitors most of the paramters that SPM/2 does but it also works on symmetric multiprocessor (SMP) systems.

In general, performance tuning consists 4 steps:

A sound understanding of the problem is critical in monitoring and tuning the system. You should understand the problem in detail rather than at a high level like "the system is slow". Ask specific, pointed questions, like:

• If the system is slow, how slow is it?
• What activity is slow?
• How long does the activity usually take?
• Does the problem occur when using a particular application, when accessing a disk, or communicating remotely?
• What performance do you expect or believe is reasonable?

Be able to quantify the problem and when possible, obtain supporting data. As you are obtaining additional data, your problem description should become more focused.

You should also find out all you can about what has recently been done to this system that may have affected its performance. You may find that additional software has been installed, additional communications sessions were defined, or even that some of the memory has been removed.

Also consider the environment this system is working in. Environmental factors that can affect performance might include:

• Stand-alone or LAN environment
• Communication links
• Hardware configuration (memory, disk space, CPU, coprocessor)
• Applications running concurrently

Once you understand the problem, you should define a realistic goal for improvement. How will you know when the performance is acceptable? It may be easy to identify your desired goal, but you might not immediately know whether this goal is realistic.

After you have identified the problem and the environmental factors that affect it, you can narrow down possible causes and solutions. This involves identifying possible bottlenecks, verifying whether they are indeed bottlenecks, and devising possible solutions to alleviate them. Be aware that once a bottleneck is identified and steps are taken to relieve it, another bottleneck may suddenly appear. This may be caused by several variables in the system running near capacity.

Bottlenecks occur at points in the system where requests are arriving faster than they can be handled, or where resources, such as buffers, are insufficient to hold adequate amounts of data. Finding a bottleneck is essentially a step-by-step process of narrowing down the causes of the problem:

• Identify the hardware component
• In a networked environment, try to determine whether the bottleneck is occurring on the client or the server. If neither system seems to have a problem, check the physical network and all connectivity devices.
• Identify the resource that is affected
• A performance monitoring tool can be used to monitor system resources and indicate which resource is being overused.
• Consider what is happening internally when the function is performing poorly
• Consider all the steps undertaken by the poorly performing function. For example, if the system is sorting a remote database file, there should be heavy CPU and memory utilization. If you see a lot of disk activity this may indicate excessive memory paging and/or poor cache utilization.

Now that you have identified potential bottlenecks and have selected a performance monitoring tool, you need to have a plan to move forward into the tuning process. There are five basic components in a performance tuning methodology that apply to all cases:

• Define the problem
• Hypothesize solutions
• Design tests
• Set values and run tests
• Analyze the results

Use the process described earlier in this chapter to ensure a complete and thorough understanding of the problem.

Narrowing in on the cause of a performance problem is an iterative process, involving identification of possible bottlenecks and verification of whether they are indeed bottlenecks. It is important to make sure the correct bottleneck has been identified before pouring in resources to alleviate it. If not, unnecessary expense may be incurred by adding resources that do nothing to improve performance. For example:

• RAM could be added to a database server in order to increase the size of the buffer pool, only to find out that the problem is inappropriate indices, not a small buffer pool.
• A faster CPU could be purchased, hoping to improve response time. Although response time may indeed improve slightly with a faster CPU, it might later be discovered that the real bottleneck is insufficient buffer space on the adapter card or a slow fixed disk (in the case of an I/O intensive application). Hence, it is important to think through several possibilities and test them out. Once a bottleneck is identified, and resources have been applied to relieve it, another bottleneck may suddenly surface. This may be because several things in your system are running near capacity. Note however that there will always be something in the system that is the gating performance factor. Depending on the workload, this factor may or may not be an actual bottleneck.

To increase the capacity at a bottleneck, think of ways to offload the work arriving there or improve its capacity, through hardware or software. From there, come up with hypotheses of things that may relieve bottlenecks and improve performance. Possible examples follow, though in no particular order. Note that changing the values of system parameters may only be one avenue to pursue.

• Faster hardware - e.g. CPU, DASD, communications medium (i.e. adapter or connection)
• Parameter tuning
• Additional RAM or disk space
• Changing the topology - i.e. how many workstations are going through (or to) what servers, controllers, etc.
• Using or increasing a memory cache
• In a swapping system, perhaps reducing the size of buffers or numbers of active applications.
• Application redesign

Given the possible solutions, design tests to try them out. Make sure that these tests are repeatable. Approach the testing effort methodically, testing each hypothesis one at a time.

• Prioritize your ideas from "most likely to have an impact with minimal effort" to "least likely to have an impact with great effort".
• Start with a single hypothesis and decide what you are going to do to prove whether it is true or false. For example, if your hypothesis is to "add more buffer space," then only change the parameter needed to accomplish this.
• If the hypothesis is proven false, restore the parameter and move to the next hypothesis and start the cycle again.

Setting new variable values and running tests is probably the most iterative part of the entire process. In this stage, response time should be measured for specific, repeatable events, both before and after changing a value.

• Change only ONE thing at a time. Changing more than one variable will cloud results, since it will be difficult to determine which variable has had what effect on system performance. The general rule may perhaps be better stated as "change the minimum number of related things." In some situations, changing "one thing at a time" may mean changing multiple parameters, since changes to the parameter of interest may require changes to related parameters. (For example, in Database Manager, changing the BUFFPAGE parameter may require an increase to the SQLENSEG parameter.)
• Start in the same state. Start each iteration of your test with your system in the same state. For example, if you are doing database benchmarking, make sure that the values in the database are reset to the same setting each time the test is run.
• Check for Control. You can never control your testing too much. This mainly involves carefully documenting each step in your tests - to the point of being scientific. This will ensure that you're not doing things differently from run to run, and that you're not introducing new variables that could cloud the results. Writing things down is also essential for going back and recalling exactly what you have and have not tested since it is easy to forget!
• Work on one problem at a time. It is easy to lose control and focus when working with a large number of parameters and components. Additionally, it is likely that anomalies or problems will come up during testing, such as functional problems. While it will be necessary to resolve problems that obstruct your goal of identifying bottlenecks and improving performance, problems that are not directly related to this may need to be put aside for a while, or given to another group to work on in parallel. The point here is to maintain your focus.

Analyzing the results of your tests involves being able to interpret and explain the data you obtain in order to understand what's going on in the system. Information explaining the results should be available with the software tools used for the testing. SPM/2 has very detailed help screens that explain all the parameters it monitors.

After installation, there are changes that you can make to improve the performance of OS/2 Warp 4. Some of these changes like changing desktop settings are general in nature and will make slight improvements in the overall system performance. These changes can be done by any user and are listed in this section. Other changes are more specific for certain system components such as the system swap file, file systems, the CONFIG.SYS file, etc. These changes require certain knowledge of how various OS/2 components interact with each other. Such changes are listed in the next section, "Advanced OS/2 Tuning."

The OS/2 WarpCenter is a customizable, object-based status bar that can remain on top of all maximized windows. You can use the OS/2 WarpCenter to perform OS/2 desktop operations and display information about your system. You can display battery usage, system activity, and disk space monitors. OS/2 WarpCenter monitors the CPU activity on your computer and displays it through the system activity pulse. It indicates periods of low, medium, and high activity.

• The system activity monitor program runs at a very low priority level, therefore, it does compete with your application for CPU cycles. For optimal system performance, you can turn the monitor program off.
• To turn the system activity monitor program off:

OS/2 Warp 4 provides the OS/2 WarpGuide folder which contains guidance objects for selected computer tasks. Some objects have cue cards available to assist you with each step of the task.

• OS/2 WarpGuide is a task-mentor who uses cue cards or wizards to help you complete a task. As a result, anytime you start a task that OS/2 WarpGuide knows about, a OS/2 WarpGuide button appears on the title bar of the window you are using. If your profile indicates you are a novice for the current task, OS/2 WarpGuide automatically shows you cue cards and shades unneeded parts of the window. The shading does not change the way a window works. You can still click on the areas under the shading. If your skill level is intermediate, OS/2 WarpGuide shows only cue cards. If you are an expert, cue cards are not shown, but you can access a cue card for the current task by clicking on the OS/2 WarpGuide button.

• The appearance of the cue cards will affect your system performance because it requires processing time. Therefore, you should turn the cue cards off if you feel you don't need the OS/2 WarpGuide assistance.
• To permanently turn cue cards off:

Animation is the process of drawing boxes on the screen that appear to grow in size culminating in an open folder or session. This gives a nice appearance when drawing the screen objects. Disabling animation will save a small amount of system resource that would otherwise be used to expand and contract graphical brackets around folders as they are opened or closed

• On memory constrained systems, the performance when opening folders and starting sessions can be improved by disabling animation.
• To disable desktop animation:

During installation, OS/2 Warp detects your system display adapter hardware and installs the appropriate display drivers and resolutions. However, the higher the resolution, the more memory that is used. Very high resolution and color support can require 100 to 200K of physical memory. Since the display drivers and resolutions have great impact on your system performance, you can tune your display subsystem as follows.

• To change the display resolution:

• To change the display driver:

• If you are changing from one type of SVGA hardware to another type, it is best if you change the display driver to VGA before you change hardware, then change back again to the correct display driver type. This will keep you from having a display/hardware mismatch that could necessitate reinstalling OS/2. You can also revert to VGA during system boot.

The OS/2 system responsiveness may be better if you minimize frequently used applications between use since accessing a minimized application is always faster than starting the same application. This is also true when frequently working with the same folders.

• When you have applications or folders that you use often, leaving them open at shutdown (or placing them in the startup folder) will cause them to be loaded at system boot time, thus allowing you to access them much faster. However, placing the application in the startup folder will prolong the system boot time because it has to start the application.
• You can use the Minimized Window Viewer to view the applications and folders that have been minimized.

Performance when starting applications can be improved by reducing the application load time.

• To reduce the search time for OS/2 to locate the application, start the application from its own directory or call the application with a fully qualified path.
• Using the icon to start the application is optimal because the icon will have the exact path for the executable file if properly installed.

Applications and folders can be opened several ways. You can open your application faster if you know how to take advantage of the Startup Folder and the OS/2 multitasking feature.

• Applications that were left open at shutdown will reopen at boot time after the Workplace Shell is started.
• Applications placed in a STARTUP.CMD file will also be processed at boot time, after the Workplace Shell is started.
• Applications and folders placed in the Startup Folder will be opened with the processing overlapping the startup of the Workplace Shell.

• Run only programs that are necessary. Close all applications that are not needed.
• Verify that the settings are correct for the application, especially DOS applications that may poll, so that useful tasks are always processing.
• Limit background processing to improve foreground performance by increasing or reducing the application's session priority.

You should use solid colors and avoid the use of bitmaps for desktop and folder backgrounds. These particular options use more memory and require more processing time to display them.

Deselect the System Sounds options, unless you like the sounds when opening and closing your folders. It costs between 250 and 300K in working set just to hear the sound. An additional 40K or so of working set can be saved by executing DINSTSND.CMD in an OS/2 command session. This will unhook the system sounds from the OS/2 desktop. To get them back, you would execute INSTSND.CMD.

There are many fonts supplied with OS/2 and even more supplied with various word processing and graphics applications. Avoid the temptation of installing more fonts than are necessary by installing only the ones that you will use. You can always install others later if you should need them. This simple exercise of restraint will improve performance when loading applications that use fonts. Each installed font uses at least 2KB of memory, even if it is not being used. This number increases significantly when you actually use the font in an application.

When you have a choice of choosing which kind of fonts to install on your system, remember that outline fonts are more efficient than bitmapped fonts because the characters are cached into memory. With bitmapped fonts, the entire character rendering is loaded into memory. Bitmapped fonts are defined for a specific screen resolution and display type, whereas outline fonts are scaleable and tailored to the specific device installed on the system.

Mouse pointers are basically bitmaps. The amount of memory used will be affected by which mouse pointer style you choose. If you activate the comet cursor, this will cost additional memory and processing time whenever the mouse is being used.

It is important to close folders and applications when they are no longer being used. Although a large portion of unused programs will be swapped out, some portion of every program is non-swappable and will use memory for as long as the program is active. The more active programs in the system, the more memory will be used.

As placed ( or Flowed) icon views offer faster performance than Gridded views for folders containing multiple objects. The operating system has to retrieve an objects coordinates from the OS2.INI if a Gridded view is being used. Flowed views display one object after another without keeping track of specific coordinates.

You should also restrict the use of programs which, as a class are more decorative than useful. That is, the amount of function they provide is low compared to the memory they use. These programs, like screen savers, clocks and animated icons should not be used on systems with a limited amount of memory.

There are many more tuning parameters for an OS/2 system than discussed in the previous section. This section will detail advanced tuning parameters and explain how they can be used to further improve your system performance. This chapters focus will be on tuning parameters that optimize the Workplace Shell, task scheduling, CONFIG.SYS and AUTOEXEC.BAT files.

The Workplace Shell starts automatically when OS/2 is booted. The Workplace process is the one under which all the Workplace Shell classes are loaded and initialized. Therefore, objects representing Workplace Shell classes and their subclasses must run on this process. The Workplace process is actually launched from the Shell process, which is the process indicated in the SET PROTSHELL= statement in the CONFIG.SYS file. Once the Shell process is running, it starts the Workplace process. The Shell process is responsible for restarting the Workplace process in the event that it is ended as a result of a trap.

• The PROTSHELL= statement in the CONFIG.SYS file indicates which process is to be launched as the Shell process.
• The SET RUNWORKPLACE= statement in the CONFIG.SYS file indicates which process is to be the Workplace process.
• In the default configuration, both the PROTSHELL and RUNWORKPLACE environment variables are set to PMSHELL.EXE.
• PMSHELL.EXE is designed to distinguish between being started as the Shell process versus being started as the Workplace process.

Preemptive means that the multitasking activity needs no cooperation from the executing programs. The operating system maintains control over executing programs, and stops, or preempts, them when their time slice with the CPU is over or when a higher priority program is ready to run.

CPU scheduling is based on the following four priority classes, ranked in order from lowest priority to highest:

• Idle-time (priority 1)
• Regular (priority 2)
• Server (priority 4)
• Time-critical (priority 3)

Each class has 32 levels of execution ordering. Scheduling parameters are user-selectable at the time the system is started or can be varied dynamically based on system load.

Depending on a thread's priority class and level, the operating system periodically gives each thread in each process a small slice of CPU time. Threads with higher priorities always run before threads having lower priorities. A thread runs until its time is up or until a thread with a higher priority is ready to run. At that time, the operating system preempts the thread and starts another thread. Threads can also voluntarily relinquish the CPU (for example, by calling DosSleep).

The amount of time in each time slice is defined by the TIMESLICE command in the CONFIG.SYS file. The TIMESLICE command can be used to customize the size of the time slices that a thread gets. The default is for the operating system to dynamically vary the size of the time slice based on the activity of the thread and the overall system load.

When a thread is created (using DosCreateThread), it inherits the priority of the thread that started it. DosSetPriority enables threads to change their priority classes and levels in response to changes in their execution environments. DosSetPriority enables a thread to change its own priority, or the priority of any thread within its process. DosSetPriority also enables changing priorities for the entire process and for descendant processes. Within each class, the priority level of a thread can vary because of a DosSetPriorty request or, if dynamic priority variation is being used, because of action taken by the operating system.

• The TIMESLICE command in CONFIG.SYS sets the minimum and maximum amount of processor time allocated to processes and programs for both OS/2 and DOS sessions.
• The first parameter selects the minimum TIMESLICE value in milliseconds. This value is the minimum amount of time a thread is to be processed before yielding the processor to a thread of the same priority level. This value must be an integer greater than or equal to 32.
• The second parameter selects the maximum TIMESLICE value in milliseconds. The value of this parameter is the maximum amount of time a thread can be processed before yielding processor time. This value must be an integer greater than or equal to the minimum value, and less than 65536.
• The default is dynamic time slicing, which varies the size of the time slice depending on system load and paging activity. Dynamic time slicing is designed to give the best performance in most situations.

OS/2 provides a considerable amount of flexibility in the settings in the CONFIG.SYS file. You can change these settings for exploration and exploitation of OS/2 performance. If properly done, customizing the CONFIG.SYS file will improve OS/2 Warp 4 performance and reduce memory requirements significantly.

• After making your change and before rebooting the system, make sure you save three files CONFIG.SYS, OS2SYS.INI, and OS2.INI. You need those files to recover to the last saved setup.
• If the system fails to reboot after changes were applied, use the ALT-F1 feature to get back to the OS/2 prompt for recovery.

The following is a list of statements in the CONFIG.SYS file that you can change to impact performance.

The BASEDEV statement is used to load base device drivers. Device support for disks, diskettes, printers connected to the workstation, and other devices, is loaded with the BASEDEV statement. A device driver is a file that contains the code that the OS/2 operating system needs to recognize a device and correctly process information received from or sent to that device. A base device driver is one that is needed when the OS/2 operating system is first started.

• Unlike the DEVICE statement, the BASEDEV statement cannot contain either drive or path information because the OS/2 operating system cannot process such information at the stage of the startup sequence when the BASEDEV statements are processed. The root directory of the startup partition is first searched for the specified file name, then the \OS2\BOOT directory of the startup partition. If drive or path information is included in a BASEDEV statement, an error is generated.
• In addition, BASEDEV statements are not necessarily processed in the order in which they appear in your CONFIG.SYS file. The extensions of the file names specified in the BASEDEV statements are examined; the statements are then processed in the following order of file name extensions:
• SYS
• BID
• VSD
• TSD
• ADD
• I13
• FLT
• DMD
• Files with other file-name extensions will not be loaded.

• If several BASEDEV statements load file names with the same extension, those files will be loaded in the order in which they appear in the CONFIG.SYS file.
• Remark any BASEDEV statements that supports devices that are no longer used on the system being tuned.

Applications consist of groups of segments that can be either loaded into physical memory at the same time or called when needed. Memory over commitment occurs when a program requires more memory than is actually available in the computer. The operating system handles memory over commitment by moving some of the information stored in memory off to a file known as the swap file located on the hard drive. This activity is called swapping or paging. Swapping makes it possible for applications to overcommit the amount of physical memory in the system. In OS/2, the file where the data is written to is the SWAPPER.DAT file. Although an application cannot control swapping, you can specify whether the system can swap memory by including the MEMMAN command in the CONFIG.SYS file.

• If the system is started from a hard disk, swapping (SWAP) is the system default; from a diskette, the default is no swapping (NOSWAP).

• Be aware that disabling swapping will severely limit the number of applications that the user will be able to run concurrently; if there is not enough physical memory present, the operating system might not even boot.

The following discusses the two commands MEMMAN and SWAPPATH in the CONFIG.SYS file that you can use to tune the swap file.

If the MEMMAN command specifies SWAP, the operating system writes selected memory pages to the SWAPPER.DAT file whenever insufficient physical memory exists to satisfy an allocation request. This is the default choice. If the MEMMAN command specifies NOSWAP, the operating system does not swap memory.

• To permit swapping, type the following in the CONFIG.SYS file:

• To run a time-dependent application and prevent the OS/2 operating system from swapping the contents of storage to disk, type the following in the CONFIG.SYS file:
• MEMMAN=NOSWAP
• To permit swapping and enable a program to receive an error return code when there is not enough space in the swap file for the program to run, type the following in the CONFIG.SYS file:

• To permit swapping and enable APIs to allocate and use protected memory, type the following in the CONFIG.SYS file:

The exact amount of memory available to an application depends on the amount of physical memory in the machine and the amount of free disk space on the partition that contains the SWAPPER.DAT file. The location of the SWAPPER.DAT file can be specified by including the SWAPPATH command in the CONFIG.SYS file.

• With the SWAPPATH command, you can specify the location of the SWAPPER.DAT file, the amount of free disk space to reserve in the partition which will contain SWAPPER.DAT, and the initial size of SWAPPER.DAT. The operating system adjusts the size of SWAPPER.DAT as necessary, leaving other files on the drive and the requested free space untouched.

SWAPPATH=drive:\path minfree initial

• To store the swap file in the C:\OS2\SYSTEM directory, type the following in the CONFIG.SYS file:

• To specify 512KB (minfree) as the amount of free space left for other applications, type the following statement in your CONFIG.SYS file:

• To specify 18MB as the initial size of a swapper file on a partition with 20MB of free space and a minfree value of 2MB, type the following in the CONFIG.SYS file:

There are two parameters in the swappath statement: minfree and initial. Both are expressed in KB, and the system rounds them to megabytes at boot time. The minfree value determines at what time you will receive a warning message that disk space has been reduced too low. If the remaining amount of free space after the swapper.dat file extension, is less than the amount (in megabytes) of the minfree value, a warning message is displayed.

• The default minfree value is 2048 KB.
• The best minfree value for a system running several concurrent applications is generally 4096KB. If you are working with large databases, increase the value to 6144 KB or larger. This value gives you plenty of time to handle warning for a shortage of DASD space for the SWAPPER.DAT.

The initial swap file size is preallocated to a minimum size during system boot up, depending on the amount of physical memory installed in the system. This helps prevent the excessive overhead of growing the swap file during paging operations.

• The default initial value is 2048 KB

When your applications are being executed, a larger swap file might be needed than what has been preallocated. The OS/2 kernel will increase the size of the swap file in 1 MB increments if more swap space is needed. When one or more pages need to be swapped out from memory, the kernel will determine if these pages already have swap space allocated in the swap file. If yes, the swap manager will simply write them into the allocated swap space. If not, then new swap space will be allocated in the swap file. If there is no space left in the swap file, the swap file has to grow. The swap manager then writes the pages to their new swap space. Swap space in the swap file is normally not freed up until the corresponding memory is deallocated. When the swap file grows beyond the initial size, then the system must manage the swap file to determine when compaction can take place. This additional overhead will cause a performance penalty.

• To keep system performance optimal, make sure the initial swap file size is large enough to handle your applications.
• To determine the correct size of your swap file, check the size of the SWAPPER.DAT file occasionally. The size specified in the CONFIG.SYS should be at least 1 or 2 MB larger.
• The following data taken on a 486/33 with 16MB of physical memory represents the size of the SWAPPER.DAT file after OS/2 Warp is booted:

• To create a contiguous swap file - If you are using the FAT file system, IPL your system under DOS, delete the SWAPPER.DAT file, defragment the disk partition where the swap file will be located, and then IPL your OS/2 system. This should keep your swap file from getting fragmented.

The swap file begins compaction when the amount of free swap space in the swap file exceeds 1.5 MB. The compaction is done at system idle time. During compaction, free swap space will be moved to the end of the swap file. After compaction, when the amount of free space at the end of the swap file is greater than 1 MB, the swap file will be decreased, in 1 MB decrements.

• The swap file never gets smaller than the initial size.

BREAK instructs the system to check if you pressed the Ctrl and Break keys together before the system carries out a program request. Pressing and holding the Ctrl and Break keys together stops a command from completing its task.

• BREAK can be entered in the CONFIG.SYS file, in a batch file, or at the command prompt. If BREAK is ON, processing might be slower, but the operating system will probably intercept Ctrl+Break faster. Setting BREAK=ON allows you to leave a program even if it produces few or no standard device operations (such as a compiler). For example, if a program is being compiled and it meets an error or loop, it is important to have a way to stop compilation.
• The default is OFF
• To have the system check for Ctrl+Break when you request it, enter the following statement in your CONFIG.SYS file:

Sets the number of disk buffers that the system uses.

• The disk buffer is a 512-byte block of storage the system uses to read and write blocks of data that do not occupy an entire sector. You can increase the speed of your system by increasing the value specified for BUFFERS. However, when you increase the number of disk buffers, you decrease your available memory. You might want to experiment with the number of buffers to get maximum performance. Additional buffers can cause some applications to run more slowly because there is less memory available for the application to keep data. More frequent read and write requests than are otherwise necessary might then result.
• By using the disk buffer, the operating system can read and write blocks of information into the buffer in preparation for processing the information. While the information is in the buffer or being processed, the input device can begin reading new pieces of information so the processor does not have to wait unnecessarily to process information and program instructions. The processor can complete its operation, because the next block of information to process is already in the buffer area.
• Some other situations might also occur. For example, suppose the processor completes its work and there is no information in the buffer to process. The processor must wait until the next block of information is read into memory by the input device. Similarly, if the input device reads information into the buffer before the system has time to process the records, the buffer might reach its capacity and have to wait until the system accepts more information to process.

• Depending on how many programs you work with at a given time, you might want to experiment with this number the number of disk buffers to maximize performance on your system.
• If you run many programs in OS/2 sessions, you can increase the speed of your system by increasing the value specified for BUFFERS (for example, BUFFERS=70). However, remember that when you increase the number of disk buffers, you decrease your available memory by 512 bytes for each buffer specified. Additional buffers might cause some programs to run more slowly because there is less memory available for the program to keep information. This can result in more frequent memory swapping, which will slow down performance.
• Buffers is also considered as a cache for FAT entries. It should not be reduced below 60, even on low memory systems because it will, as a result, increase the number of disk reads that are done to the FAT directory entries and therefore bring down your system performance.

Selects the system code pages (defined character sets) to be prepared by the OS/2 operating system for code-page switching. You must include the appropriate DEVINFO statements (for keyboard and video display) for both code pages in the CONFIG.SYS file.

• The display and printers each default to a native device character set. The keyboard and country information default to the national language code page supported by the country code specified in the COUNTRY statement.
• When your computer displays output, the characters used are defined by a specific code page. Each code page contains letters, numbers, symbols, and other characters common to a particular country. Each character has a number (1 to 255) assigned to it. For example, character number 212 might display one character in the U.S. code page (437), but a different one in the Portuguese code page (860). Therefore, you should use your default national-language code page unless you are working with files that were created using another code page or unless you are planning to send files to other countries.
• When using a file that was created in another code page, you can switch to that code page or to the multilingual code page. We recommend you use the multilingual code page (850) whenever possible because it supports many languages. For example, suppose you create a file using code page 850 and send it to someone in another country. When that file is viewed or printed using code page 850, it is identical to your copy. If, however, the file you send was not created using the multilingual code page, the receiver will need to switch to the code page that it was created with. Once code pages are defined on your system, you can switch back and forth between the prepared code pages.
• In the OS/2 operating system, a program or user can change the active code page. Two pages can be active simultaneously. Code pages for the keyboard and display can be set independently; however, code-page switching can take place only in displays that support code-page switching, including the following products:
• IBM Enhanced Color Display
• IBM Personal System/2 Displays
• IBM Enhanced Graphics Adapter
• IBM Personal System/2 Video Graphics Array
• IBM Personal System/2 Display Adapter
• IBM Personal System/2 8514/A
• If you plan to switch code pages and are using a code page other than 850, we recommend that you do not name your files or subdirectories with accented characters.
• To ensure you will be able to access files prepared with another code page, be sure to use only the characters A-Z and 0-9 when naming files and directories. This prevents file access problems when switching between code pages that have different character capitalization rules.

• Incorrect, partial, or mismatched setup of statements for code-page selections, country code, keyboard layout, display, or printer can cause ineffective switching between code pages. This will in turn cause performance degradation. If your printer is correctly set up for code-page switching, print jobs started in a DOS session or in the current OS/2 session, after a successful CHCP command is issued, will print in the new code page.

Installs a device driver by specifying the path and complete file name of the device driver in your CONFIG.SYS file.

• A device driver is a file that contains the code needed so that the OS/2 operating system can recognize the device and correctly process information received from or sent to that device. It loads standard default drivers that support standard system display terminals, keyboards, printers, diskette drives, hard disk drives, and serial devices. You can, however, replace these or add other devices by coding and loading a device driver using DEVICE statements in the CONFIG.SYS file. DEVICE statements are processed in the order in which they appear in the CONFIG.SYS file. The default device drivers are:
• ANSI.SYS - Allows extended screen and keyboard support for DOS sessions.
• COM.SYS - Allows OS/2 application programs or system programs, such as SPOOL, to use serial devices.
• EGA.SYS - Allows DOS programs that require Enhanced Graphics Adapter support to be run.
• EXTDSKDD - SYS Allows access to an external diskette drive referencing a logical drive letter.
• LOG.SYS - Allows system error logging using the SYSLOG utility program.
• MOUSE.SYS - Provides support for pointing devices.
• OS2ASPI.DMD - Supports existing device drivers written to Adaptec's ASPI interface.
• OS2CDROM.DMD - Provides CD-ROM support for OS/2 sessions.
• PMDD.SYS - Provides pointer draw support for OS/2 sessions
• POINTDD.SYS - Provides mouse pointer draw support.
• TOUCH.SYS - Provides support for touch devices.
• VDISK.SYS - Installs a simulated disk called a virtual disk.
• VEMM.SYS - Provides DOS Expanded Memory Manager.
• VXMS.SYS - Provides DOS Extended Memory Specification.

• Install only device drivers that are needed. For example, if you do not plan to run DOS and Windows applications, you can remove VEMM.SYS and VXMS.SYS. The following are potential candidates for removal from the CONFIG.SYS file.
• VDISK
• COM and VCOM
• CDROM and VCDROM
• PCMCIA
• BASEDEV=IBM2FLPY.ADD
• BASEDEV=IBM1FLPY.ADD
• BASEDEV=IBM1S506.ADD
• BASEDEV=IBM2ADSK.ADD
• BASEDEV=IBM2SCSI.ADD
• BASEDEV=OS2SCSI.DMD
• BASEDEV=PRINT01.SYS
• BASEDEV=PRINT02.SYS
• APM.SYS and VAPM.SYS
• EGA.SYS
• EXTDISKDD.SYS.
• TOUCH.SYS
• Change the DEVICE=\OS2\MDOS\VEMM.SYS statement to VEMM.SYS 0. This statement loads a driver that provides Expanded Memory Support (EMS) for DOS sessions. Adding a 0 variable causes OS/2 to not allocate EMS to a DOS session unless you override the setting in that session's DOS Settings. Most programs do not require EMS, so disabling EMS by default will save RAM.
• Change the DEVICE=\OS2\MDOS\VXMS.SYS statement to DEVICE =\OS2\MDOS\VXMS.SYS /XMMLIMIT=4096,0 /UMB. This will allocate a maximum of 4MB of SMS for the entire system, but it will not give any XMS memory to a DOS session unless you override the setting in an individual session's DOS Settings. DOS sessions won't get XMS by default, which will save memory (since most DOS programs can run without XMS). If you replace /UMB with /NOUMB, no DOS session will be able to use upper memory blocks. If you want DOS=HIGH to be the default, use /XMMLIMIT=4096,64 /UMB instead. Each session will need at least 64KB of XMS.

Loads a specified DOS device driver into an available upper memory block (UMB) for a DOS session.

• DOS device drivers are normally loaded into low memory (below 640KB) in DOS sessions. However, when you type the DEVICEHIGH= statement into your CONFIG.SYS file, the operating system will attempt to load the specified DOS device driver into an available upper memory block (UMB). If a UMB is not available, the device driver will be loaded into low memory as is done for a DEVICE= statement. To enable UMBs, type the DOS=UMB statement in the CONFIG.SYS file.

• You should load DOS device drivers onto UMB to preserve low memory for DOS applications.

The disk cache has the potential for dramatic performance gains. The disk cache allows a portion of system storage to be used as an additional hard-disk buffer. DISKCACHE speeds up application programs that read hard disks by keeping hard disk data frequently accessed in a cache buffer. When an application program requests hard disk data that is already in the cache buffer, the disk cache sends the data directly to the application program. This method of accessing data is much faster than if the data had to be read from the disk each time. A disk-cache size is preselected by the system based on installed memory, disk size, and file systems installed. Any memory set aside for the disk cache is memory that is taken away from the free memory available for programs. Therefore, it is recommended that you determine the amount of memory required for normal operation of your system, then dedicate as much of the remaining memory to a disk cache. This requires that you have a good understanding of the working set requirements of your system. For example, a computer with 6MB or more of RAM should use a disk-cache size of 256KB.

The DISKCACHE default sizes for FAT are as follows:

• For systems with 4MB or less of memory, the value d is set to 48KB.
• For system memory above 4MB and up to 5MB, the value d is set to 64KB if more DASD is formatted for HPFS than for FAT. If more DASD is formatted for FAT than for HPFS, the value d is set to 48KB.
• For system memory above 5MB and up to 6MB, the value d is set to 128KB.
• For system memory above 6MB and up to 8MB, the value d is set to 512KB.
• For systems with more than 8MB of memory, the value d is set to 5% of the memory size up to a limit of 14MB.

• Default sizes for DISKCACHE are set up by the installation program. The dependencies are the amount of physical memory and the number of partitions formatted for either file system.
• The minimum disk cache size for the FAT file system is 0KB (you can select not to use a cache). The maximum is xxKB. The maximum cache size fo FAT is 14.4MB.
• You need to select Shut down from the menu of the desktop before turning off your system. Failure to do so can cause loss of data if the contents of the cache buffers have not been erased and written to disk.
• The amount of storage required for control information is determined by the total size of one or more hard disks. When the amount of storage you specify in the DISKCACHE statement is not available, the system displays an error message. When the amount of storage you specify in the DISKCACHE statement is not sufficient to support the total hard disk size, the disk cache does not work.
• The disk cache is allocated at system startup, and there is no dynamic adjustment of its size. It is recommended that the threshold size be set at 32 unless the software product you are using is disk intensive and the manufacturer supplies information on the block size required. If the block size is defined in terms of byte count, divide the byte count by 512 and round up the quotient to the nearest whole number to determine the threshold value.
• There are four parameters in DISKCACHE=D,T,LW,AC: to specify the amount of real memory used for caching disk data. D specifies the cache size, T specifies the cache threshold, i.e., the largest data block placed in the cache. LW means Lazy Write, i.e., write data to disk only when system is not busy as opposed to right away. AC: tells the system to run checkdisk if the machine encounters power failure or otherwise is not shut down correctly.

• Modifying this statement can increase the speed of your system. If no DISKCACHE statement is specified, no cache storage is allocated. When you increase the size of your disk cache, you also decrease the size of available memory for other usage. For this reason, you may want to experiment with the cache size to get maximum performance.
• When disk cache is set to dynamic, sizes are based on the amount of memory that is available in the system and how many partitions are formatted for the FAT file system, not on the disk size.
• You need to select Shut down from the menu of the desktop before turning off your system. Failure to do so can cause loss of data if the contents of the cache buffers have not been erased and written to disk.
• The DISKCACHE default cache sizes for FAT are as follows:
• For systems with 4MB or less of memory, the value d is set to 48KB.
• For system memory above 4MB and up to 5MB, the value d is set to 64KB if more DASD is formatted for HPFS than for FAT. If more DASD is formatted for FAT than for HPFS, the value d is set to 48KB.
• For system memory above 5MB and up to 6MB, the value d is set to 128KB.
• For system memory above 6MB and up to 8MB, the value d is set to 512KB.
• For systems with more than 8MB of memory, the value d is set to 5% of the memory size up to a maximum size of x.
• When the amount of storage you specify in the DISKCACHE statement is not available, the system displays an error message. The disk cache is allocated at system startup, and there is no dynamic adjustment of its size.
• Reduce the diskcache size when running applications that provide their own caches like AutoCAD, Foxpro, or DB2.
• It is recommended that the threshold size be set at 32 unless the software product you are using is disk intensive and the manufacturer supplies information on the block size required. If the block size is defined in terms of byte count, divide the byte count by 512 and round up the quotient to the nearest whole number to determine the threshold value. The default threshold value is 4.
• Enable LAZYWRITE (LW) whenever possible. This allows disk writes to be temporarily held in memory to increase throughput. Without LW, disk writes are done immediately. LW will increase disk performance, but an unexpected power outage may cause data loss.

You can load a DOS TSR program into an upper memory block (UMB) by typing the LH or LOADHIGH command at the DOS command prompt. If no UMB is available, the TSR program will be loaded into low memory (below 640KB). To enable UMBs, type the DOS=UMB statement in the CONFIG.SYS file

• Specifies whether the DOS kernel will reside in the high memory area (HMA) and whether the operating system or DOS applications will control upper memory blocks.
• Upper memory blocks are provided by the XMS device driver. It also is necessary to include a VXMS.SYS statement in the CONFIG.SYS file to have upper memory blocks available.

• With a DOS=HIGH/LOW,UMB statement, the operating system controls the upper memory blocks. This means that DOS applications can be loaded into upper memory but cannot allocate UMBs.
• With a DOS=HIGH/LOW,NOUMB statement, the operating system will not control any UMBs. DOS applications can allocate UMBs but cannot be loaded there.

FCBS allows you to alocate File Control Blocks for DOS sessions. Most new DOS programs do not use FCBS so these values can often be lowered to save memory.

• This statement has no effect in OS/2 sessions.
• A file control block (FCB) is a record that contains all of the information about a file (for example, its structure, length, and name). If a program tries to open more than the number of files specified in the FCBS statement, the system closes the least-recently used file control block and opens the new file. Some application programs use file control blocks to create, open, delete, read, and write to files. New programs written for the operating system usually use internal file IDs (handles) for file input/output.
• If a program tries to open more than the number of file control blocks specified in the FCBS statement, the system closes the least-recently used FCB and opens a new file. The files that are protected from being closed are not included in the list of least-recently used FCBs. If a program tries to read or write to a file that has been closed because it is the least-recently used FCB, the system displays an error message.

Determines the maximum number of files available in DOS sessions.

• This statement has no effect in OS/2 sessions.
• When a DOS session is started, 20 files are available to be used by all programs running in that DOS session. A file is in use when a program is processing some kind of operation in it. When a program is using a file for its operation, that file is unavailable to another program. The file is returned to availability when the program has finished its operation and the file is closed.

• Regardless of the FILES= setting, all DOS programs are initialized to a maximum of 20 files. It is the responsibility of an application to increase the number of files up to the maximum set by the FILES= statement.
• Placing a FILES= statement in the CONFIG.SYS file increases the default value for all DOS sessions. Each session can also be customized by changing the appropriate DOS setting.
• To specify a maximum of 40 files to be open at the same time in a DOS session, type the following in the CONFIG.SYS file:

Installs a file system (IFS) by specifying the path and complete file name of the file system driver in your CONFIG.SYS file.

• A file system driver is a file that contains code needed to manage disks and diskettes formatted for file systems other than the file allocation table (FAT).

• Use this command to replace the FAT file system with a file system of your choice. An example of an IFS driver is HPFS.IFS.
• To install the High Performance File System in a system with 128 KB cache and 4KB maximum record size, you have to place the following statement in the CONFIG.SYS file:
• IFS=C:\OS2\HPFS.IFS /CACHE:128 /CRECL:4 /AUTOCHECK:C
• If you select HPFS as your standard file system, the OS/2 installation procedure inserts an IFS statement as the first entry in the CONFIG.SYS file.
• System installation automatically sets up the HPFS cache for you if you format the primary partition with HPFS (using the OS2.INI file). If you format the primary partition for FAT instead, and then later want to format another partition with HPFS, you need to add an IFS statement to the CONFIG.SYS file.
• Keep in mind that the IFS statement is device-dependent and must be included before any DEVICE statements.
• If you start DOS (from outside the OS/2 operating system, that is, from a DOS partition or diskette), files on HPFS partitions are not accessible. (This means that you cannot start your system from a DOS installation diskette while using HPFS). If you start a Specific Version of DOS from within the OS/2 operating system (that is, a version of DOS running in a DOS session), then files on HPFS partitions are accessible.
• If your system has no HPFS partitions defined, you should disable the loading of HPFS by adding a REM to the beginning of the IFS= line in your CONFIG.SYS.
• Lazy writing for HPFS defaults to ON. A RUN=CACHE statement is required to change the state of lazy writing. CACHE also can be executed from a command prompt.
• Optimize the HPFS CACHE setting on systems using the HPFS file system or REMark it out if the system does not use this file system. The HPFS code and data space requirement is 200KB of memory plus the cache requirement (minimum cache size is 64KB). Removing this statement will save at least 264KB and as much as 2312KB.
• Optimize the CRECL value by experimenting with different threshold values while monitoring the HFFS cache utilization with SPM/2. This will ensure the optimum value is determined.

Allows I/O privilege to be granted to requesting processes in OS/2 sessions.

• The privilege level assigned to a program determines what code segments and data segments it can access. The privilege level also limits the machine instructions a program can process.
• Application programs are usually assigned privilege level 3. This means that they can call routines that run at any other privilege level. However, they can access only their own data segments and cannot issue any I/O instructions.
• Programs that are granted I/O privilege run at privilege level 2. When IOPL is YES, a program assigned privilege level 2, such as a subsystem that needs to communicate directly with a specific device, is then permitted to send or receive instructions to or from that device.

• To permit I/O privileges to processing programs, type the following in the CONFIG.SYS file and restart your system:

• To prevent I/O privileges from processing programs, type the following in the CONFIG.SYS file and restart your system:

• To allow I/O privileges to be granted to programs named PROC2 and PROC3, type the following in the CONFIG.SYS file and restart your system:

Sets a search path for commands and programs.

• PATH searches specified directories for commands or batch files that the system did not find when it searched the current directory. PATH only finds files that can be run, such as files with the following extensions: .COM, .EXE, and .BAT (for DOS sessions), or .CMD (for OS/2 sessions).
• PATH is a system environment variable. If the system cannot find an external command or program in your current directory, it queries the environment for a value for PATH. Application programs can also query the environment for the value of PATH and, depending on what they find, change their behavior.
• When you install the OS/2 operating system, the installation program places the following in the CONFIG.SYS file.

• System installation also creates the following PATH statement in your AUTOEXEC.BAT file for use with DOS sessions:

• Setting the PATH in the CONFIG.SYS and AUTOEXEC.BAT files lets you avoid having to set PATH from the command prompt each time you turn on your system.
• As you create your own subdirectories, you can change the PATH statement in your CONFIG.SYS to reflect your new directory structure. For DOS sessions, you update the PATH statement in your AUTOEXEC.BAT file.

• Directory names should be placed in the order of usage. The most accessed directory should be listed first and the least accessed listed last.
• If programs will be executed from an object on your desktop or folder, specify the path there and not in the PATH statement. Only place directories in the PATH statement for executables that will be called from other programs or commands.

DPATH indicates what directories applications should search for their data files (if an application program uses the DPATH directory list).

• DPATH is a system environment variable, which means that application programs can query the environment for its value, and, depending on what they find, change their behavior.
• Like the PATH command, the number of directories you can specify with DPATH is limited only by the length of the command line. The length of a DPATH command can be up to six characters less that the maximum number of characters allowed on the command line. Once you set a search path for data files with DPATH, the path remains in effect for the current command processor until you replace it with another DPATH command.

• Directory names should be placed in the order of usage. The most accessed directory should be listed first and the least accessed listed last. .

Identifies the locations of dynamic link libraries for OS/2 programs.

• LIBPATH is used to identify a set of directories to be searched when the OS/2 operating system loads dynamic link libraries. Because dynamic link library modules are shared globally, this command allows path searching to be defined globally rather than on a per-process basis (as done by the PATH command).
• LIBPATH is not a part of the environment and therefore cannot be viewed with the SET command. Also, unlike the PATH environment variable, the current directory is not searched first.
• The installation program places this statement in your CONFIG.SYS file:

• Directory names should be placed in the order of usage. The most accessed directory should be listed first and the least accessed listed last.
• Make sure that .; is the first directory in the LIBPATH.
• If possible, place the DLL used by a program in the same directory as the working directory when the program is running. Then, you do not need to add that directory to the LIBPATH statement. Also, place all directories that are on a network at the end of your LIBPATH statement in case the network goes down and they cannot be accessed.

Sets the amount of time a ready-to-run thread waits before the system assigns it a higher priority.

• When a regular-class thread is denied the processor for a defined number of seconds, it receives a temporary increase in priority for a period of time up to the minimum time slice.
• MAXWAIT has no effect if the PRIORITY command is set to ABSOLUTE.
• The system limits the time that a regular-class thread waits to be processed. When the time limit is reached, the system raises the priority of the thread to give it a chance to be processed.

• The most appropriate amount of time to set depends on the number of applications that must run concurrently and the kinds of activities the applications perform (the system default is three seconds). Experiment with this time to improve overall system performance.
• To cause a thread to wait up to 5 seconds before it receives a temporary increase in priority, type the following in the CONFIG.SYS file:

• You can specify a number from 1 through 255. The default value is 3. Use 2 for systems running lots of programs together or a program that runs at a higher priority with others that run at a lower priority.

Selects priority calculation in scheduling regular-class threads.

• The system assigns a thread based on its display status (background or foreground), recent input and output activity, and frequency of processor use. Most threads are assigned Regular priority.
• Applications can adjust priorities, but the system has a built-in method of handling access to the processor. The default method is Dynamic. Changing this to Absolute can help achieve predictable results by determining the order of priority strictly on the basis of class and level.
• To change the PRIORITY statement so the OS/2 operating system varies the priorities of threads as they are running, type the following in the CONFIG.SYS file and restart your system:

• To change the PRIORITY statement so the OS/2 operating system does not vary the priorities of threads as they are running, type the following in the CONFIG.SYS file and restart your system:

• DYNAMIC almost always offers the best performance.
• If DYNAMIC is not specified then each thread will receive a minimum and maximum time slice of 32 milliseconds with no additional time slices as specified in the TIMESLICE= statement.

Specifies disk input/output priority for applications running in the foreground.

• When PRIORITY_DISK_IO=YES is specified in the CONFIG.SYS file, an application running in the foreground will receive disk I/O priority over applications running in the background. This means that the application in the foreground will have a better response time than applications running in the background.
• To specify that applications in the foreground are to receive priority for disk access, type the following in the CONFIG.SYS file:

• To specify that all applications (foreground and background) are to be treated equally with regard to disk access, type the following in the CONFIG.SYS file:

• Changing PRIORITY_DISK_IO to NO in CONFIG.SYS will improve the performance of communications applications running in the background that are doing disk I/O, if there is foreground work being performed that is also doing disk I/O.

Sets parallel-port device-driver buffer size.

• The PRINTMONBUFSIZE= statement enables you to increase the size of the OS/2 parallel-port device-driver buffer and thereby increase performance of data transfer to devices connected to the parallel port. This device-driver monitor buffer is used only if a printer character monitor is active. The parallel port device driver will allocate and register its monitor chain buffer based upon the value specified.

• If you increase this value, additional system memory is used.
• To set the parallel-port device-driver buffer size for LPT1 as 2048 bytes, for LPT2 as 134 bytes, and for LPT3 as 134 bytes, type the following in the CONFIG.SYS file:

Specifies the highest storage address allowed for the DOS operating environment.

• If you specify a number that exceeds the amount of memory allowable for your system configuration, the system sends you an error message and ignores the statement. It then automatically calculates the largest default value for your system.
• If you do not have an RMSIZE statement in your CONFIG.SYS file, the default is the total amount of low memory installed (either 512KB or 640KB). If this total is 640KB or less, then the default size is the total memory minus the minimum required for protect-mode operations. If this total is 1024KB or greater, the default size is the amount of memory installed below 1024KB, either 512KB or 640KB.
• If you decided to specify PROTECTONLY=NO, you can further reduce the size of the DOS environment by specifying RMSIZE. This allows you to make the size of the DOS environment smaller than the maximum amount available if all the remaining memory below 640KB were used for DOS sessions.
• Specifies a number from 0 through 640, representing a multiple of 1024 bytes.
• To set the size of the DOS environment to 256KB, type the following in the CONFIG.SYS file:

• Leave the default for optimal performance in your DOS sessions.

Sets the maximum number of independent actions, known as threads, for OS/2 sessions.

• Applications consist of a series of instructions. The processor reads each instruction and performs the associated activity. The sequential execution of the instructions by the processor is called the thread of execution. More than one thread of execution can exist within a single process. Typically, OS/2 applications contain many threads.
• Several threads can be ready to execute at the same time, but only one thread at a time can have access to the processor. Access to the processor is managed by the system scheduler, which assigns each thread a priority. The thread that has the highest priority, and that is ready to run, is allocated to the processor. For example, if a thread is being processed, and another thread with a higher priority becomes ready to run, the system stops processing the thread with the lower priority and allocates the processor to the thread with the higher priority. That thread is processed until it relinquishes control of the processor or until a thread of higher priority is ready to run.
• The system supports a maximum of 4095 threads, which it allocates to itself and the applications running on it. Reducing the number of threads while running complex applications or system extensions, can force activities that COULD be performed concurrently, to be performed serially, thus slowing performance. If no THREADS statement is in the CONFIG.SYS file, the default number of threads is 64.
• To have the system handle up to 512 active threads, type the following in the CONFIG.SYS file:

• If there is no THREADS statement is in the CONFIG.SYS file, the system defaults to a value of 64.

• Each thread requires a minimum of 4KB stack allocated by the system.
• OS/2 threads get priority boost when they have foreground focus.
• All DOS and Windows threads run at the same priority in a round robin manner.
• DOS and Windows disk I/O can execute on a separate thread.
• The basic thread priority is 200.
• Communications Manager and LAN server have threads that run at Time Critical and Server priority levels.
• Set THREADS to a value 50% larger than the actual number of threads expected to be used to avoid running out of threads.

Sets the minimum and maximum amount of processor time allocated to processes and programs for both OS/2 and DOS sessions.

• Unless a dispatching priority is explicitly defined by an application, the system assigns one to each thread of execution. The system uses round-robin (that is, time-distribution) time slicing to ensure that threads of equal priority are given equal chances to be processed.
• The first value (X) in the statement TIMESLICE=X,Y is the minimum amount of time a thread can be processed before yielding the processor to a thread of the same priority level; the second value (Y) is the maximum amount of time a thread can be processed before yielding processor time.

• This statement is not found in the CONFIG.SYS file after you install OS/2 but is sometimes recommended to be added. This was okay to add for OS/2 2.0, 2.1 or 2.11 systems, but not for OS/2 Warp. In OS/2 Warp, we dynamically modify a threads time slice based on actions that have occurred. For instance, if a thread took a page fault during it's time slice, we give it an extra time slice to process what is contained in the faulted page. We also give applications doing disk I/O extra time slices if the data they are reading is in the disk cache. When the TIMESLICE= parameter is used, none of these actions will occur. Instead, each thread will be given the minimum time slice of X, and its time slice will not be allowed to go beyond value Y.
• The default is dynamic time slicing based on system load and paging activity. Dynamic time slicing gives the best performance in all situations.
• To set the minimum TIMESLICE value to 32 and allow the maximum value to default, type the following in the CONFIG.SYS file:

• To set the maximum TIMESLICE value to 32 and allow the minimum value to default, type the following in the CONFIG.SYS file:

• To change the minimum and maximum time slice allowed to 45 milliseconds, type the following in the CONFIG.SYS file:

• To change the maximum time slice allowed to 125 milliseconds to support a communication program, and the minimum time slice to 40 milliseconds, type the following in the CONFIG.SYS file:

• If you do not have a TIMESLICE statement in your CONFIG.SYS file, the minimum and maximum default values are set.

The Single Input Queue (SIQ) allows the user to take focus away from an application that is monopolizing the message queue.

• When you request a focus change, e.g., by clicking on another application or pressing the Ctl+Esc, the application that has the focus should respond to the message in a certain amount of time, say x milliseconds. If the application does not respond within that time, OS/2 flags the application queue as bad. It will then switches focus to the desired application.
• OS/2 will monitor the queue marked as bad to see when it does start responding messages. It will mark the queue as good when this occurs.

• To enable the SIQ feature, place a SET PM_ASYNC_FOCUS_CHANGE statement in the CONFIG.SYS file and reboot.
• The parameters for the SIQ statement is:

• The default is OFF (disabled). To turn SIQ on (enable), use

• To change the timeout value, put the following statement:

The AUTOEXEC.BAT file is specific to the DOS session and has no performance impact on OS/2 applications. You can however customize your DOS session by having DOS system commands in the AUTOEXEC.BAT file. This will start your memory resident programs and set up environment variables as required by your DOS applications.

• To make as much base memory as available to applications, remove all unnecessary commands from the AUTOEXEC.BAT file.
• You can also create several AUTOEXEC.BAT files, each file corresponds to specific DOS commands needed by each specific application.
• The specification of a specific AUTOEXEC.BAT file to a DOS session is done by selecting the setting DOS_AUTOEXEC in the DOS settings notebook for the application object.

Application software offers a great deal of flexibility in its ability to be tuned for improved performance. Skilled programmers have tremendous control over the performance of their application as well as the performance of the entire system. Applications can be written to use minimal amounts of memory and processor resources. A poorly written application can cause major problems by using excessive amounts of memory and CPU cycles.

Applications usually do not have tunable options that allow a user to modify their performance. If they do, the best way to discover and implement them is to read the documentation that comes with the program. For example, Lotus Notes for OS/2 has a memory tuning parameter that when placed in the Notes.INI file, keeps the application from using all of the systems free memory. Likewise, IBM's C Set compiler has an optional command that will cause the compiler to remain in memory after it has been loaded by the first compile action. Subsequent compiles become faster because the compiler does not need to be re-loaded into memory.

Under OS/2 Warp, application programmers have a great deal of control over the performance of both DOS and OS/2 programs. Some general programming rules when programming OS/2 applications include using multiple threads, checking the linker map to place functions that call each other in the same code page, and keeping your DLLs in the working directory so OS/2 will not have to search to find them. DOS programs should be designed to not poll hook interrupts, but try to limit far references and keep functions that call each other in the same segment. These techniques and more are explained in the many books focused on programming for performance.

DOS application performance can be improved by maximizing the use of memory below 640KB. Drivers such as EMM386 and HIGHMEM are designed to free as much memory as possible and provide disk caching to speed up hard drive access. Since some DOS applications respond differently than others using these drivers, it is usually necessary to experiment with them and other parameters to find the optimal performance

configuration.

OS/2 applications run natively on OS/2 Warp 4, therefore, no special settings nor configurations changes are required. That is, users do not need to make explicit changes to OS/2 applications. However, there are techniques that you can use to speed up the application loading or execution time.

• The LIBPATH, which is set in CONFIG.SYS, specifies a search path which the OS/2 operating system uses when searching for dynamic link libraries (DLLs). The LIBPATH is set during system startup and cannot be changed dynamically.
• Always set the path for the most frequent accessed programs first in the LIBPATH.
• Do not change the order of the OS/2 components set in the LIBPATH.

When SOMobjects 2.0 is installed on OS/2 Warp, the LIBPATH, PATH, and DPATH environment variables in CONFIG.SYS might be changed to place the SOMobjects directories before the operating system directories in the search order for DLLs, EXEs, and data files. This will cause the Workplace Shell to encounter an unrecoverable error the next time the system is rebooted because it requires the SOM DLLs that are contained in the \OS2\DLL subdirectory, and the performance of your system could be severely degraded.

• In order to allow SOMobjects 2.0 Workstation applications to run successfully, you must edit CONFIG.SYS and change the LIBPATH, PATH, and DPATH statements before rebooting the system. These statements must be changed to place the operating system directories before the SOMobjects directories.

• The same problem will occur for any application that ships SOMobjects 2.0 DLLs if the application places its DLL directory first in the LIBPATH. Once again, the workaround is to assure that the \OS2\DLL subdirectory is before any other directory that contains earlier versions of the SOM DLLs. Any changes made to the PATH and DPATH environment variables by the application installation must also be reversed.

You can get faster compile times with Visual C++ by using some of the following techniques.

• Check the settings of your environment variables (LIBPATH, PATH, INCLUDE, and so on). If the VisualAge C++ directories are at the end of the paths, the compiler or linker must search through all of the other directories before it finds the required DLLs, header files, and so on.
• Ensure you preload the compiler with the /Tl option (it is preloaded by default). This option keeps the compiler components loaded in memory.
• If you are statically linking to the VisualAge C++ libraries, try dynamic linking.
• Use precompiled header files. See the User's Guide for details on how to structure your files so the compiler can take full advantage of the precompiled headers.
• Turn off all optimizations.
• If you are using the HPFS file system, set the IFS statement in your CONFIG.SYS file to:

• Add more RAM to your system. In a memory-constrained environment, OS/2 spends more time swapping data to disk, which increases compilation times tremendously. Additional RAM allows the compiler and its data to remain in memory, which can make your builds run more quickly.
• Define a virtual disk (VDISK or RAM disk) with the OS/2 VDISK device driver. It creates a disk from your system's RAM. For example, placing this statement in your CONFIG.SYS file:

• Minimize dependencies between source files so that changes made to one file don't require you to recompile all your files.

This section discusses the Win-OS/2 environment which supports the execution of Windows applications.

WIN-OS/2 is an environment that allows you run Windows programs under OS/2. There are two types available of WIN-OS/2 environments available:

• WIN-OS/2 Full Screen
• WIN-OS/2 Window (or seamless)

• Some DOS and Windows programs run correctly only in full-screen sessions. Any Windows program that does not use the Windows application program interface (API) function to change the video mode should be run in a WIN-OS/2 full screen session.

During the installation of OS/2 Warp, if you had Windows programs already installed on your hard disk, these programs may have been automatically added to your OS/2 Desktop. Windows programs that were added during installation can be found on the Desktop in the following folders:

• WIN-OS/2 Groups:

• Windows Programs and Additional Windows Programs

The Windows Programs folder and the Additional Windows Programs folder contain Windows programs that have settings optimized during the installation process to improve their performance. If these programs do not run correctly, you can specify other settings. Windows programs that do not belong to any group are added to these folders.

For example, if you have CorelDraw for Windows installed, when you run Add Programs, a folder for all the CorelDraw programs is created and placed in the Additional Windows Programs folder. Now you have access to all the CorelDraw programs in one folder.

A Windows application can run in a common or separate (seamless) session. Common sessions share one WIN-OS/2 kernel regardless of the number of applications loaded. Separate sessions load a new copy of the WIN-OS/2 kernel each time an application (or session) is started.

• If you launch an application from a separate seamless session, the time taken to load the application includes the time to load the WIN-OS/2 kernel as well. In general, it is always faster to load a Windows application in a common session because the WIN-OS/2 kernel doesn't have to be loaded for each application.

WIN-OS/2 can run in two operating modes:

• Standard Mode is used to run programs written for Microsoft Windows Versions 3.0 and 3.1 standard mode.
• Enhanced Compatibility Mode is used to run programs that require Microsoft Windows Versions 3.0 and 3.1 enhanced mode. The Enhanced Compatibility Mode enables the user to run a number of Windows 3.1 enhanced mode applications. It is important to realize that this is not an implementation of Windows 3.1 enhanced mode, but a mode specific to WIN-OS/2 that illustrates the flexibility of OS/2 and its power in blending different application environments into an integrated platform since the major benefit to Windows 3.1 users of enhanced mode was virtual memory - something which OS/2 users already have.

• All Windows Version 3.0 and 3.1 standard mode programs will run in a WIN-OS/2 Enhanced Compatibility Mode session. The default setting for these sessions is Enhanced Compatibility Mode.

• You may want to consider changing the WIN-OS/2 session mode to standard if you are running Windows programs that do not require enhanced compatibility. Performance of Windows programs running in standard mode could be faster than those running in the enhanced compatibility mode.

You can specify a mode for a WIN-OS/2 session or Windows program by changing the WIN-OS/2 run mode setting. For Windows programs that require Microsoft Windows Version 3.1 enhanced mode, set the WIN_RUN_MODE setting to 3.1 Enhanced Compatibility.

The following WIN-OS/2 and DOS Settings should be used for DOS and Windows Multimedia applications:

• To improve the performance of the device, you can change any of the settings:

• To enable audio support for most applications in DOS and Windows sessions, the following settings for DOS properties must be in effect:
• INT_DURING_IO = On
• VIDEO_RETRACE_EMULATION = Off
• AUDIO_ADAPTER_SHARING = Required

This setting allows access to audio hardware for the DOS session.

• Two applications cannot use an audio adapter even if one is not required to run the program. This will allow you to minimize conflicts by defining audio specifications for each DOS session.
• Select Optional to indicate that a program in this DOS session should use an audio adapter if one is available.
• Select Required to indicate that a program in this DOS session must have access to an audio adapter.
• Select None to indicate that a program in this DOS session does not require an audio adapter.
• The default setting is None.
• You can set this setting anytime.

WIN-OS/2 supports the following levels of Win32s:

• 1.15
• 1.20
• 1.25
• 1.25a

• Of the Win32s applications IBM has tested, the following are not supported.

• We recommend that you set the DOS setting DOS_FILES to 255 on sessions that run Win32s applications.
• If a Win32s application states that it has run out of memory, change the DOS setting for DPMI_MEMORY_LIMIT to DECREASE the amount of DPMI memory. This will allow more room for Win32s memory.
• To run Visual FoxPro, change the DOS setting for DPMI_MEMORY_LIMIT to 16.

WIN-OS/2 settings allow you to make adjustments that will improve the performance of your Windows programs.

The following list identifies the types of settings you can change and they will be discussed in corresponding sections.

• Keyboard settings
• Memory settings
• Mouse and touch-sensitive screen settings
• Printer settings
• Video settings
• Hardware-related settings

OS/2 allows you to specify certain settings that can be globally applied to all Win-OS/2 sessions. These settings can be accessed from the folder System Setup -> WinOS/2 Setup.

• From the 3.1 Session bookmark, the Win-OS/2 setup settings notebook provides you buttons for selecting Win-OS/2 full screen or window environment.
• If you select Win-OS/2 window, you can further select Separate session or Common session.
• If you do not select Separate session (i.e., you select Common session) then you can select the Fast load option. This option if selected will create a common session and then preload it with a copy of the Win-OS/2 kernel.

• Use the Fast load option to speed up the loading of all Windows applications running in a seamless and common Win-OS/2 session.
• The Fastload option will take effect immediately after the Win-OS/2 setup settings notebook is closed.

• From the Data Exchange bookmark, you can specify how data are to be dynamically exchanged between Win-OS/2 and OS/2 sessions. When the DDE setting is On, dynamic data exchange (DDE) is public. Windows programs that support DDE automatically update identical data in other Windows and OS/2 programs. Otherwise, you can share information only with other Windows programs. When this setting is set to Off, DDE is private and Windows programs cannot share DDE information with OS/2 programs. For further information, please see the tips for WIN_DDE below.
• Similarly, the clipboard can also be set to either public or private. When this setting is On, the clipboard is public. Windows programs can share data with other DOS, Windows, and OS/2 programs. Otherwise, you can share information only with other Windows programs in that session. When this setting is set to Off, the clipboard is private and Windows programs cannot share clipboard information with OS/2 programs. For further information, please see the tips for WIN_CLIPBOARD below.

As mentioned above, the Win-OS/2 settings can be set from System Setup -> WinOS/2 Setup or from the properties associated with each session object. The following list contains the available WIN-OS/2-specific settings.

• WIN_CLIPBOARD
• WIN_DDE
• WIN_RUN_MODE
• WIN_ATM

This setting allows WIN-OS/2 to share clipboard information between WIN-OS/2 and OS/2 sessions.

• Select WIN_CLIPBOARD; then select the On radio button to share clipboard information among OS/2, DOS (window), and Windows programs.

• For better performance this setting should be set to OFF for private data exchange between WIN-OS/2 applications. However, if this setting is OFF then you will not be exchanging clipboard data between OS/2 applications and WIN-OS/2 applications. The default value is OFF (private).
• You can change this setting before you start the session or at any time after the WIN-OS/2 session is started.
• If you are running multiple Windows programs in a single WIN-OS/2 session, it is possible to share clipboard information between these programs even when this setting is Off (private).

This setting allows programs that support DDE to update their data automatically.

• Select WIN_DDE; then select the On radio button to enable sharing of data among other OS/2 and Windows programs.

• If you are running multiple Windows programs in a single WIN-OS/2 session and the program supports the DDE feature, it is possible to share DDE information between these programs even when this setting is Off (private).
• The default value is Off (private).
• You can change this setting before you start the session or at any time after the WIN-OS/2 session is started.
• This setting is only listed in the WIN-OS/2 Setting window and does not apply to DOS window or DOS full-screen sessions. As a result, this should be set to OFF for private data exchange between DOS applications.
• For better performance, this setting should be set OFF, but only if you are not exchanging data via DDE between OS/2 and WIN-OS/2 applications.

Use WIN_RUN_MODE (Run mode) if you want to specify a mode for your Windows programs. To specify a particular mode, select either the 3.1 Standard or 3.1 Enhanced Compatibility radio button.

• The default value for this setting is 3.1 Enhanced Compatibility Mode.
• You must change this setting before starting a WIN-OS/2 session (or starting one Windows program).
• To set the mode:

This setting loads the Adobe Type Manager fonts for Win-OS/2.

• Select WIN_ATM; then select the On radio button to enable Adobe Type Manager font support for a WIN-OS/2 session. When this setting is set to Off, Adobe Type Manager will not be loaded when the WIN-OS/2 session is started. The default setting is Off.
• WIN_ATM cannot be reset from within a WIN-OS/2 session. To change this setting, you must end the WIN-OS/2 session, reset this setting, and restart the WIN-OS/2 session.

• Loading the ATM will waste memory if it is not used later. For better performance this setting should be set to OFF.
• Modifying the setting while the session is running will not dynamically load the ATM.

The following are tips for using your computer more efficiently when running Windows programs in WIN-OS/2 sessions:

• If you are running Windows programs in WIN-OS/2 windowed sessions, you cannot have any statement in the AUTOEXEC.BAT file that prompts the user for input (for example, "Press any key to continue").
• Do not use the SETUP.EXE file shipped with Windows 3.1. Instead, use the SETUP.EXE file shipped with WIN-OS/2 to ensure your environment is properly configured for OS/2. Use the Selective Install program in OS/2 to change video device drivers for CGA, EGA, SVGA, VGA, XGA, and 8514, and for mouse device drivers. To start Selective Install, open OS/2 System, System Setup, then Selective Install.
• If a Windows program does not work correctly in a WIN-OS/2 session, it is likely that the program files were not all migrated properly. To fix the problem, you can reinstall the program using any WIN-OS/2 session. (Select Run on the File menu of the Program Manager and follow the program's instructions.) Or, if you know the specific files that are needed, you can copy them from the \WINDOWS directory to the \OS2\MDOS\WINOS2 directory.
• The value for VIDEO_SWITCH_NOTIFICATION should not be changed for an active WIN-OS/2 session.
• You cannot use the WIN-OS/2 Control Panel to change mouse buttons in WIN-OS/2 sessions. Change mouse button settings from the OS/2 Desktop to affect the WIN-OS/2 mouse buttons in the WIN-OS/2 environment.
• If you install the US English version of OS/2, and you want to change the system configuration to another country or language, run Selective Install to make the changes effective for OS/2. To make the changes effective for WIN-OS/2, start WIN-OS/2 in a full-screen session, open the Control Panel, and use the International choice to make your changes.
• If you are running a WIN-OS/2 full-screen session with an XGA video device driver and your WIN-OS/2 objects are not clear, use the Control Panel to select another color scheme for the WIN-OS/2 Program Manager.
• If you cannot paste a bitmap from the OS/2 clipboard to a WIN-OS/2 session, the program might not understand the device-independent bitmap (DIB) format of the file. For example, icons created using the Icon Editor are not understood by some Windows programs, such as Microsoft Paintbrush. If your WIN-OS/2 session is started first, you can view the bit map in the OS/2 clipboard; however, you cannot paste it. The Paste menu choice is dimmed (unavailable).
• Metafiles in WIN-OS/2 and OS/2 are not compatible. If you copy a WIN-OS/2 metafile to a public clipboard, it will be sent to PM and vice versa.
• If you want to use dynamic data exchange (DDE) using the Paste Link choice on the File menu of a program, consider the following information.
• The clipboard should be set to Public. The client and server must negotiate the data format to initiate the DDE link. If this negotiation fails, some applications do not display any error message and no further action is taken. If this happens, try another menu choice (for example, Link), if available.
• To improve performance of Lotus Applications in WIN-OS/2, change the following settings to ON:

OS/2 recognizes over 200 of the most popular games and educational programs. Most games will run well under OS/2 if you use the customized DOS settings that are provided when you create a program object for your games using Add Programs from the System Setup folder or using the Program template from the Templates folder. If OS/2 does not recognize a game, it assigns default settings to the game. If the default settings are unsatisfactory, you can customize them to suit the requirements of the game.

You can use Add Programs to create program objects for games that are already installed on your system. For each game that it recognizes, Add Programs assigns a set of customized DOS Settings to the program object, which is placed in the Games folder in the OS/2 System folder.

• When you install a new game, use the default subdirectory whenever possible. Then, make a note of the path and file name used to start the game. Use the Program template from the Templates folder to create a program object for the new game. Type the path and file name in the appropriate field in the Settings notebook of the new object. OS/2 will attempt to match the file name to the list of games found in the recognition database. If a match is found, OS/2 will automatically adjust all settings necessary to run the game.
• If you have a game or educational program that is not recognized by Add Programs and that does not use the default DOS Settings, you can customize the settings for this program by doing the following:

• You might want to create another DOS full-screen session with the following settings to try running games that otherwise cause problems:
• DOS_HIGH ON
• DOS_UMB ON
• EMS_MEMORY_LIMIT 0 or 4096
• HW_NOSOUND ON
• HW_ROM_TO_RAM ON
• HW_TIMER ON
• IDLE_SENSITIVITY 100
• INT_DURING_IO ON
• KBD_ALTHOME_BYPASS ON
• MOUSE_EXCLUSIVE_ACCESS ON
• VIDEO_8514A_XGA_IOTRAP OFF
• VIDEO_RETRACE_EMULATION OFF
• XMS_MEMORY_LIMIT 0, 64, or 4096
• Other settings that you should consider to enhance game play include:
• DOS_BACKGROUND_EXECUTION
• DOS_FILES
• DOS_STARTUP_DRIVE
• DPMI_DOS_API
• DPMI_MEMORY_LIMIT
• DPMI_NETWORK_BUFFER_SIZE
• HW_NOSOUND
• IDLE_SECONDS
• KBD_CTRL_BYPASS
• The following tips might help you play these popular games:
• Master of Orion - Add a SET BLASTER statement to your AUTOEXEC.BAT file
• Link386 Pro - Add a SET BLASTER statement to your AUTOEXEC.BAT file
• DOOM 1.2 - Direct sound effects and music to a PC speaker, or set up Doom I with no sound settings
• DOOM II - Set up the FX selection as a PC speaker and the MUSIC selection as your audio card
• TIE Fighter - The application might stop after about 30 minutes of play in the training session. This occurs in the training session only.
• Myst and The Making of Myst - Do the following:

• Open Assistance Center.
• Open Information.
• Open Tasks folder.
• Open the OS/2 Warp Desktop Guide online book.

• THE 7th QUEST

• Open the pop-up menu for the 7th QUEST object.
• Click on Settings.
• Click on the Session tab.
• Click on DOS Settings.
• Click on OK.
• Click on DOS_DEVICE.
• In the Value window, change the path to ID\T7G.
• Click on Save.
• Close the notebook.

• Edit the ID\T7G\GROOVIE.INI file.
• Under the section that lists your audio card, change the DMA address from the default to your card's DMA setting.

For new games (or games that will not work after using the steps above), try using the Dedicated DOS/Windows mode (session type). This requires that you have Dual Boot installed. Install the game using DOS or Windows and verify that it functions correctly, then create a program object on the OS/2 Desktop and select the Dedicated DOS/Windows Session type. Using this program object, you can now suspend OS/2 Warp to run the game and just as quickly resume your OS/2 Warp environment.

This section discusses tuning tips for DOS applications.

OS/2 provides support for various DOS environments. These environments include DOS, DOS sessions in the OS/2 operating system, and specific versions of DOS started from diskette. As noted earlier, when you are starting a specific version of DOS from diskette, DOS mouse, XMS, or EMS driver support must be replaced with the OS/2 version of the driver, supplied in the OS2\MDOS directory.

Some of the DOS properties are not processed in a DOS session started from the specific version of DOS. The ignored DOS properties are those that configure parameters that are controlled by the CONFIG.SYS file on the DOS startup diskette. These ignored properties include:

• BREAK
• DOS Device Drivers
• DOS Memory Size (KB)
• DOS Shell
• Simulated DOS Version

Other differences include:

• FCB values are restricted to the minimum of the two values in the DOS and OS/2 configuration files.
• The EXIT command does not work when issued from the top level prompt in a DOS session started from a specific version of DOS. You need to use the EXIT_VDM command to successfully exit from a DOS session started from a specific version of DOS.
• There is generally less memory available in a DOS session started from a specific version of DOS.
• A DOS session started from a specific version of DOS will not support extended attributes on logical drives managed by the file system of that specific version of DOS.

DOS applications can be run in a full screen or windowed session. In a full screen session, data are directly written to video memory while the windowed session does not.

• Non-graphical DOS applications like Foxpro 1.0 runs very well in a VDM windowed session.
• DOS programs that are doing intensive text or graphical display will run slower in a windowed session compared to a fullscreen session.

The OS/2 multitasking feature allows you to run multiple DOS, Win-OS/2 or OS/2 sessions at any instance of time. However, DOS applications rarely block themselves. They consume CPU timeslices even if they are in the background or appear not to be doing anything (e.g., polling keyboards or other devices). You can control this behavior by adjusting the following DOS setting parameters: IDLE_SENSITIVITY, SESSION_PRIORITY, and DOS_BACKGROUND_EXECUTION. The tuning of DOS settings are explained as follows.

You can selectively configure a DOS session by changing the session's DOS settings. Most of the settings defaulted values were set based on extensive internal testing. However, some DOS applications require certain features that can be determined by experimenting with the following:

This setting allows you to select an AUTOEXEC.BAT file.

• Use DOS_AUTOEXEC (DOS AUTOEXEC.BAT file) if you want to specify the path and file name of a batch file other than the default AUTOEXEC.BAT file. The default AUTOEXEC.BAT file usually resides in the root directory of the startup drive. This setting is useful for specifying specific environments for individual sessions.
• The default is blank, which means that the AUTOEXEC.BAT file in the root directory of the startup drive is used.
• You must change this setting before starting the session.
• Specify a different AUTOEXEC.BAT for each DOS session will help reducing memory and optimize function.
• Overall system performance is improved when application specific AUTOEXEC.BAT files containing only the device drivers needed for that program. If application specific drivers were loaded from the CONFIG.SYS file at each boot RAM is wasted if the application is not used.

This setting allows DOS applications to run in the background.

• Select DOS_BACKGROUND_EXECUTION, then select the On radio button if you want to allow DOS programs to run in the background. Selecting On means that your DOS application will keep running when it is not in the foreground.
• When this setting is Off, your program will be suspended when it is not in the foreground. When your DOS program is suspended, it will no longer receive interrupts. This means there will be no tasking overhead required to support this DOS session while it is suspended. Select On if you are running a DOS program that is communicating using a COM port or a network adapter. You also should select On when running WIN-OS/2 DDE or when running a Windows program on the desktop. The default value is On.
• You can change this setting before you start the session or at any time after the DOS session is started.

This setting is used when you want OS/2 to check for the Ctrl+Break or Ctrl+C key combinations when your application is running.

• Use DOS_BREAK (Break); then select the On radio button if you want the operating system to check for the keystrokes Ctrl+Break or Ctrl+C while a program is processing. Then, you can press Ctrl+Break or press Ctrl+C to stop a process. For example, if you have Break set to On, and you want to stop compiling a program, press Ctrl+Break.
• Unless you specify otherwise during installation, the operating system places a BREAK=OFF statement in your CONFIG.SYS file. With BREAK=OFF in CONFIG.SYS, the operating system checks for the Ctrl+keys only during standard input or output operations; it does not check for Ctrl+keys while the program processes information. For example, if CONFIG.SYS has BREAK=OFF, the operating system checks for the Ctrl+ keys when the program expects input from the keyboard or the program sends information to the screen or printer. You cannot use Ctrl+Break or Ctrl+C to stop a process (such as a program compilation) if an error occurs or the process repeatedly loops through the same steps.
• Programs run more slowly when you set Break On. The default for this setting is Off.
• You must change this setting before starting the session.
• If you want to have the option to interrupt a DOS batch file running in a VDM in a faster way then this setting should be turned on.

Use DOS_DEVICE to modify the set of DOS device drivers that is loaded into a particular DOS session.

• When you select this setting, you see a list with the information about each DOS device driver specified in your CONFIG.SYS file. The information consists of the path and file name and the current value (if available) of each DOS device driver. For example:

• Add a DOS device driver by typing its name on a new line.
• Remove a DOS device driver by deleting all information about it.
• Add or change a value by typing the new value.
• You must change this setting before starting the session.
• Use this option to load only the DOS devices that you need. This will lower you boot time if you include the DOS device in the CONFIG.SYS file.

This setting specifies the maximum number of file control blocks which may be opened by applications running in a VDM.

• Use DOS_FCBS (FCB count) if you load a file-sharing module and want to change the maximum quantity of file control blocks (FCBs) that a DOS session can have open. The field for this setting contains a range of values from 0 to 255 (FCBs). To change the value, drag the box, select a button, or type into the entry field.
• If you notice poor DOS session performance in a networking environment, use this setting to limit the number of FCBs. If you set a value for this field and your DOS session opens the maximum FCBs you specify, DOS closes the least recently used FCB when it receives the next FCB open request. You can use an additional DOS setting, DOS_FCBS_KEEP, to prevent DOS from closing one or more of the first FCBs it opens.
• The default value is 16.
• You must change this setting before starting the session.

This setting specifies the number of FCBs that will be protected against automatic closure.

• Use DOS_FCBS_KEEP if you want to specify the number of file control blocks (FCBs) that DOS does not automatically close. DOS closes FCBs to keep the number of open FCBs at, or below, the maximum allowed. The field for this setting contains a range of values from 0 to 255 (FCBs). To change the value, drag the box, select a button, or type into the entry field.
• The default value is 8.
• You must change this setting before starting the session.
• Keeping a number of FCBs protected may improve your application performance.

This setting specifies the maximum number of file handles which may be opened in a VDM.

• Use this setting to specify the maximum number of files that can be open at the same time in a DOS or WIN-OS/2 session. Specify a value of 20 to 255. The default value is 20. This setting has no effect in an OS/2 session.
• When a DOS session is started, 20 file handles are available to all programs running in the session. When a WIN-OS/2 session is started, the minimum number of available file handles is 48. This number can be increased by the program. A file is in-use when a program is processing an operation in it. The file becomes available when the program finishes its operation and the file is closed.
• You can change the setting for this session at any time.
• Some applications may requires a large number of files. For example, dBASE IV requires at least 40.

This setting specifies the length of time, in seconds, the operating system waits before applying idle detection in a DOS session.

• Use IDLE_SECONDS to specify the length of time the operating system waits before applying idle detection processing to a DOS session. The field for this setting shows the amount of idle time allowed in seconds. Values range from 0 to 60. To change the value, drag the box, select a button, or type into the entry field.
• If a program appears idle, DOS gives it less time to run so that other programs can make use of the time taken from the idle program. You allow an idle period for a program, such as a game, that waits a brief time after prompting for your input but continues activity if you do not respond. If a program appears to run slowly when waiting for input, increase the value in this field.
• The default value is 0 seconds. When IDLE_SECONDS is set to 0, the operating system immediately applies idle detection processing after a program prompts you for input.
• You can change the setting for this session at any time.
• This setting works with the IDLE_SENSITIVITY setting to help control polling DOS applications.
• You can increase this value if you have an application that waits for input or at a prompt (like a game).
• Some programs periodically appear to be waiting for input, but then change their behavior and continue after a time. This setting disables the IDLE_SENSITIVITY function for a period of time after useful work has been detected. See also IDLE_SENSITIVITY below for more details on idle detection.
• If a program appears to run slowly when there is an option for the user to provide input, this value should be increased.
• Setting the value too high gives the DOS program more resources than it needs.
• A game might pause, for example, to wait for the user to make a choice, but then continues if the user does not react.

Specifies a threshold for judging when an application is considered idle.

• Use IDLE_SENSITIVITY if you want to specify a threshold for judging when a program is doing nothing but waiting for input. The value in this field is a percentage of the maximum frequency with which a program repeatedly checks, or polls, for input. To change the threshold, drag the box, select a button, or type into the entry field.
• If a program polls at a rate greater than the percentage specified in this field, the program is likely to be idle, so the operating system reduces the amount of processor time allocated to the session. By selecting a value in this field, you prevent the operating system from applying idle detection until the program reaches a percentage of this predetermined maximum.
• Increase the percentage if your program can receive input while running and seems to run slower than you expect. If you select 100 in this field, you turn idle detection off, and the program can poll as often as necessary without operating system intervention.
• The default value is 75 (percent).
• You can change the setting for this session at any time.
• Increase the percentage if the application can receive input while running and seems to run more slowly than expected. Selecting 100 in this field turns idle detection off, and the application can poll as often as necessary without operating system intervention.
• Be aware that polling applications are detected quicker on fast systems than on slower systems. This means that the value on different speed systems must vary -- decrease the value on faster systems. Example: If a polling DOS application with idle_sensitivity set to 50 on a 33 Mhz CPU is detected as exceeding the threshold and forced to yield its timeslice by OS/2, it may not be detected as exceeding the threshold on a 16 Mhz system with the same idle-sensitivity value. The 16 Mhz system will need to set a lower value before OS/2 will consider the same application as exceeding the threshold and cause a yield.
• DOS programs often "poll" for input when they are waiting for a user response. For example, a program might wait for a response by repeatedly checking to see if the user has pressed a key. In a multitasking environment such as OS/2 2.x, this wastes time when other programs could be running instead. The operating system detects idle programs by looking for a high rate of polling for input. When programs are judged to be waiting for input, they are given less time to run. For example, if idle sensitivity is set to 75%, an application repeatedly checking to see if input is available would have to do this checking at more than 75% of the maximum possible rate before it would be judged idle. Idle detection is a "best guess" of what the program is doing. It could be that the program is polling at a very high rate, but is still doing useful work in between checking. It might be that the application checks at a fairly slow rate but still is doing nothing but waiting. The idle sensitivity threshold allows adjustment of the threshold for a particular application. Also see IDLE_SECONDS.
• If an application receives input while running, and seems to run slower than expected, the idle sensitivity should be set to a higher value. This lets the application poll at a higher rate without being judged idle. Setting the level to 100 turns idle detection off altogether. The application will be allowed to poll for input as often as it likes. If an application is waiting for input and other applications do not appear to be running, the idle sensitivity should be adjusted downward. This lowers the threshold for judging the application idle.

This setting allows interrupts to be handled during file I/O. When set to on, this creates a second thread for the application to use for interrupt handling when the primary thread is busy with I/O operations.

• Use INT_DURING_IO (Interrupt During I/O) to enable or disable interrupts during disk read and write operations. Select the On radio button to allow interrupts during disk I/O. This allows programs to receive interrupts while waiting for the completion of the disk request. Many multimedia programs need interrupts during disk read and write operations. For example, while running Linkway programs on CD-ROM.
• When this setting is set to Off, interrupts will be disabled until disk I/O is complete. The default setting is Off.
• You must change this setting before starting the session.
• This setting is primarily designed for multimedia applications and should be turned on when running a multimedia application, MSCDEX applications, and many games.
• Creates extra overhead on the system for processing and memory requirements, and can cause degradation of performance for other applications.
• Unless your application is interrupt-sensitive, leave this setting Off.

This setting allows you to set priority level for the execution of your application.

• Selecting SESSION_PRIORITY enables you to increase the priority of separate WIN-OS/2 sessions. Change the value of priority either by entering a new value or by using the left or right arrows. The setting ranges from 0 to 31 in increments of 1 with a default setting of 0.
• SESSION_PRIORITY cannot be reset from within a WIN-OS/2 session. To change this setting, you must end the WIN-OS/2 session, reset this setting, and restart the WIN-OS/2 session.

The following list contains the available memory settings that you can change to affect the performance of DOS applications..

• DOS_HIGH
• DOS_RMSIZE (DOS memory size)
• DOS_UMB (DOS owns UMBs)
• DPMI_DOS_API (DOS API translation)
• DPMI_MEMORY_LIMIT
• DPMI_NETWORK_BUFF_SIZE
• EMS_HIGH_OS_MAP_REGION
• EMS_LOW_OS_MAP_REGION
• EMS_MEMORY_LIMIT
• EMS_FRAME_LOCATION
• MEM_EXCLUDE_REGIONS
• MEM_INCLUDE_REGIONS
• XMS_HANDLES
• XMS_MEMORY_LIMIT
• XMS_MINIMUM_HMA

Use DOS_HIGH to load DOS outside the 640K low memory address space.

• Select DOS_HIGH (Load DOS high); then select the Off radio button if your program requires that DOS is located below the 640KB address of DOS session memory. Selecting Off is similar to the statement to DOS=LOW.
• The default value for this setting is On, making all of the memory area from address 0 to address 640KB available to user programs.
• You must change this setting before starting the session.

Defines the amount of conventional memory available to WIN-OS/2.

• Use DOS_RMSIZE (DOS memory size) if you want to change the amount of memory available to DOS programs running in this session. The field for this setting shows the amount of memory, in kilobytes (KB), that a DOS program has for its use. Values range from 128 to 640. If you want to decrease the amount of memory available to DOS programs running in this session, drag the box, select a button, or type into the entry field.
• The maximum value, 640, is the default.
• You must change this setting before starting the session.

• This setting is used to decrease the amount of available memory to less than 640 KB. Do not decrease this value for WIN-OS/2 sessions.
• Decrease the amount of program memory if your video adapter requires some of the 640KB normally allocated to programs, or if your program cannot run properly in an area of memory only as large as 640KB.

Allows DOS TSRs and devices to control the upper memory blocks (UMBs).

• Select DOS_UMB (DOS owns UMBs); then select the Off radio button when required to give ownership of upper memory blocks (UMBs) to certain types of terminate-stay-resident (TSR) programs and DOS device drivers.
• Memory addresses from 640KB to 1MB can be divided into UMBs of 16KB or more. When TSR programs and device drivers reside in UMBs, your other DOS programs can use all of memory address area 0 to 640KB. The DOS kernel normally owns UMBs and manages the loading of TSR programs and device drivers into a UMB using the DEVICEHIGH= and LOADHIGH= statements in your DOS CONFIG.SYS file. Some programs capable of loading into a UMB must own and manage the UMB. Change this setting to Off for a DOS session if you want to run a program that must own a UMB in that session.
• The default value for this setting is On.
• You must change this setting before starting the session.

Allows you to control whether DOS API translation is enabled for DPMI applications in this session.

• Select DPMI_DOS_API (DOS API Translation) if your program can use the DPMI (DOS Protected Mode Interface). The field for this setting contains a list, and the selection you make in this list determines whether requests for DOS system services are translated by the system or by your DOS program. Translating means changing the memory address of the initial request from above 1MB (protected mode memory) to below it (real mode memory) where DOS can access and fill the request.
• Select AUTO if some of your programs already perform this translation. You can identify a program that translates between upper memory and the lower 1MB by documentation stating that the program comes with a DOS extender based on the DPMI specification.
• Select ENABLED if you use programs that expect the operating system to perform the translation. An example of a program that relies on the operating system to translate is a program written for Windows.
• Select DISABLED if your programs do not use DPMI.
• The default value is Program-selectable.
• You must change this setting before starting the session.

This setting allows you to specify the amount of DPMI memory, in megabytes, available for DOS session.

• Use DPMI_MEMORY_LIMIT to define the amount of DPMI (DOS Protected Memory Interface) available to the DOS session. The field for this setting contains values expressed in 1 megabyte (MB) intervals, ranging from 0 to 512MB. To change the value, drag the box, select a button, or type into the entry field. This setting enables you to specify the amount of DPMI memory needed for your DOS programs, on a per-session basis.
• Select 0 if your DOS program does not use DPMI.
• The default value is 16 (MB). However, the value set by the installation program is 64. Increasing this setting for a WIN-OS/2 session enables more programs to run in this session.
• A Windows application may not be able to start or would exhibit poor performance behavior if it doesn't have enough DPMI memory. For Win32s applications, make sure you have the DPMI_MEORY_LIMIT set to at least 64. Paradox 7 and AutoCAD 13 will need 128MB of DPMI memory to run satisfactorily.
• You must change this setting before starting the session.

Use this setting to control the size, in kilobytes (KB), of the network translation buffer for DPMI programs in this session.

• The default value is 8 KB. The range is from 1 to 64 KB.
• This setting allows you to configure the size of the translation buffer for DPMI programs, for example, Windows programs that transfer data over a network. If a network-specific Windows program does not run correctly under OS/2, increase this setting, then restart the session.
• You must change this setting before starting the session.

Use EMS_FRAME_LOCATION to change the location of the Lotus/Intel/ Microsoft Expanded Memory Specification (LIM EMS) expanded-memory region. Select the arrow to the right of the list to see all the choices.

• Use this setting if your DOS session addresses a device that requires an area of memory within an automatically determined expanded-memory region. If you have a problem running a program that takes advantage of LIM EMS, change the EMS_HIGH_OS_MAP_REGION DOS setting to 0, then run your program. If the problem continues, change this EMS_FRAME_LOCATION value.
• Select NONE if you want to turn off the high EMS range. The default is AUTO, which enables the session to locate expanded memory automatically.
• You must change this setting before starting the session.

This setting allows you to adjust the size of an additional EMS region.

• Use EMS_HIGH_OS_MAP_REGION to select an amount of memory that a DOS program can add to the 64KB expanded-memory region accessed by Lotus/ Intel/ Microsoft Expanded Memory Specification (LIM EMS). The field for this setting contains values in kilobytes units, ranging from 0 to 96
• To change the value, drag the box, select a button, or type into the entry field.
• If you select values for the MEM_EXCLUDE_REGIONS and MEM_INCLUDE_REGIONS settings to avoid a conflict with addresses used by devices, you can set this EMS_HIGH_OS_MAP_REGION to an area that accommodates both your program and the device.
• To resolve an expanded-memory address conflict with a device, set MS_HIGH_OS_MAP_REGION to 0.
• The default value is 32.
• You must change this setting before starting the session.

This setting allows you to use and to set the size of the remappable conventional memory.

• Use EMS_LOW_OS_MAP_REGION to select an amount of re-mappable conventional memory. This setting affects only DOS programs capable of remapping conventional memory. The field for this setting contains values in kilobytes (KB) units, ranging from 0 to 576. To change the value, drag the box, select a button, or type into the entry field.
• The default value is 384.
• You must change this setting before starting the session.

This setting allows you adjust the amount of EMS memory.

• Use EMS_MEMORY_LIMIT to define the amount of EMS (Expanded Memory Specification) available to the DOS session. The field for this setting contains values expressed in 16-kilobyte (KB) units, ranging from 0 to 32768. To change the value, drag the box, select a button, or type into the entry field.
• Select 0 if your program cannot use EMS. Select a value higher than the default for a program that requires a large amount of expanded memory. This setting enables you to limit the amount of EMS that a program reserves, which prevents a program from allocating more memory than necessary. The system does not reserve any EMS for a program until that program requests EMS.
• The default value is 2048.
• You must change this setting before starting the session.

This setting allows you to specify regions that EMS/XMS cannot use.

• Use MEM_EXCLUDE_REGIONS to fill in any regions any regions between memory addresses 640KB and 1MB that you want to force the system to map to physical memory at the same address. EMS (Expanded Memory Specification), XMS (eXtended Memory Specification), or a copy of a ROM (read-only memory) program cannot use the areas you exclude. Type addresses as hexadecimal numbers. You can specify a range of memory, or you can supply a single address for the beginning address for a 4KB region. If you want to exclude several regions, separate them with commas. For example:

• By default, this field is empty.
• You must change this setting before starting the session.

This setting allows you to specify regions that EMS/XMS can use between RMSIZE and 1 MB..

• Use MEM_INCLUDE_REGIONS to fill in any areas between memory addresses 640KB and 1MB that you want to designate for EMS (Expanded Memory Specification), XMS (eXtended Memory Specification), or a copy of a ROM (read-only memory) program. Type addresses as hexadecimal numbers. You can specify a range of memory, or you can supply a single address for the beginning address for a 4KB region. If you want to include several regions, separate them with commas. For example:

• The include region D0000-D8000 will include the entire memory area between D8000 and D8FFF.
• Assign addresses to the include region when you know your DOS session does not use device drivers or hardware adapters that use memory between 640KB and 1MB. Including regions can improve the performance of programs that use EMS or XMS memory.
• By default, this field is empty.
• You must change this setting before starting the session.

This setting allows you to adjust the number of handles for XMS usage.

• Use XMS_HANDLES to change the number of XMS (eXtended Memory Specification) handles set aside for use by the DOS session. The field for this setting contains values ranging from 0 to 128 (handles). To change the value, drag the box, select a button, or type into the entry field.
• Each XMS block has a handle (a unique number) associated with it, and the XMS facility allocates memory space to hold the quantity of handle numbers you specify. Use this setting to limit the reserved spaces. You can increase the value in this field if you expect your program to require a large number of handles. Setting aside space for a large number of handles may slow your system.
• The default value is 32.
• You must change this setting before starting the session.

This setting allows you to adjust the amount of XMS memory available.

• Use XMS_MEMORY_LIMIT to specify the amount of memory any one DOS session can allocate to XMS (eXtended Memory Specification). The field for this setting contains values in kilobyte (KB) units, ranging from 0 to 16384. The value 16384KB is equivalent to 16 megabytes (MB). To change the value, drag the box, select a button, or type into the entry field.
• Specifying a large number for either the global or the per-session extended-memory limit can slow your system.
• The default value is 2048.
• You must change this setting before starting the session.

This setting allows you to adjust the minimum allocation size of the High Memory Area (HMA).

• Use XMS_MINIMUM_HMA to change the minimum of high memory area (HMA) available for use as conventional memory. The field for this setting contains values in kilobyte (KB) units, ranging from 0 to 63. To change the value, drag the box, select a button, or type into the entry field.
• Only one program per session can use HMA. You can use this setting to adjust the size of the minimum memory allocated to HMA. This prevents a small program from allocating HMA and wasting any area between the program size and the HMA maximum of slightly less than 64KB.
• Only a real-mode program can use HMA as conventional memory. If your program can run in the protected mode specified by DPMI (DOS Protected Mode Interface), you do not need this setting.
• The default value is 0, or no minimum, which causes the system to assign the entire HMA area to the first program requesting HMA.
• You must change this setting before starting the session.

For a DOS or Win-OS2 session, OS/2 provides the following available video settings.

• VIDEO_8514A_XGA_IOTRAP
• VIDEO_FASTPASTE
• VIDEO_MODE_RESTRICTION
• VIDEO_ONDEMAND_MEMORY (On-demand memory allocation)
• VIDEO_RETRACE_EMULATION
• VIDEO_ROM_EMULATION
• VIDEO_SWITCH_NOTIFICATION (Screen-switch notification)
• VIDEO_WINDOW_REFRESH (Window refresh interval)

This setting is used to directly access the Model 9514/A or XGA video mode.

• Select VIDEO_8514A_XGA_IOTRAP; then select the Off radio button if you want your DOS program to access the model 8514/A or XGA (extended graphics array) video directly. If you select Off, your program might run faster, and you release the 1 megabyte (1MB) of memory allocated to saving video information in a DOS session. Certain operations such as painting a dithered background will run faster when settin if Off.
• If you have this setting Off and you switch from your 8514/A or XGA program, the screen image might not be correct when you return to the program. To correct this problem, set the VIDEO_SWITCH_NOTIFICATION (Screen-switch notification) DOS setting to On. This notifies your DOS program to redraw the screen.
• When VIDEO_8514A_XGA_IOTRAP is set to Off, you cannot copy information from that session to the system clipboard, nor can you view the program from a window.
• The default value is On to ensure that the screen image is restored on a screen switch.
• You must change this setting before starting the session.
• Set this to ON for all WIN-OS/2 sessions that run in 8514 or XGA video modes.

This setting is use to increase the speed of input other than the keyboard (e.g., character Cut and Paste transfers).

• Use VIDEO_FASTPASTE (Fast paste); then select the On radio button if you want to increase the speed of character Cut and Paste transfers between the clipboard and a DOS session.
• This setting does not work with programs that monitor keyboard interrupts directly. Further, if you use a program that re-buffers keystrokes internally, that internal buffer can overflow because of a large quantity of paste-transferred characters.
• The default value is Off.
• You can change the setting for this session at any time.
• Pasting into the DOS command prompt, or any application using DOS Console I/O functions, generally works. However, the Microsoft Editor (M) and its successor, Programmer's Workbench (PWB), can fail when using fast pasting, because they rebuffer keystrokes in an internal buffer, which can overflow.

This setting extends DOS conventional memory beyond the 640 KB address space by limiting the video mode support to text or CGA graphics.

• Use VIDEO_MODE_RESTRICTION if you want to remap as user ( conventional) memory the non-visible portion of video memory (beyond address 640KB) for a program that displays only text or low-resolution graphics, such as those produced by a CGA (color graphics adapter). The field for this setting contains a list. Select the arrow to the right of the list to see all the choices.
• Selecting CGA (for a program that is text-only or uses low-resolution graphics) adds 96 kilobytes (KB) to program memory space. Selecting MONO (for a program that uses monochrome text) adds 64KB to program memory space. This is valuable for applications that do not take advantage of EMS or XMS memory extenders.
• The DOS_RMSIZE (DOS memory size) setting (RMSIZE) must equal 640KB.

• The default value is NONE.
• You must change this setting before starting the session.

This setting delays allocation of a video-save buffer which can free memory swap space for use by full screen session.

• Select VIDEO_ONDEMAND_MEMORY (On-demand memory allocation); then select the Off radio button if you want to ensure that a full-screen session operates in the highest resolution video modes.
• When you switch from a full-screen session, the system saves the full-screen video image in a reserved area of memory. Selecting Off causes the system to reserve the memory space for saving a video image at the start of a program, rather than at the time of the screen switch. Selecting Off might prevent a program from failing for lack of sufficient memory to save a high-resolution, full-screen image at the time you switch from the full-screen view.
• The default value is On, which (1) causes the system to reserve this memory space for saving the video image at the time you switch from full-screen, (2) enables you to start a program quickly, and (3) frees memory space for other programs.
• Selecting ON allows a full screen DOS session to run without pre-allocating a virtual video buffer for high-resolution graphics modes. Using this setting does not prevent execution of graphics application. It means that allocation of the buffer is delayed until it is needed. This can save a substantial amount of memory/swap space, which might be important under certain low-memory conditions. It also enables you to start a program quickly
• You can change the setting for this session at any time.
• This setting reduces swap space requirements for full screen DOS sessions
• If the allocation of a virtual video buffer for a full screen DOS session fails at the time the application changes video modes, the sessions will be frozen and you must switch back to the shell to free memory. Unless you are able to free memory from another session, you may be unable to get the DOS application running again. This is a concern if the application contains unsaved data.

This setting allows simulation of video retrace status port to provide faster access which improves text scrolling speed.

• Select VIDEO_RETRACE_EMULATION; then select the Off radio button if you want to disable frequent video retrace. When this setting is Off, retrace occurs only at the interval specific to the video mode of the running DOS program.
• DOS applications that poll the video retrace status port often write to the screen only during the retrace interval, even though it is safe (on EGA and VGA adapters) to draw at any time without causing interference (also known as "snow"). This feature causes most applications to write to the screen more often, and compensates for the performance drag imposed by monitoring the port in the first place.
• A few DOS programs run slower with VIDEO_RETRACE_EMULATION set to On. Changing this setting to Off increases the performance, but screen-switching is not as reliable. During screen-switching, the program palette may not be restored correctly; this may result in a blank screen.
• The default value is Off.
• You can change the setting for this session at any time.
• Set Off for games and graphics applications.
• This setting controls the frequency of video retrace.
• A few DOS applications run more slowly with this setting set to ON.
• When set to off, retrace occurs only at the interval specific to the video mode of the running DOS application.

This setting emulates text based video ROM functions (INT 10h ) for performance and codepage support.

• Use VIDEO_ROM_EMULATION; then select the Off radio button if you want to disable the emulation (in text mode) of these common video functions: WriteChar, WriteTTY, and full-screen Scroll. Select Off if your video read-only-memory (ROM) provides enhancements to these functions.
• The default value is On, Because the INT 10h ROM Video services are well documented, incompatibilities are unlikely, and the performance benefits of using the emulation are quite significant.
• You can change the setting for this session at any time.
• Provides faster output for selected video functions than ROM services typically provide. This also has a dramatic effect on the performance of those functions in a window.
• Some ROM might offer enhanced services that are not included in the emulation. Applications that rely on these services might not run correctly.

This setting notifies the DOS program when the session switches to or from a full screen VDM session.

• Select VIDEO_SWITCH_NOTIFICATION (Screen-switch notification); then select the On radio button if you want to notify a DOS program about a switch between background and foreground. If you select On, programs that monitor screen-switching will save or redraw the screen on a screen-switch.
• Select On if the OS/2 video driver does not support all the features offered by your video adapter and used by your DOS programs. This setting allows applications that monitor this notification to redraw their screens as needed. This might be necessary for some video adapters that provide modes (and applications that use those modes) that are not fully supported by the OS/2 video driver or are slightly incompatible. It also is valuable in situations where an OS/2 video driver has not allocated a virtual video buffer (see VIDEO_8514_XGA_IOTRAP).
• Use this setting if you use the VIDEO_ONDEMAND_MEMORY (On-demand memory allocation) DOS setting, because concurrent buffer allocation and screen switching can make the screen go blank. For WIN-OS/2 sessions, set this setting to On.
• For standard monochrome, CGA (color graphics adapter), EGA (enhanced graphics adapter), and VGA (video graphics adapter) video modes, the OS/2 video driver should perform adequately with this setting at Off. If you find your program redraws too often with this setting on, select Off.
• The default value is Off, because most standard video modes do not use screen-switch notification.
• You can change the setting for this session at any time.
• WIN-OS/2 understands this notification and will redraw the screen when the screen is switched. For WIN-OS/2 sessions, set the setting to ON.
• This setting must be ON if the VIDEO_8514A_XGA_IOTRAP is set OFF

This setting adjusts the window update frequency for a specific DOS session.

• Use VIDEO_WINDOW_REFRESH to adjust the time that elapses before a window is redrawn. The values range from 0.1 second to 60.0 seconds (1 minute). To change the value, drag the box, select a button, or type into the entry field.
• Increase the value, thereby increasing the delay between screen redraws, if you run a program (such as a graphic program) that writes frequently to video memory. Increasing the delay between each write to video memory frees the processor for other program tasks. Reduce the value if you find the program hard to use or because you prefer more frequent screen image updating. This setting does not change the rate of scrolling, keyboard input display, or any video events other than refresh.
• To test the effect of changing the value for this setting, test the text output from a DOS DIR or TYPE command before and after adjusting the setting.
• The default value is 0.1, which represents the interval between window updates.
• You can change the setting for this session at any time.
• A large refresh period can make an application unusable (or at least, very hard to use).

The following list contains the available mouse and touch-sensitive screen settings.

• MOUSE_EXCLUSIVE_ACCESS
• TOUCH_EXCLUSIVE_ACCESS

Allows VDMs to run applications that maintain their own mouse pointers. Some DOS applications manage their own mouse positions and movements; in many cases, the application's values for mouse sensitivity and/or double-speed threshold are different from those of Presentation Manager. As a result, a Presentation Manager mouse pointer might be outside the VDM window while the application pointer is somewhere in the window not receiving any mouse events. This means having two asynchronous mouse pointers on the screen.

• Select MOUSE_EXCLUSIVE_ACCESS; then select the On radio button if you use a program that manages its own mouse positions, setting mouse sensitivity and mouse tracking speed separately from Presentation Manager mouse settings. For example, use MOUSE_EXCLUSIVE_ACCESS and select On if your screen displays two unsynchronized mouse pointers, one in the DOS session, and one in a Presentation Manager session or on the Desktop.
• After you select On, you must press a mouse button inside the DOS session to delete the Presentation Manager pointer. Press Alt, Ctrl+Esc, or Shift+Esc to display the Presentation Manager pointer again.
• You force the physical mouse driver to send its events directly to the virtual mouse driver without going through Presentation Manager. Only one mouse pointer appears when the particular VDM window has the focus
• The default value is Off.
• You can change the setting for this session at any time. However, this only marks the VDM window and does not actually activate the setting. To activate it, press a mouse button in the VDM window.The Presentation Manager pointer disappears, leaving only the application pointer. To regain the Presentation Manager pointer, press any of the hot keys (Alt, Ctrl+Esc, Shift+Esc).
• Examples: WordPerfect 5.1 has its own block-shaped mouse pointer that appears together with the system mouse pointer when the window has the focus. Turning MOUSE_EXCLUSIVE_ACCESS on allows the user to remove the system mouse pointer when in WordPerfect.

• Select TOUCH_EXCLUSIVE_ACCESS; then select the On radio button if a program you run in a DOS Window does not respond properly when you touch a touch-sensitive display (such as the IBM PS/2 Touch Display, Model 8516) that is connected to the mouse adapter of an IBM Personal System/2. For example, if a drawing program does not draw lines when you move your finger across the display screen, you use TOUCH_EXCLUSIVE_ACCESS and select On. You do not need this setting for a program running in a DOS full screen session.
• When this setting is On, the DOS program reads your position in any area of the screen you touch. For example, if you touch the upper-left corner of the screen, the program reacts as though you are touching the upper-left corner of the window. To have the place you touch match the position you want to touch in the window, make the window the same size as the screen.
• The default value is Off.
• You can change the setting for this session at any time.

The following settings will affect the performance of Communications applications.

• COM_DIRECT_ACCESS
• COM_HOLD
• COM_RECEIVE_BUFFER_FLUSH
• COM_SELECT
• HW_ROM_TO_RAM
• HW_TIMER

When set on, VCOM.SYS allows direct access to the COM ports.

• Use COM_DIRECT_ACCESS (COM direct access) to give a program direct hardware access for COM ports. Select the On radio button to track which COM port the DOS session is using. The default is Off, which disables direct access to a COM port.
• You must change this setting before starting the session.
• Programs that need direct access, such as AS/400 Asynch Router, FastLynx, FSDUAT, and MS Word will now work.
• Buffers in COM.SYS cannot be used. Characters might be lost, and some applications might suffer from the lack of buffering.
• The default is Off.

When set on, provides exclusive access to COM ports for the specified VDM, preventing other processes from using the port and preventing the operating system from releasing the port until the VDM terminates.

• Select COM_HOLD (Hold COM resource); then select the On radio button if you want to give exclusive use of a particular communications port (for example, COM1) to your DOS session. Selecting On prevents other sessions from using the same COM port until you end the DOS session. It also enables the DOS session using the COM port to access data files on your disk or diskette.
• When this setting is Off, the operating system releases the COM port as soon as the program using it ends, even if the DOS session from which you access the port is still active. Some DOS communications functions, such as accessing a computerized bulletin board, require two programs -one that dials the bulletin board, and one that enables you to exchange information with the bulletin board computer. Select On if your system sometimes disconnects a dialed connection from a DOS session. For example, select On if you have difficulty maintaining communication between a DOS program and a bulletin board. The default value is Off.
• You must change this setting before starting the session.
• If not required by the application running in a VDM, this setting might prevent their applications from accessing COM ports.
• The default setting is Off.

This setting allows control of the received data buffers when the DOS session is switched to the foreground, or when the DOS program enables the received data interrupt.

• Select COM_RECEIVE_BUFFER_FLUSH to control the content of the received data buffers when the received data interrupt is enabled by a DOS program or when a DOS session is switched from the background to the foreground. The field for this setting contains a list from which you can select Receive Data Interrupt Enable, Switch to Foreground, ALL, or NONE.
• Some DOS programs require that communications data be discarded when the program is switched to the foreground; other DOS programs require that the data be kept. You can use COM_RECEIVE_BUFFER_FLUSH to override the program setting and discard or keep the communication data for all programs in this DOS session.
• Select Receive Data Interrupt Enable to indicate that, for this DOS session, the operating system is to discard data in the received data buffer when the DOS program enables the received data interrupt.
• Select Switch to Foreground to indicate that, for this DOS session, the operating system is to discard data in the received data buffer when the DOS program is switched to the foreground.
• Select ALL to indicate that communications data be discarded when a DOS program enables the received data interrupt or the program is switched to the foreground.
• Select NONE to indicate that, for this DOS session, the operating system is to keep data in the received data buffer.
• The default is NONE.
• You can change the setting for this session at any time.

When set, allows a program to select and use one communication port.

• Use COM_SELECT (COM Selected Port Access) to select the COM port for this DOS session. The field for this setting contains a list from which you can select either ALL, COM1, COM2, COM3, COM4, or NONE. For example, if you select COM1, only COM1 can be accessed from this DOS session.
• Some DOS programs take control of all available COM ports, even though they access only one. Therefore, once this DOS program starts, a COM port cannot be accessed. COM_SELECT prevents the DOS program that takes control of the available ports from also taking control of unnecessary resources.
• Select NONE if you do not want any COM ports available for the DOS programs you run in this DOS session.
• The default is ALL, which enables all COM ports to be used from this DOS session.
• You must change this setting before starting the session.
• You can limit your program to just the COM port that it requires; some programs, such as like LapLink Pro, try to take over every available COM port. Communications that are not selected are hidden from the program.
• Some programs need to have access to the COM ports to work, even if they are not using them.

Enabling HW_ROM_TO_RAM causes the operating system to copy read-only memory (ROM) and run the copy in 32-bit random access memory (RAM).

• Select HW_ROM_TO_RAM (Copy ROMs to RAM); then select the On radio button if you want to copy the Basic Input Output System (BIOS) from read-only memory (ROM) to random access memory (RAM). BIOS might run faster in ROM than in RAM. Also, to test and debug a program, you can set break points in the RAM copy.
• This setting is useful if debugging the kernel. The change allows normal breakpoints to be set in ROM and allows stepping over calls and loops.
• If an application writes to a memory address used by the ROM while this setting is enabled, it might cause unpredictable results for that application and for every application run thereafter in the VDM.
• The default value is Off.
• You must change this setting before starting the session.

This setting allows an application to have direct access to the 8253 timer ports, and prevents the operating system from trapping, or intercepting, the timer request and emulating a timer.

• Use HW_TIMER (Timer Hardware Access) if you want to give a program direct access to hardware (model 8253) timer ports. Select the On radio button to prevent the operating system from trapping, or intercepting, the timer request and emulating a timer.
• Use this setting for timing-critical programs. Your program might require direct timer access to avoid the trapping overhead introduced by an emulated timer. (An emulated timer does not include in its timing the amount of time used to trap a timer request.) Further, some computers poll timer ports, introducing an additional delay that can become too long when added to trapping overhead.
• A program may not function properly if you select On after the program has already emulated timing. The program may not function properly if you change the setting back to Off after the program directly uses a hardware timer, because the program then fails to adjust properly for emulated timing. Selecting On for this setting for multiple DOS sessions can cause programs running in these sessions to interfere with one another.
• Certain timing-critical applications do not run (or run much slower) if accesses to timer ports are trapped and virtualized. In addition, the values they read do not accurately reflect the amount of time passed, because they do not take trapping overhead into account. Enabling this setting allows certain timing-dependent code to run more effectively.
• Applications that change the divisor before this setting is enabled, and then read the timer ports after the setting has been enabled, might not function properly. If the setting is enabled first, the VDM does not detect changes to the divisor correctly, and the simulated interrupt frequency will be incorrect.
• The ROM on some systems implement very brief delays by polling the timer ports. These delays become unacceptably long unless direct timer port access is allowed.
• The default value is Off. Most applications operate normally with timer virtualization.
• You can change the setting for this session at any time. It is useful to change this setting dynamically and watch for changes in application performance.

OS/2 Warp 4 supports a variety of hardware devices for use in games, video display, input, printing, speech, multimedia, and data communications. As a result, OS/2 Warp 4 provides a number of settings which can be used to tune individual device performance. Those tuning tips are discussed in the following sections.

The resolutions that can be set for a particular display adapter are dependent on the:

• Specific display being used
• Specific display adapter being used
• Graphics accelerator chip set on the adapter
• Video device driver being used
• Amount of video memory on the adapter

Many of the accelerated video device drivers with OS/2 support the various resolutions and number of colors. Not all of the device drivers support all of the resolutions. In general, the higher the display resolution, the slower the performance would become. However, since high resolution has better visual effects, you have to decide how to compromise between visual and performance.

Some adapters have configuration DIP switches to select desired vertical refresh rates for high-resolution modes (800 x 600 and 1024 x 768). Others are shipped with DOS video-configuration utility programs that allow selection of refresh rates. Usual refresh rates range from 56 Hz to 72 Hz non-interlaced or 88 Hz interlaced. The display has to be capable of synchronizing to this frequency for proper mode set. Make sure you understand how OS/2 controls the display configuration discussed below before attempting to change your display configuration

SVGA display and video mode configuration under OS/2 is controlled by the SVGADATA.PMI file. This file can be provided by the display adapter manufacturer or created using the SVGA utility program. he SVGA utility program gets information from the SVGA chip set to set each video mode and captures the current state of the display adapter. This information is stored in the SVGADATA.PMI file and used when the system is started.

• Both the SVGA.EXE and SVGADATA.PMI are located in the \OS2 directory.
• To create the SVGADATA.PMI file, type one of the following commands at a DOS command prompt and press Enter.

Switching to a lower capability display after installing high-resolution (SVGA) drivers might cause the system to start out of synchronization.

• Follow this procedure to switch to a display with less capability:

• If your system has an 8514/A adapter, you can improve the performance of your Windows programs by changing their properties. Open the Properties notebook for each Windows program and change the following WIN-OS/2 properties:

Printing performance can be tuned by making changes with printer and job property settings, changes to the CONFIG.SYS, and changes to the print spooler. Some of these changes are generic and affect all printing, while some affect only certain types of printing.

Every object, including the printer object, has adjustable settings. The printer object has several settings that affect performance. These are Job Properties and Printer Properties. Printer Properties can be located by turning to the Printer driver notebook page, click on the printer object you wish to view. Use mouse button 2 to display its context menu, and then select settings to see the printer properties. Job Properties can be accessed by selecting the Job Properties button on the Printer driver page of the notebook. Job Properties control things such as resolution, orientation and number of copies while Printer Properties describe the way the printer is set up, like the number of paper trays or font cartridges installed in the printer. Printer Property information is stored in the printer driver. Not all settings are supported by all printers. Queue options include Job dialogue before print, printer-specific format and print while spooling. Job dialog before print allows the user to specify job properties on a per-job basis, rather than using default job properties. Printer-specific format creates print jobs that only a specific type of printer can print correctly. These jobs take much more storage than printer-independent jobs. Print while spooling allows the job to begin printing immediately, without waiting to receive the end of job from the program. Print options includes start and stop times.

Not all settings listed in this section are available for all printers, but, if available, they do change the performance of printing on your system. The following properties will affect performance.

By specifying the amount of memory your printer has, the printer driver can determine if compression is to be used. Compression improves performance by reducing the amount of data that has to go to the printer.

This option allows you to vary the resolution of your graphics printing. The selections are usually presented in terms of "dpi" (dots per inch). The higher the number the better quality your print will be. The drawback is that it will also take longer to print. However, you can use a low number for draft output and select the highest number for printing the finished version. A printer's memory size can limit the resolution you can choose.

This option compresses graphic print data which has the advantage of faster printing for most jobs that contain graphics. Two common types of compression are G4 and TIFF Packet Byte.

• G4 - This improves the printing of graphic data that does not have large numbers of alternating bits, for example, large areas that are filled with solid color. G4 is available on all IBM 4029 printers and IBM 4019 models that support Form Feed Time Out. The 4019 models do not support G4 when printing in landscape mode.
• TIFF - This improves the printing of graphic data that consists mostly of repeating bytes, for example, large areas having one type of fill pattern.

This option allows you to download (copy) OS/2 system bitmap fonts, to the memory of your printer. They will be copied to the printer as a device bitmap font. The advantage is that a device font uses a smaller spool file and prints quicker than a font printed in raster (graphic font) form.

If overlaying system fonts with graphics, or if print output differs from that shown on the screen, then disable this option.

Pattern filling commands will be directly sent to the printer instead of asking the operating system to perform the pattern filling. This reduces the spool file size for pages that contain dense graphics (shaded and patterned rectangular areas), and large scaled text. These improve printing speed. This option should not be used if printer output patterns must exactly match patterns displayed on your screen, nor if there are overlapping shaded or patterned graphics in your document.

This option enables HP-GL/2 output. This allows the supporting of many more graphics commands in the printer. This will allow faster printing of graphic objects such as lines and circles. This also reduces the spool file size and helps to print more quickly. For faster output, enable Page Protection (which may require additional printer memory) on both the printer and Printer Properties dialog and use HP-GL/2.

Large Buffers allow the printer drivers to use more of OS/2's memory in order to speed up printing. Around 4 MB is used for printing so system memory should be at least 8 MB. If this option is set to OFF, then smaller memory requests, around 1 MB will be used conserving memory. If you have less than 8MB of system memory, then it is better not to use this option.

The Print while spooling option allows the printer to start processing the print job before the application has finished sending the entire job to the spool queue. Print jobs formatted in printer-specific format (PM_Q_RAW) can speed up printing by using Print While Spooling.

This "threading" will increase throughput but could cause timeout problems while printing large files with images. To solve this problem you can disable the Print While Spooling option or you can increase the timeout value setting in the port object. The default is On.

Start Time and Stop Time can be entered for each print object. For example, time settings for "lunch time", 12:00p - 12:50p, can be used which enables printing when you are not there.

Fonts can be stored in several places. They can be built into the printer, housed on a cartridge that's plugged into the printer, or reside on your system and be downloaded to the printer as needed. When you use printer-based fonts, whether built-in or on a cartridge, you can print faster than if you first have to download them.

Fonts are either bitmapped or scaleable. With a bitmapped font, each character is stored as a collection of individual pixels, so you need a separate definition for each point size. Scaleable fonts, also called outline fonts, are stored as algorithms. This means that the system can generate the font in any size using the algorithm. Generating scaleable fonts takes time. If you're using one font in just one size to format an entire document, the extra time may be hardly noticeable. If you're using a lot of different fonts, the time may be considerable. You can use any combination of these font variations, bitmapped or scaleable, stored in the printer or in the computer. Clearly, you'll get the fastest printing with bitmapped fonts stored in the printer (see Fast System Fonts), and the slowest with scaleable fonts stored in your computer.

Despite the speed disadvantage, there are strong arguments for storing fonts on your computer and for using scaleable rather than bitmapped fonts. First, most printers have room for only one or two font cartridges. So if you want to add new fonts to your library, you have to switch cartridges when you want to use them. It's easier and much more efficient to store them on your hard disk, where they're all available at the same time. An advantage to scaleable fonts is that you're guaranteed to have the typeface available in any size you'll ever need. Scaleable fonts require far less storage space on-disk, or in your printer, than a set of equivalent bitmapped fonts in a range of sizes.

The PRINTMONBUFSIZE parameter in the CONFIG.SYS file sets parallel-port device-driver character monitor buffer sizes for LPT1, LPT2, and LPT3. To speed up data transfers to devices connected to your system's parallel ports, increase the associated device-driver monitor buffer sizes. For example, PRINTMONBUFSIZE=2048,134,134 increases the device driver buffer for a device connected to LPT1 to 2048 bytes. The default is 134,134,134.

Printing through the spooler will provide the best performance on your system. Here are some suggestions and settings that can affect printing performance.

It is recommended that the OS/2 spooler be enabled when more than one print job can be sent to the printer at one time. The spooler provides flexibility while optimizing the use of the system's print resources. The OS/2 spooler can print a job in the background while you continue using the application. You can also set the spooler's print priority via the spooler object setting.

The OS/2 spooler can support a number of printers simultaneously and can be configured so that jobs on a single queue can be shared among all the printers. This load balancing, called pooling, is particularly important in server environments and can be achieved without the knowledge of your applications. Jobs can also be reprioritized while they are waiting in the queue. For example, an urgent job can be given a higher priority than other queued jobs or can be selected to print next, see Changing a Print Job's Priority.

If only one print job will be active on your printer at a time, you can disable the spooler. This will save memory and remove one process and one thread from your system's overhead.

If print jobs are very large, you may assign a different spooler path (drive or path) that has more space than your install drive. If your print usage is heavy, you want to place the spool file on your fastest hard disk. The spool path is a setting of the spooler object.

The OS/2 spooler has a setting called Print Priority. This allows you to vary the spooler's priority from low to high. The default setting allows printing to be balanced with your use of the desktop and your applications. If your application appears to be printing slowly, you may want to choose a slightly higher value so that printing will complete faster. If you choose a higher value, OS/2 will let print jobs print faster, but this may cause your desktop or applications to respond slower. In a print environment where very little on screen work is performed or where print performance is of utmost concern, you should increase the value. Priority changes become effective when you close the spooler object folder.

There are two formats of spool file data. They are the standard (PM_Q_STD) or the raw (PM_Q_RAW) spool file data formats. The standard format is much preferred as it consumes much less disk space than the raw format file. Having less data to send across the parallel port saves time in getting the data into the printer's buffer. Network traffic is also reduced if printing across a LAN.

Changing a print job's priority will cause that particular print job to print before any other queued job. To do this, click on the print job you wish to change. Use mouse button 2 to display its context menu, and then select print next. You can change the priority of a print job so that it can print before or after other jobs queued. To do this, click on the print job you wish to re-prioritize. Use mouse button 2 to display its context menu. Open Settings and change the value in the Priority field.

While there are no performance specific tuning options, there are two things to check.

• Do not use the LPTDD.SYS device driver unless necessary. (The DOS application is using INT 21h and is not closing the LPT1 handle). This will slow down your DOS printing performance.
• The other is the DOS setting called PRINT_TIMEOUT. This is useful for DOS applications which do not explicitly close their print jobs. This is the time that OS/2 waits before forcing a print job to the printer. A timeout of 1 or 2 seconds is sufficient for small print jobs, such as copying the contents of the screen. However, when printing large files, formatting documents, or running calculations, the value must be set high enough to allow all print results to reach the spooler before the time limit expires. If not, results go in two or more spool files instead of one, and the resulting output may be unsatisfactory. The default time is 15 seconds.

You should always keep the OS/2 Spooler enabled to get the most benefit out of the OS/2 print subsystem. This will assure that even from the WIN-OS/2 environment, printing is done in a separate thread. You should also keep the WIN-OS/2 Print Manager disabled unless you are using a COM attached printer. That is, always keep the WIN-OS/2 Print Manager icon closed.

The OS/2 Spooler allows multithreading and can deal with huge print files, even while you work in WIN-OS/2. Print jobs sent from any WIN-OS/2 application to a parallel attached printer won't show up in the WIN-OS/2 Print Manager. In this case if you need to view or manipulate these print jobs, use the correct OS/2 printer object on the Desktop.

You should direct application output to LPTn.OS2 (where n is 1,2,3) where possible. LPTn refers to the physical printer port. LPTn.OS2 is a file which is intercepted by WIN-OS/2 and routed directly to the spooler. This will provide improved performance over the standard LPT port assignments.

You should always install equivalent printer queues in the OS/2 Desktop for your WIN-OS/2 printers even if you are only going to print to them from WIN-OS/2. If there is no equivalent OS/2 printer driver available then use the IBMNULL.DRV printer driver found in the OS/2 printer object.

If you have a COM attached printer and you would like to have your print jobs spooled, then enable the WIN-OS/2 Print Manager. This should be the only reason for you to use the WIN-OS/2 Print Manager. Remember that print jobs directed to LPTn.OS2 and LPTn will still go through the OS/2 Spooler.

• If your printer performance seems slow, try to increase the size of the font cache. The default setting is 96KB. For graphic arts applications, you might want to use a font cache size of 128KB or larger. The size of the font cache determines the amount of system memory available to store font information. The default setting for the font cache is 96KB. You can set the font cache from 64KB to 32000KB. If you are using many typefaces or sizes, you might want to increase the font cache size to improve performance. Experiment with the font cache size parameter to see how it affects performance. If your applications seem unusually slow when you scroll, change pages, or display fonts, your font cache size is probably too small.

• ATM can use pre-built fonts (soft fonts) or resident fonts (cartridge fonts or fonts built into the printer) when the exact font size and style are available. This reduces the amount of printer memory required to print some pages and might improve printing performance. The Adobe Font Foundry program (included with all Adobe Type Library packages) can be used to generate such soft fonts; the ATM Control Panel can then be used to turn this feature on and off.
• If you are using ATM with a PostScript printer, PostScript soft fonts are automatically downloaded when you print; you might want to download fonts that are not resident in your printer prior to printing. Downloading fonts before printing can increase printing performance. This feature is especially useful if you frequently use the same fonts on your PostScript printer.

• Font selection - The selection of text fonts can significantly affect printing performance. OS/2 supports two types of fonts: downloaded SYSTEM fonts and DEVICE fonts. DEVICE fonts are built into the laser printer and perform much faster. When text is formatted for the printer by the OS/2 spooler, one of two paths is taken: (1) for each SYSTEM font text character, the spooler must request a bitmap of the character from the OS/2 operating system, or (2) for DEVICE fonts, the text character is sent directly to the printer as an ASCII character. The results of certain printing tests for a 10 page Lotus WordPro for OS/2 text only document show DEVICE fonts to print 4-to-1 faster than SYSTEM fonts. It also showed 2-to-1 improvement printing a six page Lotus Freelance for OS/2 document which was mostly text with a Freelance SmartMaster background.

• Large Buffer - The Large Buffer option allows the OS/2 Spooler to temporarily use 4 MB of system memory to format the document for the printer, the default for OS/2 Warp Versions 3 and 4 is 1 MB. For a one page document with four large bitmaps mixed with text; the printing time with Large Buffer selected was 50% faster. Large Buffer is set in the printer JOB PROPERTIES - OPTIONS panel.
• Spooling format - The overall time for both spooling formats, standard or raw, to print a document is about the same. However, the STD format is sent to the OS/2 Spooler much faster than RAW format and returns control of the mouse and cursor to the user. When RAW format is used, the application must format the document in the foreground which ties up the keyboard much longer, whereas with STD format, the OS/2 Spooler formats the document in the background. The STD or RAW format selection, if available, is in the PRINT JOB PROPERTIES panel of the application. Some applications, such as Lotus WordPro for OS/2, offer only the faster spooling STD format.
• Spooler priority - As previously discussed, increasing the priority of the OS/2 SPOOLER has a double edged effect. Printing time can be improved up to one third when the OS/2 Spooler priority is increased, but the mouse and keyboard responsiveness decreases accordingly. If absolute printing time is important, setting the OS/2 Spooler priority to the highest setting will help. You might also consider foreground printing for a single user printer by disabling the OS/2 Spooler. Both of these options are set at the OS/2 Spooler icon which is in the OS/2 System - System Setup folder. Click on the OS/2 Spooler icon with the right mouse button. "Disable Spooler" can be selected, or click on "Settings" to open the OS/2 Spooler settings notebook to change the "Spooler Priority".
• Disk cache - Smaller improvements can be gained by increasing the disk cache size for the file system on which the spooler stores it's temporary files. The spooler temporary directory can be changed in the OS/2 Spooler settings notebook. Generally, sizes larger than 4096 kilobytes for a desktop PC provide little, or no improvement. Shared network printers can benefit more when the disk cache is increased on the server. Increasing disk cache permanently reduces the amount of memory available to other applications. Type "HELP DISKCACHE" for the FAT file system, and "HELP HPFS.IFS" for the HPFS file system for information on setting these parameters. Typically, the default disk cache sizes perform well for most documents.

IBM VoiceType is a new and creative approach to personal computing: using your voice to communicate with your computer. VoiceType has two components:

• Navigation lets you use voice commands to move around the OS/2 Desktop, to manage files, folders, and windows, and to work with your programs.
• Dictation lets you write letters and other documents without using a keyboard. You dictate the words and they are converted to text at a rate of 70 to 100 words a minute.

Use sleep mode when you want VoiceType to stop listening, but you want to be able to turn VoiceType on with a voice command. Using sleep mode when you are not using voice commands or dictation increases operating-system performance.

To turn on sleep mode, use either of these methods:

• Say "Go-to-sleep."
• Click on Go to sleep on the Actions menu on the Voice Manager status window.

To turn off sleep mode, use either of these methods:

• Say "Wake-up-please."
• Click on Go to sleep on the Actions menu on the Voice Manager status window.

• If sleep mode is active, the microphone button shows the microphone lying down with Zzz across the top of it.

Voice type applications are very processing and memory intensive. For acceptable performance , the hardware requirements as suggested by OS/2 Warp 4 installation are:

• Intel Pentium 100MHz or higher processor
• 24MB-32MB of RAM
• hard disk with at least 225MB disk space (user selectable)
• 640x480 resolution display with 256 colors
• IBM compatible mouse is required
• diskette drive A and CDROM driver
• 14.4K or higher modem or network connection for Internet access
• Sound card for multimedia or speech
• High quality microphone for speech (requires Active Noise Cancellation feature, ANC, for optimal performance.)

OS/2 Warp 4 is a critical component in IBM's vision of the complete, managed, client-sever system. It is the key element which allows the PC to become the focal point of information processing and places the user in control of this information. OS/2 Warp 4, as the integrating platform, provides a wide degree of support for many connectivity products as well as supporting other existing networking products. This chapter covers performance tuning tips for a OS/2 Warp 4 client workstation.

The OS/2's Multi-Protocol Transport Services (MPTS) allows easy integration of OS/2 Warp 4 into a number of networking environments. The MPTS implementation includes all current transport functionality found in Network Transport Services/2 (NTS/2), including LAN Adapter and Protocol Support (LAPS).

All data sectors received by MPTS are stored in buffer structures called mbufs, also known as clusters. There are two types of mbufs. Small mbufs are 256 bytes long and large mbufs are 4096 bytes long. The initial number of small or large mbufs to be allocated by MPTS can be altered by modifying the line containing "RUN=x:\mptn\bin\cntrl.exe" in the MPTSTART.CMD file as follows:

RUN=x:\mptn\bin\cntrl.exe /SM xx /LM yy

where /SM and /LM are keywords standing for small and large mbuf, and xx and yy are the desired number of mbufs to be allocated. The /SM and /LM keywords are placed on the command line after the arguments to the /P keyword. The specified number of small mbufs is rounded up to the nearest multiple of 128 and the specified number of large mbufs is rounded up to the nearest multiple of 2.

For example, if you specify 600 as the number of small mbufs, the MPTS program allocates 640 small mbufs. If you specify 65 as the number of large mbufs, the MPTS allocates 66 mbufs.

• The default mbuf settings are adequate for most workloads. MPTS dynamically allocates additional mbufs as needed. Consider increasing the default allocation of large mbufs for systems where MPTS is heavily used (such as file servers) and where the NetBIOS protocol is in use.
• If only the INET service driver is in use, the number of large mbufs can be reduced. Doing so may improve overall performance of the Distributed Computing Environment (DCE) by increasing the physical memory available to DCE server processes. A good value for the number of large mbufs is 72.
• If your application does many large file transfers, then you may want to increase the Maximum Transmissible Unit (MTU) size for improved performance. File transfers of 2048 (2K) or greater would benefit by increasing the MTU size. If most of your file transfers are smaller than 2K, then the default MTU size of 1500 is recommended.
• The MTU size can be changed with the IFCONFIG command in the TCP/IP SETUP.CMD. Set the MTU size to the desired packet size plus 40 bytes-the maximum TCP/IP header size. The desired packet size must be a multiple of 2048. For example:

• A related parameter is the XMITBUFSIZE parameter in the token-ring section of your PROTOCOL.INI file. This parameter must be configured to support transmission of buffers that are at least the size that you specified for the MTU. By default, the XMITBUFSIZE parameter is not specified in the PROTOCOL.INI file, and the parameter value defaults to the largest size that your adapter card and ring speed allows. This parameter can be added, but the value must be greater than or equal to the MTU size.
• When changing these parameters, to prevent data loss, the MTU size must not be greater than the maximum that your token- ring adapter allows. Refer to the XMITBUFSIZE range in the appropriate .NIF file (IBMTOK.NIF for example) to determine valid values for both XMITBUFSIZE and MTU size.
• If the transport protocol to be used by an Socket/MPTS application is known in advance, additional steps can be taken to improve performance This topic offers suggestions for the INET (native) transport:
• If Socket/MPTS is installed on a token-ring LAN, increasing the maximum transmit unit (MTS) may improve performance of applications that transfer large amounts of data such as file transfer protocol (FTP). Use the IFCONFIG command to modify the MTU size. The IFCONFIG command is described in Manually Modifying Your TCP/IP Configuration.

A SOCKS (SOCKet Secure) server is a type of firewall host that protects computers in a business network from access by users outside that network. The SOCKS server verifies that your computer and user ID are allowed to access external networks, such as the Internet.

The 32-bit client applications for TCP/IP for OS/2 that can be used with SOCKS support include Telnet, TelnetPM, FTP, FTP-PM, Sendmail, NewsReader/2, Gopher, and WebExplorer.

• To use SOCKS support with FTP, you must use the FTP provided with TCP/IP for OS/2 Version 4.

You can configure SOCKS defaults (including whether SOCKS support is on or off), SOCKS servers, and direct connections to hosts in your private business network by using the Configuration notebook. You can also configure the SOCKS support by manually editing the SOCKS configuration files.

• By default, SOCKS support is turned off.
• Because SOCKS support can affect performance, you should turn it off if you do not need an external connection (outside the firewall).
• SOCKS is intended for client systems. For any system with server responsibility, SOCKS support should be turned off.
• The SOCKS support code attempts to determine whether a connection request is internal or external (inside or outside the firewall). If it cannot determine which kind of connection is requested, it attempts to establish an external connection.
• If you are using a serial connection (SLIP or PPP) to access the Internet, you need to turn SOCKS support off.
• If you have a serial connection to your company's gateway and are using a SOCKS server to connect to the Internet, SOCKS support must be turned on for your system and your host IP address must be registered with your company's gateway.
• The SOCKS support code does not support non-blocking connections. It always waits for a connection to be completed.
• If you are using SOCKS support with WebExplorer, you should not have a proxy gateway or a SOCKS server enabled in WebExplorer.

The following changes to the PROTOCOL.INI file may improve your LAN requester performance.

• Set XMITBUFS to 2. This allows one buffer to fill while the other is transmitting; yielding greater throughput.
• Set XMITBUFSIZE to 4224. Supports sending 4096 data packets and protocol headers. The default is 2048.
• Set T1 to 2000. Changing this timeout value to 2000 (2 seconds) reduces the number of retransmits across the network. If transmissions don't get a response within the time specified in this timeout value, they do multiple retires, resulting in additional network traffic.
• Set T2 to 400. Raising this Receiver Acknowledgment Timer to 400ms reduces network session traffic by allowing a workstation time to respond without having to process retries.
• Set NETBIOSRETRIES to 2. NETBIOSRETRIES specifies how many times LR/LS will broadcast a request for duplicate NETBIOS names. In a reliable network, you can reduce traffic by lowering the number of retries.
• Set LOOPPACKETS to 2. These are internal packets on the adapter that can be used by the adapter to send packets to itself rather than transmitting them over the network. Increasing this value reduces network traffic.
• Set NETBIOSTIMEOUT to 500. NETBIOSTIMEOUT specifies how long LS will wait to send the next request to identify a NETBIOS duplicate name. Changing the timeout value to 500ms will improve startup time by 6 seconds and logon by 12 seconds (if previously set to 2000). Formula: NETBIOSTIMEOUT x NETBIOSRETRIES = LR start time. Double this result for the logon improvement since userid and userid/domain name each have to be registered in the NETBIOS Names table.
• Set RECVBUFSIZE to 256. A smaller buffer size will take better advantage of any unused portion of the 64KB NETBIOS segment.

The following recommendations are for running OS/2 NetWare Requester.

• To improve performance, copy frequently used NetWare utilities to the NetWare Requester. For example: copy LOGON.EXE, LOGOUT.EXE, MAP.EXE and SLIST.EXE.
• The following is a sample NET.CFG. Use this configuration when you first attempt to use the NetWare requester over LAN Distance. Use the buffer size of 1514 for a token-ring environment (not 4202).

• For a token-ring environment, LAN Distance requires that all frames have source routing information. This means that ROUTE.NLM must be loaded on the NetWare server and ROUTE.SYS must be loaded for the NetWare requester.
• The NetWare requester must have a fix for NWREQ.SYS. The fix must be 7/21/94 or later. This fix can only be installed on the OS/2 NetWare Requester.
• The NetWare requester for OS/2 has a fixed timeout value for resending frames when there has been no response from the server. Over a slow link, this can cause frames to be retransmitted several times causing slow performance and REQ1040 and REQ1039 error messages from NetWare.
• NWREQ.EXE contains the 7/21/94 NWREQ.SYS fix from Novell which increases the timeout value. There is a side effect of this fix. When the LAN Distance connection is dropped, it will take several minutes for NetWare to destroy the default drive due to the longer timeout value. You may notice this when you are trying to shut down OS/2.
• Make sure the NetWare client for OS/2 is version 2.1 or later. Otherwise, NWDAEMON must be executed after the LAN Distance connection has been established by issuing:

• When using packet burst for the DOS NetWare client, the latest VLM.EXE is required. VLM.EXE must be dated 5/31/94 or later. VLM11.EXE contains the 5/31/94 fix.
• Make sure that DOSUP9 and WINUP9 (or later) fixes have been applied for the NetWare client.
• In order to enable LAN Distance for NetWare during LAN Distance installation or through settings, LSL.COM and VLM.EXE must be in the NetWare directory. LAN Distance requires the use of VLM.EXE.
• When you run NetWare and LAN Distance in a Windows environment and you exit Windows, the machine may lock up. This has been fixed by the NetWare APAR IC07995.
• Novell DOS Requester running LAN Distance and Windows will lock up after exiting Windows. VIPX.386 version 1.19 has the corrections needed.
• An important factor in network performance is the efficiency of the network. The size of the data packet being transmitted between the client and the server has a significant impact on performance. The larger the packet size, the faster the response time. An optimized network configuration ensures that the packet size of the client matches that of all the servers it intends to connect with (and any gateways or routers in between). Currently, the client workstations are configured to transmit data packets of 1514 bytes. The domain controller/file servers are configured to transmit and receive data packets of 4224 bytes. All the network gateways and routers should be checked to determine the maximum data packet size they can independently support. Once this value is determined, the maximum common data packet size that can be supported on the gateways, client workstations, and servers should be implemented across all systems
• Set the Token Ring adapter's shared RAM size to 16KB. This improves performance by optimizing the throughput of the adapter.

The TCP/IP Version 4.0 shipped with OS/2 Warp 4 has many new features:

• Dynamic IP client supports the Dynamic Host Configuration Protocol (DHCP) which dynamically allocates and reuses IP addresses, and Dynamic Name Service (DDNS) which dynamically resolves IP addresses to IP hosts.
• Socks security which permits TCP/IP applications to access the Internet through many standard firewalls.
• WinSock 1.1 Open32 Support enables WinSock 1.1 to be used in conjunction with Open32 for the porting of Windows TCP/IP applications.
• Variable subnet routing.
• IP alias support enables OS/2 Warp 4 to support several web servers on a single system.
• Multicast allows packets to be transmitted to multiple users.

Note: File transfers of 2048 (2KB) or greater would benefit by increasing the MTU size. The default of 1500 bytes does not efficiently use the available network bandwidth (unless the network is Ethernet, in which case 1500 is the maximum size). If most of your file transfers are smaller than 2KB, then the default MTU size of 1500 is recommended. The MTU size can be changed from the TCP/IP Configuration object. Please see the procedure for changing the MTU size discussed in the MPTS section.

Tuning database software can make a tremendous impact on response time when retrieving information from a client workstation. Without being familiar with the relational database system being used, specific recommendations cannot be made. The following comments are based on knowledge of IBM's relational database systems.

• When querying large amounts of data, verify the data is being transferred in blocks rather than row by row, assuming the system allows for row blocking. Note that although the network can be tuned for a certain data packet size, the database application may or may not be configured to use it.
• Verify that your queries are accessing the database via an index, where applicable. The database administrators should have a tool to provide this information.
• If database access is heavy, there may be performance problems associated with table, page, or row locking. Again, the administrators should have tools to determine if excessive locking or lock escalation is occurring. If so, it is possible that a different isolation level could be used that would permit greater concurrency.
• Database tuning is very system-specific, but there are other tuning parameters, such as buffers, that can be tuned as well. If client queries are slow, it is recommend that the server be tuned and optimized for improved queries response.

Starting the Notes Client application takes at least 3MB of RAM. Each time a document is opened at the client workstation, the document has to be transferred from the Notes Server (hence network optimization is very important) to the client's RAM. The document is contained in RAM until it is closed. Tune the client-to-server packet size to ensure the maximum packet size is being transmitted. Also, close all documents after using them.

Redefine the Lotus Notes client hardware port to increase the amount of memory allocated to transfer data across the network. The default is 2000 bytes. Increase this value to 4000 or 6000. Increasing this value may or may not improve the efficiency of data transfer. Therefore it becomes important to measure response time before and after changing this value.

Remove the TIMESLICE statement in the CONFIG.SYS file of OS/2 Warp systems. The Lotus Notes 3.0 installation program often places this statement in the CONFIG.SYS file. The default value of DYNAMIC offers the best performance.

If you feel comfortable with OS/2 Warp 4 internal operations, you can make the following changes to the CONFIG.SYS file to make it leaner and less memory demand. This section was designed as a pullout section.

• Re-order the LIBPATH, PATH, and DPATH parameters. Directory names should be placed in the order of usage. The most accessed directory should be listed first and the least accessed listed last.
• There are two other environmental variables that the system uses when an application is looking for a DLL (dynamic link library). They are:
• SET BEGINLIBPATH=path
• SET ENDLIBPATH=path

• Relocate the SWAP file to the root directory of the most used partition and set it's initial size to a value slightly larger than it typically grows. This makes it large enough so that it does not have to grow in size while running applications. In systems using the FAT file system, this technique also minimizes fragmentation of the SWAP file on the hard drive. If more than one physical disk drive is present, relocate the SWAP file to the least used drive and place it in the root directory of the most used partition.
• Initial Swapper File Size. Change the third parameter (second number) to 20480 or 30920 so the swapper starts out at 20 or 30 MB. This is especially important on a FAT partition, since FAT has a tendency to fragment files that impact performance when the swapper file fragments. As a result, at startup, OS/2 will find a contiguous 20 MB area and reuses it each time. You can also use the following rule of thumb: "initial swap file size = total physical memory size + 8MB."

• Ensure DOS=LOW,NOUMB. If a DOS application needs DOS to be loaded high or device drivers to be loaded in upper memory, they should be set from that applications settings notebook. Setting them in the CONFIG.SYS file forces them to be set for all DOS applications whether they need it or not.

• Set BUFFERS greater than or equal to 60 if using FAT, otherwise set to 30. Buffers are physical memory used to support partial sector reads and writes in a FAT file system environment. They are also used to cache FAT directory entries and for swap file disk I/O. Because they are used to cache FAT directory entries, they should not be reduced below 60, unless you are not using the FAT file system on any of your disks. Reducing this number will increase the number of disk reads that are done to the FAT directory entries and therefore slow down your system.

• MAXWAIT=3. This statement specifies the number of seconds a task must wait before getting a priority boos. If your system is under a heavy load, a program may have to wait for execution time. Receiving a priority boost will put a program ahead of others that are also waiting for the processor. Decreasing this number will help programs get execution time faster, but the overall performance may suffer. Increasing this number will allow the OS/2 Scheduler to resolve requests for system time based on the true priority of the programs.

• Set PRIORITY_DISK_IO=YES This allows the application that has screen focus to receive a priority boost when it's disk operation is complete. This applies to the first time slice given to the thread after the disk operation is complete. After the time slice, the state is reset for the thread and the priority boost removed.

• TIMESLICE=X,Y This statement is not found in the CONFIG.SYS file after you install OS/2 but is sometimes recommended to be added. This was allright to add for OS/2 2.0, 2.1 or 2.11 systems, but not for OS/2 Warp. In OS/2 Warp, we dynamically modify a threads time slice based on actions that have occurred. For instance, if a thread took a page fault during it's time slice, we give it an extra time slice to process what is contained in the faulted page. We also give applications doing disk I/O extra time slices if the data they are reading is in the disk cache. When the TIMESLICE= parameter is used, none of these actions will occur. Instead, each thread will be given the minimum time slice of X, and its time slice will not be allowed to go beyond value Y.

• Add SET RESTARTOBJECTS=STARTUPFOLDERSONLY after the SET AUTOSTART statement. This eliminates numerous boot problems caused by misbehaved programs that won't close. Otherwise OS/2 starts them again. This action also decreases swapping when the system is first booted up.

• To reduce memory and CPU usage, change the SET AUTOREFRESHFOLDERS statement to NO. When SET AUTOREFRESHFOLDERS=NO, the system will not automatically update changes you make to the folders and objects in OS/2. For example, if you delete an object from a folder after you make this change, you will have to either close the folder and reopen it or select View and then Refresh Now from the pop-up menu to observe the changes you have made. This change is recommended for computers that are used as servers not as workstations.

• SET PM_ASYNC_FOCUS_CHANGE=ON in the CONFIG.SYS file to fix the single input queue problem. The OS/2 solution detects misbehaved applications that cause system hangs in what is often incorrectly attributed to OS/2 as the Single Input Queue (SIQ) problem. The fix is implemented at the system level as a separate OS/2 thread that monitors the status of the input queue. No modifications of applications are necessary.

• Optimize the DISKCACHE statement on systems using the FAT file system or REMark it out if the system does not use the FAT file system. Disk caching allows a certain amount of (RAM) memory to serve as a cache for disk I/O. A cache improves performance when a particular disk file is accessed frequently. Keeping it in memory will avoid real I/O and thereby improve I/O response time when accessing that file. In memory-constrained systems, the recommendation is to decrease caching. This is not obvious but the rationale is that the benefit of using memory for disk caching is lower than the benefit of having the memory available for other processes when they are referenced. Experimenting with various DISKCACHE settings to achieve the best performance is the most effective way to determine the correct value.

• Optimize the DISKCACHE Threshold value. It is recommended that the threshold be set at 32 unless the software product you are using is disk intensive and the manufacturer supplies information on the block size required. Otherwise, experiment with different threshold values and monitor the DISKCACHE utilization with SPM/2 to achieve the most effective value.

• Enable LAZYWRITE (LW) whenever possible. This allows disk writes to be temporarily held in memory to increase throughput. Without LW, disk writes are done immediately. LW will increase disk performance, but an unexpected power outage may cause data loss.

• Optimize the HPFS CACHE setting on systems using the HPFS file system or REMark it out if the system does not use this file system. Optimize the CRECL value by experimenting with different threshold values while monitoring the HPFS cache utilization with SPM/2. This will ensure the optimum value is determined.
• REMark the HPFS statement. This system does not use the HPFS file system. The HPFS code and data space requirement is 200KB of memory plus the cache requirement (minimum cache size is 64KB). Removing this statement will save at least 264KB and as much as 2312KB.

• Set THREADS to a value 50% larger than the actual number of threads expected to be used. Threads consume resident memory so determining the optimum value for this parameter will affect the amount of memory that is available for applications to use.
• One page of resident memory is need for approximately every 32 threads that are defined. As a minimum, you will need 80 threads to support the base OS/2 Warp system and 3 or 4 OS/2, DOS and or Windows applications. The system will support up to 64000 threads, but typically you will not have enough memory in your system to support more than 300 to 500 threads. 18 threads are required for LAN Server 4.0, and 12 for Personal Communications/3270. You will need an additional 2 threads for each Personal Communications/3270 session that is started. To calculate the number of threads that you will need in your system, use the formula 54+(2xN)+10 where N is the number of programs that you will run together. If the program requires more than 2 threads, add in the additional threads.

• Remove any VDISK parameters. A VDISK is a virtual disk made in the computers physical memory to provide quick access to often-used files and programs. These systems don't have enough memory to support using a VDISK.

• Ensure PRIORITY=DYNAMIC. This allows OS/2 to adjust thread priorities based on its display status (foreground or background), recent input and output activity, and frequency of processor use. DYNAMIC allows this calculation of priorities to support a system boost for foreground applications. This is the default. ABSOLUTE performs no calculation. There is no system-applied boost for foreground applications when this parameter is specified.

• REMark the COM and VCOM device driver statements. These statements load support for serial ports. These drivers should only be removed if there are no immediate intentions to use such devices in this system.

• REMark the CDROM and VCDROM device driver statements. These statements load support for CD ROM devices. These drivers should only be removed if there are no immediate intentions to use such devices in this system.

• REMark the PCMCIA device driver statements. This statement provides support for PCMCIA devices. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=IBM2FLPY.ADD device driver statement. This driver supports diskette drives on microchannel computers. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=IBM1FLPY.ADD device driver statement. This driver supports diskette drives on non-microchannel computers. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=IBM1S506.ADD device driver statement. This driver supports MFM, RLL, and IDE disk controllers. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=IBM2ADSK.ADD device driver statement. This driver supports ABIOS-based disk devices. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=IBM2SCSI.ADD device driver statement. This driver supports SCSI controllers on microchannel computers. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=OS2SCSI.DMD device driver statement. This is the SCSI device driver manager. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the BASEDEV=PRINT01.SYS statement. This statement supports printer ports on non-microchannel computers.

• REMark the BASEDEV=PRINT02.SYS statement. This statement supports printer ports on microchannel computers.

• Your system uses the IBMINT13.I13 driver, which causes your system performance to suffer. (RMVIEW /IRQ shows one of the IRQ levels being controlled by IBT13BIOS Int 13 BIOS Support. If you have an IDE hard drive, make sure the statement BASEDEV=IBM1S506.ADD is in the CONFIG.SYS. Adding it should change the IRQ owner to ST506 / IDE Controller. If it does not, you may need a third party device driver to get a performance improvement.

• REMark the APM.SYS and VAPM.SYS statement. This statement supports Advanced Power Management (APM) but your computer doesn't use this feature.

• REMark the EGA.SYS statement. This statement loads support for DOS applications that use EGA display registers. You only need this driver if you use DOS graphics programs that expect EGA compatibility.

• REMark the EXTDISKDD.SYS statement. This statement allows access to external floppy disks using a logical drive letter. This driver should only be removed if there are no immediate intentions to use such a device in this system.

• REMark the TOUCH.SYS statement. This statement loads a device driver that provides support for touch screen displays.

• Change the DEVICE=\OS2\MDOS\VEMM.SYS statement to VEMM.SYS 0. This statement loads a driver that provides Expanded Memory Support (EMS) for DOS sessions. Adding a 0 variable causes OS/2 to not allocate EMS to a DOS session unless you override the setting in that session's DOS Settings. Most programs do not require EMS, so disabling EMS by default will save RAM.

• Change the DEVICE=\OS2\MDOS\VXMS.SYS statement to DEVICE =\OS2\MDOS\VXMS.SYS /XMMLIMIT=4096,0 /UMB. This will allocate a maximum of 4MB of SMS for the entire system, but it will not give any XMS memory to a DOS session unless you override the setting in an individual sessions's DOS Settings. DOS sessions won't get XMS by default, which will save memory (since most DOS programs can run without XMS). If you replace /UMB with /NOUMB, no DOS session will be able to use upper memory blocks. If you want DOS=HIGH to be the default, use /XMMLIMIT=4096,64 /UMB instead. Each session will need at least 64KB of XMS.

• Change BREAK=ON to OFF. This statement instructs DOS sessions to check for Ctrl+Break key presses. If set to ON, Control-Break checking is more frequent, but DOS programs may run slower.

• Change FCBS=16,8 to 4,4. This statement allows you to allocate File Control Blocks (FCBs) for DOS sessions. Most new DOS programs do not use FCB's so these values can be lowered to save RAM.