Networking for Home

From Wiki
Jump to: navigation, search

By Nicholas McGuigan

So! You have just bought your second PC and you have given your old one to the kids (or you're the kids!). You need to transfer files between the old and new systems. The kids want more disk space and access to the fancy printer you bought with the new system.

Yes, you are discovering the delights of a multi-system household that in this day and age can include laptops from work, spouse desktops and kids games/school machines. Businesses have been tackling this type of environment for a long time now with a tool called a Local Area Network or LAN for short. Why shouldn't you do the same?

No reason at all! Today, LAN hardware is cheap, reliable and readily available. With OS/2 Warp Connect, so is the software needed to drive it. With a LAN using these components, you can share disks and printers with other systems connected on the LAN using Peer for OS/2, you can transfer files directly between them using TCP/IP for OS/2, share clipboards and DDE sessions and do personal conferencing with Person to Person. All this and more can be accomplished with just OS/2 Warp Connect and nothing more to pay.

This article looks at how you would go about implementing a LAN in your home using the capabilities of OS/2 Warp Connect. I will mostly be concentrating on stuff you can do without having to buy anything extra. However, occasionally I will show how you can build on the base infrastructure with additional components.

Concepts and Terminology

If you are knowledgeable about Local Area Networks and the like, you can probably skip this section. It is mostly designed to level set readers who haven't had much to do with them by introducing them to various basic concepts and terminology.

Firstly, the "home network" we are talking about is a Local Area Network (LAN). So what is a LAN? Very simply, a LAN is a communications network in the form of a piece of wire that runs around the area connecting up all the PCs that need to talk to each other.

It is called a Local Area Network as it generally connects up small areas such as the rooms in your dwelling, small offices, corporate departments and so on. Connecting up dispersed locations, for example an office in Melbourne to one in Detroit, requires a different type of network called a Wide Area Network (WAN).

The shape the LAN wire takes is called its topology and the way the signals that flow across it are formatted is called its communications protocol. There are two common protocols:

The Ethernet communications protocol uses a straight section of wire called a bus with special terminators at each end. Multiple buses can be connected together to form larger networks. Newer forms of Ethernet, 10BaseT for example, are implemented using a central hub and look like star wired networks. However, inside they resolve down to a bus like the other forms.
Connected into the bus are the PCs that need to communicate using the LAN. These compete for use of the LAN by trying to transmit and then listening to see if they were successful. For more details, see Ethernet LANs.
Token Ring
The Token Ring communications protocol uses a ring topology with the wire in the form of a loop. The loop is actually implemented in a central hub called an MSAU or MAU or, more lately, CAU with LAMs. The PCs are connected via wires that plug into the hub giving it a star wired appearance.
Access to the LAN is controlled by a token that is passed from PC to PC. The way this is done ensures that each PC gets a fair share of the LAN and enables high LAN utilisations are achieved. For more details, see Token Ring LANs.

To be part of a LAN, each PC must have a LAN Adapter card installed and this must be attached to the LAN, usually by a piece of cable.

It must be emphasized that a LAN is not owned by any of the applications that run over it. There is no such thing as a Novell NetWare LAN or a Windows LAN. Each and every LAN enabled application can run side by side and independently of every other LAN enabled application. Thus you can have NetBIOS, IEEE802.2, IPX, SNA LU6.2, TCP/IP and other conversations all taking place simultaneously. The one thing that does characterise a LAN is its topology and fundamental LAN communications protocol, that is whether it is Ethernet or Token Ring.

The next piece of the puzzle is the PCs that attach to the LAN. I will often refer to these as Personal Workstations or just Workstations. Such a workstation can operate in either of two roles, a client which uses the resources that other workstations own and share and a server workstation which does the owning and sharing.

In the LANs created in corporations, these roles are usually quite distinct with special workstations being setup in groups as servers and with all other workstations operating as clients. The clients generally have human operators whereas the servers are locked away somewhere and operate unattended.

In general, the set of workstations operating together on a LAN may be quite heterogeneous. For example, we could quite easily encounter Windows, OS/2 and Apple clients all operating together. This can also be the case at home. For example, I am very happy with OS/2 and have designed my LAN around its use. However, my children are attending schools that insist on Apples.

You may expect a future article on how I dealt with this problem but for the rest of this one, I will assume for simplicity we are talking OS/2 Warp Connect workstations. As Warp Connect shares a common protocol, namely Server Message Block (SMB), with Windows for Workgroups, Windows NT, IBM LAN Server and some others, most of the stuff we talk about can be very simply extended to Windows family clients.

The LAN with its LAN communications protocols, Ethernet and Token Ring, provides the basic connectivity between the individual workstations. If you like, it is the road network connecting the various sites. However for it to be useful, it must be used for something. In other words, someone must drive trucks and cars across it. Those someones, or somethings in this case, are applications and the trucks and cars are the higher level communications protocols such as NetBIOS and TCP/IP.

NetBIOS is a relatively simple protocol that enables two LAN-attached workstations to communicate by passing messages. The workstations must be attached to the LAN as NetBIOS doesn't operate over a WAN. NetBIOS is used as a base for a lot of LAN traffic such as Disk and Printer Servers and so on.

TCP/IP is a communications protocol that can be used to connect workstations in both a LAN and WAN environment. It has a higher overhead than NetBIOS but has more general purpose functionality defined for it including additional protocols such as File Transfer Protocol (FTP), Telnet and the mechanism you are probably using to view this document now, Hypertext Transfer Protocol (HTTP).

When setting up our home network, we will configure both NetBIOS and TCP/IP for our use. However, there are a number of other protocols that are commonly found in a LAN environment. These are:

This was supposed to supersede the defacto standard NetBIOS as a standard protocol to connect Ethernet or Token Ring attached workstations over a LAN. In practice, it is used for some 3270 Emulators and not much else that I can see.
This is an efficient and highly reliable communications protocol used much in the "big iron" shops where these characteristics are valued. Like TCP/IP, is can be used to connect workstations across LAN and WAN environments.
This protocol is used by Novell NetWare clients and servers and not much else. In pure NetWare only environments, it is an asset. In the more common mixed environments, it is a problem to be solved.

We briefly discussed the concepts of client workstations and server workstations above. A server workstation is one which owns resources that it subsequently makes available to or shares with client workstations who are the users or consumers of those shared resources. There are numerous different types of servers that can be set up including:

  • Disk
  • Print
  • Application
  • Web
  • Communications
  • Database
  • Security
  • Directory
  • Systems Management
  • Lotus Notes

And lots more. In the course of this article, we will be discussing Disk and Print servers in depth and Communications and Web servers in passing.

Servers are usually implemented by a piece of code (program) that manages the shared resource and provides access to it via the selected communications mechanisms. Client workstations usually have a corresponding piece of partner code, often called the client or requester, which is used to access the resources managed by the server.

We discussed earlier how it was common practice to have a set of workstations performing the role of server and the remainder performing the role of client. In a lot of corporate environments, these roles are fixed. However, there is an alternative type of networking, called peer networking, where each workstation can take on the role of pure server or pure client or both at the same time. OS/2 Warp Connect provides a function called IBM Peer for OS/2 Warp which enables this type of networking and this is what we will be using to set up our home network.

Normally, when setting up your own home LAN, there is quite a bit of software to assemble to do it all. Add to this that if you want to do it in a Microsoft Windows environment, you will have to be an expert in DOS memory management and other esoteric concerns. However, with OS/2 Warp Connect, all the pieces of the puzzle are in one package. You get the wherewithal to access the LAN using NetBIOS, TCP/IP, IEEE802.2 and IPX, to set up disk, printer and communications (COM port) servers, transfer files about (FTP), use each other's workstations (Telnet), perform remote management (Telnet, FTP), conference (P2P) and much more without shelling out a brass razzoo extra and without having to worry about Upper Memory Blocks (UMB) and the like. To fill you in on the details, the next section will do a review of what's in OS/2 Warp Connect.

Warp Connect Overview

For those of you that haven't met OS/2 Warp Connect, this section will briefly review what is in it and how it relates to its siblings, IBM OS/2 Warp for Windows (a.k.a. Warp Red Spine/Box) and IBM OS/2 Warp with WINOS2 (a.k.a. Warp Blue Spine/Box).

In essence, OS/2 Warp Connect is the same OS/2 Warp we know and love together with an additional set of client connectivity options for use in a networked environment. As with original Warp packages, there are two versions, one for a native Windows environment and one with WINOS2 and, yes, I believe they have red and blue spines although I haven't personally laid eyes on the former. The BonusPak remains unchanged.

So what are the connection options provided and how do these position Warp Connect in the market? The following options are provided as part of the Warp Connect package:

  • Multiprotocol Transport Services (MPTS)
  • TCP/IP for OS/2
  • LAN Server Requester or Peer for OS/2
  • Netware Client for OS/2
  • LAN Distance Remote
  • Lotus Notes Express

These are described in more detail in the next sections along with the following topics:

  • Installation
  • BonusPak Contributions

Multiprotocol Transport Services (MPTS)

Multiprotocol Transport Services (MPTS) is an implementation of the Multiprotocol Transport Network (MPTN) architecture. It provides support for protocols such as NetBIOS, TCP/IP and IEEE 802.2 over a variety of media such as Ethernet and Token Ring local area networks (LAN).

In addition, MPTS implements a software layer called Common Transport Semantics (CTS). This is a framework that supports a mix-and-match approach to protocols and the application programming interfaces (API) used to drive them. For example, using the MPTS supplied with Warp Connect you can run NetBIOS over TCP/IP and can add additional products to run Sockets over SNA and LU6.2 over TCP/IP.

If you didn't quite get all of that, don't worry. It has very little to do with home networking. From our home LAN perspective, MPTS and the various protocol and MAC drivers that are part of it are just the software glue that attaches our workstation to the LAN.

TCP/IP for OS/2

Warp Connect has a full version of TCP/IP which supports both SLIP and PPP dial up connections and LAN connections and can do so simultaneously.

You may be familiar with the BonusPak IBM Internet Access Kit (IAK). This was implemented on IBM TCP/IP for OS/2 (Version 2) which had been stripped down to restrict it to dial (SLIP, PPP) connections only. The new kit not only removes the restrictions but is a new version as well.

You should note that the original IAK is available still on the BonusPak as before. If you install the full TCP/IP implementation as part of the Warp Connect install, you should not install the BonusPak IAK. All the familiar IAK tools are installed as part of the full product anyway.

LAN Server Requester or Peer for OS/2

Both of these products are provided but you can only install one. For home networking in particular and for most business applications, I recommend the OS/2 Peer product.

So what are these things. Both provide a client requester function, sometimes called a redirector, to servers that communicate using a protocol called Server Message Block (SMB) over NetBIOS and, more lately, TCP/IP. Servers of this type include IBM LAN Server and Microsoft NT Advanced Server.

Using the requester function, we can make drives, directories and printers accessible on our own system. For example, one of the servers shares a directory and we can make it look like a drive, called a network drive, on our system and then use it like we would any other drive. There are a number or trifling details like security and access permissions that interfere with this vision of paradise but I will deal with them later.

In addition to the requester function, both products provide a peer function and it is here we can differentiate the two. The peer function enables the normally client code to function as a server, albeit in a more limited sense. In other words, I can decide to share directories and printers with authorised users without having to install a full function server package. Clipboard and DDE sharing is also supported.

The LAN Server Requester product is quite limited in its implementation of peer services. It can only support one user of a shared resources and its user interface for sharing is quite limited. Peer for OS/2 is more more of a proposition. It really implements a mini-server with a simple and attractive user interface and features complete integration with the Workplace Shell. Multiple remote users are simultaneously supported.

Netware Client for OS/2

This is much the same sort of deal as the LAN Server Requester but for Novell NetWare servers instead. This is good news if you have a Novell server but they are a bit rich for home use so I will dwell no more upon it.

LAN Distance Remote

The good news is LAN Distance provides you with a way of extending your LAN across the telephone network. Thus if you have a mobile system, you can dial your LAN and effectively become part of it remotely, using all the same stuff you use when connected locally.

The bad news is that LAN Distance Remote is the client piece that can connect your workstation to the LAN. You need the server piece, LAN Distance Connection Server, to catch the Remote call and make you part of the network.

For the most part, I want to stick to talking about stuff that you can do right out of the Warp Connect box. However for this category, I will talk about the whole LAN Distance setup in Remote Access because of the powerful additional dimensions it opens for us.

Lotus Notes Express

With some copies of OS/2 Warp Connect, a "Lite" version of the Lotus Notes client, called Lotus Notes Express is included as a promotion.

Although a Notes setup can greatly increase the function available in a home LAN, it does require additional software to implement a Notes Server and a level of skill and planning beyond what is required for the rest of functions described in this article. Highly recommended if you have the skill, finances and energy but we won't be covering it here.


On top of all the features and functions we have described above, Warp Connect has a very nice installation process which takes the hassle (some would say fun) out of installing all this stuff.

The familiar plain OS/2 Warp install is present as before. The install proceeds through the initial character based phase to the Presentation Manager phase. At the end of the standard install dialogs during the Presentation Manager phase, a new set of dialogs prompt for details of the desired communications environment. It is here you select which functions you want and how you want them to be configured. After that, just watch the blinking lights until the install is complete and your workstation has rebooted itself.

BonusPak Contributions

The BonusPak supplied with OS/2 Warp Connect is identical to that supplied with the other Warp siblings. The only major change is under Warp Connect you would not normally install the Internet Access Kit as this function, much expanded, is provided by the TCP/IP Version 3.0 installed as part of the base.

As you would know if you have used OS/2 Warp before, the BonusPak is stuffed full of nice to have goodies. However, there is one feature included that can significantly add value to our home LAN, IBM Person to Person, the IBM personal conferencing system.

Person to Person (P2P) provides a number of functions that enable a group of up to eight (8) users to share information in the following ways:

  • Exchange messages
  • Share and annotate information
  • Share clipboards
  • Video conference

NetBIOS and TCP/IP connections are supported as well as POTS phone links, ISDN, SNA and so on. Personal conferencing and its implementation on your home LAN is covered in Personal Conferencing in this article.

Getting Wired

In this section, we will look briefly, very briefly, at the physical wiring required to implement our home LAN. Essentially, this boils down to a choice of two LAN types, Token Ring and Ethernet. We will look at what these are and what the implications are when wiring up a home LAN in the following sections:

  • Token Ring LANs
  • Ethernet LANs
  • Making a Choice

Token Ring LANs

NetWired01.jpg Although sometimes the actual wiring doesn't appear like one, this is a loop of wire to which the participating workstations are connected. Use of the wire is very orderly, being controlled by a token which is passed from system to system.

The token is a short empty message. When it arrives at your workstation and is free, you may attach a message to be sent to another workstation on the LAN. The token is now no longer free and each participating workstation just passes the message on until it reaches the target workstation.

The target reads the message and then passes it on again but with a received flag set on. Again the token is passed around until it reaches the original sender who now generates a free token which is passed on to the next workstation in the ring. Using the token ring protocol, which is defined in IEEE 802.5, every workstation gets a chance in turn to use the LAN leading to predictable performance and high utilisation (up to 80%).

To implement a token ring LAN, each machine must have a token ring LAN adapter. The actual token ring is implemented in a hub. There are various types of hub ranging from the simple unpowered IBM 8228 Multistation Access Unit (MSAU) to some very fancy powered stuff with network management and a price tag to match.

The workstation adapters are connected to the hubs by wire of varying types, for example Unshielded Twisted Pair (UTP) or Shielded Twisted Pair (STP), depending on the type of hub used. Hubs may be strung together to make a big single ring and multiple rings may be bridged together to make larger structures.

Ethernet LANs

NetWired02.jpg An Ethernet LAN is actually a type of shared bus although again the physical wiring can hide this. The protocol by which the participating workstations gain access to this bus is called Carrier Sense Multiple Access/Collision Detect (CSMA/CD).

CSMA/CD is quite different from the orderly sharing scheme of token ring LANs. The workstations compete for access by first listening to see if anyone is transmitting. If the LAN is occupied, they wait a bit and try again. When the LAN is free, the workstation transmits its message which it simultaneously reads back again. By checking the received message with the transmitted message, the workstation can tell if someone transmitted at the same time, called a collision, and corrupted the message. If a collision occurs, each collider backs off a random amount of time and then tries again.

CSMA/CD is quite easy to implement and is very effective at low utilisations. However, over about 30% utilisation, a considerable proportion of the available bandwidth is tied up in collisions and retries which has a major impact on throughput.

As with token ring, each participating machine must have an Ethernet LAN adapter in it. Unlike token ring, a hub is not necessarily required. The simplest form of Ethernet LAN is a straight piece of wire terminated at both ends. The wire runs through connectors in the back of the LAN adapters. Other Ethernet types, for example 10baseT, utilise hubs.

Making a Choice

So what does all that mean. For the home user, virtually nothing. It is unlikely that load and throughput considerations will drive the LAN type decision in the home so other factors, mainly price, will be much more important.

In the price department Ethernet is considerably cheaper than token ring. Adapters are generally very cheap. For example, $75 Australian should get you something quite serviceable and there are cheaper ones out there. The straight wire version of Ethernet using thin Ethernet wiring is the scheme I would recommend for the same price reasons. Hubs are expensive and should be avoided in home implementations unless you have a large extended family with lots of machines and a pressing need for improved system management.

That said, the question remains as to why you might choose token ring. I must confess I have a token ring setup. My decision was driven by the fact that my company uses token ring in the office and so the mobile I use, an IBM Thinkpad 755CE, comes with a PCMCIA token ring card. My choice was to go Ethernet and have to obtain a PCMCIA Ethernet card or to stay token ring and buy a ISA bus token ring card for my designated server and a hub.

I chose the latter course as I was able to obtain a good deal on a hub and and a LAN adapter. Together these came in as less dollars than a PCMCIA Ethernet adapter which is a bit more pricey than the cheapies I mentioned above. It also saved me the hassle of swapping from token ring to Ethernet every time I moved from office to home and vice versa.

In summary, my recommendation is to go for the Ethernet option avoiding hubs. Make sure you choose a set of Ethernet adapters supported by OS/2. Warp's support is fairly comprehensive but it doesn't hurt to check. Get some advice about wiring and stuff unless you're a wiz on that topic. Then wire up your home to the level that suits you. This can range from a wire along the back of your workbench up to a fancy set of wall mounted faceplates in each room holding a participating machine. My hub is balanced on top of a pile of bricks and the connecting wires trail along the back of the desk. It works for me!

Whatever decision you make, OS/2 Warp Connect will support either transparently to the applications that use the network. How this happens and what you need to do to set it up is covered in the next section.

Basic Setup

This section deals with the basic requirements for implementing the home LAN installation using Warp Connect. It covers what to install from the OS/2 Warp Connect package and configuring the basic communications components, the LAN connection using MPTS and the TCP/IP environment. It finishes with a summary of what you should have when these steps have been completed.

  • What to Install
  • Configuring the LAN Connection
  • Configuring TCP/IP
  • Configuring Peer for OS/2
  • Installation Summary

What to Install

We have had a general look at the contents of the OS/2 Warp Connect package in the Warp Connect Overview section. However, as we pointed out in that section, not all the features are suitable for use in a home LAN. These are the features I recommend you install for this environment:

IBM Peer for OS/2
This provides the mechanism for sharing and using shared resources such as disks and printers across the LAN.
This provides the communications support from transferring data between workstations and terminal access to the server if required.
IBM Person to Person
From the BonusPak, this provides the basis for personal conferencing around the LAN using either NetBIOS or TCP/IP.
IBM LAN Distance Remote (Optional)
Together with the additional IBM LAN Distance Connection Server, this provides the capability for remote dial in access to the home LAN. You should only install it if you plan on obtaining the connection server. See the Remote Access topic for more details.

Installation of all these except IBM Person to Person (P2P) is done during the main system installation procedure. P2P must be installed from the BonusPak CD in the normal way. The Multiprotocol Transport Services (MPTS) is installed automatically if you select any communications options.

During installation, you have the opportunity to specify what configuration details you require. The configuration information for the base communications products, MPTS, TCP/IP and Peer for OS/2 are covered in the next sections.

Configuring the LAN Connection

For our purposes, MPTS implements an NDIS compliant environment to support your LAN adapter and to provide simultaneous access to it from a variety of protocols. MPTS provides the environment, supporting software and the protocol stacks (drivers) for NetBIOS, IEEE802.2 and NetWare. The TCP/IP product provides an additional stack for TCP/IP.

You must provide a LAN card. If the card is known to Warp Connect, the installation process will select the appropriate driver. If not, you must supply an OS/2 NDIS compliant MAC driver for the card. You will be prompted for this during the install procedure.

Whether you use a known adapter or supply your own, you will be prompted to supply configuration information for the adapter. This information is fairly straightforward, for example interrupt level to be used, default ringspeed for token ring and so on.


Once the main installation is complete, you should have a working system. However, if you need to change it or just have an insatiable curiosity, you need to use the MPTS program. Two icons for this program can be found on the desktop with one of them being shadowed into the Network folder. Start it up, select Configure and then LAN Adapters and Protocols and you see a screen like the one shown here.

The top two boxes enable you to select an adapter (left) and then assign protocols to be used with it (right). The result is shown in the bottom box as an adapter entry with a series of assigned protocols indented underneath. Multiple adapters can be defined in this way with the same or different sets of supported protocols. Double clicking on any line, adapter or protocol, or selecting them and pressing the Edit pushbutton enables you to specify or modify various settings.

Once complete, pressing the Ok pushbutton rebuilds a file called PROTOCOL.INI which is used to initialise the LAN setup at boot time. If you change anything, you must reboot to effect the changes.

Now the OS/2 Warp Connect installation does a pretty good job at setting up the LAN environment so what are you likely to end up changing in the setup? Generally, the only thing I find it necessary to tune up a bit is the NetBIOS Sessions, Commands and Names. These can be changed by double clicking on the NetBIOS protocol entry for the adapter.

The file LANTRAN.LOG is created during the boot and contains a message saying how many sessions, commands and names are available after the Peer for OS/2 has taken its allocation (see Configuring Peer for OS/2 for more details) so use this to juggle the figures if you are having NetBIOS connection failures due to insufficient resources.

Configuring TCP/IP

The main details of the TCP/IP configuration are dealt with during the system installation. You will be asked to supply the following information:

  • IP Address
  • Subnet Mask
  • Host Name
  • Domain Name

To be a TCP/IP host, you must have an IP address. Most of the other paraphernalia of an IP network, Routers and Domain Name Servers, aren't applicable to the home environment and should be left blank on the prompt dialogs.

What IP address should you use? Generally, your home system will be separate from any other network so you can pretty well make your own IP address up. If you are connected to another network, you will need a router and an allocated IP address. In this case, contact the administrators of the other network and ask their advice.

Without belabouring the details, an IP address is a set of four numbers separated by dots. Each of the numbers can range from 0 to 255, that is the range of an 8 bit number. For example, is my IP address allocated to me by my company. For your private home scheme, I recommend you take a scheme like and vary the xxx piece from 1 to 255 with each of your home systems getting a unique number.

Another piece of arcana you will be required to specify is the Subnet Mask. If you use the scheme suggested above, a Subnet Mask of should be used. If you use a scheme of your own, you know enough to decide on your own subnet mask.

The host name is a plain text name by which your machine is known throughout the TCP/IP network. (Note: a TCP/IP network is called an internet. The Internet is just a network of internets that is publicly accessible.) For example, the system I am writing this on has a host name of nicholas.

A domain name is a sequence of plain text names separated by dots. Each plain text name represents a domain under the control of a specific administering authority. For example, is the domain name of the system being used to write this. Strictly speaking you don't need much of a domain name for the home environment but a scheme such as familyname.home is suggested.

If you move a mobile between work and the home, you may want to have the home environment's setup look like the work environment. Thus you could have the same IP number, subnet mask, host name and domain name. This would enable to avoid fiddling with the configuration each time you move the mobile.

Moving mobiles is a bit of a pain in IP networks as your IP address is tied to routers which don't move. One solution to this problem is a protocol that enables machines to be allocated an IP address dynamically. IBM OS/2 Warp Server has such a capability built in for example. However, these are a bit beyond the scope of our home LANs.

The main system install is complete as far as the definitions required for the local system. However, you will need to modify the configuration to add the names of your other systems. In a larger environment, for example at work, this would be taken care of by a Domain Name Server (DNS). This is a piece of code that takes a host and domain name and returns the corresponding IP address for that host. In the case of our home LAN where there is no DNS capability, we must specify the names of each host in the network together with its IP address.

Specifying these additional pieces of information is done using the TCP/IP Configuration program found in the TCP/IP folder on the desktop. You can do all the configuration by fiddling with text files in the %ETC% directory, usually C:\MPTN\ETC. However, the configuration utility is easier to get going with.

Start the utility by opening the icon (double click). A notebook will be displayed. Click on the various tabs to display the different configuration dialogs and make any changes you need to. Once the changes have been made, close the notebook (double click system menu) and reboot the system. The key tabs (right hand side of the notebook) are:

  • Network
  • Hostnames
  • Autostart
  • Security


If you picked right during the main install you probably won't need to mess about with this page. This is where the IP address and subnet mask for the host are specified.

If you add a second LAN adapter, you will need to make changes here as well. IP addresses are actually assigned by host and LAN adapter pair. Each adapter represents a different network as far as the host is concerned and must have a separate IP address. To set the new adapter details, click on the next adapter name, for example LAN interface 1, in the list box on the left and fill in the IP address and subnet mask on the right. Don't forget to enable the interface using the check box at the top.


There are two pages on this tab, the first contains the workstation's hostname and the local domain name. If the main install went ok, you probably don't need to change them but this is where you do if you need to. You can ignore the list boxes underneath in our simple home LAN environment.

The second page is where we specify the other hosts in our home LAN. To reach it, click the forward button at the bottom left of the first page. Using the Add, Change and Delete pushbuttons below the listbox, enter a list of IP addresses and host names for the machines on your home LAN. When finished, click on the checkbox just under list box. This will ensure this list is used to resolve host names.


This page is where you specify what TCP/IP services are to be automatically started when TCP/IP is initialised. What you specify here will be different depending on the role you have selected for the machine being installed. For a designated server, I would configure ftpd and telnetd to autostart. For other systems, you must decide how you want to work with these services. On my own system for example I have ftpd configured to autostart but not telnetd.

If you are going to autostart services, I recommend you use the inetd super server daemon. This starts the other services within the same OS/2 session and only when there is an incoming request for them. To configure, click on the inetd entry in the Services to autostart listbox and then check the Autostart service check box on the right.

If you are going to autostart telnetd, you should then click on the Foreground session radiobutton and check the Minimized checkbox. This is because the Telnet daemon runs as an OS/2 fullscreen session and the inet daemon cannot start such processes if it is running detached. If Telnet is not being autostarted, click the Detached radiobutton.

For both ftpd and telnetd, click the name in the Services to autostart listbox and then check the Autostart checkbox and the Inetd super server daemon radiobutton. If there any other services you would like to start, configure them in the same way.


This is where you specify a password for incoming Telnet users and userids and passwords for FTP users. For Telnet, just enter a suitable password. This ends up being added to the CONFIG.SYS as a SET statement as follows:


The upshot of this is if someone gets physical access to your system, they find out your Telnet password. Don't give anyone FTP access to your CONFIG.SYS or to your %ETC% directory.

To add FTP users, click on the FTP access protection listbox and use the Add pushbutton. We will talk more about the requirements here in the section Transferring Data.

Configuring Peer for OS/2

Peer for OS/2 is a NetBIOS application and draws resources from the pool of NetBIOS resources configured using MPTS as described above. It should not be necessary to modify the NetBIOS resources Peer requires or any of the other possible settings but if you need to, they are all found in the IBMLAN.INI file in the C:\IBMLAN directory.

The number of sessions, commands and names that Peer will use from the NetBIOS resource pool is specified in the NETx statements that are found near the top of the file in the section called [networks]. There is one for each LAN adapter so for our home LAN, NET1 is likely to be the only one present. The following figure shows what the values specified represent:


There is quite a lot of stuff specified in the IBMLAN.INI but the good news is it doesn't need to be changed for our environment. However, have a browse through it to get your bearings. Some of the comments make interesting reading. If you do decide to fiddle, make a copy of the original so you can get back to it easily.

The only thing that might need some attention occasionally is the Computername and Domain values. Computername is the NetBIOS name assigned to your machine on the network. Domain is the name of the Peer domain. Essentially, it is a name chosen to identify the group of machines that work together. Various commands use this name to identify other machines owning resources you may want to use. For our home LAN, I suggest a simple domain name such as HOME for your domain.

Both of these names are specified during the main install and, if you are happy with them, you don't need to change them. However, if you do, they are in the IBMLAN.INI at the bottom of the section marked [requester]. Changing the Domain name is relatively simple but if you change your machine name and others use resources on you machine, you should notify them to update their definitions as well.

Installation Summary

If all has gone well and you performed all the installation and configuration steps described in this section, you should have the following environment:

  • OS/2 Warp Operating System to give you your basic operating system environment.
  • Multiprotocol Transport Services to give you access to the LAN via your installed LAN adapter and which is configured to provide a set of NetBIOS resources and support the use of NetBIOS and IEEE802.5 across the LAN.
  • TCP/IP to provide a TCP/IP protocol stack to MPTS which supports the use of TCP/IP across the LAN. This also provides a familiar set of TCP/IP services such as FTP, Telnet, Talk, Finger, Ping and so on. As a by-product, the Internet Access Kit including the WebExplorer, Gopher, Newsreader/2 and Ultimail/2 Lite are all installed for use over the LAN and dial up connections. As usual, a dialer is provided.
  • Peer for OS/2 to provide the infrastructure for sharing files and printers on your machine with other users and for using files and printers shared by other users.

You may have chosen to install the LAN Distance Remote product as well. If so, review the section Remote Access for information about configuring and using this product.

The next few sections deal with how use this base to share resources and to transfer files and data about the place.

Resource Sharing Concepts

NetShareConcepts01.gif This section covers the sharing of resources on your newly created home LAN. The typical resources you might share are:


This is an obvious choice. Mum or Dad buys a new beaut but tres expensive printer for their essential business needs (yeah, right!) leaving little Johnnie and Joannie to face the most important years of their lives (school and such) struggling with a dot matrix printer that Noah abandoned when he took to the Ark. Now, thanks to the wonder and convenience of a home LAN, the new printer can be shared amongst all the needy users in the house. The shared printer looks like just any other printer on your desktop.


Sharing disk directories enables you to share disk space amongst the home LAN users. As in the printer case, this enables the latest large disk purchase to be used by all the family. However, there are some additional benefits as well. These include being able to share what is in the shared directory, for example files and programs, and being able to use shared disk to make copies of files from the client workstations for backup and archive purposes. Shared printers look like additional disk drives to the using (client) workstation.


Like directories, whole disks can be shared. This is most useful for sharing changeable media devices such a Compact Disk drives or diskette drives.

COM Ports

Communications ports can also be shared which leads, in some circumstances, to the sharing of modems and so on. I say in some circumstances because although the shared port on the using (client) workstation appears as a new COM port, there is no physical port present of course. Thus the application that uses the shared port on the client workstation must use it entirely through the virtual redirected port and not try to directly access the hardware.

Generally, the shared resource appears on the client workstation as a local resource. For example, shared printers appear as local printers and shared directories appear as local disks. When shared resources appear on the client workstation like this they are called network or redirected devices.

I have subdivided this section into the following parts:

  • Tools
  • Basic Mechanics
  • Controlling Access
  • Sharing Resources
  • Using Resources


Before we go any further, a quick word about the tools is in order. The basic mechanism for sharing on our home LAN is the OS/2 Peer that comes with OS/2 Warp Connect. This provides us with the ability to setup and use a network of peer workstations with some sharing resources and some using them.

The nice thing about a peer network is that anyone can share his or her local resources. Nothing special is required, for example special server code. That is already included in the peer code. Of course, for regularly shared resources a bit of planning and organisation will tend to put these on designated servers but that is just a matter of configuration not software installation.

There are several tools that enable use to work with the peer environment:


The peer environment provides us with a set of commands to enable us to set up resources, share them, control access to them, use them and so on. These commands have the general format:

NET function parameters...

Except for a couple of examples, we will generally not be talking much about commands. Their real strength is imbedded in REXX command files used to automate some of the LAN administration tasks. For more details, see the online reference in the OS/2 Peer folder.

Sharing and Connecting

This application is found in the OS/2 Peer folder. It is a Workplace Shell program that enables you to define various profiles for sharing your local resources, connecting to remote resources to use them and for controlling access to the resources you have shared.

LAN Resource Browser

This tool is part of the Network Aware Shell, a series of extensions to the Workplace Shell to facilitate a level of integration between the Workplace Shell capabilities and the resources located on the LAN. The browser may be found in the Network folder along with a shadow to the OS/2 Peer folder. The full name of the browser is LAN Server and OS/2 Peer Resources.

The browser may be used to login to the LAN environment. Just click on it with mouse button 2 to get the context menu and then select the Login... menu item. To logoff again, just select the same menu item, now called Logout....

However, the major function of the browser is to browse the resources available to you on the network. Open the browser to see all the workstations you can access from your workstation. The workstations shown will be all those in your own peer domain, that is with the same domain name.

Opening any of the workstations shown will display the resources you can access on that workstation. You can use these resources directly, for example drag files to and from network directories, or you can shadow them onto your desktop and assign drive letters or printer devices to them as appropriate.

Workplace Shell

The peer environment is fully integrated into the Workplace Shell to present a seamless environment. For example, each resource that can be shared, disks, directories, printers and so on, has a Share... menu item added to its context menu. This can be used to perform the following actions:

  • Start sharing
  • Stop sharing
  • Configure sharing
  • Control access
  • Apply access permissions

We will find out more about these operations below. In addition, the following extra pages are added to the settings notebooks of all shareable resources:

  • Shares
  • Access controls

Apart from these peer specific operations, the Workplace Shell makes no distinction between network resources and local resources when you use them which makes for an integrated single system image environment.

User Profile Management

This tool is used to define users and groups of users to whom resource access may be granted on a particular workstation. In order to be able to access a resource on a particular workstation, users must be defined on that workstation using UPM. The User Account Management application in the UPM Services folder is used to define these users. This folder also provides a Logon and Logoff icon however I recommend the use of the LAN Resource Browser for this task. Refer to the OS/2 Peer documentation for more details on UPM.

Basic Mechanics

The first thing to consider when setting up an environment to share resources is to decide what resources you want to share and which workstation should own them. In other words, which workstation should be a server.

Purely from a software point of view, any of the workstations can be a server. It is usage and capacity that determines the best server candidates.

Any workstation that isn't on the network 100% of the time makes a poor server. Also any machine that gets rebooted a lot or has dual boot installed and is sometimes booted as a DOS or Windows 95 system is also a poor choice. These are the usage factors you must consider.

Capacity is largely dictated by what you want to do. You don't need an enormous amount of power to serve a disk to two or three LAN users. I comfortably accomplish this using an old 50MHz 486 with not new IDE disks.

What you do need to share a resource is enough of the resource to share. Thus sharing a disk with only 20MB of free space is essentially a waste of time. Estimate how much disk space will be required by your users, double it and add 20% for safety, add what the local system will consume and you will have a reasonable estimate for your disk requirements.

To set up the server, you must have IBM Peer for OS/2 Warp installed and started. In particular, you must have the Peer component started which is the installation default. To perform any sharing or using, you must also be logged on to the workstation at which you are performing the work. Controlling Access has a complete overview of the security mechanism.

The act of sharing a resource is essentially the act of creating a special name, called a Network Name, which is understood by the server software and is used by the client software to access the resource. Network Names, generally called NetNames, can be created in various ways. For example, to share a directory called C:\Public\GeneralArtwork you could issue the following command on an OS/2 command line:

NET SHARE GENART=C:\Public\GeneralArtwork

This would create a netname, GENART, that refers to the directory resource, C:\Public\GeneralArtwork. Client workstations can then access this shared resource using the netname in the following command:


Where SERVER1 is the name assigned to the server workstation when you installed OS/2 Warp Peer. Don't get confused with TCP/IP host names which are different. In fact, as a tip I recommend you make these the same so you have less to remember but otherwise there is no connection. The X: is a drive letter of your choice which should not be used anywhere else on your workstation. When the command is executed, the shared directory will look like drive X: on the client workstation.

Commands are useful to show us the raw mechanics behind the sharing mechanism. However, we have a number of visual tools to protect us from the nasty brutish world of the command line:

  • Sharing and Connecting Application
  • Network Aware (Workplace) Shell
  • LAN Resource Browser

These are the tools we shall be working with for the most part. For full details on the command set, see the Commands and Utilities online manual in the Books folder inside the OS/2 Peer folder.

Controlling Access

Before we go too much further, we need to check out the security system that forms part of OS/2 Warp Connect. Like any resource you share across a network, disks, directories, printers and so on all need to be protected from unauthorised access. The OS/2 Warp Connect security system, User Profile Management (UPM) performs this function.

There are two parts to the security system. The first defines authorised users and allocates user identities (userid) and passwords to them. The user can then identify themselves by logging into the system supplying the userid and password. The second part concerns determining what resources the user can have access to and granting that access when requested.

The first part is performed entirely within the UPM system. Within the UPM Services folder on the desktop after OS/2 Warp Connect has been installed is a tool called User Account Management. This is used to define each user you want to have access to your workstation. Larger organisations can gather defined users into Groups for easier management.

During the installation of OS/2 Warp Connect, you are prompted for an initial system administrator userid and password. This should be set up for the workstation's user who should also be configured as the workstation's system administrator. You must login using this userid and passowrd to use the facilities of UPM account management.

You could login using the Logon/Logoff icons in the same UPM folder. Alternatively, you could login using the login menu item of the LAN Server and OS/2 Peer Resources icon in the Network folder. I prefer this latter method as it links in with the Network Aware (Workplace) Shell we will be discussing later.

Access to shared resources on a server workstation is controlled by an access control profile called an Access Control List (ACL). These are special profiles maintained by the Peer software containing a list of userids or group names granted access to the resource and the level of access granted.

All shared resources must have an ACL associated with it even if it just grants full read/write access to PUBLIC. We will cover the detail of creating access control profiles when we discuss setting up shared resources as that is generally the time we would create the profile for the resource being shared.


In a peer network such as the one we are contemplating, to use a shared resource a user must logon on their own workstation with their allocated UPM userid and password. This means the userid and password must be defined on both their own workstation and the server workstation they wish to access. Whenever they connect to a shared resource, the userid and password they are logged on locally with are passed to the server for validation there. Again, this means the userid and password must also be defined on the server workstation.

The environment has two provisions to help reduce the work of maintaining all these userids and passwords. Firstly, you can set up resources as publicly accessible and that therefore require no userid and password to use. Secondly, when you set up connections, you can specify that you want to be prompted for a new password if the server password differs from the local one.

For more information about access control, UPM and logging in and out, see the relevant sections in the Commands and Utilities and User's Guide online books in the OS/2 Peer folder.

Sharing Resources

Sharing resources can be accomplished in one of three ways, commands (NET), the Sharing and Connecting application and the network aware extensions to the Workplace Shell. We won't be looking at the NET commands much. There usefulness lies in the fact that they can be included in REXX command files which enables you to automate a lot of routine tasks.


Sharing and Connecting is started using the icon shown which is found in the OS/2 Peer folder. This shows a window containing a notebook with three tabs:

  • Connections
  • Shares
  • Access Control

The Connections page is used to view what resources your workstation is using on other workstations. We will look at this page when we discuss using resources in the Using Resources section below.

Of the other two tabs, the Shares page is used to create, alter and delete profiles describing resources owned by our workstation and which are to be shared and describing when they are to be shared. The Access Control page is used to create, alter and delete access control profiles.

Sharing a resource requires three steps:

  1. Describing the resource in a share profile
  2. Authorising access in an access control profile
  3. Initiating the share using the share profile

The first step, describing the resource, can be done using the Shares page of the Sharing and Connecting application or using the resource's Workplace Shell context menu.

Using the Sharing and Connecting application, switch to the Shares page, pull down the Share menu and select the Create... menu item. Select the resource type from the resulting dialog and press the Ok pushbutton.

On the resulting panel, fill in the resource details including a description and so on. The share name is the public netname used to access the resource when it is shared. You can also limit the number of users that can access a particular resource at any one time. This is useful to enforce licensing requirements for programs you put in shared directories.

The Start Sharing... checkbox enables you to specify this resource is to be shared when the peer service is started, normally when the workstation is booted. If you don't specify this option, you must manually share the resource when it is required.

The Grant access... pushbutton provides a tie in to the access control management environment available from the Access Control page. This enables you set up an access control profile for the specific resource you are creating a share profile for now and this would probably be the normal way you create such profiles.

Pressing the Grant access... pushbutton displays the Grant Access dialog. This dialog has two sets of contents depending on whether you choose to grant Basic access or Customized access. Basic sets a simple access level that is applicable for all users no matter what their userid, password or group is. Customized enables you to specify the Groups and/or Users that can access this resource and what access permissions they are granted.

An access permission is a level of access, for example read only, read/write and so on. An additional checkbox at the bottom of the dialog sets auditing on for this resource. When set on, all accesses to the resource are logged in the Audit Log.

When all setting have be made to your satisfaction, pressing the Ok pushbuttons on each dialog returns you to the main page and the share and access control profiles are created. If an access control profile needs to be explicitly created, turn to the Access Control page and use the Create... menu item on the Access pulldown menu.

You should note that you can create access control profiles independent of any particular shared resource. For example, you might have a shared directory to which we grant read/write access. We could create an access control profile for one of its subdirectories restricting access to read only although the subdirectory is not explicitly named in a share profile. When your delete a share profile, you are given the option of deleting the access profiles or leaving them in place. Access control profiles may be created for individual resources without an associated share profile using the Access Controls page.

Another thing to note is the Apply access permissions... menu item on the Access pulldown menu. This copies the access control profile, creating a new one for each subdirectory within a shared directory. Normally, a new access control profile is automatically created when a new subdirectory is created within a shareable resource. However, when you first create the share profile, you must do this manually using this menu item. Note that if you already have access control profiles on some or all of the subdirectories, these will be overwritten.

As we mentioned before, we can bypass the Sharing and Connecting application and use the Workplace Shell directly. To create a share profile and access control profile for a resource, click on it with mouse button 2 to popup the context menu. At or near the bottom, you will see a Share menu item with a cascade arrow. If you don't see the arrow, Peer is not started. Start it, logon and try again.

Click the Share menu item and select the Configure sharing menu item. This will lead you to the same Configure Sharing dialog you reached from the application. The process of creating a share profile and associated access control profile is the same. The details of the profiles can be found in the Shares and Access controls pages of the resource's settings notebook.

If you just want to create an access control profile for the resource, use the Control access menu item from the cascade menu. The Apply access permissions menu item can be used to replicate the profile to all subdirectories if required.

Once the share profile and access control profile have been created for the resource, the last step is to share the resource. This is done automatically for your when you create the share profile. However, if you want the share to be automatically done each time you start the Peer service, you must click the Start Sharing... checkbox when creating the share profile.

If you have not set up automatic sharing for a resource, you must manually share it. This can be done using the functions of the Sharing and Connecting application or the Workplace Shell as before.

With the application, start it, go to the Shares page, select the share profile of the resource to be shared and then select the Start menu item from the Share pulldown menu. Alternatively, you can click the share profile with mouse button 2 to get a popup menu with the same options. The Stop option on either menu is used to manually stop sharing the resource.

Using the Workplace Shell, click on the resource to be shared with mouse button 2 to get its context menu. Select the Share option at the bottom and select Start sharing from the cascade menu to start the share or Stop sharing to stop it again.

Once again, for more information about sharing resources, check out the online documentation that comes in the OS/2 Peer folder. The Sharing and Connecting application help is also useful reading.

Using Resources

Once a workstation has shared resources, other workstations can use them by connecting to them using either the same Sharing and Connecting application or the Workplace Shell. In the application, the Connections page is used to set up connection profiles which record the details of the resources you wish to connect to. Connection resources may be currently connected or disconnected. Inactive connections have a small icon in the shape of a broken red lightning zap on them.

Creating a new connection profile is just a matter of pulling down the Connection menu and selecting the Create... menu item. You will be walked through the process of establishing a connection profile for a resource on a server.

In summary, you need to specify the name of the server workstation owning the resource and the netname the resource was shared with. Pulling down the list from the share/alias combo box will show you a list of candidate workstation names to select from. You will then specify the name, for example drive letter, by which that shared resource will be known on your workstation.

Setting on the Connect to resource at logon checkbox specifies that you will automatically connect to this resource whenever you fire up your workstation starting the peer service. Setting on the Prompt for password checkbox indicates you would like to be prompted for a password should your local one not match any on the server workstation.

Creating the profile will also initiate the connection. To automatically, connect on subsequent starts of your workstation, click the Connect to resource at logon checkbox. If this box is not clicked, you must select the connection profile and use the Start menu item on the Connection pull down menu. Alternatively, click on the profile using mouse button 2 to get a popup menu and select the Start menu item. The connection can be terminated anytime using the Stop menu item for either menu.

As with sharing, the Workplace Shell can also be used to connect to shared resources on the LAN. The main tool for connecting to resources is the LAN Server and OS/2 Peer Resources folder which is normally found in the Network folder on your desktop. This is also used to login and out using the appropriate option on its context menu. I will refer to it from here on as the LAN Resources Browser.

Open the LAN Resources Browser. Inside, you should find an icon for your own workstation and other workstations on the LAN with resources to share. If you can't see the workstation you are after, click on any of them with mouse button 2 to get the context menu then select Access another.... Ignore the first field and type the name of the workstation into the second field, Server, and press the OK pushbutton.

You could try the pulldown option on the Server field but if the workstation isn't in the main folder it probably won't be in drop down list. If the workstation can be found, it will be added to those in the folder. A shadow of the workstation icon also appears on the desktop. This can be shredded if not required.

Having located the workstation owning the resources you are after, you must open it (double click) to see the resources it has to offer. These will shown as icons inside the open workstation folder. You can now access any of the displayed icons directly with no further work. For example, you can drop files onto printers and folders and drag files out of folders and so on. To go further, you can assign a local device name, for example a drive letter or printer device, to the resource by clicking on it with mouse button 2 to get its context menu and selecting the Assign... menu item.

Unlike the Sharing and Connecting application, using the Workplace Shell does not set up a permanent connection profile that can be used again and again. It just sets up a one time connection to the resource. Next time you start up your workstation, you will have to re-establish the connection manually. You can streamline this process by dragging shadows out of the LAN Resources folder and placing them where they are more accessible.

Resource Sharing Specifics

This section builds on the information presented in the previous section by covering some of the specific details of sharing disk, printer and other resources on your home LAN. I have subdivided the section into the following topics:

  • Directory and Drive Specifics
  • Printer Specifics
  • Other Resources

Directory and Drive Specifics Now that we have a general understanding of sharing resources on server workstations and connecting to them from client workstations, let's look as some of the specifics when dealing with shared drives and directories.

Directories are multilevel entities that contain not only files but potentially other directories in an nested hierarchy. When we share a directory, we create a Network Name (netname) that, together with the workstation name, uniquely identifies it on the LAN. When we connect to a remote directory netname, we effectively create a new drive on our local desktops. We call these drives Network Drives and they can be found in your Drives folder. Access them just like any other drive within the restrictions imposed by the shared resource's access control profile.

Understanding access control profiles and how they relate to the files and directories you are accessing can be a problem. Firstly, understand that access control profiles can be created for individual files, directories and for the whole drive. When you try and access a file in a directory, sub or otherwise, on a network drive, the access control mechanism checks for access control profiles in the following order:

  1. Access control profile for the file itself
  2. Access control profile for the enclosing directory
  3. Access control profile for the whole drive

As soon as a profile is found in the search order, the access permissions found in that profile are applied against the attempted access.

The implications are reasonably clear. You must have a profile at one of the three search points for the file to be accessible. It is no good having a profile applied to a directory and expecting to be able to access a file two or more subdirectories down in the tree using it. It won't feature in the search.

Note also that a profile on the root directory is not the same as a profile for the whole disk. In fact a profile for the whole disk is most useful when sharing diskette drives and CD-ROMs, that is removable devices. It is impractical to keep making access control profiles for each directory you want to access each time you change the disk in the drive. By creating an access profile for the whole drive, the first two search points fail but the third always succeeds.

It is worth noting the range of possible permissions that can be granted in disk/directory sharing situations:

Files can be read and executed but not changed
Files can be written to but not read, run, created or deleted
Files can only be executed
Files can be created
Files may be deleted
File attributes can be changed
The user can change the access permissions for the resource

The capitalised letter is often used to represent the permission in commands and displays.

There are some common types of disk and directory shared resources you may want to consider setting up:

Home Directories

It is common to give each person a private area on a shared disk called a Home Directory. This is just a private workarea in which they can put directories and files they don't want on their own workstations.

Set up a directory, called Home say, on your designated server and under it define a directory for each user on the system. A good naming scheme is to use the person's true name, for example \Home\NicholasMcGuigan. The share profile for each should be set up to share on server startup. Access should be restricted to the assigned person who should be granted all permissions. Users traditionally access this facility with a drive letter of H: (for H:ome!).

Transfer/Exchange Area

This is a read/write area available to all users for use as a common scratch pad and exchange area. For example, I could create a subdirectory on it and leave some stuff for someone else. When they get in, they can access the directory and copy it off to their own workstations. Care should be taken to ensure people don't use it as a permanent storage area. The adventurous of you could write a little REXX command to scan it and delete anything over a week old.

On your server, create a directory called Shared to hold all your ad hoc shared areas and then create a subdirectory called Scratch to be the exchange area. Share this with Basic read/write access for all. Sharing should be done at server startup. Encourage users to use the same drive letter, for example S:, to access it. This creates a common vocabulary when discussing the system.


We have discussed the sharing of drives above. CD-ROMs are common candidates for this type of sharing. You should always try to have a CD in the drive at all times to avoid device not ready problems. Share the whole drive with Basic read only access.


Sharing applications is an art all of its own and I don't intend to plumb the depths here. However, taking care of a couple of points can save you a bit trouble later on.

Firstly, separate the component files into a read and read/write piles. Read is generally easy and should reside on the server. The read/write pile you will have to decide whether it lives on the server in a separate read/write directory or on each client workstation. It depends on the application, the users and so on.

Write a little REXX procedure to set up the environment if there are multiple shared directories to access or to handle any other setup complexities. This procedure should live in the primary application directory.

Watch out for DLLs and other "Path" complexities. It is a LAN Administrator's commandment not to put network drives into the CONFIG.SYS paths. Find another way.

Put an additional access control profile on the main executable file (EXE) to restrict access to execute (X). This means people can't copy the file off the server. You will have to use the NET ACCESS command to do this as the other tools can't handle files.

Put a limit on the number of users that can simultaneously access the application's main directory to limit usage to the number of licenses you have purchased of the application.

The NET APP command can be used to set up complete application definitions but only when connected to a full LAN Server domain which is beyond the scope of this article.

Reference Materials

These are just read only directories containing stuff like artwork, reference manuals and so on. A large amount of disk saving can be realised by moving such stuff off each of the workstations and making it commonly accessible on the server.

There are plenty of other ideas for using your disk server but these will help you get started.

Printer Specifics

Sharing printers over the LAN makes use of the two part structure of printer drivers. Let me briefly review how this works in the standalone case and the network case.


In the diagram on the left, the block on the left represents the program producing the printed output and the symbol on the right the target printer. The upper path between them represents the elements of a local environment and the lower path those of a network environment. The two D shapes with numbers in them represent the two halves of the printer driver.

When the program starts printing to its selected printer, part one of the printer driver grabs the output and puts it in a spool file on the local disk. The format of this file can be an OS/2 Metafile or a native printer data stream, for example PCL5.

A piece of code called the print queue processor is responsible for reading this file when the target printer becomes available and transferring it through the second part of the printer driver directly to the printer. This is accomplished by transferring the native data stream straight through the driver to the printer or by replaying the metafile and having the driver render it on the output device.

For networked printers, the process is very much the same with just a little bit of magic in the middle. Part one of the printer driver produces the spool file as usual but instead of being stored locally, the spool file is transferred directly to the server workstation and placed in the spooler queue there. In time, the local spooler will organise it to be printed through part two of the same printer driver but on the server workstation.

There is one major implication here and that is the printer driver for a networked printer must be installed on both the client and the server workstation. If the driver is not available when the network printer is setup on the client, you will be prompted to install it.

Setting up a shared printer on the server workstation is quite straightforward. A local printer is setup on the server in the usual way using a template, Create another... and so on. A key element of the new printer is its queue name. This can be viewed on the first page of the settings notebook in the Physical Name field. This name becomes the netname for the shared printer. You have no choice in the matter.

Once created, the printer is shared using either the Sharing and Connecting application or the Workplace Shell as described previously. The Share name on the Configure Sharing dialog is set to the printer queue name and cannot be changed.

Granting access, both the Basic and Customised versions, is just a matter of granting users the right to use the printer. There are no subtle shades of access as for disk based resources. The only access permission relevant is Create.

To connect to the shared printer, the Sharing and Connecting application can be used as before. However, although this does access the shared printer and does create a network printer port, LPTx, on the connecting workstation, it does not create a printer icon nor does the printer appear in printer selection lists. This is because this connection process does not cause the printer driver to be installed and the network printer to be initialised.

A better way involves the LAN Resources folder. Open it, find the server workstation and drag out a shadow of the network printer onto your desktop. You will then be prompted to install the printer driver if you don't have it installed. Follow the instructions on the screen to complete the driver installation.

When complete, the printer is ready to use. Just move the shadow to a convenient location. Once the desktop icon has been created and the driver installed, the Sharing and Connecting application can be used to renew the connection each time you start your workstation. Other methods of creating the initial network printer icon involve the Network Printer template and Create another... on an already accessed network resource context menu.

Once the printer icon has been created, using it is identical to any local printer. You can drag files to it and select it in printer setup lists within applications. There is nothing left to do in the OS/2 environment.

However, if you plan to use the printer from the DOS or Windows environments, you must do a few more things. Firstly, you must assign an LPTx device. Click on the context menu, select Assign port... and then select an appropriate port from the dialog shown. To unassign the port, select the same entry, now called Unassign port.

Once you have assigned a port, DOS/Windows can use the printer. Go into Windows and set up a Windows printer device as you would normally. Make sure it is of the same type as the real printer and implements printer drivers compatible with those the OS/2 printer is setup with.

Other Resources

So far, we have covered sharing drives, directories and printers in this section. However, there is one other resource type you can share and that is serial queues or COM ports. At first sight, this might seem to be a useful thing and induce visions of pools of shared modems and so on. However, the reality it a bit more limited.

When sharing a COM port, you must understand that you will be creating a redirected or network COM port on the client workstation. The problem is you will not of course be creating an equivalent hardware port on the client workstation and most serial communications program are very hardware aware. The effect of this is that only programs that stick to using the COM.SYS driver and avoid the hardware underneath it are likely to work with these network COM ports.

As an experiment, I shared COM1 on my designated server and accessed it as COM2 on one of my workstations. A modem is attached to COM1 on the server. I then used HyperACCESS Lite from the OS/2 Warp BonusPak to try and effect a connection using a Direct Connect profile. When I started the connection, the modem raised DTR indicating I was talking to the modem. I then typed in AT I expecting some kind of identification response. I did get character echo but I didn't get any response from this or any other AT command.

In summary then, a potentially useful feature hampered by lack of code to exploit it.

Transferring Data

This section covers transferring data around the network from workstation to workstation. There are a number of ways this can be done. For example, the data can be collected as a file and then the file copied or moved to another workstation. Alternatively, the data can be copied using a shared network clipboard or "trickled" using network DDE facilities. This section is divided into the following topics:

  • Transferring Files with FTP
  • Other File Transfer Techniques
  • Shared Clipboard and DDE

Transferring Files with FTP

The TCP/IP File Transfer Protocol (FTP) is a simple mechanism for transferring files from one workstation to another. OS/2 Warp Connect provides two implementations of FTP as part of its TCP/IP kit. The first is FTP-PM, a presentation manager program with some drag and drop capability. The second is a command line version which is invoked by typing the FTP command on an OS/2 command line.

I will not be dealing with the command line version in this article. In addition, there is an implementation of the related Trivial File Transfer Protocol (TFTP) supplied as a command line utility and I won't be covering this either. Both are documented in the online TCP/IP documentation that comes with the product.

Finally, as part of the same kit, there is a REXX FTP application program interface which enables FTP exchanges to be driven directly out of a REXX command file. Again, space forbids me to cover this in any detail so I will just refer you to the REXX FTP API online manual in the OS/2 Information folder.

To use FTP to send files to and receive files from a remote workstation, two things must be set up on that remote workstation:

FTP Daemon

The FTP Daemon (ftpd) is the server part of the setup. This listens for FTP requests on its well known port number. When a request comes in, it handles the remote workstation's end of the transfer conversation.

User Identity

When a user attempts to connect to a remote workstation to perform a transfer, the remote workstation needs to know who that user is and what they can have access to. This is done by setting up an FTP user profile for each user needing to use FTP to and from that remote workstation. A catch-all userid, anonymous, can be setup to provide public access to the workstation with no password required.

These things are set up using the TCP/IP configuration tool found in the TCP/IP folder. After installation, the TCP/IP folder tends to end up in your OS/2 System folder. The configuration icon is labelled TCP/IP Configuration.

The ftpd daemon can be started manually from a command line each time you want to use it or it can be configured using the TCP/IP Configuration program. To set up the ftpd daemon for autostart, open the TCP/IP Configuration program and turn to the Configure Automatic Starting of Services page with the Autostart tab.

Firstly, select the inetd service from the Services to autostart listbox. Make sure the Autostart service checkbox is checked. Select the Detached radiobutton as the start method. If you plan in the future to autostart the telnetd daemon, you should select the Foreground session radiobutton and check the Minimized checkbox.

What this does is to configure a special type of daemon or server that listens for incoming requests and then starts the actual server required for the particular request received. Thus, instead of starting an ftpd server and having it run all the time, we start inetd. When an FTP request comes in, inetd starts ftpd which then handles the request.

Now we must configure FTP as a service to be handled by inetd. Selected ftpd in the listbox. Check the Autostart service checkbox and click the Inetd super server daemon radiobutton to indicate this server is to be handled by inetd as described above. This completes the configuration of the FTP server daemon autostart.

Next we need to set up user identities to enable remote users to start FTP conversations with the workstation. Turn to the Configure Server Security page using the Security tab. Click in the box labelled FTP access protection (TRUSERS). This activates the pushbuttons needed to add user definitions.

Push the Add pushbutton to open the FTP User Entry dialog. Enter a Username and Password in the fields provided. Then enter a list of fully qualified directories in the fields provided for read and write access. You don't need to enter subdirectories, just the tops of the main directory trees you will be accessing. Clicking the checkboxes just underneath means you are authorising them to use all the directories on the workstation except the ones listed. When finished, press the Add pushbutton to add the user.

You should add all the users you want to grant access to in this way. Anonymous can be added like this as well but a password is not required. Be fairly restrictive about what you grant anonymous as anyone can use this userid. For all other users, you should be reasonably specific about what you grant unless you trust them.

Once the environment is established, file transfer proceeds fairly simply using the FTP-PM application in the TCP/IP folder. Start this up and enter the remote host name, fully qualified with its domain name, and your FTP userid and password for that remote host on the dialog shown.

A PM window is then shown divided horizontally by a blue line. Above this line are two list boxes that enable you to position yourself on your local workstation by selecting drives, directories and files just as if you were using a file dialog. Below is a file/directory list from the remote host. Again, using the entries in this and typing into the entry field at the top enables you to position yourself on the remote host and access the files there.

To transfer files from the remote workstation to yours, position yourself in the target directory on your workstation using the controls above the blue line. Then do the same to locate the files on the remote host using the controls below the line.

Before starting the transfer, you should then set various options using the Options pulldown menu. First set the Transfer Mode to Binary to transfer all files without regard to content. Secondly, set Confirmation to Off to avoid being prompted to confirm each and every file being transferred.

The actual transfer is then just a matter of selecting all the files in the remote host directory by clicking on them and then dragging them to the Files listbox above the line and dropping them there. The files are then transferred with a progress indicator being shown.

To transfer files from the local to remote workstation, just reverse the direction of the drag. That is select all the files in the Files listbox above the line and drag them to the Directories/Files listbox below it.

In addition to the file and disk/directory selection facilities described above, there are also facilities to create directories on either the local or remote workstations and to rename or delete files and directories on either host.

That is just about it for the basic transfer facilities. What about setting up the workstations? As mentioned above, each workstation that needs to participate as a target for a remote file transfer operation must have the ftpd daemon running or startable by inetd and have each potential user defined to it.

This is fine for designated servers by for individual user who may want to transfer the odd file from time to time, it is a bit of overkill. In these cases, I recommend the following approach:

  1. Either define ftpd to start from the inetd super server or set up a small REXX procedure to kick it off on demand. This REXX procedure can be placed on the launchpad to give you a one button start.
  2. Set up a transfer area, for example x:\Transfer with an Incoming and an Outgoing subdirectory.
  3. Define the anonymous userid with no password. In the read list enter both the Incoming and Outgoing subdirectories, for example:
 x:\Transfer\Incoming x:\Transfer\Outgoing

In the write list enter just the Incoming subdirectories, for example:


Using the setup described above, users can connect to your workstation and put files in the Incoming directory and get files from the Outgoing subdirectory. To enable someone to get a file from you, copy it into the Outgoing subdirectory and tell them to go for it.

Other File Transfer Techniques

FTP is definitely one of the better ways to transfer files around. However, it has one glaring problem, it requires both participating workstations to be there at the same time. A way of dealing with this issue is required if household members have their own schedules and are not always present when you need to send them files.

One way is to set up a store and forward mechanism using the OS/2 Peer disk sharing capability or even FTP itself. The idea is to set up a disk directory on a designated server and to transfer files to that area. Subsequently, when the intended recipient returns, he or she can check for the files and copy them to their own workstation.

The two issues here are security and target user. The first problem is that in a general scratch pad area, everyone can see your files. This might not be an issue in a home environment but then again it might be.

One approach may be to setup individual transfer areas. The problem here is you would need one area per pair of transferring users which would soon get out of hand if you have a lot of users requiring this type of privacy. A better approach is to use encryption or to restrict store and forward transfers to "doesn't matter" type communications.

Another approach is to set up a transfer area for each user and set up an FTP profile giving everyone write but not read access to everyone else's area. The area owner should have read and write access. Then transferers can write to the target user's area. One effect of having write only on a directory is you can write to it but you can't see what is in the directory, not even a file list. This keeps the communication confidential.

The other issue is how do you tell if a file is for you or someone else. In the latter case above, that is covered by the way the directories are set up. If the file is in your directory, it is destined for you. However, if you are using a common directory as a file transfer bucket, this issue can be a major problem.

There are no ready rolled solutions to this problem. However, one way to deal with it is to put the name of the recipient into the file's extended attributes. For example, you could place the target user name into the Subject extended attribute and then use a REXX command file to list all files targeted for a particular user based on the content of the attribute. Select any data file, open its attributes and click on the File tab to see the Subject attribute.

Shared Clipboard and DDE

Finally, there are two facilities supplied as part of OS/2 Peer which are useful for moving non-file data around the network:

Shared Clipboard

This extends your clipboard onto the LAN. By sharing your clipboard, remote users can paste information into their documents that has been copied from the clipboard on your machine.

Network DDE

Network DDE extends the DDE application driven data exchange mechanism onto the network. This enables applications on your local workstation to feed data directly into an application on another workstation across the network and vice versa.

These are set up and managed using the Network DDE and Clipboard application in the OS/2 Peer folder. The application window contains an array of eight buttons as follows:

Copy Clipboard

This function enables you to copy the contents of a remote clipboard into your own clipboard. From there, you can paste the contents into an application. You specify the remote workstation whose clipboard is to be copied.

Copy Clipping

This function enables you to copy a clipping, saved clipbpard data as created by Manage Clippings, to the clipboard. The clipping can be copied from the local or a remote workstation.

Manage Clippings

This function enables you to save the contents of the local clipboard for subsequent reuse later on. Such saved contents are called Clippings. They may be used by copying them to the clipboard again using the Copy Clippings function.

Control Access

This function controls whether or not remote users can have access to your clipboard or your collection of clippings and whether they can establish remote DDE links to you. Each of these functions can be enabled or disabled individually.

View Links

Displays the currently active DDE links to and from your workstation to other remote workstations. By selecting a link and pressing the Close link pushbutton, you can delete active links.

Active Workstations

This function enables you to check to see if clipboard sharing and network DDE is running on any specified remote workstation.

Clear Clipboard

This function clears the local clipboard.


This function display useful help information and guides you in using the features available.

Other Functions

So far we have talked about sharing resources such as disks and printers on the home LAN and about transferring files and other data around it. There is much, much more you can do with the LAN. This section runs through some of the additional options you can implement if you have the need.

  • Personal Conferencing
  • Remote Access
  • Web Server

Personal Conferencing

Personal Conferencing is the use of the LAN and your workstation to talk to other users on their workstations on the LAN and to share data and information with them while you are doing so. You can talk to multiple users at once which is what makes it a conference rather than a point to point conversation.

The use of your computer in this way enriches the content of your conversation. For example, instead of trying to describe the thing you are seeing on your desktop ('s got two tails and you won't believe where it's stuffing its food!) you can show it to the participants, point out the salient details, annotate it and generally talk about your problem/excitement/feelings instead of wasting bandwidth on verbal description.

As we learnt in Warp Connect Overview, the OS/2 Warp Connect BonusPak contains a tool called IBM Person to Person (P2P) and this is the tool we use to implement personal conferencing on the home LAN.


The folder shown is created on your desktop after you have completed installing P2P from the BonusPak. Getting Started is an online user guide to getting the product up and running. This should be consulted to learn the ins and outs of configuring the product.

The major part of the configuration process is defining your access to the various communications mechanisms that you are going to use and then defining who you are going to talk to. The following communications protocols are supported:

  • Asynchronous Comms (Direct Modem)
  • NetBIOS
  • TCP/IP
  • ISDN
  • Novell SPX

For a home LAN, I recommend NetBIOS as the cheapest and easiest. If you plan to conference across the Internet, you should also configure TCP/IP. Finally, if you are going to conference with others via your serial port and modem, you should configure the asynchronous comms support. Happily, multiple communications protocols can be configured for use at the same time. Being OS/2 (multitasking!), you can also use them simultaneously as well.

Once configured, the Call Manager must be up and running for anything significant to happen. This is the piece of code that handles incoming calls and sets up outgoing ones. I shadow mine to the Startup Folder so that it comes up when OS/2 Warp starts.

The Address Book is where you create and manage your address books. You can have multiple address books, for example Business, Personal and so on. Each entry in an address book identifies a potential conference party together with how P2P should get to them, for example NetBIOS name, TCP/IP host name and so on.

The Address Book is used to initiate a call to a person or set of people. These people are contacted via the communications protocol designated in the address book entry and, if contacted successfully, are brought into the conference. This is very like establishing a conference call with a PABX extension.

When a call arrives at a called workstation, the Call Manager intercepts it and puts a message up on the screen and sounds a ringing tone on the speaker (just like a telephone). The called party has the option of accepting the call or rejecting it. If you reject the call or you aren't there to answer it and a time out occurs, the caller is notified appropriately. You can also bar all calls if you don't want to be bothered while working on something. The configuration process enables you to specify messages to be sent to the caller when rejecting or barring calls.

Once the conference has been established, there are a number of tools you can use to communicate with your partners:


This tool enables you to type text messages that are displayed in the Talk windows of the conference parties. You see any messages they type as well. The tools keeps a log of messages as you go which can be saved in a file when the conference is over. This gives you a handy record of the interchange.

Talk is fairly cumbersome and I personally prefer the telephone as the primary communications channel. However, where a telephone is not available or, perhaps, the cost is prohibitive, the Talk utility is good value.


Possibly the most useful of all the tools, the Chalkboard is a window into which text and images can be loaded for display on each of the conferencing parties' chalkboards. A powerful feature of the chalkboard is the ability to copy the content of a window on your desktop into them and them to dynamically refresh the contents as the original window changes. This facility, called mirroring, can be used to walk conference parties through a sequence of steps performed by an application on the desktop.

The Chalkboard also provides various text and drawing tools that you can use to annotate and highlight the contents. These tools can also be used to create sketches on the fly without a base image or application mirror. As the tools are used, the results are propagated to each of the conference parties so they can see the result.

Each user has a pointer which they can use to point to things in the Chalkboard. Pressing the mouse button makes the pointer visible on the conference partners chalkboards and displays your name next to it so they can see who is pointing.

Once again, when the conference is finished, the contents of the chalkboard can be saved in a file to provide a permanent record of how you ended up. During a later conference, the contents of the file can be reloaded into a chalkboard and work on the contents can resume.


This tool enables you to share your clipboard with your other conferencees. For example, you can copy a set of cells from your Lotus 1-2-3 or Mesa/2 spreadsheet and your partners can paste them into a wordprocessor or their spreadsheet program. Very handy for ad hoc data transfer.

Of course, you could use the Peer for OS/2 Warp shared clipboard instead. Which one you would choose would depend on what mode you were in at the time. If you are using P2P to interact at the time, the Clip tool is the natural choice. Otherwise use the Peer shared clipboard. Of course the P2P clip tool can be used over a lot of connections that the Peer tool cannot.


P2P also includes a tool to do video conferencing. However, this does require a significant hardware investment. You will need a special multimedia adapter called the IBM ActionMedia II card with a Capture Adapter daughter board. This is not cheap and the ISA version takes two IRQs which is just not on for general purpose desktop systems. For special purpose video conferencing workstations, it might be acceptable.

Next you will need a video camera. Ideally, you will want a small unobtrusive little device that sits on top of your monitor. However, I have worked with a standard home video camera and, although bulky and obtrusive, it did do the job quite well.

All this costs money, lots of it. However, once spent, you will be relieved to know that the required software is all included in P2P. The connection works just like the other tools and a single conference can include any admixture of tools including the video tool. You will be able to see up to two of your video enabled conference partners on the screen at one time. Switching between partners is just a matter of clicking on the appropriate pushbuttons.

Scenes shown on the video windows can be captured and saved in a file for future use. Another tool, Stills Capture, can be used to capture images coming in from the local camera. This can be used quite independently of the video system to capture images for subsequent use in other applications or, for example, to copy into a chalkboard for discussion.

If any of your conference partners does not have a video setup, they cannot transmit images. However, by configuring Software Video Emulation, they can receive video which is then rendered by the P2P software. The images are black and white and a bit jerky but it is a cheap solution for those who need to receive an occasional bit of video.

In summary, Person to Person is a handy little package for ad hoc personal conferencing between up to eight people. It can be used around the home LAN, across the Internet or over a dialed modem link. And best of all, it is part of the OS/2 Warp BonusPak and so doesn't require any additional outlay.

Remote Access

There are various products on the market that enable remote users to access a LAN across a dial in connection. IBM's entry in this field is called LAN Distance and, as described in LAN Distance Remote, OS/2 Warp Connect contains the client piece of this product, LAN Distance Remote. The server piece is called LAN Distance Connection Server and this must be purchased separately, either on its own or as part of the OS/2 Warp Server product.


The Connection Server is installed on a workstation directly attached to the LAN. The Remote clients can then dial in to it to become part of the LAN, albeit over a somewhat slower link. Each Connection Server can support up to 32 serial ports. The dialed Remote workstations are seen as an additional (virtual) LAN segment with the Connection Server playing the part of a LAN bridge.

Connection Servers can dial each other as well. In this mode, they form a remote bridge connecting two physical LAN segments.

Although it involves buying additional software, namely the LAN Distance Connection Server, adding remote access to your home LAN can greatly increase its power and range. Consider the following scenarios:

  1. Children at school and parents at work can all dial into the home LAN to pick up and drop off files, use the printers, leave messages and use any of the functions they would normally use when locally connected.
  2. The home Connection Server could dial, subject to suitable authorisation, other Connection Servers thus joining two remote LANs together. The remote LAN could be your work LAN for example. This would enable you to access your home LAN facilities and the same time you have access to the full complement of work facilities.

You should note that LAN Distance has a full set of security facilities including userid/password access and dial back capabilities. This is most important when opening your site to outside access via modems.

Web Server

A World Wide Web server, the last function we will be considering here also requires additional software. However, this is freely available from the web itself. To access the free software, simply visit the IBM Internet Connection Server site at, register, and download the code.


So what is a web server and why would you want one? I can answer the first question but you will have to decide the second issue.

A web server is a TCP/IP application that services requests from web browsers such as the WebExplorer and Netscape. These requests are generally for Hypertext Markup Language (HTML) text files and for a variety of image and audio files and are presented to the server via the Hypertext Transfer Protocol (HTTP).

The web server is actually just another TCP/IP daemon like ftpd and telnetd. In this case, it is called httpd and it listens to port 80 for HTTP requests. Unlike ftpd and telnetd, it is not suitible for running under inetd due to the simple get/send/disconnect nature of the HTTP protocol.

Browser requests can also cause scripts or programs to be executed on the server to perform various work tasks. These scripts can be written in a variety of languages including C, C++ and REXX. Web servers can also act as interfaces to FTP servers and can create visual file lists in your browser. Selecting a file will cause it to be transferred to your workstation.

In summary, web servers provide a framework for distributing files and documents and for creating network centric applications without a great deal programming skill.

Managing the Environment

System Management is a big topic and, when you are managing an environment with thousands of workstations, servers and LANs, it can be quite complex unless you are helped by tools costing big dollars. Although we need to manage our home LAN just like anything else, the environment is much simpler which means we don't have to invest in expensive tools.

For starters, the number of workstations borders on the trivial. My network has two workstations today and may in time grow to four or five. In addition, there is just a single LAN segment and no WANs to consider. Managing this is not an arduous chore. However, it still has to be done.

This section will deal with the management tasks we might need to do and will briefly describe the tools we have to perform those tasks. As before, all these tools are built in to the kit that comes with the OS/2 Warp Connect package. The following task areas will be covered:

  • Remote Administration
  • Problem Management
  • Monitoring the Environment
  • Data, Users and Printers

Remote Administration

Remote Administration covers managing key resources from your own workstation without running around all over the place. Generally speaking, you would mostly be concentrating on administering your designated servers. Managing user workstations is probably more than the average home LAN needs to achieve. The following tools are key to this area:

FTP-PM Utility

As we described in Transferring Files with FTP, the FTP-PM utility is used to transfer files to and from workstations connected by TCP/IP using the File Transfer Protocol (FTP). As far as remote management is concerned, FTP-PM is used to move files on and off the designated servers. This can range from new application data files to an updated CONFIG.SYS file.


The NET ADMIN command is an OS/2 Peer command used to execute commands against a selected server. The general format is:

NET ADMIN \\serverid /C command

Any command can be run as long as it will run in a detached session. Prompted input or Presentation Manager are not available. Specifying no command opens a remote command session with the remote workstation. You can issue multiple commands on the command session command line. Enter EXIT to terminate it. To use the NET ADMIN command, you must be authorised as an administrator at the server.

Telnet Command Line

Telnet is a network terminal emulator that enables you to connect via TCP/IP to the target workstation. The Telnet window then contains a remote command line from the remote workstation.

To use Telnet with a remote workstation, the Telnet daemon, telnetd, must be started on that workstation. This may be configured in the same way as the FTP daemon as described in topic Transferring Files with FTP.

Another tool that bears mention is the SETBOOT command. Amongst other things, this enables you to reboot the remote workstation by issuing it from either the NET ADMIN command line or the Telnet command line. When issuing it from the NET ADMIN command line, you must specify the full pathname (the OS2 directory).

This command enables you to implement system changes, for example an updated CONFIG.SYS transferred using FTP-PM, and then reboot the system all without laying a hand on it. The command will close the file system but doesn't close any applications down so ensure you notify users to logoff and so on. Make sure the remote system will reboot to a fully operational state.

Talking about notifying users, a useful administration tool is the Network Messaging utility found in the OS/2 Peer folder. This is usually configured to start automatically on system boot after a normal system install. Using it, you can send messages to individual users, groups of users and broadcasts to the entire user community. Use it to notify users of administration events such as close down for reboots and so on.

Problem Management

Problem Management in the home LAN context is the arduous task of analysing an error situation to work out what has gone wrong and what needs to be done to fix it. There are a number of tools that can be used here:


This file, found in the \IBMCOM directory on your boot drive, is a trace of the startup of the LAN interface. If you are having troubles starting the LAN drivers or, for example, NetBIOS resources are insufficient, the messages in this file will generally show where the problem has occurred and may indicate what you need to do to fix it. One of the things shown is the LAN Adapter Address (LAA) the interface is using.


This utility is part of the LAN Distance product and can be found in the LAN Distance directory, \WAL, on the boot drive. It is used to establish whether or not a message can be sent to a particular LAN adapter. The following command format is sufficient for most purposes:

OS2PING /a=xxxxxxxxxxxx

The xxx... parameter represents the target LAN adapter address (LAA). If no response is received, you can infer that there is no LAN path between your machine and the specified target. If the LANTRAN.LOG for both indicates a good initialisation, it may be time to check hubs and wires. Full OS2PING operating instructions may be found in the OS2PING.INF online manual, also found in \WAL.


This utility is used after the basic LAN is in place. In other words, LANTRAN.LOG shows good and OS2PING is reaching all the other workstations. PING is used to check if a TCP/IP packet can be sent from your workstation to another. The IP address of the other workstation is used as the target address. Multiple responses are sent back. To terminate, press Ctrl-Break.

If no responses are received, a TCP/IP connection is not available between the two machines. It is then time to check the TCP/IP configurations on each and stuff like the subnetwork mask, IP address and so on. Issuing the NETSTAT command on each workstation will show information about the local TCP/IP network connection that may be useful in this situation.

Peer Error Log

This is a log of all errors encountered by the OS/2 Peer product. You can view it using the Error Log icon in the OS/2 Peer folder. To see details on any particular message, select it and use the Error details... menu item on the Selected pulldown menu.


This is a set of related management and monitoring facilities that is installed as part of OS/2 Warp Connect. The following facilities are provided:

  • System Error Log
  • Message Console
  • Message Log Formatter
  • Dump Formatter

These tools are most useful for gathering diagnostic information for use in reporting problems to IBM or other vendors.

Other TCP/IP Facilities

Finally, there are a bunch of other tools supplied as part of TCP/IP to enable you to run packet traces, intercept SNMP alerts and so on. These are a bit beyond the scope of this article but once you are comfortable with your LAN, a bit of research playing with these will add to your skills.

Monitoring the Environment

This activity is about checking up on the normal operation of the LAN to make sure all is well, nobody is raiding the cookie jar and you aren't running out of anything. Two tools are useful here:

Peer Statistics

These are a set of statistics maintained by OS/2 Peer showing various totals since they were last reset. You can view them from the Sharing and Connecting application or by issuing the NET STATISTICS command. On the application window, use the Statistics... item on the Status pulldown menu.

On this same menu, you can get a snap shot of the number of sessions other workstations have established with you using the Active sessions... item and see which files they have open on your workstation using the Open files... item.

Peer Audit Log

This tool enables you to check accesses to audit resources. Audited resources are those shared with auditing set on by means of the Audit this resource checkbox on the Grant Access dialog for the resource.

The audit log is viewed using the Audit Log icon in the OS/2 Peer folder. To view the details on any particular entry, select the entry and use the Audit entry details... item on the Selected pulldown menu.

Data, Users and Printers

This topic doesn't actually introduce any new tools. The tools used here are tools we have talked about before. This topic is just a catch-all to remind you of the tasks to be done to complete the Systems Management picture:

Data Management

The first big crash resulting in loss of data or files generally teaches you all you need to know about data management. Back your data up regularly and consistently. I should also add that you should test your restore and recovery procedures regularly to ensure they work. It is no good trying to recover using a backup that is of the wrong data.

If you have a designated server, this can simplify your backup environment to a degree. Ask the users to copy data to the server and then back the server up periodically. The period is up to you but the users should know how long it is and when the backups are actually done.

Centralising the backups like this can mean more data is backed up in one go compared to each individual user backing up their own volatile data. Depending on how much data is involved and how often it needs to be backed up, you may want to invest in a tape or optical disk device to do the backups.

User Administration

User administration is done using the User Profile Management utility as described previously. Each user should be allocated a unique userid. In small families, this could be their first (given) name.

The LAN Administrator should define all new users on common designated servers using the allocated userid and a commonly known password, for example PASSWORD. The Expire password should be checked so that the first time a user logs on, they will prompted for a new password which will become their regular secret password.

Users should define themselves on their own workstations in the same way except they can directly set their passwords. They should also be defined locally as Administrators. Of course, they would probably be defined automatically during installation by responding to the prompts then.

If someone not on a designated server wants to define users to access their resources, that is up to them. However, they should use the same userid for a particular user and expire the password. Using the Basic access control is better in these situations as userids and passwords don't have to be defined and thus don't have to be maintained.

After they are defined, it is up each user to manage their passwords on each server to which they have been granted access. This is done using User Profile Management. First logon locally using the UPM Logon icon then start the User Account Management utility. Select Remote peer workstation and specify a remote workstation with your userid defined on it. Use the Change password... menu item on the Actions pulldown menu to change the password. To go on to the next workstation, use the Select destination... menu item on the same Actions pulldown menu.


Printer administration is mostly a matter of setting up and sharing the printer definitions on the designated servers and clearing the odd paper jam. To assist in setup tasks, a Remote Admin cascade menu item is available on the context menu of any network printer.

The facilities hanging off this menu item enable you to create, copy and delete printer definitions on a server workstation from any workstation you might be on at the time. You must be logged on as an administrator for the target and source workstation.

Another thing you may want to set up in a shared environment is a printer separator page for each network printer. This is an extra page printed at the start of each print job containing details such as the userid of the job submitter. I have one on my laser printer which is used for bulk jobs but not on my colour inkjet which tends to be used for smaller jobs.

The separator page is specified in a text file containing a set of special codes that the print system substitutes when the file is printed. This separator file is associated with the printer by entering its name and path in the Separator File field on the Print Options page of the printer's settings notebook.

OS/2 Warp Connect comes with two sample separator page files, PSCRIPT.SEP for PostScript printers and SAMPLE.SEP for most of the rest. Essentially, the separator page lays out the page and inserts the special controls that the print subsystem uses to insert data. For example, the control sequence @N is substituted with the userid of the job submitter. A full list of these codes may be found in the help associated with the Separator Page field in the printer settings.


I have been doing the stuff I describe in this article for years now in large enterprise customers with complex mixes of workstations, enterprise and departmental servers and interconnected heterogenous networks. So when I set out to write this article I thought "A piece of cake, a short review of a simple environment based on a single product, OS/2 Warp Connect". Hmmm! It didn't work out quite like that did it!

In fact this very lengthy article just skims the surface of an area that really requires a large knowledge base to operate in professionally. One of the interesting things I discovered while writing the article is exactly how much knowledge is there and how unconsciously I exercise it on a daily basis.

However, that said, I feel that although there is a lot to learn in the longer term, the whole thing is based on some relatively simple concepts and some reasonably easy to use tools. Hopefully, this article will get you started on using them to enable you to design, implement and run a home LAN environment without investing a lot in training, reading and further education.