			         README.TXT
			     PC/TCP ONNET 1.2
			 PC/TCP NETWORK SOFTWARE 3.1

				 Contents


	1. Installing PC/TCP OnNet and PC/TCP Network Software 
	   1.1	Using Multiple TCP/IP Protocol Stacks  
	   1.2	Choosing a DOS or Windows Install
	   1.3	Upgrading
	   1.4	Installing with Windows for Workgroups 3.11
	   1.5	Removing Obsolete Parameters	
		1.5.1  Removing Parameters from the
		\WINDOWS\SYSTEM.INI File 
		1.5.2 Removing Parameters from the AUTOEXEC.BAT File  
	   1.6	Possible Problem With NDIS 1.X, PROTMAN.DOS, and
		NETBIND  
	   1.7	Deleting Files During an Upgrade from PC/TCP Network
		Software, V2.3  
	   1.8	Installing Multiple Kernels, and Adding New
	        Components or Interfaces  
		1.8.1  Installing More than One Type of Kernel
		1.8.2  Installing Both a TSR and a VxD Kernel (OnNet only)
	   1.9	Decompressing Files
	   1.10  Installing PC/TCP with Microsoft Chicago (Windows 95)  
	2. Kernel Name Resolution and Third-Party Applications
	3. TN Negotiating the X-Display Option
	4. Resizing the PC/TCP Windows TNVT Scrollback Buffer
	5. PC/TCP Windows FTP Server and Server Control Applications 
	6. New Functionality for OnNet 1.2/PCTCP 3.1
	   6.1 Network Time, Windows Time Synchronization Client
	       6.1.1  TZ Environmental Variable Examples
	       6.1.2  Network Time Application Time Zones Converted to
		      DOS TZ Format
	   6.2 NFS Autotuning
	   6.3 New Kernel Features
	       6.3.1 FDDI Suport
	       6.3.2 New Parameters in the [pctcp kernel] Section of the
		     .INI File
	   6.4 Installing and Using Mail OnNet
	       6.4.1 Overview
	       6.4.2 Mail  OnNet Configuration
	7. Known Problems

1.  Installing PC/TCP OnNet and PC/TCP Network Software

1.1  Using Multiple TCP/IP Protocol Stacks 

Two TCP/IP protocol stacks cannot run simultaneously over a single
network card and driver.  Both TCP/IP stacks require the same packets
(such as IP and ARP), and the driver can give these packets to only
one stack.  Because of this, you cannot use PC/TCP concurrently over
a single network card with another TCP/IP protocol stack, such as
Microsoft TCP/IP.

1.2  Choosing a DOS or Windows Install

The INSTALL.EXE program in DOS does not install any Windows files or
configure the product to run in Windows.  To use PC/TCP in Windows,
you must use the PC/TCP Windows SETUP.EXE program.  For more
information on how the Install program lets you choose networking
programs in Windows or in DOS, see the PC/TCP manual "Getting
Started" and the PC/TCP Release Notes.

1.3  Upgrading

If you are upgrading, exit any PC/TCP Windows applications before
you run SETUP.EXE.  The kernel and other TSRs, such as InterDrive,
can be loaded when you run the Setup program.

1.4  Installing with Windows for Workgroups 3.11

When installing with Windows for Workgroups (WfW) 3.11, you must use
the WfW Network Setup program to install an NDIS driver before
running the PC/TCP SETUP.EXE. You usually do this at the time you
install Windows for Workgroups.  For PC/TCP Networking Software (TSR
kernel), choose a Real Mode NDIS Driver. For OnNet (VxD kernel),
choose an Enhanced Mode NDIS driver (or if you want to manually switch
between the VxD and TSR kernels, choose "Real Mode and Enhanced Mode
NDIS Driver").  You can also run over ODI drivers under WfW with
either the TSR or the VxD kernel.  

See the installation procedures in the manual "Managing PC/TCP" for
more information.  

1.5  Removing Obsolete Parameters 

1.5.1  Removing Parameters from the \WINDOWS\SYSTEM.INI File

The following SYSTEM.INI lines were required in the PC/TCP Network Software
V2.3 release, but are now obsolete.  The Install program removes any
of these entries:

	[386Enh]
	device=wfwftp.386
	secondnet=wfwftp.386
	device=vpctcp.386
	secondnet=vpctcp.386

Install does not remove the dis_pkt.gup entry from  the  Windows SYSTEM.INI
file. This entry does no harm, but you can remove it if you do not intend to
use the TSR kernel.

1.5.2  Removing Parameters from the AUTOEXEC.BAT File

Setup, when installing the VxD kernel, will remove netbios.com, idrive.exe,
idmnt.exe, idnet.exe and setclock.exe commands from AUTOEXEC.BAT
because the VxD does not support networking in DOS. If you have other
network commands in AUTOEXEC.BAT, the commands will fail.

If the netbios.com command is in AUTOEXEC.BAT, Setup adds the
parameter "vnbep=yes" to the [pctcp vxdinit] section of the PCTCP.INI
file. If the idrive.exe command is in AUTOEXEC.BAT, Setup adds the
parameter "vidrive=yes" to the [pctcp vxdinit] section of PCTCP.INI.
This provides NetBIOS and InterDrive functionality under Windows
using the VxD kernel, if you were previously using this functionality.

If you are using setclock.exe in AUTOEXEC.BAT you can add the NETTIME.EXE
to your startup program group to get the same functionality that setclock
provides on Windows startup.  Refer to section 6.1 "Network Time, 
Windows Time Synchronization Client" in this README and the "Using PC/TCP 
in Windows" guide for more information.

1.6  Possible Problem with NDIS 1.X, PROTMAN.DOS, and NETBIND

The install and setup programs copy the NDIS 2.xxx redistributable
files PROTMAN.DOS and NETBIND.EXE when you install an NDIS driver. If
you already have older copies of these NDIS files, and the netbind
command in AUTOEXEC.BAT does not include a path, the netbind command
may fail.

The \PCTCP directory is added to the path first.  This causes the new
version of netbind to run, which is not compatible with the old
version of PROTMAN.DOS in the CONFIG.SYS file.

To resolve this, either add the complete path to the old netbind
command;  or, change the pathname in CONFIG.SYS to use the new
PROTMAN.DOS in the PCTCP directory.

1.7  Deleting Files During an Upgrade from PC/TCP Network Software, V2.3

The install program is conservative in choosing the files it deletes
when upgrading into the same directory. It does not delete the
following old files, which you may want to delete manually:

  aexecftp.bat		  autoinst.cwa
  autoinst.exe		  autoinst.hlp
  board.dat		  config.ins
  ftp.ico		  kappconf.cwa
  kappconf.exe		  kappconf.hlp
  kappconf.pif		  lpq.ico
  lpr.ico		  mail.ico
  merger.exe		  pctcp.aib
  pctcp.ico		  ping.ico
  protocol.ftp		  samp_net.cfg
  system.ftp		  template.ini
  tn.ico

To see which files are removed, see the [remove] section of FILES.INF.

1.8  Installing Multiple Kernels, and Adding New Components or Interfaces

1.8.1  Installing More than One Type of Kernel

If you use your computer over both a LAN (Local Area Network, such as
Ethernet) and a Serial port using SLIP or PPP, you need to install
two kernels and to configure multiple interfaces during that
phase of the configuration.

1.  Run the Install program.
    If an existing driver is found, you should choose not to use it.
2.  Choose Serial port using SLIP or Serial port using PPP from the
    list of Network Cards. 
3.  Run the install program a second time.
4.  At the Reinstallation dialog box, choose Add.
    If an existing driver is found, you should choose it; otherwise,
    choose your driver from the list of network cards.

1.8.2  Installing Both a TSR and a VxD Kernel (OnNet Only)

This is now the default behavior of OnNet 1.2. If you prefer only
the VxD or TSR kernel, use the custom install option.

1.9  Decompressing Files

The PC/TCP files are compressed using a Microsoft compression
utility.  To manually decompress a file from the disks, you can use
the standard Windows EXPAND.EXE utility, usually located in the
\WINDOWS directory.  As described in the hardcopy documentation, you 
can also use the SETUP.EXE /Z or the INSTALL.EXE /Z command.

1.10  Installing PC/TCP with Microsoft Chicago (Windows 4.0)

During its second Beta, Microsoft changed the Chicago
protocol-to-driver interface from NDIS version 3.0 to NDIS version
3.1 to support the dynamic loading and unloading of drivers and
protocols.

FTP Software supports NDIS versions 3.0 and 3.1. If you are a Chicago 
Beta site and need to use Chicago with PC/TCP, contact FTP Software 
Technical Support.

To install NDIS 3.1 support, do the following:

(This assumes that NetBEUI is already installed on your machine.)

	1. There are two files in the pctcp directory: ND3HLP.386 and
	ND31HLP.386. If you work in Chicago, you should delete ND3HLP.386
	and rename ND31HLP.386 to ND3HLP.386. (In the future, the 
	install program will do it for you.)

	2. Copy the PCTCPND3.INF file into the CHICAGO\INF directory.

	3. If you are using a beta version of Chicago that was released 
	prior to October 1994, modify the line in the [ND3HLP.AddReg] 
	section in the PCTCPND3.INF file so that there is no * before 
	ndis, and add .386 after it.  The line should read as follows: 

                HKP,,DevLoader,,ndis.386

	4. Edit the SETUP.INF file in the CHICAGO\INF directory. Add the 
	following line into the [load_inf] section of this file:

		pctcpnd3.inf

	5. Reboot the machine

	6. From the Control Panel, start Network and 

		* Choose the 'Protocol' button.
		* Choose the 'Add' button.
		* Choose 'FTP Software. Inc' in the 'Manufacturers' 
			window.
		* Choose 'NDIS3 Helper for PC/TCP' in the 'Model' window.
		* Choose 'OK'.
		* Choose 'Close'. 
		* Choose 'OK'.

	7. Reboot the machine.

2.  Kernel Name Resolution and Third-Party Applications

To make the PC/TCP TSR kernel smaller, Domain Naming Service (DNS) code
was moved out of the kernel into a separate library.

If you are using applications written with the PC/TCP Development Kit
in an earlier version of PC/TCP that use the PC/TCP kernel for
name resolution, keep the [pctcp kernel] parameter
"kernel-does-dns=yes" in the PCTCP.INI file.  Setting this parameter
to "no" shrinks the kernel by 6.5K.  Set this parameter to "no" if
you do not use old applications that require DNS support in the
TSR kernel, and want to free more low DOS memory.

3.  TN Negotiating the X-Display Option

If you have an X-server running on your system, DOS TN.EXE should
negotiate the X-display option.  If it doesn't, check the [pctcp kernel]
section of your PCTCP.INI file and set "pktdrv-loopback=yes". 

4.  Resizing the PC/TCP Windows TNVT Scrollback Buffer

If you change the size of the TNVT scrollback buffer, TNVT will 
retain (or save) only one screen of data containing the last 25 lines of
the scrollback buffer.  This frees memory resources for other
applications.

5.  PC/TCP Windows FTP Server and Server Control Applications

If you have a file transfer in progress with the Windows FTP Server,
and you attempt to close the Server Control application, Server
Control will not exit cleanly, and you will not be able to reload
Server Control and the servers later.

If you are using the FTP server and have an active file transfer in
progress, first stop the Windows FTP Server, then exit the Server
Control application.

6.  New Functionality for OnNet 1.2/PCTCP 3.1.

6.1 Network Time, Windows Time Synchronization Client

Network Time is a Windows(TM) application that allows the
user to maintain the PC system clock by routinely synchronizing 
it with a Network Time Server.  The only requirement is that the 
Network Time Server support RFC (Request For Comment) 868, which 
is the Time Protocol RFC.  

Network Time can run in a variety of configurations from "single
shot" to "time watch dog."  In its "single shot" configuration,
Network Time (which can be placed into the Windows Startup Group and
configured through Windows to run iconized) is configured to run
once, then exit.  The user may elect to have Network Time simply 
notify them, or to request specific permission to
change the PC clock before it exits. This PC clock update
authorization function is desirable for any PC that is interfacing in
any way with any other network machines since files, or more simply
events, contain time stamps that reflect the PC's time.  If the PC's
clock is too far out of agreement with other machines on the network,
discrepancies can occur that may interfere with productivity.  Time
synchronization between networked machines is of particular
importance for shared files.
	
In "time watch dog" configuration, Network Time can be configured to
check the Time Server in periodic intervals from once a minute, to
once every 45 days.  Users have the option of allowing Network Time
to notify them when it will be updating the PC clock, or explicitly
requesting permission to set the PC clock.  This functionality is
specifically desirable on networks where there is a lot of
communication and shared work, or where almost any form of network
(login) security is invoked.

FTP Software, Inc. originally designed its own method of time zone
handling several years ago into its products to make up for
the deficiencies in using the DOS TZ environment variable.  For
consistency issues, applications from FTP Software, Inc. have always
fallen back to using the DOS TZ environment variable when no PC/TCP
specific time zone information could be found.

The addition of a third format in this release is due to the
inclusion of our new Windows Network Time application.  This
application was designed specifically for Windows users who need a
more sophisticated time zone management system than Windows (or DOS)
alone provides.  It is the intention of FTP Software, Inc. to use
more sophisticated time zone handling in all of our applications, not
just those designed for Windows.

Windows NT, and the Chicago (Windows 95) incorporate a similar time
zone handling philosophy to that incorporated for Network Time (and
ultimately for our other applications as well).  FTP Software, Inc.
will continue to incorporate these new technologies into the product
line as they become available, however, until the release of Windows
95, it is necessary to use the newly designed transition technology
that Network Time uses for sophisticated time zone handling in
Windows, and for the benefit of any application running directly over
DOS that contains (almost) no sophisticated time zone handling at
all.

Mail OnNet is different from all other applications from FTP
Software, Inc. in that it is an acquired technology, and currently
only uses the DOS TZ environment variable.  This will change in the
future to include the newer technology developed for Network Time,
which is designed to fall back to our "old" configuration method for
backwards compatibility, as well as fall back to the DOS TZ
environment variable for worst case configuration scenarios.

FTP Software, Inc. recognizes that ideally a user should have to
configure the time zone only once and in only one place.  We have
done our best to achieve this situation, and to avoid the possibility
that one application will obtain the correct time zone information,
but another application using a different time zone philosophy will
not. Our temporary solution for this is that the install/setup 
program:

         1. Asks you to choose the time zone from our new list.
         2. Writes the new format time zone information to PCTCP.INI.
         3. Converts this new information into the old format and 
	    writes it to the PCTCP.INI file.
         4. Converts this value into the TZ environment variable 
	    format and writes it to AUTOEXEC.BAT.
 
If you need to change the time zone after the install is done:

		1. Run Network Time.
		2. Choose Settings.
		3. Choose Time Zones.
		4. Choose your time zone from the list box.
		5. Choose OK.

This procedure updates your time zone for both the new and old
formats for backwards compatibility.  It will NOT, however, modify
your DOS TZ environment variable for the Mail OnNet application.  Set
the TZ environment variable in the AUTOEXEC.BAT file.

6.1 TZ Environmental Variable Examples

Use the following TZ environment variable examples if you wish to
edit the AUTOEXEC.BAT file.

        Time Zone		   Recommended TZ environment 
				      variable statement 
				     (set in AUTOEXEC.BAT)

    UTC/Greenwich Mean Time		set TZ=UTC0   
					    or   
					set TZ=GMT0

    Australia/Tasmania			set TZ=EST-10EDT
    Australia/Queensland		set TZ=EAT-10
    Australia/North			set TZ=CST-9:30WST
    Australia/West			set TZ=WAT-8
    Australia/South			set TZ=CST-9:30CDT

    Britain				set TZ=BST0BDT

    Canada/Newfoundland			set TZ=NST3:30NDT
    Canada/Atlantic Standard		set TZ=AST4ADT
    Canada/Eastern Standard		set TZ=EST5EDT
    Canada/Central Standard		set TZ=CST6CDT
    Canada/Mountain Standard		set TZ=MST7MDT
    Canada/Pacific Standard		set TZ=PST8PDT
    Canada/Yukon Standard		set TZ=YST9YDT

    Europe/Western			set TZ=WST0WDT
    Europe/Middle			set TZ=MST-1MDT
    Europe/Central			set TZ=CST-1CDT
    Europe/Eastern			set TZ=EST-2EDT

    Iceland				set TZ=WIT0

    Japan				set TZ=JAT-9

    New Zealand				set TZ=ZST-12ZDT

    Singapore				set TZ=SIT-8

    Turkey				set TZ=EST-3EDT

    US/Eastern Standard			set TZ=EST5EDT
    US/East-Indiana			set TZ=EIT5
    US/Central Standard			set TZ=CST6CDT
    US/Mountain Standard		set TZ=MST7MDT
    US/Pacific Standard			set TZ=PST8PDT
    US/Yukon Standard			set TZ=YST8YDT
    US/Hawaii Standard			set TZ=HAT10
    US/Arizona				set TZ=MAT7
    
    Time Zone A				set TZ=A  1
    Time Zone B				set TZ=B  2
    Time Zone C				set TZ=C  3
    Time Zone D				set TZ=D  4
    Time Zone E				set TZ=E  5
    Time Zone F				set TZ=F  6
    Time Zone G				set TZ=G  7
    Time Zone H				set TZ=H  8
    Time Zone I				set TZ=I  9
    Time Zone K				set TZ=A  10
    Time Zone L				set TZ=A  11
    Time Zone M				set TZ=A  12
    Time Zone N				set TZ=A  -1
    Time Zone O				set TZ=A  -2
    Time Zone P				set TZ=A  -3
    Time Zone Q				set TZ=A  -4
    Time Zone R				set TZ=A  -5
    Time Zone S				set TZ=A  -6
    Time Zone T				set TZ=A  -7
    Time Zone U				set TZ=A  -8
    Time Zone V				set TZ=A  -9
    Time Zone W				set TZ=A  -10
    Time Zone X				set TZ=A  -11
    Time Zone Y				set TZ=A  -12
    Time Zone Z				set TZ=A  0


6.2 Network Time Application Time Zones Converted to DOS TZ Format

Following is a brief introduction to (Microsoft's) DOS TZ environment
variable format:

Microsoft's specification with the TZ environment variable states
that the format must be as follows:

			XXX[+|-]hh[:mm][YYY]

where XXX is the three letter abbreviation of the time zone, hh[:mm]
is the hour [and minute, if applicable] offset of the time zone, and
[YYY] is the three letter abbreviation for the daylight savings time
zone, if applicable.  It is because of this format specification that
the "generic" time zones must contain spaces in their designations so
that they comply to the three-letter time zone abbreviation format.  

It has become accepted (not by FTP Software, Inc.) that any time zone
abbreviation that has an 'S' or a 'D' as its second letter contains a
daylight savings time rule in its format.  Whereas the format for the
TZ environment variable does not contain a specific offset for this
time change, it is assumed to be one hour behind the offset
specified.  It is for this reason that FTP Software, Inc. suggests
changing the three-letter designation for time zones that do not have
a daylight savings rule.

FTP Software, Inc. plans to have this time zone configuration
problem entirely resolved for the next release.

	 
6.2 NFS Autotuning

InterDrive has an automatic tuning device to dynamically adjust three
factors that can affect network performance: streaming, read size,
and write size.

In a typical network exchange, one system sends a packet, then waits
for a response from the remote host before sending the next packet.
InterDrive can do what is known as "streaming"; that is, it sends
several packets at a time without waiting for a response for each one
sequentially. Because several packets are being processed
concurrently, writes and reads can take much less time than waiting
for each packet to travel through the network and be acknowledged by
the remote host. InterDrive does require an eventual response for
each packet that it sends. Consequently, streaming can improve
performance without affecting reliability.

Read and write size also affect the speed at which InterDrive
processes data. "Read size" is the size of packets that InterDrive
gets and processes from the NFS server. An example of a read is when
you copy a file from the server to your local PC. "Write size" is the
size of packets that InterDrive formats and sends to the server. An
example of a write is when you save a file to a network drive.

The autotuner establishes an initial packet read and write size and
streaming value based on a number of factors, including the transfer
size requested by the server, the largest packet size supported by
the network, and your PC/TCP kernel configuration. It then
continuously adjusts those values based on the number of successful
attempts by InterDrive to get and send data across the network.

If performance is suffering, the autotuner gradually decreases the
streaming value, then the read and write size, until the number of
retries decreases. After a period of successful transfers elapses,
the autotuner gradually increases read and write size, then
streaming, in an attempt to improve performance even more. The
process of adjustment is continuous based on feedback from the
network, but the values eventually stabilize under normal network
conditions.

Autotuning is enabled by default. If you prefer not to use autotuning, you
can turn it off for a specific file system by entering autotune=no in
the [pctcp idrive filesys] section that defines the file system in
your PCTCP.INI file. If read-size=, write-size=, and stream=
parameters exist in your PCTCP.INI file from a previous release of
PC/TCP software, and if autotuning is off, InterDrive uses the values
specified in your file. With autotuning on, InterDrive starts out
using the specified values, but the values are likely to vary up or down as
a result of the autotuning mechanism.

6.3 New Kernel Features

6.3.1 FDDI Support 

FDDI support was added both in the Kernels and in ODIPKT and DIS_PKT.GUP.

6.3.2 New Parameters in the [pctcp kernel] Section of the .INI 
      file

Turn 0n/Off slow start. This is user-visible parameter. If
a user has 'hang'-like problems with some Windows applications
(the known ones are: HGopher, WinVN, TCP3270, Ingres 4GL, and
Microsoft SQL Admin. Tool), the user should try to set this 
parameter to 'no'. (Default: 'yes' for SLIP and PPP, 'no'
for other media.)
	
do-slow-start = [yes/no]		

6.4 Installing and Using Mail OnNet

6.4.1 Overview

Mail OnNet is a complete mail system running on PCs connected to an 
internet (including the Internet) through an open standards mail 
server. In many installations the server will be running UNIX, but 
it could also be running DOS, OS2, NT, VMS or a mainframe operating 
system.

Because Mail OnNet implements the Internet's MIME standard, you can 
send virtually any type of data across the Internet. You can send 
spreadsheets, formatted text, graphics, sound clips or any of the 
many other types of files you work with. Since the MIME standard is 
backwards compatible, you will be able to send simple mail messages 
to users who do not have a MIME-compliant mail system.

You can use the Mail OnNet application to compose messages 
and to attach files to send with messages. When you receive mail, you 
can use Mail OnNet to read simple messages and view attachments by 
launching other applications. Mail OnNet also has commands for replying 
to messages, forwarding them to other people, and re-sending them as 
attachments to another message.

6.4.2 Mail OnNet Configuration

After the installation is completed, you must configure Mail OnNet before
you can use the application. Refer to Appendix A "Configuring Mail 
OnNet" in the Mail OnNet User's Guide for details.


7. Known Problems

For information, refer to the paper copy of the README.





 
