Surviving with OS/2 Warp in a sea of Wiindows

This article may be republished in its entirety or partially as long as Robert "RokNroB" Thomas is given credit somewhere in the republished material along with my email address of roknrob@flash.net

Introduction

1.0 Introduction

It's not very easy to run Warp when surrounded by Windows, particularly if your network is based on NT server and your peer's predominately also use Windows. Network administrators are quick to say "We don't support OS/2!". Peer's are unable to offer any advice. Your only reliable source is IBM, or if you're lucky, there's someone around that uses Warp also. Predominantly, Warp users turn to the Internet for guidance, and solutions to their problems. It can be frustrating, but if you look hard enough, you can solve most of the issues involving being compatible with Windows.

The issues range from Network Operating Systems and network protocols to data file formats. These issues alone require herculean efforts for the average user. Even to the experienced OS/2 Power user, these problems can be difficult. Hopefully, this document will solve some of the issues for an OS/2 user lost in a sea of Windows.

Networking
2.0 Introduction

OS/2 Warp has very excellent support for other networking operating systems (NOS) besides IBM LAN Server (or Warp Server), such as Novell and Banyan. Warp also supports a number of networking protocols. TCP/IP is the most popular these days, but Warp has NetBios (NetBEUI), NetBios over TCP/IP (TCPBEUI), IBM IEEE 802.2, Netware and Banyan. The most important feature of all this networking support is that the requester's execute concurrently. Meaning that you can run them all at the same time!

In the present OS/2 Warp architecture, IBM refers to this networking support as Multi-Protocol Transport Services. The support is provided by drivers called requester's. The requester's are specified in the config.sys file and loaded at boot. Network communication is provided to and from the requester's and protocol's using NDIS (Network Driver Interface Specification). OS/2 Warp version 4 and OS/2 Warp Connect ship with these requesters: IBM LAN, 3270 Emulation, Netware, IBM TCP/IP. These requester's also have their associated protocol drivers as described previously (TCP/IP, 802.2, etc.). Banyan supports networking in native OS/2 as well as DOS VDM's and WinOS2.

The installation of MPTS will install a copy of the online book "Network Adapters and Protocol Service Guide". This book is located in the Assistance Folder inside the Information folder under Tasks. This book traverse's OS/2 Warp networking in detail.

2.1 Warp Connect vs. Warp 4.0

OS/2 Warp Connect has separate requester's for LAN Server and Peer. Warp Connect will only allow either the LAN Server requester or the Peer requester to be installed. This is because they both share the same file name and directory structure.

OS/2 Warp 4 combines the LAN Server requester and the Peer requester into one requester. Warp 4 also shipped with DHCP, whereas Warp Connect had this software added via a fixpack. Warp 4 TCP/IP stack is newer than Warp Connect's. However, fixpacks will bring Warp Connect's TCP/IP stack to par with Warp 4.
As a final note, some users claim that Connect's Peer client is superior to Warp 4's. However, I have seen no evidence or documentation to support these claims.

Networking Interoperability: Windows
3.0 Introduction

This passage will help you set up the OS/2 Warp client to be compatible with Windows. Microsoft has changed little tidbits of LAN Manager operating characteristics with the release of NT 4.0 and Win95. Some of the default settings shipped with these products can and will cause confusion and frustration for the OS/2 user.

You will need to install IBM Peer for OS/2 to interoperate with a Microsoft Network. The OS/2 Warp client is very easy to setup to interoperate with a Microsoft Network if you know the tricks involved. OS/2 Warp 4 will install the "File and Print Client Guide" when Peer is installed which incorporates a brief section on interoperability with Microsoft Networks. Literature is spread throughout IBM, some docs at PSP, some at Raleigh, some here and there on the net.

The three protocols generally needed to interoperate with Microsoft Network's are TCP/IP, NetBios, and NetBios over TCP/IP. The NetBios protocol is used locally on a subnet because it contains no routing information. This also means that NetBios cannot see past a router without help. NetBios over TCP/IP can see past a router and this protocol is generally used at corporate sites where large segmented networks are the norm as shown in figure 1.

Figure 1

3.1 Windows NT

Microsoft has strayed once again from networking standards in their proprietary implementation of domain registration. What does this hack on networking standards mean to an OS/2 user? It means that OS/2 Warp clients cannot logon to NT domains through a router. This also will cause problems for products from other vendors as well. Microsoft has a long way to go before they are an Enterprise NOS.

Despite Microsoft efforts to keep Warp off an NT server, an OS/2 Warp client can take advantage of Microsoft Network in one of two ways. The Warp client can logon to the NT domain or logon locally. However, browsing is severely limited on a Microsoft Network if the servers have been configured with the default settings (more on this in a later section). Either method will achieve the desired results, to use the resources on a Windows NT server domain. One precaution, your local OS/2 Warp logon must exactly match the logon ID on the NT domain controller. In addition, NT server allows lower case in passwords whereas Warp does not.

In a segmented network architecture where the OS/2 Warp client is separated from the NT server via a router, NT domain authentication is impossible with the default configuration of the Warp client. IBM has described this issue in Technical Document #7775533. IBM Technical Document #3724433 describes some useful NT administrator tips. In order for the Warp client to be authenticated by the NT domain controller the IP address will have to be added to the RFCBCST.LST file. Other NT resources would be added to the RFCNAMES.LST file. These files may be updated using MPTS or a text editor may be used. After the RFC files have been modified, the RFCADDR command can be run from an OS/2 window which will update the system and prevent the client from having to be restarted.

3.1.1 Windows NT: WINS

WINS (Windows Internet Name Service) is a proprietary implementation of a Domain Name Server and a NetBios Name Server (NBNS). This hack gives the appearance that WINS is a Dynamic Domain Name Server. However, since WINS in not really a DDNS, other network operating systems that are compliant with a DDNS will not operate properly. The other function of WINS is to provide NetBios computer name registration. Combined with the DHCP server option which passes out IP addresses, WINS will update the database with pointers to the DNS (this is the hack).

OS/2 Warp clients can take advantage of the NT WINS NetBios Name Server. Your administrator or another peer can give you the IP address of the primary and backup WINS servers. If you are you using DHCP you can request these IP addresses and view them from the DHCP Monitor program. If the Warp client is separated from the WINS server via a router, the NetBios over TCP/IP protocol is a must. Also the node type should be set to "H-NODE" when operating in a segmented network. Due to the implementation of DHCP in OS/2 Warp you will have to manually edit the protocol.ini and add the WINS IP addresses into the TCPBEUI section as follows:

[TCPBEUI_nif]
DriverName = tcpbeui$
Bindings = PCNTND_nif
NODETYPE = "H-Node"
NBNSADDR = "XXX.XXX.XXX.XXX"
NBNSBACKADDR = "XXX.XXX.XXX.XXX"
OS2TRACEMASK = 0x0
SESSIONS = 130

You will have to add the text "NBNSADDR=", and where the X's are, you would put the IP address of the WINS server. NBNSBACKADDR is the backup WINS server.

The following are some useful DHCP options provided by the Microsoft DHCP server. These are the only options supported by Windows based DHCP clients (lease options 51,58 and 59 not included in Table 1).

Opt   Option Name   Description
1   Subnet Mask   Defines subnet mask for the client.
3   Router        Defines default router IP address (gateway).
6   DNS Servers   Defines IP addresses of the domain name servers.
15   Domain Name   Defines domain name for the client.
44   WINS/NBNS     Defines IP address of the NetBios Name Servers.
46   WINS/NBT      Node type: 1=B node, 2=P node, 4=M node, 8=H node
47   NetBios scope ID Defines text string for NetBios over TCP/IP scope ID.

Table 1

3.1.2 Windows: Browsing

OS/2 clients are unable to browse available resources on Microsoft Networks due to a LAN Manager parameter called lmannounce. This parameter defines the response to LAN Manager 2.x browser broadcasts. The default response is to ignore these broadcasts. However, the net view command can show resources when the resource is specified as follows: "net view \\resource". If the command "net view" is used, nothing will show except your workstation or other OS/2 Servers/Workstations on your network. The Window's servers and workstations will have to have their default settings changed as outlined below to enable browsing from OS/2.

Windows for Work Groups:

Add the parameter "lmannounce=yes" in the [network] section of the system.ini file.

Windows 95:

The parameter "LMAnnounce" is in located in Network settings under File and Print sharing properties.

Windows NT 4.0 Server:

In Network settings, Services, Server, select the Make Browser Broadcasts to LAN Manager 2.x clients at the bottom of the dialog page.

Windows NT Workstation:

Users will have to manually modify the Lmannounce entry in the registry. The entry is as follows:
\HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\LanmanServer\Parameters
This setting will have to be changed from the default of 0 to 1. The regedt32.exe program will have to be used for the above procedure. Regedt32.exe is located in \WINNT\SYSTEM32.

3.2 Banyan Vines

Banyan Vines support is installed using a Banyan provided install program called VCLIENT. Vclient will also modify your config.sys heavily. Do not run VCLIENT until you have installed your network adapter using MPTS and other networking protocols.

If you are using OS/2 Warp 4.0 you will need a fixpack from Banyan. This fixpack consists of two files, VINES2-5.IFS and VINES2-6.IFS. Depending on what version of Banyan Vines server that your network is running will determine what file to use. VINES2-5 is for Vines version 5.x and VINES2-6 if for Vines version 6.x. You will need to install one of these files before rebooting OS/2 after installation of Vines. Your machine will trap on every boot until you install the needed file into the Vines subdirectory.

The following is a real handy feature to get access to files for different OS's from the Banyan server. You can map your server (Z:\) drive in DOS, OS/2 or Win95/NT by using the setdrive command. By mapping the server drive to root will provide a hint to what OS's the server is setup to provide client connectivity with. Use the following procedure to accomplish this:

1. Use the whatz command to find your Banyan server.
2. Use the setdrive command, setdrive x: "blah@blah@myserver" /ROOT

This new drive mapping should contain several sub-directories such as OS/2, DOS and WIN32. You can also build vclient disks for OS/2 or copy files needed for DOS VDM's and WinOS2.

This is what the Banyan install program VCLIENT will do to your config.sys:

REM >THE NEXT FEW LINES LOAD VINES NETWORK SOFTWARE IN
REM >REQUIRED ORDER, SET AT INSTALLATION TIME. DON'T EDIT
REM >OR MOVE ANY LINE WITHOUT SPECIFIC VINES INSTRUCTION.
REM >ALSO, DON'T REMOVE "Z:\" FROM YOUR SET PATH= LINE;C:\office31
REM >OR "C:\vines-directory\DLL" FROM YOUR LIBPATH= LINE.;C:\office31
SET VINESDIR=D:\OS2\VINES
IFS=D:\OS2\VINES\VINES2.IFS
DEVICE=D:\OS2\VINES\BANCOMM2.SYS/SOCKETS=60/SPP_CONNECTIONS=60/KBYTES_COMMBUFFERS=96
DEVICE=D:\OS2\VINES\VBAN.SYS /INT=63
DEVICE=D:\OS2\VINES\INNS.SYS
IFS=D:\OS2\VINES\VINESNP2.IFS
DEVICE=D:\OS2\VINES\drivers\bn_NDIS\NDISBAN2.SYS
REM >END OF VINES SOFTWARE INFORMATION.

3.2.1 Banyan Vines: OS/2 DOS VDM Support

To get Banyan Vines support in DOS VDM's , add this statement to your autoexec.bat:

C:\VINES\BANSVC.COM
This program provides the Vines interface from a DOS VDM and WinOS2 to OS/2.

3.2.2 Banyan Vines: WinOS2 Support

WinOS2 will also run Banyan Vines. You will have to modify this statement in your system.ini file:

[boot]
.
.
network.drv=d:\os2\mdos\winos2\system\vines.drv
.
.

If you plan on using a Windows based mail program with Banyan, you will need some MS-DOS files. These files are usually the DLL's that contain the interface to Vines. I know of a mail application that runs in Windows and that is LSMAIL or SharkMail. You can get these files (DLL's) by using the setdrive command to map your Banyan server with the /ROOT option as described previously.

3.3 Samba
Jacco de Leeuw has created a fantastic web page containing information on how to setup and get connected using Samba.

3.4 Peer in Win-OS/2
OS/2 is able to provide Peer services in Win-OS/2. By enabling IBM Peer for OS/2 in Win-OS/2, you can connect to network resources in File Manager. In general, this makes Win-OS/2 network aware. However, two files are needed from the IBM Dos LAN Requestor services. These are NETAPI.DLL and PMSPL.DLL. If you have OS/2 Warp Server, the files are located on the CD under CID\CLIENT\DLS.

Installation is easy and painless. Start Win-OS/2, open Win-OS/2 Setup from the Main Window, select Options, then select Change system settings, select IBM Peer for OS/2, then select OK. Win-OS/2 Setup will prompt for the Windows diskettes it needs (Insert your OS/2 Warp CD into the CD drive and point the location to \OS2IMAGE\DISK_W1, etc). The above mentioned files will need to handy also (NETAPI.DLL, PMSPL.DLL).

Although this is pretty cool (IBM has some great Software Engineer's), I've noticed a performance hit in my Win-OS/2 sessions with IBM Peer for OS/2 enabled in Win-OS/2. This is due to the setup program modifying the system.ini with some new parameters, PSP and timer variables. I removed these from the [386enh] section without any problems and my performance was on par again.

Microsoft Exchange 4.0

4.0 What is it?

Exchange is a Microsoft application that runs on a Windows server. Exchange provides e-mail and other services such as being able to setup meetings electronically. In order to use the Exchange service you must have the Exchange client installed or another client application that is compliant with the Exchange protocols.

4.1 Installation and Setup

The Exchange client's dwell on the Exchange Server CD. OS/2 will need the WIN16 version of the client since Microsoft only supports Windows platforms. The WIN16 client will execute under WinOS2. Also on this CD is the Forms Designer package which has the 16 bit version of the MS Visual Basic Compiler. The Exchange 4.0 client will require at least fixpack 2 from Microsoft for the Exchange 4.0 client to run properly under WinOS2. Microsoft is currently up to fixpack 4 for Exchange 4.0 and also states that only fixpack 2 is supported in WinOS2. OS/2 will also need to have TCP/IP and TCP/IP DOS support installed. Installation of the client is straight forward and hassle free. You will need information provided by your network administrator. This information will consist of the Exchange server name, and the name of your post office box. The install program will require that you reboot Windows after installation. After closing the WinOS2 session, use your favorite text editor and modify the file exchnge.ini. The file will be located in C:\OS2\MDOS\WINOS2. You will want to move the TCP/IP protocol statement in Rpc_Binding_Order to be the first protocol as shown below:

[Exchange Provider]
Rpc_Binding_Order=ncacn_ip_tcp,ncacn_np,ncacn_spx,netbios,ncacn_vns_spp

The Exchange client is now ready to be run.

TIP1: Some users of Exchange (WIN16) will notice that some of the messages they receive do not display well or get a warning message with attachments. This is due to missing fonts in Win-OS/2 and the Exchange client. You can remedy this by locating a Windows machine and copying the fonts. Most fontscan be found in C:\WINNT\Fonts. True Type fonts end with an extension of TTF. Copy the fonts to a temporary sub-directory and start Win-OS/2, openControl Panel, then open Fontsand goto Add. Point the to the sub-directory where you just copied the fonts and selectAllthen OK. That's it, your done!

TIP2:Choose the Aerial font for the Exchange client. MS Outlook defaults to this font and others will not know any difference. The default font in Exchange WIN16 is MS San Serif . This font does not display well for some reason in MS Outlook under Win95 and NT.

Microsoft Office

MS Office for Windows 3.1 runs without problems in WinOS2 and is compatible with Office 95. MS Office 97 is not compatible with either software package. However, there exists a file converter for Word 6 that will import Word 97 documents into Word 6. Also there is a patch for Word 97 that will allow saves to .DOC extensions instead of RTF (Rich Text Format). There are no other Office 97 converter's available for MS Office for Windows 3.1. Microsoft has released two new viewers for Windows 3.1, one for Word97 and one for PowerPoint. Microsoft has a page which lists all of the viewers and converters for MS Office.

This document was created and published with StarOffice 4.0 International Beta 1
This document was updated and published with Netscape Communicator/2 Beta 2