C-KERMIT 7.0 INSTALLATION INSTRUCTIONS FOR VMS and OpenVMS          -*-text-*-


  As of:  C-Kermit 7.0.196
  This file last updated:  Sat Jan  1 13:29:35 2000

  F. da Cruz, C. Gianone, M. Evarts, Columbia University, New York, NY.
  Terry Kennedy, Saint Peters College, Jersey City, NJ.
  And: Peter Mossel, James Sturdevant, Richard Gilbert, Sebastian Bazley.

  Copyright (C) 1985, 200,
    Trustees of Columbia University in the City of New York.
    All rights reserved.  See the C-Kermit COPYING.TXT file or the
    copyright text in the ckcmai.c module for disclaimer and permissions.


DOCUMENTATION

Please purchase the manual if you have not already done so.  Sales of the
manual are the primary source of revenue for the nonprofit but entirely
self-funding Kermit Project.

  Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Second Edition,
  1997, Digital Press / Butterworth-Heinemann, Woburn, MA, ISBN 1-55558-164-1
  US single-copy price: $44.95; quantity discounts available.  Available in
  computer bookstores or directly from Columbia University:

    The Kermit Project
    Columbia University
    612 West 115th Street
    New York NY  10025-7799  USA
    Telephone: +1 (212) 854-3703
    Email: kermit-orders@columbia.edu
    Web: http://www.columbia.edu/kermit/

  The CKERMIT2.TXT file contains supplementary info for C-Kermit 7.0 to be
  used until the 3rd edition of the manual is ready.


CONTENTS:

  QUICKSTART GUIDE
     I. BOOTSTRAPPING
    II. CONFIGURING VMS FOR BEST RESULTS WITH KERMIT
        1. TERMINAL BUFFER SIZE
        2. USER QUOTAS AND PRIVILEGES
        3. CONFIGURING SERIAL COMMUNICATION PORTS
        4. CONFIGURING LAT DEVICES
        5. THE VIRTUAL TERMINAL DRIVER
        6. CAPTIVE ACCOUNTS AND RESTRICTED ACCESS
   III. DECODING VMS C-KERMIT HEX FILES
    IV. INSTALLING VMS C-KERMIT
     V. USING MODEMS
    VI. BUILDING VMS C-KERMIT FROM THE SOURCE CODE
        1. PROGRAMMING TIPS
        2. VMS TCP/IP NETWORKING SUPPORT FOR C-KERMIT
   VII. CASE STUDY: ALPHA SETUP AND TEST RESULTS
 (VIII. MAKING AND USING VMSINSTAL KITS)


QUICKSTART GUIDE

To install VMS C-Kermit on VAX/(Open)VMS 5.0 or later, and Alpha OpenVMS
(all versions), please follow the instructions in the next three major
sections of this file.  The first section, CONFIGURING VMS FOR BEST RESULTS
WITH KERMIT, contains important information needed to achieve solid
performance from C-Kermit.  Please read it and follow the suggestions or give
it to your system manager.  The second section, DECODING VMS C-KERMIT HEX
FILES, explains the process required to create an executable image from the
"text-only" HEX files.  These HEX files are distributed on the ANSI tapes from
Columbia University and are decoded using an assembly-language program which
is also provided.  If you have received VMS C-Kermit on TK50 tape in BACKUP
format, then you already have binary executable files included on the tape.
The third section, INSTALLING VMS C-KERMIT, provides step-by-step instructions
for making C-Kermit available and fully configured for your users.

If you are running a version of VAX/VMS *prior* to 5.0, or need to customize
the C-Kermit sources, please refer to section IV, BUILDING VMS C-KERMIT FROM
THE SOURCE CODE.


I - BOOTSTRAPPING

In many cases, you can get C-Kermit onto your VMS system using FTP, an old
version of Kermit that is already there, or some other existing file transfer
method, or by copying it from magnetic tape, diskette, or CDROM.

In case none of those methods are available to you, here is a method to
"bootstrap" C-Kermit onto a VAX system from another computer.  It uses the
older and smaller "Kermit-32" program (which runs only on VAXes, not Alphas)
to load the newer and larger C-Kermit program.

Suppose, for example, you have a PC with DOS, Windows, or some form of UNIX
such as Linux, which has FTP capability, and the PC is connected to your VAX
through its serial port (directly, with a null modem cable, or else through a
modem), and the PC already has its own Kermit program installed (MS-DOS
Kermit, Kermit 95, or C-Kermit, depending on the OS).  Here are specific
instructions you can try; this example assumes the PC has Linux and C-Kermit:

  1. Get the files vmsmit.hex and vmsdeh.mar with anonymous ftp in text mode
     onto your PC from kermit.columbia.edu, directory kermit/b.  Also get
     the appropriate version of VMS C-Kermit on your PC from the same site.

  2. Use C-Kermit on Linux to log in to your VAX:

       set line /dev/ttyS0 ; or whatever
       set speed 19200
       set flow xon/xoff
       set transmit eof \26
       connect

  3. Log in to VMS, SET DEFAULT to the desired directory, and then give
     the following commands at the VMS prompt:

       set terminal /ttsync /hostsync

  4. Give the following command at the VMS prompt:

       create vmsmit.hex

  5. Escape back to C-Kermit on Linux with Ctrl-\ C.

  6. Tell C-Kermit to:

       transmit vmsmit.hex

  7. Repeat steps 4-6 for VMSDEH.MAR.

  8. Now you should have VMSMIT.HEX and VMSDEH.MAR in your VMS directory.
     Give the following commands to VMS:

       macro vmsdeh
       link vmsdeh
       run vmsdeh

  9. When VMSDEH prompts for a filename, type "vmsmit.hex".

 10. When VMSDEH is finished, it will prompt you for another filename.
     Just press the Enter (Return) key.

 11. Now VMSMIT.EXE should be in your directory.  To run it, type:

       run vmsmit

     at the VMS prompt.

 12. Use this program to transfer the appropriate version of C-Kermit
     to VMS, and then you will have a modern, fast, up-to-date
     version of Kermit.

WARNING: You can't use Kermit-32 ("Bliss Kermit") to receive a VMS binary
program.  If you have to use Kermit-32 to get C-Kermit onto your VAX, you'll
need to transfer a hex-encoded version of the binary, rather than the straight
binary, and then "dehexify" the result as shown above.  This is because
Kermit-32 stores incoming binary files in a format that is not appropriate for
VMS executables (variable 510 instead of fixed 512).


II - CONFIGURING VMS FOR BEST RESULTS WITH KERMIT

  II.1. TERMINAL BUFFER SIZE

VMS is shipped with default installation parameters designed to function on
all possible configurations.  Some of these parameters have not been changed
since the "average" VMS system was a VAX-11/780 with 1Mb of memory.

The main parameter that affects Kermit is the terminal type-ahead buffer size,
which applies to serial terminal devices (with the TT or TX prefix).  There
are two possible values in VMS - the "normal" size and the "alternate" size.
The defaults for these are 78 and 200 bytes, respectively.  If more data
arrives at the terminal driver than these buffers can hold (which is a likely
occurrence during file transfer), it will be discarded and file transfers will
be slowed down or terminated by errors.

This is most frequently seen when receiving files on a slow VAX, particularly
when using long packets and/or sliding windows.  File reception requires
larger system buffers (to hold arriving packets), and the speed of the VAX
controls how quickly Kermit can empty them.

The recommended minimum size for each of these buffers is the number shown as
"Buffer size" by the C-Kermit SHOW PROTOCOL command, which is the total amount
of memory allocated by C-Kermit for packet buffers (window slots times packet
length).  VMS C-Kermit is shipped with a buffer size of 9065, which can be
altered by the user with a SET BUFFERS command.

To change the values of the VMS typeahead buffer sizes, you should edit the
file SYS$SYSTEM:MODPARAMS.DAT.  Determine the new values you want to use and
add lines like the following to the end of the MODPARAMS.DAT file:

  MIN_TTY_TYPAHDSZ = new_value_for_regular	! For VMS C-Kermit
  MIN_TTY_ALTYPAHD = new_value_for_alternate	! For VMS C-Kermit

for example:

  MIN_TTY_TYPAHDSZ = 2064
  MIN_TTY_ALTYPAHD = 2064

The TTY_ALTYPAHD size should be at least as great as the TTY_TYPAHDSZ.
Digital recommends a value of 2064 or greater for TTY_ALTYPAHD if you are
running VMS V5.5 or higher, or if you are running the optional LATmaster code
under VMS V5.4-1, -2, or -3.

You should also examine this file to be sure there aren't any other
definitions for TTY_TYPAHDSZ or TTY_ALTYPAHD.  If there are, you'll get
warning messages in the next step.

    You may wish to simply set TTY_TYPAHDSZ=TTY_ALTYPAHD=2064, since
    most common VMS "TTY ports" these days are actually LAT or TCP/IP
    devices, which cannot easily be configured to use the alternate
    buffer.  Also, it takes a privileged user or program to set a port
    to use the alternate buffer, and since we do not recommend
    installing Kermit with privileges, this would restrict Kermit access
    to privileged users.

    Let's consider a medium-sized VAX with perhaps 64 "ports" (either
    serial ports or LAT or TCP/IP network ports).  This system probably
    has at least 16 megabytes of memory.  Configuring TTY_TYPAHDSZ to
    2064 will take up 64 * 2064 bytes of memory, or 132096 bytes.  This
    is less than 1 per cent of available memory.  Most systems would
    have more than 16Mb of memory for 64 simultaneous users, lowering
    the percentage even further.

In some cases, it might also be necessary to increase your system's MAXBUF
parameter.  It should be somewhat longer than the longest packet you want
Kermit to be able to send or receive, to allow for SYS$QIO overhead (the
bigger the value, the more overhead).  DEC currently recommends 2300, which
should be sufficient for 2K (2048-byte) packets.  If you want to use
C-Kermit's maximum packet length, 9024, then your MAXBUF should be set to
about 12000.  Do this in the SYS$SYSTEM:MODPARAMS.DAT file:

  MIN_MAXBUF=xxxx

You should also ensure that PQL_MBYTLM is at least MAXBUF + 2300; otherwise,
at least on early 5.x VMS releases (reportedly), the system can crash.

To have these changes take effect, run the "AUTOGEN" procedure:

  @SYS$UPDATE:AUTOGEN GETDATA SETPARAMS

or:

  @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS

or:

  @SYS$UPDATE:AUTOGEN SAVPARAMS GENPARAMS FEEDBACK
  DIFFERENCE/OUTPUT=DIFF.DAT/PARALLEL SETPARAMS.DAT
  EDIT/TPU DIFF.DAT ! Check out what Autogen is going to do to me.
  @SYS$UPDATE:AUTOGEN SETPARAMS REBOOT

(Read about AUTOGEN in the VMS Guide to System Management)

This incorporates the new buffer sizes into the system configuration, and they
will take effect the next time the system is reloaded.

To examine your system parameters:

  run sys$system:sysgen
  SYSGEN> use current
  SYSGEN> show maxbuf                (should be at least 2064)
  SYSGEN> show virtualpagecnt        (should be at least 50000)
  SYSGEN> show /tty                  (TTY_ALTYPAHD should be at least 2064)

In an emergency, or for testing purposes, you can also change your MIN_MAXBUF
value "on the fly":

  $ run sys$system:sysgen
  SYSGEN> set maxbuf 2300
  SYSGEN> write active
  SYSGEN> exit

This operation should be used with caution, and should probably NOT be used
with values greater than about 3000.  The AUTOGEN procedure is safer because
it understands the relationships among the major parameters.

NOTE: Although it is still recommended that you make your MAXBUF setting
large enough for Kermit packets, it is (as of C-Kermit edit 190) no longer
strictly necessary.  C-Kermit's packet writer now recovers from MAXBUF and
quota-exceeded errors automatically by backing off and retransmitting the
packet in appropriate-size chunks (size determined by trial and error).
But this involves a small amount of additional overhead, so it's still best
to have adequate MAXBUF and quotas.

  II.2. USER QUOTAS AND PRIVILEGES

C-Kermit communications are also affected by the user's BYTLM quota and
possibly also the process page quota (PGFLQUO).  Also the BIOLM quota
(should be at least 10 or 20).

In modern versions of VMS, the default BYTLM quota is 8192, which should
normally be adequate.  If C-Kermit users experience error messages informing
them that a quota was exceeded during terminal emulation or file transfer, the
system manager should increase the user's BYTLM and/or process page quota.  To
find out the user's quotas, the system manager should:

  set default sys$system
  run authorize
  UAF> show <username>

Then look for the relevant quotas and adjust them as required.  The BYTLM
quota should be somewhat greater than the product of Kermit's window size
and packet size, for example, 8192 for 4 window slots and 2000-byte-packets.
PGFLQUO should be 20,000 or higher.

If users will be using C-Kermit's PUSH command or issuing REMOTE commands (such
as REMOTE DIR) to the VMS C-Kermit server, the user will need to have the
ability to create subprocesses (AUTHORIZE parameter PRCLM).  If Kermit will
itself be invoked as a subprocess (for example, from within a menu system) this
should be considered as well.  Kermit uses local mailboxes for remote command
execution, so users will also need the TMPMBX privilege if these commands are
to be used.

  II.3. CONFIGURING SERIAL COMMUNICATION PORTS

If your system has a port that is frequently used for file transfers (for
example, with a modem), you should have your system manager enable the
alternate type-ahead buffer, and direct memory access, by placing the command:

  $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD/DMA

in the system-wide startup command file, where ddcu: is the name of the
device, for each such device.  If DMA is not enabled, Kermit will run more
slowly and use a lot more CPU time.  (Note: DMA is only available on certain
types of devices; e.g. TX but not TT or LTA).

If the device is connected to a modem, and is to be used for dialing out,
also include the /MODEM qualifier:

  $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD/DMA/MODEM

The modem must also be configured to make DSR follow CD.  In modems that use
the Hayes AT command set, the command is AT&S1.  If you can't configure your
modem this way, then VMS will hang up on it during the dialing process,
preventing you from completing calls (C-Kermit's DIAL command will make this
setting in the modem for you on a per-call basis, but only if this information
is in its internal modems database; tell C-Kermit to SET MODEM TYPE xxx and
then SHOW MODEM to find out).  A less desirable workaround is to configure the
modem to ignore DTR (AT&D0), but this can block normal hangup methods even
when you want to use them, thus opening security loopholes.  A third
possibility is to jumper the CD and DSR wires in your modem cable.

If the VMS port is not connected to a modem or other data communications
device that follows the RS-232 (V.24) signaling conventions, or if the VMS
port does not have a full complement of RS-232 wires (which are lacking in
modular MMJ ports, for example), you might have to set the /NOMODEM qualifier
instead:

  $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD/DMA/NOMODEM

Even with these settings you might experience what UNIX users know fondly as
"getty babble", which occurs when logins are enabled on the device.  This
occurs with Kermit, SET HOST/DTE, or any other method of communication; for
example, AT<CR> is sent to the modem, the modem echoes AT<CRLF> and then says
OK<CRLF>.  VMS thinks a user named AT is trying to log in with a password of
OK, and says "User authorization failure", but the modem echoes this too,
and so on, back and forth, many times, maybe forever.  Reportedly, this can
be prevented by giving the SECURE attribute to the port in question, e.g.:

  $ SET TERMINAL ddcu:/PERMANENT/SECURE

which disables logins on the port until a BREAK signal is received.

Additionally, for non-privileged users to access a terminal device, they need
to be granted access to it.  The default for terminals is access only by users
with SYSTEM privileges (UIC group less than or equal to MAXSYSGROUP, or with
SYSPRV privilege).  See the VMS documentation for the SET PROTECTION command
for more information.  Note that if you grant everyone access to the port,
anyone can make phone calls via the modem, so you might want to limit this to
particular users, possibly by using a device ACL (VMS V5.0 and later only).

  II.4. CONFIGURING LAT DEVICES

In this discussion, we are using a DECserver 700-16 (the kind with RJ45
connectors that lack a full complement of modem signals).  (For examples
of configuring the DECserver 200, also see Section IV.)

  II.4.1. CONNECTING A LAT PORT TO A PC

We'll begin by connecting a PC's serial port to DECserver Port 2.  Commands
are given at the DECserver's console, normally Port 1.  In case it is a new
DECserver and you haven't yet given it a name:

  Local> set privilege
  Local> define server name latbox
  Local> initialize delay 0

We'll be using the server name "latbox" in the examples.  Now set up port
minimally for a test:

  Local> define port 2 autobaud disable
  Local> define port 2 speed 19200
  Local> define port 2 signal check disable
  Local> logout port 2

Then:

 1. Plug a BN25G-04 cable into LAT port 2.

 2. Plug the appropriate adapter (H8585-something) into the other end
    and connect it to the PC's serial port.  In this case, the PC has
    a DB-9, so we use the H8585-AA.

 3. Start Kermit on the PC and tell it to:

      SET PORT COM1 (or whatever)
      SET SPEED 19200
      SET FLOW NONE
      SET CARRIER OFF
      CONNECT

 4. Press the Enter key.  You should see the Local> prompt, and you should
    be able to type commands, e.g. to connect to your VMS system.

OK, so it works in local mode.  If not, check your cabling.  Now to set it up
for remote mode, i.e. to allow VMS to make a connection to the PC through the
DECserver port:

  Local> change port 2 access remote
  Local> show port 2

Take note of the port's name; by default it is PORT_2, but you can change it
to anything you like with:

  Local> change port 2 name blah

We'll stick with PORT_2 in this discussion.

With Kermit on the PC is still in CONNECT mode, do:

  Local> test port 2

This should put a test pattern on PC screen.

Now to set up the port for use from VMS.  First enable SYSPRV, CMKRNL, LOG_IO,
and SYSNAM privileges, then:

  $ run sys$system:latcp
  LATCP> create port lta600:
  LATCP> set port lta600: /application /node=latbox /port=port_2 /noqueue
  LATCP> exit

The /NODE switch gives the nodename of the DECserver; the /PORT switch gives
the port *name* (not number) of the port on the DECserver.  The /NOQUEUE
switch is important; otherwise if somebody does "set port lta600" when it is
in use, they will sit there and wait until it becomes free.

Then in VMS:

  $ set terminal LTA600: /permanent /fullduplex /altypeahd /speed=19200

This sets the typeahead buffer and makes the speeds match.  You can use LATCP
again to verify the setup:

  $ run sys$system:latcp
  LATCP> show port lta600:

  Target Port Name: PORT_2       Actual Port Name:
  Target Node Name: LATBOX       Actual Node Name:
  Target Service Name:           Actual Service Name:

(Use "show port" without any port number to look at all defined LAT ports.)

That's it.  Now start kermit and assign the port:

  $ kermit
  C-Kermit> set line lta600:
  C-Kermit> show communications

This should display the name and speed of the LAT device, as configured
above.  Then to make the connection:

  C-Kermit> connect

Type some characters to VMS C-Kermit -- you should see them come out on the
PC's screen.  Type some characters on the PC keyboard and they should come out
on VMS C-Kermit's screen.

On the PC, escape back to the Kermit prompt and type "show comm" or "show
modem" to see what modem signals are being presented by the connection.
DECservers that have 25-pin serial connectors, such as the 200 and the 700-8,
can do full modem control, but those with mini connectors, such as the 700-16,
make you choose between limited sets of modem signals; the DECserver can be
configured for either hardware flow control (recommended for high-speed
connections) or DTR/CD (allowing each end of the connection to tell when the
other end has hung up), but you can't have both.  On the DECserver, use:

  Local> define port 2 signal select xxx

where xxx is CTS-DSR-RTS-DTR or RI-DCD-DSR-DTR, to select the desired
complement of modem signals; the first one for hardware flow control, the
second one for ring/hangup control.

  Local> define port 2 signal control enable
  Local> logo port 2

On the PC, use "show comm" to make sure the PC sees the CTS signal.  If so,
tell Kermit to:

  set flow rts/cts

Then put the PC Kermit in server mode and, using VMS C-Kermit as client,
transfer some files.  Experiment with window size, packet length, and
unprefixing to achieve the highest transfer rate.  Then experiment with higher
serial speeds -- this will require a LATCP command on VMS, "change port" and
"logout port" commands on the DECserver, and a "set speed" command in PC
Kermit.

  II.4.2. SETTING UP A DIALOUT PORT

Now let's connect a modem to DECserver Port 3 for high-speed data transfer
(RTS/CTS, but no RI/CD).  In this example the modem is a USR Courier.

Connect port 3 (in this case with BN25G-04 cable with an H8585-AC adapter)
to the modem.  Then at the DECserver:

  Local> set privilege
  Local> define port 3 autobaud disable
  Local> define port 3 speed 38400
  Local> define port 3 signal select cts
  Local> define port 3 signal check enable
  Local> define port 3 access remote
  Local> define port 3 name dialout
  Local> logout port 3
  Local> show port 3

Back at VMS:

  $ run sys$system:latcp
  LATCP> create port lta601:
  LATCP> set port lta601: /application /node=latbox /port=dialout /noqueue
  LATCP> exit
  $ set terminal LTA601: /permanent /fullduplex /altypeahd /speed=38400

Now start C-Kermit and assign the port:

  $ kermit
  C-Kermit> set modem type usr
  C-Kermit> set line lta601:
  C-Kermit> show comm           ; Speed should be 38400
  C-Kermit> set dial display on ; To verify modem dialog
  C-Kermit> dial 7654321

And off you go.

For other configurations, refer to your DECserver and LATCP documentation.
You can set up port "hunt groups", you can assign logical names to the VMS
ports, which can refer to single LAT ports or entire hunt groups, and so on.
You can even define "bidirectional" ports for both calling in and calling out,
but these are difficult to troubleshoot when there are problems.

  II.4.3. DECSERVERS AND TELNET

DECservers that support TCP/IP connections can be used by C-Kermit for shared
dialout modem access.  The DECserver can be configured for this using a
command like:

  CHANGE TELNET LISTENER 2001 PORT 1 ENABLE

This associates TCP socket 2001 with serial port 1 on the DECserver.
Then you can use Kermit to Telnet to port 2001 on the DECserver and dial
the modem that is on the DECserver's serial port 1.

If you cannot get reverse LAT working, but LAT is working, it is still
possible to use Kermit via LAT so long as your system (and Kermit) support
TCP.  Start Kermit, tell it to "set host localhost" (the TCP loopback name).
In connect mode you can log back on to the same system (see the cautions in
"Using C-Kermit" about "C-Kermit in the Middle").

Then you can use SET HOST/LAT from the CONNECT session to dial out, login to
the remote system and start the remote Kermit.  Now go back to the original
Kermit session to transfer the files.  You should try it first with SET
PREFIXING ALL in C-Kermit, and probably also SET PARITY SPACE, and relatively
short packets.  If that works, you can try settings that give higher
performance at your own risk.

  II.5. THE VIRTUAL TERMINAL DRIVER

For incoming modem connections, it can be very useful if the VMS system is set
up to support Virtual Terminals.  Once these have been set up, then if an
incoming connection fails because of line problems, it should be possible to
reconnect to the original session by redialling and logging in again.  You
should then get a prompt asking if you wish to connect to your disconnected
session, allowing you to resume where you left off.  You should see something
like:

    You have the following disconnected process:
Terminal   Process name    Image name
VTA456:    ABCDEF          (none)
Connect to above listed process [YES]: Y
Connecting to terminal _VTA456:
ABCDEF>

There is a timeout of something like an hour, after which the disconnected
session is deleted entirely.

[If on re-dialing the host you find you are reconnected to the original
session without needing to login, then that host has a security problem, as
well as a misconfigured DECserver and/or modem or lead...]

The virtual terminal driver is loaded at startup (or later) using SYSGEN or
SYSMAN as appropriate.  The definition for TTY_DEFCHAR2 in MODPARAMS.DAT also
needs to be changed to set the appropriate bit to enable the disconnect
processing by default on all terminals.  [This change needs a reboot.]

Something like the following should work (check the VMS manuals):

VAX:
$ MCR SYSGEN VTA0/NOADAPTER/DRIVER=TTDRIVER

Alpha:
$ MCR SYSMAN IO CONNECT VTA0/NOADAPTER -
        /DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE

MODPARAMS.DAT:
TTY_DEFCHAR2 = 135170 ! = %x21002. Check the manual!
(%x20000 = Disconnect, %x1000 = Line Edit, %x2 = Autobaud)

  II.6. CAPTIVE ACCOUNTS AND RESTRICTED ACCESS

Some VMS sites restrict users from getting at the DCL prompt and services by
setting their accounts to be "captive".  This should automatically prevent
C-Kermit's DCL-access commands (such as PUSH) from working.  Any attempt to
execute such a command should result in C-Kermit issuing an error message.
Should a user circumvent this, VMS will automatically terminate the user's
process.  In addition to CAPTIVE, accounts can also be set to RESTRICTED, to
disable all types of spawning.  Note that DEC says that RESTRICTED is only
used "to ensure users complete login processing without interruption". DEC
further states that they intend to modify VMS utilities to no longer prohibit
spawning in a future release.

Further, you should be aware that preventing users from getting to DCL only
provides an illusion of security. There are many ways of getting to DCL which
are non-obvious. For cases where absolute security is required, you should in-
vestigate the AUTHORIZE flags CAPTIVE and DISIMAGE. Consult the VMS Security
Manual for more information.

C-Kermit itself can be configured to prevent system access, by compiling it
with the NOPUSH option (for this you would have to edit CKVKER.COM file and
add a definition for the symbol NOPUSH to the CFLAGS).  This disables not only
the PUSH command and its synonyms (RUN, @, SPAWN), but also OPEN !READ, OPEN
!WRITE, as well as the server's execution of REMOTE HOST commands.  See
CKCCFG.DOC for further information.

There is also a runtime approach for this: put the (invisible) command NOPUSH
someplace where it will always be executed; for example, the system-wide
CKERMIT.INI file, or in the "kermit" command definition:

  $ KERMIT :== "$SYS$TOOLS:KERMIT ""-C"" ""NOPUSH"""

You can also define the logical name (environment variable) CK_NOPUSH to
achieve the same effect.

The NOPUSH command does at runtime exactly what defining the NOPUSH symbol
at compile time does.


III - DECODING VMS C-KERMIT HEX FILES

If you have obtained the executable VMS C-Kermit program encoded in printable
"hex" format on magnetic tape or over a network, you can decode it back into a
runnable .EXE program image using the CKVDEH.MAR program.  This is an
assembly-language program for the VAX or Alpha, which you should assemble,
link, and run as follows:

  $ macro ckvdeh  (on the Alpha, substitute "macro/migrate ckvdeh")
  $ link ckvdeh
  $ run ckvdeh

CKVDEH prompts you for the input file name and then creates a .EXE file with
the same root name.  For example, if you enter CKVKER.HEX as the source file,
the resulting executable will be CKVKER.EXE.  This procedure works on both the
VAX and the Alpha -- the same program, CKVDEH.MAR, compiles and runs on
both platforms.

The C-Kermit .EXE files were built under VAX/(Open)VMS 5.x and Alpha
OpenVMS 1.x (whenever possible; otherwise under 6.1).  The VAX versions will
not run under pre-5.0 VAX/VMS releases.  If you have a VMS 4.x system with C
compiler, however, you should be able to build C-Kermit using the CKVOLD.COM
procedure.

Since VMS C-Kermit can be built with no TCP/IP support or with support for
several different TCP/IP packages, and it can be built on both the VAX and
Alpha platforms, you should pick the right .HEX file for your environment.

The naming conventions are as follows:

  CKVaKER-VMSnn-tttvv.xxx

where:

  CKV = "C-Kermit for VMS".
    a = architecture: A for Alpha, V for VAX.
  KER = Kermit
   nn = VMS version, e.g. 55 for VMS 5.5, 70 for VMS 7.0.
  ttt = TCP/IP product, if any:
	CMU = CMU-OpenVMS/IP ("CMU/Tek")
	UCX = Compaq (DEC) TCP/IP(*)
	PST = Process Software TCPware
	TGV = Process Software (Cisco (TGV)) MultiNet(*)
	WIN = Attachmate (Wollongong) WIN/TCP (PathWay)(*)
   vv = The version number of the TCP/IP product (may be 2 or characters)
  xxx = HEX (text-encoded binary) or EXE (true binary)

When there is no TCP/IP support built in, tttvv is "NONET".

(*) It's a bit of a task to keep up with all the buyouts and renaming.
    Any of these companies or products can be snapped up and/or renamed
    at any time, and most of them have been.

Examples:

  CKVVKER-VMS55-NONET.HEX:   VAX, VMS 5.5, no TCP/IP, hex format.
  CKVAKER-VMS62-TGV40.EXE: Alpha, VMS 6.2, Multinet 4.0, binary format.

Not every combination is necessarily available.  In general, an .EXE built
under a certain version of VMS will also run under later VMS versions, but the
opposite is usually not true.  Also, if a version was built under the same
VMS version that you have, but with a higher ECO level (OS or library patches),
it might not run.

So try to pick one that was built under a VMS version less than or equal to
yours, and with the the same TCP/IP product you have having with a version
number less than or equal to yours.  If that doesn't work, try the next
earlier one, etc.  If you can't find one for your TCP/IP product, try the
lowest-numbered UCX (DEC TCP/IP) version; most third-party TCP/IP products
also support UCX applications.  In any case, after getting the appropriate
executable onto your VMS disk, rename it to KERMIT.EXE, e.g.:

 $ RENAME CKVAKER-VMS62-TGV40.EXE KERMIT.EXE

The "labeled file converter" is simple; it comes in a VAX version,
CKVVCVT-VMSnn.{HEX,EXE}, and an Alpha version, CKVACVT-VMSnn.{HEX,EXE}.
Rename it to CKVCVT.EXE so VAX and Alpha users don't have to use different
names for the same program.


IV - INSTALLING VMS C-KERMIT

VMS C-Kermit must be installed on your VMS system by hand.  There is no
VMSINSTAL kit because it would have to include many megabytes of differently-
configured executables to choose from, and many of system-configuration items
discussed above are best done by the system manager manually, in privileged
mode, after some thought and consideration.

IMPORTANT:

DO NOT INSTALL VMS C-KERMIT AS A PRIVILEGED PROGRAM!  Instead, install it
as a foreign command.

To install C-Kermit, follow this procedure:

 1. If you have the old Bliss Kermit-32 on your system, rename it to
    KERMIT32.EXE.  If you have a symbol KERMIT defined to run Kermit-32,
    change the symbol name to KERMIT32.

 2. Identify the directory where you want to install the C-Kermit program.
    Normally this would be a directory that is unaffected by installation
    of DEC software, such as SYS$TOOLS = SYS$SYSDEVICE[SYSTOOLS].  From now
    on, we will assume you are using SYS$TOOLS:.

 3. Copy the desired .EXE file (VAX or Alpha, with the appropriate networking
    support) to that directory, rename it to KERMIT.EXE, and give users
    permission to run it, for example:

    $ COPY CKVVKER-VMS55-UCX20.EXE SYS$TOOLS:KERMIT.EXE
    $ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE) SYS$TOOLS:KERMIT.EXE

    If Kermit is going to be used a lot, you can have it preloaded and
    its pure memory segments shared:

    $ INSTALL ADD SYS$TOOLS:KERMIT.EXE/OPEN/HEADER/SHARE

 4. Copy the standard CKERMIT.INI file to the same directory:

    $ COPY CKERMIT.INI SYS$TOOLS:
    $ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE) SYS$TOOLS:CKERMIT.INI

 5. Add the following line to SYS$COMMON:[SYSMGR]SYSTARTUP_V5.COM (or
    whatever your system startup file is):

    $ DEFINE/SYSTEM CKERMIT_INI SYS$TOOLS:CKERMIT.INI

 6. Find your system-wide login DCL command procedure:

    $ SHOW LOGICAL SYS$SYLOGIN
    "SYS$SYLOGIN" = "SYS$TOOLS:SYLOGIN.COM" (LNM$SYSTEM_TABLE)

    and then add the following line to it:

    $ KERMIT :== $SYS$TOOLS:KERMIT

    This defines SYS$TOOLS:KERMIT.EXE as a "foreign command".

    NOTE: VMS 6.2 and later support automatic creation of foreign
    commands by placing the corresponding .EXE (or .COM) files in any
    directory that is included in the DCL$PATH logical name; e.g.:

    $ DEFINE DCL$PATH SYS$DISK:[],DISK1:[TOOLS],SYS$SYSTEM:

 7. Install the C-Kermit HELP file in your VMS HELP library.  First delete
    any earlier KERMIT help entry, then install the new one:

    $ LIBRARY/HELP/DELETE=KERMIT SYS$HELP:HELPLIB.HLB
    $ LIBRARY/INSERT/HELP SYS$HELP:HELPLIB.HLB CKVKER.HLP

 8. Create a publicly accessible directory, such as [KERMIT], in which to make
    other C-Kermit files available to your users:

    CKERMIT.KDD
      Sample dialing directory file.
    CKERMIT.KSD
      Sample services directory.
    CKERMIT.KND
      Sample network directory.
    CKEDEMO.KSC
      Macro definitions from "Using C-Kermit".
    CKEVT.INI
      Command file to demonstrate special screen effects from "Using C-Kermit".
    CKCKER.UPD
      A supplement to the book, "Using C-Kermit", describing features added
      since the book was published.
    CKCKER.BWR
      The general C-Kermit beware file.
    CKVKER.BWR
      The VMS-specific C-Kermit beware file.

If the Kermit program is not installed as a "foreign command" as in (6) above,
you can still RUN it, but you can't pass command-line arguments to it this
way.  However, you can pass command-line arguments if you invoke it with the
MCR command:

  $ mcr kermit -s oofa.txt ; (assumes "kermit.exe" in sys$system)

or:

  $ mcr disk1:[olga]kermit -s oofa.txt ; (explicit path given)


V - USING MODEMS

If you have a VAX or Alpha with a real serial port (DB-9 or DB-25), you
can use it with a modem.  If your machine has MMJ (assymetrical RJ-45)
modular jack sockets (like a VAXstation 3100), you won't be able to make
very good use of modems since these ports do not support modem signals.

Before attempting to use a modem on port (say) TTA0, you (or the system
manager) will need to configure the port as a modem port:

 $ SET TERMINAL TTA0 /MODEM /ALTYP /PERM

From section 5.2.3.1 of the I/O User's Reference Manual:

  Remote terminal connections have a timeout feature for the
  security of dial-up lines. If no channel is assigned to the port
  within 30 seconds, or a port with an assigned channel is not
  allocated, the DTR signal is dropped. Such action prevents an
  unused terminal from tying up a line. However, there are
  configurations (such as a printer connected to a remote line)
  in which the line should not be dropped even though it is not
  being used interactively. To bypass the 30-second timeout,
  set the system generation parameter TTY_DIALTYPE to 4.
  (Note that if TTY_DIALTYPE is equal to 4, all dial-up lines
  will skip the timeout waiting for a channel to be assigned.)y

The following is reprinted by permission; references to Kermit-32 are
obsolete.

		How to Use a MODEM With Your VMS System
                           Richard B. Gilbert
		      Computer Systems Consultant
		       76702.1567@CompuServe.Com

                         Revised July 30, 1996

	Most MODEMs come with factory defaults intended for dialout use with
PCs.  The MODEM is typically set to ignore DTR; e.g., assume that it is always
asserted and to assert CD at all times regardless of the actual state of the
received carrier.  The user is not required to do much, if anything, to get it
to work.  Such a MODEM requires some configuration before it will work
properly, or at all, with a VMS System.

	Be sure that the serial port you are using supports MODEM control
signals.  On the DMF32, for example, only ports 0 and 1 can be used with
MODEMS.  These ports on the DMF32 must have DIP switches set to enable MODEM
control signals.  The VAXStation 3100 does NOT support MODEM control! (It is
possible to use a MODEM but the VAXstation cannot detect the loss of the
connection; the next person to dial in could find himself logged in to your
account!)  The MicroVAX 3100 does support MODEM control.  As a general rule,
anything with a DEC Modified Modular Jack (MMJ) connector does not support
full MODEM control; the MMJ has only six pins and nine are required.  Eight
pin RJ45 connectors are sometimes used; e.g. on some models of the DECserver
700, where a choice is offered as to the signals supported.

	Connect the MODEM with a cable that supports MODEM control signals,
such as Digital's BC22E.  The BC22F, connecting all twenty-five pins, is
overkill but will work quite well.  A twenty-five conductor ribbon cable will
also work but a shielded cable is highly recommended in order to comply with
Radio Frequency Interference (RFI) requirements.

	Note that while it was possible to "fake it" with VMS V4.x and
earlier, VMS V5 requires that all of the MODEM control signals be connected.
(Pins 2-8, 20 and 22 should be connected straight through; i.e., 2-2, 3-3,
4-4, ...).  If you are forced to sacrifice one signal, try RI (Ring Indicator)
first.  For reference, here is the standard pinout for the RS-232-C DB-25
connector.

	Pin	Description
	1	Protective ground (may be connected to shield at ONE end only)
	2*	Transmitted data (TxD)
	3*	Received data (RxD)
	4*	Request to send (RTS)
	5*	Clear to send (CTS)
	6*	Data set ready (DSR)
	7*	Signal ground
	8*	Carrier detect (CD)
	12	Speed Mode Indicate (or secondary CD)
	15	Synchronous transmit clock
	17	Synchronous receive clock
	19	Speed select (or secondary RTS)
	20*	Data terminal ready (DTR)
	22*	Ring indicator (RI)
	23	Data Signal Rate Select (DSRS)

	It should be noted that not all devices connect or support all these
pins and not all those listed are necessary for "full MODEM control".   The
pins marked with an asterisk are generally essential to satisfactory and
secure operation of your modem.

	You will need to make some switch settings on your MODEM.  The
following settings are for a U.S. Robotics Courier V32bis FAX Modem.  Other
U.S. Robotics MODEMs use quite similar switch numbers and settings.  Other
manufacturers may use different switch numbers but the functions available are
typical.  See your MODEM's instruction manual for the sordid details.  The
settings marked with an asterisk are critical to the successful use of your
MODEM.  Some settings can also be made from the CPU via the MODEM's AT
command set, in which case the hardware switch settings determine the MODEM's
power on defaults.  The AT commands in parentheses, following the switch
settings, are the commands for a U.S. Robotics Courier HST Dual Standard
MODEM.  Check your manual for the proper commands for your MODEM.

* 1.  DTR Normal (controlled by CPU)			(AT&D2&W)
  2.  Verbal result codes (Useful during dialout)	(ATV1)
* 3.  Do not display result codes (Quiet mode)		(ATQ1)
  4.  Echo off line commands (Useful during dialout)	(ATE1)
* 5.  Auto answer (MODEM will answer the phone if DTR is asserted) (ATS0=1)
* 6.  Normal Carrier detect (controlled by MODEM)	(AT&C1&W)
  7.  Display originate result codes only.
  8.  Normal At command set (Must be enabled for auto dial.)
  9.  Online after +++
 10.  Load NVRAM defaults on power up.

************************************************************************

	Many users have observed a VMS System dropping DTR (Data Terminal
Ready) while a user is trying to dial in, causing the MODEM to hang up the
phone.  The terminal driver will drop DTR if it sees DSR (Data Set Ready) for
more than thirty seconds, without also seeing CD (Carrier Detect).  If it is
possible to configure the MODEM so that it does not assert DSR until it
asserts CD (AT &S1&W), do so.  Otherwise it will be necessary to use a
modified cable. At the VAX end of the cable, cut the wire leading to pin 6
(DSR) and jumper pin 6 to pin 8 (CD).


	Commands similar to the following should be placed in your
SYS$MANAGER:SYSTARTUP_VMS.COM (SYSTARTUP_V5.COM for VMS V5.X) file to set up
an asynchronous port for use with a MODEM.  You may want to add some more
qualifiers but this will get you going.
$	SET TERMINAL -
	/PERMANENT -	! Make settings permanent
	/MODEM -	! Use MODEM control signals
	/DIALUP	-	! Gives the DIALUP identifier to user.
	/HANGUP	-	! Hang up the phone when user logs off
	/AUTOBAUD -	! Detect the user's baud rate and set it.*
	/ALTYPEAHD -	! Use the alternate typeahead buffer.  The
			! alternate typeahead buffer can be made larger
			! than the regular one.  This is helpful if you
			! are doing file transfers.  See SYSGEN parameter
			! TTY_ALTYPAHD.
	/HOSTSYNC -	! VMS System will send XOFF when its buffer is
			! nearly full and XON when it is ready for more
			! input.  See SYSGEN parameter TTY_ALTALARM.
	_TXA0:

$	SET SECURITY /CLASS=DEVICE /PROTECTION=W:R	! VMS V6
			! Sets device protection to allow non-privileged
			! users to allocate the device for dialing out.
			! Otherwise user must own device or hold SYSPRV.
or
$	SET PROTECTION=W:R /DEVICE			! VMS V5

	* Many modern MODEMs are capable of using a fixed DTE rate to talk
to the computer; e.g. if they are set to 19200, they will talk to the
computer at 19200 regardless of what speed they are using to talk to the
remote MODEM.  This feature has performance implications for MODEMs that do
data compression using either CCITT V.41 or MNP.   For such MODEMs, set a
speed that is at least four times the rated DCE speed of the MODEM or the
highest available speed using /SPEED=xxxxx rather than using /AUTOBAUD.  The
MODEM must be set to use the corresponding speed.  The U.S. Robotics Courier
series are set to a particular DTE rate by the most recent AT&W command; the
rate set is the current speed of the port.  See your MODEM's instructions for
details.

************************************************************************

	The following commands should probably go in SYS$SYLOGIN, your
system-wide login command file:

$! Test for interactive or batch mode
$!
$	IF F$MODE() .NES. "INTERACTIVE" THEN GOTO 10$
$!   Set up device dependant terminal characteristics.  This only works
$! if the terminal responds to ANSI Device Attributes (DA) control string.
$! Most DEC terminals (VT1xx, VT2xx, VT3xx, VT4xx, VT5xx, LAxxx) and
$! compatibles will do so.
$	IF F$GETDVI("TT", "TT_MODEM") THEN $ SET TERMINAL /INQUIRE
$ 10$:
**************************************************************************

	To set the terminal for temporary dialout use, execute the following
commands:
$	ALLOCATE TXA0:	KER$COMM	! Logical is useful for Kermit-32.
$	SPEED="''P1'"
$! Default to 1200 baud.		! Pick a suitable default value.
$	IF SPEED .EQ. "" THEN SPEED=1200
$	SET TERMINAL /NOAUTOBAUD /SPEED='SPEED' KER$COMM:

	You may need to add a /NOECHO qualifier if your terminal program is too
stupid to read with no echo.  It is not necessary with SET HOST/DTE, KERMIT,
XMODEM, or HOST32.


	To support a MODEM on a DECServer 200:

1. Set up the terminal server as follows: (assuming port 8)

Local> DEFINE PORT 8 ACCESS DYNAMIC AUTOBAUD DISABLED
Local> DEFINE PORT 8 DSRLOGOUT DISABLED FLOWCONTROL XON
Local> DEFINE PORT 8 INACTIVITY ENABLED MODEM ENABLED
Local> DEFINE PORT 8 SIGNAL CHECK ENABLED
Local> DEFINE PORT 8 SPEED 2400 ALTERNATE SPEED 1200
Local> DEFINE PORT 8 DIALUP ENABLED
Local> LOGOUT PORT 8
Local> DEFINE SERVICE service_name PORT 8 IDENT "string"
Local> SET SERVICE service_name PORT 8 IDENT "string"

	Other port characteristics may be defined "to taste".

2. Insert the following statements in SYS$STARTUP:LAT$SYSTARTUP.COM
(SYS$MANAGER:LTLOAD.COM for VMS V5.4 and below):

CREATE PORT LTA100: /NOLOG

SET PORT LTA100: /APPLICATION /NODE=server_name /SERVICE=service_name -
	/NOQUEUE /NOLOG

	The LTA number is more or less arbitrary but must take into account
the fact that LAT startup creates a few ports temporarily (starting at
LTA1) and the number you choose must not conflict.

	The server_name and service_name must correspond exactly to the
names used in the DECserver DEFINE SERVER server_name and DEFINE SERVICE
service_name commands!

3. Insert the following statements in SYS$MANAGER:SYSTARTUP_VMS.COM
(SYS$MANAGER:SYSTARTUP_V5.COM for VMS V5.X):
$!
$	@SYS$STARTUP:LAT$STARTUP.COM	! Start LAT.
$! Note that SYS$STARTUP:LAT$STARTUP.COM starts LAT and then invokes
$! LAT$SYSTARTUP.COM to complete the system specific part of the startup.
$! VMS V5.4 and below would use @SYS$MANAGER:LTLOAD.COM.
$!
$! Set up MODEM port on terminal server.  The SET TERMINAL may not
$! be necessary at all since the DECserver DEFINE commands include equivalents
$! for everything except /ALTYPEAHD.
$	SET TERMINAL /PERMANENT /DIALUP /ALTYPEAHD /HOSTSYNC	LTA100:
$	SET SECURITY /CLASS=DEVICE /PROTECTION=W:R 		LTA100:

4. Reboot or execute the commands in steps 2 and 3.


VI - BUILDING VMS C-KERMIT FROM THE SOURCE CODE

C-Kermit is written in the C programming language.  To build C-Kermit on the
VAX, you must have VAX C, DEC C, or GNU GCC.  At some sites, the C header
files are archived in a VMS library and then VMS C-Kermit might not be
compilable.  If the C compiler (preprocessor) complains about not being able
to find header files, you'll have to extract them from the library.  A sample
DCL procedure for this can be found at the end of this file.

WARNING: When building with GCC on a VMS system that has Multinet installed,
you must ensure that the GCC TIME.H file is used instead of the Multinet
TIME.H; otherwise there will be a fatal error in CKVTIO.C at the declaration
of "tcount", around line 450.  Other warnings appear to be harmless.

WARNING: DEC C 4.0 has a bug in which the XABALL struct member xab$b_bkz (used
in CKVFIO.C) is not defined.  DEC gives a simple example -- compiling the
following code with DEC C using either /DECC and /VAXC:

#include <rms.h>
struct XABALL xabDATAall;
int f() {
    xabDATAall.xab$b_bkz = 63;
    return 1;
}

Results in:

%CC-E-NEEDMEMBER, In this statement, "xab$b_bkz" is not a member of
 "xabDATAall".

If you find that the above code produces the same problem on your system,
define BUGFILL7, e.g.:

  @ckvker.com "" "" "BUGFILL7"

BEWARE: Certain versions of VAX C can generate incorrect code when a function
is used before it is declared, and it generates a return value (via a return
statement) that is not used; other functions might have their entry masks
(argument lists) corrupted.  If you experience bizarre behavior from a version
of C-Kermit built with VAX C, try recompiling with /OPT=NOINLINE and /NOOPT,
or some other reduced optimization level.

Both VAX C and DEC C are moving targets.  A version of C-Kermit that was built
successfully with version x.y of the compiler almost always fails to build
under version x.y+1.  Thus you will find increasing numbers of #ifdefs in the
code (mostly CKCNET.C and .H and the CKV*.* modules) keyed on explicit C
compiler version numbers.  Note the form of these carefully -- they have to be
just right).  Also note that you can't use constructions like:

  #if __DECC_VER >= 500000000

ANYWHERE in a portable module because neither "#if" nor relational operators
in preprocessor statements are portable.

The number of possible VMS C-Kermit configurations is large, perhaps not even
countable: VAX vs Alpha, VAXC vs DECC vs GCC, no network support vs Multinet
vs TCPware vs Wollongong vs UCX vs CMU/Tek, and this release of VMS versus all
the others.  The kicker is in the releases; for example DEC C 4.0 vs 4.1 vs
5.0 vs 5.3 (etc) versus the TCP/IP product's header files, which themselves go
through all sorts of releases and patches.  We can't guarantee that C-Kermit
can be successfully built on every combination, but in version 6.0 we are much
closer to that goal than ever before.

Before leaving this topic, let's look at how to find out the relevant version
numbers.  SHOW SYSTEM (among other commands) tells you the VMS version number.
To find the C version number, try:

  $ CC /VER

which works for recent DECC versions, or:

  $ CC NLA0: /NOOBJ /VERSION

or (when the above doesn't work):

  $ CC/LIST=FOO SYS$INPUT
  ^Z

and then look at the first line of FOO.LIS.

The method for finding out the TCP/IP product version number depends on the
product.  For Multinet:

  $ MU SHOW /VERSION

For DEC TCP/IP (UCX) versions 3.0 and later:

  $ UCX SHOW VERSION

For earlier releases, or ones where the above command doesn't work, try:

  $ RUN SYS$SYSTEM:UCX$VERSIONS

or:

  $ ANALYZE/IMAGE SYS$SYSTEM:*BGDRIVER

or:

  $ ANALYZE/IMAGE SYS$LOADABLE_IMAGES:*BGDRIVER

For others: (somebody please fill this in)

Before trying to compile, make sure you've got the disk space and quotas, etc,
that are needed.  In version 6.0 and later, you'll probably need as much as 8
or 10 megabytes for all the sources, objects, and binaries.

The User Authorization File (UAF) parameters of the account in which C-Kermit
will be built must be set to accomodate the large size of some source modules.
Recommended values are:

  PAGE FILE QUOTA:  at least 60000
  Working set extent:  at least 5012

To modify: Suppose a user KERMIT is the VMS account from which Kermit is
maintained.  To set these values, the system manager must do the following:

  $ set default sys$system
  $ mcr authorize
  UAF> modify kermit/pgflquo=60000/wsextent=5012
  UAF> exit

If errors such as:

  %cc-f-text Virtual Memory limits exceeded

occur during the build procedure, these parameters may need adjustment
(upwards).

To build C-Kermit, create a new directory and make it your current directory:

  $ CREATE/DIR [.KERMIT]
  $ SET DEFAULT [.KERMIT]

and put the C-Kermit source files and build procedures there, for example by
copying them from the distribution tape or cartridge.

Two build procedures are provided for C-Kermit 6.0 and later; one (CKVOLD.COM)
for VMS 4.x, the other (CKVKER.COM) for VMS 5.0 and later.  The two are
equivalent except for syntax, and should work everywhere.  No extra products
(MAKE, MMS, MMK, etc) are required (but MMS or MMK will be used if present).
The auxilliary file CKVKER.MMS is used if MMS or MMK are present.  To build
C-Kermit:

   $ @CKVKER  (or @CKVOLD)

Please read the comments at the top of CKVKER.COM itself for further
instructions and information.

NOTE: if you get messages like this in the link step:

  %LINK-I-OPENIN, Error opening SYS$COMMON:[SYSLIB]VAXCRTLG.OLB; as input,
  %RMS-E-FNF, file not found
  %LINK-I-OPENIN, Error opening SYS$COMMON:[SYSLIB]VAXCRTL.OLB; as input,
  %RMS-E-FNF, file not found

it probably means you have a LNK$LIBRARY symbol defined in your job (or
system-wide) and the definition is inappropriate.  DEASSIGN it if possible.
If not, and if the LINK step produced no other error messages, and the
WERMIT.EXE binary seems to run OK, then you can ignore the error messages.

If you get huge amounts of warnings like:

            getsockname(sock,(struct sockaddr *)&l_sa,&slen);
............^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value"
&slen" is "int", which is not compatible with "unsigned int".
at line number 5870 in file DISK$USRG:[FDC.KERMIT]CKCNET.C;20

this indicates that some essential header file is not being executed, which
can happen for all sorts of reasons (usually some symbol was defined by some
other header file that interferes with a subsequent one).  The trick here is
to get an include-file listing, which is possible with DECC (maybe VAXC too):

  @ckvker.com "" "" "" /LIST/SHOW=INCLUDE

and then look through the CK????.LIS file of the offending module.

  V.1. PROGRAMMING TIPS

For testing the DEC C version number:

  #ifdef __DECC_VER
  #if (__DEC_VER >= 050100000)
  blah
  #endif
  #endif

Note: the version number is vvuuteeee; vv is the major version (like 5),
uu is the update number (like the "3" in 5.3), t is a code for field test,
real release, etc, and eeee is the edit suffix.  This is available only in
DECC 5.0 and later.  It also has a __VMS_VER...  Note #2: Remember not to
add a leading zero because that changes it to octal.

  V.2. VMS TCP/IP NETWORKING SUPPORT FOR C-KERMIT

VMS C-Kermit is capable of establishing TCP/IP TELNET connections and acting
as a TELNET program with built-in file transfer, script programming,
character-set translation, etc, if it is built appropriately.  If you have one
of the following products installed on your system, complete with libraries
and header files:

  1. DEC TCP/IP (UCX)
  2. TGV MultiNet TCP/IP
  3. Wollongong WIN/TCP or PathWay
  4. Process Software TCPware
  5. CMU-OpenVMS/IP with Mike O'Malley's sockets library

then you can include TCP/IP capability in your version of VMS C-Kermit.

The TCP/IP product is selected automatically by the build procedure based on
the presence or absence of certain files on your system.  To override the
automatic selection, define the symbol NET_OPTION in one of the following ways
before running the build procedure:

  $ NET_OPTION = "NONET"      ! Build with no TCP/IP networking support
  $ NET_OPTION = "CMU_TCPIP"  ! Build with CMU/Tek TCP/IP networking support
  $ NET_OPTION = "DEC_TCPIP"  ! Build with DEC TCP/IP (UCX) support
  $ NET_OPTION = "MULTINET"   ! Build with TGV MultiNet TCP/IP support
  $ NET_OPTION = "TCPWARE"    ! Build with Process Software TCPware support
  $ NET_OPTION = "WINTCP"     ! Build with WIN/TCP or PathWay support

That is, type one of the commands listed above at the DCL prompt (shown above
as "$") before running the build procedure.  You can also force a "NONET"
build with the CKVKER.COM "N" command-line option.

Note: If you are building a version with TCP/IP support, and you have the
required TCP/IP libraries and header files, but the #include files can't be
found at compile time, then maybe they were put into a text library, in which
case you need to unpack the include-file library into separate files using the
VMS LIBRARY command.

V.2.1. DEC TCP/IP (UCX)

If the C-Kermit build procedure does not notice that you have DEC TCP/IP
installed when you really do, it is likely because the file
SYS$STARTUP:UCX$STARTUP.COM is read-protected (e.g. because your site
runs DECinspect).  Turn on READONLY privilege.

If the DEC TCP/IP version of KERMIT.EXE crashes immediately upon startup
with a message like:

  %LIB-E-ACTIMAGE, error activating image
   R4GRIE$DIA0:[SYS0.SYSCOMMON.][SYSLIB]UCX$IPC_SHR.EXE;1
  -SYSTEM-F-PRIVINSTALL

it means the system manager has to install the UCX sharable library:

  INSTALL ADD SYS$SHARE:UCX$IPC_SHR.EXE

V.2.2. WOLLONGONG (now Attachmate) TCP/IP

Wollongong (now Attachmate (now defunct)) support should work for both new
(PathWay) and older (WIN/TCP) versions, and C-Kermit versions linked under
older Wollongong versions should still run under the newer version.  But note
that the pieces of the Wollongong package are now unbundled -- you have to buy
the runtime, access, API, etc, pieces separately, and (of course) you need the
API to compile C-Kermit with Wollongong TCP/IP support.

C-Kermit 7.0 has been verified to build on VMS ... with Pathway 3.1 with a
few harmless warning messages, but the following change is required to the
Attachmate-supplied file TWG$TCP:[NETDIST.MISC]DEF.COM to remove the
definition of DECC$SYSTEM_INCLUDE:

$ diff twg$tcp:[netdist.misc]def.com
************
File TWG$COMMON:[NETDIST.MISC]DEF.COM;2
   37   $! define decc$system_include   twg$tcp:[netdist.include],      -
   38   $!                              twg$tcp:[netdist.include.sys]
   39   $!
******
File TWG$COMMON:[NETDIST.MISC]DEF.COM;1
   37   $ define decc$system_include    twg$tcp:[netdist.include],      -
   38                                   twg$tcp:[netdist.include.sys]
   39   $!

You can't build VMS C-Kermit with Wollongong TCP/IP support using GCC due to
the use of "noshare" in the Wollongong header files.

Reportedly, when building C-Kermit with WIN/TCP support with older versions
(5.1 and earlier?) of WIN/TCP, the symbol WIN$PERROR is undefined at link
time and the build fails.  Workaround: change the one reference to
win$perror(), which occurs in the contti() function in CKVTIO.C, to be
simply perror().

  V.2.3. TGV (now Cisco) MULTINET

If your VAX has the TGV MultiNet TCP/IP networking product, CKVKER.COM
automatically builds C-Kermit with MultiNet TCP/IP support included.  However:

. In older (pre-V3.1) MultiNet installations, the header files might not be
  installed.  Without these, C-Kermit will not build correctly.  The system
  manager can add Multinet 3.1 programming support by installing MNETLIB031
  from the Multinet distribution, if licensed to do so.

. Anyone building the VMS version with certain versions of TGV MultiNet
  support under VAX C 3.1 might get an error message about conficting
  definitions of "time_t".  This is because of a conflict between DEC's
  <types.h> and MultiNet's <types.h> caused because DEC changed the definition
  between VAX C 3.0 and 3.1.  Kermit can't do anything about this because
  CKVTIO.C #includes <time.h>, which itself includes <types.h>.  The warning
  is not fatal.

  V.2.4. CMU-OpenVMS/IP

CMU-OpenVMS/IP (CMUIP), originally CMU/Tek-TCP/IP, is a public domain TCP/IP
package originally developed at Carnegie-Mellon University (CMU) by Tektronix
(Tek).  CMUIP was released to the public trust in December 1992 as
CMU-OpenVMS/IP and is now maintained by a diligent group from around the
Internet.  Support is provided through the usenet group:

  vmsnet.networks.tcp-ip.cmu-tek

BSD socket support for C-Kermit is supported thanks to a new CMU-OpenVMS/IP
socket library written by Mike O'Malley of Digital Equipment Corporation.  If
you have this library installed on your VMS system, the build procedure will
find the file CMUIP_ROOT:[SYSLIB]LIBCMU.OLB and C-Kermit will be built
automatically with CMU-OpenVMS/IP support unless you define NET_OPTION to say
otherwise.  The LIBCMU socket library can be found on the kermit.columbia.edu
anonymous ftp server.


VII - CASE STUDY: ALPHA SETUP AND TEST RESULTS

  (by Peter Mossel)

Model number:  DEC3000/400, a workstation with 64MB of memory.
Ports used:    OPA1: (a MMJ connector for the alternate operator console)
               TTA1: (a 25-pin male D-connector on the back)
Operating System:  OpenVMS V1.0
Firmware:  V1.1

Upon power-up, the console displays something like:
...
CPU   OK  KN15-BA V1.1-S11A IO20 sV1.0 DECchip 21064 P2.1
...

Testing setup 1:  OPA1:

+-------+
|     MMJ--- DECconnect cable ---MMJ H8571-A--- modem cable to PC
+-------+                            (passive adapter)

In words, plug a DECconnect cable with MMJ plugs on both ends in the
alternate console port on the back of the DEC3000/400.  Make sure S3 is
in the "up" position.  The workstation screen is now the console (OPA0:)
and the extra port, OPA1:, is available for connecting a terminal or
printer.  This MMJ plug is the only MMJ plug on the back of this machine.

My other host for the test is a DECpc 466, a 66MHz i486 with DOS 5.0 and
MS-DOS Kermit 3.12.  The 466 has 2 serial ports, both 9-pin.  I attached a
standard 9-pin to 25-pin modem cable (the ones that came into existence with
the IBM PC/AT which originally had only a 9-pin serial port) to the serial
port on the 466.

Now we must join a 25-pin connector and a MMJ connector.  This is done with a
passive adapter (H8571-A) which converts the RS423 signalling standard
(balanced TX+ TX- RX+ RX-, DTR, DSR) to RS-232.  All this is fairly standard
for DEC sites.  Note that when connecting a modem to an MMJ connector, we have
only a subset of the required modem signals, so this is not supported via MMJ.
The other port (TTA1) has full modem control.  Note that the DECconnect cable
always reverses TX and RX, so it effectively functions as a NULL-modem cable.

Testing setup 2:  TTA1

+-------+
|     25-pin D connector --- NULL modem cable to PC
+-------+
Use the (only) 25-pin D-connector on the back.  Now we need a null modem
cable (see the Kermit book), and, because my PC has a 9-pin serial
port, I also need a 9-pin to 25-pin modem cable.

Testing setup 3:  LAT

Connect the PC with a standard cable to the terminal server, which speaks
LAT to my DEC3000/400.  The speed can be set up to 19200 baud with the
terminal server in use.

Test script for setup 1 and 2:

On DEC3000:
$ kermit
C-Kermit>set line xxx
   (where xxx is OPA1 or TTA1)
C-Kermit>set speed 19200

On the PC
C:\kermit
MS-Kermit>set port 1
MS-Kermit>set speed 19200
MS-Kermit>server

On the DEC3000:
C-Kermit>get test.fil
C-Kermit>finish

On the PC
MS-Kermit>quit

Test script for setup 3 (LAT):
On the PC
C:\kermit
MS-Kermit>set port 1
MS-Kermit>set speed 19200
MS-Kermit>connect

[ Now log into DEC3000 as host ]

$ kermit -x

[ back to the PC ]

MS-Kermit>get test.fil
MS-Kermit>bye

Results:

In all three cases, the data transfer speed is excellent.  Over 80% of the
bandwidth of the communication channel is used for the file transfer,
sometimes even more.  The DEC3000 is loaded with processes (MOTIF, Sybase
DBMS, NFS clients and servers,...) and heavy network activity (DECnet, LAT,
TCP/IP but no characters have ever been lost, even when the DBMS fires up.  No
special SYSGEN parameters, just configured for a normal workstation with
MOTIF.

Notes:

1.  Device protection

In a system like this out of the box, the device protection on TTA1 and
OPA1 does not allow an unprivileged user to use these lines for DIAL-OUT
from Kermit.  Thus, the system manager must set every time the system is
rebooted:

  $ set protection=w:rwlp/device OPA1:
  $ set protection=w:rwlp/device TTA1:

Without these special protections, a terminal connected to these ports
will still be able to login and get the "Username:" prompt.

2.  Console device speed

The Alpha VMS V1.0 cover letter mentions that the command

  $ set terminal/speed=nnnn/perm/opa1:

will have no effect on the speed of OPA1.  In practice, there is no problem
with Kermit file transfers.  The data just get thru fine and file transfers
are OK.  The release notes also mention that setting the speed of OPA1 can
be accomplished by setting the console environment variable "tta1_baud" to the
desired speed.  See the hardware guide on how to do this.  The problem will be
fixed in a future release.


VIII - MAKING AND USING VMSINSTAL KITS

(NOTE: This section is only for future reference, in case it becomes
practical to distribute VMSINSTAL kits for C-Kermit.  For now, please ignore.)

(The reason it isn't practical to build VMSINSTAL kits is that they would
be HUGE -- we have five networking options times two processors (VAX and
Alpha) times two choices of whether you want to build from the source code
or accept the included binary, and the resulting kit still would not solve
the many VMS configuration problems discussed above.)

After building C-Kermit using one of the procedures outlined above, execute
the DCL procedure CKVMSI.COM to create a VMSINSTAL kit.  This kit can be
created either with or without the source code.  In any case, it includes the
C-Kermit executable program, the C-Kermit help file (for installation in your
HELP library), plus a sample CKERMIT.INI (C-Kermit initialization) file, and
release notes.  You may now install C-Kermit using the command:

  @sys$update:vmsinstal kermit

It will prompt you for which components you want installed, and where to put
them.  CKVMSI and CKVKIT were written by Terry Kennedy of Saint Peters College.

SAMPLE HEADER-FILE EXTRACTION PROCEDURE

This one is for VAX C, and probably needs a few more files extracted from it
than are shown below.

$!
$! XTRACTHD.COM
$! By Robert Weiner, Programming PLUS, rweiner@watsun.cc.columbia.edu
$! FEB-1992
$! Use this Extract Header command script to extract the VAXC header files
$! from sys$library:vaxcdef into the current directory inorder to compile
$! ckermit if you don't have the include files already in sys$library:
$! You must also modify the CKVKER.COM procedure to include
$! "CCFLAGS = /INC=([])" for this to work, ie. search current directory too.
$!
$ write sys$output "Extracting CKERMIT Include Files into Local Directory..."
$!
$lib /log /extract=CTYPE	/output=CTYPE.h		sys$library:vaxcdef.tlb
$lib /log /extract=DCDEF	/output=DCDEF.h		sys$library:vaxcdef.tlb
$lib /log /extract=DESCRIP	/output=DESCRIP.h	sys$library:vaxcdef.tlb
$lib /log /extract=DEVDEF	/output=DEVDEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=DVIDEF	/output=DVIDEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=ERRNO	/output=ERRNO.h		sys$library:vaxcdef.tlb
$lib /log /extract=FILE		/output=FILE.h		sys$library:vaxcdef.tlb
$lib /log /extract=IN		/output=IN.h		sys$library:vaxcdef.tlb
$lib /log /extract=INET		/output=INET.h		sys$library:vaxcdef.tlb
$lib /log /extract=IODEF	/output=IODEF.h		sys$library:vaxcdef.tlb
$lib /log /extract=JPIDEF	/output=JPIDEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=LIMITS	/output=LIMITS.h	sys$library:vaxcdef.tlb
$lib /log /extract=NETDB	/output=NETDB.h		sys$library:vaxcdef.tlb
$lib /log /extract=RMS		/output=RMS.h		sys$library:vaxcdef.tlb
$lib /log /extract=SETJMP	/output=SETJMP.h	sys$library:vaxcdef.tlb
$lib /log /extract=SIGNAL	/output=SIGNAL.h	sys$library:vaxcdef.tlb
$lib /log /extract=SOCKET	/output=SOCKET.h	sys$library:vaxcdef.tlb
$lib /log /extract=SSDEF	/output=SSDEF.h		sys$library:vaxcdef.tlb
$lib /log /extract=STARLET	/output=STARLET.h	sys$library:vaxcdef.tlb
$lib /log /extract=STAT		/output=STAT.h		sys$library:vaxcdef.tlb
$lib /log /extract=STDIO	/output=STDIO.h		sys$library:vaxcdef.tlb
$lib /log /extract=STDLIB	/output=STDLIB.h	sys$library:vaxcdef.tlb
$lib /log /extract=STRING	/output=STRING.h	sys$library:vaxcdef.tlb
$lib /log /extract=STSDEF	/output=STSDEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=SYIDEF	/output=SYIDEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=TIME		/output=TIME.h		sys$library:vaxcdef.tlb
$lib /log /extract=TIMEB	/output=TIMEB.h		sys$library:vaxcdef.tlb
$lib /log /extract=TT2DEF	/output=TT2DEF.h	sys$library:vaxcdef.tlb
$lib /log /extract=TTDEF	/output=TTDEF.h		sys$library:vaxcdef.tlb
$lib /log /extract=TYPES	/output=TYPES.h		sys$library:vaxcdef.tlb
$lib /log /extract=UAIDEF	/output=UAIDEF.h	sys$library:vaxcdef.tlb
$!
$! The end
$!

(End of file CKVINS.DOC)
