home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
old
/
ckermit5a190
/
ckvins.doc
< prev
next >
Wrap
Text File
|
1995-07-12
|
49KB
|
1,127 lines
C-KERMIT 5A INSTALLATION INSTRUCTIONS FOR VMS and OpenVMS -*-text-*-
5A(190)
Fri Nov 25 12:12:59 1994
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
Copyright (C) 1985, 1994, Trustees of Columbia University in the City of New
York. The C-Kermit software may not be, in whole or in part, licensed or
sold for profit as a software product itself, nor may it be included in or
distributed with commercial products or otherwise distributed by commercial
concerns to their clients or customers without written permission of the
Office of Kermit Development and Distribution, Columbia University. This
copyright notice must not be removed, altered, or obscured.
DISCLAIMER:
The C-Kermit software is provided in source code form by Kermit Development
and Distribution, Columbia University. The software is provided "as is;" no
other warranty is provided, express or implied, including without
limitations, any implied warranty of merchantability or implied warranty of
fitness for a particular purpose.
"VMS" as used in this document refers to both VMS and OpenVMS on VAX
processors and OpenVMS on Alpha AXP processors. Most of the words in the
previous sentence are trademarks (TM) of Digital Equipment Corporation.
Neither Columbia University nor any of the contributors to the C-Kermit
development effort, including, but not limited to, AT&T, Digital Equipment
Corporation, Data General Corporation, International Business Machines
Corporation, or Saint Peters College warrant C-Kermit software or
documentation in any way. In addition, neither the authors of any Kermit
programs, publications or documentation, nor Columbia University nor any
contributing institutions or individuals acknowledge any liability resulting
from program or documentation errors.
DOCUMENTATION
Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Digital Press /
Butterworth-Heinemann, Woburn, MA, 1993, 514 pages, ISBN 1-55558-108-0
US single-copy price: $36.95; quantity discounts available. Available in
computer bookstores or directly from Columbia University:
Kermit Development and Distribution
Columbia University Academic Information Systems
612 West 115th Street
New York, NY 10025 USA
Telephone: (USA) 212 854-3703
Domestic and overseas orders accepted. Price: $34.95 (US, Canada, and
Mexico), $45 elsewhere. Orders may be paid by MasterCard or Visa, or
prepaid by check in US dollars. Add $35 bank fee for checks not drawn on
a US bank. Price includes shipping. Do not include sales tax.
Inquire about quantity discounts.
You can also order by phone from the publisher, Digital Press /
Butterworth-Heinemann, with MasterCard, Visa, or American Express:
+1 800 366-2665 (Woburn, Massachusetts office for USA & Canada)
+44 993 58521 (Rushden, England office for Europe)
+61 2 372-5511 (Chatswood, NSW office for Australia & New Zealand)
+65 220-3684 (Singapore office for Asia)
A German-language edition is also available:
Frank da Cruz and Christine M. Gianone, "C-Kermit - Einfuehrung und
Referenz", Verlag Heinz Heise, Hannover, Germany (1994).
ISBN 3-88229-023-4. Deutsch von Gisbert W. Selke. Price: DM 90,00.
Verlag Heinz Heise GmbH & Co. KG, Helstorfer Strasse 7, D-30625 Hannover.
Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 53-1 29.
QUICKSTART GUIDE
To install VMS C-Kermit on VAX/(Open)VMS 5.x or 6.x, and Alpha AXP OpenVMS 1.x
or 6.x systems, 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 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 - CONFIGURING VMS FOR BEST RESULTS WITH KERMIT
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.
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.
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
If it is not connected to a modem or other data communications device that
follows the RS-232 signalling conventions, 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 PROTCTION 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).
4. LAT DEVICES
LAT ports present additional complications. Most LAT problems are not in
Kermit, but can be reproduced using the SET HOST/DTE command or the SET HOST
/LAT command. The VMS LAT documentation contains information on configuring
LAT ports and troubleshooting problems. Your terminal server might have come
with additional documentation.
Experience shows that it is difficult to properly configure a LAT port to
handle both incoming and outgoing connections. Therefore seperate LAT ports
are recommended for incoming and outbound connections.
LAT devices should be configured /NOQUEUED (in your LATCP CREATE PORT or
SET PORT command); otherwise C-Kermit (or other software) will hang waiting
for a busy port to become free. /NOQUEUED is the default.
You might want a service on the LAT server that is connected to ALL the
dialout modems, i.e. a dialout modem pool. Example:
On Server:
Local> set privilege
Local> define service modem_pool port 1,2,3,4
[...]
On the OpenVMS System:
$ mcr latcp
LATCP> Create Port -
lta1000:/Application/Logical=(Name=$T1000,Table=System)
LATCP> Set Port lta1000: /Node=SAS323 /Service=Modem_Pool
5. CAPTIVE ACCOUNTS
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 example:
$ localopts = "/define=(""NOPUSH"")"
$ @ckvker.com
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.
II - 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 AXP, which you should assemble,
link, and run as follows:
$ macro ckvdeh (on the Alpha AXP, 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 AXP -- 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 AXP
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 AXP platforms, you should pick the right .HEX file for your environment:
TCP/IP Product VAX Alpha AXP
none CKVKER.HEX CKVAXP.HEX
CMU-OpenVMS/IP ("CMU/Tek") CKVVCMU.HEX (none)
DEC TCP/IP (UCX) CKVVUCX.HEX CKVAUCX.HEX
TGV MultiNet CKVVTGV.HEX CKVATGV.HEX
Wollongong WIN/TCP (PathWay) CKVVWIN.HEX CKVAWIN.HEX
Process Software TCPware CKVVPST.HEX CKVAPST.HEX
Labeled file converter: CKVCVT.HEX CKVACVT.HEX
Each HEX file was built from an .EXE file on the oldest VMS version we had
access to, in most cases 5-point-something. 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.
III - 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. 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 CKVVUCX.EXE SYS$TOOLS:KERMIT.EXE
$ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE) SYS$TOOLS:KERMIT.EXE
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
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.
CKEDEMO.INI
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.
IV - USING MODEMS
The following is reprinted by permission:
How to Use a MODEM With Your VAX
Richard B. Gilbert
Computer Systems Consultant
76702.1567@CompuServe.Com
Revised October 27, 1994
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 switches set to enable MODEM control signals.
The VAXStation 3100 does NOT support MODEM control! The MicroVAX 3100 does
support MODEM control.
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. 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, ...)
You will need to make some switch settings on your MODEM. The following
settings are for a US Robotics Courier 2400. See your MODEM's instruction
manual. The switch numbers will be different but the functions available are
typical. 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. Single phone line (As required)
8. Normal At command set (Must be enabled for auto dial.)
9. Online after +++
Many users have observed the VAX 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).
A command 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 - ! VAX 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 PROTECTION=W:R /DEVICE
! Sets device protection to allow non-privileged
! users to allocate the device for dialing out.
! Otherwise user must own device or hold SYSPRV.
* 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, use
/SPEED=xxxxx rather than /AUTOBAUD.
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, 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. Note that, while this works for
$! me on VMS V5.4, it has been reported to me that /HANGUP is not allowed
$! under VMS V5.5. The SET TERMINAL may not be necessary at all since the
$! DECserver DEFINE commands include equivalents for everything except
$! /ALTYPEAHD.
$ SET TERMINAL /PERMANENT /MODEM /DIALUP /HANGUP -
/ALTYPEAHD /HOSTSYNC LTA100:
$ SET PROTECTION=W:R /DEVICE LTA100:
4. Reboot or execute the commands in steps 2 and 3.
It appears that SET HOST /DTE LTAnn: no longer works as of VMS V5.5-2. I
suspect that it will not work under VMS V5.4-1 or higher with LATmaster
installed. Instead, define the MODEM port as a service on the terminal
server and use SET HOST /LAT service_name.
V - 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 3.0 or later, DEC C, or GNU GCC. VAX C has undergone
a large number of changes during its lifetime. Some header files may be
missing in earlier versions. VMS C-Kermit was developed using VAX C V3.2 and
VMS V5.5, but it was designed to work on earlier systems, back to VMS 4.4 and
VMS C 3.0, if built in those environments (but testing is needed for
verification). Please report any problems building C-Kermit on older VMS/C
configurations so they can be fixed (or at least documented as problems).
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.
BEWARE: VAX C can generate incorrect code under certain circumstances.
For example, if 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.
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.
Four build procedures are provided. You should use them in the this order
of preference:
1. For those with VMS MAKE (available from DECUS, written by Todd Aven of the
Software Sweatshop in Long Beach, NY, and also distributed with VMS
C-Kermit on magnetic tape or cartridge by Columbia University; to install
it, follow the directions in CKVMAK.HLP), a makefile is supplied, called
CKVKER.MAK, originally written by Terry Kennedy of Saint Peters Collge,
Jersey City, New Jersey. The makefile is CKVKER.MAK. Rename it to
MAKEFILE. (note the period):
$ RENAME CKVKER.MAK MAKEFILE.
To build C-Kermit with DEC C, type (but don't do it yet -- first read about
network options below):
$ MAKE
at the DCL prompt (shown as $). To build C-Kermit with GNU C, type:
$ MAKE GKERMIT
Use MAKE if you plan to be editing the source files and rebuilding C-Kermit
periodically. This eliminates the need to recompile source files that have
not been changed. NOTE: If you change compiler options but not the source
files, use "MAKE /FORCE" to force recompilation of all modules.
2. The CKVKER.COM DCL command procedure. This procedure unconditionally
compiles and links all the source modules into WERMIT.EXE. This procedure
can be used on any VAX that has suitable versions of VMS and C, and it is
the procedure you would normally use if you do not intend to be modifying
the source code after building the program. To build C-Kermit with the
DCL procedure, type:
$ @CKVKER
NOTE: CKVKER.COM should not be edited except for strictly local purposes.
It is generated automatically from CKVKER.MAK by:
$ MAKE/KEEP/NOEXECUTE/FORCE/OUT=CKVKER.COM
All changes of a global nature should be made to the makefile and then a
new CKVKER.COM generated from it as shown.
3. MMS. The CKVKER.MMS file can be used with MMS on VAX or Alpha or with
Mattgoat Software MMK.
4. CKVOLD.COM, for building Kermit on VMS 4.x systems. Or... You can
also build C-Kermit on a VMS 5.x or 6.x system, move the object modules
to a VMS 4.x system, and then do the linking there, to produce an
executable that will run on the VMS 4.x system. To do this:
1. generate CKVKER.COM (or use existing version) and rename
2. edit the COM file
(a) add "OLD_VMS" to the /DEFINE=(...) (and customize other options}
(b) add CKVOLD to the appropriate compile and link lists
(c) change library name, e.g., to CKVOLD (and make the library more
compact by adding "/DATA=REDUCE" to the /CREATE)
(d) make the file compile-only ("GOTO The_Exit" after the compile list)
(e) extract the link list to another file
(the command file uses DCL IF THEN ELSE constructs not available
on older systems)
3. compile
4. copy library and link file to older system
5. link & install
If you have the DEC FORTRAN 6.0 library, UVMTHRTL.EXE, installed, the
resulting KERMIT.EXE file will not run on VMS systems that have an older
FORTRAN library, or lack one altogether:
%DCL-W-ACTIMAGE, error activating image MTHRTL
-CLI-E-IMGNAME, image file $1$DIA0:[SYS1.SYSCOMMON.][SYSLIB]UVMTHRTL.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
The new FORTRAN library has a different identifier. To link with the old
version of the FORTRAN library, two possibilities exist:
1) Link with SYS$LIBRARY:STARLET/LIB which uses NO shareable images.
2) Perform two defines prior to linking (this causes warning messages)
DEFINE/USER MTHRTL FORTRAN$MTHRTL-VMS
DEFINE/USER VMTHRTL FORTRAN$VMTHRTL-VMS
The second option has been tested successfully on a VAX/VMS system that
has neither FORTRAN nor C installed.
CUSTOMIZING THE BUILD PROCEDURE
If you have a DCL symbol "localopts" (case doesn't matter) defined when you
use either the makefile or the .COM file, the contents of that symbol will be
used instead of the normal ones ("siteopts" -- see the makefile). You can use
any legal CC compiler option here. For example:
$ LOCALOPTS = "/UNDEFINE=(""DYNAMIC"")"
$ MAKE
-- or --
$ @CKVKER
Note the doubled quotes because they're inside a symbol definition. If you
don't have a LOCALOPTS symbol, the null string is used and SITEOPTS prevails.
LOCALOPTS is evaluated in the generated .COM file, so it works for both the
makefile and the .COM file.
If using LOCALOPTS to add or change compiler options, be sure to include ALL
such options, not just the additional ones, and be sure to include the /FORCE
modifier with your MAKE command, to force recompilation of all modules.
Read CKCCFG.DOC for further information about compile-time options for feature
selection.
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.
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.
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
WOLLONGONG TCP/IP
Wollongong 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.
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().
TGV MULTINET
If your VAX has the TGV MultiNet TCP/IP networking product, both procedures
automatically build 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.
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.
VI - CASE STUDY: ALPHA AXP 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 AXP 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 VMS AXP 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. But Kermit gets confused when it calculates line thruput based on
300 bps. 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.
VII - 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 AXP) 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
$!
$! 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 makefile DESCRIP.MMS 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)