
                        C-Kermit 8.0 VMS Hints and Tips
                                       
   [ [1]Contents ] [ [2]C-Kermit ] [ [3]Kermit Home ]
   
      As of C-Kermit version: 8.0.209, 17 March 2003
      This file last updated: Sun Mar 9 18:51:13 2003 (New York City
   time)
   
     IF YOU ARE READING A PLAIN-TEXT version of this document, note that
     this file is a plain-text dump of a Web page. You can visit the
     original (and possibly more up-to-date) Web page here:
     
  [4]http://www.columbia.edu/kermit/ckvbwr.html

   Authors:
          F. da Cruz, C. Gianone, Columbia University, New York, NY.
          Terry Kennedy, Saint Peters College, Jersey City, NJ.
    ________________________________________________________________________
  
  CONTENTS
  
  1. [5]INTRODUCTION
  2. [6]THE C-KERMIT COMMAND PARSER
  3. [7]COMMUNICATIONS
  4. [8]GENERAL FAILURES
  5. [9]LOCAL FILE OPERATIONS
  6. [10]FILE TRANSFER
  7. [11]OTHER TOPICS
    ________________________________________________________________________
  
  1. INTRODUCTION [ [12]Top ] [ [13]Contents ] [ [14]Next ]
  
   SECTION CONTENTS:
   
  1.1. [15]Terminology
  1.2. [16]Documentation
  1.3. [17]Technical Support
  1.4. [18]Other Sources of Information

   This is what used to be called the "beware file" for VMS C-Kermit,
   formerly known as CKVBWR.TXT (and before that CKVKER.BWR). This
   edition is current as of C-Kermit 8.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 ([19]Section
   1.1). The General C-Kermit Hints and Tips document:
   
  [20]http://www.columbia.edu/kermit/ckcbwr.html

   formerly known as CKCBWR.TXT (and before that CKCKER.BWR), contains
   similar material that applies to all C-Kermit versions: Unix, VMS,
   VOS, etc.
   
   VMS C-Kermit installation instructions are in a separate document:
   
  [21]http://www.columbia.edu/kermit/ckvins.html

   (formerly known as CKVINS.TXT. Please be sure you have read that file
   before concluding that C-Kermit isn't working right on VMS.
   
   [ [22]C-Kermit ] [ [23]Kermit Home ]
    ________________________________________________________________________
  
  1.1. Terminology
  
   [ [24]Top ] [ [25]Contents ] [ [26]Section Contents ] [ [27]Next ]
   
   "VMS" as used in this document refers to both VMS and OpenVMS on VAX
   processors and OpenVMS on Alpha (formerly known as AXP) processors,
   and presumably any other architectures that VMS will be adapted to,
   such as IA64, PowerPC, or PA-RISC. Most of the words in the first part
   of the previous sentence are or were 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. Compaq, in turn, is on its way into the stomach of an
   even bigger fish, most likely Hewlett Packard.
   
   There might be contradictory bits of advice in this file, since much
   of the information was culled from different sources at different
   times. Comments, reports, suggestions, contributions are always
   welcome.
   
   [ [28]C-Kermit ] [ [29]Kermit Home ]
    ________________________________________________________________________
  
  1.2. Documentation
  
   [ [30]Top ] [ [31]Contents ] [ [32]Section Contents ] [ [33]Next ] [
   [34]Previous ]
   
    1. Frank da Cruz and Christine M. Gianone, [35]Using C-Kermit, Second
       Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1997,
       622 pages, ISBN 1-55558-164-1. This is a printed book. It covers
       C-Kermit 6.0.
    2. The C-Kermit 7.0 Supplement:
       [36]http://www.columbia.edu/kermit/ckermit70.html
    3. The C-Kermit 8.0 Supplement:
       [37]http://www.columbia.edu/kermit/ckermit80.html
       
   The C-Kermit home page is here:
   
  [38]http://www.columbia.edu/kermit/ckermit.html

   [ [39]C-Kermit ] [ [40]Kermit Home ]
    ________________________________________________________________________
  
  1.3. Technical Support
  
   [ [41]Top ] [ [42]Contents ] [ [43]Section Contents ] [ [44]Next ] [
   [45]Previous ]
   
     Email: [46]kermit-support@columbia.edu
     News: [47]comp.protocols.kermit.announce
     [48]comp.protocols.kermit.misc
     <-- Announcements, moderated
     <-- Discussion, unmoderated
     Web: [49]http://www.columbia.edu/kermit/
     [50]http://www.kermit-project.org/
     [51]http://www.columbia.edu/kermit/faq.html <-- Kermit Project Home
     Page
     <-- Alternative Web address
     <-- Frequently Asked Questions
     Post: The Kermit Project
     Columbia University
     612 West 115th Street
     New York NY 10025-7799
     USA
     Fax: +1 (212) 662-6442
     
   [ [52]C-Kermit ] [ [53]Kermit Home ]
    ________________________________________________________________________
  
  1.4. Other Sources of Information
  
   [ [54]Top ] [ [55]Contents ] [ [56]Section Contents ] [ [57]Previous ]
   
   The OpenVMS Frequently Asked Questions (FAQ) document is available at
   various sites on the Internet, including (checked Feb 2003):
   
  [58]http://www.openvms.compaq.com/wizard/openvms_faq.html
  [59]ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms

   The following newsgroup is dedicated to discussion of VMS-related
   topics:
   
  [60]comp.os.vms

   And this one to more general DEC-related topics:
   
  [61]comp.sys.dec

   [ [62]C-Kermit ] [ [63]Kermit Home ]
    ________________________________________________________________________
  
  2. THE C-KERMIT COMMAND PARSER
  
   [ [64]Top ] [ [65]Contents ] [ [66]Next ] [ [67]Previous ]
   
   SECTION CONTENTS:
   
  2.1. [68]Running C-Kermit in DCL Command Procedures
  2.2. [69]Running C-Kermit from ALL-IN-1
  2.3. [70]Running C-Kermit under DECIntact

   When you start C-Kermit at your terminal, everything should work as
   expected. You get the prompt, you can type commands, your keystrokes
   echo (once, not zero or two times), ? gives help, Ctrl-C interrupts a
   command in execution and returns to the prompt. However, VMS offers a
   wide variety of "other" environments (Batch, Spawn'd, DCL command
   procedures, pipes, mailboxes, ...) in which programs can execute, and
   Kermit tries to recognize and adapt itself to them automatically, but
   this might not always work. Therefore, two command-line options are
   provided so you can force the required adaptations:
   
   -z
          Force foreground. If Kermit thinks it's in the background, i.e.
          that it does not have a connection to a command terminal (your
          keyboard), it is likely to (a) not issue a prompt; (b) not echo
          your keystrokes; (c) not respond to "?", Esc, etc. Use the -z
          option to force it to treat SYS$INPUT as a real terminal, even
          if it doesn't seem to be one.
          
   "-B"
          Force Background (the doublequotes are necessary to prevent DCL
          from lowercasing the B). This is for the opposite situation: If
          Kermit thinks SYS$INPUT is a real terminal, but it's not, then
          Kermit command procedures might fail immediately with "?Can't
          initialize" or somesuch. Use the "-B" option to tell Kermit it
          doesn't really have a terminal.
          
   VMS-style command-line editing (arrow keys, etc) is not supported (you
   can, however, use up and down arrow keys for command recall in
   C-Kermit 8.0.201 and later). 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 (or Ctrl-P, same
   thing) 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

   [ [71]C-Kermit ] [ [72]Kermit Home ]
    ________________________________________________________________________
  
  2.1. Running C-Kermit in DCL Command Procedures
  
   [ [73]Top ] [ [74]Contents ] [ [75]Section Contents ] [ [76]Next ]
   
   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 IF, 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 brief 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.
   
   [ [77]C-Kermit ] [ [78]Kermit Home ]
    ________________________________________________________________________
  
  2.2. Running C-Kermit from ALL-IN-1
  
   [ [79]Top ] [ [80]Contents ] [ [81]Section Contents ] [ [82]Next ] [
   [83]Previous ]
   
   Contibuted by: Dr. David Kelly, Australian Environmental Protection
   Authority, [84]kellyd@airmoon.epa.nsw.gov.au
   
   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

   [ [85]C-Kermit ] [ [86]Kermit Home ]
    ________________________________________________________________________
  
  2.3. Running C-Kermit under DECintact
  
   [ [87]Top ] [ [88]Contents ] [ [89]Section Contents ] [ [90]Previous ]
   
   To use C-Kermit in remote mode under DECIntact, you must:
   
    a. Have C-Kermit 7.0 or later, and:
    b. Tell it to "set line /share tt:".
       
   This might also work with ALL-IN-1 ([91]Section 2.2).
   
   [ [92]C-Kermit ] [ [93]Kermit Home ]
    ________________________________________________________________________
  
  3. COMMUNICATIONS
  
   [ [94]Top ] [ [95]Contents ] [ [96]Next ] [ [97]Previous ]
   
   SECTION CONTENTS:
   
  3.1. [98]Serial and LAT Communications
  3.2. [99]Network Communications

   Also see:
   
     * [100]Section 6 of the [101]Installation Instructions: Using Modems
       by Richard B. Gilbert.
     * [102]http://www.tmesis.com/modem/.
       
  3.1. Serial and LAT Communications
  
   [ [103]Top ] [ [104]Contents ] [ [105]Section Contents ] [ [106]Next ]
   
   SUBSECTION CONTENTS:
   
  3.1.1. [107]Dialing
  3.1.2. [108]Speed
  3.1.3. [109]Echoing
  3.1.4. [110]Modem Signals
  3.1.5. [111]Buffering and Flow Control
  3.1.6. [112]LAT

   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
    
   SUBSECTION CONTENTS:
   
  3.1.4.1. [113]The SET CARRIER-WATCH Command
  3.1.4.2. [114]The SHOW COMMUNICATIONS Command
  3.1.4.3. [115]The WAIT Command
  3.1.4.4. [116]The HANGUP Command

   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
    
   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 7.0, 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 7.0, 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
    
   Hardware flow control (RTS/CTS) is not supported by VMS, despite
   rumors to the contrary. From "[117]Ask the Wizard #0153" (July 1998):
   
     Setting the port to hardware flow control at the console will not
     have any meaning to VMS. It does not see or make use of that
     information. Also VMS does not officially support hardware flow
     control for serial lines. For output when using modem lines the
     system will honor CTS. But we will not lower RTS when the type-
     ahead buffer is almost full. In V7.1 there is an attribute to
     enable RTS for input flow control on modem lines. But this support
     is not documented and there is no way from DCL to enable it.
     
   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 the [118]Installation Instructions.
   
     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 [119]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
   the [120]Installation Instructions.
   
   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.)
   
   [ [121]C-Kermit ] [ [122]Kermit Home ]
    ________________________________________________________________________
  
  3.2. Network Communications
  
   [ [123]Top ] [ [124]Contents ] [ [125]Section Contents ] [
   [126]Previous ]
   
   SECTION CONTENTS:
   
  3.2.1. [127]X.25
  3.2.2. [128]TCP/IP

   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 7.0 and later 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 8.0.209, 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 the [129]Installation Instructions
   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.
   
   [ [130]C-Kermit ] [ [131]Kermit Home ]
    ________________________________________________________________________
  
  4. GENERAL FAILURES
  
   [ [132]Top ] [ [133]Contents ] [ [134]Next ] [ [135]Previous ]
   
   General failures can sometimes occur for 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 the
   [136]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."
   
   [ [137]C-Kermit ] [ [138]Kermit Home ]
    ________________________________________________________________________
  
  5. LOCAL FILE OPERATIONS
  
   [ [139]Top ] [ [140]Contents ] [ [141]Next ] [ [142]Previous ]
   
   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.
       
   C-Kermit 7.0 (Jan-Feb 2000) added a new stdio-based FILE command
   allowing opening, closing, reading, writing of local files. Since
   C-Kermit is a C program, this works best with stream files. In
   particular FOPEN /APPEND works only with stream (Stream_LF) files. If
   you try to use FOPEN /APPEND on a non-Stream_LF file, the appended
   portion is in Stream_LF format but the original portion remains in
   whatever format it was in before.
   
   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.
   
   [ [143]C-Kermit ] [ [144]Kermit Home ]
    ________________________________________________________________________
  
  6. FILE TRANSFER
  
   [ [145]Top ] [ [146]Contents ] [ [147]Next ] [ [148]Previous ]
   
   SECTION CONTENTS:
   
  6.1. [149]Automatic Transfer Mode
  6.2. [150]Oddball File Formats
  6.3. [151]Disk Quotas
  6.4. [152]Control-Character (Un)Prefixing
  6.5. [153]External Protocols
  6.6. [154]Miscellaneous

   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 7.0 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 in C-Kermit
       7.0).
     * 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 7.0 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.
   
   [ [155]C-Kermit ] [ [156]Kermit Home ]
    ________________________________________________________________________
  
  6.1. Automatic Transfer Mode
  
   [ [157]Top ] [ [158]Contents ] [ [159]Section Contents ] [ [160]Next ]
   
   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 7.0) are
   filename patterns (SET FILE PATTERNS). To force binary-mode
   transmission, use SET FILE TYPE IMAGE. See the VMS appendix of
   [161]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
   [162]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.
   
   [ [163]C-Kermit ] [ [164]Kermit Home ]
    ________________________________________________________________________
  
  6.2. Oddball File Formats
  
   [ [165]Top ] [ [166]Contents ] [ [167]Section Contents ] [ [168]Next ]
   [ [169]Previous ]
   
   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 7.0, C-Kermit sent the raw
   records, INCLUDING THE PADDING. In 7.0 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.
   
   [ [170]C-Kermit ] [ [171]Kermit Home ]
    ________________________________________________________________________
  
  6.3. Disk Quotas
  
   [ [172]Top ] [ [173]Contents ] [ [174]Section Contents ] [ [175]Next ]
   [ [176]Previous ]
   
   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.
   
   [ [177]C-Kermit ] [ [178]Kermit Home ]
    ________________________________________________________________________
  
  6.4. Control-Character (Un)Prefixing
  
   [ [179]Top ] [ [180]Contents ] [ [181]Section Contents ] [ [182]Next ]
   [ [183]Previous ]
   
   Exercise caution when sending files to VMS when C-Kermit is in remote
   mode. Aside from all the buffering limitations of LAT and VMS, 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.
   
   [ [184]C-Kermit ] [ [185]Kermit Home ]
    ________________________________________________________________________
  
  6.5. External Protocols
  
   [ [186]Top ] [ [187]Contents ] [ [188]Section Contents ] [ [189]Next ]
   [ [190]Previous ]
   
   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.
   
   [ [191]C-Kermit ] [ [192]Kermit Home ]
    ________________________________________________________________________
  
  6.6. Miscellaneous
  
   [ [193]Top ] [ [194]Contents ] [ [195]Section Contents ] [
   [196]Previous ]
   
   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
   shows 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).
   
   [ [197]C-Kermit ] [ [198]Kermit Home ]
    ________________________________________________________________________
  
  7. OTHER TOPICS
  
   [ [199]Top ] [ [200]Contents ] [ [201]Previous ]
   
   (So far just one...)
   
  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 and later bypass it entirely due to problems discovered
   during the development cycle.
   
   [ [202]Top ] [ [203]Contents ] [ [204]C-Kermit Home ] [ [205]Kermit
   Home ]
     _________________________________________________________________
   
   
    C-Kermit 8.0 VMS Hints and Tips / The Kermit Project / Columbia
    University / 17 March 2003

References

   1. http://www.columbia.edu/kermit/ckvbwr.html#contents
   2. http://www.columbia.edu/kermit/ckermit.html
   3. http://www.columbia.edu/kermit/index.html
   4. http://www.columbia.edu/kermit/ckvbwr.html
   5. http://www.columbia.edu/kermit/ckvbwr.html#x1
   6. http://www.columbia.edu/kermit/ckvbwr.html#x2
   7. http://www.columbia.edu/kermit/ckvbwr.html#x3
   8. http://www.columbia.edu/kermit/ckvbwr.html#x4
   9. http://www.columbia.edu/kermit/ckvbwr.html#x5
  10. http://www.columbia.edu/kermit/ckvbwr.html#x6
  11. http://www.columbia.edu/kermit/ckvbwr.html#x7
  12. http://www.columbia.edu/kermit/ckvbwr.html#top
  13. http://www.columbia.edu/kermit/ckvbwr.html#contents
  14. http://www.columbia.edu/kermit/ckvbwr.html#x2
  15. http://www.columbia.edu/kermit/ckvbwr.html#x1.1
  16. http://www.columbia.edu/kermit/ckvbwr.html#x1.2
  17. http://www.columbia.edu/kermit/ckvbwr.html#x1.3
  18. http://www.columbia.edu/kermit/ckvbwr.html#x1.4
  19. http://www.columbia.edu/kermit/ckvbwr.html#x1.1
  20. http://www.columbia.edu/kermit/ckcbwr.html
  21. http://www.columbia.edu/kermit/ckvins.html
  22. http://www.columbia.edu/kermit/ckermit.html
  23. http://www.columbia.edu/kermit/index.html
  24. http://www.columbia.edu/kermit/ckvbwr.html#top
  25. http://www.columbia.edu/kermit/ckvbwr.html#contents
  26. http://www.columbia.edu/kermit/ckvbwr.html#x1
  27. http://www.columbia.edu/kermit/ckvbwr.html#x1.2
  28. http://www.columbia.edu/kermit/ckermit.html
  29. http://www.columbia.edu/kermit/index.html
  30. http://www.columbia.edu/kermit/ckvbwr.html#top
  31. http://www.columbia.edu/kermit/ckvbwr.html#contents
  32. http://www.columbia.edu/kermit/ckvbwr.html#x1
  33. http://www.columbia.edu/kermit/ckvbwr.html#x1.3
  34. http://www.columbia.edu/kermit/ckvbwr.html#x1.1
  35. http://www.columbia.edu/kermit/ckmanual.html
  36. http://www.columbia.edu/kermit/ckermit70.html
  37. http://www.columbia.edu/kermit/ckermit80.html
  38. http://www.columbia.edu/kermit/ckermit.html
  39. http://www.columbia.edu/kermit/ckermit.html
  40. http://www.columbia.edu/kermit/index.html
  41. http://www.columbia.edu/kermit/ckvbwr.html#top
  42. http://www.columbia.edu/kermit/ckvbwr.html#contents
  43. http://www.columbia.edu/kermit/ckvbwr.html#x1
  44. http://www.columbia.edu/kermit/ckvbwr.html#x1.4
  45. http://www.columbia.edu/kermit/ckvbwr.html#x1.2
  46. mailto:kermit-support@columbia.edu
  47. news:comp.protocols.kermit.announce
  48. news:comp.protocols.kermit.misc
  49. http://www.columbia.edu/kermit/
  50. http://www.kermit-project.org/
  51. http://www.columbia.edu/kermit/faq.html
  52. http://www.columbia.edu/kermit/ckermit.html
  53. http://www.columbia.edu/kermit/index.html
  54. http://www.columbia.edu/kermit/ckvbwr.html#top
  55. http://www.columbia.edu/kermit/ckvbwr.html#contents
  56. http://www.columbia.edu/kermit/ckvbwr.html#x1
  57. http://www.columbia.edu/kermit/ckvbwr.html#x1.3
  58. http://www.openvms.compaq.com/wizard/openvms_faq.html
  59. ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms
  60. news:comp.os.vms
  61. news:comp.sys.dec
  62. http://www.columbia.edu/kermit/ckermit.html
  63. http://www.columbia.edu/kermit/index.html
  64. http://www.columbia.edu/kermit/ckvbwr.html#top
  65. http://www.columbia.edu/kermit/ckvbwr.html#contents
  66. http://www.columbia.edu/kermit/ckvbwr.html#x3
  67. http://www.columbia.edu/kermit/ckvbwr.html#x1
  68. http://www.columbia.edu/kermit/ckvbwr.html#x2.1
  69. http://www.columbia.edu/kermit/ckvbwr.html#x2.2
  70. http://www.columbia.edu/kermit/ckvbwr.html#x2.3
  71. http://www.columbia.edu/kermit/ckermit.html
  72. http://www.columbia.edu/kermit/index.html
  73. http://www.columbia.edu/kermit/ckvbwr.html#top
  74. http://www.columbia.edu/kermit/ckvbwr.html#contents
  75. http://www.columbia.edu/kermit/ckvbwr.html#x2
  76. http://www.columbia.edu/kermit/ckvbwr.html#x2.2
  77. http://www.columbia.edu/kermit/ckermit.html
  78. http://www.columbia.edu/kermit/index.html
  79. http://www.columbia.edu/kermit/ckvbwr.html#top
  80. http://www.columbia.edu/kermit/ckvbwr.html#contents
  81. http://www.columbia.edu/kermit/ckvbwr.html#x2
  82. http://www.columbia.edu/kermit/ckvbwr.html#x2.3
  83. http://www.columbia.edu/kermit/ckvbwr.html#x2.1
  84. mailto:kellyd@airmoon.epa.nsw.gov.au
  85. http://www.columbia.edu/kermit/ckermit.html
  86. http://www.columbia.edu/kermit/index.html
  87. http://www.columbia.edu/kermit/ckvbwr.html#top
  88. http://www.columbia.edu/kermit/ckvbwr.html#contents
  89. http://www.columbia.edu/kermit/ckvbwr.html#x2
  90. http://www.columbia.edu/kermit/ckvbwr.html#x2.2
  91. http://www.columbia.edu/kermit/ckvbwr.html#x2.2
  92. http://www.columbia.edu/kermit/ckermit.html
  93. http://www.columbia.edu/kermit/index.html
  94. http://www.columbia.edu/kermit/ckvbwr.html#top
  95. http://www.columbia.edu/kermit/ckvbwr.html#contents
  96. http://www.columbia.edu/kermit/ckvbwr.html#x4
  97. http://www.columbia.edu/kermit/ckvbwr.html#x2
  98. http://www.columbia.edu/kermit/ckvbwr.html#x3.1
  99. http://www.columbia.edu/kermit/ckvbwr.html#x3.2
 100. http://www.columbia.edu/kermit/ckvins.html#x6
 101. http://www.columbia.edu/kermit/ckvins.html
 102. http://www.tmesis.com/modem/
 103. http://www.columbia.edu/kermit/ckvbwr.html#top
 104. http://www.columbia.edu/kermit/ckvbwr.html#contents
 105. http://www.columbia.edu/kermit/ckvbwr.html#x3
 106. http://www.columbia.edu/kermit/ckvbwr.html#x3.2
 107. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.1
 108. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.2
 109. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.3
 110. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.4
 111. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.5
 112. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.6
 113. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.4.1
 114. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.4.2
 115. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.4.3
 116. http://www.columbia.edu/kermit/ckvbwr.html#x3.1.4.4
 117. http://www.openvms.compaq.com/wizard
 118. http://www.columbia.edu/kermit/ckvins.html
 119. http://www.columbia.edu/kermit/ckvbwr.html#x6
 120. http://www.columbia.edu/kermit/ckvins.html
 121. http://www.columbia.edu/kermit/ckermit.html
 122. http://www.columbia.edu/kermit/index.html
 123. http://www.columbia.edu/kermit/ckvbwr.html#top
 124. http://www.columbia.edu/kermit/ckvbwr.html#contents
 125. http://www.columbia.edu/kermit/ckvbwr.html#x3
 126. http://www.columbia.edu/kermit/ckvbwr.html#x3.1
 127. http://www.columbia.edu/kermit/ckvbwr.html#x3.2.1
 128. http://www.columbia.edu/kermit/ckvbwr.html#x3.2.2
 129. http://www.columbia.edu/kermit/ckvins.html
 130. http://www.columbia.edu/kermit/ckermit.html
 131. http://www.columbia.edu/kermit/index.html
 132. http://www.columbia.edu/kermit/ckvbwr.html#top
 133. http://www.columbia.edu/kermit/ckvbwr.html#contents
 134. http://www.columbia.edu/kermit/ckvbwr.html#x5
 135. http://www.columbia.edu/kermit/ckvbwr.html#x3
 136. http://www.columbia.edu/kermit/ckvins.html
 137. http://www.columbia.edu/kermit/ckermit.html
 138. http://www.columbia.edu/kermit/index.html
 139. http://www.columbia.edu/kermit/ckvbwr.html#top
 140. http://www.columbia.edu/kermit/ckvbwr.html#contents
 141. http://www.columbia.edu/kermit/ckvbwr.html#x6
 142. http://www.columbia.edu/kermit/ckvbwr.html#x4
 143. http://www.columbia.edu/kermit/ckermit.html
 144. http://www.columbia.edu/kermit/index.html
 145. http://www.columbia.edu/kermit/ckvbwr.html#top
 146. http://www.columbia.edu/kermit/ckvbwr.html#contents
 147. http://www.columbia.edu/kermit/ckvbwr.html#x7
 148. http://www.columbia.edu/kermit/ckvbwr.html#x5
 149. http://www.columbia.edu/kermit/ckvbwr.html#x6.1
 150. http://www.columbia.edu/kermit/ckvbwr.html#x6.2
 151. http://www.columbia.edu/kermit/ckvbwr.html#x6.3
 152. http://www.columbia.edu/kermit/ckvbwr.html#x6.4
 153. http://www.columbia.edu/kermit/ckvbwr.html#x6.5
 154. http://www.columbia.edu/kermit/ckvbwr.html#x6.6
 155. http://www.columbia.edu/kermit/ckermit.html
 156. http://www.columbia.edu/kermit/index.html
 157. http://www.columbia.edu/kermit/ckvbwr.html#top
 158. http://www.columbia.edu/kermit/ckvbwr.html#contents
 159. http://www.columbia.edu/kermit/ckvbwr.html#x6
 160. http://www.columbia.edu/kermit/ckvbwr.html#x6.2
 161. http://www.columbia.edu/kermit/ckmanual.html
 162. http://www.columbia.edu/kermit/ckmanual.html
 163. http://www.columbia.edu/kermit/ckermit.html
 164. http://www.columbia.edu/kermit/index.html
 165. http://www.columbia.edu/kermit/ckvbwr.html#top
 166. http://www.columbia.edu/kermit/ckvbwr.html#contents
 167. http://www.columbia.edu/kermit/ckvbwr.html#x6
 168. http://www.columbia.edu/kermit/ckvbwr.html#x6.3
 169. http://www.columbia.edu/kermit/ckvbwr.html#x6.1
 170. http://www.columbia.edu/kermit/ckermit.html
 171. http://www.columbia.edu/kermit/index.html
 172. http://www.columbia.edu/kermit/ckvbwr.html#top
 173. http://www.columbia.edu/kermit/ckvbwr.html#contents
 174. http://www.columbia.edu/kermit/ckvbwr.html#x6
 175. http://www.columbia.edu/kermit/ckvbwr.html#x6.4
 176. http://www.columbia.edu/kermit/ckvbwr.html#x6.2
 177. http://www.columbia.edu/kermit/ckermit.html
 178. http://www.columbia.edu/kermit/index.html
 179. http://www.columbia.edu/kermit/ckvbwr.html#top
 180. http://www.columbia.edu/kermit/ckvbwr.html#contents
 181. http://www.columbia.edu/kermit/ckvbwr.html#x6
 182. http://www.columbia.edu/kermit/ckvbwr.html#x6.5
 183. http://www.columbia.edu/kermit/ckvbwr.html#x6.3
 184. http://www.columbia.edu/kermit/ckermit.html
 185. http://www.columbia.edu/kermit/index.html
 186. http://www.columbia.edu/kermit/ckvbwr.html#top
 187. http://www.columbia.edu/kermit/ckvbwr.html#contents
 188. http://www.columbia.edu/kermit/ckvbwr.html#x6
 189. http://www.columbia.edu/kermit/ckvbwr.html#x6.6
 190. http://www.columbia.edu/kermit/ckvbwr.html#x6.4
 191. http://www.columbia.edu/kermit/ckermit.html
 192. http://www.columbia.edu/kermit/index.html
 193. http://www.columbia.edu/kermit/ckvbwr.html#top
 194. http://www.columbia.edu/kermit/ckvbwr.html#contents
 195. http://www.columbia.edu/kermit/ckvbwr.html#x6
 196. http://www.columbia.edu/kermit/ckvbwr.html#x6.5
 197. http://www.columbia.edu/kermit/ckermit.html
 198. http://www.columbia.edu/kermit/index.html
 199. http://www.columbia.edu/kermit/ckvbwr.html#top
 200. http://www.columbia.edu/kermit/ckvbwr.html#contents
 201. http://www.columbia.edu/kermit/ckvbwr.html#x2
 202. http://www.columbia.edu/kermit/ckvbwr.html#top
 203. http://www.columbia.edu/kermit/ckvbwr.html#contents
 204. http://www.columbia.edu/kermit/ckermit.html
 205. http://www.columbia.edu/kermit/index.html
