VMS Kermit Beware File ---------------------- VMS Kermit 3.3.111 and later only work with VMS Version 4.0 and above. VMS Kermit 3.1 or earlier may be used with VMS Version 3. A hex copy of version 3.1 is in VMSV31.HEX. The VMSMIT.HEX file was produced using VMSHEX on an .EXE file that was built from the .OBJ files linked together on a VMS 4.3 system. It was found that an .EXE file linked on a VMS 4.5 system would not run under VMS 4.3, but that a version linked under 4.3 would run under 4.4 and 4.5 of VMS. Use VMSDEH to convert the VMSMIT.HEX file back into an executable .EXE file. (VMS programs check the version numbers of the run time libraries. They will allow programs to migrate to newer versions of the library, but not the other way around. There is a dispatch table in the library, which can change between releases of VMS. The version checks are done against the VMS library, instead of the dispatch table version number which doesn't exist.) Known problems with VMS Kermit 3.3.111: o Commands are upcased so that LIB$TPARSE will scan the command correctly. This causes problems when attempting to set the prompt and sending server commands to a UNIX based Kermit. o Kermit-32 will quote multiple characters with "~" in a file name even if the REPEAT_QUOTE character is set to space. o When receiving a file of type FIXED, if the final record is not exactly 512 bytes, then an error occurs and the receiving Kermit blows up. o Kermit-32 can hang on a virtual terminal due to XON-XOFF processing between the VAX and a remote system. o Incoming filenames are truncated to 9.3 (pre-VMS version 4) format, rather than being allowed to fit in the new 39.39 format. Miscellaneous messages, suggestions, and hints follow... ------------------------------ [This problem may or may not be fixed in the current version of KERMIT. It is not possible to reproduce this error at Stevens, so if someone runs into it please post a message about it.] Date: Friday, 6 Dec 85 07:37:12 PST From: vax135!cornell!uw-beaver!tektronix!teklds!scottt@ucbvax.berkeley.edu Subject: Error notice for VMS Kermit. I am letting a friend ask via this account that works for the City of Portland Oregon in the transportation engineering bureau... Mark L. Millard 8415 SE Stephens St. Portland, Or 97216 Home: (503)253-4545 Work: (503)796-7234 I have run into a problem with VMS kermit V3.1.066 and C3.0.051. I do not know if this is how you want bug reports. Just leave me mail if it is not. Reply to tektronix!teklds!scottt and I will get the reply. It goes like this for machines V (VMS) and M (masscomp): (0) V context: VAX port has alternate typehead so that 9600 baud does not have problems over running the usual 8 character over run area. The buffer is 200 with alarm (^S) point at 64. The port is used to log in on M from V and use it directly. It is also used to transfer data to and from V. At 9600, the effective rate is about 2400 and it takes hours to transfer one EMME2 (transportation flow model) database. I do not want to use a slower line. The problem only occurs using kermit on the VAX as a virtual terminal. No problems have occured with kermit running on both machines (file transfers). (1) M eventually sends sufficient text to fill V's typehead buffer past the alarm (^S) point so V sends ^S. (2) Kermit on V does not empty the typeahead buffer, instead it leaves some character(s) in the buffer and waits for some condition to start its read. Now M is waiting for V while V is waiting for M because... (3) VMS does not send ^Q to allow M to continue until the typeahead buffer is empty and... (4) Kermit waits at LEF for something to come from M but nothing comes because M is waiting for a ^Q before continuing. (5) A way to force this to occur is to turn on Read_Sync on the port before starting Kermit (Kermit leaves this characteristic alone). Then Kermit gets stuck immeadiately. (6) I have to stop/id the process that got stuck in Kermit. When I rerun Kermit and connect, the output starts where it left off when Kermit hung. In other words, M was waiting to output and running Kermit on V caused V to send M the required ^Q. (7) Kermit on V does not respond to typing on V's side when it is stuck waiting for M. This makes me expect that the wait is specificly for an event from M's side. M_M ------------------------------ Date: Thu 10 Jul 86 09:19:47-EDT From: Frank da Cruz Subject: Using VMS Backup with Kermit Apparently, VMS Backup cannot create a saveset on disk with a blocksize of 512, which is the blocksize used by VMS Kermit when you give the "set file type fixed" command. To remedy this situation, Gary Stebbins of DEC wrote a little procedure for converting VMS Backup savesets to and from blocksize 512, to allow these files to be transferred with Kermit. Use of Backup in this way permits convenient transfer of a group of unlike or complex files in a single Kermit operation, such that all their FILES-11 and RMS attributes are preserved after transfer. Thanks to Bernie Eiben for sending it in. The files are in KER:VMSBAK.DOC and KER:VMSBAK.BAS. ------------------------------ Date: Mon 22 Sep 86 09:26:38-EDT From: Frank da Cruz Subject: VMS Kermit installation To: rmcqueen@SITVXB The following message from Bernie, about installing Kermit... What do you think? Also, this raises the larger question about block sizes in VMS Kermit. That's one of the most common complaints about it -- you can only have one block size -- 512 -- which seems to be a big stumbling block for some people. Also, about the continuting discussion of using Kermit to transfer "wierd" VMS files (RMS, etc) -- maybe it would make sense to build a special SET FILE TYPE FILES-11 command into the next release of VMS Kermit, which would simply transmit the file's FAB (or whatever it's called) along with the file itself, so that the FILES-11 system on the receiving end could reconstitute it correctly. Although it would be nice to do this with attribute packets (as Kermit-11 does), the SET command would be a lot simpler, and would get an awful lot of mileage. What do you think, is there any hope? - Frank --------------- Date: 19 Sep 1986 2137-EDT From: "Bernie AT&T:617-467-5664 LDP Workstations" To: fdc@cu20b Subject: VMS-KERMIT I've "solved" the problem internally by making a 'KIT' available. All VMS software comes in 'KITs' , which are 'installed' via VMSINSTAL. A 'KIT' is basically a BACKUP-set with a slightly special 'Command-file' doing the 'dirty work' behind the scenes.. I suspected and was proven 'right' - that 'VMS-SYSTEM managers' are VERY suspicious to anything not coming as a KIT . They 'reject' these things typically as 'WE DON'T WANT TO USE ANYTHING WHICH IS NOT SUPPORTED'. However a 'KIT' typically 'slips by' - and also only needs ONE ANSWER to a simple question... ... KIT to install ? KERMIT I could make the 'KIT' available - and it would have to be used in conjunction with VMSBAK.BAS [as it goes BACKUP's minimal blocking is 1024 and KERMITS 'unary' blocking is 512 - aside from that , the higher the 'blocking' the less the [considerable] overhead of BACKUP. Let me know ... Rgds, Bernie. -------- Date: 22 Sep 1986 1512-EDT From: "Bernie AT&T:617-467-5664 LDP Workstations" To: Frank da Cruz Subject: Re: VMS-KERMIT Ok, here comes the 'magic' [not really - just bloody stuff] ... KIT's are in essence BACKUP save-sets with a 'command-file' which is executed in a sub-process. First a 'listing' of the contents of the save-set.. Listing of save set(s) Save set: KERMIT032.A Written by: EIBEN UIC: [000201,000201] Date: 8-AUG-1986 09:48:35.27 Command: BACKUP *.* KERMIT032.A/SAV/BLOCK=2048 Operating system: VAX/VMS version V4.4 BACKUP version: V4.4 CPU ID register: 08000000 Node name: _MKTUP1:: Written on: _DUA1: Block size: 2048 Group size: 10 Buffer count: 3 [EIBEN.IBM]KERMIT.CLD;2 1 27-APR-1985 10:07 [EIBEN.IBM]KERMIT.EXE;1 91 23-MAY-1986 08:40 [EIBEN.IBM]KERMIT.HLB;3 141 17-APR-1986 22:21 [EIBEN.IBM]KERMIT_SYS.HLP;4 141 17-APR-1986 22:16 [EIBEN.IBM]KITINSTAL.COM;3 1 30-JUL-1985 13:23 Total of 5 files, 375 blocks End of save set .. the first four files are 'more-or-less' the files, as one finds them in the distribution [first one is ued to insert KERMIT as a command] . .. and now the 'directions' for VMSINSTAL - as written in KITINSTAL.COM $ On Control_Y Then Vmi$Callback CONTROL_Y $ On Warning Then Exit $Status $ If P1 .eqs. "VMI$_INSTALL" then goto Install $ Exit Vmi$_unsupported $ $ Install: $ Vmi$Callback SET PURGE yes $ Vmi$Callback SET IVP no $ $ Vmi$Callback PROVIDE_IMAGE Exe$ KERMIT.EXE Vmi$Root:[SysExe] $ Vmi$Callback PROVIDE_FILE Hlb$ KERMIT.HLB Vmi$Root:[SysHlp] $ Vmi$Callback PROVIDE_DCL_HELP KERMIT_SYS.HLP $ Vmi$Callback PROVIDE_DCL_COMMAND KERMIT.CLD $ $ Exit Vmi$_success BTW - this 'KIT-file' could be 'munged' thru the BASIC-thingy to have 512-byte blocking - so that KERMIT can handle it - and then put into KB: - , with the direction to use the BASIC-thingy again to 'up' the blocking to 2048... and then use '@SYS$MANAGER:VMSINSTAL' to install it... Rgds, Bernie.. -------- ------------------------------ Date: Tue 11 Nov 86 10:58:37-EST From: Frank da Cruz Subject: VMS Kermit To: rmcqueen@SITVXB I got a call from Bernie Eiben at DEC today. He found that VMS Kermit does not mesh well with the new VAXmate services. The problem is that when you use VAXmate services to create files on VMS, and then use Kermit later to transfer them to your PC at home, the file are junk. The reason is that VAXmate services use something called "streamline" files(?). Bernie found that if you SET FILE TYPE BLOCK (in Stevens Kermit), then you can use the files OK. But since most users don't know to do this, he suggests that VMS Kermit be fixed to notice when it's sending a "streamline" file, and then do what SET FILE TYPE BLOCK would have done, i.e. bypass RMS translation, and just send the data. I'm not quite sure what to do when sending the files back to VMS -- I assume that the user would still have to SET FILE TYPE BLOCK explicitly if s/he wanted them usable by VAXmate services (Bernie, would that work?). - Frank ------------------------------ Date: Mon, 22 Dec 86 09:48 EST From: (brian nelson) Subject: VMS Kermit Settings To: sy.fdc@cu20b DMF/DHU/DHV terminal settings and PACX systems: Regarding VMS terminal settings, here are two example from my 785. The first, TXA1, is on a DMF32 connecting into a Gandalf PACX 1000 system via an AMTB3. This line is used all the time to connect into both Vadic VA4224 modems for calling off campus, and also to connect to the other systems hooked into the Gandalf system. Ie, Kermit-32> CON TXA1 will get the Gandalf to recognize the DMF line as a terminal once it seems a transition in DTR (which can be done by exiting VMS kermit and going back into Kermit). Terminal: _TXA1: Device_Type: Unknown Owner: No Owner Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase No Tab Wrap Scope Remote Eightbit Broadcast No Readsync No Form Fulldup Modem No Local_echo Autobaud Hangup No Brdcstmbx DMA Altypeahd Set_speed Line Editing Overstrike editing No Fallback Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRT No Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 This is just an example of the settings for user lines, all of which connect via the PACX 1000. Note the DISCONNECT setting, this is highly desirable for security. If the user hangs up, or otherwise disconnects without logging out, the drop of CD will have VMS disconnect the process and eventually delete the process (default is 900 seconds). Physical terminal: _TXF0: Username: CSDJR [(2(] Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase Tab Wrap Scope Remote Eightbit Broadcast No Readsync No Form Fulldup Modem No Local_echo Autobaud Hangup No Brdcstmbx DMA Altypeahd Set_speed Line Editing Overstrike editing No Fallback Dialup No Secure server Disconnect No Pasthru No Syspassword No SIXEL Graphics Soft Characters Printer port Application keypad ANSI_CRT No Regis No Block_mode Advanced_video Edit_mode DEC_CRT DEC_CRT2 Brian ------------------------------ Date: Tue, 24 Feb 87 16:30:32 CST From: "Jeff Balvanz" Subject: Problems With VAX/VMS Kermit Keywords: VAX/VMS Kermit We have been having some problems with VAX/VMS Kermit here at ISU and I'm wondering if anyone can offer some advice. Here are some of the problems: 1. When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an eight-bit communications line, SET PARITY NONE on both ends usually results in 16 retries and no packets sent. Setting parity to EVEN on both ends causes a file to be uploaded, but often with repeated characters in the file (as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable. However, setting the parity back to NONE on both sides after an unsuccessful upload at EVEN sometimes results in a successful transfer. It drives us nuts because sometimes no parity works just fine, and some files will transfer successfully with EVEN parity. The files that give repeating characters are normal text files, and it is (to me, anyway) impossible to determine any difference between the files that work and those that don't. However, a file that doesn't work once usually will repeat the behavior. 2. Downloading files with FORTRAN carriage control to MS-Kermit 2.29 (or, I suspect, any other local Kermit) results in the message "Illegal file type" from VMS Kermit. APPENDing the file to a normal file created with the CREATE command causes it to download just fine. According to the source code this was supposed to be fixed in VMS Kermit v 3.2. We are running VMS version 4.5 and VMS Kermit version 3.2.076, just assembled from MACRO source gotten from Columbia over BITNET since the VMS upgrade. Any suggestions? I'd be happy to correspond with someone over BITNET if it will help. Jeff Balvanz Manager, Microcomputer Services Iowa State University Computation Center GR.JLB@ISUMVS.BITNET ------------------------------ Date: Wed 18 Mar 87 16:15:21-EST From: Frank da Cruz Subject: Yet another suggestion for VMS Kermit To: rmcqueen@SITVXB I've been getting complaints that there's no way to send a BREAK from VMS Kermit. Since you really need to do this when connected to IBM mainframes (SET IBM ON), or to get the attention of certain communication devices, you might consider installing this. I realize there's probably no way to actually get VMS to transmit a real BREAK, but you can do what we did in DEC-20 Kermit: when the user gives the B command during CONNECT, you crank the baud rate down to 50 baud, transmit 2 or 3 NUL characters, and then restore the baud rate. I don't know if VMS would let you do this (you probably need SYS$CHANGING_BAUD_RATE privileges or something), but if so, it's worth a try. What do you think? Things like this are becoming more of an issue now that we're getting thousands of "personal VAXes" out there, which are used primarily in local, rather than remote, mode. - Frank ------------------------------ Date: Wed 18 Mar 87 11:37:58-EST From: Frank da Cruz Subject: Question of the day To: rmcqueen@SITVXB, sy.christine@CU20B.COLUMBIA.EDU "I'm trying to transfer a (...) file from the PC to VMS Kermit and after xx (small number, like 25) packets, the transfer fails with the message 'record to long for internal buffer'." The (...) file is usually some kind of CAD file (like IGIS format, or however you spell it). The problem is that the file is just one long stream of ASCII characters, with no CRLFs. But VMS is a record-oriented file system, and a file has a maximum record length, so this long file won't fit into a record in the VMS file. Workaround: "set file type fixed" on VMS Kermit. At least then you can transfer the file to it. What you do with it after that, I don't know. ------------------------------ Date: Wed 18 Mar 87 14:28:14-EST From: Frank da Cruz Subject: Tektronix vs Kermit To: sy.christine@CU20B.COLUMBIA.EDU, rmcqueen@SITVXB I talked the horse's mouth (ear?) about this... Andrew Burke at Tektronix (503-685-3112). In case you get more questions about this, here's the scoop. IGES files are an ANSI standard format for interchanging graphics information (IGES = Initial Graphics Exchange Specification). There are several variations of IGES. The first one, which everyone should be using, has 80-column records (like card images). Others include "compressed" and "binary". Teknicad is Tektronix's CAD package for VAX/VMS, and it only understands the 80-column format, so it doesn't do any good to use Kermit (or any other file transfer mechanism) to send the other kinds to a VAX for use with Teknicad. The people who are complaining about "record too long for internal buffer" are incorrectly trying to send compressed or binary IGES files to the VAX. This means that they either used the wrong conversion option on their CAD station, or else the conversion program on their CAD station produces the wrong kind of IGES file by default. The IGES standard is available from the National Bureau of Standards under reference number 82-2631. Thus is answered the question of the day. - Frank ------------------------------ Date: Tue, 14 Apr 87 22:32 PST From: (Don Jenkins) Subject: NEW VMS KERMIT there seems to be a small problem with the latest release of vms kermit. when one return from server mode (without giving the finish command) you can't break out of server mode with a control-y (one must use the finish command from your pc) to exit. don jenkins uc riverside. ------------------------------ Date: Mon 20 Apr 87 17:11:10-EST From: Christopher P. Lent Subject: Generating a BREAK with VMS Hi, I was looking through the VMSMIT.BWR file and I noticed that Frank was under the impression that VMS couldn't send a break. Well after VMS4.4 VMS can send breaks. Attached is an INFO-VAX message about it. Enjoy, Chris Lent ------------------------------ Date: Tue, 14 Apr 87 04:48:23 PST From: nagy%43198.hepnet@lbl.arpa Subject: Sending a Break "character" from VMS This information is from the VMS V4.4 Release Notes section 2.3.10.1 on page 2-20: Previously, there was no $QIO system service that allowed an application to send a break to a terminal. A break can now be sent by setting TT$M_BREAK in the P5 parity flags argument to the IO$_SETMODE $QIO. Sending the break actually involves two $QIOs; one to turn it on and one to turn it off. (The break bit in the parity flags argument is set to turn on break and cleared to turn it off.) The application should use a timer in between the two $QIOs to ensure that the break has time to take effect. So, VMS V4.4 and later support generation of the Break from an application program. ------------------------------ Date: Tue, 21 Apr 87 06:48:55 PDT From: ROME%ORN.MFENET@nmfecc.arpa Subject: Kermit 32 3.3.077 bug I wrote a letter to you describing this bug. We just got a newer version of VMS Kermit and it seems to have the same bug. When sending a binary file from the VAX without using 8th bit quoting, characters 163 and 254 get prefixed with the '#' control character quote. Since the checksum is correct, I am reasonably sure that this analysis of the situation is correct. Is this a known problem? can you reproduce it? Is there a bulletin board I can access to get information on such problems? Jim Rome, Oak Ridge National Lab (615) 574-1306 ------------------------------ Date: Tue 9 Jun 87 10:32:37-EDT From: Frank da Cruz Subject: Bad bug in VMS Kermit To: rmcqueen@SITVXA.CCNET Bob, I got a call today from one of our supercomputer users, who is trying to transfer binary files between a VMS system (that front ends for a Cray in Pittsburgh) and a Mac (or a PC, or a PDP-11, all with the same results). The problem is that portions of the data are incorrect after transfer. This appears to be closely related to the following two bug reports (more on this below): ------------------------------ Date: Tue, 24 Feb 87 16:30:32 CST From: "Jeff Balvanz" Subject: Problems With VAX/VMS Kermit Keywords: VAX/VMS Kermit We have been having some problems with VAX/VMS Kermit here at ISU and I'm wondering if anyone can offer some advice. Here are some of the problems: 1. When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an eight-bit communications line, SET PARITY NONE on both ends usually results in 16 retries and no packets sent. Setting parity to EVEN on both ends causes a file to be uploaded, but often with repeated characters in the file (as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable. However, setting the parity back to NONE on both sides after an unsuccessful upload at EVEN sometimes results in a successful transfer. It drives us nuts because sometimes no parity works just fine, and some files will transfer successfully with EVEN parity. The files that give repeating characters are normal text files, and it is (to me, anyway) impossible to determine any difference between the files that work and those that don't. However, a file that doesn't work once usually will repeat the behavior. ------------------------------ Date: Tue, 21 Apr 87 06:48:55 PDT From: ROME%ORN.MFENET@nmfecc.arpa Subject: Kermit 32 3.3.077 bug I wrote a letter to you describing this bug. We just got a newer version of VMS Kermit and it seems to have the same bug. When sending a binary file from the VAX without using 8th bit quoting, characters 163 and 254 get prefixed with the '#' control character quote. Since the checksum is correct, I am reasonably sure that this analysis of the situation is correct. Is this a known problem? can you reproduce it? Jim Rome, Oak Ridge National Lab (615) 574-1306 ------------------------------ (Frank again) The guy who called said he discovered 3 problems: 1. If his file contains 8 null bytes in a row, only seven of them come through. 2. The sequence 3131 (hex) is received as 0C (hex). 3. The sequence 3030 (hex) is received as 0A0A (hex). Other repeated sequences, however, seem to be transferred correctly. There seems to be something bad lurking in Kermit-32's packet encoding, which is triggered whenever you have binary files and repeat counts. This is pretty serious. Is there any chance you can take a look? If there's anything Kermit should be able to do right, it's transfer files! I'll be calling the super- computer center to verify that they're not running some ancient version of VMS Kermit, but from the messages above, it appears that the problem persists even in recent versions. Thanks! - Frank ------------------------------ 25-Jun-87 17:53:52-EDT,1065;000000000001 Return-Path: Received: from CRVAX.SRI.COM by CU20B.COLUMBIA.EDU with TCP; Thu 25 Jun 87 17:53:04-EDT Date: Thu 25 Jun 87 14:51:48-GMT From: John Herndon Subject: Re: Kermit-32 question To: SY.FDC@CU20B.COLUMBIA.EDU Message-ID: <551627508.0.CONSULT2@CRVAX.SRI.COM> In-Reply-To: <12303621509.8.SY.FDC@CU20B.COLUMBIA.EDU> Mail-System-Version: Frank, Back in May I sent out a question about why SET FILE_TYPE BINARY failed in Kermit-32 v3.3. I screwed up and included the wrong file in the message. Well, I didn't see your reply asking about the screwed-up message until just now (I don't actually usually read my mail on the VAX!). So I just thought I'd write and let you know that I found out that the problem was that the command should be SET FILE TYPE BINARY (no underscore in FILE_TYPE) -- then binary transfers work. So the problem is a minor problem in the internal documentation, not a major problem in the program Susan Cole ------- Reportedly, VMS Kermit doesn't set its return code ($STATUS) according to the success or failure of the most recent transaction, which makes it tough to write automated DCL procedueres that use Kermit. ------- Reportedly, VMS Kermit will report a huge number, rather that the actual effective baud rate, when you give the STATUS command under VMS 4.4 or later. It seems to work OK under VMS 4.3. Also, older versions of VMS Kermit (e.g. 3.0) seem to report the effective baud rate correctly, even under VMS 4.4 or later... ------- ------------------------------ Date: 18 Sep 87 8:38 -0600 From: Grant Delaney Subject: Kermit 32 ESCAPE and VT330 terminal A note of caution the kermit-32 escape sequence is also the terminal reset and self test sequence for the NEW VT330 terminal. The escape sequence should therefore be changed before a connect if you want to get out again. Grant ------------------------------ 28-Sep-87 08:45:26-EDT,1393;000000000005 Return-Path: Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 28 Sep 87 08:45:24-EDT Received: from UOFT02.BITNET (BRIAN) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id 1656; Mon, 28 Sep 87 08:43:11 EDT Date: Mon, 28 Sep 87 08:39 EDT From: (Brian Nelson) Subject: kermit-32 bugs To: sy.fdc@cu20b X-Original-To: frank, BRIAN Frank, Here is an interesting log of an annoying Kermit-32 problem under VMS 4.5. The only thing I can think of thats changed here in the recent past is the decnet node name. Brian $ ker ser Kermit-11 T3.59 Last edit: 17-Sep-87 Kermit Server running on PDP-11 host. Please type your escape sequence to return to your local machine. Shut down the server by typing the Kermit BYE command on your local machine. [Returning to VAX/VMS Kermit-32] Kermit-32>loc dir *.raw Directory SYS$SYSROOT:[BRIAN] PRQ001.RAW;1 Total of 1 file. Kermit-32>sen *.raw Sending: %KERMIT32-E-RMS32, %RMS-E-FNF, file not found for *.RA0 Kermit-32>loc dir *.listing Directory SYS$SYSROOT:[BRIAN] CHEM87.LISTING;1 Total of 1 file. Kermit-32>send *.listing Sending: %KERMIT32-E-RMS32, %RMS-E-FNF, file not found for *.LISTINI Kermit-32>bye Rmt$ log BRIAN logged out at 28-SEP-1987 08:34:09.56