Columbia Kermit/kermit.zip/archives/ckc197.zip/ckvbwr.txt

Text File | 2000-02-27 | 51KB | 1,145 lines

CKVBWR.TXT          "Beware File" for C-Kermit Version 7.0        -*- text -*-

            (Open)VMS VERSION FOR DEC VAX AND ALPHA

Applies to C-Kermit 7.0.197
Last update: 8 February 2000

Authors: Frank da Cruz and Christine M. Gianone (Columbia University, NYC);
         Terry Kennedy (Saint Peters College, Jersey City, NJ).

  Copyright (C) 1985, 2000,
    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.


CONTENTS

  1. INTRODUCTION
  1.1. Documentation
  1.2. Technical Support
  1.3. Other Sources of Information

  2. THE C-KERMIT COMMAND PARSER
  2.1. Running C-Kermit in DCL Command Procedures
  2.2. Running C-Kermit from ALL-IN-1
  2.3. Running C-Kermit under DECIntact

  3. COMMUNICATIONS
  3.1. Serial and LAT Communications
  3.1.1. Dialing
  3.1.2. Speed
  3.1.3. Echoing
  3.1.4. Modem Signals
  3.1.4.1. The SET CARRIER-WATCH Command
  3.1.4.2. The SHOW COMMUNICATIONS Command
  3.1.4.3. The WAIT Command
  3.1.4.4. The HANGUP Command
  3.1.5. Buffering and Flow Control
  3.1.6. LAT
  3.2. Network Communications
  3.2.1. X.25
  3.2.2. TCP/IP

  4. GENERAL FAILURES
  5. LOCAL FILE OPERATIONS

  6. FILE TRANSFER
  6.1. Automatic Transfer Mode
  6.2. Oddball File Formats
  6.3. Disk Quotas
  6.4. Control-Character (Un)Prefixing
  6.5. External Protocols
  6.6. Miscellaneous

  7. OTHER TOPICS
  7.1. Non-DEC Terminal Types


1. INTRODUCTION

This is the "beware file" for VMS C-Kermit 7.0.  It contains hints and tips
specific to the VMS version of C-Kermit not necessarily found in the manual,
or which developed since the manual was published (Section 1.1 below).
CKCBWR.TXT, contains similar material that applies to all C-Kermit versions:
UNIX, VMS, VOS, etc.  The CKERMIT2.TXT file contains documentation for
features that were added to C-Kermit since the second edition of "Using
C-Kermit" (which corresponded with version 6.0) was published.

VMS C-Kermit installation instructions are in the file CKVINS.TXT.  Please
be sure you have read that file before concluding that C-Kermit isn't working
right on VMS.

1.0. TERMINOLOGY

"VMS" as used in this document refers to both VMS and OpenVMS on VAX
processors and OpenVMS on Alpha (formerly known as AXP) processors.  Most of
the words in the previous sentence are trademarks (TM) of Digital Equipment
Corporation and/or Compaq Computer Corporation.

"DEC" is the way most people refer to Digital Equipment Corporation.

Digital Equipment Corporation was acquired in 1998 by Compaq Computer
Corporation, and thus references to Digital Equipment Corporation or DEC
should be interpreted accordingly in light of the evolving integration,
transfer of copyrights and licenses, product renaming, etc.  In this document
we stick with the traditional and familiar nomenclature.

There might be contradictory bits of advice in this file (and in the
CKVBWR.TXT file), since much of the information was culled from different
sources at different times.

1.1. DOCUMENTATION

  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: [phone]
    Email: [e-mail]
    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.

The various supporting online text files were renamed in C-Kermit 7.0 for
better operation with Windows-based Web browsers, which assume that .DOC
files are Microsoft Word documents, etc:

 Old Name            New Name
  CKERMIT2.UPD        CKERMIT2.TXT
  CKVKER.BWR          CKVBWR.TXT   (this file)
  CKVINS.DOC          CKVINS.TXT
  etc etc...

1.2. TECHNICAL SUPPORT

Please consult the documentation listed above, plus the CKCBWR.TXT file and
this file itself, before submitting questions, reporting problems, etc, to:

Email: [e-mail]

 News: comp.protocols.kermit.announce          <-- Announcements, moderated
       comp.protocols.kermit.misc              <-- Discussion, unmoderated

  Web: http://www.columbia.edu/kermit/         <-- Kermit Project Home Page
       http://www.kermit-project.org/          <-- Alternative Web address
       http://www.columbia.edu/kermit/faq.html <-- Frequently Asked Questions

 Post: The Kermit Project
       Columbia University
       612 West 115th Street
       New York NY  10025-7799
       USA

 Fax: [phone]
  or: [phone]

Telephone support also available:

  USA Only:  [phone], cost: $2.50 per minute
  Anywhere:  [phone], cost: $25.00 per call, payable via Visa or MC.

1.3. OTHER SOURCES OF INFORMATION

The OpenVMS Frequently Asked Questions (FAQ) document is available at various
sites on the Internet, including:

  ftp://ftp.digital.com/pub/Digital/dec-faq/vms
  ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms
  http://www.openvms.digital.com/wizard/openvms_faq.txt

The following newsgroup is dedicated to discussion of VMS-related topics:

  comp.os.vms

And this one to more general DEC-related topics:

  comp.sys.dec


2. THE C-KERMIT COMMAND PARSER

VMS-style command-line editing (arrow keys, etc) is not supported.  Kermit
does not use the VMS F$PARSE facility -- it has its own command parser that
lacks certain features of F$PARSE (arrow-key editing, etc) but has many other
features that F$PARSE lacks: context-sensitive "?"-help and file lists,
keyword and filename completion, filename menus, variables, macros, etc.
C-Kermit does, however, support command recall via Ctrl-B and Ctrl-N.

If you write a DCL command file that starts Kermit with a command-file name
as its first command-line argument, e.g.:

  $ kermit oofa.ksc

and then SUBMIT this DCL command file as a batch job, be aware that the
batch job is executed out of your login directory, so if the command file
(OOFA.KSC in this case) is not in your login directory, you must either SET
DEFAULT to the directory it is in, or else give a fully qualified filename:

  $ set default [mydir.mysubdir]
  $ kermit oofa.ksc

or:

  $ kermit [mydir.mysubdir]oofa.ksc

Contrary to expectations of VMS users, the MSEND command does NOT use
commas to separate file specifications.  E.g. say this:

  C-Kermit>msend ckc*.% cku*.% ckv*.%

not this:

  C-Kermit>msend ckc*.%, cku*.%, ckv*.%

CD (Change Directory) to a DECnet node does not work in VMS C-Kermit.

The VMS 6.1 and 6.2 C Run Time Libraries (CRTL) have bugs in them that prevent
the CD command from working totally right when given no argument, which is
supposed to put you back in your login directory, when SYS$LOGIN indicates a
search list and/or hidden directories.  C-Kermit tries to work around this bug
(technical explanation: use CRTL chdir(), which is supposed to do all the
right things; if it fails then use the VMS sys$setddir() system service, which
works in cases where VMS 6.1/6.2 CRTL doesn't, but which applies to your whole
job rather than to Kermit's process tree only, and then when Kermit exits, it
tries to use sys$setddir() again to restore your startup directory -- but if
C-Kermit is interrupted or terminated abnormally this won't work, etc etc.)
If you have trouble with all this, then CD to the desired device:directory
explicitly or define a macro to do this.  (The problem, if it occurs, is in
the library that C-Kermit was linked with, not the one on your VMS system, so
installing ECOs, etc, would not help.)

OPEN !WRITE does not work in VMS C-Kermit.

VMS C-Kermit does NOT provide program status codes in the normal VMS manner.
Rather, it returns the codes described on pp. 323-324 of "Using C-Kermit", by
assigning them to the symbol CKERMIT_STATUS.  For example, if a RECEIVE
operation failed:

  $ show symbol ckermit_status
    CKERMIT_STATUS == "4"
  $

Arguments supplied to the EXIT (or QUIT) commands take precedence:

  C-Kermit>exit 1234
  $ show symbol ckermit_status
    CKERMIT_STATUS == "1234"
  $

If C-Kermit encounters no execution errors, and EXIT (QUIT) is given without
an operand, then:

  C-Kermit>exit
  $ show symbol ckermit_status
    CKERMIT_STATUS == "0"
  $

You can use the CKERMIT_STATUS symbol as in this DCL example:

  $ kermit -s oofa.txt
  $ if ckermit_status .eq. 0 then goto ok


2.1. RUNNING C-KERMIT IN DCL COMMAND PROCEDURES

It is often desirable to wrap C-Kermit in a DCL command procedure.  Such
a procedure, for example OOFA.COM, can be run either directly on your job's
controlling terminal by:

  $ @OOFA [ parameters ]

or as a batch job via:

  $ SUBMIT OOFA [ switches ]

When you are writing a DCL command procedure that runs C-Kermit, you
must make a choice:

 1. If you want to be able to include Kermit commands in the DCL procedure as
    "image data" (i.e. lines that don't start with $), then you can NOT
    include any Kermit commands that would require access to the real console
    terminal's keyboard and screen, such as CONNECT.  That is, the person who
    runs the DCL procedure can NOT interact directly with a remote computer.
    This type of DCL command procedure can be run either on a terminal via @,
    or as a batch job via SUBMIT.

 2. If you want the user to be able to interact directly with the remote
    computer through Kermit's CONNECT command, then:

    (a) The DCL procedure can be run only with @, not with SUBMIT.  That is,
        it cannot be a batch job; it must have access to the console terminal.

    (b) You must include the following DCL command in the DCL procedure
        immediately before starting Kermit:

        $ DEFINE /USER SYS$INPUT SYS$COMMAND

    (c) You can not include Kermit commands as "image data" in the DCL command
        procedure.  Instead, you must create a separate Kermit command file,
        and use command-line arguments to instruct Kermit to execute it; for
        example:

        $ define /user/nolog sys$input sys$command
        $! Execute oofa.ksc instead of normal initialization file.
        $ kermit -y oofa.ksc

        or:

        $ define /user sys$input sys$command
        $! Execute oofa.ksc after executing normal initialization file.
        $ kermit "-C" "take oofa.ksc"

Here is a sample DCL command procedure of the first type, which can be run
either on the controlling terminal or as a batch procedure, and requires no
interaction from the user.  Lines beginning with dollar sign ($) are DCL
commands, other lines are fed to the application program (Kermit).

  1. $ write sys$output "Hello from DCL"
  2. $ set default [myuserid.mysubdirectory]
  3. $ kermit
  4. set background off
  5. echo Hello from C-Kermit
  6. @ write sys$output "Hello from DCL from inside C-Kermit"
  7. take oofa.ksc
  8. exit
  9. $ write sys$output "All done."

(The numbers are not part of the file.)  Lines 1-3 are DCL commands.  Line 3
starts C-Kermit.  Lines 4-8 are C-Kermit commands.

Line 4 causes Kermit prompts and commands read as image data from the
remainder of the .COM file to be echoed to the batch log.  Normally this is
not done, and the only material that goes into the batch log is output from
Kermit commands like ECHO (next item).   The SET BACKGROUND OFF command
tells Kermit that even though it is running in batch, it should issue its
prompt and echo its commands.  You can accomplish the same thing by starting
Kermit the "-z" command-line option (line 3 would be "$ kermit -z").

Line 5 shows how to enter messages in the batch log.  Line 6 shows
how to run DCL commands from within Kermit (you can use @ (at-sign), !
(exclamation mark), or the word RUN -- all of them are synonyms, followed by
a DCL command).  Line 8 exits from C-Kermit back to DCL.

In line 7, C-Kermit is told to execute a script program from another file,
OOFA.KSC.  Script programs to be run during the batch session are best kept in
separate C-Kermit command files because certain commands, notably GOTO, FOR,
WHILE, and XIF, do not work when entered in the interactive command stream.
Here is a sample command file:

set take echo on        ; Make Kermit commands appear in the batch log
set take error on       ; This stops execution automatically upon error
set input echo on       ; This makes INPUT material appear in the batch log
set host blah           ; Make a network connection to host "blah"
set file display serial ; Use SERIAL or NONE for the batch log, not FULL or CRT
input 5 login:          ; Wait for a login prompt
output myuserid\13      ; Send my user ID and a carriage return
input 5 Password:       ; Wait for password prompt
output \$(P1)\13        ; Send my password (see below) and a carriage return
input 20 \13\10$\32     ; Wait for system prompt
output kermit\13        ; Start Kermit on host "blah"
input 5 Kermit>         ; Wait for Kermit> prompt
output server\13        ; Put remote Kermit in server mode
in 5 READY TO SERVE...  ; Wait for READY message
get oofa.txt            ; Get a file from the remote server
bye                     ; Terminate the remote session
end                     ; Return to local C-Kermit prompt

Note that the commands from a TAKE file are not echoed to the batch log
unless you include SET TAKE ECHO ON.

VERY IMPORTANT: Batched login scripts are inherently insecure because the
passwords are visible in plaintext, either in a file or else in the batch
queue entry.  VMS presently offers no secure way that we know of to enter a
password into a batch job.

Two very insecure methods can be used:

  1. Put the password in the Kermit script file.  The risk here is that
     anybody who gains access to the file, or to the system backup tapes, can
     learn your password on the remote system.

  2. Give the password as a parameter to the SUBMIT command when starting the
     batch job, for example:

     $ SUBMIT OOFA /NOTIFY /PARAM=("mypassword")

     (This sets the DCL parameter P1 to your password on the remote host (for
     further information, give the DCL command "help submit /param").
     Quotation marks are necessary to preserve lowercase letters (important
     when logging in to UNIX hosts).  DCL parameters may be referenced in
     Kermit commands as \$(P1), \$(P2), etc.)  The disadvantage here is that
     the VMS SHOW ENTRY/FULL command displays the parameters from your SUBMIT
     command, making the password visible to (at least) the system operator,
     and (most likely) also to other users, such as members of your group
     (batch queues are, by default, read-accessible by all members of their
     group).

Both methods can be made somewhat safer by adjusting the protections on the
files and/or batch queues that will contain sensitive information, but there
can be no guarantees.  Therefore: EXERCISE EXTREME CAUTION with passwords in
login scripts and batch jobs.

And please note further that passwords passed in plain text -- as they still
must be in most cases, particularly those involving dialup access -- are
subject to discovery by various other means, including, but not limited to,
wire tapping, Ethernet packet tracing, etc.

2.2. RUNNING C-KERMIT FROM ALL-IN-1

  Dr. David Kelly, Australian Environmental Protection Authority
  [e-mail]

ALL-IN-1 uses mailboxes (MBX) devices, rather than terminals.  TT: is
reassigned from the user's controlling terminal to a mailbox device.  C-Kermit
uses TT: as its default line device and so doesn't work straight off under
ALL-IN-1.  SYS$INPUT is reassigned to something else again.  SYS$OUTPUT
remains assigned to the user's original terminal line so it can be used to
specify the line device for C-Kermit when called from within ALL-IN-1.  Below
is a script which can be run from ALL-IN-1 which calls C-Kermit to receive a
file.  SYS$OUTPUT is temporarily redefined to stop some guff showing on the
screen.

$! RECEIVE_FROM_PC.COM
$!
$! Transfer file from PC into ALL-IN-1 using KERMIT
$! Invoked by TRANSFER_PC_TO_A1.SCP, which is in turn called by the RF
$! option on DT menu.
$!
$ set noon
$ on control_y then goto exit
$
$       tt1=f$trnlnm("sys$output")
$       kermit :== $epa__system:Ckermit
$       define/user sys$input sys$command
$       define sys$output sys$login:del.txt
$       kermit -l 'tt1' -b 9600 -r -a a1file.a1f -q -i
$       deassign sys$output
$       del sys$login:del.txt;
$exit:
$ exit

Similarly a file can be sent :

$! SEND_TO_PC.COM
$! Transfer document from ALL-IN-1 to the PC
$! invoked by TRANSFER_A1_TO_PC.SCP which is, in turn, called by the
$! SF option on the DT menu
$!
$ set noon
$ on control_y then goto exit
$!
$       write oamailbox "OA GET #CURDOC_FILENAM"
$       @dclmailbox:
$       a1file = "''result'"
$       vmsfile = "A1FILE.A1F"
$       copy/nolog/noconfirm 'a1file' 'vmsfile'
$       kermit :== $epa__system:Ckermit
$       define/user sys$input sys$command
$       tt1=f$trnlnm("sys$output")
$       define sys$output sys$login:del.txt
$       kermit -l 'tt1' -b 9600 -s A1FILE.A1F -q -i
$       deassign sys$output
$       del sys$login:del.txt;
$       if $severity .le. 1 then goto exit
$! if an error occurs, tell ALL-IN-1
$       write oamailbox "OA GET $PC_KERMIT_STATUS=0"
$       @dclmailbox:
$exit:
$ deletex/nolog a1file.a1f;*
$ exit

2.3. RUNNING C-KERMIT UNDER DECINTACT

To use C-Kermit in remote mode under DECIntact, you must:

 (a) Have C-Kermit 6.1 or later, and:
 (b) Tell it to "set line /share tt:".

This might also work with ALL-IN-1 (Section 2.2).


3. COMMUNICATIONS

(Also see Section V of CKVINS.TXT: "Using Modems" by Richard B. Gilbert.)

3.1. SERIAL AND LAT COMMUNICATIONS

If you are experiencing very poor performance on serial connections, use the
VMS command SHOW TERMINAL to make sure that the terminal device has the DMA
(Direct Memory Access) characteristic.  If it does not, try setting it (or
get your system manager to, in case privilege is required):

  $ SET TERMINAL device_name /PERMANENT/DMA

On some slower VAX models with built-in serial ports, such as the VAXstation
3100 or MicroVAX-II, receiving files on serial ports at (say) 19200 bps
results in high CPU utilization, slowing down the system for other processes.
This is because on certain systems, such as the VS3100, serial ports interrupt
the CPU every time a character arrives.  Most VMS systems nowadays, however,
support either DMA for serial port i/o, or have their users coming in through
terminal servers.

3.1.1. Dialing

If dialing out a serial port does not work at all -- modem ignores commands
sent to it, etc -- make sure the terminal port has the /MODEM characteristic,
e.g.:

  $ SET TERMINAL TTA0 /MODEM /PERM

Dialing is possible only on LAT devices and on serial ports that have that
have the /MODEM attribute (e.g. "set term tta0 /modem /altypahd /perm").
The modem must be configured for "DSR tracks CD" -- that is, it must not
turn on its DSR signal before the connection is made; otherwise VMS will
hang up on it during the dialing process.  C-Kermit 7.0 and later include
"&S1" in the initialization string for modems that use the AT command set.
If you are modifying init strings or defining your own modem type, be sure
to include this command or the equivalent.

If a DIAL or SET SPEED command gives the error:

  ?ttbin: sys$qiow: %SYSTEM-F-NOLOG_IO, operation requires LOG_IO privilege

then either the user must be given LOG_IO privilege or else the device must be
given the SET_SPEED attribute.  However, note that under certain versions of
VMS the TT2$M_SETSPEED bit in TTY_DEFCHAR2 is not properly propogated to LAT
devices.  It is best to issue the command SET TERM/PERM/SET_SPEED LTA31: at
startup when the LTA31 device is initially created (which, of course, would be
done by a sufficiently privileged account).

"How do I dial with C-Kermit and then exit, leaving the connection open so I
can use it from another application?"  Prior to starting Kermit, tell VMS to
set the device to /NOMODEM.  Another possibility is to allocate the line
BEFORE you run C-Kermit.  Ownership is defined as either having a channel
assigned to the device or having allocated the device.  All the channels get
closed when the image exits, but allocation persists.

3.1.2. Speed

Prior to C-Kermit 6.0, there was no way to select a serial communications
speed higher than 38400 bps.  In version 6.0, it is possible to SET SPEED
57600, 76800, and 115200, since these speeds are supported in VMS 6.x and
later.  However, the fact that you can set a particular speed doesn't mean
this will work.  The device might not support it.  In some cases, the device
will actually use the low-order bits of the speed value, because its speed
register is smaller than the codes used for the new higher speeds.

3.1.3. Echoing

If you CONNECT to a modem or other device, and see a neverending stream of
messages, the terminal device probably has the /LOCAL_ECHO characteristic.
As of edit 189, C-Kermit attempts to turn off this characteristic
automatically as part of the SET LINE procedure.

3.1.4. Modem Signals

A VMS serial communication device has either the /MODEM or else the
/NOMODEM characteristic.  You can view a device's configuration with the
VMS SHOW TERMINAL command, for example:

  $ SHOW TERMINAL TTA0:

and you can change it with SET TERMINAL, e.g.:

  $ SET TERMINAL TTA0: /MODEM

When a /MODEM device is opened (e.g. with C-Kermit's SET LINE command), VMS
asserts the DTR signal (assuming the interface and cable support modem
signals), and allows I/O with the device even if the device is not asserting
the CD signal.  However, once the device does assert CD (or, perhaps more
accurately, whenever the phone is "off hook"), VMS requires CD to stay up for
further I/O; if the CD signal goes off, VMS returns a hangup (SS$_HANGUP)
indication.

When a /NOMODEM device is opened, VMS does not assert any modem signals,
including DTR, and does not require or test for any modem signals from the
device.  Thus the /NOMODEM is of little use with any kind of data
communication equipment (e.g. modems, terminal servers, multiplexers) that
require DTR (some modems can be configured to ignore DTR, e.g. with AT&D0).

On the other hand, /NOMODEM is probably necessary for VMS serial ports that
do not support modem signaling (such as the one on the VAXstation 3100), or
cables that do not contain all the needed wires (such as DEC's MMJ
connector; looks like an RJ45 modular jack, but with an offset tab).  If you
use a /NOMODEM port, the device it is connected to must be configured to
operate without seeing DTR, and in any case C-Kermit will not be able to
detect connection loss.

Setting /MODEM or /NOMODEM on a LAT device has no effect on the LAT port
itself, nor, evidently, on VMS -- reportedly, SS$_HANGUP is still reported
when the LAT device hangs up, even when set to /NOMODEM.

Although it is within the power of an application such as C-Kermit to switch
the device between /MODEM and /NOMODEM, it is not practical because doing
so hangs up the device.  Thus C-Kermit lets the VMS terminal driver control
the modem signals, and interprets and reacts to indications about modem
signals from VMS as best it can, according to your preferences.

3.1.4.1. The SET CARRIER-WATCH Command

  The behavior described below is new to C-Kermit 6.1 Alpha.11.

When CARRIER-WATCH is ON or AUTO, C-Kermit checks for carrier at the
beginning of any communications-related command (CONNECT, SEND, GET, FINISH,
INPUT, OUTPUT, etc), and each of these commands fails at any time during its
execution if VMS reports a "data set hangup" (SS$_HANGUP).  Thus, it is
not possible to CONNECT to a modem and type AT commands before the modem has
made a connection if CARRIER-WATCH is ON or AUTO.

When CARRIER-WATCH is OFF, the aforementioned checks are not made, and any
SS$_HANGUP errors that occur are ignored.

If the device is set to /NOMODEM, all checks for carrier will fail, and the
device will be unusable unless CARRIER-WATCH is OFF.

On LAT devices, the initial checks are never made since LAT devices do not
reveal their modem signals to VMS.  SS$_HANGUP errors, however, are treated
as they are for real serial ports.

3.1.4.2. The SHOW COMMUNICATIONS Command

As of C-Kermit 6.1 Alpha.10, SHOW COMMUNICATIONS should display modem
signals on both VAX and Alpha when the SET LINE device is a local serial-port
device.  Modem signals are not displayed for LAT devices.

3.1.4.3. The WAIT Command

As of C-Kermit 6.1 Alpha.10, the WAIT command (which waits a specified
amount of time for a given set of modem signals to appear on the current SET
LINE device) should work on both VAX and Alpha serial port devices.  It does
not work on LAT devices.

3.1.4.4. The HANGUP Command

When used on a serial communication device, the HANGUP command (as well as
the CONNECT-mode escape command, H, and the hangup done by the DIAL command
when DIAL HANGUP is ON) takes at least 3 (three) seconds; perhaps as many as
six.  This is a feature of VMS.

If you use the HANGUP command on a /NOMODEM device that is, nevertheless,
connected to a modem, be sure that Kermit has been told to:

  SET MODEM HANGUP-METHOD MODEM-COMMAND

3.1.5. Buffering and Flow Control

During terminal connection (SET LINE) and file transfer over a serial device,
buffer-overrun or BYTLM-quota-exceeded messages might appear.  It is essential
that any VMS system that needs to use Kermit or any other program to transfer
files over serial devices, especially when long packets or sliding windows are
to be used, be SYSGEN'd with large typeahead buffers, and that user accounts
be given large BYTLM quotas.  See CKVINS.TXT.

  Note that LATmaster software (optional as of VMS V5.4-1, mandatory as of
  VMS V5.5) requires a minimum Alt-Typeahead buffer of 2064 bytes.  Thus, you
  may already have increased the size.

To get around problems on systems where users have small BYTLM quotas, the
txbufr() routine in CKVTIO.C has been limited to reading 512-byte chunks at a
time from the communication device.  This does not appear to have an adverse
affect on performance.  If it does, a quick fix is to recompile CKVTIO.C,
defining CKV_IO_SIZE to be something bigger, e.g.

  /define=("CKV_IO_SIZE=8192")

or whatever.  A better fix might be to have txbufr() check the user's
remaining BYTLM quota before doing each read.  But the overhead in doing this
might cancel out the advantage of doing it.

The SET FLOW RTS/CTS command is not supported in the VMS version of C-Kermit.
VMS versions prior to 7.0 do not support RTS/CTS (hardware) flow control.
However, RTS/CTS flow control can still be used on LAT ports that support it.

VMS flow control is governed by two SET TERMINAL parameters: /TTSYNC and
/HOSTSYNC.  TTSYNC lets the terminal control the flow of data from the host
and HOSTSYNC lets the host control the flow of data from the terminal.  In
general, these are implemented as Xon/Xoff flow control in each direction, but
on LAT and TCP/IP connections, they can also affect the internal networking
protocol, and they can be implemented on the LAT server's serial interface
with any flow control method at all - Xon/Xoff, RTS/CTS, etc.

In VMS C-Kermit, SET FLOW XON/XOFF is equivalent to $ SET TERM /HOSTSYNC
/TTSYNC.  There should never be a reason to SET FLOW NONE in VMS -- in fact,
it is almost always a bad idea (see File Transfer section).

When C-Kermit is in "remote mode", i.e. it is on the far end of a connection,
and is not establishing a connection itself, it uses your current VMS SET
TERMINAL parameters for flow control during command processing.  During packet
mode, however, it obeys your C-Kermit SET FLOW-CONTROL setting to ensure the
chances of lost data are minimal.

When C-Kermit is in "local mode", i.e. it is being used to establish a
connection with SET LINE or TELNET, there are two components to your
connection: the part between your terminal and C-Kermit (call this "Part A"),
and the part between C-Kermit and the remote computer or service that you have
connected to ("Part B").  At all times, the flow control used on Part A is
governed by your VMS SET TERMINAL parameters, and the flow control used on
Part B is always governed by C-Kermit's SET FLOW-CONTROL command.

If you are using C-Kermit in local mode to access a remote host to use the
EMACS editor, you might find that the Ctrl-S (Search) and Ctrl-Q (Quote)
commands don't work -- your screen and keyboard "freeze" when you type Ctrl-S,
and Ctrl-Q seems to have no effect (except unfreezing your session after
Ctrl-S).  This means that your VMS command terminal has the /TTSYNC
characteristic; Ctrl-S and Ctrl-Q are being used for flow control between your
terminal and the VMS system -- the remote system and EMACS never see them.
There are two ways around this problem:

 1. Tell VMS to SET TERM /NOTTSYNC before starting C-Kermit.  In this case,
    you are in danger of losing data on the connection, particularly if your
    connection to VMS is through a LAT device.

 2. Leave the /TTSYNC characteristic in force and use the long forms for the
    EMACS commands: ESC-X Search-Forward and ESC-X Quoted-Insert.  Or assign
    these functions to other EMACS keys in your EMACS initialization file.

3.1.6. LAT

It is possible to SET LINE to an LTA (LAT) device, but correct operation is
reportedly dependent on the version of DECserver code and the VMS version, and
which patches have been applied, and of course the way the whole setup is
configured.  More about LAT configuration in CKVINS.TXT.

If you use C-Kermit to SET LINE to an LTA device and receive a hangup message
immediately:

  contti: ttiosb.status: %SYSTEM-F-HANGUP, data set hang-up

then:

 . Perhaps the line is already being used on another system that is
   connected to the same terminal server (in this case SET HOST /DTE will
   fail the same way).  Unfortunately LAT has no way to signal this
   condition.

 . Make sure you've created an LTA port on your VMS system which is
   mapped to the DECserver port that the modem is connected to.

 . Can you use the VMS SET HOST/DTE command to connect to that line?  If you
   get the same error (which you should) there's a configuration problem in
   the DECserver setup for that port, or the devices protection, or your
   privileges or quotas, or somesuch.

 . In order for VMS to connect to the dial-out modem, it needs to see the
   carrier detect signal asserted.  If that signal isn't asserted, the server
   will return a "hangup" error on the first character sent to the port.
   C-Kermit's SET CARRIER command has no effect in VMS.

 . Additionally, some modems want to see various settings on RTS/CTS and
   DSR/DTR before they will accept input.  If you have a breakout box and
   someone who is skilled at using it, you can usually resolve these problems.

C-Kermit puts LAT terminal servers into PASSTHRU mode, which disables their
forward/backward session switch characters.

Reportedly, if you have CONNECTed out through a LAT device, the CONNECT-mode
escape command to hang up (<esc-char>U) does not work.  Reason: unknown.
Cure: unknown (The LAT programming interface is very poorly documented).
Workaround: SET LINE <cr> or CLOSE <cr> to close the SET LINE device.

Reportedly, although Kermit can SET LINE to a LAT device and work OK, the
same can't be said for a "LAT group" (whatever that is).  The user who
submitted this report said that this problem could be worked around by telling
VMS to SET TERM <blah> /NOALTYPEAHD before starting Kermit (take this one
with a grain of salt).

Reportedly, to use C-Kermit with a LAT device under LATmaster, the associated
terminal device must be set /NOREADSYNC.

Reportedly, when transferring files TO a VMS system over a LAT connection (for
example, from a PC equipped with PATHWORKS or SuperLAT and MS-DOS Kermit),
packet sizes greater than 255 (some reports say 70!) cannot be used,
irrespective of the VMS SYSGEN parameters regarding MAXBUF, etc.  The problem
seems to lay in the LAT protocol itself, or the particular implementation of
it, whereby applications are not informed of -- and cannot find out -- limits
on transmission.  (And yet, others say they have no problems with file
transfers over LAT connections, even with packet sizes greater than 1000.)

3.2. NETWORK COMMUNICATIONS

There is (as yet) no support for initiating connections over DECnet, nor for
VAX/PSI.  Certain types of TCP/IP are supported (including DEC TCP/IP (UCX),
CMU-OpenVMS/IP ("CMU/Tek"), TGV MultiNet, Wollongong WIN/TCP or PathWay,
Process Software TCPware); other types: not yet (e.g. Fusion).

3.2.1. X.25

Poor performance has been observed when C-Kermit is receiving files on a
VAX/PSI (X.25) system, attached to a certain X.25 network (Autonet), but not
others, attached via a DSW42 interface: huge numbers of I/O requests drive the
load way up.  Reportedly, "this is due to a VAX PSI feature called
Synchronized Echo Protocol (SEP), which is supposed to coordinate echo by the
X.25 PAD, e.g. when typing ahead.  When disabling this feature, the file
transfers proceed fast and efficient.  This feature is a network-specific X.25
1"facility" negotiated at call-setup time, not an X.3 parameter (standard or
otherwise) -- Facility Number 66 (decimal, or 42 hex).  It could not even be
set or viewed by the user or the VAX administrator.  It had to be disabled by
the network provider.  I think that most X.25 networks do not even implement
this feature and thus is it not common issue.  In any case, in our situation,
I asked the X.25 network provider to disable this feature, and now C-Kermit is
performing efficiently, but now, of course, echoing (e.g. of material that is
typed ahead) is no longer synchronized."

3.2.2. TCP/IP

Reportedly CMU/IP support in C-Kermit 6.1 does not work at all.
Cause and cure unknown.

The TCPware version works correctly with TCPware versions 4.1-2 or later;
earlier versions, such 3.1-3, have a bug that can result in failure of
C-Kermit to make network connections, with a message like:

 ?contti: network sys$qio: %SYSTEM-F-IVCHAN, invalid I/O channel

Process Software recommends upgrading to the current TCPware release.

DEC TCP/IP (UCX) 2.0C and earlier, which runs only on VAXes, has a bug that
prevents TCP port lookup by name from working as expected, so if you tell
C-Kermit to "telnet blah" or "set host blah", you'll get a "Connection
refused" error.  If you don't specify a port, Kermit substitutes the service
name "telnet" and then asks UCX to look it up; UCX finds it but erroneously
returns a port number with its bytes swapped (e.g. 5888 instead of 23), and
then Kermit tries to connect to port 5888 on the host; most hosts will refuse
the connection; if they don't, you probably didn't reach a Telnet port anyway.
The workaround is to include a port number (not name) in your command.  Any of
the following will work:

  set host blah:23
  set host blah 23
  telnet blah:23
  telnet blah 23

A patch was issued after C-Kermit 6.0.192 was released, adding the following
command to VMS C-Kermit versions built on VAXes with UCX:

  SET TCP UCX-PORT-BUG { ON, OFF }

If you have UCX 2.0C or earlier, and C-Kermit won't make Telnet connections,
tell it to:

  SET TCP UCX-PORT-BUG ON

In case your version of C-Kermit 6.0 does not have this patch, then use
the workaround of specifying a port number.

The previous hint also applies when running UCX versions of C-Kermit under
Wollongong or other TCP/IP products that have a UCX compatibility mode.  If
you get "connection refused", then include the port number in the TELNET or
SET HOST command.

The UCX version of Kermit works on MultiNet systems too, because MultiNet
automatically goes into "UCX compatibility mode" when a UCX application is
run.

You can also use the non-network version of C-Kermit on a MultiNet system to
make TCP/IP connections as follows:

$ telnet/create foo.bar.baz.com
Trying...
TELNET session now connected to _NTY5:
%DCL-I-ALLOC, _$4$NTY5: allocated

$ kermit
C-Kermit 6.0.192, OpenVMS AXP
Type ? or HELP for help
C-Kermit>set line telnet_nty
C-Kermit>connect
etc...

If you enter the VAX from elsewhere through a TELNET connection, and the VAX
is running CMU-OpenVMS/IP, Fusion, or an early version of DEC TCP/IP (UCX),
you might notice that file transfers into the VAX fail almost immediately.  If
this happens, it is most likely the result of small VMS typeahead buffers.
See CKVINS.TXT for how to increase typeahead buffer sizes, or work around the
problem by telling VMS C-Kermit to ask for smaller packets, for example:

  C-Kermit>set receive packet-length 65  ; (Use the longest length that works)

When using the CMU-OpenVMS/IP TCP/IP transport, assign the system logical
INET$SERVICE_TELNET_TCP to the telnet port as follows:

    $ DEFINE /SYSTEM INET$SERVICE_TELNET_TCP 23

This is only required if the -j option is used without specifying a port to use
(e.g. -j host).  If this logical assignment is not made using `-j host' option
will fail with the error:

  %CKERMIT-E-FATAL, can't open host connection

The default port, hardcoded in C-Kermit, is 23.  Another port may be specified
using the -j option as `-j host:port'.

SET INPUT ECHO OFF seems to have no effect when given to VMS C-Kermit and
the INPUT command is reading from the console terminal.

4. GENERAL FAILURES

...can occur for many reasons beyond Kermit's control, many of them related to
VMS system parameters or limits on the user or process: disk quotas, user
pagefile quotas (AUTHORIZE parameter PGFLQUO), system pagefile space filling
up, etc.  See CKVINS.TXT (installation instructions) for details.

To increase a user's pagefile quota, tell AUTHORIZE to MODIFY
username/PGFLQUO=number.  The system itself might be running out of pagefile
space, which would cause the system to grind to a halt and eventually crash.
You can check the system pagefiles with SHOW MEMORY/FILE: add up the "Free"
numbers for the [*]*PAGEFILE.SYS files and see if the total is big enough
(there should normally be at least 100K free pages on an active system).  If
not, the system manager would use the procedure @SYS$UPDATE:SWAPFILES to
resize the files.

VMS C-Kermit can hang or crash with an "access violation" under certain
conditions when trying to hang up a modem-controlled device that is already
hung up; investigation shows that the hang or crash happens in VMS kernel
space, not in Kermit.

Reportedly, on certain VMS configurations (but not others), the following
sequence can cause C-Kermit to crash:

  set host somewhere
  connect
  (escape back)
  receive
  Ctrl-C
  connect

The problem appears to be in the VMS C library's implementation of signal
handling and longjumps.

"Zombie" process can be left behind under certain conditions when a VMS
Kermit server has been sent a BYE command, particularly over a TCP/IP
connection (connection disappears before VMS has a chance to print its
"logged out" message, and now there is nothing to print it on).

One user reported "massive failures" when transferring files with VMS C-Kermit
through a particular kind of terminal server.  She had followed all the
directions in the manual, the CKVINS.TXT file, and the CKVBWR.TXT files (as it
was before this item was added).  The terminal server, an Equinox ELG48, uses
TELNET protocol to a DECstation 3000 Model 600 running VMS 6.1 and TGV
MultiNet 3.3.  Later, she reported: "It turned out that upgrading the software
on our terminal server has fixed the problem.  It's so odd that the problem
only occured after we upgraded from VMS V5.5-2 to V6.1, since the terminal
server worked fine before the upgrade.  It's also weird that this terminal
server has always worked fine for our Suns, also.  Here's the details of the
terminal server if you want to keep these details on file: Equinox PBX 20 with
ELG 48 board.  The ELG 48 rev was 2.30.  After upgrading it to V2.33,
everything works fine."

5. LOCAL FILE OPERATIONS

As of edit 190, VMS C-Kermit supports append operations: the various logs
(packet, debug, transaction, etc) can be opened in append mode by including
the APPEND keyword after the filename, e.g.:

  LOG TRANSACTIONS TRANSACT.LOG APPEND

An arbitrary file can be opened for output in append mode:

  OPEN APPEND OOFA.TXT

and the SET FILE COLLISION APPEND option now works during file transfer.

When using append operations:

 . Be careful not to append files of different types together, such as a text
   file to an indexed file, or a fixed-record binary file to a text file, etc.
   The result will generally be unusable.

 . SET FILE COLLISION APPEND does not work when the FILE TYPE is LABELED.
   This is deliberate: labeled transfers are designed to give you an exact
   copy of the file, including attributes.

There is no facility in C-Kermit to distinguish between "overwriting" and
"versioning".  SET FILE COLLISION OVERWRITE always creates a new version in
VMS.

BUG: As of this writing, APPEND operations do not use the RMS "first free
byte", and so start on a new block boundary.

6. FILE TRANSFER

Remember that VMS file formats are substantially different from those on
UNIX, DOS, Windows, etc.  Be sure to consult the VMS Appendix of "Using
C-Kermit" on this topic, and to find out the special commands and procedures
that apply to VMS.

C-Kermit 6.1 Beta has the following problems, which we hope can be resolved
before the final release:

 . LABELED mode lacks relative pathname option; directory-tree transfers
   don't work between two VMS systems because they go into LABELED mode
   automatically (THIS ONE SHOULD BE FIXED AS OF BETA.05).
 . Confusion about SET TRANSFER MODE { AUTOMATIC, MANUAL } vs FILE TYPE IMAGE
   (should AUTOMATIC unset IMAGE?  Should IMAGE set MANUAL? ...)
 . Need better error message for failure to receive a file in text mode that
   has lines longer than 32K, or else a way to recover when this happens,
   e.g. by breaking the long line.

C-Kermit 6.1 also enables proper transfer of fixed-length-record files with
odd record lengths, and fixes problems with overstrike records in Fortran
Carriage Control files.  These fixes should go a long way towards eradicating
the complaints about files that Kermit-32 could transfer correctly, but
C-Kermit could not.

6.1. Automatic Transfer Mode

File transfer modes (TEXT vs BINARY) are set automatically for each file when
sending.  The SET FILE TYPE BINARY and SET FILE TYPE TEXT commands are ignored
when sending files.  So (in C-Kermit 6.1) are filename patterns (SET FILE
PATTERNS).  To force binary-mode transmission, use SET FILE TYPE IMAGE.  See
the VMS appendix of "Using C-Kermit".

One notable consequence of this fact is that if you send a file from VMS
C-Kermit in IMAGE mode (because it would not be transferred in binary mode
without this setting), then any attempt to RESEND or REGET it must also be
done with VMS C-Kermit in IMAGE mode.

The other aspect of automatic transfer mode is that VMS-to-VMS transfers shift
automatically into LABELED mode (again, see the manual).  One consequence of
this is that any "as-name" that you give for the file is ignored.  To defeat
this, use "set transfer mode manual".

DEC PATHWORKS file services normally create files in stream mode,  but
this can be overridden when the file service is created:

  $ ADMIN/PCSA
  PCSA> SET FILE_SERVER SERVICE service-name/ATTRIBUTES=SEQUENTIAL_FIXED

The normal stream files will be treated as TEXT by Kermit.  To transfer
PATHWORKS files that are really binary, such as executables, use IMAGE mode.

6.2. Oddball File Formats

When sending binary files that have an odd record length, please note that
these files are actually stored with an even record length on disk.  For
example, suppose DIR/FULL X.VDM says "fixed-length records, record length 17".
On disk, the file really has 18-byte records; each 17-byte record is padded
with a NUL (0) byte to make its length even; this is revealed by DUMP.
Prior to version 6.1, C-Kermit sent the raw records, INCLUDING THE PADDING.
In 6.1 and later, odd-length records are sent without padding.

If a text file is accidentally sent to VMS C-Kermit in binary mode, you can
fix it afterwards (in recent VMS versions) with a DCL command like:

 $ SET FILE/ATTRIBUTES=(RFM:STM,LRL:0,MRS:0) filename

Transfer of VFC (Variable with Fixed Control) files, such as those created
by DCL, is problematic, since the meaning of the control bytes is defined by
the application.

VMS MAIL messages: If you want to download mail messages to a PC (or other
non-VMS system), select the message of interest using the SELECT and DIRECTORY
commands within VMS MAIL, then EXTRACT/ALL to extract all the selected
messages to a normal text file, then use Kermit to SEND this file.  Don't even
think about trying to transfer your mail file as-is to a non-VMS system; it is
a complicated indexed file, possibly containing pointers to other files, etc.

ZIP files: If you have trouble transferring ZIP files into or out of VMS
using BINARY mode, use IMAGE mode instead (SET FILE TYPE IMAGE).  The same
applies to binary files created by VMS UNZIP.

6.3. Disk Quotas

Incoming files are rejected if the available space on the disk device is less
than the size of the file.  However, the user's disk quota is not checked.
Quota checking could erroneously report that a user couldn't store a file for
a number of reasons: for example, the user has the EXQUOTA privilege, C-Kermit
is installed with EXQUOTA privilege (not recommended!), overdraft, etc.
Because of the large potential for denying a transfer that would fit, the file
is accepted regardless of the disk quota.  This is consistent with the way
other VMS utilities work.

6.4. Control-Character (Un)Prefixing

Exercise caution when sending files to VMS when C-Kermit is in remote mode.
Aside from all the buffering limitations of LAT and VMS (see below), please
note the following:

 . On most VMS systems, the controlling terminal MUST have the /TTSYNC
   and /HOSTSYNC characteristics, even on Telnet connections, or else
   massive amounts of data can be lost.

 . There are evidently certain control characters that can not be safely
   unprefixed when sending to VMS, no matter how far C-Kermit goes to put
   the job's controlling terminal in "passthrough" mode.  These include:

      Ctrl-Q  XOFF  17
      Ctrl-S  XON   19
      Ctrl-C  ETX    3
      Ctrl-N  SO    14
      Ctrl-O  SI    15
      Ctrl-X  CAN   24
      Ctrl-Y  EM    25

As well as 141, 145, 147 (CR, XOFF, XON with their high bits set).  If you
find file transfers into VMS stalling, it is very likely because one or more
of the these characters is unprefixed.

On a related note, Carriage Return (13) and IAC (255) must be prefixed on
Telnet connections, and Kermit's start-of-packet character (normally SOH,
ASCII 1) should also be prefixed.  NUL (0) should be prefixed too.

6.5. External Protocols

You can use the ZMODEM SZ and RZ commands as "external protocols" over a
connection you have established with C-Kermit, to a host or service that
does not support Kermit protocol.  Start the file transfer on the remote
end, escape back to C-Kermit, give the SPAWN command, and then (for example):

  $ define tt xxx:
  $ rz

where xxx is the designation of the terminal device (TT or LTA) that you have
dialed out on.  When the transfer is complete, LOGOUT from the SPAWN'd
subprocess and you'll be back at the C-Kermit prompt.

6.6. Miscellaneous

The file size shown in the file transfer display when sending a file might
be incorrect under certain conditions (but the file is still transferred
correctly).

Incoming files, if accepted, are always stored as a new file with the next
highest version number, even when FILE COLLISION is set to OVERWRITE or
RENAME.

When you send a BYE command to a VMS C-Kermit server, it does not guarantee
that the VMS job will be logged out.  If C-Kermit was SPAWN'd from another
process, only C-Kermit itself disappears in this case.  Even if the whole VMS
session ends, if the user came in through a LAT terminal server, they will be
back at the "Local>" prompt and the phone line won't be disconnected.

When transferring files in LABELED mode, the file transfer display will show
the name the file was sent as, not the "true" name within the labeled file.
Also, note that a transfer may fail with an obscure error (can't create output
file) if there is something incorrect with the label information (for example,
if you specified that the file should be restored to the original directory
and you don't have privilege to write to that directory on this system).

Reportedly, when VMS C-Kermit is in local mode and transferring a file (file
transfer display is showing) over a MultiNet TCP/IP connection and a broadcast
from a completing batch job (SUBMIT/NOTIFY) arrives, it crashes C-Kermit with
%SYSTEM-F-ACCVIO, access violation.  The stack dump shows this occurs in the
netinc() routine while reading a packet (rpack).


7. OTHER TOPICS

7.1. Non-DEC Terminal Types

Non-DEC terminal types are not well supported under VMS.  While it might be
possible to install a definition for a non-DEC terminal (such as the IBM 3151)
in the SMG database, very few applications actually use this information.
Also, although C-Kermit 5x and 6.x used SMG, C-Kermit 7.0 bypasses it entirely
due to problems discovered during the development cycle.

(End of CKVBWR.TXT)