PreviousCCILU2 Communications Module States Calling CCI Functions by ValueNext"

Chapter 5: Configuring TCP/IP and the VSL for DOS and Windows

This chapter describes how to configure TCP/IP and the Virtual Sockets Library (VSL) for DOS and Windows.

5.1 The Configuration Process

CCITCP is supplied with support for PC/TCP V2.1 or later from FTP Software Inc. under DOS and Windows 3.n, and without support for XM.

If any other TCP/IP or XM support is required, you must make the following configuration changes:

  1. Check the table in the section Intermediate Support Modules to confirm that the TCP/IP transport vendor's product is supported and which modules will be required for execution.

  2. DOS:
    Under DOS systems, msocklib.rc and vsldos.ini will be copied to the exedll subdirectory during installation, and vsldos.ini must be edited using information from the table below.

    Under Windows, msocklib.dll, msocklib.rc, and vsl.ini must be copied to the Windows system subdirectory and vsl.ini must be edited using information from the table below.

  3. Set the VSL environment variable to point to the directory containing the two files mentioned in point 2, if this subdirectory is not already on the PATH.

  4. Execute any .exe files identified in item one.

  5. Run the setup installation utility (located in the exedll directory) by entering:
    Setup CCITCP 

    and choose one of the following options:

CCITCP is now ready for use.

After the initial installation, you are only required to repeat step 4 above. This should ideally be placed in your autoexec.bat file. It must be executed after the TCP/IP transport provider software is loaded to ensure that support for CCITCP is always present on the system.

5.2 Intermediate Support Modules

An intermediate support executable (.exe and/or .dll for Windows, .exe only for DOS) is required for CCITCP to operate with the following TCP/IP vendors products.


TCP/IP Product

DOS and Windows 3Com 3+Open TCP V1.1

DOS and
Beame & Whiteside
DOS and
D-Link TCP/IP for DOS V2.0 mlocus2.exe
DOS and Windows FTP Software PC/TCP
for DOS
DOS and Windows FTP Software PC/TCP
for DOS
DOS and Windows HP ARPA Services for

DOS and Windows Locus TCP/IP for DOS V2.0 mlocus2.exe
DOS and Windows Microsoft LAN Manager TCP/IP V2.1 m3open.exe
DOS and Windows Novell LAN
Workplace for DOS
V4.00 V4.01
DOS and Windows Sun PC-NFS TCP/IP V3.0
DOS Sun PC-NFS TCP/IP V4.0a via either of the above
Windows Sun PC-NFS TCP/IP V4.0a mpcnfs4.dll
Windows Sun PC-NFS TCP/IP V5.0b
mpcnfs4.dll or use default Winsock V1.1 support
DOS and Windows Ungermann-Bass Net/One TCP/IP V16.4
Windows Windows Sockets TCP/IP
Support Stacks
NetManage NEWT
Chameleon TCP
Frontier Tech Super-TCP
V1.0 rev c mwsock10.dll

In the above table, entries marked for "DOS and Windows" denote that the same module should be used for both operating systems. Entries marked for "DOS" or "Windows" without the "and" indicate that an operating system specific driver should be used. Not all network TCP/IP transport providers are available for both operating systems.

Where many versions are listed for a particular TCP/IP transport provider, the driving module listed against the first version applies to all subsequent versions unless otherwise stated.

There is a section for each TCP/IP transport provider with more detailed information about configuration located at the end of this chapter.

5.3 Configuring Support Files

In DOS environments, msocklib.rc and vsldos.ini are located in the exedll subdirectory and the VSL environment variable should be set to point to this directory.

In Windows environments, msocklib.dll and vsl.ini should be placed in the Windows system directory (where win.ini is located), and the VSL environment variable should point to this directory.

When installing for both DOS and Windows, we recommend that you locate all required files in the main Windows directory to avoid the need to reset the VSL environment variable when moving between the two operating systems.

The files vsldos.ini (under DOS) and vsl.ini (under Windows) must be edited to identify the TCP/IP support module to be used. For example, the default network support vendor is "ftp"; therefore the line reads:


To change this to Beame & Whiteside TCP/IP, change the line to:


The current list of available support modules is held in a table within the vsl.ini configuration file in the following format:

3open="3Com 3+Open TCP"
3open2="3Com 3+Open TCP version 2.0"
bw="Beame & Whiteside TCP/IP"
dlink="D-Link TCP/IP for DOS"
novlwp="Novell LAN WorkPlace for DOS"
ftp="FTP PC/TCP"
hparpa="HP ARPA Services for DOS"
locus2="Locus TCP/IP for DOS"
lanman="Microsoft LAN Manager TCP/IP"
pcnfs="Sun PC-NFS"
pcnfs2="Sun PC-NFS v3.5"
pcnfs4="Sun PC-NFS v4.0"
netone="Ungermann-Bass Net/One"
wintcp="Wollongong WIN/TCP for DOS"
pathway="Wollongong PathWay Access for DOS"
winsock="Generic Windows Sockets TCP/IP"

This table is subject to change, so you should check the exact entry that is required from within the actual .ini files concerned before updating the network= entry in the .ini file.

If XM support is required, the following line must appear in vsldos.ini:


This determines CCITCP's extended memory execution behavior. When invoked in protect mode by a DOS extender, such as XM, CCITCP tries to fulfil its memory requirements using DOS dpmi services if present, if not then XM services will be used if they are present.

If either DOS DPMI (v0.9 or later) or XM (1.4.4 or later) are not present, unpredictable results may occur when CCITCP is loaded into protected mode memory using a DOS extender.

5.4 Loading TSR Support for VSL

Having identified the TCP/IP vendor's product that will run CCITCP, you should load the .exe, if any, that is required to invoke the VSL support layer before CCITCP is invoked.

When using VSL modules to support CCITCP, each TCP/IP vendor's configuration is unique. See the section VSL Support for CCITCP for details on vendor specific products and VSL.

5.5 VSL Support for CCITCP

Any VSL support which uses an .exe TSR file for support can be used for CCITCP support under DOS. Both .exe and .dll can be used for Windows.

TSRs are required to be loaded in base memory for access to the selected network transport. Therefore we recommend that when a choice is possible you use .dll modules to support Windows applications.

The following sections describe how to install and use VSL support for the CCITCP communications module.

5.5.1 VSL Support and TCP/IP

TCP/IP stacks are supported with this release.

The sections specify which TCP/IP stacks are supported at this release, the version numbers specifically validated, and any pertinent transport-specific information.

In general, it is not recommended that you attempt to load any of the VSL2 network-specific TSRs in winstart.bat. It should be possible, depending on your particular configuration, to load the VSL2 TSRs high with DOS V5.0, to maximize the amount of DOS memory available to applications.

Note: TSRs may be unloaded from memory by using the /u flags when invoking them from the command line. If any other TSRs have been loaded after the VSL2 TSRs, it may not be possible to unload the VSL TSR from memory. An appropriate warning message will be displayed on the screen in these circumstances.

Currently, TSRs loaded high cannot usually be unloaded. Com 3+ Open TCP

The VSL provides the following 3Com TCP support:

The TCPCONNECTIONS parameter in the TCP/IP section of protocol.ini determines the number of concurrent TCP connections allowed by 3Com TCP.

See the section Microsoft Lan Manager TCP/IP for details of updated sockets.exe modules which are also relevant with this product. Beame & Whiteside TCP/IP

The VSL provides support for Beame & Whiteside TCP/IP versions 2.2, 2.3, and 3.0 in the mbw.exe TSR file.

If you experience problems with Beame & Whiteside TCP/IP which seem to indicate data loss or some other degree of unpredictability, try increasing the buffer space for incoming packets configured in the BWCUSTOM utility to, say, 30,000 or 50,000. Typically, a "Printer not ready" error message from Beame & Whiteside TCP/IP indicates lack of buffer space.

With earlier versions of TCP/IP (for example, V2.2), Beame & Whiteside recommend that you use NDIS network interface drivers rather than specific native drivers when running under Windows. D-Link TCP/IP for DOS

The VSL provides D-Link Locus TCP/IP V2.0 support in the mlocus2.exe TSR file.

This is an OEM version of Locus TCP/IP for DOS. See the section Locus TCP/IP for DOS. FTP PC/TCP

The VSL provides FTP Software Inc. PC/TCP V2.04, V2.05, and V2.1 support in the mftp.exe TSR file. For PC/TCP V2.2, V2.3, V3.0, V3.1 and V4.0 support, use the mftp22.exe TSR file.

Add the following entry to the [pctcp kernel] section of the pctcp.ini file:


It is recommended that FTP PC/TCP Virtual Device Driver (VxD) is used under Windows in order to avoid transmission problems with data buffers greater than 8K.

The FTP PC/TCP Virtual Device Driver (VxD) is required in order to run other FTP applications alongside VSL-derived applications over FTP TCP/IP under Windows.

Ensure that you allocate enough TCP and packet buffers for your application within the FTP kernel.

For example:

kernel-name  -t  16  -p 20

allocates 16 TCP connections and 20 packet buffers.

Device driver entries for ipcust.sys and ifcust.sys must be configured into config.sys even for V2.1 and V2.2 of FTP PC/TCP which, theoretically, uses the new configuration mechanism. Version 2.3 of PC/TCP does not require these drivers to be loaded.

Intermittent problems with FTP when using a packet driver can usually be cured by running with a packet driver at least at V7.3.

Once the maximum number of connections has been reached, it may prove difficult to effect any connection thereafter until all, or almost all, connections have been closed. You are therefore recommended to set the maximum number of connections to a higher value than you will actually need.

The maximum number of concurrent connections supported under FTP is 19. FTP PCTCP Process Limits

The TCP/IP processing for CCITCP is performed in two domains: the transmission control protocol (TCP) domain, which contains CCITCP server-client connections, and the unconnected datagram protocol (UDP) domain, which is used to make the connection to the ccitcp2 process.

CCITCP requires two TCP connections for its own use, so in the TCP domain, you must allow 2+(n*2) TCP connections, where n is the number of CCI-Connect and CCI-Initserver calls that the user program will make to or from the DOS machine concurrently.

The FTP PCTCP kernel for DOS sets limits on the actual number of network connections that can be used at any time. For V2.05 of PCTCP for DOS, this default limit is four TCP connections (for the limits on previous or later versions of this software, refer to your FTP documentation).

You can configure the number of TCP connections when installing PCTCP using the file pctcp.ini for version 2.1 or later, or the following command:

kernel  -t number-of-TCP-connections 
        -u number-of-UDP-connections

for example, the command line:

wd8003 -t 6 -u 7

would force a Western Digital card based kernel to load buffers for six TCP connections and seven UDP connections.

Note: You may want to use the PCTCP utility "inet conf" to check that the configuration has worked. Since the PCTCP kernel itself uses two UDP connections, the UDP connections will show two more than the command line configuration requested.

Additionally, due to a trade-off of RAM against network connections, you are recommended to use later versions of PCTCP, which inherently use less RAM for the kernel.

You can configure up to 32 TCP and UDP connections in total using the DOS PCTCP kernel. As noted previously, the TCP ports can be directly mapped onto the number of concurrent CCI-Connect and CCI-Initserver statements used, plus two extra transient UDP connection for each CCI-Initclient or CCI-Initserver routine used. The actual maximum number of possible connections varies slightly from kernel to kernel. However, due to an internal limitation within FTP's kernel, only 20 connections may be used for CCITCP at any one time. See your FTP documentation for further information.

If you encounter any unexpected behavior when using PCTCP for DOS, try increasing the number of available connections, especially if you are invoking more than one CCI-Connect statement within any program and using a local DOS CCITCP2.

Due to an operating system restriction, CCI-Receiveall will only give valid results for 20 clients. HP ARPA Services for DOS

The VSL provides Hewlett Packard ARPA Services for DOS support in V.2.1 in the file mhparpa.dll for Windows, and m3open.exe for DOS.

See the section Microsoft Lan Manager TCP/IP for details of updated sockets.exe files which are also relevant with this product. Locus TCP/IP for DOS

The VSL provides Locus TCP/IP V2.0 support in the mlocus2.exe TSR file.

Locus TCP/IP for DOS is a pseudo bsd4.2 implementation. Consequently, only client-side functionality is supported for this transport. To be specific, the following CCITCP functions are NOT supported for Locus TCP/IP:

Configure the number of connections by using the -s argument to the LTCPIP program.

For example:


configures 8 connections. Microsoft LAN Manager TCP/IP

The VSL provides Microsoft LAN Manager TCP/IP V2.1 support in the m3open.exe TSR file.

Ensure that the NUMSOCKETS parameter in the SOCKETS section of tcputils.ini is set to the maximum concurrent number of connections required.

Ensure that you invoke the socktsr.exe TSR or the sockets.exe TSR located in the \lanman\arpa directory

If you are using a version of TCP/IP that requires the use of the m3open.exe (V2.1.5 or later) module, contact your Micro Focus Product Support representative to obtain the upgrade file sockets.exe. This file is needed to enable full support for this module. This file is the property of Microsoft Corporation and will appear in a future release of all TCP/IP modules supported by the m3open.exe TSR; therefore, carefully check the installed sockets.exe file to ensure that it is of the same date or later than the module supplied by Micro Focus.

If you were previously using socktsr.exe, replace that module with sockets.exe. This should not affect the operation of any other TCP/IP applictations that you may have running.

Full details of installation are contained within the .zip file that is used to deliver the sockets.exe module. Microsoft 32-bit TCP/IP V3.11b

Please use the Generic Winsock V1.1 CCITCP support from the installation utility when using this product. Novell LAN Workplace for DOS

To ensure correct operation of CCITCP, apply Novell LAN Workplace update LW42T3.EXE. This can be obtained from the Novell Netwire sites on the Internet at or from CompuServe.

The VSL provides Novell LAN Workplace V4.00 and V4.01 support in the mnovlwp.dll file.

We recommend that as new releases of TCP/IP appear, you test these for functionality before using the sockets.exe module supplied by Micro Focus. The problems requiring the use of this module may have been corrected in the new TCP/IP software release.

If more than 20 UDP and TCP sockets are allocated in total in net.cfg it may be the case that no UDP sockets are accessible.

When using Windows, Novell LAN Workplace for DOS will only work successfully when Windows is running in enhanced mode.

The dotted decimal IP address should be used when specifying the host name of the machine running the ccitcp2 registration process. Under DOS, this is done using the CCITCP2 environment variable. Under Windows, it is done using the CCITCP2 entry in the cci.ini file.

set CCITCP2=
[ccitcp-base] CCITCP2= Sun PC-NFS TCP/IP

The VSL provides support for the following Sun Microsystems PC-NFS TCP/IP support:

The size of the PC-NFS libraries necessarily linked into the mpcnfs.exe TSR is extremely large. To reduce memory occupation, should it be a problem, try using the /c number argument to reduce the number of concurrent sockets managed by the TSR, or switch to the PC-NFS 3.5 or above products. V3.0 supports a maximum of 8 sockets.

If you experience problems with Sun PC-NFS V3.01, you should update to V3.5 or later.

The Sun Resident Transport Module, rtm.exe, must be loaded prior to invoking Windows with V3.5 or later. The /HEAP parameter must be specified with rtm.exe if more than 8 sockets are required. Each connection consumes 4 Kbytes, so RTM /HEAP 60 specifies the maximum 15 sockets.

With V3.5, either rnmfile.exe or rnmnis.exe should be run after rtm.exe is loaded. You should run rnmnis.exe if you want to use Yellow Pages (NIS), if not, run rnmfile.exe.

See subdirectory \exedll\vsl\nfs on the release disk for more information from Sun on V3.5.

mpcnfs4.dll will only work with V4.0a of PC-NFS. There are some files available from Sun that you can ship with your application to upgrade any version of PC-NFS to V4.0a.

Specific TSR command line arguments:

MPCNFS    /n256 Packet buffer size, default 512. Determines the size of network packets.
MPCNFS    /r512 Read/Send buffer size, default 1024. Determines buffer sizes.
MPCNFS    /y Specifies that Sun Yellow Pages facility (NIS) is being used. Ungermann-Bass Net/One TCP/IP

The VSL provides Ungermann-Bass Net/One TCP/IP V16.4 and V16.5 support in the mnetone.exe TSR file.

If you experience intermittent problems with Net/One V16.4, you should update to V16.5 or later. Windows Sockets TCP/IP Stacks

Windows Sockets provides WinSock v1.0c TCP/IP support.

The VSL Generic Windows Sockets DLL is written to expect Windows Sockets compliant stacks conforming to the Windows Sockets specification Version 1.0 Revision C.

The following TCP/IP vendors Windows Sockets stacks have been validated with the mwsock10.dll file:

In some cases, it may be desirable to install VSL support for TCP/IP systems which support the Generic Winsock V1.1 specification interface. This is enabled by using the mwinsock.dll file and using the entry transport=winsock in the vsl.ini file.

As more vendors move towards Generic Winsock V1.1 compliance, it is increasingly likely that the latter option should be used if a winsock.dll module is present in your chosen TCP/IP vendors package.

Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousCCILU2 Communications Module States Calling CCI Functions by ValueNext"