CKVKER.BWR "Beware File" for C-Kermit Version 6.0 -*- text -*- (Open)VMS VERSION FOR DEC VAX AND ALPHA Applies to C-Kermit 6.0.192 Last update: Thu Dec 5 15:43:07 1996 Authors: Frank da Cruz and Christine M. Gianone (Columbia University, NYC); Terry Kennedy (Saint Peters College, Jersey City, NJ). Copyright (C) 1985, 1996, Trustees of Columbia University in the City of New York. The C-Kermit software may not be, in whole or in part, licensed or sold for profit as a software product itself, nor may it be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. This copyright notice must not be removed, altered, or obscured. VMS C-Kermit installation instructions are in the file CKVINS.DOC. Please be sure you have read that file before concluding that C-Kermit isn't working right on VMS. Note: "VMS" as used in this document refers to both VMS and OpenVMS on both VAX and AXP (Alpha) processors. Most of the words in the previous sentence are trademarks (TM) of Digital Equipment Corporation. DOCUMENTATION C-Kermit is documented in the book "Using C-Kermit", Second Edition, 1997, by Frank da Cruz and Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1. Price: US $39.95. To order, call Columbia University, New York City, at +1 212 854-3703, or Digital Press / Butterworth-Heinemann: +1 800 366-2665 (Woburn, Massachusetts office for USA & Canada) +44 1865 314627 (Oxford, England distribution centre for UK & Europe) +61 03 9245 7111 (Melbourne, Vic, office for Australia & NZ) +65 356-1968 (Singapore office for Asia) +27 (31) 2683111 (Durban office for South Africa) A German edition is available from Verlag Heinz Heise in Hannover, Germany, Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 52-1 29. New features added since these books were published are documented in the ckcker.upd file. TECHNICAL SUPPORT Please consult the documentation listed above, plus the ckcker.bwr file and this file itself, before submitting questions, reporting problems, etc, to: E-Mail: kermit-support@columbia.edu News: comp.protocols.kermit.misc Post: The Kermit Project Columbia University 612 West 115th Street New York NY 10025 USA Fax: +1 212 663-8202 or: +1 212 662-6442 Telephone support also available: USA Only: +1 900 555-5595, cost: $2.50 per minute Anywhere: +1 212 854-5126, cost: $25.00 per call, payable via Visa or MC. 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: "?"-help, keyword and filename completion, filename menus, variables, macros, etc. As of edit 190, C-Kermit does support command recall (via Ctrl-B and Ctrl-N, not via arrow keys). 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.scr 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.SCR 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.scr or: $ kermit [mydir.mysubdir]oofa.scr 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 OPEN !READ process needs to be closed explicitly. If it is not, then subsequent SEND commands will erroneously try to read from the !READ process. (This should be fixed in 6.0) 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 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 or as a batch job via: $ SUBMIT OOFA 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. If you include a CONNECT command in this type of batch job, the CONNECT command will fail with the following message: Sorry, Kermit's CONNECT command can be used only on a real terminal. If this is not a batch a job, then you must: $ DEFINE SYS$INPUT SYS$COMMAND in your DCL command procedure before starting Kermit. 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 SYS$INPUT SYS$COMMAND (/USER, /NOLOG, etc, switches may be used). (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.scr instead of normal initialization file. $ kermit -y oofa.scr or: $ define /user sys$input sys$command $! Execute oofa.scr after executing normal initialization file. $ kermit "-C" "take oofa.scr" 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 prompt {} 5. echo Hello from C-Kermit 6. @ write sys$output "Hello from DCL from inside C-Kermit" 7. take oofa.scr 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 shows how to set C-Kermit's prompt to nothing to reduce clutter in the batch log, should you desire. 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.SCR. 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 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 (known to the writers of this document) 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. RUNNING C-KERMIT FROM ALL-IN-1 Dr. David Kelly, Australian Environmental Protection Authority 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 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. 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.DOC (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.DOC file, and the CKVKER.BWR 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." 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. FILE TRANSFER 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. To force binary-mode transmission, use SET FILE TYPE IMAGE. See the VMS appendix of "Using C-Kermit". 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. C-Kermit sends the raw records, INCLUDING THE PADDING. Thus, if you send such a file to (say) DOS or UNIX for actual use, your DOS or UNIX application must be coded to account for this -- if the record length is odd, add one to it. If you send the file back to VMS, just tell VMS C-Kermit to SET FILE RECORD to the original odd length, and the resulting file will be identical to the original one. 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. 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 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. 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. 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). 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. 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). 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.) SERIAL AND LAT COMMUNICATIONS Prior to version 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. 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. The SET CARRIER command is not supported in the VMS version of C-Kermit. Certain operations driven by RS-232 modem signals do not work on VAXstations or other DEC platforms whose serial interfaces use MMP connectors (DEC version of RJ45 telephone jack with with offset tab). These connectors convey only the DSR and DTR modem signals, but not carrier (CD), RTS, CTS, or RI. 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. This is a feature of VMS. 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). 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 typehead buffers, and that user accounts be given large BYTLM quotas. See CKVINS.DOC. 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. 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.DOC. 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: . 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 (U) does not work. Reason: unknown. Cure: unknown (The LAT programming interface is very poorly documented). Workaround: SET LINE 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 /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. FLOW CONTROL 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. 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. 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, which, 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 be ignored. 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 charactistic 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. 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). 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. If you enter the VAX from elsewhere through a TELNET connection, and the VAX is running CMU-OpenVMS/IP, Fusion, or 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.DOC 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) 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... 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. PERFORMANCE 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 partially because VMS C-Kermit's serial i/o routines need to be restructured along the same lines as the network ones (nonblocking buffered reads), but also 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. A similar problem is 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 "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." (End of CKVKER.BWR)