═══ 1. Notices ═══ o First Edition (September, 1992). (Patrick M. Schoeller) o Revised: 2.0 (June, 1993) - Changed the Format and updated for the OS/2 2.1. release. Added information for INTEL SatisFAXtion/400 and ACDI communications. (Patrick M. Schoeller). o Revised: 2.1 (August, 1993) - Added PCMCIA and Serial Printing material. Improved Trouble Shooting section. (Patrick M. Schoeller). o Revised: 2.2 (September, 1993) - Added APAR listing and more applications. Added more information about serial printing. (Patrick M. Schoeller) o Revised: 2.3 (October, 1993) - Updated PCMCIA information and Specific Applications. (Patrick M. Schoeller) The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "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 disclaimer 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 publication at any time. It is possible that this publication may contain reference to, or information about, IBM products (machines and programs), programming, 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, programming, or services in your country. Requests for technical information about IBM products should be made to your IBM Authorized Dealer or your IBM Marketing Representative. 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 protected 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 designated 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 Commercial Relations, IBM Corporation, Purchase, NY 10577. ═══ 1.1. TRADEMARKS AND SERVICE MARKS ═══ Terms denoted by a single asterisk (*) in this publication are trademarks of the IBM Corporation in the United States and/or other countries. These terms include: IBM Micro Channel Operating System/2 OS/2 PS/2 WIN-OS/2 Workplace Shell XGA Terms denoted by a double asterisk (* *) in this publication are trademarks of other companies. Other trademarks appearing in this publication are owned by their respective companies. Microsoft, MS Bookshelf, MS Excel, MS Flight Simulator, MS Money, and Windows are trademarks of Microsoft Corporation. IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESSED OR IMPLIED, INCLUDING WITHOUT LIMITATION, WARRANTIES OF FITNESS AND MERCHANTABILITY WITH RESPECT TO THE INFORMATION IN THIS DOCUMENT. BY FURNISHING THIS DOCUMENT, IBM GRANTS NO LICENSES TO ANY RELATED PATENTS OR COPYRIGHTS. Copyright IBM Corporation, 1993, all rights reserved. ═══ 1.2. HOW TO BEST USE THIS GUIDE ═══ This guide to analyzing serial communication problems was designed using the OS/2 2.x Information Presentation Facility (IPF). Documentation created with IPF has an INF suffix and can be examined using the OS/2 VIEW command. The online help is created with this facility. The hard copy version is created using the same master IPF document with some additional SCRIPT commands and is then submitted to BOOKMASTER, an IBM VM (mainframe) application. This guide's primary purpose is to assist support personnel in analyzing serial communication problems under the OS/2 2.x operating system. The educational material is located towards the beginning and the support material is towards the end of the guide. This guide is not intended to be read as a book from cover to cover; rather this guide is much like a medical encyclopedia where you list the symptoms of the problem and try to find the closest match. For those users who have the printed version of this guide, There are many cross references so that you can quickly refer to another section of the document and return to where you are reading. Since the table of contents is very detailed, there is no index. For those users who have the online version of this guide (COM.INF), we recommend that you copy the COM.INF file to the \OS2\BOOK directory. You can then create a copy of the "Command Reference" which is located in the Information Folder on the OS/2 desktop. You will need to change the "Parameters" field from CMDREF.INF to COM.INF You will also need to change the title to something meaningful. The most efficient way to utilize this guide is the use the SEARCH facility of the VIEW command (i.e. the object you created in the previous paragraph). For example, say you get an "out of memory" error when starting a DOS program. You could do a search on MEMORY (select ALL SECTIONS) and this would list all topics which have the word MEMORY listed. You will find that every item in the table of contents (TOC) has some information. The easiest way to read a section is to double click on the main TOC item and use the FORWARD and BACKWARD buttons. If you are referred to another section, you can return to your previous position by selecting the PREVIOUS button. You may have to make multiple selections of the PREVIOUS button if you use the FORWARD and BACKWARD buttons. ═══ 2. INDUSTRY STANDARD (AT BUS) ARCHITECTURE OVERVIEW ═══ The original Industry Standard Architecture (ISA) machine (the IBM PC-AT) allowed for the definition of up to four serial communications ports. However, there has never been any hardware architectural standard that defined the I/O port addresses or Interrupt Request (IRQ) lines associated with serial ports #3 or #4. Over the years a convention was established which places the port addresses for COM3 and COM4 at 03E8 and 02E8 respectively. This is a generally accepted convention and is not a standard. If multiple hardware adapters of any kind (not just communications) are using the same I/O address, then the effect on your computer will be totally unpredictable. OS/2 2.x is an interrupt driven operating system and requires unique I/O addresses and Interrupt Request lines (IRQs) for each adapter in the system on an ISA computer system. ISA systems have what are called "edge triggered" interrupts in contrast to Micro Channel (MCA) and EISA which use "level sensitive" interrupts. Edge triggered interrupts can only be sensed for a very short period of time. If a second interrupt arrives from another adapter while the first interrupt is still being processed, then the second interrupt will be lost. Also, if two adapters are sharing the same PHYSICAL IRQ then the processor does not know which adapter (and therefore which OS/2 session) should get the Interrupt Request (IRQ). In a single tasking operating system such as DOS, the sharing of interrupts is not a problem as only one application is in use at a time. OS/2, however, presents a different set of problems. If we have two, three, or four serial communications adapters, the probability is now pretty high that we might try to use two or more of them at the same time. If some of them have previously been set up using shared interrupts, then the stage is set for mysterious things to happen that probably didn't happen under DOS. ═══ 2.1. ISA BUS ARCHITECTURE ═══ On an ISA machine there are a total of 15 IRQ levels available. These interrupts are determined by the two INTEL 8259a (or compatible) Programmable Interrupt Controllers (PIC). Each PIC is capable of handling 8 Interrupt ReQuest lines (IRQ) but IRQ2 of the first pic is cascaded (or linked) to IRQ9 of the second PIC. Any adapter which is physically configured (or "jumpered") to IRQ2 will recognized by OS/2 as IRQ9. This is defined by the hardware and not the OS/2 operating system. The standard settings, in order of priority, follow: ┌──────┬────────────────────────────────────────────────────────────────┐ │IRQ# │Device Associated │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 0 │System Timer │ ├──────┼────────────────────────────────────────────────────────────────┤ │1 │Keyboard │ ├──────┼────────────────────────────────────────────────────────────────┤ │2 │Secondary Interrupt Controller (see note) │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 8 │Realtime Clock │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 9 │--- (see note) │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 10 │--- free │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 11 │--- free │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 12 │--- free - reserved for aux dev │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 13 │Math Coprocessor │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 14 │Hard Disk │ ├──────┼────────────────────────────────────────────────────────────────┤ │ 15 │--- free │ ├──────┼────────────────────────────────────────────────────────────────┤ │3 │COM2 (Serial Communications Port #2) │ ├──────┼────────────────────────────────────────────────────────────────┤ │4 │COM1 (Serial Communications Port #1) │ ├──────┼────────────────────────────────────────────────────────────────┤ │5 │LPT2 (Parallel Printer Port #2 - add. 278) │ ├──────┼────────────────────────────────────────────────────────────────┤ │6 │Diskette │ ├──────┼────────────────────────────────────────────────────────────────┤ │7 │LPT1 (Parallel Printer Port #1 - add. 3BC or 378) │ └──────┴────────────────────────────────────────────────────────────────┘ Note: On the IBM-AT (ISA bus) the IRQ9 pin is identical with the IRQ2 pin on the original IBM-PC. If you have an older, 8-bit adapter whose documentation states that it uses IRQ2, then be aware that this will actually be seen as IRQ9 when plugged into the 16-bit ISA bus. OS/2 can detect that an interrupt line is shared and will disallow the simultaneous use. Assume that COM1 and COM3 were sharing IRQ4 (a fairly common real situation). If we tried to use both COM ports at the same time, OS/2 would refuse to allow the second one to start. A well-written OS/2 communications program would see and report the error from OS/2 that the port could not be opened. A DOS application, however, will likely be unprepared to respond to this strange situation, and may simply hang, waiting for the port that will never open. To avoid these problems, make sure that all of your hardware adapters have their own unique I/O addresses and IRQ assignments. Unfortunately, on an ISA machine, OS/2 has no way to query the computer to find out what these settings are. Therefore, after checking and setting the adapters according to the instruction manuals, you must also tell OS/2 what you've done by placing explicit information into the CONFIG.SYS file. ═══ 2.2. ISA INTERRUPT REQUEST LEVELS AND I/O ADDRESSES ═══ The Industry Standard Architecture (ISA) computers use EDGE triggered interrupts (versus LEVEL triggered interrupts used in Microchannel Architecture (MCA) computers). OS/2 2.x only supports interrupt sharing on MCA computers. The reason that interrupt sharing is not supported on ISA computers is a limitation of the ISA architecture (edge triggered interrupts) and performance. Every adapter in an ISA computer must have a unique IRQ which is PHYSICALLY defined by hardware jumpers or logically defined by software supplied by the vendor of the adapter. The adapter and not OS/2 determines the IRQ settings. The same can be said for I/O addresses. ═══ 2.2.1. DETERMINING IRQS FOR ISA COMPUTERS ═══ o On an ISA computer, the only reliable way to verify the IRQ settings for every adapter is to manually inventory each adapter. You usually do not have to worry about the parallel ports, the disk drives or the Math Coprocessor (if one is installed). There are some utilities available for DOS which may be able to indicate if you have an IRQ conflict. o If your set an ISA adapter to IRQ2, this adapter will be known to OS/2 as IRQ9. The reason for this is there are two INTEL 8259a (or compatible) Programmable Interrupt Controllers (PICS) in the ISA bus architecture. Each PIC can handle eight (8) interrupts. IRQ2 which is located on the master PIC cascades to IRQ9 of the slave PIC. This is a function of the hardware and not the OS/2 operating system. ═══ 2.2.2. DETERMINING I/O ADDRESSES ═══ There is a technique available for determining which Input/Output (I/O) addresses are in use by the serial communication adapters which are identified by COMx. For other types of adapters, you will have to manually inventory each adapter. You usually do not have to worry about the parallel ports, the disk drives or the Math Coprocessor if one is installed. The technique to determine which I/O addresses are in use is detailed below: 1. Start a DOS Full Screen Session (command prompt). 2. Enter DEBUG and press the enter key. 3. At the '-' prompt, enter D 40:0 and press the enter key. 4. You will see 0040:0000 followed by pairs of hexadecimal numbers. These numbers are the I/O addresses recognized by COM.SYS. Below is an example of COM1 and COM2: 0040:0000 F8 03 F8 02 00 00 00 00-BC 03.... This represents 03f8 (COM1) and 02f8 (COM2). If COM3 was present, it would follow COM2's address. NOTE 1 If the above procedure shows "E8 02" in COM3's address position, there is NOT a serial communication adapter defined as COM3 and there is a serial communication adapter defined as COM4, see the following section and MISCELLANEOUS ERRORS NOTE 2 If COM1 or COM2 slots are equal to zero (00 00) AND you have a serial mouse plugged into the port in question, this is normal. The MOUSE.SYS driver enters zeros for the port it owns so that other drivers (i.e. COM.SYS) do not interfere with the port. 5. Enter Q and press the enter key to leave DEBUG. The following section shows various location 40:0 scenarios. ═══ 2.2.2.1. LOCATION 40:0 SCENARIOS ═══ This section gives the user some common scenarios to look for when debugging location 40:0. Note that a serial device could be an external serial (COM) port, internal modem or some other specialized serial device. Also note that DEBUG can be run in NATIVE DOS to confirm posting of port addresses to location 40:0. Note: The CONFIG.SYS line shown in the examples is what you would expect the customer to have set so that the DEBUG 40:0 matches. These examples are not always valid and are noted in each individual case. 1. 0040:0000 F8 03 F8 02 20 32 28 32-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS MCA class computer with 4 serial devices: COM1(3f8), COM2(2f8), COM3(3220), COM4(3228). This is a VALID CONFIG.SYS line. 2. 0040:0000 F8 03 F8 02 E8 03 E8 02-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS (3,3e8,ii) (4,2e8,ii) WHERE 'ii' is equal to the PHYSICAL IRQ level set on the serial device. ISA class computer with 4 serial devices: COM1(3f8), COM2(2f8), COM3(3e8), COM4(2e8) - Either no MOUSE or a BUS MOUSE. Very likely has IRQ conflicts with either the MOUSE or between the serial devices. Another possibility is a malfunctioning MOUSE or the MOUSE.SYS statement is following the COM.SYS statement in the CONFIG.SYS file. The MOUSE.SYS statement should always precede the COM.SYS statement in the CONFIG.SYS file. This is a VALID CONFIG.SYS line provided the IRQs match the physical IRQ of the serial devices. 3. 0040:0000 00 00 F8 02 00 00 00 00-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS ISA or MCA class computer with two serial devices - MOUSE is on COM1. 4. 0040:0000 F8 03 00 00 E8 03 00 00-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS (3,3e8,ii) WHERE 'ii' is equal to the PHYSICAL IRQ level set on the serial device. ISA class computer with three serial devices - MOUSE is on COM2. This is a VALID CONFIG.SYS line. 5. 0040:0000 F8 02 E8 03 00 00 00 00-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS (3,3e8,ii) WHERE 'ii' is equal to the PHYSICAL IRQ level set on the serial device. ISA class computer with two or three serial devices - Either no MOUSE or BUS MOUSE. Warning: This configuration is very suspicious and will probably not work as 2f8 is the wrong address for the slot. Definitely want to check the PHYSICAL configuration of the serial adapter. In this instance, check to see that COM1 is enabled on the adapter. If the adapter is configured correctly, there may be a hardware problem. The CONFIG.SYS line is valid but there is a suspected hardware error. 6. 0040:0000 F8 03 F8 02 E8 02 00 00-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS (4,2e8,ii) WHERE 'ii' is equal to the PHYSICAL IRQ level set on the serial device. ISA class computer with three serial devices - either no MOUSE or BUS MOUSE. Note: The third device is configured for what is usually assigned to COM4(2e8). OS/2 is going to want to treat this as COM3, I/O address 2e8 and what ever IRQ is assigned. This situation usually causes an error (i.e TRAP 000e, IPE, etc.). Please review MISCELLANEOUS ERRORS for more information. This is currently NOT a valid CONFIG.SYS line due to a defect in the Serial Device Driver (COM.SYS). 7. 0040:0000 E8 02 F8 02 E8 02 00 00-BC 03.... CONFIG.SYS: ..\OS2\COM.SYS (4,2e8,ii) WHERE 'ii' is equal to the PHYSICAL IRQ level set on the serial device. ISA class computer with three serial devices - MOUSE is on COM1. Note: The COM.SYS device driver has taken the (4,2e8,ii) parameter passed and incorrectly placed the I/O address in slot one which was set to zero by the MOUSE.SYS device driver. This situation always causes an error. Please review MISCELLANEOUS ERRORS for more information. This is currently NOT a valid CONFIG.SYS line due to a defect in the Serial Device Driver (COM.SYS). ═══ 2.3. ISA, OS/2 AND PARALLEL PORTS ═══ The printer port addresses and IRQ levels are hard coded in OS/2 as follows: ┌───────────────┬───────────────┬───────────────────────────────────┐ │PORT │I/O ADDRESS │IRQ │ ├───────────────┼───────────────┼───────────────────────────────────┤ │LPT1 │3BC or 378 │IRQ7 │ ├───────────────┼───────────────┼───────────────────────────────────┤ │LPT2 │278 │IRQ5 │ └───────────────┴───────────────┴───────────────────────────────────┘ Unlike the COM ports, where the addresses and the interrupts can be specified by parameters to the COM.SYS in the CONFIG.SYS file, the printer port addresses and IRQs shown above are fixed. OS/2 assigns LPT1 to the highest printer port address being used. The printer address is specified in the printer adapter board. With OS/2 you can not use both addresses 3BC and 378 as printer port addresses. Both parallel ports (LPTs) would be sharing IRQ7. Unlike DOS, OS/2 uses interrupts for printing. The interrupt is triggered by the signal line, ACK, from the printer. If the IRQs are not configured correctly or if the printer cable is missing the ACK line, the printer may work under DOS and have problems under OS/2. ═══ 2.4. ISA AND OS/2 SUMMARY: ═══ Even though there is some flexibility for printer and COM port assignments, try to stick to the standard assignment as shown in the IRQ table above. The I/O addresses and IRQs are determined by the HARDWARE. The parameters passed to COM.SYS DO NOT change the hardware; these parameters are a reflection of the physical hardware settings. Available interrupts, in order of priority, are: IRQ9, IRQ10, IRQ11, IRQ12, IRQ15, IRQ3 (if not used for COM2), and IRQ5 (if not used for LPT2). Physical addresses and interrupts can be indicated in OS/2 to the communication drivers. Usual default settings follow: o COM1 - 03f8 - IRQ 4 (OS/2 & industry default) o COM2 - 02F8 - IRQ 3 (OS/2 & industry default) o COM3 - 03E8 - (industry practice) o COM4 - 02E8 - (industry practice) There is no OS/2 default setting for COM3 and COM4. It must be specified by the device=x:\OS2\COM.SYS statement (where x: is the installed drive) in the config.sys file. An example of address and interrupt assignments follows: o COM1 - 03F8,IRQ4 o COM2 - 02F8,IRQ3 o COM3 - 03E8,IRQ5 (IRQ5 not being used by LPT2) o COM4 - 02E8,IRQ10 (would require a 16 bit adapter) o LPT1 - 378,IRQ7 If interrupt devices are occasionally losing data, try moving to a higher priority unused interrupt. ═══ 2.5. NOTES ON MICROCHANNEL ARCHITECTURE MACHINES ═══ OS/2 2.x requires no extra configuration for Microchannel Architecture (MCA) computers. MCA computers have the ability to share interrupts although for best performance, you should try to limit the number of devices sharing IRQ4 and IRQ3 which are used for COM1, COM2 and COM3. On a MCA machine, COM1 is defined as IRQ4, I/O address 3f8, COM2 is defined as IRQ3, I/O address 2f8, COM3 is defined as IRQ3, I/O address 3220 and COM4 is defined as IRQ3, I/O address 3228. ═══ 3. OS/2 2.x COMMUNICATION DRIVERS ═══ There have been many enhancements to the serial communication drivers in OS/2 2.x. These enhancements have been made based on testing and customer feedback. With the introduction of OS/2 2.1 and any later Service Pack (CSD), there are three major versions of the serial communication drivers available: OS/2 2.0, OS/2 2.0 + SP (XR06055) and OS/2 2.1. The OS/2 2.1 drivers cannot be used with OS/2 2.0 and system level XR06055. The major differences between the various drivers are the DOS Settings available, the command line parameters to the COM.SYS driver and performance enhancements. A description of the OS/2 2.x serial communication drivers follows: ┌─────────┬─────────────────────────────────────────────────────────────┐ │COM.SYS │The COM.SYS driver is the main OS/2 2.x communications │ │ │driver. This file is located in the \OS2 directory. COM.SYS│ │ │processes all passed parameters. COM.SYS should be located │ │ │towards the end of the CONFIG.SYS after all other serial │ │ │device drivers (i.e. MOUSE.SYS). │ ├─────────┼─────────────────────────────────────────────────────────────┤ │VCOM.SYS │The VCOM.SYS driver is used in every Virtual Dos Machine │ │ │(VDM) and Virtual Machine Boot (VMB). This file is located │ │ │in the \OS2\MDOS directory. The purpose of the VCOM.SYS is │ │ │to virtualize all serial interfaces to DOS applications. │ │ │There are no parameters passed. VCOM.SYS should always │ │ │follow COM.SYS in the CONFIG.SYS file. │ ├─────────┼─────────────────────────────────────────────────────────────┤ │COMM.DRV │The COMM.DRV is used in WIN-OS2 sessions. This file is │ │ │located in the \OS2\MDOS\WINOS2\SYSTEM directory. There are │ │ │no parameters passed. COMM.DRV is NOT in the CONFIG.SYS │ │ │file. │ └─────────┴─────────────────────────────────────────────────────────────┘ ═══ 3.1. OS/2 2.0 GA (XR02000) DRIVER PARAMETERS ═══ These settings are for those customers who are at SYSLEVEL XR02000 and have ISA machines and wish to use COM3, COM4, or non- standard I/O addresses must modify the config.sys file to include the following parameters for the COM.SYS driver. DEVICE=C:\OS2\COM.SYS (n,a,i) [(n,a,i)] . . where the last parameter is optional n = the Com port a = COM port I/O address (e.g. 03E8, 02E8) i = IRQ level For example, to specify that COM3 is at address 03E8 on IRQ5 and that COM4 is at address 02E8 on IRQ10, use the following statement (assuming that OS/2 is installed on the C: drive): DEVICE=C:\OS2\COM.SYS (3,3E8,5) (4,2E8,10) Note that this syntax is actually quite general. Non-standard parameters for COM1 and COM2 are set the same way. The I/O address and IRQ level should be noted in the documentation that came with the adapter. Either or both might be fixed values or adjustable to a range of values via jumpers or switches. In some cases, you may find that the values are fixed or that the range of settings available to you is insufficient to avoid the sharing conflict. See VCOM.SYS DOS SETTINGS AVAILABILITY TABLE for settings you can adjust. ═══ 3.2. OS/2 2.0 SERVICE PACK (XR06055) DRIVERS ═══ Those customers who have ISA machines and wish to use COM3, COM4 or non- standard I/O addresses must modify the config.sys file to include the following parameters for the COM.SYS driver. You may also wish to use the new parameter for spurious interrupts on MCA or ISA machines. You will have to specify each COM port with it's IRQ and I/O address. DEVICE=C:\OS2\COM.SYS (n,xxxx,ii,s) [(n,xxxx,ii,s)]... where the last parameter is optional. ┌──────┬──────┬──────────────────────────────────────────────────────┐ │OPTION│VALUES│DESCRIPTION │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │n │1 - 4 │Serial port number (usually 3 and 4 but it is possible│ │ │ │to configure 1 or 2 to a different IRQ or I/O │ │ │ │address). │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │xxxx │03f8, │Any valid serial port address. Those shown are the │ │ │02f8, │addresses which are normally used. The port address │ │ │03e8, │must be valid or the results are unpredictable. │ │ │0438, │ │ │ │3220, │ │ │ │3228 │ │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │ii │3, 4, │Physical IRQ level of the serial port. IRQ sharing is│ │ │5, 9, │not permitted on ISA computers. The interrupt must be│ │ │10, │valid or the results are unpredictable. │ │ │11, 15│ │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │s │ │Spurious Interrupt switch. Some UART chips or │ │ │ │malfunctioning modems can create interrupts when no │ │ │ │interrupt is expected. These interrupts are known as │ │ │ │spurious interrupts. │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │ │d, D │This instructs the COM driver to deinstall if more │ │ │ │than 1000 consecutive spurious interrupts occur. │ │ │ │(DEFAULT) │ ├──────┼──────┼──────────────────────────────────────────────────────┤ │ │i, I │This instructs the COM driver to ignore spurious │ │ │ │interrupts. │ └──────┴──────┴──────────────────────────────────────────────────────┘ See VCOM.SYS DOS SETTINGS AVAILABILITY TABLE for settings you can adjust. ═══ 3.3. OS/2 2.1 (XR02010) AND OS/2 2.0 SP/2 ═══ The OS/2 2.1 (XR02010) serial device drivers are installed exactly like the OS/2 2.0 Service Pack (XR06055) drivers. See OS/2 2.0 SERVICE PACK (XR06055) DRIVERS See VCOM.SYS DOS SETTINGS AVAILABILITY TABLE for settings you can adjust. ═══ 3.4. DOS SETTINGS WHICH AFFECT SERIAL COMMUNICATIONS ═══ The follow sections describe the various DOS Settings which can be set by the user. Please refer to the appropriate section for the system level of OS/2 you are executing to see which DOS settings apply. ═══ 3.4.1. VCOM.SYS DOS SETTINGS AVAILABILITY TABLE ═══ This table shows the DOS settings which are available at various releases of OS/2 2.x ┌──────────────────────────────────┬────────┬────────┬────────┐ │DOS SETTING │XR02000 │XR06055 │XR02010 │ ├──────────────────────────────────┼────────┼────────┼────────┤ │COM_DIRECT_ACCESS │ │ X │ X │ ├──────────────────────────────────┼────────┼────────┼────────┤ │COM_HOLD │ X │ X │ X │ ├──────────────────────────────────┼────────┼────────┼────────┤ │COM_RECEIVE_BUFFER_FLUSH │ │ │ X │ ├──────────────────────────────────┼────────┼────────┼────────┤ │COM_SELECT │ │ X │ X │ └──────────────────────────────────┴────────┴────────┴────────┘ ═══ 3.4.2. COM_DIRECT_ACCESS DOS PROPERTY ═══ When COM_DIRECT_ACCESS is ON, VCOM.SYS will allow a DOS application to access the serial ports directly. This DOS property makes LapLink III, FastLynx, FSDUAT, AS/400 Asynch Router, and MS WORD work in a VDM session. However, since the buffers in COM.SYS are not used, characters may be lost and some applications may suffer from the lack of buffering. With most DOS applications, COM_DIRECT_ACCESS should be set to OFF as the default setting. ═══ 3.4.3. COM_HOLD DOS PROPERTY ═══ The COM_HOLD Dos Property is used to keep a serial port open until the Virtual Dos Machine (VDM) Session is terminated. This setting is used for DOS applications which open the serial port and then spawn another application which expects the serial port to be opened. The disadvantage of using this setting is that even if the DOS application closes the serial port, OS/2 will keep the serial port open and will not allow any other session to access that serial port until the VDM session terminates ═══ 3.4.4. COM_RECEIVE_BUFFER_FLUSH DOS Property ═══ This option is only valid if COM_DIRECT_ACCESS is equal to OFF. There are four options for this DOS Setting: NONE (default), RECEIVE DATA INTERRUPT ENABLED, SWITCH TO FOREGROUND and ALL. The purpose of this option is to provide more flexibility for configuring DOS applications. Some DOS applications are timing sensitive and will not always read every character from the UART. Some applications may have delays built in knowing that the data in the UART will be overwritten in a set period of time. Since the timing of the VDM does not match exactly to native DOS, this type of application will not run correctly under OS/2. The DOS Settings are described in the following sections. ═══ 3.4.4.1. NONE SETTING ═══ When the "NONE" Property is set, no data will be flushed from the receive buffer (of the OS/2 communication driver). This is the default action. ═══ 3.4.4.2. RECEIVE DATA INTERRUPT ENABLED SETTING ═══ When the "RECEIVE DATA INTERRUPT ENABLED" Property is set, any data in the received data buffer for this DOS session will be discarded whenever the DOS program enables the received data interrupt on the UART. Most DOS applications have been designed to execute in a single tasking environment. Such applications experience difficulty when data (or interrupts) are queued up while the application is switched to the background or when the time slice expires. This option is for DOS programs which require data to be discarded while the received data interrupt is disabled. ═══ 3.4.4.3. SWITCH TO FOREGROUND SETTING ═══ When the "SWITCH TO FOREGROUND" Property is set, any data in the received data buffer for this DOS session will be discarded whenever the DOS program is brought to the foreground (from a background state). Background processes do not receive as high a priority as foreground processes. Some DOS applications which are timing sensitive cannot process the data (which may have accumulated in the received buffer) if the data is bunched up. This feature was added for CAD application using a digitizing tablet. If there was a great amount of puck activity while the application was in the background, the application would occasionally hang when brought to the foreground. This option corrected the problem by flushing the accumulated data and allowing the application to start fresh in the foreground. ═══ 3.4.4.4. ALL SETTING ═══ When the "ALL" Property is set, both the "RECEIVE DATA INTERRUPT ENABLED" and the "SWITCH TO FOREGROUND" options are enabled. ═══ 3.4.5. COM_SELECT DOS Property ═══ COM_SELECT allows the DOS session to select only one communication port to be used by the session. The communication ports which are not selected will be hidden from the DOS session. There are some DOS applications which take over every available communication port. This DOS property is effective in preventing those DOS applications from taking over all the communication ports. An example of a DOS application which attempts to control all the communication ports is LapLink Pro. If LapLink Pro and another application which accesses a communication port are executed at the same time, it is necessary to set COM_SELECT. The default setting is ALL. ═══ 3.5. OS/2 2.0 COMMUNICATION DRIVER DIFFERENCES ═══ The major differences between the GA release of the OS/2 2.0 communication device drivers and the later release of the communication device drivers are: 1. The parameters which are passed to the COM.SYS device driver. 2. The enhanced DOS Settings which provide more flexibility in running DOS programs. 3. There have been various defects corrected. These are noted in a later section. ═══ 4. OS/2 2.x COMMUNICATION TROUBLE SHOOTING ═══ This section will give some insight into trouble shooting communication problems with OS/2 2.x. Past experience shown that most problems will be resolved by one or more of the solutions listed below. We recommend that you print and complete the work sheets (ISA WORK SHEETS) provided at the end of this document. This is the information you will be asked when you request support for serial communication problems. ═══ 4.1. COMMON PROBLEM SCENARIOS ═══ This section will describe some common scenarios and recommend what sections to review. If you are using the OS/2 VIEW command, you can double click on a highlighted section to review it. When you are finished with the selection, click on the previous button to return to your previous position in the document. ═══ 4.1.1. WHERE DO I START ANALYZING MY SERIAL COMMUNICATION PROBLEM? ═══ First you need to determine which area of the system is not working. If you are getting an error on boot (i.e. SYS01201), you should reference the BOOT TIME ERRORS section of this document. If you are getting application errors, then you need to determine if the problem is an operating system error or application error. If you have an Industry Standard Architecture (ISA) class computer, you will need to map out the Input/Output (I/O) addresses in use and Interrupt ReQuest (IRQ) levels. The sharing of IRQs on ISA class computers is not permitted under OS/2 2.x. This is a limitation of the architecture. This limitation does not apply to MCA class computers. (See ISA INTERRUPT REQUEST LEVELS AND I/O ADDRESSES) The best way to begin analyzing the problem is to complete the ISA WORK SHEETS which are located at the end of this documents. There are instructions to assist you in collecting the information. If you have a MCA class computer, you usually will not have to worry about collection I/O address or IRQ information. If you have an ISA class computer, the I/O address and IRQ information is mandatory. If there are no errors during boot time and all I/O addresses and IRQs are unique (for ISA class computers), then use the MODE command against the serial port in question (i.e. COM1:). If this reports back data, then there is a good chance that the OS/2 side of the serial communication driver (COM.SYS) is working. If you get an error, then check that the physical hardware settings match any parameters you passed to COM.SYS. This is the cause for most problems on an ISA class computer. If you get no errors from the MODE command, you could use the PM TERMINAL applet to test the serial device (i.e. modem). You will have to customize the applet for your particular configuration. Refer to CUSTOMIZING THE PM TERMINAL APPLET for more information. If the PM Terminal application works successfully, then at least you know that the basic hardware configuration is correct and you have isolated the problem to the specific application or environment (DOS or WIN-OS2). If the problem lies with a DOS or MS-WINDOWS communication application and the MODE command works, there is a possibility that the application is not configured correctly. Most well written DOS applications are can be configured to any I/O address and IRQ for the serial port. If this is not the case with your application and you have to use, for example, COM3 and IRQ5, then this DOS base application is not going to work reliably under OS/2 2.x. You can try to use the COM_DIRECT_ACCESS DOS property. The following sections give specific advice for various situations. If viewing the ONLINE format of this document, review the HOW TO BEST USE THIS GUIDE at the beginning of this document. ═══ 4.1.2. COMx NOT INSTALLED OR IRQ NOT AVAILABLE ═══ When booting OS/2 2.x, you get a message stating that the COMx port is not available or the IRQ is not available. If the computer is an ISA class machine, there is most likely an I/O address or IRQ conflict. References: 1. BOOT TIME ERRORS 2. PS/2 (MICROCHANNEL ARCHITECTURE) COMPUTERS 3. INDUSTRY STANDARD ARCHITECTURE (ISA) 4. COMMON ISA AND MCA SITUATIONS 5. ISA INTERRUPT REQUEST LEVELS AND I/O ═══ 4.1.3. CANNOT OPEN A DOS (VDM) SESSION ═══ You do not get any errors during boot but whenever you try to open a DOS session (or start a DOS application), you get "out of memory messages" or other system messages (i.e. TRAP 000e or IPE). This is a problem on ISA class computers when using more than two (2) serial ports. There is a work around for the problem and is documented in the sections listed below. References: 1. MISCELLANEOUS ERRORS 2. DETERMINING I/O ADDRESSES 3. PROBLEMS REPORTED AGAINST COM.SYS/VCOM.SYS ═══ 4.1.4. I CONFIGURED COM4 BUT ONLY MODE COM3 WORKS ═══ This can also happen with any of the serial ports. OS/2 2.x uses the ABIOS specification for assigning logical names to the serial ports. The first address posted in the ROM BIOS area is designated as COM1, the next is COM2, etc. References: 1. MISCELLANEOUS ERRORS 2. ISA BUS ARCHITECTURE 3. DETERMINING I/O ADDRESSES 4. PROBLEMS REPORTED AGAINST COM.SYS/VCOM.SYS ═══ 4.1.5. OS/2 2.1 AND TRAP000D WHEN ACCESSING THE SERIAL PORT ═══ If you are running PROTECTONLY or have VCOM.SYS disabled, you will get this trap. This will be corrected in the next CSD for OS/2 2.1. References: PROBLEMS REPORTED AGAINST COM.SYS/VCOM.SYS ═══ 4.1.6. MODE COMMAND WORKS BUT APPLICATION DOES NOT SEE PORT (OR MODEM) ═══ You issue a MODE command from an OS/2 command prompt and you get a response back which shows the serial port settings. This is a good sign as this indicates that the OS/2 Serial Device Driver, COM.SYS, has seen the port and installed for it. Your problem now is that the particular application does not recognize the port (or modem). If the device in question is a modem, you can enter the following at the OS/2 command prompt to see if data is reaching the modem. If this command does not work, there may be a hardware or configuration problem. ECHO ATA > COMx: Where COMx: is COM1:, COM2: or the COM port you are using. You should hear the telephone dial tone (if the phone is connected) followed by the carrier tone. To turn off the carrier tone, You should enter the following: ECHO ATZ > COMx: References: 1. APPLICATION DOES NOT RECOGNIZE THE PORT 2. PERFORMANCE ISSUES 3. MISCELLANEOUS ISSUES COMMON TO OS/2 AND DOS ═══ 4.1.7. APPLICATION SEEMS TO BE LOSING DATA ═══ For serial communications, make sure that your modem is capable of hardware handshaking (CTS/RTS). You could try using the MODE command to set RTS=HS and OCTS=ON. References: 1. APPLICATION DOES NOT RECOGNIZE THE PORT 2. PERFORMANCE ISSUES 3. REAL TIME APPLICATIONS 4. USING THE MODE COMMAND ═══ 4.1.8. SERIAL PRINTER WILL NOT WORK ═══ Should you be having problems getting a Serial Printer to work under OS/2, you may have to adjust some of the MODE command settings. First make sure that the printer will work under DOS. If DOS is not an available option, verify that the cable is correct for the printer. You may want to first disable (or turn off) all the settings available using the MODE command. References: SERIAL PRINTERS AND PLOTTERS ═══ 4.1.9. SERIAL PRINTER SEEMS TO GET TOO MUCH DATA (OVERFLOW) ═══ Serial Printers like all other serial devices use a handshaking protocol. This is either software handshaking (XON/XOFF) or hardware handshaking (DSR, RTS, CTS). If you know the printer is configured for Software Handshaking, use the MODE command to set XON=ON. You may need to set all other settings to OFF. If you know the printer is configured for Hardware Handshaking, use the MODE command to set RTS=HS, OCTS=ON and ODSR=ON. You may also have to set IDSR=ON if the printer uses Data Set Ready for Handshaking. In this case, you will most likely set ODSR to OFF. References: SERIAL PRINTERS AND PLOTTERS ═══ 4.1.10. SERIAL PRINTER NOT PRINTING ENTIRE DOCUMENT ═══ If you are printing very large jobs, you may need to set the port for infinite write time out. This is the TO=ON value which is set with the MODEcommand. This is similar to the ',p' value used with the DOS 5.0 MODE command. There may also be a handshaking problem. References: SERIAL PRINTERS AND PLOTTERS ═══ 4.2. BOOT TIME ERRORS ═══ This section will describe what action to take should the COM.SYS or VCOM.SYS give an error message at OS/2 initialization (or boot) time. ═══ 4.2.1. PS/2 (MICROCHANNEL ARCHITECTURE) COMPUTERS ═══ 1. If the COM.SYS driver issues a warning at boot time on a PS/2 or other MCA class computer, reboot the computer using the reference diskette and check that the port has been properly configured. 2. If you have the PROTECTONLY flag in the CONFIG.SYS file set to YES and you are at System level XR06055 or previous, you will need to get the next service pack or OS/2 2.1. Earlier version of the OS/2 operating system did not permit interrupt sharing in PROTECTONLY mode. 3. If the PS/2 is using PCMCIA Technology, reference the section titled: PCMCIA SUPPORT UNDER OS/2 2.. ═══ 4.2.2. INDUSTRY STANDARD ARCHITECTURE (ISA) COMPUTERS ═══ 1. Verify that all IRQ levels and I/O addresses are unique for every adapter. The usual problem is that communication adapters (internal modems, FAXes, etc) use COM3 and IRQ4 which is already in use by COM1. You must PHYSICALLY change the IRQ on the adapter to one which is not in use. You need to refer to the documentation which came with the adapter. (See ISA BUS ARCHITECTURE). 2. Verify that you are passing the correct parameters to the COM.SYS driver in the CONFIG.SYS file. Some PCM machines need to have all the serial ports (i.e COM1, COM2) defined to COM.SYS in the CONFIG.SYS. If you are using a serial mouse, do not specify the communication port of the mouse. (See COMMON ISA AND MCA SITUATIONS). 3. There were problems at System Level XR02000 with recognizing some serial adapters. This has been resolved at System Level XR06055 or higher. 4. If error message during boot: COM PORT not installed because interrupt already in use, check for an IRQ conflict with other device drivers or hardware. 5. If the MODE command fails, check the CMOS data area to verify that the I/O address is listed. The OS2/DOS utility, DEBUG, will show the I/O addresses listed at location 40:0. (See DETERMINING I/O ADDRESSES FOR ISA COMPUTERS) 6. You can try explicitly setting the port parameters by passing arguments to the COM.SYS device driver. For example: DEVICE=..\OS2\COM.SYS (1,3F8,3) (2,2F8,4) ═══ 4.2.3. COMMON ISA AND MCA SITUATIONS ═══ 1. If using LAN SERVER with the UPS monitoring option and having problems at boot with COM.SYS or VMOUSE.SYS, move the OS2UPS.SYS driver to before the POINTDD.SYS statement in the CONFIG.SYS file. 2. If using LAN SERVER 3.0 with the UPS monitoring option, you need to get the latest CSD for LAN SERVER 3.0. There have been reports of TRAP 0008 which have been resolved by the latest CSD. 3. If system (AT bus or MCA) boots without error but a COM port is still not working at all, issue a MODE command (from an OS/2 command prompt) to the problem COM port (i.e. MODE COM1:). If the MODE command indicates that the COM port is not installed (i.e. SYS1798, SYS0049), check for IRQ conflicts. (See ISA BUS ARCHITECTURE). Note: If the mouse is on a COM port, the MODE command will report a SYS1620, the COM port specified is not installed, since the mouse has taken that COM port. 4. Make sure that the serial adapter posted the I/O address correctly to BIOS location 40:0. Reference DETERMINING I/O ADDRESSES 5. You must also check to see that there is a port available to install. For instance, if there is only one serial port and a serial mouse is installed, then the COM.SYS will issue a SYS1208 error indicating that there are no available ports. In this instance you should remark (REM) the COM.SYS and VCOM.SYS statements in the CONFIG.SYS file. 6. Verify the dates of COM.SYS and VCOM.SYS. They should match the following table: ┌─────────┬────────┬──────┬────────┬────────┐ │SYSLEVEL │DRIVER │SIZE │DATE │TIME │ ├─────────┼────────┼──────┼────────┼────────┤ │XR02000 │COM.SYS │24760 │ 3-30-92│12:00p │ ├─────────┼────────┼──────┼────────┼────────┤ │ │VCOM.SYS│ 7680 │ 3-30-92│12:00p │ ├─────────┼────────┼──────┼────────┼────────┤ │XR06055 │COM.SYS │24984 │10-16-92│ 3:46a │ ├─────────┼────────┼──────┼────────┼────────┤ │ │VCOM.SYS│ 8496 │10-16-92│ 5:19a │ ├─────────┼────────┼──────┼────────┼────────┤ │XR02010 │COM.SYS │25368 │ 4-29-93│ 9:34p │ ├─────────┼────────┼──────┼────────┼────────┤ │ │VCOM.SYS│ 8112 │ 4-22-93│ 6:41p │ └─────────┴────────┴──────┴────────┴────────┘ ═══ 4.3. APPLICATION DOES NOT RECOGNIZE THE SERIAL PORT ═══ This section will describe what to do if an application cannot recognize a serial port. If you had errors at boot time, please refer to BOOT TIME ERRORS ═══ 4.3.1. OS/2 (PROTECT MODE) APPLICATIONS ═══ If the application cannot access the serial port, issue a MODE command against the serial port in question. If the MODE command works, contact the vendor of the OS/2 application. ═══ 4.3.2. DOS (REAL MODE) APPLICATIONS ═══ 1. If the application cannot access the serial port, try setting (for the VDM session) the DOS Setting COM_DIRECT_ACCESS to ON. You have to close the VDM session before making changes to the DOS Settings. 2. Any application which uses QBASIC or BASIC CTTY will need to have the DOS_DEVICE DOS setting set to: C:\OS2\MDOS\COMDD.SYS. If OS/2 is not installed on C:, then substitute the appropriate drive letter. 3. See MISCELLANEOUS ERRORS ═══ 4.3.3. MISCELLANEOUS ISSUES COMMON TO OS/2 AND DOS ═══ 1. Verify that the application is configured for the correct IRQ and I/O Address. Remember that the I/O address for COM3 and COM4 on MCA computers is different than ISA computers. (See NOTES ON MICROCHANNEL ARCHITECTURE MACHINES) 2. Issue a MODE command against the serial port in question. If the MODE command indicates that the port is not installed, verify the IRQ and I/O address of the serial port. You should also check to see that parameters passed to COM.SYS match the physical configuration of the serial port. 3. If the modem is external to the computer, try to copy the config.sys file to the COM port to which the external modem is attached. You should be able to observe the various indicator lights turning on or flashing. If there is no change in the state of these lights, the external modem may be connected to the wrong port, the port may not be at the correct I/O address or IRQ level or the port may be broken. 4. You can use the ECHO command to send modem commands to a modem. This is useful to see if the modem will go "off hook" and get a dial tone. You open up an OS/2 window or full screen session and enter the following: ECHO ATA > COMx: Where COMx: is COM1:, COM2: or the COM port you are using. You should hear the telephone dial tone (if the phone is connected) followed by the carrier tone. 5. To turn off the carrier tone, you should enter the following: ECHO ATZ > COMx: ═══ 4.4. OS/2 SYSTEM ERRORS ═══ This section will describe various OS/2 generated errors and give a brief description of what these errors indicate. ═══ 4.4.1. TRAPS ═══ o If the OS/2 operating system traps when opening a DOS or WIN-OS2 session, verify that you have the correct COM.SYS / VCOM.SYS drivers installed. These drivers are a matched set and cannot be mixed between releases. The OS/2 2.1 and later service pack drivers are not designed to work on system levels XR02000 and XR06055. SEE: COMMON ISA AND MCA SITUATIONS o You should also verify any parameters you have giving to the COM.SYS device driver (in the CONFIG.SYS file). On some ISA machines, the COM.SYS device driver may have problems if incorrect IRQ and I/O addresses are given. (MISCELLANEOUS ERRORS) o If using LAN SERVER 3.0 with the UPS monitoring option, you need to get the latest Corrective Service Diskette for LAN SERVER 3.0. There have been reports of TRAP 0008 which have been resolved by the latest LAN SERVER CSD. ═══ 4.4.2. SYS3175 AND SYS3176 ═══ o If the application is an OS/2 application, contact the vendor of the application. o If the application is a DOS application, look at the Stack Segment and Extended Stack Pointer (SS:ESP) value in the register dump. If the ESP is very low (close to zero or '0000ffff'), the application has run out of stack space. The same logic applies to the Base Pointer (BP) register. This usually happens to applications which have Interrupt Service Routines (ISRs) that are subject to time constraints. The delivery (timing) of interrupts to the VDM session is different than under native DOS. This is a result of tasking (or CPU sharing) abilities of OS/2. Under DOS, the interrupts generated by the UART (of the serial port) are delivered in "real" time. Under OS/2, the interrupts are delivered at "task" time which is the time allocated by the system scheduler. Since the COM.SYS/ VCOM.SYS device drivers can accumulate interrupts, the delivery of the interrupts to the application can be faster under OS/2 than under native DOS. If an application expects to have a consistent delay between interrupts, the application may overwrite it's allocated stack due to excessive recursion into the ISR. This is also known as nested interrupts. o DOS (REAL MODE) APPLICATIONS ═══ 4.4.3. SYS0099 AND SYS1798 (PORT IN USE) ═══ o OS/2 will only permit one application or session to access a serial port. Should an application attempt to access a serial port which is in use, this message will appear. Many DOS applications (such as Personal Information Managers) open the serial ports for automatic phone dialing. You can use the COM_SELECT DOS setting to "hide" the serial port from the offending application. o Some DOS applications will open ALL of the COM ports. Use the COM_SELECT Dos Setting in all of the DOS communication sessions (VDMs). o Most DOS applications are designed to run on a single task system (DOS). Even though OS/2 allows multiple DOS applications to execute simultaneously, OS/2 is not able to manage file and device sharing for these applications. A well written application would only open a device (such as a serial port) when the device is required. Unfortunately, many DOS applications open the device as part of the initialization sequence for the application. This leads to device contention under OS/2. You can use the COM_SELECT DOS setting to "hide" the serial port from the offending application. o Most DOS applications use the machine instructions IN and OUT to communicate to the physical UART. Since there is no definitive OPEN or CLOSE statement, OS/2 has no way to determine when an application is finished using a serial port. OS/2 will not allow access to the port once an application has issued an IN or OUT machine instruction. The only way for another session to gain access to the serial port is to terminate the VDM session which accessed the port in question. o If you load any DOS or MS-Windows applications under OS/2 2.x, there is a very good possibility that the CONFIG.SYS file was updated. If any DOS (which includes Windows) device drivers are loaded in the OS/2 2.x CONFIG.SYS file or any DOS Terminate but Stay Resident (TSR) programs are loaded in the OS/2 2.x AUTOEXEC.BAT file, you will get these errors whenever you open more than one VDM session. You should load the DOS device drivers into the DOS_DEVICE DOS Settings and create unique AUTOEXEC.BAT files for each program object which requires special device support. You can get more information about the DOS_DEVICE setting from the Master Help online guide. Note: An example of an application which will cause this error is the INTEL SATISFAXTION 400 MODEMS ═══ 4.4.4. SYS0049 ═══ If you get this error and the SYSLEVEL is XR06055 or XR02010, try using the Spurious interrupt switch which is passed on the command line to the COM.SYS device driver. If this switch corrects the problem, you may wish to investigate your hardware and connections for a fault. If there are spurious interrupts present, your system may not perform at it's potential. SEE: OS/2 2.0 SERVICE PACK (XR06055) DRIVERS ═══ 4.4.5. MISCELLANEOUS ERRORS ═══ Many errors are caused by not providing the correct information to the COM.SYS device driver on an ISA personal computer. The most common mistake is to associate the logical name the operating system assigns to an adapter port (i.e. COM1, LPT1) to the physical adapter. The adapter only knows to map to a base I/O address and IRQ which must be unique. Most DOS based applications do not "open" the serial port (INT21 interface) but using the machine instructions IN and OUT to communicate directly to the adapter's port. OS/2 applications require a file handle (i.e. COM1) to communicate with physical devices because the applications are shielded from the device by the physical device driver. o If you get "out of memory errors", TRAP 000e, Internal Processing Error (IPE), SYS3175 or SYS3176 errors when opening a VDM or WIN-OS2 session, verify any parameters you have giving to the COM.SYS device driver (in the CONFIG.SYS file). On some ISA machines, the device driver may have problems if incorrect IRQ and I/O addresses are given. o There is a situation where a VDM will either not start or COM4: is not recognized. OS/2 2.x currently follows ABIOS specification and assumes that serial ports will be defined sequentially. The first I/O address at physical location 0:0400 (or 40:0) is COM1, the next address is COM2, etc. A common occurrence of this scenario is when COM1, COM2 and COM4 are defined (i.e. no COM3). If you use the DEBUG utility, you will see E8 02 in COM3's slot (40:4). The COM.SYS will assign COM3 to I/O address 2E8. The procedure to correct this error is to define COM4 as COM3 to the COM.SYS serial communication driver. COM.SYS looks at the parameters passed to see what LOGICAL NAME (i.e. COM3) is assigned to a particular I/O address and IRQ combination. Even though the serial adapter (i.e. modem) appears to be COM4, in reality, all the adapter cares about is the I/O address and IRQ. An example of how to correct the above situation: DEVICE=x:\OS2\COM.SYS (3,2E8,5) Note: The "3" is the logical name given to the adapter (i.e. COM3), "2e8" is the physical address of the adapter (which is usually for COM4) and "5" is the physical IRQ of the Adapter. Please refer to the DETERMINING I/O ADDRESSES section for more information using the DEBUG command. See also PROBLEMS REPORTED AGAINST COM.SYS/VCOM.SYS for more information about specific problems. ═══ 4.5. SERIAL PRINTERS AND PLOTTERS ═══ There are very few known problems with using serial printers plotters under OS/2 2.x other than having OS/2 driver support. The following sections will provide detail information on how OS/2 interacts with the printer. ═══ 4.5.1. SERIAL PRINTER NOT WORKING ═══ The usual cause of a serial printer not to function is because the serial communication driver (COM.SYS) was not informed of what handshaking method was to be used. Users must check with the printer manufacturer (or documentation) to determine which type of handshaking the printer uses. A serial (RS-232) line tester is also useful. Below are some suggestions to assist in analyzing the problem: o If you have NATIVE DOS, you should first verify that the printer is working correctly by booting a NATIVE DOS diskette (or dual boot) and copy the CONFIG.SYS file to the printer. COPY CONFIG.SYS COMx: where COMx: is the serial port where the printer is attached. o Boot to OS/2 and use the MODE command to turn off ALL the hardware handshaking lines (i.e. RTS, DTR, IDSR, ODSR, OCTS, XON, etc.). o Use the MODE command to set the correct baud rate (usually 9600), parity (usually NONE) and stop bits (usually 1). o Open a DOS (VDM) session and use the copy command to copy the CONFIG.SYS file to the printer twice. If this is a laser printer, you may have to use the Form Feed feature of the printer to eject the page. You should watch the indicator lights of the printer to see if you can detect any data transfer. o If the COPY command does not work in the DOS (VDM) session, edit the CONFIG.SYS file and place a "REM " before the DEVICE=..\OS2\MDOS\VCOM.SYS line. Reboot the OS/2 operating system and try the COPY command again. If this does not work, there may be a cabling problem, a port problem or handshaking problem. Note: If the VCOM.SYS device driver is not loaded, then any application which use the serial ports will have direct access to the port. Remarking out the VCOM.SYS device driver eliminates a layer of software and will assist in determining the cause of the problem. o If the COPY command works in a DOS (VDM) session, open an OS/2 session and try the COPY command there. o If the COPY command works in a DOS (VDM) session and an OS/2 session, then using the graphical interface (i.e. the DRIVES folder) on the desktop, drag a text object to the printer object defined for the serial port. You may want to HOLD the queue to see that the text object is placed into the printer object and then RELEASE the queue. Note: You should keep a record of the above tests should you need to contact OS/2 Technical Support. If the COPY command works in DOS and NOT in OS/2, there may be a handshaking error. Use the MODE command to verify that all handshaking settings are set to "OFF". If the COPY command works from both command prompts but not from the OS/2 desktop, this could be a Print Spooler configuration error. You have to set the Baud Rate, Parity and Stop Bits for the port when you create the printer object. After you get the printer working, you may have handshaking problems such as data overflow. Please refer to the following sections for more information about serial printers and handshaking. ═══ 4.5.2. SERIAL PRINTERS AND HANDSHAKING ═══ Most advance printers today handshake to the operating system regardless if the printer is parallel or serial. While the parallel interface is relatively simple, the serial interface has many ways to implement handshaking. Serial handshaking can be broken down into software handshaking and hardware handshaking. To find out which type of handshaking your printer uses, refer to the printer manufacturer's documentation. ═══ 4.5.2.1. SERIAL PRINTERS AND SOFTWARE HANDSHAKING ═══ Software handshaking is when the printer and application (or OS/2) use "software" codes such as XON/XOFF to regulate how much data is sent to the printer. If your applications seem to be overflowing the printer and you know that the printer is implementing software handshaking, you can use the MODE command to set XON=ON. This setting instructs the OS/2 serial device driver to respect the software handshaking codes sent by the printer and only send data to the printer when instructed to do so by the printer. Note: If you set software handshaking and the printer is not using software handshaking, you may not be able to print at all. You must verify that the handshaking method is set identically in the application, in OS/2 and in the printer setup. You may also need to set some of the other MODE values to "OFF". ═══ 4.5.2.2. SERIAL PRINTERS AND HARDWARE HANDSHAKING ═══ Hardware handshaking is when the printer and application (or OS/2) use the physical signals present in the communication cable between the printer and the computer. There are various combination of signals which can be used and these combinations are printer dependent. You need to refer to the printer manufacturer's documentation to determine which hardware handshaking signals are in use. The MODE command is used to set the hardware handshaking values. The combinations below have been found to work on some printers: o RTS=HS, OCTS=ON o RTS=HS, OCTS=ON, ODSR=ON o RTS=ON, OCTS=ON, ODSR=ON, IDSR=ON Note: If you are printing very large jobs, you may need to set the port for infinite write time out. This is the TO=ON value which is set with the MODE command. This is similar to the ',p' value used with the DOS 5.0 MODE command. TIP If no data appears to be sent to the printer, set all the MODE values to "OFF". Then if the printer works, individually set the values to "ON" to determine which setting is preventing transmission to the printer. ═══ 4.6. PERFORMANCE ISSUES ═══ There are a few settings you can set to improve the performance of serial communication applications. Some of these settings will affect overall OS/2 system performance. By favoring one type of application (i.e. serial communications), you may adversely affect other applications in the system. While OS/2 is an efficient, multitasking operating system, current technology specifies one CPU which can execute only one machine instruction at a given time. ═══ 4.6.1. GENERAL PERFORMANCE ISSUES ═══ o Try reducing the IDLE_SENSITIVITY DOS Settings for ALL other DOS applications. Some DOS applications continually poll the keyboard which can reduce the number of available interrupts at a given time. Note: You may wish to make a special DOS template which can be used to create OS/2 desktop objects for non-serial DOS or Windows applications. Set the IDLE_SENSITIVITY to less than 50 for this template. o Try increasing/decreasing CACHE to reduce disk activity. Decreasing DISK CACHING may reduce swapping. You must experiment on your machine. o Use the Lazy Write (/LW) option on the IFS, CACHE or DISKCACHE option in the CONFIG.SYS. o In the config.sys file, set: - PRIORITY_DISK_IO: NO - MAXWAIT: 1 o OS/2 2.0 is a multi-tasking/processing operating system. Slower microprocessors (i.e. 386/16mhz) are not going to have enough cycles to support communications above 9600 BAUD. o Even on faster machines there may be problems with supporting high speed communications. Some internal modems have been known to induce spurious interrupts which take away from the total number of interrupts that can be processed. Much depends on the quality of the hardware and the ability of the software to work with advanced communication processors such as the 16550AFN UART. o The delivery (or timing) of interrupts is different in the Virtual Dos Machine (VDM) than under native DOS. While the goal is to achieve or better the timing of native DOS, this is very difficult on the current single CPU platform used in personal computers. Applications which are time dependent (purposely timed to execute under native DOS) are not going to perform well under OS/2 2.x. Most applications which "poll" fall into this catagory. (See: REAL TIME APPLICATIONS) o DOS applications which are interrupt driven (i.e. have an Interrupt Service Routine) and issue the End-of-Interrupt to the PIC towards the end of the ISR processing (to avoid nested interrupts) will be top performers under OS/2 2.x. Consult with the vendor of the application. ═══ 4.6.2. MISCELLANEOUS ISSUES ═══ o There may be later OS/2 2.x communication drivers. These drivers are usually classed as BETA and are supported through a mail in or FAX feedback form. Should a beta driver be released, the driver will be available from the IBM OS/2 Bulletin Board Service or on CompuServ Information Service. (Call 1-800-547-1283 for information about registering for and accessing the IBM OS/2 BBS, or call 1-800-992-4777 for the OS/2 Support Line.) o The COM.SYS/VCOM.SYS device drivers only support FULLY backward compatible (Asynchronous) chip sets to the National Semiconductor NS16550A. These chip sets would include the NS8250 and NS16450. There is no support for the 8530 synchronous chip set. The COM.SYS/VCOM.SYS device drivers were never designed to support synchronous communications. ═══ 4.6.3. OS/2 PERFORMANCE ISSUES ═══ OS/2 applications have the ability to be multithreaded, use shared memory and can designate the priority to be processed at. If you have performance problems with an OS/2 application, contact the vendor of the application. ═══ 4.6.4. DOS PERFORMANCE ISSUES ═══ If the application is a DOS communication program, set the DOS_SETTINGS to the following for best performance: ┌────────────────────────────────────────┬──────────────────────────────┐ │DOS Setting │Value │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_HOLD │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_RECEIVE_BUFFER_FLUSH (XR02010) │(See values listed) │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_DIRECT_ACCESS (XR06055) │OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_SELECT (XR06055) │specific COMx │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_DEVICE (COMMDD.SYS ) │\os2\mdos\comdd.sys │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_ROM_TO_RAM │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_TIMER │ON or OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SECONDS │60 │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SENSITIVITY │100 │ └────────────────────────────────────────┴──────────────────────────────┘ Note: In order to favor your DOS based serial communication applications, you should reduce the IDLE_SENSITIVITY to below 50 in all other VDMs. ═══ 4.6.4.1. DOS BASED FAX APPLICATIONS ═══ There are no DOS based fax applications which are known to work reliably under OS/2 2.x. There has been some success with CLASS 1 fax software on a high powered 486 processor platform. There has also been some success using the Intel Satisfaxtion 400 internal modem. If sending and receiving faxes is an integral part of the system, an OS/2 fax application (such as FAXPM, FaxWorks/2 and BitFax/2) should be considered. ═══ 4.6.4.2. REAL TIME APPLICATIONS ═══ OS/2 2.x is a dynamic operating system which shares a single CPU architecture with multiple applications (processes) in such a way that the applications appear to be working simultaneously. This works fine for most types of applications. "Real Time" applications such as synchronous communications or Process Control applications place a tremendous burden on the CPU and the operating system because of the intensity of interrupt (event) processing required. The delivery (or timing) of interrupts is different in the Virtual Dos Machine (VDM) than under native DOS. While the goal is to achieve or better the timing of native DOS, this is very difficult on the current single CPU platform used in personal computers. OS/2 2.x is a very complex operating system which is able to schedule activities on a personal computer in a way similar to many minicomputers. The time slice and "freeze" times are dynamic and dependent on system activity. With a preemptive multitasking operating system, applications which are "real time" applications need to be event driven (i.e. interrupt) and need to execute at interrupt time. In the OS/2 2.x environment (on an INTEL based hardware platform), this would be a RING 0 Physical Device Driver (PDD) with a corresponding Virtual Device Driver (VDD) for VDM support. Any time the COM.SYS and VCOM.SYS drivers are not used or if COM_DIRECT_ACCESS, is set to ON, the application executing in a VDM may lose data. The reason for this is that all tasks even if in the foreground get a time slice to use the CPU. When that time slice is exhausted, the OS/2 scheduler looks to see if any other application wishes to "run". During this time, the VDM is frozen until it is rescheduled to run again. Since there is not a physical device driver for the serial port, any data (interrupt) delivered to the port may not be processed. The primary purpose of the COM.SYS / VCOM.SYS device drivers is to provide a buffer (similar to some DOS based Interrupt Service Routines) and allow data to accumulate while the VDM is not scheduled to run. ═══ 5. APPLICATION SPECIFIC PROBLEMS ═══ This section will highlight known problems with various applications. Many of these applications are listed in the OS/2 README file. ═══ 5.1. GENERAL PROBLEMS ═══ o If an application hangs, first check that the entire system has not hung. You can do this by using the CTRL-ESC sequence which should give you a window list. Sometimes this can take up to one minute if an application is hung. OS/2 will then prompt you to terminate the hung application. o If the CTRL-ESC sequence works, terminate (close) application from the window list and then issue a MODE command from the command line. If the MODE command is successful, then there may be a problem with the application. If the application is an OS/2 application, you will need to contact the vendor of the application. If the application is a DOS application, experiment with some of the DOS Settings especially the COM_DIRECT_ACCESS property. o Another thing to check when serial communication applications hang is the status of the port. Use the MODE COMMAND to turn off XON, IDSR, ODSR and OCTS. o If an application is experiencing a lot of data loss, you can lower the baud rate, upgrade to the latest release of OS/2 or change the settings in the CONFIG.SYS file (See GENERAL PERFORMANCE ISSUES). You can also try setting OCTS=ON and RTS=HS using the MODE command. If the application is an OS/2 application, contact the vendor of the application. o If a DOS application is not able to "auto answer" a modem, try the COM_DIRECT_ACCESS DOS Setting. ═══ 5.2. SPECIFIC APPLICATIONS ═══ This section will detail known problems about specific applications and will offer suggestions to correct the situation. ═══ 5.2.1. AUTOCAD 12.0 WITH A DIGITIZING TABLET ═══ AutoCad 12.0 will now see a digitizing tablet. This feature was added at OS/2 2.0, System Level XR06100 and OS/2 2.1. There are some restrictions: o The application appears to be very sensitive to the timing of the interrupt delivery. The application will only work on a 486/33mhz processor or better. o You need to set the COM_RECEIVE_BUFFER_FLUSH DOS Setting to SWITCH_TO_FOREGROUND. o You need to press one of the buttons on the puck when the AUTODESK logo is displayed. This speeds up the loading of the application and allows the application to find the digitizer. ═══ 5.2.2. ATTACHEMATE EXTRA! AND PRINTING ═══ If serial printers seem to be overflowing, try using the MODE command to set the following parameters: MODE COMx: RTS=HS,OCTS=ON,ODSR=ON Where COMx: is the serial port attached to the printer. Also See: SERIAL PRINTERS AND PLOTTERS ═══ 5.2.3. Compuserv Information Manager (CIM) (Dos Version) ═══ CIM will only work under OS/2 2.1 and OS/2 2.0, System Level XR06100if IRQ2 (IRQ9) must be used. Otherwise the application should work on standard IRQ/IO Address. ═══ 5.2.4. CrossTalk for Windows ═══ Use the MODE command to set BUFFER=OFF. Use the COM_SELECT DOS Setting for the specific serial port. ═══ 5.2.5. DOW JONES LINK ═══ This application requires the COMDD.SYS device driver. (DOS (REAL MODE) APPLICATIONS) ═══ 5.2.6. FAXWORKS FOR OS/2 (PMFAX) ═══ o There was a problem with OS/2 disabling the serial port when using FAXWORKS for OS/2. The Softnet BBS service has a private fix for OS/2 2.0. The problem has been resolved at System Level XR09999. The problem may also appear on PS/2 (MCA class) machines in OS/2 2.1. The Softnet BBS will be provided a fix when available. o This application will work with the INTEL SatisFAXtion fax modems under OS/2 2.x. Please contact Softnet for further information. o FAXWORKS for OS/2 requires a parameter passed to the FMD.SYS file to be able to share IRQ's on a MCA class machine. The statement should look like: DEVICE=x:\FAXWORKS\FMD.SYS S o If using an IBM Internal 2400/9600 fax/modem, you need to get 1.30b or later of FAXWORKS for OS/2. o If you are using a PCMCIA modem, you will have to pass parameters to the FMD.SYS device driver which is located in the OS/2 2.1 CONFIG.SYS file. The PCMCIA modem must be set for the next available serial port which is usually COM2. The following show the two ways to configure FMD.SYS: DEVICE=x:\FAXWORKS\FMD.SYS N DEVICE=x:\FAXWORKS\FMD.SYS (2,2F8,3) Note: You must be at version 1.30b of FAXWORKS for this procedure to work. ═══ 5.2.7. FT TERM 2.1 ═══ The FT Terminal application requires a COMMAND.COM loaded if the application is to be launched from the OS/2 desktop. This is done in the same fashion as the PC/ANYWHERE VERSION 4.5 (HOST AND REMOTE) application. FT Terminal (version 2.1) would not dial out correctly on some machines. This problem was not reproducible at System Level XR06055 or higher system levels of OS/2 2.x ═══ 5.2.8. GOLDEN COMPASS FOR OS/2 ═══ There have been performance problems reported against Golden Compass for OS/2 especially if a Virtual Dos Machine (VDM) is opened while Golden Compass is connected to CompuServ. The developer of the application is aware of the problems and can be contacted via CompuServ (GO OS2AVEND and enter section #2). ═══ 5.2.9. INTEL SatisFAXtion 400 Internal ═══ There has been some success with the Intel Satisfaxtion 400i fax/modem. Previous versions of this modem have not worked reliably with the INTEL supplied software. FAXWORKS for OS/2, however, does provide support for most of the Intel Satisfaxtion 400 modems. Please contact Softnet for further information. See Also INTEL SATISFAXTION 400 (internal) FAX/Modem ═══ 5.2.10. LapLink III, Laplink PRO ═══ If you are at system level XR02000, remark out VCOM.SYS otherwise use the COM_DIRECT_ACCESS DOS Setting. You must also use the MODE command to set IDSR, ODSR and OCTS of all the COM ports to OFF unless you use the COM_SELECT DOS Setting ═══ 5.2.11. MAXIMUS/2 ═══ You must use the MODE command to set OCTS=ON to keep Maximus/2 from overflowing the modem with data. ═══ 5.2.12. Mirror III ═══ This application is similar to CrossTalk. Use the MODE command to set the BUFFER=OFF. ═══ 5.2.13. OS/2 DATABASE APPLET ═══ The OS/2 Database Applet requires that the user customize the dialing and the hangup strings. Below is an example of each which works with 100% Hayes compatible modems: DIALING STRING AT&F&D3L0DT HANGUP STRING ATH0Z ═══ 5.2.14. PC/ANYWHERE VERSION 4.5 (HOST AND REMOTE) ═══ Norton's pcANYWHERE VERSION 4.5 has been tested under OS/2 2.0 at SYSLEVEL XR06055 and under OS/2 2.1 (SYSLEVEL XR02010). The application was tested using a PS/2 70, 60mb IDE drive (FAT) and 6mb of RAM using a full null modem connection. The application was executed in a customized Virtual Dos Machine (VDM) (i.e a DOS Full Screen) session. The performance was not equal to native DOS but was reasonable. File transfer was tested using AWSEND with no adverse affects. PC Anywhere and other similar applications try to get back to a DOS command which is not possible when the application is specified in the PATH and FILE NAME of the ICON. There is a simple test to see if the following fix will work. 1. Make a copy of the application object (icon). 2. Using the copy of the object, click with the right hand Mouse button and select the settings menu option. Replace the PATH and FILE NAME with a '*'. This is identical to the DOS FULL SCREEN object (icon). 3. Click on the copy of the object to start it. You should be at a DOS command prompt. Enter the name of the application and test the failing portion. If the application works, then substitute the following for the PATH and FILE NAME: x:\OS2\MDOS\COMMAND.COM Where 'x' is the OS/2 drive letter. Substitute the following for PARAMETERS: 4. /k x:\path\file.exe Where x:\path\file.exe is your application. 5. You should set the working directory to the PATH you specified in the PARAMETERS: x:\path See following sections for pcANYWHERE specific configuration. ═══ 5.2.14.1. PC/ANYWHERE HOST SESSION ═══ Due to the way Norton's pcANYWHERE/Host works, you have to specify a base COMMAND.COM as detailed in the following example. Please note that we are using drive letter "C" and directory AWHOST for our example. Your drive or directory could be different. Hardware handshaking (RTS/CTS) is very important and must be implemented. With Hardware Handshaking enabled, we recommend the following settings for the MODE command (USING THE MODE COMMAND): RTS=HS OCTS=ON Known Limitations under OS/2 2.x o When exiting AWHOST, user is left at full screen DOS command prompt (which is just like native DOS). The user needs to use the CTRL-ESC key sequence or enter EXIT at the command prompt to return to the OS/2 desktop. o If the application is switched to the background, performance will be degraded. The design of OS/2 is such that background activity will always run at a lower priority than foreground activity. o Application will get best performance in a full screen DOS VDM session. ═══ 5.2.14.1.1. CREATING AN OS/2 ICON FOR pcANYWHERE/Host ═══ 1. Copy a PROGRAM object from the TEMPLATES folder to the location where you wish to create the ICON for pcANYWHERE/Host. 2. Using the assumptions previously stated, enter the following for the PATH and FILE NAME fields: C:\OS2\MDOS\COMMAND.COM 3. Enter the following for the PARAMETERS: /k C:\AWHOST\AWHOST.EXE 4. Enter the following for the WORKING DIRECTORY: C:\AWHOST 5. Select the SESSION tab and then select DOS FULL SCREEN 6. Select the DOS settings and set the settings according to the table shown below. 7. Select the GENERAL tab and give the session a name (i.e. AWHOST). You could also select an ICON for the session if you have one available. pcANYWHERE HOST DOS SETTINGS FOR VDM SESSION ┌────────────────────────────────────────┬──────────────────────────────┐ │DOS Setting │Value │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_DIRECT_ACCESS (XR06055) │OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_HOLD │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_RECEIVE_BUFFER_FLUSH (XR02010) │NONE │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_SELECT (XR06055) │specific COMx │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_BACKGROUND_EXECUTION │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_BREAK │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_FILES │40 │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_HIGH │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_UMB │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_ROM_TO_RAM │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_TIMER │OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SECONDS │60 │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SENSITIVITY │100 │ ├────────────────────────────────────────┼──────────────────────────────┤ │INT_DURING_IO (XR02010) │ON │ └────────────────────────────────────────┴──────────────────────────────┘ ═══ 5.2.14.1.2. pcANYWHERE/Host configuration for OS/2 2.x ═══ This section will describe how Norton's pcANYWHERE/Host (application) was configured. The test environment used a full null modem cable to implement hardware handshaking (RTS/CTS). Hardware handshaking is the only reliable method of flow control under OS/2 2.x. If you are using a modem connection, please insure that your modem is capable and is configured for hardware handshaking. You will need to refer to the documentation which came with the modem to determine the correct modem initialization strings. 1. Start the AWHOST program and select HARDWARE CONFIGURATION. 2. Refer to the table below for the HARDWARE CONFIGURATION. This table defines a DIRECT connection using a full null modem cable. You may need to use different settings for a MODEM connection. Hardware handshaking (RTS/CTS), however, is very important. 3. Refer to the table below for PREFERENCES pcANYWHERE/HOST HARDWARE CONFIGURATION ┌────────────────────────────┬────────────────────┬────────────────────┐ │SETTING │DIRECT │MODEM │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Device/Port: │Serial - COMx │Serial - COMx │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Modem: │None │MODEM │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Data Rate: │19200 or less │19200 or less │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Parity: │NONE │NONE │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Flow Control: │RTS/CTS │RTS/CTS │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Connection started by: │Data Set Ready (DSR)│Depends on Modem │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Connection ended by: │Carrier Detect (DCD)│Depends on Modem │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Break length: │5 │5 │ ├────────────────────────────┼────────────────────┼────────────────────┤ │DTR state: │On While Connected │Always On │ ├────────────────────────────┼────────────────────┼────────────────────┤ │RTS state: │Always On │Always On │ └────────────────────────────┴────────────────────┴────────────────────┘ pcANYWHERE/HOST PREFERENCES ┌──────────┬──────────────────────────────────────┬────────────────────┐ │PREFERENCE│SETTING │VALUE │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │Features │Special Keyboard Handler: │None │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │ │OTHER VALUES │Defaults │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │General │Eliminate snow: │NO │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │ │Command to load host in high memory: │<> │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │ │Time between host screen scans: │20 or greater │ └──────────┴──────────────────────────────────────┴────────────────────┘ ═══ 5.2.14.2. PC/ANYWHERE REMOTE SESSION ═══ Please note that we are using drive letter "C" and directory AWREMOTE for our example. Your drive or directory could be different. Hardware handshaking (RTS/CTS) is very important and must be implemented. ═══ 5.2.14.2.1. CREATING AN OS/2 ICON FOR pcANYWHERE/Remote ═══ 1. Copy a PROGRAM object from the TEMPLATES folder to the location where you wish to create the ICON for pcANYWHERE/Remote. 2. Using the assumptions previously stated, enter the following for the PATH and FILE NAME fields: C:\AWREMOTE\AWREMOTE.EXE 3. Enter the following for the WORKING DIRECTORY: C:\AWREMOTE 4. Select the SESSION tab and then select DOS FULL SCREEN 5. Select the DOS settings and set the settings according to the table shown below. 6. Select the GENERAL tab and give the session a name (i.e. AWREMOTE). You could also select an ICON for the session if you have one available. pcANYWHERE REMOTE DOS SETTINGS FOR VDM SESSION ┌────────────────────────────────────────┬──────────────────────────────┐ │DOS Setting │Value │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_DIRECT_ACCESS (XR06055) │OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_HOLD │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_RECEIVE_BUFFER_FLUSH (XR02010) │NONE │ ├────────────────────────────────────────┼──────────────────────────────┤ │COM_SELECT (XR06055) │specific COMx │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_BACKGROUND_EXECUTION │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_BREAK │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_FILES │40 │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_HIGH │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_UMB │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_ROM_TO_RAM │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │HW_TIMER │OFF │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SECONDS │60 │ ├────────────────────────────────────────┼──────────────────────────────┤ │IDLE_SENSITIVITY │100 │ ├────────────────────────────────────────┼──────────────────────────────┤ │INT_DURING_IO (XR02010) │ON │ └────────────────────────────────────────┴──────────────────────────────┘ ═══ 5.2.14.2.2. pcANYWHERE/Remote CONFIGURATION FOR OS/2 2.x ═══ This section will describe how Norton's pcANYWHERE/Remote (application) is configured. The test environment uses a full null modem cable to implement hardware handshaking (RTS/CTS). Hardware handshaking is the only reliable method of flow control under OS/2 2.x. If you are using a modem connection, please insure that your modem is capable and is configured for hardware handshaking. You will need to refer to the documentation which came with the modem to determine the correct modem initialization strings. 1. Start the AWREMOTE program and select HARDWARE CONFIGURATION. 2. Refer to the table below for the HARDWARE CONFIGURATION. This table defines a DIRECT connection using a full null modem cable. You may need to use different settings for a MODEM connection. Hardware handshaking (RTS/CTS), however, is very important. 3. Refer to the table below for PREFERENCES pcANYWHERE/REMOTE HARDWARE CONFIGURATION ┌────────────────────────────┬────────────────────┬────────────────────┐ │SETTING │DIRECT │MODEM │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Device/Port: │Serial - COMx │Serial - COMx │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Modem: │None │MODEM │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Data Rate: │19200 or less │19200 or less │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Parity: │NONE │NONE │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Flow Control: │RTS/CTS │RTS/CTS │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Connection started by: │Always Connected │Depends on Modem │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Connection ended by: │Always Connected │Depends on Modem │ ├────────────────────────────┼────────────────────┼────────────────────┤ │Break length: │5 │5 │ ├────────────────────────────┼────────────────────┼────────────────────┤ │DTR state: │Always On │Always On │ ├────────────────────────────┼────────────────────┼────────────────────┤ │RTS state: │Always On │Always On │ └────────────────────────────┴────────────────────┴────────────────────┘ pcANYWHERE/REMOTE PREFERENCES ┌──────────┬──────────────────────────────────────┬────────────────────┐ │PREFERENCE│SETTING │VALUE │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │General │Eliminate snow: │NO │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │Mouse │ALL │Defaults │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │Remote │Special Keyboard handler: │Disabled │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │ │OTHER VALUES │Defaults │ ├──────────┼──────────────────────────────────────┼────────────────────┤ │Terminal │ALL │Defaults │ └──────────┴──────────────────────────────────────┴────────────────────┘ ═══ 5.2.15. PCBOARD ═══ PCBOARD requires COM_HOLD=ON with system level XR02000 release but requires COM_HOLD=OFF with XR06055 release. ═══ 5.2.16. PM TERMINAL (OS/2 APPLET) ═══ There have been changes to the PM Terminal applet which is supplied with OS/2 2.x. These changes are available in OS/2 2.1 or from the Softronics Bulletin Board Service which is listed in the PM Terminal dialing directory. Some of the changes made were the ability to download from a system which was using seven (7) data bits such as CompuServ Information Service (CIS). This can also be accomplished by using an eight (8) bit communication session and a seven (7) bit terminal (video) operating mode. This is all configured in the PM Terminal applet. Users who get SFT3906 (Global File Name) errors during file transfers need to insure that they have provided a valid file name for the PC FILE NAME: field. Users should also insure that they have fully deleted the *.* value which is the default for the field. There has been some confusion about the ACDI interface. In general, all modem connections should be defined as STANDARD. You should not used ACDI unless you know that you are connecting to an ACDI network interface. If you need to use ACDI, you will have to remove the REM statement in front of the SASYNCD*.SYS statement which is located in the CONFIG.SYS file BUT ONLY IF you have not installed the asynchronous features of Communication Manager. If you see the device drivers ASYNCDDB.SYS or ASYNCDDC.SYS loaded in the CONFIG.SYS file, then the asynchronous features of Communication Manager have been installed. SFT0049 is an error message received when there is a fault with ACDI support in PM Terminal. Check to see that you do not have the Communication Manager and the PM Terminal ACDI drivers loaded together in the CONFIG.SYS file. See Also: ACDI COMMUNICATIONS UNDER OS/2 2.X. CUSTOMIZING THE PM TERMINAL APPLET. ═══ 5.2.17. SLP LABEL PRINTER (SEIKO) ═══ The Seiko SLP Label Printer has been tested under OS/2 2.1 for both the DOS and Windows application. There are some limitations when using the software under OS/2 2.x. These limitations are: 1. To install the software, the COM_DIRECT_ACCESS DOS Setting must be set to ON for the VDM Session. You should create a copy of the DOS FULL SCREEN command prompt and modify the DOS Settings. 2. The vendor's software will only work with programs which are in the same VDM (DOS) or WIN-OS2 session. 3. The vendor's software will not work with OS/2 based applications. This is a limitation of the vendor's software as it is designed to only work with DOS or Windows. 4. Since the main portion of the software is a Terminate but Stay Resident (TSR) module, the PATH AND FILENAME option for the OS/2 desktop object should be set to COMMAND.COM or a '*'. 5. A separate DOS batch file should be created using the AUTOEXEC.BAT as a base to enable the software. This BATCH file should then be used in the DOS_AUTOEXEC DOS Setting. See the Master Help index for information on DOS Settings. The following DOS Settings need to be set for the OS/2 desktop object BEFORE installing the software: ┌──────────────────────────────────────────────────┬──────┐ │COM_DIRECT_ACCESS │ON │ ├──────────────────────────────────────────────────┼──────┤ │COM_HOLD │ON │ ├──────────────────────────────────────────────────┼──────┤ │HW_ROM_TO_RAM │ON │ ├──────────────────────────────────────────────────┼──────┤ │HW_TIMER │ON │ ├──────────────────────────────────────────────────┼──────┤ │IDLE_SECONDS │ 60 │ ├──────────────────────────────────────────────────┼──────┤ │IDLE_SENSITIVITY │100 │ └──────────────────────────────────────────────────┴──────┘ ═══ 5.2.18. TERMINAL EMULATOR/2 (TE/2) ═══ TE/2 was getting intermittent traps (TRAP000d or TRAP000e) at System Level XR02000. This has been resolved at System Level XR06055 or OS/2 2.1. ═══ 5.2.19. TIMESET 5.3 ═══ In order to use TimeSet 5.3, you must be at System Level XR06100 or OS/2 2.1. The following DOS Settings must be configured: ┌──────────────────────────────────────────────────┬──────┐ │COM_DIRECT_ACCESS │ON │ ├──────────────────────────────────────────────────┼──────┤ │COM_HOLD │ON │ ├──────────────────────────────────────────────────┼──────┤ │HW_ROM_TO_RAM │ON │ ├──────────────────────────────────────────────────┼──────┤ │HW_TIMER │ON │ ├──────────────────────────────────────────────────┼──────┤ │IDLE_SECONDS │ 60 │ ├──────────────────────────────────────────────────┼──────┤ │IDLE_SENSITIVITY │100 │ └──────────────────────────────────────────────────┴──────┘ ═══ 5.2.20. TYIN2000 ADAPTER CARD ═══ TYIN2000 Installation with OS/2 Requirements: o OS/2 2.1 GA o TYIN2000 software version 1.2 Considerations before installing the TYIN2000 o Review the ISA BUS ARCHITECTURE o Determine and record all configuration information using the ISA WORK SHEETS Hardware Configuration o The choices are com1 through com4. o The TYIN2000 automatically associates a Base I/O address with each com port selection: COM1 = 03F8, COM2 = 02F8, COM3 = 03E8, COM4 = 02E8. o Select a com port that is not being used and is sequential. For example, if you have COM1 & COM2, then you should select COM3. See DETERMINING I/O ADDRESSES for further information. o Write down the com port and I/O address information for use later in the installation procedure. o Do not install TYIN2000 at this time. Software Installation and Setup 1. Migrate the WIN-OS2 Program Manager to the Desktop. 2. Open the settings dialog box. Select the SESSION tab and select Separate Session. Please refer to DOS PERFORMANCE ISSUES to configure this WIN-OS2 session for optimum performance. Additionally, set the following DOS Settings: ┌────────────────────────────────────────┬──────────────────────────────┐ │WIN_RUN_MODE │3.1 ENHANCED │ ├────────────────────────────────────────┼──────────────────────────────┤ │WIN_CLIPBOARD │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_FILES │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_HIGH │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_UMB │ON │ ├────────────────────────────────────────┼──────────────────────────────┤ │DOS_AUTOEXEC │C:\TYIN.BAT │ └────────────────────────────────────────┴──────────────────────────────┘ Note: If you get General Protection (GP) errors, try setting WIN_RUN_MODE to STANDARD. 3. Select the GENERAL tab of the settings notebook and name the object: TYIN2000 4. Start the program manager Icon. 5. From the Program Manager File Menu, select Run. Insert TYIN2000 installation disk 1 of 2. and and type "x:\install", where x=the drive being used. Hit enter and follow the installation prompts provided by the TYIN2000 software. 6. Allow the software to update the AUTOEXEC.BAT. 7. For FAX MGR options setup see the TYIN2000 "Getting Started" booklet. 8. Rename the AUTOEXEC.BAT file to TYIN.BAT. 9. Rename the AUTOEXEC.BAK to AUTOEXEC.BAT. 10. Change directory to x:\TYIN and open the file TYINLD.BAT with an editor. Locate the line @C:\TYIN\LOADTYIN C:\TYIN\tyin.bin COMx IRQx 240. 11. Replace the COMx with the com port selected on the card, ie; COM3. 12. Refer to the information recorded earlier and edit IRQx, where x is the available IRQ recorded earlier. If using serial ports COM3 or COM4, refer to OS/2 2.x COMMUNICATION DRIVERS for configuration information. 13. Save the file and shutdown OS/2. Hardware Installation 1. Carefully install the TYIN2000 card in an empty slot (use a 16 bit slot ). 2. Start computer. Start Tyin Icon. TYIN is now ready to use. Limitations The scanner is untested. ═══ 5.2.21. TRI-BBS 4.02 ═══ TRI-BBS version 4.02 works much better under OS/2 2.1 or OS/2 XR06100. ═══ 5.2.22. WILDCAT BBS 3.0 ═══ Version 3.0 of this DOS application has been reported to work under OS/2 2.0. ═══ 5.2.23. X00.SYS (FOSSIL Driver) ═══ If you are at System Level XR02000 you need to place a REM before the VCOM.SYS in the CONFIG.SYS. If you have system level XR06055 or OS/2 2.1 you can set the DOS Setting, COM_DIRECT_ACCESS, to ON. The author of the X00.SYS fossil driver has an OS/2 version available. ═══ 6. USING THE MODE COMMAND ═══ This section will give a summary of how to use the MODE command. More information about the MODE command can be obtained from the online OS/2 Command Reference. ═══ 6.1. MODE COMMAND SUMMARY ═══ Use MODE from an OS/2 Command line or DOS command line and set IDSR, ODSR, and OCTS equal to OFF. For example: MODE COM3:9600,N,8,1,OCTS=OFF,ODSR=OFF,IDSR=OFF sets COM3 to 9600, no parity, 8 data bits, 1 stop bit, OCTS, ODSR and IDSR to OFF. If OCTS and/or ODSR are set to ON, the COM port will not transmit data unless CTS and/or DSR signal lines are enabled. If set to OFF, the COM port will transmit regardless of the state of signal lines CTS and/or DSR. If IDSR is set to ON, the COM port will discard the incoming data unless DSR signal line is enabled. If set to OFF, the port will receive data regardless of the state of DSR. If any problems transmitting or receiving, set OCTS=OFF, ODSR=OFF, IDSR=OFF to ensure that the hardware connected to the COM port is not preventing the port from transmitting or receiving. If an application appears to experience data loss, you can try setting OCTS=ON and RTS=HS. This will force the COM.SYS to hardware handshake with the port. The attached device, however, must be configured for hardware handshaking (RTS/CTS). You can also use XON=ON if the application and devices support software handshaking. You should not try to use both simultaneously. The MODE command at System Level XR02000 is broke; it shows the BUFFER=N/A even though a 16550AFN buffered UART communication processor is present. This problem was corrected at System Level XR06055. Many applications may override the settings established with the MODE command. The MODE command (utility) uses the same interface to the COM.SYS device driver as any other OS/2 application or VCOM.SYS. VCOM.SYS translates the INT14 (BIOS) interface for COM.SYS. For more information about using the MODE command, refer to the "OS/2 Online Command Reference" found in the Information folder. ═══ 7. ACDI COMMUNICATIONS UNDER OS/2 2.X ═══ This section will give a brief summary of using ACDI communications under OS/2. You can get more information from the COMMUNICATIONS MANAGER CONFIGURATION GUIDE (IBM publication number S04G-1002-00) ═══ 7.1. ACDI COMMUNICATIONS SUMMARY ═══ The COMMUNICATIONS MANAGER CONFIGURATION GUIDE (IBM publication number S04G-1002-00) describes ACDI as an IBM supplied interface that incorporates high level functionality (link establishment, disconnect, etc.), and a low level device driver that can be called from application programs. Communication Manager supplies two device drivers, asyncddb.sys and asyncddc.sys, that are used to provide serial communication capabilities to applications that support ACDI API calls. Communication Manager also supplies an asynchronous Terminal Emulator that utilizes ACDI API calls. These drivers work independent of com.sys that is supplied as part of the OS/2 base system, in that, ACDI API calls invoke the asyncddc.sys driver which communicates with the serial port hardware, and non- ACDI API calls invoke the com.sys driver which then communicates with the serial port hardware. At the termination of a given session the current driver relinquishes control of the serial port hardware. PM Terminal, supplied to IBM by Softronics, also provides a facility to use the ACDI API's available from the Communications Manager supplied device drivers (asyncdd*.sys). In the event that Communications Manager is not loaded, and one wishes to use the ACDI function in PM Terminal, Softronics has included a device driver, sasyncdb.sys, that uses the ACDI API calls, and is capable of communicating with the serial port hardware. If using Communication Manager on a system with com port hardware that is DMA capable, and asynchronous support was selected at installation, APAR JR06199 is applicable. The fix requires a modified version of asyncddc.sys. ═══ 8. CUSTOMIZING THE PM TERMINAL APPLET ═══ This section will describe how to customize PM Terminal for your modem. This section will also describe how to configure PM Terminal for downloading files from seven data bit connections such as CompuServ Information Services (CIS). The PM Terminal is designed to be an object oriented system. The session you select from the main menu is composed of Terminal, System Environment, Connection Path, Modem, Telephone Network and File Transfer objects. A session has one of each object. The most difficult part of configuring PM Terminal is the definition of the Modem and Video objects. Once the low level objects (i.e Modem) are created, a session profile is easily customized by selecting the various object modules from a list. This document will give a step by step procedure for creating a standard 14.4kb Hayes compatible modem session. You can use this procedure for any baud rate. ═══ 8.1. PM TERMINAL CUSTOM MODEM CONFIGURATION ═══ This procedure will define a high speed connection and demonstrate how to configure a session to the IBM National BBS. 1. Double Click on the PM Terminal ICON 2. Click once with the Left Mouse Button (LMB) on the Session Menu. 3. Click once with the LMB on the Setup Profiles menu option. 4. Click once with the LMB on the CONNECTION button. 5. Click once with the LMB on the ADD button. 6. Click once with the LMB on the OK button to accept Standard COM. 7. Place a comment which describes this Connection Object. For example, MY MODEM 19.2k,n,8,1 (19.2k BAUD, no parity, 8 bits, one stop bit). 8. Click with the LMB on the COM port to be used. 9. Click with the LMB on the SETUP button. 10. Click with the LMB on the ADD button. 11. Click with the LMB on the OK button to accept Standard Com. 12. Click with the LMB on the List Box button (arrow) to display choices. 13. Click with the LMB on the Auto-Dial selection to highlight it. 14. Click with the LMB on the OK button to accept this entry. 15. Click with the LMB on the List Box button (arrow) to display choices. 16. Click with the LMB on the Hayes Smart Modem 2400 (for this example otherwise pick a modem which is similar to your modem). The Hayes Smart Modem 2400 is a good base choice for defining custom sessions. 17. Click with the LMB on the OK button to accept this entry. 18. Place a comment which describes this MODEM object (i.e. Hayes Compatible 2400). 19. Click with the LMB on the Device Initialization String. 20. Click on the CHANGE Button. 21. Delete the "&T5" from the Initialization String. 22. Click with the LMB on the OK Button to accept this entry. 23. Click with the LMB on the SAVE AS button. 24. Enter a name to save this MODEM object (i.e. MY MODEM). 25. Click with the LMB on the SAVE button to save this MODEM object. 26. Click with the LMB on the CLOSE button to return to previous menu. 27. Click with the LMB on the Communication Parameters. 28. Click with the LMB on the CHANGE button. 29. Click with the LMB on the List Box button (arrow) to display choices. 30. Click with the LMB on the 19200 (to select the correct baud rate for this example). 31. Click with the LMB on the OK button to accept this entry. 32. Click with the LMB on the Flow Control entry. 33. Click with the LMB on the CHANGE Button. 34. Click with the LMB on the CTS option. 35. Click with the LMB on the RTS option. 36. Click with the LMB on the OK button to accept this entry. 37. Click with the LMB on the SAVE AS button to save this CONNECTION object. 38. Enter a name to save this CONNECTION object (i.e. COM - Standard). 39. Click with the LMB on the CLOSE button to return to previous menu. 40. An option step would be to setup a file transfer and telephone network profile. 41. Click with the LMB on the CLOSE button to return to previous menu. 42. Click with the LMB on the SESSION menu. 43. Click with the LMB on the ADD menu option. 44. Enter a Comment for the session (i.e IBM BBS Service in Atlanta) 45. Click with the LMB on the List Box button (arrow) of the Terminal Emulation profile selection. 46. Scroll down to the IBM ANSI terminal option and click once with the LMB to highlight the option. 47. Click with the LMB on the List Box button (arrow) of the Connection Path profile selection. 48. Scroll down to the option and click once with the LMB to COM - Standard to highlight the option. This is the name of the CONNECTION object you just created in step 38. 49. Click with the LMB on the ADD button. 50. Enter the complete phone number of where you want to dial. 51. Recommend that you select "Display this dialog box at connect time". 52. Click with the LMB on the SAVE AS button. 53. Enter a Session Name (i.e. IBM BBS 19.2k) 54. Click with the LMB on the SAVE button. You can use your modem object and connection object in other session profiles. After the creation of the Session Profiles, you may need to close PM TERMINAL and restart it. ═══ 8.2. PM TERMINAL CIS SESSION ═══ There is a problem downloading files from any communication session which is not a default of eight data bits, one stop bit and no parity (8N1). CompuServ Information Service (CIS) is an example of such a session. This is the work around for the problem: 1. First we need to create a special Terminal Profile for CIS. We will name this CIS Terminal. 2. Using the Left Mouse Button (LMB), select the Session menu bar. 3. Select Setup Profiles from the menu choices with the LMB. 4. Select TERMINAL with the LMB. 5. Select ADD with the LMB. 6. Click with the LMB on the List Box button (arrow) to display choices. 7. Select IBM ANSI from the choices listed by clicking once with the LMB. 8. Select the OK button using the LMB. 9. Select the OPERATING MODE choice by clicking once with the LMB. 10. Select the CHANGE button using the LMB. 11. Select "7 Bit Operating Mode" using the LMB. 12. Select the OK button using the LMB. 13. Select the SAVE AS button using the LMB. 14. Enter the name CIS TERMINAL for the name. 15. Select the SAVE button using the LMB. 16. Select the CLOSE Button using the LMB. 17. Select the CLOSE button using the LMB. 18. Either select the CIS session which is supplied with PM Terminal or use one you created using the steps defined above in step one. If you are using a custom session, remember that the communication session MUST BE defined for eight data bits, one stop bit and no parity (8N1). For this example, we will use the predefined CIS Session. 19. Select the CIS session by clicking once with the LMB. 20. Using the Left Mouse Button (LMB), select the Session menu bar. 21. Select the CHANGE menu option using the LMB. 22. Under the TERMINAL EMULATION PROFILE, click with the LMB on the List Box button (arrow) to display choices. 23. Select CIS TERMINAL from the select displayed using the LMB. 24. Under the CONNECTION PROFILE, click with the LMB on the List Box button (arrow) to display choices. 25. Select a Connection Profile which uses 8 data bits, one stop bit and no parity. This could be the custom one you created in the previous section (i.e. COM - Standard). 26. Select the OK button using the LMB. 27. Select the SAVE button using the LMB. ═══ 9. INTEL SATISFAXTION 400 (internal) FAX/Modem ═══ This section will describe how to configure the INTEL SatisfaxTion 400 (internal) modem under OS/2 2.0 and OS/2 2.1. Some of this information applies to the external version as well. ═══ 9.1. INTEL SATISFAXTION HARDWARE DESCRIPTION ═══ The Intel SatisFaxtion Model 400 FAX/Modem differs from typical ISA internal FAX/Modems in that it does not have a physical UART on board, instead, an onboard micro-controller emulates the UART function using software. More detailed information can be found on the INTEL Support Bulletin Board at (503) 645 - 6275. RELATED INFORMATION: SMRTUART.TXT HINT12.TXT ═══ 9.2. SMRTUART.TXT file from the INTEL BBS ═══ The following section is taken from an information file that is available on the Intel Support BBS at (503) 645-6275 (filename=SMRTUART.TXT). IBM provides this information with no warranty or support implied for any listed products. By providing this information, IBM is not implicitly or explicitly endorsing any products which may be mentioned nor does IBM necessarily agree with any statements made in the SMRTUART.TXT document. ═══ 9.2.1. SATISFAXTION 400 SMART UART OVERVIEW ═══ Both the SatisFaxtion 200 & 400 fax modems have a large gate array device which in addition to other functions, provides special circuitry that appears to the PC processor as a standard 16450 compatible serial port. In reality, it's just a facade that looks just like a serial port. Instead of shifting the character bits serially in from and out to a modem on the far end of an RS-232 cable, the characters stay intact as bytes. These characters are transferred directly between the PC processor and the SatisFaxtion 200 and 400 80C186-16 on-board processor through the silicon. The special circuitry inside the device gives the 80C186-16 complete visibility and control of the 16450 facade internal workings. The 80C186-16 knows what the PC processor is doing on the other side of this facade, and more importantly, has direct control over what the PC processor sees. On the SatisFaxtion 400, since the on-board 80C186-16 knows whether or not the PC processor has taken the last character that it deposited into the 16450 interface, it will NEVER try to put another character in until the previous one is read -- no data is spilled. Think of it as a really smart faucet that shuts off the water if you don't replace the cup in time. This is true no matter how fast the data is being moved or how busy the PC processor is. The on-board 80C186-16 will wait indefinitely until the PC processor has taken the last character before trying to give it a new one. This protection against data loss enables you to set your communication application baud rate (DTE rate) as high as you like with no fear of losing data. ═══ 9.3. HINT12.TXT file from the INTEL BBS ═══ The following sections are from a file on the INTEL BBS which answers questions about using the INTEL FAX/Modem products under the OS/2 environment. IBM provides this information with no warranty or support implied for any listed products. By providing this information, IBM is not implicitly or explicitly endorsing any products which may be mentioned nor does IBM necessarily agree with any statements made in the HINT12.TXT document. ═══ 9.3.1. INTEL SATISFAXTION 400 AND OS/2 2.x ═══ ALL OF OUR SATISFAXTION MODEMS CAN BE OPERATED AS A DATA MODEM UNDER OS/2 WITHOUT A PROBLEM. The one thing to be aware is that the SatisFAXtion Modem/200 and 400 boards require their device driver to be loaded in a DOS session, then the modem can be used normally from DOS, Windows or OS/2 applications. This can easily be set up as a batch load process. SatisFAXtion Modem/100 and /400e modems do not require any additional drivers to be used as data modems under OS/2. For FAXING, our SatisFAXtion drivers can be loaded and run from a DOS session under OS/2, but this does not provide faxing directly from OS/2 applications. However, our testing to date indicates that the SatisFAXtion Modem/100 & 400e do not fax reliably from a DOS session under OS/2; these products will require a third party OS/2 fax driver for Class 1 devices (such as that available from SofNet) to be used for faxing under OS/2. We do NOT provide an OS/2 DLL with any of our products for faxing within OS/2's native environment. Customers looking for such a driver can contact SofNet at (404) 984-8088. Note: When running DOS apps in the background, neither FAX nor MODEM programs work reliably under OS/2. For best results always run DOS communication applications in the foreground. ═══ 9.3.2. WHY DON'T YOU PROVIDE COMPLETE OS/2 SUPPORT IN THE BOX? ═══ WHY DON'T YOU PROVIDE COMPLETE OS/2 SUPPORT IN THE BOX? Because we prioritize our development projects and feature enhancements based on customer interest and demand. While OS/2 support is certainly climbing up the list, to date our customers have put greater emphasis on other requests. ═══ 9.3.3. DON'T OTHER FAXMODEM VENDORS PROVIDE OS/2 SUPPORT? ═══ DON'T OTHER FAXMODEM VENDORS PROVIDE OS/2 SUPPORT? We don't know of any desktop fax modems today that are including software for faxing from OS/2. To date such support is only available for desktop fax modems as an add-in third party product from a company such as SofNet. ═══ 9.4. INSTALLING THE INTEL SATISFAXTION 400 SOFTWARE UNDER OS/2 ═══ The following sections will describe how to install the INTEL supplied software under OS/2. There are some differences between OS/2 2.0 and OS/2 2.1. Please refer to the appropriate section. ═══ 9.4.1. PREREQUISITES FOR INSTALLING THE INTEL SUPPLIED SOFTWARE ═══ 1. Intel makes available software updates on their BBS (503 645-6275). At the time of this writing, an update for the model 400 SatisFaxtion was available (filename=29.EXE, 481,455 bytes, 5/18/93). This file is self- extracting and contains updates to several component files required for the procedures outlined in the following sections. 2. Unlike most FAX/Modem adapters, the Intel SatisFaxtion 400 (internal ISA) FAX/Modem adapter requires the use of two different base address/IRQ combinations. One combination is required for the modem portion, while the second is needed for the FAX function. The installation software supplied with the unit will set the FAX side of the adapter to a default base address of 0350h and set the physical Interrupt Request Level to IRQ10. For most OS/2 installations this will be satisfactory. Should you require different settings, please consult the INTEL documentation for further information. You will need to know the I/O address and IRQ later in the installation process so keep a record of what is configured. 3. The installation software may set the modem side of the adapter to "off", or to a combination already in use. A utility supplied with the adapter (SETUP.EXE) will allow you to change the values for the modem side. If your system has an existing COM1 and COM2 port, we suggest that you choose the COM3 option with the IRQ5 value if you do not have a 2nd physical parallel port (LPT2) installed. In the case where you do have two parallel ports (LPT1 & LPT2), and two serial ports (COM1 & COM2), you MUST disable either the second parallel port (LPT2) or one of the existing serial ports to install this adapter card. You may then use the IRQ made available for the modem side of the SatisFaxtion 400. ═══ 9.4.2. INSTALLATION OF BASIC INTEL SOFTWARE UNDER OS/2 2.0 AND 2.1 ═══ This section will give some advice on installing the BASIC Intel Software under OS/2 2.0 and OS/2 2.1. The installation is basically the same as under native DOS but there are a few extra steps involved. 1. Before starting the installation process, make a copy of your AUTOEXEC.BAT and the CONFIG.SYS files: COPY AUTOEXEC.BAT *.OS2 COPY CONFIG.SYS *.OS2 2. Open a DOS session (VDM) and follow the Intel supplied instructions for copying the SatisFaxtion software. Since you have made a copy of the OS/2 AUTOEXEC.BAT and CONFIG.SYS files, you should allow the installation utility to update these files. When you are prompted to remove the diskette and reboot the machine, do the following: a. Use the CTRL-ESC key to display the window list. b. Press the DELete key and select YES to terminate the VDM Session. 3. Open a VDM and change to the drive and directory where the Intel software was installed. 4. Copy any Intel update files (see the proceeding section) into this directory (and in the case of 29.EXE, type 29 at the command prompt - as the file is un-archived answer yes to overwrite existing files). 5. Once this is completed, you may have to execute the advanced setup option of the Intel supplied utility (SETUP.EXE) to set the base address/IRQ for the modem side of the adapter. Please refer to the INTEL documentation and the next section for further information. At this point, your AUTOEXEC.BAT file will contain statements added by the installation utility. These are TSR programs needed to run the FAX side of the adapter. To prevent these programs from being loaded into each DOS session (VDM) you will need to copy the old files back. Before you copy the old files, you must do the following: COPY AUTOEXEC.BAT FAX400.BAT COPY CONFIG.SYS CONFIG.400 COPY AUTOEXEC.OS2 *.BAT COPY CONFIG.OS2 *.SYS You need to note the IOADDR value in the CONFIG.400 as you will require this for configuration of VDMs which will require FAX access. ═══ 9.4.2.1. EXECUTING THE INTEL SATISFAXTION 400 SETUP.EXE PROGRAM UNDER OS/2 ═══ This section will give a brief overview for running the SETUP.EXE program. This example should work for most computers which ONLY HAVE ONE (1) PARALLEL port and TWO (2) SERIAL ports at standard I/O addresses and IRQ levels. Should you have a different hardware configuration, please consult the INTEL documentation. 1. Open a DOS session (DOS command prompt), change to the drive and directory where the Intel SatisFaxtion software was installed. 2. Type SETUP . After the SETUP screen appears press enter. At the red screen type "C" to continue. Note: you can ignore the message which states that SETUP.EXE is unable to access the SATISFAXTION driver. 3. At the "Options Menu" select the entry labeled "Advanced Setup". 4. At the "Advanced Setup" menu select the "Set-up Hardware" entry. 5. At the "Set-up Hardware" menu select the "Modem I/O, Interrupt" entry. 6. Choose one of the 7 entries (the 5th entry being the recommended COM3/IRQ5 combination for systems that have two serial ports - COM1 and COM2) and press enter. 7. When you have returned to the "Set-up Hardware" menu press F10 to update the adapter card EEPROM. 8. The "ESC" key will bring you back to the "Options" menu where you should select "Exit setup". You will be prompted with "Are you sure?" to which you should reply yes. 9. The next screen will ask if you wish for your AUTOEXEC.BAT and CONFIG.SYS files to be updated. Select "Quit" (without update). Note: If you update the AUTOEXEC.BAT OR CONFIG.SYS files, the procedures outlined in this document will not work correctly. We recommend that you always keep a working copy of the CONFIG.SYS and AUTOEXEC.BAT files in a safe place. 10. The SETUP.EXE utility then replies with "Press any key to reboot". When you are prompted to reboot the machine, do the following: a. Use the CTRL-ESC key to display the window list. b. Press the DELete key and select YES to terminate the VDM (SETUP.EXE) Session. 11. You should now be back at your desktop. ═══ 9.4.3. SETTING UP THE MODEM OPERATION OF THE INTEL SATISFAXTION 400 ═══ Once the software has been installed, and the modem port configured, it is necessary to load a device driver that Intel supplies before accessing the modem. This device driver, SATISFAX.SYS, is a DOS based driver that initializes the adapter card and must not be loaded in the OS/2 CONFIG.SYS file. The SATISFAX.SYS device driver must be loaded into every Virtual Dos Machine (VDM) session which needs access to the INTEL Satisfaxtion 400. The following procedure will create a program object that will load the device driver from the startup folder each time OS/2 is started. You can also use this object as a template for all VDM sessions which will require access to the INTEL Satisfaxtion 400. 1. Open the Startup folder. 2. Drag a "Program Template" into the startup folder. 3. Enter a "*" in the "Path and File Name" field. 4. Enter "/C EXIT" in the "Parameters" field. 5. Enter "X:\FAX" in the "Working Directory" field. Note: X: is the drive letter you specified during the software installation. 6. Turn to the "Settings" page. 7. Click on the "DOS Window" radio button. 8. Click on the "DOS Settings" button. 9. Enter "X:\FAX\SATISFAX.SYS IOADDR=0350" in the DOS_DEVICE field. Note: X: is the drive letter you specified during the software installation. Warning: Make sure that the IOADDR value is what is loaded in the CONFIG.400 file which you previously saved. 10. Click on "Save" 11. Select the "General" page. 12. Give the object a meaningful name (ie. "Modem Initialization"). 13. Close the Settings Window. After performing these steps, shutdown OS/2 and then reboot to continue. After rebooting the modem should be available to application programs. For OS/2 communications applications it is only necessary to specify the port (COM3 if the above suggestions were followed). For DOS based communications programs, specify the port/IRQ combination using the facility provided by the application. Refer to the application manual and ISA AND OS/2 SUMMARY: ═══ 9.4.4. SETTING UP THE FAX OPERATION OF THE INTEL SATISFAXTION 400 ═══ Operation of the FAX side of the adapter requires a FAX application program such as Intel's FaxAbility (Windows based) or FAXWORKS (OS/2 based). FAXWORKS supplies an OS/2 based device driver that will operate with the SatisFaxtion 400. FaxAbility require the Intel supplied TSR's be loaded into the DOS session that FaxAbility is being run from. This is accomplished differently for OS/2 V2.1 and OS/2 V2.0. ═══ 9.4.4.1. INSTALLING THE FAXABILITY SOFTWARE UNDER OS/2 2.X ═══ The installation of the Intel FaxAbility software under OS/2 is identical no matter which version of OS/2 you are running. The setting up of the ICONS, however, is somewhat different. We shall describe a method that we know works reliably but this is not the only way for the software to be installed. Each user will have to customize the DOS batch files for their unique environment. You need to initialize the Intel Satisfaxtion modem before loading WIN-OS2. The following procedure is to be followed: 1. Open the startup folder and make a COPY of the "Modem Initialization" object you previously created. You may place the copy on the desktop or in any folder of your choosing. 2. Open the Settings Notebook of this new object and erase the PARAMETERS and WORKING DIRECTORY fields. 3. Select the SESSION tab and choose DOS FULL SCREEN. Note: You must use a DOS FULL SCREEN session for this procedure otherwise the results will be unpredictable. 4. Select the GENERAL tab and name this new object "FaxAbility". We will now refer to the object as the FaxAbility Icon. 5. Close the settings notebook. 6. Double Click on the (new) FaxAbility Icon which should bring you to a full screen DOS command prompt. 7. Run the FAX400.BAT batch file which you previously created. 8. Enter WINOS2 and press the enter key. 9. You should now be at the WIN-OS2 desktop. At this point you need to follow the Intel Supplied instructions for installing the FaxAbility application. The installation will procedure just as it would under native MS Windows 3.x. After the installation of the software is complete, you will need to refer to the appropriate section (depending on the version of OS/2 2.x) for creating an ICON on the OS/2 desktop. ═══ 9.4.4.2. CREATING A FAXABILITY ICON UNDER OS/2 2.0 ═══ There is a special procedure to load TSRs with Windows based programs under OS/2 2.0. This procedure is not required under OS/2 2.1. This section will explain how to create an ICON on the desktop. This is only an example and you might have to change things such as drive letters and paths. This example could be used for other DOS and WINDOWs applications which require access to the Intel Satisfaxtion modem. 1. You will need to make a copy of the FAX400.BAT file which you previously created. Copy this file to a file named: WFAX400.BAT. Example copy FAX400.BAT WFAX400.BAT 2. Use the System Editor (E.EXE) to edit the WFAX400.BAT file. You have two options: a. You can just start a WIN-OS2 full screen session or b. You can start the Intel FaxAbility program "seamlessly" The following figures will give you an example of what your WFAX400.BAT should look like. The PATH setting may be different depending on where you have loaded the software. We have assumed that the INTEL software and the OS/2 operating system have been loaded on drive 'C'. ═══ 9.4.4.3. EXAMPLE OF SEAMLESS EXECUTION OF FAXABILITY UNDER OS/2 2.0 ═══ ┌──────────────────────────────────────────────────────────────────────────────┐ │ECHO. │ │ │ │PROMPT $i$p$g │ │ │ │REM SET DELDIR=C:\DELETE,512; │ │ │ │PATH │ │ │ │C:\OS2;C:\OS2\MDOS;C:\OS2\MDOS\WINOS2;C:\;C:\F AX; │ │ │ │LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM │ │ │ │LOADHIGH DOSKEY FINDFILE=DIR /A /S /B $* │ │ │ │C:\FAX\CASMGR.EXE C:\FAX\CASMGR.CFG │ │ │ │C:\FAX\FAXPOP.EXE │ │ │ │winos2.com C:\faxablty\manager.exe │ │ │ │exit │ └──────────────────────────────────────────────────────────────────────────────┘ ═══ 9.4.4.4. EXAMPLE OF OS/2 2.0 FULL SCREEN WIN-OS2 SESSION AND FAXABILITY ═══ ┌──────────────────────────────────────────────────────────────────────────────┐ │ECHO. │ │ │ │PROMPT $i$p$g │ │ │ │REM SET DELDIR=C:\DELETE,512; │ │ │ │PATH │ │ │ │C:\OS2;C:\OS2\MDOS;C:\OS2\MDOS\WINOS2;C:\;C:\F AX; │ │ │ │LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM │ │ │ │LOADHIGH DOSKEY FINDFILE=DIR /A /S /B $* │ │ │ │C:\FAX\CASMGR.EXE C:\FAX\CASMGR.CFG │ │ │ │C:\FAX\FAXPOP.EXE │ │ │ │winos2.com │ │ │ │exit │ └──────────────────────────────────────────────────────────────────────────────┘ To setup the FaxAbility Icon (which you previously created), you need to modify the object's Settings: Note: We are still following the previous example of having the INTEL software and the OS/2 operating system loaded on drive C. You will need to make adjustments if you have loaded the INTEL software or OS/2 on any other disk drive. 1. Open the settings notebook and enter the following fields: o PATH & FILENAME: C:\faxablty\manager.exe o PARAMETERS: o WORKING DIRECTORY: C:\faxablty 2. Select the SESSION tab and select WIN-OS2 Full Screen from the options presented. 3. Click on the WIN-OS2 (DOS) Settings button to configure the session. 4. Select the DOS_DEVICE option from the list and make sure that the SATISFAX.SYS device driver is loaded. You need copy the line from the CONFIG.400 (from a previous step) that states c:\FAX\SATISFAX.SYS IOADDR= 5. Select the DOS_SHELL option and set the shell command to the following: C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /K WFAX400.BAT 6. You may also need to adjust some of the other settings for better performance. (DOS PERFORMANCE ISSUES) 7. Select SAVE to save the settings. Close the object. You should now be able to double click on the FaxAbility Icon and start the program. ═══ 9.4.4.5. CREATING A FAXABILITY ICON UNDER OS/2 2.1 ═══ To setup the FaxAbility Icon (which you previously created), you need to modify the object's Settings: 1. Open the settings notebook and enter the following fields: o PATH & FILENAME: C:\faxablty\manager.exe o PARAMETERS: o WORKING DIRECTORY: C:\faxablty 2. Select the SESSION tab and select WIN-OS2 Full Screen from the options presented. 3. Click on the WIN-OS2 (DOS) Settings button to configure the session. 4. Select the DOS_DEVICE option from the list and make sure that the SATISFAX.SYS device driver is loaded. You need copy the line from the CONFIG.400 (from a previous step) that states c:\FAX\SATISFAX.SYS IOADDR= 5. Select the DOS_AUTOEXEC option and set the AUTOEXEC command to the DOS batch file, FAX400.BAT, which you created during installation: Example C:\FAX400.BAT 6. You may also need to adjust some of the other settings for better performance. (DOS PERFORMANCE ISSUES) 7. Select SAVE to save the settings. Close the object. You should now be able to double click on the FaxAbility Icon and start the program. ═══ 9.4.5. FAXWORKS, INTEL SATISFAXTION AND OS/2 ═══ This section gives some comments from a Fernwood (BBS) SatisFaxtion 400 user. While there is no official endorsement for any products listed, we have provided this information for users who may be using these products. ═══ 9.4.5.1. Comments from a Fernwood BBS SatisFaxtion 400 User ═══ The best fax modem for OS/2 users is, probably, the Intel Satisfaxtion 400, a 14.4KB fax and data modem with co-processor on board. Co-processed faxing is ideal for a multi-tasking environment. The problem is that Intel rather emphatically says that it does not support OS/2 and gives little help to callers trying to use their modems under OS/2. So let me outline a couple of points I've learned playing with the modem, OS/2 and several fax, communications and BBS packages. The only place where Intel's lack of support for OS/2 has much impact is in the configuration process. The modem works perfectly well with all the OS/2 packages I've tried it with. Normal DOS installation creates two files, Download.400 and Loader.400, which are downloaded to the modem and work perfectly well under OS/2. The only tricky part is the DOS "SetUp" program in the supplied diskettes. This program scopes out your system and assigns I/O addresses and COM ports for fax and data respectively. You can run Setup under OS/2 DOS on some machines without difficulty. Type "Setup noreboot" at the DOS prompt. If Setup has trouble configuring the modem under OS/2 DOS, which happens, you can use Boot Manager or Dual Boot to boot up real DOS and configured the modem that way. My notebook, however, runs only OS/2 HPFS and Setup, run under OS/2 DOS, could not find a com port for the data modem. It insisted on turning the modem off. I tried configuring the modem under real DOS on a much different machine and forcing the values I thought might work on my notebook. The data modem would not function when I installed it with those settings on my notebook. (Intel's tech support had told me that the results of my unsuccessful attempts to find correct com port settings for the data modem meant that it would not run under OS/2 on that notebook system.) But if I have learned anything about OS/2, it is that you should never give up. There is almost always another way to do anything. So I tried the following: I created a 3 1/2 inch DOS boot disk and copied the files from Intel's first 5 1/4 installation diskette onto it. I booted DOS from the floppy and ran Setup from the A: drive. Since I use HPFS, the system did not know about the C: drive and I could not perform some functions that required a C:\ drive directory. But Setup did work perfectly in assigning addresses and ports. I also used Advanced Setup to configure answering mode, etc. Just stay out of any line that prompts for a hard drive directory. You will have to reboot to get out again. When I had finished configuring the modem, Setup wrote the settings to the modem's non-volatile RAM. I then aborted Setup and rebooted OS/2. The modem worked! Once you have configured the modem itself, you just get copies of the two *.400 files supplied (in a *.zip file) on the installation diskette and put them in you FaxWorks directory. You will need to start up FaxWorks in receive mode each time you reboot your system in order to download these files to the modem. One of the great things about the Satisfaxtion 400 is that it will allow you to run both fax and data from the same line without juggling the software. In other words, you can fire up your communications software and access the data modem while FaxWorks is still running in receive mode. (Obviously, you can't fax and modem at the same time.) Intel documentation describes a setting of the modem, when it is the sole owner of a phone line, which allows it to answer the phone, listen for a fax, then send out data modem mating signals for a few seconds and then switch back to fax mode again. In theory, this allows it to answer incoming autodial fax calls, manual dial fax calls and autodial modem calls in the appropriate modes. I tried this with the OS/2 version of the Maximus BBS. The modem was set up to answer on one ring and to own the phone line. FaxWorks was set up to receive on the first ring. Maximus was in the default mode: S0=0 and the BBS software ready to send ATA after one RING. That does not work. S0 must be set to a number greater than 0 or the modem will not attempt to recognize incoming data calls. So I set S0=1 in the initialization string the BBS sends out to the modem and set the BBS to the alternative mode where it responds to the modems autoanswer feature. This half worked. All fax calls were answered as faxes. But modem calls were answered as data calls only until the first fax call came in. After the first fax call, the modem treated all calls as fax calls, until I manually reinitialized the modem by killing and restarted Maximus. Obviously, FaxWorks was reinitializing the modem and setting S0 back to 0, the factory default. So I changed the Initialization string in Maximus by adding "&W&Y" to the end of the string. "&W" stores the configuration in the first of two places in the modem's memory. I figured that FaxWorks probably issued an "ATZ". To be on the safe side, I also added "&Y" which instructs the modem to use the programmed settings at startup. This worked! Here is what happens. The modem picks up at the first ring and listens for a fax tone. If it hears one it tells FaxWorks to pick up. If it does not here a tone, it answers as a modem and tries to handshake. If it succeeds, it tells Maximus to pick up. If it cannot handshake, it sends out fax tones and tried to connect as a fax again. I have each software package configured to turn on the modem's speaker until a connection is established. Each is set at a different volume so I can hear what is going on. If the call is a fax call, the speaker becomes active at the volume set in FaxWorks only after the modem hands the call to FaxWorks. It acts, in other words, just as if FaxWorks had picked up the call itself. If the call is a modem call, the speaker becomes active at the volume set in Maximus, but only after the modem hands the call to Maximus. I now have my office's EMail & File Transfer BBS and main fax all coming in on the same phone line to my desktop computer running OS/2. This integrates Email and file transfer with fax communications. I can also use my own BBS to retrieve faxes on the road. I intend to install the multi-line version of FaxWorks when it becomes available and run a two line fax and two node Maximus BBS from the same two phone lines and modems. ═══ 10. PCMCIA SUPPORT UNDER OS/2 2.X ═══ This section will highlight support features for PCMCIA support under OS/2 2.x. The base support for PCMCIA is enabled in OS/2 2.1 and later releases. ═══ 10.1. GENERAL PCMCIA OVERVIEW ═══ OS/2 2.1 supports the level 2.0 Personal Computer Memory Card International Association (PCMCIA) specification for credit-card sized adapters such as memory, I/O devices, modems, and LAN Adapters. OS/2 2.1 is enabled to support environments which comply with the three layers of the PCMCIA architecture. This means that OS/2 2.1 contains the Card Services support which allows PCMCIA adapter manufacturers to write Client Device Drivers and Personal Computer System Manufacturers to ship Socket Services. ═══ 10.2. PCMCIA HARDWARE DESCRIPTION ═══ There are three major hardware components defined in the PCMCIA architecture: Cards, Sockets and Adapters. PCMCIA cards are treated in much the same way as standard removable media (such as diskettes). The card slots (called sockets) are open bays which the cards are inserted in without removing system covers or powering off the system unit. Adapters are connected to the host system's bus. The adapters map the host system bus technology to the PCMCIA technology. ═══ 10.3. PCMCIA SOFTWARE DESCRIPTION ═══ There are three major software components defined in the PCMCIA architecture: Card Services, Clients and Socket Services. The following sections will give a description of the required software layers for PCMCIA support. ═══ 10.3.1. CARD SERVICES ═══ The Card Services component is an operating system specific layer that provides the Card Services functions defined in the PCMCIA interface specification. The Card Services interface functions are provided according to the operating system's details for the client device driver model environment. Card Services relies on the operating system and Socket Services interfaces in order to facilitate requests from PCMCIA clients. The functions, features and availability of the Card Services component is the responsibility of the operating system developer/manufacturer. OS/2 2.1 contains the PCMCIA Card Services layer of support. The OS/2 Card Services support provides PCMCIA 2.00 Card Services conforming interfaces as a 16-bit inter-device driver communications interface (IDC). The PCMCIA Card Services layer is responsible for managing system resources on behalf of the Client Device Drivers and the Socket Services Layer. Client Device Drivers must use the Card Services interfaces to obtain access and configuration support for the various PC Cards supported by the client. Card Services are enabled under OS/2 2.1 using the PCMCIA.SYS and VPCMCIA.SYS device drivers. ═══ 10.3.2. CLIENT DEVICE DRIVERS ═══ Clients manage the device characteristics in an operating system specific environment and can be generalized as card-specific device drivers. The Client Device Drivers are required to manipulate the PC Card and provide the application transparency for the card devices. Therefore, for any given card (device) there must be specific device driver for each supported operating system. In addition, one client device driver can simultaneously manipulate several cards of the same type. Clients rely on the Card Services interfaces in order to set up and remove accessibility to the PCMCIA cards (devices). The functions, features, and availability of client device drivers is the responsibility of the PCMCIA card developer/manufacturer. Client Device Drivers for OS/2 2.1 use the OS/2 Card Services IDC interface to setup and release the various resources (IRQ, IO ports, Memory addresses, etc.) for PC Cards. The Client Device Drivers are supplied by the adapter manufacturer. ═══ 10.3.3. SOCKET SERVICES AND RESOURCE MAP UTILITIES ═══ The PCMCIA Socket Services component is a hardware-specific layer that isolates the details of the adapter and socket logic from the other software components. The Socket Services component provides the functions defined in the PCMCIA interface specification. Ideally, this software layer is built as a BIOS extension so that a single implementation can service multiple operating systems. However, it is acceptable to have device driver versions, since several situations preclude the availability of ROM solutions (as would be the case when you are adding adapters in existing host systems). The functions, features, and availability of the Socket Services Component is the responsibility of the hardware (adapter option or system unit) developer/manufacturer. The PCMCIA Socket Services layer might be implemented in either ROM BIOS or as a device driver. OS/2 Card Services uses the PCMCIA Socket Services 2.00 interfaces implemented in a 16-bit IDC interface. Since no ROM BIOS implementations of Socket Services were available to test with, OS/2 2.1 only supports implementations built as OS/2 Physical Device Drivers. The Resource Utility is a special Client Device Driver which should be provided by the PC manufacturer. This special client is called the Resource Utility or Resource Client. The Resource Client is responsible for providing Card Services with a system specific resource map for the personal computer. The Resource Client does not own any PC Cards or devices and is only active during the PCMCIA subsystem initialization. OS/2 Card Services initialize with a generic default system resource map which might not utilize the current system's resources in an optimal manner. Hence, it is strongly recommended that a system specific Resource Client be provided by each system manufacturer with system model resource details. ═══ 10.3.4. PCMCIA SUPPORT LAYERS ═══ The following table identifies the various PCMCIA Layers. ┌──────────────────────────────┬──────────────────────────────┐ │PCMCIA DEVICE TYPE │WHO SHOULD SUPPLY │ ├──────────────────────────────┼──────────────────────────────┤ │Card Services │Operating System │ ├──────────────────────────────┼──────────────────────────────┤ │Client Device Driver │PCMCIA Card Manufacturer │ ├──────────────────────────────┼──────────────────────────────┤ │Socket Services │PC/Socket (adapter) Supplier │ ├──────────────────────────────┼──────────────────────────────┤ │Resource Utility │PC/Socket (adapter) Supplier │ └──────────────────────────────┴──────────────────────────────┘ ═══ 10.4. PCMCIA AND OS/2 2.1 SUMMARY ═══ In summary, OS/2 2.1 provides the PCMCIA Card Services layer. There are other PCMCIA layers which are required in order to have a fully functioning PCMCIA configuration. The Socket Services and Resource Utility should come with the system unit/adapter option and should be located on the Hardware Options Reference/Setup diskette along with installation instructions. The Client Device Drivers should be provided by the PC Card/Device manufacturer and should be located on the PC Card Reference/Setup diskette along with installation instructions. It should be noted that some PC Cards do not come with any software support or hardware reference diskettes. These PC Cards require/expect a third party program to manage the PC Card. Care should be taken when purchasing PC Cards as to what requirements exist. Developers who are interested in writing OS/2 2.1 device drivers (Socket Services, Resource Map Utilities or Client Device Drivers) should consult chapter thirteen in the OS/2 2.1 DDK Input/Output Device Driver Reference manual (S71G-1898-0) IBM is aware of our customer's problems in obtaining these pieces and is working with the PCMCIA manufacturers to resolve this situation. ═══ 10.5. IBM PCMCIA DATA/FAX MODEMS ═══ IBM has PCMCIA Data/FAX modem products which could be used on the IBM Thinkpad 720 series of personal computers. Two of these products are the IBM PCMCIA High-Speed Data/FAX Modem and the IBM PCMCIA Data/FAX Modem. The IBM PCMCIA High-Speed (14.4) Data/Fax Modem has OS/2 2.1 Client (device) Driver support but the IBM PCMCIA (2400/9600) Data/Fax Modem was not announced for OS/2 2.1 and was not shipped with OS/2 2.1 Client (device) Driver support. The way you determine the difference between the modems is to examine the front of the modem. The High Speed modem has IBM High Speed PCMCIA Data/FAX Modem, the Low Speed Modem just has IBM PCMCIA Data/FAX Modem. The IBM Model Number for the High Speed PCMCIA Data/FAX modem is: FC3635. The IBM Model Number for the Low Speed PCMCIA Data/FAX modem is: FC3634. ═══ 10.5.1. INSTALLATION PROBLEMS WITH THE IBM PCMCIA MODEM ═══ There is a problem if installing the IBM PCMCIA High Speed Data/FAX modem on a drive other than the OS/2 2.1 system drive. You will need to use the following procedure: 1. If you did not install PCMCIA support during OS/2 2.1 installation, use OS/2 Selective Install to install PCMCIA support. Follow the instructions given in the OS/2 documentation. 2. Use the PCMCIA Device Driver Diskette that shipped with your system to install Socket Services. Follow the instructions delivered with your hardware. 3. After completing installation of Socket Services driver, do NOT power off or reboot the system. Edit the CONFIG.SYS in the root directory where OS/2 is installed. 4. Find these two statements which were installed during step 2 above: REM DEVICE=d:\OS2\PCMCIA.SYS REM DEVICE=d:\OS2\MDOS\VPCMCIA.SYS Note: Make sure that a DEVICE=d:\OS2\COM.SYS statement precedes the first PCMCIA.SYS statement. See OS/2 2.1 GA CONFIG.SYS 5. ADD the following statements to your CONFIG.SYS file in the order indicated below. The lines starting with REM are the ones from a previous step. Make sure to substitute the drive letter where OS/2 is installed in place of the 'd:' in the statements below. See OS/2 2.1 GA CONFIG.SYS for a working example. REM DEVICE=d:\OS2\PCMCIA.SYS DEVICE=d:\IBMODEM\ESTDFM.OS2 S1C2 REM DEVICE=d:\OS2\MDOS\VPCMCIA.SYS DEVICE=d:\OS2\$ICPMOS2.SYS DEVICE=D:\OS2\IBM2SS02.SYS DEVICE=D:\OS2\ICRMU02.SYS 6. Remove the REM statements that precede the PCMCIA.SYS and VPCMCIA.SYS device driver statements. 7. Save the CONFIG.SYS file and exit the editor. 8. Create a \IBMODEM directory on the drive where OS/2 is installed and copy ESTDFM.OS2 from the IBM Data/Fax Modem Diskette into this directory. 9. Shutdown OS/2 and re-IPL your system. The PCMCIA and Modem device driver statements in CONFIG.SYS should appear in CONFIG.SYS as shown the section OS/2 2.1 GA CONFIG.SYS . ═══ 10.5.2. OS/2 2.1 CONFIG.SYS ORDERING FOR THE OS/2 2.1 PCMCIA SUPPORT ═══ There is a problem with COM.SYS and the way it interacts to Card Services (PCMCIA.SYS). Normally, COM.SYS would follow PCMCIA.SYS but due to a defect, the OS/2 2.1 COM.SYS must come before PCMCIA.SYS. Future releases of OS/2 2.1 will require COM.SYS to follow PCMCIA.SYS. The next section gives an example of the device statements for the IBM PCMCIA High-Speed Data/FAX Modem on an IBM Thinkpad 720. ═══ 10.5.2.1. OS/2 2.1 GA CONFIG.SYS & IBM 720 PCMCIA SUPPORT ═══ This is an example of a partial CONFIG.SYS from an IBM Thinkpad 720(c) using an IBM High-Speed PCMCIA Data/FAX Modem with OS/2 2.1 ship level drivers. IFS=C:\OS2\HPFS.IFS /CACHE:64 /CRECL:4 PROTSHELL=C:\OS2\PMSHELL.EXE SET USER_INI=C:\OS2\OS2.INI SET SYSTEM_INI=C:\OS2\OS2SYS.INI SET OS2_SHELL=C:\OS2\CMD.EXE SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,CONNECTIONS SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE SET COMSPEC=C:\OS2\CMD.EXE . . . DEVICE=C:\OS2\APM.SYS {Advance power management} DEVICE=C:\OS2\PWRMGMT.SYS DEVICE=C:\OS2\MDOS\VAPM.SYS {Virtual Advance Power Management} DEVICE=C:\OS2\POINTDD.SYS DEVICE=C:\OS2\MOUSE.SYS DEVICE=C:\OS2\COM.SYS DEVICE=C:\OS2\PCMCIA.SYS {Card Services} DEVICE=C:\IBMODEM\ESTDFM.OS2 s1c2 {Client Device Driver for Modem} DEVICE=C:\OS2\MDOS\VPCMCIA.SYS {Virtual Card Services} DEVICE=C:\OS2\MDOS\VMOUSE.SYS DEVICE=C:\OS2\MDOS\VCOM.SYS CODEPAGE=437,850 DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP DEVINFO=SCR,VGA,C:\OS2\VIOTBL.DCP SET VIDEO_DEVICES=VIO_SVGA SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA) DEVICE=C:\OS2\MDOS\VSVGA.SYS DEVICE=C:\OS2\$ICPMOS2.SYS {HW Resource utility} DEVICE=C:\OS2\IBM2SS02.SYS {Socket Services} DEVICE=C:\OS2\ICRMU02.SYS {Resource Map Utility} ═══ 10.5.2.2. FUTURE OS/2 2.1 CONFIG.SYS & IBM 720 PCMCIA SUPPORT ═══ This is an example of a partial CONFIG.SYS from an IBM Thinkpad 720(c) using an IBM High-Speed PCMCIA Data/FAX Modem with a later OS/2 2.1 COM.SYS. This is not currently available. There are APARs which address this issue. IFS=C:\OS2\HPFS.IFS /CACHE:64 /CRECL:4 PROTSHELL=C:\OS2\PMSHELL.EXE SET USER_INI=C:\OS2\OS2.INI SET SYSTEM_INI=C:\OS2\OS2SYS.INI SET OS2_SHELL=C:\OS2\CMD.EXE SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,CONNECTIONS SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE SET COMSPEC=C:\OS2\CMD.EXE . . . DEVICE=C:\OS2\APM.SYS {Advance power management} DEVICE=C:\OS2\PWRMGMT.SYS DEVICE=C:\OS2\MDOS\VAPM.SYS {Virtual Advance Power Management} DEVICE=C:\OS2\POINTDD.SYS DEVICE=C:\OS2\MOUSE.SYS DEVICE=C:\OS2\PCMCIA.SYS {Card Services} DEVICE=C:\OS2\COM.SYS DEVICE=C:\IBMODEM\ESTDFM.OS2 s1c2 {Client Device Driver for Modem} DEVICE=C:\OS2\MDOS\VPCMCIA.SYS {Virtual Card Services} DEVICE=C:\OS2\MDOS\VMOUSE.SYS DEVICE=C:\OS2\MDOS\VCOM.SYS CODEPAGE=437,850 DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP DEVINFO=SCR,VGA,C:\OS2\VIOTBL.DCP SET VIDEO_DEVICES=VIO_SVGA SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA) DEVICE=C:\OS2\MDOS\VSVGA.SYS DEVICE=C:\OS2\$ICPMOS2.SYS {HW Resource utility} DEVICE=C:\OS2\IBM2SS02.SYS {Socket Services} DEVICE=C:\OS2\ICRMU02.SYS {Resource Map Utility} ═══ 10.5.3. TROUBLE SHOOTING THE 720C AND THE PCMCIA MODEM ═══ The following sections will highlight key area to review should you be having difficulty with the IBM High-Speed PCMCIA Data/FAX Modem and the IBM Thinkpad 720(c). ═══ 10.5.3.1. THE 720 CONFIGURATION (VIA THE REFERENCE DISKETTE) ═══ Below are some key settings for the IBM Thinkpad 720 which are set using the reference diskette supplied with the computer. These values were taken from a working IBM Thinkpad 720 and could be different on some machines. These values, however, are a good reference point should you be having difficulties. 1. Boot the 720 from the reference diskette supplied with the computer. 2. Select Set Configuration 3. Select View Configuration a. Check the value for Serial Port A. The default value should be: SERIAL_1,IRQ4 b. Check the value for PCMCIA Interface Controller. The default value should be: 3e0-3e1 You can modify these values if necessary by using the Change Configuration option. 4. Return to the Main Menu by pressing F3 and select Set Features. a. Select Set advanced features b. Select Set power management options c. Check that the Processor setting is not set to Auto(Long Battery Life) We recommend that you select 50 MHz. d. Check that Serial port is set to ON. e. Check that PCMCIA slots is set to ON Note: These devices can be turned off and on by using the PS2.EXE utility. The purpose of setting these devices to ON is to assist in problem resolution. Please refer to the documentation shipped with your system. 5. Return to the Main Menu by pressing F3 and select F3=Exit. ═══ 10.5.3.2. CHECK FILE VERSIONS ═══ After you verify that the IBM Thinkpad 720 system configuration (via the reference diskette) is correct, you need to check the following files versions: ┌─────────────┬────────────────────────────┬─────────┬──────┐ │FILE NAME │RESOURCE TYPE │DATE │SIZE │ ├─────────────┼────────────────────────────┼─────────┼──────┤ │IBM2SS02.SYS │Socket Services │06-14-93 │11264 │ ├─────────────┼────────────────────────────┼─────────┼──────┤ │ICRMU02.SYS │Resource Map Utility │05-17-93 │ 5797 │ ├─────────────┼────────────────────────────┼─────────┼──────┤ │$ICPMOS2.SYS │IC Card Power Mgmt. Support │06-25-93 │ 4879 │ ├─────────────┼────────────────────────────┼─────────┼──────┤ │ESTDFM.OS2 │Client (modem) Dev. Driver │04-14-93 │ 5173 │ └─────────────┴────────────────────────────┴─────────┴──────┘ The latest PCMCIA product updates are available from the IBM National Support Center BBS. The disk images are stored in the Reference Diskette library. You will need to enter REF DISK at the main BBS menu to enable access to this library. The files names are: TPPCM112.EXE - Latest Socket Services for IBM Thinkpad 720(c) HSPCM120.DSK - Latest Client Device driver for the IBM PCMCIA Data/FAX modem. ═══ 10.5.3.3. CHECK MODEM VERSION ═══ If your IBM highspeed PCMCIA Data/FAX modem is losing data or does not make consistent connections, you need to check the version of the FLASH ROM. The procedure should be used: 1. Use a terminal emulator (such as PM Terminal) to connect directly to the modem. 2. Enter "ATI0" and check that the modem responds with "14400". 3. Enter "ATI3" and check that the modem responds with something similar to "PCMCIA HS v1.29 . . . 1993 - 028". If the number after the "1993" date is less than "028", you need to contact the support number which came with your Thinkpad system. You will need a FLASH ROM update. ═══ 10.5.3.4. OTHER IBM THINKPAD 720/PCMCIA ISSUES ═══ 1. The order of the config.sys file is very important. Your should review OS/2 2.1 GA CONFIG.SYS to see that your CONFIG.SYS file is similar. Please note the placement of the COM.SYS in relation to the PCMCIA.SYS statement. 2. The Serial Ports (i.e. COMx) must be defined sequentially. This means that if you have COM1 enabled on the IBM 720, the first PCMCIA modem should be defined as COM2. This is done by passing parameters to the ESTDFM.OS2 Client Device Driver. 3. If the PS2.EXE utility is used to set the IBM 720 to TRAVEL mode, the Socket Services may abort with a TRAP000D. This problem is currently being addressed. 4. The 16 byte buffer in the UART of the IBM PCMCIA High-Speed Data/FAX Modem is not recognized by OS/2. This problem is currently being addressed. 5. There appears to be problems with multiple insertion events. This has not been recreated with the latest Socket Services and Resource Map Utility for the IBM 720. ═══ 10.6. PCMCIA MODEMS WITH VENDER SUPPLIED (DOS) "POINT ENABLERS" ═══ The COM.SYS device driver will accept parameters for serial ports which do not exist in the machine at boot time. PCMCIA modems are an example of such hardware. While PCMCIA devices are only supported when the PCMCIA 2.0 specification is implemented, some PCMCIA modems have been found to work (with restrictions) under the OS/2 2.1 Virtual DOS Machine (VDM). User's should inquire with the modems vendor for the availability of OS/2 2.x PCMCIA 2.0 device driver support for their PCMCIA modem to achieve best results. The method described in this section may not work in future releases of the OS/2 product. The following requirements must fulfilled to have support for PCMCIA modems using DOS based device drivers: 1. The PCMCIA modem may need to be present in the machine at boot time. There is no "hot plug" support available when using DOS based device drivers. 2. You will have to determine in advance what I/O address and IRQ will be used by the PCMCIA modem. You will have to specify these as parameters to the COM.SYS device driver (See OS/2 2.1 (XR02010) AND OS/2 2.0 SP/2 ). 3. The PCMCIA modem must have the ability to be enabled (or "turned on") from an OS/2 2.1 VDM Session. 4. The software (i.e. the Point Enabler) to enable the PCMCIA modem will need to be executed at before using the modem. We recommend the same type of procedure as used with the INTEL Satisfaxtion 400 modem; create a DOS batch file which runs the vendor's device drivers and then terminates. You can create an ICON to this batch file and include it in your STARTUP folder. Note: If you are using a DOS based serial communication application, you may wish to load the DOS based device drivers into the VDM session. If the drivers are normally load in the DOS "CONFIG.SYS" file, you can load them into the DOS_DEVICE setting. If the drivers are normally loaded in the DOS "AUTOEXEC.BAT" file, you can load the drivers in a custom "AUTOEXEC.BAT" file and assign the file to the session using the DOS_AUTOEXEC setting. Refer to the OS/2 Master Help facility for more information. 5. The point enabler must not detect conflicting devices using the BIOS (40:0) data area. If the point enabler does detect conflicts, the point enabler needs to have an override parameter or you can try the procedure in the next section. Contact the vendor of the modem. 6. The modem must remain enabled when the point enabler is terminated. 7. If you are using an IBM 720, you will have to remark (REM) the lines in the CONFIG.SYS file which contain: PCMCIA.SYS, VPCMCIA.SYS, IBM2SS02.SYS, ICRMU02.SYS and possibly $ICPMOS2.SYS. This is required since you are not implementing a fully compatible PCMCIA 2.0 system. ═══ 10.6.1. MEGAHERTZ MODEMS UNDER OS/2 2.X WITH THE DOS ENABLER ═══ The Megahertz XJACK PCMCIA Data/FAX modem has been tested under OS/2 and will work under the limitations listed in the previous section. This procedure is designed to use the MEGAHERTZ DOS Point Enabler named SETMHZ.EXE. Megahertz is currently developing an OS/2 Client Device driver for their modem. Below are the necessary steps required to configure the Megahertz XJACK PCMCIA Data/FAX modem: 1. Edit the CONFIG.SYS and add the following parameters to the COM.SYS device driver: ..\COM.SYS (2,2f8,3) 2. You will need to create an input file for the DEBUG utility. You should create this file in the same directory as the SETMHZ.EXE program. This input file will be used to zero out the BIOS information at the 40:0 location. See the following section for an example of the DEBUG.INP file. 3. You will need to create a DOS Batch (*.BAT) file named SETUPMOD.BAT with the following lines in it: DEBUG < DEBUG.INP SETMHZ Note: This file must be in the same directory as the DEBUG.INP and SETMHZ.EXE files. 4. After creating the SETUPMOD.BAT file, you should execute it to make sure that you get no errors. 5. You then should create an ICON to point to the SETUPMOD.BAT file. You should set the WORKING DIRECTORY to the directory where the SETUPMOD.BAT, DEBUG.INP and SETMHZ.EXE files reside. This ICON (or DOS Program Object) should be placed in your Startup Folder so that the modem is initialized each time you boot OS/2 2.1. ═══ 10.6.2. DEBUG.INP ═══ The DEBUG.INP is an input file for the OS/2 - DOS DEBUG utility. This file contains the keystrokes necessary to place zeros in the ROM BIOS location for COM2. This is required for the DOS Point Enabler of the Megahertz and other similar PCMCIA Data/FAX modems. You need to create this file for the steps listed in the previous section. The DEBUG.INP file must be created EXACTLY as shown below: e 40:2 00 e 40:3 00 q Note: There should be one blank line following the 'q'. The very first line must be the "e 40:2" line. ═══ 11. PROBLEMS REPORTED AGAINST COM.SYS/VCOM.SYS ═══ This section will provide a summary of problems reported against COM.SYS/ VCOM.SYS. ═══ 11.1. APAR TABLE ═══ ┌───────┬────┬───────┬──────────────────────────────────────────────────┐ │APAR │OS/2│SYSTEM │SUMMARY │ │ │REL.│LEVEL │ │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ08430│200 │ │PM TERMINAL (SOFTERM) INCORRECTLY UPDATES THE │ │ │ │ │SCREEN POSITION WHEN USING VT100 EMULATION AND │ │ │ │ │SPLITTING LINES IN DEC EDITOR. PM Terminal │ │ │ │ │connected to DEC VAX using VT100 emulation. When │ │ │ │ │a line is split at column 39 (or greater) and then│ │ │ │ │the left arrow key is used to return to the │ │ │ │ │previous line, the status display (the Column │ │ │ │ │indicator) is shown in the middle of the document.│ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ08728│210 │ │TRAP 000D CS:EIP xxxx:00001406 CSLIM 0000299F │ │ │ │ │REV. 6.514 IN COM.SYS WHEN PROTECTONLY=YES. If a │ │ │ │ │customer is running OS/2 2.1 in PROTECTONLY mode │ │ │ │ │OR has not loaded the VCOM.SYS device driver (i.e.│ │ │ │ │REMarked it out in the CONFIG.SYS), the user will │ │ │ │ │get this trap listed at the EIP. Customer's who │ │ │ │ │require immediate relief can load a previous │ │ │ │ │version of COM.SYS. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ08958│210 │ │FAXWORKS/2 (PMFAX) APPEARS NOT TO RELEASE THE │ │ │ │ │SERIAL PORT AFTER TERMINATION. SYS1798 ERROR. │ │ │ │ │PROBLEM IS IN COM.SYS / VCOM.SYS. If a serial │ │ │ │ │port was accessed while FAXWORKS was in receive │ │ │ │ │mode, the serial port would be unusable by any │ │ │ │ │application until the OS/2 operating system was │ │ │ │ │rebooted. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ09085│210 │ │TRAP000E OR IPE ON ISA/EISA BUS MACHINES WITH │ │ │ │ │PARAMETERS PASSED TO COM.SYS. This problem should │ │ │ │ │only occur on ISA/EISA machines. The COM.SYS │ │ │ │ │device driver looks at the BIOS area (40:0) to │ │ │ │ │determine what I/O addresses are assigned to the │ │ │ │ │logical device names (i.e. COM1). The first │ │ │ │ │"slot" (40:0) address is assigned to COM1, the │ │ │ │ │next "slot" (40:2) is assigned to COM2, etc. This│ │ │ │ │trap is caused when the parameters passed to │ │ │ │ │COM.SYS are not defined sequentially or when │ │ │ │ │defining a COMx port when the previous port does │ │ │ │ │not exist. For example: DEVICE=C:\OS2\COM.SYS │ │ │ │ │(4,2e8,5) ** no COM3 defined ** │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ09294│200 │ │COM.SYS NOT BEHAVING CORRECTLY WITH RTS=TOG. When│ │ │ │ │reading from the serial port, COM.SYS is raising │ │ │ │ │RTS. This is incorrect. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ09514│210 │ │A MODE COMMAND AGAINST THE IBM PCMCIA DATA/FAX │ │ │ │ │MODEM RETURNS BUFFER = N/A. This is incorrect as │ │ │ │ │the device is buffered. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ09680│210 │ │PCMCIA.SYS MUST FOLLOW COM.SYS. This is not │ │ │ │ │correct as card services should load before client│ │ │ │ │device drivers and PCMCIA.SYS. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ09941│210 │CANCEL │CANNOT ACCESS THE COM PORT FROM A DOS 5.0 AND DOS │ │ │ │ │6.0 VMB. THE DOS 5.0 WILL SOMETIMES WORK BUT DOS │ │ │ │ │6.0 NEVER WORKS. There was a change made to │ │ │ │ │FSFILTER.SYS for OS/2 2.1 and OS/2 2.0 + XR06100. │ │ │ │ │This means that all VMBs which were created under │ │ │ │ │OS/2 2.0 will have to be updated with the FSFILTER│ │ │ │ │which came with OS/2 2.1 OR XR06100. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ10063│210 │ │WHEN USING IRQ2 FOR A SERIAL PORT IN A VDM THERE │ │ │ │ │IS NO ECHO FROM AN ATTACHED MODEM AFTER VDM │ │ │ │ │STARTED TWICE. When using IRQ2 for a serial port │ │ │ │ │in a VDM there is no echo from an attached modem │ │ │ │ │after VDM is terminated and started for the second│ │ │ │ │time. A DOS application can access the port once,│ │ │ │ │terminate the VDM session and then attempt to │ │ │ │ │access the port again. On the second try no │ │ │ │ │characters will be displayed on the screen. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ10148│210 │ │THE HOME 3270 OF THE PCS3270 VER. 3.0 ENTRY LEVEL │ │ │ │ │DOS DOES NOT WORK IN OS/2 2.1 VDM. Accessing │ │ │ │ │PCS3270 locks the host session. │ ├───────┼────┼───────┼──────────────────────────────────────────────────┤ │PJ10200│210 │ │PROBLEMS USING THE IBM (TORONTO LABS) PCMCIA │ │ │ │ │DATA/FAX MODEM UNDER OS/2 2.1. DROPPING │ │ │ │ │CHARACTERS, ETC. There is a problem with COM.SYS │ │ │ │ │and the new chipset used on these modems. APEX │ │ │ │ │modems are also corrected with the APAR. │ └───────┴────┴───────┴──────────────────────────────────────────────────┘ ═══ 12. ISA WORK SHEETS ═══ This section will provide you with ISA Work Sheets to assist you in configuring your system. Should you have any questions about adapter addresses or IRQs, you can take this sheet to the place where you purchased your system and they should be able to assist you in filling it out. The easiest way to print this out is to select the sheet you wish to print and select the COPY to file (under the SERVICES menu). This will copy the section you are in to a file named TEXT.TMP in the current working directory. You can then print this file in text mode. You can also just select the print option below. ═══ 12.1. HOW TO COLLECT DATA FOR WORKSHEETS ═══ You should first complete the basic configuration work sheet.This is very important as the type of hardware used makes a difference. Please provide as much information as possible including application names and VERSIONS, adapter names and MANUFACTURERS. If you have an ISA or EISA computer, you will have to provide accurate information about I/O addresses and IRQs which are in use. The I/O addresses and IRQs for COM1 and COM2 are usually standard. Most problems occur with the addition of other serial adapters (such as Multi-I/O adapters, internal modems, Multimedia adapters, etc). The only reliable way to determine physical IRQ assignment for an ISA adapter is to check the physical settings with the adapter's documentation. (ISA BUS ARCHITECTURE) You can use the DEBUG (DETERMINING I/O ADDRESSES) utility to get the I/O addresses used by COM1 through COM4. ═══ 12.1.1. RECOMMENDED STEPS TO COMPLETE THE FORMS ═══ 1. Complete the Hardware Configuration Work Sheet and IRQ settings. 2. Open and OS/2 Window and use the DEBUG (DETERMINING I/O ADDRESSES) to provide the I/O addresses. Record this information on the worksheets under the DEBUG information section. 3. Since you are at an OS/2 command prompt, you can get the file sizes of the COM.SYS, VCOM.SYS and COMM.DRV files by entering the following: DIR/S filename where the filename is COM.SYS and VCOM.SYS. Once the system has displayed the file, you can use the CTRL-C key sequence to cancel the search. Record the file sizes on ERROR MESSAGE AND ENVIRONMENT DETAILS Worksheet. 4. Edit the CONFIG.SYS file (E CONFIG.SYS) and search for PRIORITY_DISK_IO. Record the value on the CONFIG.SYS SETTINGS worksheet. 5. Search again for MAXWAIT. Again, record the value on the CONFIG.SYS SETTINGS worksheet. 6. Go to the bottom of the CONFIG.SYS file and work backwards until COM.SYS and VCOM.SYS are found. Is there a REM statement in front of VCOM.SYS or no VCOM.SYS loaded? If so, mark VCOM.SYS disabled otherwise mark VCOM.SYS enabled. 7. Record the parameters for the COM.SYS device driver. If any parameters are passed, verify that the I/O addresses match what you found using DEBUG in step 1 above. Remember that IRQ sharing is not permitted on ISA bus machines. PS/2's do not require any parameters. 8. You should use ALT-F4 to exit the editor and return to the OS/2 command prompt. Unless you have made specific changes, you should DISCARD any accidental changes made. This is very important for customers who are not very familiar with the editor. 9. You should now be back at the OS/2 command prompt. You should issue a MODE command against the COM port in question (i.e. MODE COM1 ). Record the values reported in the MODE COMMAND section of the worksheets. (USING THE MODE COMMAND) 10. If the problem is a DOS or Windows application, you should return to the desktop and open up the SETTINGS for the program object. Go to the Session TAB and get the DOS Settings for COM_HOLD, COM_SELECT, etc. If one of the settings is not present, mark it N/A. 11. Please give a detailed description of what the problem is. This description should include: a. The name and version of the application. b. Detailed symptoms of the problem (lost data, screen corruption, cannot dial the modem, etc). c. If known, steps required to reproduce the problem. d. What steps you did to attempt to correct the problem. ═══ 12.2. HARDWARE CONFIGURATION WORK SHEET ═══ *********************************************************************** ** Hardware Configuration Work Sheet ** *********************************************************************** OS/2 Version: _________ CSD Level: ________________________________ Manufacturer: Make,Model,Speed: _____________________________________ BIOS: Make,Date RAM: Cache: _________________________________________ HD1 / HD2: Make,Size,Type: __________________________________________ Partition Info: _____________________________________________________ Floppy Drv: A: ______ B: ______ Tape Drv: _______________________ Video: Make,Chipset,Res,VRAM: _______________________________________ Mouse: Make,Type,Buttons,Emulation: _________________________________ Printer: Make,Model,Emulation: ______________________________________ All Peripherals,Cards,Co-Processor: _________________________________ ______________________________________________________________________ *********************************************************************** ** PHYSICAL (HARDWARE) IRQ SETTINGS AND I/O ADDRESSES ** *********************************************************************** IRQ Settings -The default/common settings are shown. Please indicate the ACTUAL IRQ settings for your hardware: IRQ1: Keyboard__ IRQ2: ____________ IRQ3: __________ IRQ4: ___________ IRQ5: __________ IRQ6: Drv A_______ IRQ7: LPT1______ IRQ8: Clock______ IRQ9: __________ IRQ10: ___________ IRQ11: _________ IRQ12: __________ IRQ13: Math Coprocessor____________ IRQ14: Harddisk_ IRQ15: __________ *********************************************************************** DEBUG (D 40:0): 0040:0000 ____ ____ ____ ____ ____ ____ ____ ____ - BC 03 78 03 78 02 C0 9F ═══ 12.3. OS/2 ERROR MESSAGE & ENVIRONMENT DETAILS ═══ *********************************************************************** ** ERROR MESSAGE AND ENVIRONMENT DETAILS ** *********************************************************************** Error Message/Number, if any: __________________________________________ Where does the error occur: VDM _ OS/2 _ WinOS2 _ On Boot Up _ Config.sys: Is VCOM.SYS: Enabled _ Disabled _ Priority_Disk_IO = ____ Type: Modem _ Fax _ Peripheral (not mouse, e.g. scanner) _____________ COM Port involved: COM1 _ COM2 _ COM3 _ COM4 _ Adapter Name: _________ File Size and Dates: COM.SYS _________ ___/___/___ VCOM.SYS _________ ___/___/___ *********************************************************************** ** MODE COMMAND SETTINGS ** *********************************************************************** Mode COMx parameter settings: BAUD = ____ PARITY = ____ DATABITS = __ STOPBITS = _ TO = ____ XON = ____ IDSR = ___ ODSR = ____ OCTS = ____ DTR = ____ RTS = ____ BUFFER = ____ *********************************************************************** ** DOS_SETTINGS FOR FAILING SESSION ** *********************************************************************** DOS SETTINGS: COM_HOLD = ___ IDLE_SENSITIVITY = ____ % COM_DIRECT_ACCESS = ____ COM_SELECT = ________ COM_RECEIVE_BUFFER_FLUSH = _______________________________________ *********************************************************************** ** CONFIG.SYS SETTINGS ** *********************************************************************** COM.SYS Parms (p#, Addr, IRQ, SI): (_ , ___ , __ , _ ) (_ , ___ , __ , _) PRIORITY_DISK_IO = ______ MAXWAIT = ___________ ═══ 12.4. TRAP & SYS31xx ERRORS ═══ ****************************************************************** ** Full Trap Form (System Halted) ** ****************************************************************** TRAP ____ ERRCD= ____ ERACC= ____ ERLIM= ________ EAX= ________ EBX= ________ ECX= ________ EDX= ________ ESI= ________ EDI= ________ EBP= ________ FLG= ________ CS:EIP= ____ : ________ CSACC= ____ CSLIM= ________ SS:ESP= ____ : ________ SSACC= ____ SSLIM= ________ DS= ____ DSACC= ____ DSLIM= ________ CR0= ________ ES= ____ ESACC= ____ ESLIM= ________ CR2= ________ FS= ____ FSACC= ____ FSLIM= ________ GS= ____ GSACC= ____ GSLIM= ________ THE SYSTEM DETECTED AN INTERNAL PROCESSING ERROR AT LOCATION ## ____ : ________ - ____ : ________ _____ , ____ ________ *** OS/2 VERSION 2 *** INTERNAL REVISION _ . ___ DATE: __/__/__ ***TRAP INFORMATION*** Please indicate the failure mode: OS/2: _ DOS: _ WIN_OS/2: _ ****************************************************************** ** SYS3175 and SYS3176 Error Form ** ****************************************************************** Please give complete message. You may submit a Print Screen in lieu of this form. _______________________________________________________________________ _______________________________________________________________________ ______________________________________________________________________ P1= ________ P2= ________ P3= ________ P4= ________ EAX= ________ EBX= ________ ECX= ________ EDX= ________ ESI= ________ EDI= ________ DS= ____ DSACC= ____ DSLIM= ________ ES= ____ ESACC= ____ ESLIM= ________ FS= ____ FSACC= ____ FSLIM= ________ GS= ____ GSACC= ____ GSLIM= ________ CS:EIP= ____ : ________ CSACC= ____ CSLIM= ________ SS:ESP= ____ : ________ SSACC= ____ SSLIM= ________ EBP= ________ FLG= ________ ═══ ═══ Requires System Level XR06055 or OS/2 2.1. ═══ ═══ Requires OS/2 2.1 or XR06100 ═══ ═══ The DOS_DEVICE (COMDD.SYS) may not be the only one required depending on the application. (For example, Intel's SatisFAXion board requires a device driver loaded into each VDM which will use that adapter). The COMDD.SYS driver is usually required only for older DOS communication applications. Do not use COMDD.SYS for EVERY DOS communication session; use it only if it resolves the problem. ═══ ═══ Use the OS/2 SYSLEVEL command to determine which level of the operating system is executing. The Base Operating System Level is located on the SYSLEVEL.OS2 line. A current CSD level of XR02000 indicates that this is OS/2 2.0 General availability (GA) which was released in April, 1992. ═══ ═══ Use the OS/2 SYSLEVEL command to determine which level of the operating system is executing. The Base Operating System Level is located on the SYSLEVEL.OS2 line. A current CSD level of XR06055 indicates that this is OS/2 2.0 General availability (GA) plus the Service Pack which was released in October, 1992. ═══ ═══ Use the OS/2 SYSLEVEL command to determine which level of the operating system is executing. The Base Operating System Level is located on the SYSLEVEL.OS2 line. A current CSD level of XR06100 indicates that this is the second Service Pack for OS/2 2.0 which was released in September, 1993. ═══ ═══ Use the OS/2 SYSLEVEL command to determine which level of the operating system is executing. The Base Operating System Level is located on the SYSLEVEL.OS2 line. A current CSD level of XR02010 indicates that this is OS/2 2.1 General availability (GA) which was released in June, 1993. ═══ ═══ Use the OS/2 SYSLEVEL command to determine which level of the operating system is executing. The Base Operating System Level is located on the SYSLEVEL.OS2 line. A current CSD level of XR09999 indicates that this is a future release for OS/2 2.x due MMMM, YYYY.