home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / imail.85b < prev    next >
Text File  |  2020-01-01  |  569KB  |  13,831 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.             Columbia University Center for Computing Activities
  22.  
  23.  
  24.  
  25.  
  26.                              INFO-KERMIT DIGEST
  27.  
  28.                                   VOLUME 3
  29.  
  30.                             July - December 1985
  31.  
  32.  
  33. Table of Contents
  34.  
  35.  
  36. Volume 3, Number 1                                                            1
  37.   New Release of Kermit-11 Available                                          1
  38. Volume 3, Number 2                                                            5
  39. Volume 3, Number 3                                                           14
  40.   New Apple II Cross Assemblers                                              17
  41. Volume 3, Number 4                                                           19
  42. Volume 3, Number 5                                                           24
  43.   New vs Classic Kermit                                                      27
  44. Volume 3, Number 6                                                           30
  45. Volume 3, Number 7                                                           34
  46. Volume 3, Number 8                                                           44
  47. Volume 3, Number 9                                                           52
  48.   About the New Proposals                                                    53
  49. Volume 3, Number 10                                                          59
  50.   Re: The New Proposals                                                      60
  51. Volume 3, Number 11                                                          65
  52. Volume 3, Number 12                                                          74
  53. Volume 3, Number 13                                                          79
  54. Volume 3, Number 14                                                          87
  55. Volume 3, Number 15                                                          98
  56. Volume 3, Number 16                                                         107
  57.   New BITNET KERMSRV Command Syntax                                         112
  58. Volume 3, Number 17                                                         114
  59.   New C-Kermit Bug List                                                     114
  60. Volume 3, Number 18                                                         123
  61.   Announcing LM-KERMIT for Lispmachine Lisp Environments                    123
  62. Volume 3, Number 19                                                         131
  63.   New Macintosh Kermit Bug List                                             131
  64. Volume 3, Number 20                                                         139
  65.   Kermit Available for Os9                                                  139
  66.   Commodore 64 Kermit V1.7 Available                                        139
  67.   NEC APC III Kermit Available                                              140
  68. Volume 3, Number 21                                                         146
  69. Volume 3, Number 22                                                         154
  70.   Comments on C-Kermit new features                                         159
  71. Volume 3, Number 23                                                         163
  72.   New BOO-file Maker for MS-DOS                                             163
  73. Volume 3, Number 24                                                         171
  74. Volume 3, Number 25                                                         180
  75. Volume 3, Number 26                                                         186
  76.   New TI Pro Support for MS-DOS Kermit 2.28                                 188
  77. Volume 3, Number 27                                                         194
  78.   New Release of BBC Acorn Kermit                                           194
  79.   New ACT Apricot Support for MS-DOS Kermit 2.28                            195
  80. Volume 3, Number 28                                                         198
  81.   Problems with New HP-110 MS-DOS Kermit Support                            201
  82.   Re: Problems with New HP-110 MS-DOS Kermit Support                        201
  83. Volume 3, Number 29                                                         204
  84.   New Kermit-11 Coming                                                      206
  85. Volume 3, Number 30                                                         212
  86. Volume 3, Number 31                                                         215
  87.   Cromix Kermit???                                                          215
  88.   New Release of Burroughs B7900 Kermit                                     216
  89. Volume 3, Number 32                                                         223
  90.   New MS-DOS Kermit Available for Evaluation                                223
  91.  
  92. Table of Contents
  93.  
  94. Volume 3, Number 33                                                         232
  95.   Minor Mod to New MS-DOS Kermit                                            234
  96. Volume 3, Number 34                                                         236
  97.   New Honeywell CP-6 Kermit                                                 236
  98.   New version of IMUSIC                                                     236
  99. Volume 3, Number 35                                                         245
  100.  
  101. INFO-KERMIT DIGEST V3 #1                                                 Page 1
  102.  
  103. Info-Kermit Digest         Tue,  2 Jul 1985       Volume 3 : Number  1
  104.  
  105.                   New Release of Kermit-11 Available
  106.         Unix Program for Converting CU20B FTP Server Filenames
  107.                       Mac Kermit & Caps Lock Key
  108.               IBM PC Kermit and National Character Sets
  109.                   MS DOS Memory Allocation in Kermit
  110.                          More about ND-Kermit
  111.                        Kermit Versus 9600 Baud
  112.  
  113. ----------------------------------------------------------------------
  114.  
  115. Date: Tue 2 Jul 85 19:50:57-EDT
  116. From: Frank da Cruz <SY.FDC@CU20B>
  117. Subject: New Release of Kermit-11 Available
  118. Keywords: Kermit-11
  119.  
  120. Brian Nelson of the University of Toledo (BRIAN@UOFT02) has sent in version
  121. 2.29 of Kermit-11, replacing version 2.26 of March 1985.  The changes include:
  122.  
  123. . Fix losing attribute packets in case timed out or nak'd.
  124. . Fix ASSDEV: for stack problem
  125. . Added SET BINARY-TYPE .xxx for overriding the built-in binary file type list.
  126. . Kludge if RT system does not have a clock.
  127. . Ignore TYPE in SET FILE [TYPE] arg.
  128. . Final mods by Ned Rhodes for TSX+
  129. . Add support for server REM DIR command for RT and TSX+.
  130. . Fix bug for setting 8bit prefixing (quite noticable on PRO/RT version).
  131. . Add SET FIL [NO]SUPERCEDE to protect files that already exists.
  132. . Update packet types to symbolic names
  133.  
  134. The files are available via anonymous FTP from CU20B as K2:K11*.* (many files).
  135. General information is in K2:K11AAA.AAA.  The files are listed and explained
  136. in K2:K11FIL.DOC.  Installation instructions are in K11INS.DOC.
  137.  
  138. ------------------------------
  139.  
  140. Date: Tue 2 Jul 85 15:50:57-EDT
  141. From: Frank da Cruz <SY.FDC@CU20B>
  142. Subject: Unix Program for Converting CU20B FTP Server Filenames
  143. Keywords: FTP Server, UNIX
  144.  
  145. Many have complained that when getting (especially "mget"ing) files to a Unix
  146. system from the CU20B FTP server, the resulting filenames are not what would
  147. be desired.  This problem is partially fixed by the installation of a new FTP
  148. server that allows users to CWD (CD) to a given directory for read access, so
  149. that the fully qualified file name need not be sent back for each file gotten
  150. with an "mget".
  151.  
  152. However, even if you CWD to KER: or K2: before issuing an mget command, the
  153. files will still show up with uppercase names and will include "generation"
  154. (version) numbers.  And of course, if you fail to CWD first, you still get
  155. the directory name too, so that you are likely to find files with names like
  156.  
  157. <KERMIT>CKUFIO.C.3
  158.  
  159.  
  160. Page 2                                                 INFO-KERMIT DIGEST V3 #1
  161.  
  162. in your Unix directory, rather than the ckufio.c you might have wanted.
  163.  
  164. A new program, xxu (20-to-Unix filename converter), is available in KER:XXU.C
  165. which will fix the names of all files sent to a Unix system from a DEC-20 FTP
  166. server.  It should work on VMS and DEC-20 filenames alike -- it strips DECnet
  167. node names, device names, directory names, generation numbers, and it
  168. lowercases the uppercase letters.  When renaming to the name thus formed, it
  169. takes care not to write over any existing files.  See comments in the source
  170. for further details.
  171.  
  172. ------------------------------
  173.  
  174. Date: Fri 28 Jun 85 15:52:03-EDT
  175. From: Mauricio Matiz <US.MATIZ@CU20B>
  176. Subject: Mac Kermit & Caps Lock Key
  177. Keywords: MacKermit
  178.  
  179. Now that Kermit for the Macintosh has a keymap program that allows mapping of
  180. the control key to the caps lock key, the locking mechanism becomes a
  181. nuisance.  There have been postings about taking the whole keyboard apart and
  182. using a soldering gun, etc. in order to remove the locking mechanism.  I have
  183. come up with a simpler and easier method that does not void your warranty.
  184.  
  185. Remove the key using a small screwdriver.  There is a spring and the end of
  186. it goes through the plastic that supports the key. Stick a piece of paper or
  187. soft putty (very small) between the tip and the bottom of the keyboard.  This
  188. will prevent the key from depressing all the way and locking, but still allow
  189. contact of the key.  It even works for repeating control characters.  If you
  190. come up with a better substance to stick in there let me know (or the Kermit
  191. people at Columbia).  I have been using this for some time with no problems.
  192. I imagine that after a while I will need to change the paper because of the
  193. continued pressing on it.
  194.  
  195. Maurice Matiz
  196. Columbia University
  197. User Services
  198.  
  199. [Ed. - As usual, neither the author of this message nor Columbia University
  200. acknowledges any liability for damage or loss of warranty incurred by anyone
  201. who follows these directions.]
  202.  
  203. ------------------------------
  204.  
  205. Date: Sat, 29 Jun 85 14:43:27 -0200
  206. From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
  207. Subject: IBM PC Kermit and National Character Sets
  208. Keywords: MS-DOS Kermit
  209.  
  210. A suggestion for IBM PC Kermit: You must be aware of that many european
  211. characters have a different internal representation on the IBM PC and other
  212. computers.  The norwegian alphabet, for example, has 3 extra characters,
  213. which in normal ASCII replaces [\] (upper) and {|} (lower case).  On the IBM
  214. PC, all these characters are represented with values in the range 128-255.
  215. This means that every terminal emulation program (to have a chance on the
  216. Norwegian market) must include an option to convert between the two
  217. standards, both when acting as a terminal and when transferring files.
  218.  
  219. INFO-KERMIT DIGEST V3 #1                                                 Page 3
  220.  
  221.  
  222. We have a local mod to MSSET and MSYIBM which fixes the terminal problem,
  223. and provide a converting program on the Kermit diskette to convert the text
  224. files.  However, I feel that this must be a problem in other European
  225. countries, and I was hoping for a more general solution.
  226.  
  227. The SET KEY feature will make it possible to do terminal emulation with a
  228. "national" keyboard, but the right characters will not appear on the screen.
  229. Why not include a SET FONT command?  For Norway, all that would be needed,
  230. was 6 SET KEYs and 6 SET FONTs in a macro defined in MSKERMIT.INI, and we
  231. could do without the local mods.  As to transferring files, I prefer the
  232. "raw" approach, and leave conversion to the user.  When transferring MASM or
  233. PASCAL programs, I do not like to see my square brackets turn into
  234. you-know-what.
  235.  
  236. [Ed. - Good idea, though I'm not sure if you mean "set font" or "set
  237. character".  A font would be a whole character set, presumably some
  238. alternate character set in ROM, invokable by changing some pointer.  This
  239. would probably be easy to implement, though the details would be very
  240. system-dependent.  Changing how individual characters display would be
  241. harder, not so much to implement, but to design the command -- the user
  242. would need to say something like "if I get a character whose ASCII value is
  243. x, then display character y from font z in its place..."]
  244.  
  245. ------------------------------
  246.  
  247. From: lotto%lhasa@harvard.ARPA
  248. Date:   30 Jun 85 14:19 EDT
  249. Subject:  MS DOS Memory Allocation in Kermit
  250. Keywords: MS-DOS Kermit
  251.  
  252. Well, I finally found the problem with memory allocation and (Microsoft) I
  253. was missing something crucial. KERMIT as part of its memory initialization,
  254. gives extra memory back to DOS explicitly. Unfortunately, the calculation of
  255. the image end assumes that the stack segment is not last.  My apologies to
  256. those people that I confused from an incomplete investigation of the
  257. problem. I still object to the IBM versions of Micro- softs programs being
  258. built with new defaults, but in this case it only confused matters instead
  259. of being the root of the problem.
  260.  
  261. To address the issue of memory allocation directly, if segment ordering
  262. becomes so important, perhaps the required space should be calculated from
  263. the load module image size and not from the offset of a specific object file
  264. in KERMIT.  Is there some reason why this is undesireable?
  265.  
  266. Jerry Lotto     lotto@harvard.ARPA      inhp4!harvard!lhasa!lotto
  267.  
  268. ------------------------------
  269.  
  270. Date: Sat, 29 Jun 85 14:43:27 -0200
  271. From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
  272. Subject: More about ND-Kermit
  273. Keywords: ND Kermit
  274.  
  275. The operating system of the ND series computers is SINTRAN III.  Versions are
  276. numbered with the letters A,B,..  The Kermit I sent you runs under version J,
  277.  
  278. Page 4                                                 INFO-KERMIT DIGEST V3 #1
  279.  
  280. and needs the Pascal-J compiler and library.  The binary program,
  281. KERMIT:PROG, should run under previous versions, at least back to H.
  282.  
  283. Anyone who sends us a self-adressed diskette envelope with one 148-page 8" ND
  284. diskette (two if you need source code), will receive the latest version of
  285. ND-Kermit for free.  There are plans to include SERVER and CONNECT later this
  286. summer.
  287.  
  288.           Frithjov Iversen
  289.           RUNIT Brukerkontakt
  290.           N - 7034 Trondheim-NTH
  291.           NORWAY
  292.  
  293. ------------------------------
  294.  
  295. Date:  Sat, 29 Jun 85 22:56 EDT
  296. From:  Frankston@MIT-MULTICS.ARPA
  297. Subject:  Kermit Versus 9600 Baud
  298. Keywords: Modem, Sliding Windows Kermit
  299.  
  300. I've been experimenting with a 9600 bps dialup modem.  It is cheap (about
  301. $800).  It is really a half duplex modem that provides a full duplex
  302. interface and a reliable byte stream.  This is fine, except when one uses
  303. protocols such as Kermit and Xmodem which have only a single packet in the
  304. stream at a time.  It takes .5 seconds or more to turn around the line.  Thus
  305. sending a packet, acking and sending the next one reduce one to 1 second/
  306. package or about 900 bps for kermit and about 1200 for Xmodem.  This is the
  307. same as the problem of satellite links.
  308.  
  309. Given that such modems make a lot of sense since they make more effective use
  310. of the bandwidth for file transfering than true full duplex modems, what
  311. thought has been given to upgrading Kermit to allow for a protocol that can
  312. have multiple packets active at once?
  313.  
  314. I presume that there has already been much discussion of this, but now that
  315. it is my ox being gored, I have a special interest in this issue.
  316.  
  317. [Ed. - For a couple years, people have been asking for (a) a sliding window
  318. extension to the Kermit protocol, and (b) a way to have longer packets.
  319. Some people are working on a sliding window protocol, and a proposal will
  320. be posted to Info-Kermit some time soon.  At the same time, I'll also post
  321. a proposal for a way to allow longer packets.]
  322.  
  323. ------------------------------
  324.  
  325. End of Info-Kermit Digest
  326.  
  327. INFO-KERMIT DIGEST V3 #2                                                 Page 5
  328.  
  329. Info-Kermit Digest         Tue,  9 Jul 1985       Volume 3 : Number  2
  330.  
  331.                  KERM and KERK Registered with Apple
  332.                            Okstate Downtime
  333.                Re: MS-Kermit 2.28 Wraparound Backspace
  334.                             MASM & Kermit
  335.                        C-Kermit on HP-9000 S500
  336.                         C-Kermit Line Locking
  337.                           UUCP Line Locking
  338.               Running Pro-3xx P/OS Kermit from Tool Kit
  339.                          Bug in Prime Kermit
  340.                       More about 9600 bps Modem
  341.              More about PC-Kermit and National Characters
  342.                    Z100 Comunications Program Query
  343.                         Kermit on MicroVAX-1?
  344.  
  345. ----------------------------------------------------------------------
  346.  
  347. Date: Mon 8 Jul 85 18:04:31-EDT
  348. From: Frank da Cruz <SY.FDC@CU20B>
  349. Subject: KERM and KERK Registered with Apple
  350. Keywords: Macintosh
  351.  
  352. The Macintosh application names KERM and KERK have been registered with
  353. Apple for Macintosh Kermit and for the Macintosh Kermit Keyboard
  354. Configurator, respectively.  These names allow "documents" (e.g. settings
  355. files) created by these programs to be associated with the programs
  356. themselves so that double clicking such a document will invoke the program
  357. with the indicated settings.
  358.  
  359. ------------------------------
  360.  
  361. To: Info-Kermit@CU20B.ARPA
  362. Subject: Okstate Downtime
  363. Date: 09 Jul 85 06:43:11 CDT (Tue)
  364. From: vasoll%okstate.csnet@csnet-relay.arpa
  365. Keywords: Okstate
  366.  
  367. The system `Okstate' will be down for hardware and software upgrade from
  368. 8:00 a.m. July 17th until 5:00 p.m. July 22 (all times central).  During
  369. this time the UUCP and Kermit Server line used for the Kermit Distribution
  370. will not be available.
  371.  
  372. Mark Vasoll
  373. Department of Computing and Information Sciences
  374. Oklahoma State University
  375.  
  376. UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll
  377. ARPA:  vasoll%okstate.csnet@csnet-relay.arpa
  378.  
  379. ------------------------------
  380.  
  381. Date: Tue, 2 Jul 85 18:20:31 pdt
  382. From: tweten@AMES-NAS.ARPA (Dave Tweten)
  383. Subject: Re: MS-Kermit 2.28 Wraparound Backspace
  384. Keywords: MS-DOS Kermit, UNIX
  385.  
  386. Page 6                                                 INFO-KERMIT DIGEST V3 #2
  387.  
  388.  
  389. In Info-Kermit Digest, volume 2, number 40, Greg Small writes:
  390.  
  391.     The backspace from column 1 to column 80 of the previous line
  392.     was added for UNIX.  For normal input echoing, UNIX assumes
  393.     that the terminal handles all margin wraping.  This includes
  394.     both the normal forward wrap at the right margin and the less
  395.     known reverse wrap at column 1.  Of course this only impacts
  396.     those who enter and then wish to erase characters from lines
  397.     longer than 80 characters.
  398.  
  399. That confuses me.  My impression is that bsd UNIX uses curses and termcap
  400. entries to perform terminal independent smart terminal operations.  This
  401. includes simulation of wrap-around backspace for terminals whose termcap
  402. entries do not contain the "bw" ("backspace wraps") specifier.
  403.  
  404. My impression is reinforced by observation of "vi" behavior with long lines.
  405. I used MS-Kermit 2.27 (which correctly emulates H-19 backspace behavior) in
  406. linewrap mode.  On multi-row lines, right arrow and space moved me from
  407. column 80 on one row to column 1 on the next.  Left arrow and backspace
  408. moved me from column 1 to column 80 of the previous row.
  409.  
  410.     Actually, we have abandoned pretending that a particular
  411.     program emulates a real terminal.  We now treat each emulator
  412.     and version thereof as a seperate terminal type.
  413.  
  414. This seems to me to be a sad commentary on the current state of design and
  415. implementation of most terminal emulation packages.  It is also a little
  416. frightening to consider what this means if you multiply the number of
  417. available terminal emulators (say, for just the vt-100) times the number of
  418. different operating systems which think they know about the terminal being
  419. emulated.
  420.  
  421. Particularly in the case of Kermit, where Columbia and the user community
  422. have control over the quality of the emulation, it seems to me to make much
  423. more sense to emulate the H-19 well enough that it fools (almost) all the
  424. systems which think they know about it.  Users whose systems require a more
  425. faithful emulation than is currently provided should be encouraged to
  426. contribute Kermit code modifications.
  427.  
  428. Finally, let me reiterate that though I believe strongly in faithful
  429. emulation, and though I can't see how UNIX could require wrap-around
  430. backspace, I don't think wrap-around backspace represents a serious
  431. deviation from the ideal H-19 emulation.  I can't imagine that it is common
  432. for programs to send column-1 backspaces to H-19s, realizing that they will
  433. be ignored.
  434.  
  435. [Ed. - We have received a couple H-19 (Z-19) manuals in response to our plea a
  436. couple issues ago (thanks to those who sent them!), so we should now be able to
  437. emulate this terminal more faithfully...]
  438.  
  439. ------------------------------
  440.  
  441. From: lotto%lhasa@harvard.ARPA
  442. Date:   28 Jun 85 11:18 EDT
  443. To: harvard!info-ibmpc@usc-isib.ARPA
  444.  
  445. INFO-KERMIT DIGEST V3 #2                                                 Page 7
  446.  
  447. Subject: MASM & Kermit
  448. Keywords: MASM
  449.  
  450. If you are building KERMIT with the Microsoft assembler (any version) or the
  451. IBM release (pre 2.0) all will work as written.  If however, you are using
  452. MASM 2.0 or later (IBM release) you must specify the /S switch on the command
  453. line for MSXDMB.  Be sure the Linker you are using does not predate the
  454. version of DOS by too much.  Also, make sure you actually DO have enough
  455. memory to run KERMIT in.  A fairly significant chunk of RAM is used by the
  456. new KERMIT, but unlike the previous version, it is allocated by the program.
  457.  
  458. Gerald Lotto - Harvard Chemistry Dept.
  459.  
  460.  UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
  461.  ARPA:  lotto@harvard.ARPA
  462.  CSNET: lotto%harvard@csnet-relay
  463.  
  464. ------------------------------
  465.  
  466. Date:  Wed, 3 Jul 85 12:16 EDT
  467. From:  WIBR@MIT-MULTICS.ARPA
  468. Subject:  C-Kermit on HP-9000 S500
  469. Keywords: C-Kermit, HP9000
  470.  
  471. I solved that packet-size problem I was having (calling out and trying to
  472. send from my HP9000 Series 500).  Apparently, I have to tell the remote host
  473. that I am a vt100, or I get into problems.  At least, when I did call myself
  474. a vt100, I was able to send with no problems.
  475.  
  476. The obvious inconvenience hewith this is that since I really am using an
  477. HP2392A terminal, fun things like EMACS die big if I'm trying to use Kermit
  478. in the same login session.  Oh, well.
  479.  
  480. [Ed. - Could it be that by telling the host you are a VT100, you turn on
  481. its XON/XOFF flow control?  Maybe you could tell it you're an HP terminal,
  482. and also tell it to use XON/XOFF, and all will work well.]
  483.  
  484. A note to HP9000 users out there ( if there are any!):  Kermit cannot
  485. use an ASI card interface to a modem if it is to call outside.  It needs
  486. to be talking to a MUX board port (properly addressed by read-writeable
  487. ttyxx, cuaxx and culxx files in /dev).  Since the ASI board took care of
  488. neat items such as telling the modem to hang up when it's done with it
  489. (using signal lines), and the MUX board cannot, we installed new chips
  490. in our Racal-Vadic's (from them) to interpret a ^C^D sequence flanked by
  491. 3 seconds of dead air on either side as a "hangup".  Thus, I modified
  492. the Kermit code to echo a "^C^D" to the communications port when exiting
  493. Kermit.  Perhaps the best way to do this, would be to modify the
  494. ckudia.c MDMINF struct to include a "hangup_str" parameter.  Unless of
  495. course, this is too obscure a scenario...
  496.  
  497. One further note: ^\^F still doesn't abort a file transfer that is hung up;
  498. neither does ^\^B, for that matter.  Does the transfer have to be at least a
  499. little successful ( a few packets here and there) for this to work?  If so,
  500. perhaps it is suboptimal?
  501.  
  502. [Ed. - Right, interrupting a transfer with [^\]{^F,^B} only takes effect
  503.  
  504. Page 8                                                 INFO-KERMIT DIGEST V3 #2
  505.  
  506. after the first data packet has passed.  So there's no good way to interrupt
  507. a Unix Kermit that's stuck trying to start a file transfer, short of ^C'ing
  508. it to stop the program all together.  This is noted in the .BWR file.]
  509.  
  510. ------------------------------
  511.  
  512. Date: Sun, 7 Jul 85 10:14:48 pdt
  513. From: tweten@AMES-NAS.ARPA (Dave Tweten)
  514. Subject: C-Kermit Line Locking
  515. Keywords: C-Kermit
  516.  
  517. In Info-Kermit Digest, volume 2, number 39, Scott Weikart writes about
  518. Kermit line-locking:
  519.  
  520.      Instead of setuid, I think it would be much better to operate
  521.      setgid.  Then the ownership of the lock file would be intact.  I
  522.      put uucp, cu, kermit, etc in a group called dialer, for such
  523.      situations.
  524.  
  525. I agree that the group mechanism is the appropriate tool to use.  On our Vax
  526. 780, 4.2 BSD system, the system administrator has established a similar
  527. group.  The dial-out ttys are owned by the group and are given owner and
  528. group access, and so is /usr/spool/uucp.  That way, using /etc/groups, we can
  529. admit users to the group who have a valid need to dial out.  We thereby
  530. reduce our exposure to the phone bills which would result from someone
  531. dialing into his favorite Timbuktu bulletin board all day.
  532.  
  533. To make this system as consistant as possible, we have modified C-Kermit
  534. to make the /usr/spool/uucp "no read access" and "no write access"
  535. warning messages be preventive messages instead.  That way, if an access
  536. specification mistake has been made, there is less likelyhood of Kermit
  537. users, tip users, uucp, etc. stomping on one another.
  538.  
  539. As I see it, the problem can be resolved for all sizes of systems.  In a
  540. small system, with a tight group of users, make /usr/spool/uucp and the ttys
  541. publicly accessible.  With a larger system, make them group accessible, and
  542. only admit to the group those with a legitimate need to contribute to the
  543. size of the phone bill.
  544.  
  545. The concern over users' ability to get their work done is resolved by
  546. realizing that on a system which is small and tight-knit enough for public
  547. access to be appropriate, the "system administrator" is likely to be very
  548. accessible (if "he" is not, in fact, just a hat worn by any of several users
  549. when doing system administration tasks).  In a larger system, the
  550. administrator has a legitimate need to control access.
  551.  
  552. I do believe, though, that Kermit's /usr/spool/uucp access warnings should be
  553. made preventive.  I believe this for the very reason you (the Info-Kermit
  554. Digest editor) stated in volume 2, number 38:
  555.  
  556.      Assuming that all this can be set up, there still remain ___ major
  557.      problems with line locking:
  558.  
  559.      1. Programs will always appear that do not honor the locking
  560.         conventions, defeating the entire purpose of the locking
  561.         mechanism by simply ignoring it.
  562.  
  563. INFO-KERMIT DIGEST V3 #2                                                 Page 9
  564.  
  565.  
  566. With its current access warnings, C-Kermit is just such a program.
  567.  
  568. ------------------------------
  569.  
  570. Date: Sun, 7 Jul 85 14:53:48 pdt
  571. From: "Scott Weikart; Community Data Processing; 415-322-9069"
  572.  <cdp!scott@Glacier>
  573. Subject: UUCP Line Locking
  574. Keywords: UUCP, C-Kermit
  575.  
  576. Ken Poulton had talked about wanting to have one kermit process open a
  577. circuit, and then have other kermit processes use that same circuit.  His
  578. scheme was to have a kermit exit command that wouldn't close the line.  This
  579. scheme has the problem that people will forget to release the tty.  I had
  580. suggested an alternative scheme of having subsequent kermits run in a
  581. subshell of the kermit that opened the circuit, so that when you tried to
  582. log off you would pop back into the parent kermit and then exit it and
  583. release the line.  I had also suggested that on those systems where
  584. lock-file directories are not accessible by the world, that kermit be run
  585. setgid in a group which has write accesss to the lock-file directory, so
  586. that a) kermit wouldn't have to be setuid and b) the lock file would be
  587. owned by the user account so that subshell kermits could see if their user
  588. owned the tty lock-file.  If people wanted kermit to run setuid, I had
  589. suggested writing the account name into the lock-file, so that subshell
  590. kermits would just read the lock-file to see if their user had reserved the
  591. tty.
  592.  
  593. What follows is a discussion in usenet about a similar problem.  The last
  594. note indicates that Honey Danber UUCP uses a similar scheme: it writes
  595. the process ID (PID) into the lock-file.  So if kermit used this scheme,
  596. a subshell kermit could read the lock-file and see if its contents match
  597. kermit's PPID (parent PID), as gotten by getppid().
  598.  
  599. [Ed. - Kermit actually does write the PID into the lock file, but currently
  600. does not use it for anything.  Note that not all Unix systems have getppid().]
  601.  
  602. >>The problem with tip is that, after locking the modem port, it
  603. >>setuid's back to the original invoker's uid/gid.  This is
  604. >>supposed to patch the security hole surrounding shell escapes
  605. >>and file transfers.  Fine but; alas; it doesn't read /etc/phones...
  606.  
  607.     Another problem this causes involves /usr/spool/uucp security and LCK
  608.     files.
  609.  
  610.     It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as
  611.     this leaves a hole for (admittedly clever) vandalism.
  612.  
  613.     However, with the 4.2BSD version of `tip', this causes the LCK files to
  614.     be left around after `tip' exits, preventing use of the port until
  615.     manual intervention by a "privileged user".
  616.  
  617.     `tip' creates the LCK file while SUID, and no longer has write
  618.     permission in /usr/spool/uucp once it changes the UID.  The LCK
  619.     file therefore remains.
  620.  
  621.  
  622. Page 10                                                INFO-KERMIT DIGEST V3 #2
  623.  
  624.     For binary sites the only "solution" seems to be to leave this
  625.     directory writable.  Yuck.
  626.  
  627.     /+\ Keith F. Pilotti
  628.  
  629.         (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti
  630.         (ARPA) Pilotti@UCSD
  631.  
  632. a possible solution is to follow honey danber's lock file treatment.
  633. assuming tip's lock files have the same format as uucp's, the lock file
  634. contains the pid of the process that created it.
  635.  
  636. write a program that reads the lock file and issues signal 0 to the named
  637. pid.  if the return is 0 or EPERM, the lock file is valid, otherwise it
  638. should be removed.  if binary license is a problem, make tip a shell script
  639. that calls tip, then this program.  i leave the details to your imagination.
  640.  
  641.     peter
  642.  
  643. [Ed. - Let's keep this discussion going until some kind of concensus is
  644. reached.  My concern is that whatever mechanism is settled upon is rational,
  645. humane, simple, installable, maintainable, and explainable.]
  646.  
  647. ------------------------------
  648.  
  649. Date: 7 Jul 85 19:01:41 EDT
  650. From: D. M. Rosenblum <DR01@CMU-CC-TE>
  651. Subject: Running Pro-3xx P/OS Kermit from Tool Kit
  652. Keywords: Pro-3xx P/OS Kermit
  653.  
  654. Users of PRO/Kermit may be interested to know that PRO/Kermit can be run from
  655. PRO/Tool Kit, instead of from the main P/OS menu.  This is useful if you are
  656. in the habit of going directly into PRO/Tool Kit and doing everything from
  657. there.  Here's how to do this.
  658.  
  659. Suppose you have installed PRO/Kermit in a menu on a hard disk system.
  660. KERMIT.TSK will be in a directory of the form [ZZAPnnnnn], where nnnnn is a
  661. system-dependent five-digit number (you will have to do some hunting to find
  662. which such directory KERMIT.TSK is in).  PRO/Tool Kit's START.CMD and
  663. EXIT.CMD files will also be in a directory of the form [ZZAPmmmmm] (where
  664. mmmmm is not equal to nnnnn).  You should APPEND the following lines to
  665. [ZZAPmmmmm]START.CMD, replacing [ZZAPnnnnn] throughout by the name of the
  666. directory in which KERMIT.TSK resides.
  667.  
  668. ;
  669. ;    Install PRO/Kermit Version 1.0
  670. ;
  671. ;    Note that the reference to [ZZAPnnnnn] in the line that installs
  672. ;    KERMIT must be changed if PRO/Kermit is removed from the menus and re-
  673. ;    installed there.
  674. ;
  675.     .DISABLE QUIET
  676.     .IFNINS KERCON INSTALL [ZZKERMIT]KERCMN
  677.     .IFNINS KERCON INSTALL [ZZKERMIT]KERCON/NOREMOVE
  678.     .IFNINS KERFIL INSTALL [ZZKERMIT]KERFIL/NOREMOVE
  679.     .IFNINS KERMIT INSTALL [ZZAPnnnnn]KERMIT
  680.  
  681. INFO-KERMIT DIGEST V3 #2                                                Page 11
  682.  
  683.     .ENABLE QUIET
  684.  
  685. (the PRO DCL indirect command processor has no way of testing to see whether a
  686. common region has been installed, so you have to instead check to see whether
  687. some task, that you're careful to have installed if and only if that common
  688. region is installed, has been installed in order to determine whether the
  689. common region has been installed -- this makes the order of the commands in the
  690. START.CMD file important).
  691.  
  692. You should also append the following lines to [ZZAPmmmmm]EXIT.CMD.
  693. ;
  694. ;    Remove PRO/Kermit Version 1.0
  695. ;
  696. ;    Note that we do not remove KERCON, KERFIL, or KERCMN (which is a
  697. ;    common region), since the first two are normally installed with the
  698. ;    /NOREMOVE option (when Kermit is run from the menu in P/OS), and the
  699. ;    third is not normally removed when Kermit is exited.
  700. ;
  701.     .DISABLE QUIET
  702.     .IFINS KERMIT REMOVE KERMIT
  703.     .ENABLE QUIET
  704.  
  705. If you are on a diskette system, all references to directories [ZZAPmmmmm] and
  706. [ZZAPnnnnn] should be replaced by [ZZAPPL].  Otherwise, as far as I can tell,
  707. the procedure is the same (I don't have access to any diskette-based PROs, so
  708. I can't tell if this really works -- in other words, it's untested).
  709.  
  710. Once you have made these additions to the .CMD files, all that you have to do
  711. in Tool Kit to run PRO/Kermit is issue a RUN KERMIT command.  You will then be
  712. in Kermit's top-level menu, and you may proceed as usual.  When you exit
  713. PRO/Kermit, you will be back in Tool Kit.
  714.  
  715. ------------------------------
  716.  
  717. Date: Wed 3 Jul 85 00:13:21-PDT
  718. From: Bob Larson <BLARSON%ECLD%ECLA@columbia.arpa>
  719. Subject: Bug in Prime Kermit
  720. Keywords: Prime Kermit
  721.  
  722. Testing the new os9 kermit, I found another bug in Prime kermit.  When in
  723. server mode, Prime kermit will Ack an 'R' packet, then send a Send-Init
  724. packet.  According to the protocol manual, it is not suposed to send the
  725. 'Y' (Ack) packet.  I had to modify the os9 kermit to ignore the extra Ack.
  726.  
  727. [Ed. - If Prime Kermit really does this, it's a bug.  I've forwarded Bob's
  728. message to the Prime Kermit authors.]
  729.  
  730. ------------------------------
  731.  
  732. Date:  Wed, 3 Jul 85 21:24 EDT
  733. From:  Frankston@MIT-MULTICS.ARPA
  734. Subject: More about 9600 bps Modem
  735. Keywords: Modem
  736.  
  737. Since a few people are asking me about the modem I mentioned, I will pass on
  738. the information.  This is for informational purposes only and is not a
  739.  
  740. Page 12                                                INFO-KERMIT DIGEST V3 #2
  741.  
  742. comment pro or con:
  743.  
  744. It is the UPTA96 modem from Electronic Vaults, Inc.  Their phone number is
  745. 703-883-0332.  It presents a full duplex interfaces but transmits half duplex
  746. using its own error correcting protocol.  It can drop back to 7200 or 4800
  747. under program control.  It uses either XON/XOFF or CTS/DTR flow control.
  748.  
  749. It is available as a standalone modem or as a board for the IBM PC.  It uses
  750. a standard RJ11 jack.
  751.  
  752. ------------------------------
  753.  
  754. Date: Fri, 5 Jul 85 15:46:22 -0200
  755. From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
  756. Subject: More about PC-Kermit and National Characters
  757. Keywords: MS-DOS Kermit
  758.  
  759. What I had in mind, is what you refer to as SET CHARACTER.  Anyway, the
  760. feature need not include the ability to switch between different font sets in
  761. ROM.  It could be implemented as a simple 256-byte lookup-table.  When ASCII
  762. <xxx> comes in,look it up, and it turns into <yyy> before sending it to the
  763. screen.  One may assume that the National character ROM already is in effect.
  764.  
  765. -fi
  766.  
  767. ------------------------------
  768.  
  769. Date: Tuesday, 2 July 1985  11:43-MDT
  770. From: Dave Shanks <shanks%teneron.uucp@BRL.ARPA>
  771. Subject: Z100 Comunications Program Query
  772. Keywords: Z100 Kermit
  773.  
  774. Does anyone out there know of a good communications program for the
  775. Heath/Zenith H/Z100 under MS-DOS which supports both the serial ports?
  776. I am specifically looking for a program which will allow me to switch
  777. ports on the fly.  It would be nice if the program were in the public
  778. domain, but not necessary.  Thanks in advance.
  779.  
  780. Dave Shanks    ..!tektronix!reed!teneron!shanks
  781. Teneron Corp.
  782. 6700 SW 105th   Suite 200
  783. Beaverton, OR  97005
  784. (503) 646-1599
  785.  
  786. [Ed. - Does anyone have experience using MS-DOS Kermit on the Z100 with
  787. two ports?]
  788.  
  789. ------------------------------
  790.  
  791. Date: Mon, 8 Jul 85 11:56:14 EDT
  792. From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
  793. Subject: Kermit on MicroVAX-1
  794. Keywords: MicroVAX-I
  795.  
  796. Is there any experience with Kermit on the MicroVAX-1?
  797.  
  798.  
  799. INFO-KERMIT DIGEST V3 #2                                                Page 13
  800.  
  801. [Ed. - Comments appreciated, of course, about either VMS or Unix on the
  802. MV-I, or the MV-II for that matter.]
  803.  
  804. ------------------------------
  805.  
  806. End of Info-Kermit Digest
  807.  
  808. Page 14                                                INFO-KERMIT DIGEST V3 #3
  809.  
  810. Info-Kermit Digest         Fri, 12 Jul 1985       Volume 3 : Number  3
  811.  
  812. Departments:
  813.  
  814.   ANNOUNCEMENTS -
  815.     Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
  816.     Commodore-64 Bootstrap Program in Fortran
  817.     Assembling Apple II Kermit (AP2KER) with Apple Assembler?
  818.     New Apple II Cross Assemblers
  819.  
  820.   OLD QUERIES ANSWERED -
  821.     Re: Kermit on MicroVAX-I
  822.     Re: Z100 Communications Program Query
  823.  
  824.   NEW QUERIES -
  825.     IBM 3270/PC and Kermit?
  826.  
  827. ----------------------------------------------------------------------
  828.  
  829. Date: Fri, 12 Jul 85 16:58:22 EDT
  830. From: SY.FDC@CU20B (Frank da Cruz)
  831. Subject: Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
  832. Keywords: C-Kermit, UNIX Kermit, VMS Kermit, MacKermit
  833.  
  834. Yet another release of C-Kermit 4C, this one is 4C(056), for Unix, VAX/VMS,
  835. and the Apple Macintosh.
  836.  
  837. Major differences from 4C(055), affecting all systems:
  838.  
  839. . Various file transfer performance improvements.
  840. . Another bug with 8th-bit-prefixing negotiation fixed.
  841. . Some bugs fixed concerning interrupted file transfers.
  842. . Incoming Z (EOF) packet now ack'd only after file successfully closed.
  843. . Allowance made for ACK to F packet containing alternate file name.
  844. . "Blank lines" in packet stream no longer NAK'd.
  845. . Test for echoed packets fixed.
  846. . Input buffer now flushed only after desired packet is read.
  847. . Many minor fixes and cleanups.
  848.  
  849. Unix and VMS only:
  850.  
  851. . "statistics" and transaction log now include timing information.
  852. . "set incomplete {keep,discard}" is now implemented.
  853. . "show parameters" redesigned and has some inaccuracies fixed.
  854. . "echo" now accepts \ooo octal escapes, e.g. "echo foo\007bar" will now beep.
  855. . "set prompt" now accepts argument in doublequotes to allow blanks.
  856. . Command parser now accepts comment lines starting with "%".
  857. . It is now possible to exit protocol at any time by typing ^A^C^C<CR>.
  858. . Manual chapter updated to reflect above changes.
  859.  
  860. Unix only:
  861.  
  862. . 4.xBSD performance improved by doing nonblocking reads, own buffering
  863.   (Herm Fischer's Sys III/V code adapted to work for BSD).
  864.  
  865. VMS only:
  866.  
  867. INFO-KERMIT DIGEST V3 #3                                                Page 15
  868.  
  869.  
  870. . Version numbers should now be stripped from outbound file names.
  871. . Improved build procedure (CKV*.COM).
  872.  
  873. Macintosh:
  874.  
  875. . No Mac-specific changes were made, but the changes made to the system-
  876.   independent protocol modules should fix a couple problems that reportedly
  877.   prevented all C-Kermits from communicating with systems that send "blank
  878.   lines" between packets, with systems that echo packets, and with Kermits
  879.   that know about 8th-bit prefixing but refuse to do it.  The new Mac Kermit
  880.   release is numbered "0.8(33)".
  881.  
  882. The new release has been tested under 4.2bsd, Pro/Venix V1, and on the
  883. Macintosh against normal systems like DEC-20's and VAXes as well as against
  884. IBM mainframes both in line mode and with full screen 3270 protocol
  885. conversion (thru Series/1).  The VMS version has not been tested (feedback
  886. welcome).
  887.  
  888. Thanks to Larry Afrin, Gary Algier, Todd Booth, Kelvin Nilsen, Ken Poulton,
  889. Dan Schullman, Ed Schwalenberg, and others for reporting problems and/or
  890. suggesting fixes since the last release of C-Kermit 10 days ago.
  891.  
  892. The new files are in K2:CK*.* on CU20B, available via anonymous FTP.
  893. The updates are listed in greater detail in the files K2:CK*.UPD.  The files
  894. K2:CK*.BWR list known bugs and restrictions.  K2:CKUKER.DOC is the new
  895. Kermit User Guide chapter for Unix Kermit (not yet integrated into the
  896. monolithic Kermit User Guide, KER:KUSER.DOC).
  897.  
  898. Since C-Kermit continues to change, it is not recommended that you get these
  899. files unless:
  900.  
  901. (a) You are having problems with your present version that might be fixed
  902.     by the changes listed above;
  903. (b) You are doing development work based on the C-Kermit source (always try
  904.     to work from the latest sources!).
  905.  
  906. It is expected that these new files, along with others recently announced,
  907. will be available via uucp at okstate shortly after okstate comes back up on
  908. July 22 or thereabouts, and will also be available on BITnet via KERMSRV at
  909. CUVMA probably next week.
  910.  
  911. As usual, send comments, suggestions to Info-Kermit@CU20B.
  912.  
  913. ------------------------------
  914.  
  915. Date:      10:23:48 07/11/85 (85.192)
  916. From:      Jeff Balvanz <GM.JLB @ ISUMVS>
  917. Subject:   Commodore-64 Bootstrap Program in Fortran
  918. Keywords: Commodore 64
  919.  
  920. This is a Fortran version of the download program C64BOOT designed to
  921. bootstrap the Commodore-64 version of Kermit from our VAX system.  It should
  922. work with minor modifications with any system running Fortran-77.
  923.  
  924. [Ed. - Thanks, now we have one in each of Fortran, C, Simula, and Clu --
  925.  
  926. Page 16                                                INFO-KERMIT DIGEST V3 #3
  927.  
  928. quite a collection -- in KER:C64BOOT.* (.FOR, .C, .SIM, .CLU; pick your
  929. favorite.)]
  930.  
  931. ------------------------------
  932.  
  933. Date: Fri, 12 Jul 85 08:52:18 MST
  934. From: slesh@FTH-1
  935. Subject: Assembling Apple II Kermit (AP2KER) with Apple Assembler?
  936. Keywords: Apple II DOS Kermit
  937.  
  938.     Assembling and using the Apple Assembler/Editor version of Kermit
  939. is NOT a straightforward proposition.  (The following comments are based
  940. upon as little expertise with Apple 3.3 DOS and the assembler as I could
  941. acquire in the process of getting an Apple DOS Kermit.)  A few of the little
  942. quirks I have discovered THE HARD WAY follow:
  943.  
  944.     1-     if you obtain the source ( ap2ker.asm ) using a
  945.     communications program which runs under another operating system
  946.     and permits text files larger than 32K (e.g. CP/M 80), you will not
  947.     be able to convert the resulting file to an Apple text file without
  948.     splitting it.  My Applicard file conversion utility ADOSXFER
  949.     converted the first 32K all right then went right on cheerfully
  950.     whirring disks and flashing text on the screen.  When I attempted to
  951.     assemble the resulting product there were 81 errors.
  952.  
  953.     2-    the Apple Assembler documentation mentions something about
  954.     'chaining' - "CHN" - but I couldn't get that to work.  What did
  955.     work was naming two source files on the "asm" command line.  I
  956.     couldn't find anything in the documentation to indicate WHY it
  957.     worked.  (The binary file takes the name of the second source file
  958.     named - an undocumented feature of the Apple Assembler?)
  959.  
  960.     3-    the 'ap2ker' version does NOT have some of the features
  961.     documented in the DEC 20 version (e.g. talking to servers, setting
  962.     slots or defining keyboard type).
  963.  
  964.     A little help from anybody out there who really knows what's going
  965. on would be appreciated.
  966.  
  967. [Ed. - AP2KER is a "hand crafted" translation of the original Stevens
  968. Institute of Technology "CROSS" cross-assembler source into Apple assembler,
  969. done by Olaf Pors of the University of Virginia.  It is, indeed, based upon
  970. an older version of Apple Kermit; the CROSS version continued to change
  971. after Olaf contributed this version, and Olaf made a few changes during
  972. translation that may or may not have shown up in the "master copy".  CROSS,
  973. for those who don't know, is a general-purpose cross assembler written in
  974. PDP-10 assembly language (and hence can be run only on DEC-10 and DEC-20
  975. systems).  The input syntax closely resembles PDP-11 Macro assembler,
  976. perhaps because CROSS is based upon MACY11, the DEC-10 PDP-11 cross
  977. assembler.  Unlike MACY11, however, CROSS can generate output for a wide
  978. variety of micros from basically the same input syntax.  But since CROSS
  979. only runs on PDP-10 style processors, these benefits are not widely enjoyed.
  980. To complete the cycle, it would be interesting if someone could write a new
  981. CROSS that accepts PDP-10 Macro-10 for input and produces output in a
  982. variety of formats; then CROSS itself could be CROSS-assembled to form a new
  983. CROSS that could then cross-assemble APPLE.M65 on other machines.  But wait,
  984.  
  985. INFO-KERMIT DIGEST V3 #3                                                Page 17
  986.  
  987. maybe there's a better way ... ]
  988.  
  989. ------------------------------
  990.  
  991. Date:  08 Jul 85 AT 15:37:30
  992. From: Ted Medin <MEDIN-T%cc82@NOSC>
  993. Subject: New Apple II Cross Assemblers
  994. Keywords: Apple II DOS Kermit
  995.  
  996. I have two Apple II cross assemblers written in C.  One can handle the M65
  997. CROSS-format source for Apple II DOS Kermit and the other can handle Apple II
  998. assembler (AP2KER).  These assemblers are available in source asis if any one
  999. wants them; I got them from the net and then hacked them.  I will mail them in
  1000. three parts each as Unix shell archives; cut and execute to produce the files
  1001. which include test cases.  The test cases are the best documentation on what
  1002. the syntax is.
  1003.  
  1004. [Ed. - Thanks!  The files are available in the Kermit-Tools area on CU20B as
  1005. KT:APX*.* (Apple II assembler) and KT:M65*.* (CROSS M65 format), via anonymous
  1006. FTP, along with CROSS which is also still there.]
  1007.  
  1008. ------------------------------
  1009.  
  1010. Date: Wed 10 Jul 85 23:12:09-EDT
  1011. From: Richard Garland <OC.GARLAND@CU20B.ARPA>
  1012. Subject: Re: Kermit on MicroVAX-I
  1013. Keywords: MicroVAX-I Kermit
  1014.  
  1015. Kermit was the first means we used to load stuff into our microVAX-I last
  1016. October under microVMS V1.0.  We down-loaded the Stevens Kermit .HEX file
  1017. (using raw terminal capture with XON/XOFF flow control), did the same with
  1018. the DEHEXIFY Macro source, assembled DEHEXIFY, dehexified KERMIT, and used
  1019. it for weeks getting our applictions down from our VMS VAX 780.  It was a
  1020. mainstay until DECnet over Ethernet got installed.  It was hardwired
  1021. port-to-port at 9600 bpi.  The current version of Kermit works equally well
  1022. with microVMS V4.1
  1023.                     Rg
  1024.  
  1025. ------------------------------
  1026.  
  1027. Date: Wed, 10 Jul 85 09:58:22 cdt
  1028. From: knutson@ut-ngp.ARPA (Jim Knutson)
  1029. Subject: Re: Z100 Communications Program Query
  1030. Keywords: Z100 Kermit
  1031.  
  1032. I had thought long and hard about a way to access both ports when I was
  1033. getting the Z100 version up.  The problem has to do with using the BIOS
  1034. routines for character output.  These only support one AUX device.  To be
  1035. able to use the other serial port, a rewrite of the I/O module would need to
  1036. be done and some interrupt driven I/O routines would have to be written.
  1037. Unfortunately, I don't have the time to do this but it shouldn't be too hard
  1038. if you use the IBM-PC I/O module as an example.
  1039.  
  1040. Jim Knutson
  1041.  
  1042. ------------------------------
  1043.  
  1044. Page 18                                                INFO-KERMIT DIGEST V3 #3
  1045.  
  1046.  
  1047. Date: Fri 12 Jul 85 11:00:54-PDT
  1048. From: Wing Lee <WingLee%ECLD@ECLA>
  1049. Subject: IBM 3270/PC and Kermit?
  1050. Keywords: IBM 3270/PC
  1051.  
  1052. Will the IBM-PC kermit work on an IBM 3270/PC using its RS-232 port?  We
  1053. currently have version 2.26 of IBM-PC Kermit.
  1054.  
  1055. wing lee
  1056.  
  1057. [Ed. - Anybody have experience with this?  My guess is that it would work
  1058. just fine, but have never had any reports either way.]
  1059.  
  1060. ------------------------------
  1061.  
  1062. End of Info-Kermit Digest
  1063.  
  1064. INFO-KERMIT DIGEST V3 #4                                                Page 19
  1065.  
  1066. Info-Kermit Digest         Mon, 15 Jul 1985       Volume 3 : Number  4
  1067.  
  1068.                  Kermit Protocol Extension Proposals
  1069.                  Proposal for Extended Packet Lengths
  1070.  
  1071. ----------------------------------------------------------------------
  1072.  
  1073. Date: Mon 15 Jul 85 16:12:15-EDT
  1074. From: Frank da Cruz <SY.FDC@CU20B>
  1075. Subject: Kermit Protocol Extension Proposals
  1076. To: Info-Kermit@CU20B.ARPA
  1077. Keywords: Kermit Protocol
  1078.  
  1079. This week, two new extensions to the Kermit file transfer protocol will be
  1080. proposed.  Both address one of Kermit's weakest areas: performance.  Both
  1081. extensions are designed to allow extended Kermits to work transparently with
  1082. older Kermit programs that are ignorant of the extension; this has always
  1083. been the rule for extensions added to the protocol.
  1084.  
  1085. The two extensions are:
  1086.  
  1087. 1. Longer packets.
  1088.  
  1089. 2. Continuous transmission of packets in a "sliding window".
  1090.  
  1091. As originally designed, Kermit is a "stop and wait" protocol; each packet has
  1092. to be acknowledged before the next one is sent.  A Kermit packet includes a
  1093. single-byte length field expressed as a printable ASCII character, limiting
  1094. the packet length to 94.  The original design has been quite effective for
  1095. several reasons:
  1096.  
  1097.    a. Kermit programs are simple to write.
  1098.  
  1099.    b. The restriction on packet length guaranteed that Kermit would work on
  1100.       practically every system, including the many whose terminal input buffers
  1101.       cannot tolerate long bursts of input.
  1102.  
  1103.    c. The stop-and-wait strategy gives the operating system time to consolidate
  1104.       its input buffers.
  1105.  
  1106. As Kermit grows in popularity, it has found use in situations where its basic
  1107. design results in poor performance.  Two examples:
  1108.  
  1109.    a. Connections with built-in delays, like public networks or satellite
  1110.       links.  Unlike direct or dialup connections, these connections do not
  1111.       have a dedicated channel; response varies with the current load on the
  1112.       medium, and also with the "diameter" of the network.  Delays can slow
  1113.       down the performance or stop it all together if they exceed Kermit's
  1114.       timeout parameters.
  1115.  
  1116.    b. Direct, clean connections, to systems with big input buffers.  When
  1117.       the error rate is very low, throughput is unreasonably impeded by
  1118.       stop-and-wait for short packets.
  1119.  
  1120. At first glance, it would seem that a single solution could address both
  1121. situations.  First, note that any performance extension must require the
  1122.  
  1123. Page 20                                                INFO-KERMIT DIGEST V3 #4
  1124.  
  1125. receiver of a file to have big input buffers (and since many many systems
  1126. don't, any extensions will have to be negotiable).  The question is whether to
  1127. send one long packet or a bunch of short packets end-to-end (or both).
  1128.  
  1129. Assuming that each packet must be acknowledged, the advantage would seem to
  1130. go to long packets, since fewer acks would be required per unit data.  But
  1131. when errors occur the amount of data to be retransmitted is less with short
  1132. packets, so a sliding window with short packets would be better in a
  1133. potentially noisy environment.  But sliding windows work best on a full
  1134. duplex communication channel, which certain key systems do not provide.
  1135.  
  1136. It is still possible to do packet windowing on half-duplex connections, but
  1137. in this case the windows lurch rather than slide -- a batch of packets can be
  1138. sent, responded to by a batch of ACKs and NAKs.
  1139.  
  1140. Some random observations:
  1141.  
  1142. Longer packets are simpler to specify and program.
  1143.  
  1144. Windowing is harder to specify and program, and for true full duplex operation
  1145. also requires either multiprocessing (e.g.  separate input and output forks) or
  1146. else interrupt-driven i/o.
  1147.  
  1148. Long packets need a rigorous error-detection mechanism like the 16-bit CRC.
  1149. The normal 6-bit checksum just won't do.  Windowing with short packets, on the
  1150. other hand, should work well even with short block checks.
  1151.  
  1152. Currently during initial connection, two present-day Kermits tell each other
  1153. the longest packet they are prepared to accept, up to the maximum of 94.
  1154. Each computer bases this number on some knowledge about its input buffers.
  1155. But there are also external factors which may be unknown to the computers;
  1156. for instance, the connection has been made through a public packet-switched
  1157. network or a local area network whose interface devices might have smaller
  1158. buffers than the computers themselves.  These factors have rarely interfered
  1159. with original ("classic"?) Kermit, because even its biggest packets are
  1160. acceptable to most of these devices.  But if Kermit is extended to allow
  1161. transmission of much longer bursts of continuous data, all bets are off.  The
  1162. burden will shift to the (often naive) user to understand the communications
  1163. environment enough to elect the best parameters and options.
  1164.  
  1165. The biq question is:  Are the benefits in performance worth the cost in
  1166. complexity for specification, programming, and "user education"?  Especially
  1167. in view of the likelihood that even if adopted, the extensions will
  1168. probably not be made to more than a few of the existing Kermit programs.
  1169.  
  1170. Assuming extension is desirable, which extension should be made: long packets,
  1171. sliding windows, or both?
  1172.  
  1173. The first proposal follows.  The next one will appear in a forthcoming
  1174. Info-Kermit (most likely the next one).  By the way, it should be noted that
  1175. long packets and windowing should probably be mutually exclusive, since the
  1176. proposal for windowing (in its present form) expresses window sizes in numbers
  1177. of packets, assuming the current maximum length.
  1178.  
  1179. ------------------------------
  1180.  
  1181.  
  1182. INFO-KERMIT DIGEST V3 #4                                                Page 21
  1183.  
  1184. Date: Mon 15 Jul 85 16:12:44-EDT
  1185. From: Frank da Cruz <SY.FDC@CU20B>
  1186. Subject: Proposal for Extended Packet Lengths
  1187. To: Info-Kermit@CU20B.ARPA
  1188. Keywords: Long Packets
  1189.  
  1190. A method is proposed to allow the formation of long Kermit packets.
  1191. Questions as to the desirability or appropriateness of this extension to the
  1192. Kermit protocol are not addressed.  All numbers are in decimal (base 10)
  1193. notation, all arithmetic is integer arithmetic.
  1194.  
  1195. In order for long packets to be exchanged, the sender must set the LONGP bit
  1196. in the CAPAS field of the Send-Init (S or I) packet, and also furnish the
  1197. MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as follows (the value for
  1198. the LONGP bit and the position of the MAXLX1,MAXLX2 fields have not yet been
  1199. settled):
  1200.  
  1201.     ---+-------+-     -+--------+--------+
  1202.        | CAPAS |  ...  | MAXLX1 | MAXLX2 |
  1203.     ---+-------+-     -+--------+--------+
  1204.  
  1205. where MAXLX1 and MAXLX2 are each a printable ASCII character in the range SP
  1206. (space, ASCII 32) to ~ (tilde, ASCII 126), formed as follows:
  1207.  
  1208.     MAXL1 = char(m / 95)
  1209.     MAXL2 = char(m MOD 95)
  1210.  
  1211.     (where m is the intended maximum length),
  1212.  
  1213. to indicate the longest extended-length packet it will accept as input.  The
  1214. receiver responds with an ACK packet having the same bit also set in the CAPAS
  1215. field, and with the MAXLX1 and MAXLX2 fields set to indicate the maximum length
  1216. packet it will accept.
  1217.  
  1218. The maximum length expressible by this construct is 95 x 94 + 94, or 9024.
  1219.  
  1220. Since the sender can not know in advance whether the receiver is capable of
  1221. extended headers, the Send-Init MAXL field must also be set in the normal
  1222. manner for compatibility.
  1223.  
  1224. If the receiver responds favorably to an extended-length packet bid (that is,
  1225. if its ACK has the LONGP bit set in the CAPAS field), then the combined value
  1226. of its MAXLX1,MAXLX2 fields is used.  If the the LONGP bit is set but
  1227. MAXL1,MAXL2 is missing, then the value 500 will be used by default.
  1228.  
  1229. If it responds unfavorably (the LONGP bit is not set in the CAPAS field),
  1230. then extended headers will not be used and the MAXL field will supply the
  1231. maximum packet length.
  1232.  
  1233. After the Send-Init has been sent and acknowledged with agreement to allow
  1234. extended headers, all packets up to and including the B or E packet which
  1235. terminates the transaction (and its acknowledgement) are allowed -- but not
  1236. required -- to have extended headers; extended and normal packets may be freely
  1237. mixed by both Kermits.
  1238.  
  1239. The normal Kermit packet length field (LEN) specifies the number of bytes
  1240.  
  1241. Page 22                                                INFO-KERMIT DIGEST V3 #4
  1242.  
  1243. to follow, up to and including the block check.  Since at least 3 bytes must
  1244. follow (SEQ, TYPE, and CHECK), a value of 0, 1, or 2 is never encountered
  1245. in the LEN field of a valid unextended Kermit packet.  When extended packets
  1246. have been negotiated, the LEN field is treated as follows for the duration of
  1247. the transaction:
  1248.  
  1249.     If unchar(LEN) > 2 then the packet is a normal, unextended packet.
  1250.     If unchar(LEN) = 0 then the packet has a "Type 0" extended header.
  1251.     If unchar(LEN) = 1 or 2, the packet is invalid and should evoke an Error.
  1252.  
  1253. "Lengths" of 1 and 2 are reserved for future use in Type 1 and 2 extended
  1254. headers, yet to be specified.
  1255.  
  1256. A Type 0 extended packet has the following layout:
  1257.  
  1258. +------+-----+-----+------+-------+-------+--------+----       ----+-------+
  1259. | MARK |     | SEQ | TYPE | LENX1 | LENX2 | HCHECK |  DATA ....    | CHECK |
  1260. +------+-----+-----+------+-------+-------+--------+----       ----+-------+
  1261.                           | Extended Header        |
  1262.  
  1263.  
  1264. The blank length field (SP = char(0)) indicates that the first 3 bytes of
  1265. what is normally the data field is now an extended header of Type 0, in which
  1266. the number of bytes remaining in the packet, up to and including the block
  1267. check, is
  1268.  
  1269.     extended-length = (95 x unchar(LENX2)) + unchar(LENX2)
  1270.  
  1271. and HCHECK is a header checksum, formed exactly like a Type-1 Kermit block
  1272. check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and
  1273. LENX2 fields:
  1274.  
  1275.      s = SEQ + TYPE + LENX1 + LENX2
  1276.  
  1277.      HCHECK = char((s + ((s AND 192)/64)) and 63)
  1278.  
  1279. Since the value of the extended length field must be known accurately in
  1280. order to locate the end of the packet and the packet block check, it is
  1281. vital that this information not be corrupted before it is used.  The header
  1282. checksum prevents this.
  1283.  
  1284. The extended header, like the normal header itself, is NOT prefix-encoded.
  1285. This implies that the entity responsible for building packets must leave 3
  1286. spaces at the beginning of the data field, form the rest of the packet
  1287. (encode the data), and then go back and fill in LENX1, LENX2, and HCHECK
  1288. based upon the data actually entered into the packet, after encoding.
  1289. Similarly, the packet receiver must allow the extended header to be treated
  1290. as prefix-encoded data.
  1291.  
  1292. The packet block check is formed in the usual manner, based on all packet bytes
  1293. beginning with LEN and ending with the last character in the data field.  The
  1294. block check may be Type 1, 2, or 3, depending upon what was negotiated, but
  1295. longer packets are more likely to be corrupted than shorter ones and should
  1296. therefore have higher-order block checks if possible.  This proposal does not
  1297. change the way block check type is negotiated, and does not require that Type
  1298. 2 or 3 block check be implemented.
  1299.  
  1300. INFO-KERMIT DIGEST V3 #4                                                Page 23
  1301.  
  1302.  
  1303. ------------------------------
  1304.  
  1305. End of Info-Kermit Digest
  1306.  
  1307. Page 24                                                INFO-KERMIT DIGEST V3 #5
  1308.  
  1309. Info-Kermit Digest         Thu, 18 Jul 1985       Volume 3 : Number  5
  1310.  
  1311. Departments:
  1312.  
  1313.   KERMIT PROTOCOL EXTENSIONS -
  1314.     Kermit Extension Proposal Feedback
  1315.     Re: Proposals
  1316.     Checksum versus CRC
  1317.     Kermit Extensions
  1318.     Kermit Extended Packet Lengths Proposal
  1319.     Kermit Protocol Enhancements
  1320.     New vs Classic Kermit
  1321.  
  1322.   MISCELLANY -
  1323.     Re: IBM 3270/PC and Kermit
  1324.     RSX Kermit Warning
  1325.     Kermit for Mac L Running Unix
  1326.     Terminal Emulator w/Kermit:  Beta-test Site Query
  1327.     MS-Kermit 2.26 and Hercules Graphik Card
  1328.  
  1329. ----------------------------------------------------------------------
  1330.  
  1331. Date: Thu 18 Jul 85 19:09:55-EDT
  1332. From: Frank da Cruz <SY.FDC@CU20B>
  1333. Subject: Kermit Extension Proposal Feedback
  1334. Keywords: Kermit Protocol Proposal
  1335.  
  1336. The following messages are in response to the first Kermit extension
  1337. proposal, presented without comment.  The second proposal (sliding windows,
  1338. an effort which is being coordinated by people at The SOURCE Telecomputing)
  1339. is not quite ready yet, but should appear shortly.  If you sent a response
  1340. that doesn't appear below, send it again -- we lost our file system on CU20B
  1341. last night and some messages may have been lost.
  1342.  
  1343. ------------------------------
  1344.  
  1345. Date: Tue, 16 Jul 85 02:12:32 pdt
  1346. From: Scott Weikart <cdp!scott@Glacier>
  1347. Subject: Re: Proposals
  1348. Keywords: Kermit Protocol Proposal, Sliding Window Kermit, Long Packets
  1349.  
  1350. I would definitely like to have either sliding window protocol or long
  1351. buffers, but I'm not sure which one (or if I need both).  We're working with
  1352. some other non-profits to setup long-distance telecommunications between UN*X
  1353. and MS-DOS machines, and would like to use kermit as our transport mechanism,
  1354. but we're worried about kermit efficiency with long round-trip times (eg
  1355. packet-switched networks) or long-distance high-speed modem connections.  The
  1356. packet-networks should be error- corrected so that long packets would seem to
  1357. make sense, but I don't know if you'll get hing up by buffer sizes in the
  1358. network (the nets I'm thinking of are Uninet, and maybe Tymnet or Telenet).
  1359. We may also be using some of the new high-speed pseudo-full-duplex modems,
  1360. and I don't know enough about their error rates or buffer size factors
  1361. either; if it's error rate is high and and it doesn't do partition a block
  1362. and use its own sliding window protocol, it might be good to use half-duplex
  1363. lurching window with small packets.
  1364.  
  1365.  
  1366. INFO-KERMIT DIGEST V3 #5                                                Page 25
  1367.  
  1368. I'm not so worried that many/most kermits won't be able to handle either
  1369. extension.  For people like us who are interested in using kermit for the
  1370. transport mechanism of sophisticated telecommunications services, probably
  1371. only the more capable machines will be considered as part of the system
  1372. (although one may argue that an MS-DOS machine is not very capable).
  1373.  
  1374. As for user education about large packets, people could maybe implement an
  1375. adaptive mode that would try a 1/3 or 1/2 smaller packet each time a
  1376. transport media truncated a packet.  But that's more hairiness.
  1377.  
  1378. ------------------------------
  1379.  
  1380. Date: 15 Jul 1985 1941-EDT
  1381. From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
  1382. Subject: Checksum versus CRC
  1383. Keywords: Kermit Protocol Proposal, Checksums
  1384.  
  1385. I haven't seen a single clear review of the above - I STILL BELIEVE THAT
  1386. Checksumming of mostly analog based circuits is SUPERIOUR. CRC [ and all
  1387. quasi-mathematical "analysises" assume BIT-drops] is SUPERIOUR in catching
  1388. missing BITS [one typically can be "reconstructed" depending on the "polynom"
  1389. - two or [sometimes more] can be "detected". CHecksumming is good for
  1390. "detecting" single-bit changes [no chance to "reconstruct" - since the
  1391. position of the "change" is not known - and [obviously.. only a 50% chance to
  1392. "catch" double-bit errors].... HOWEVER - and here lays the "settle"
  1393. difference -- ANALOG CIRCUITS TEND NOT TO DROP BITS - THEY DROP MINIMALLY
  1394. WORDS and TYPICALLY "SENTENCES" -- AND CHECKSUMMING HAS A HIGH CHANCE TO
  1395. "catch" these DROPS or MODIFICATIONS - since typically [on ANALOG CIRCUITS]
  1396. FULL [either ON- or OFF-Bit sequences are substituted] -- this [by the way]
  1397. also explains my long-standing objection to CRC-protocol in MODEM
  1398. [acknowledged by the experience - that ON "BAD" lines switching from
  1399. CHECKSUMMED PROTOCOL to CRC-PROTOCOL DOESN't make a "bit of a difference". -
  1400. Yeah, I know; there's an even more serious flaw in MODEM- protocol - in that
  1401. ACK/NAK msgs are NOT encased into "message-protocol" and thereby on a "bad"
  1402. line MODEM looses typically in ACK/NAK traffic.]
  1403.  
  1404. Let me clarify [after re-reading] the above SUPERIOUR - it summs up the
  1405. "expended CPU-time {and number of program instructions}" - as compared to the
  1406. achieved results {I.e. probability to detect an ERROR}.
  1407.  
  1408. Rgds,
  1409. Bernie.
  1410.  
  1411. ------------------------------
  1412.  
  1413. Date: Tue 16 Jul 85 21:07:07-EDT
  1414. From: Richard Garland <OC.GARLAND@CU20B.ARPA>
  1415. Subject: Kermit Extensions
  1416. Keywords: Kermit Protocol Proposal, Long Packets
  1417.  
  1418. I perked my ears up at one statement in your introduction to the extensions
  1419. you outlined:  "Each packet must be ACKed" and you even gave an example of
  1420. a half duplex "lurching" window where a bunch of packets are sent and then
  1421. a bunch of ACKs are returned.
  1422.  
  1423. I would suggest two ideas for ACKs that DECnet uses:
  1424.  
  1425. Page 26                                                INFO-KERMIT DIGEST V3 #5
  1426.  
  1427.  
  1428.     o  ACKing only the last good packet and
  1429.     o  piggyback ACKing.
  1430.  
  1431. In the first case if, packets 9, 10, 11, and 12 are sent successfully, the
  1432. receiver ACKs 12 and this *implies* 9, 10, and 11 were also good.  If 9, and
  1433. 10 were good and 11 was bad on the other hand, the receiver NACKs 11, and
  1434. this implies 11 is bad, but 9 and 10 were good.  Then the sender resends
  1435. starting at 11.  This scheme allows a lot less reverse traffic.  Usually
  1436. there is a limit on the number of packets that will be sent before getting
  1437. some ACK but that is the sliding window protocol which you are working out
  1438. and I won't bother about that part of it. (DECnet uses about 3 versions of
  1439. it).
  1440.  
  1441. piggyback ACKing simply means that an ACK or a NAK can be combined with
  1442. another packet going in the right direction and is relavent for full duplex
  1443. data streams.  Perhaps Kermit will never have full duplex data (as opposed
  1444. to packets) so this idea may be irrelavent.  But if on the other hand you
  1445. want to send a bunch of packets, then send an END packet, a type of
  1446. piggybacking would allow the receiver to ACK the last n packets and the END
  1447. packet all at once.
  1448.  
  1449. By the way, I don't think sliding windows and large packet extension ideas
  1450. are mutually exclusive ways to improve performance.
  1451.  
  1452. ------------------------------
  1453.  
  1454. Date: Tue, 16 Jul 85 20:24:42 PDT
  1455. From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA
  1456. Subject: Kermit extended packet lengths proposal
  1457. Keywords: Kermit Protocol Proposal, Long Packets
  1458.  
  1459. Overall this looks pretty good, but I'd recommend a couple of small changes:
  1460.  
  1461. 1. Change the extended length specification to be simply 12 bits transmitted
  1462.    the same way as the 2-byte checksum. This limits the maximum packet size
  1463.    to 4096 bytes, but that is plenty when the best checksum is CRC-CCITT.
  1464.    It is also as big as any host's usual input buffer as far as I know.
  1465.  
  1466. 2. Include the LEN byte in the header checksum so that both checksums start
  1467.    at the same byte. Having the header one start 1 byte later than the packet
  1468.    one doesn't make any sense and will confuse the implementator.
  1469.  
  1470. I believe that the last sentence of the second-to-last paragraph is missing a
  1471. "NOT". As it stands, it contradicts the first sentence of the same paragraph.
  1472. (That is the paragraph about the extended header not being prefix-encoded.)
  1473.  
  1474. Finally, I think there is a small bug in the advanced state table shown in
  1475. the 3 April 84 protocol manual (there may be a newer one but that is the
  1476. newest I have). The Send_Gen_Cmd state should allow for receiving an F packet
  1477. in the case that it was entered from the Send_Server_Init state and sent a R
  1478. command. That is because the server will, I expect, conclude that it doesn't
  1479. need to send a S(0) because of receiving and Acking the I(0). (I haven't
  1480. tried this with a server to be sure, but the Rec_Server_Idle state
  1481. description sure implies to me that is how the server will work.)
  1482.  
  1483.  
  1484. INFO-KERMIT DIGEST V3 #5                                                Page 27
  1485.  
  1486. ------------------------------
  1487.  
  1488. Date: July 17, 1985, 09:15 CEST
  1489. FROM:  <#D15%DDATHD21.BITNET@WISCVM.ARPA>
  1490. Subject: Kermit Protocol Enhancements
  1491. Keywords: Kermit Protocol Proposal
  1492.  
  1493. Hi,
  1494.  I hope my questions are not too late for this stage of the
  1495. discussion.
  1496.  1.) which kind of systems would be able to use the large
  1497.      packets?
  1498.  2.) which kind of systems can afford (pgm size, complexity)
  1499.      the necessary changes to the software?
  1500.  3.) how does the proposal fit the rules of the early days
  1501.      of Kermit development (to have a simple, cheap to implement
  1502.      protocol for connecting especially small systems)?
  1503.  4.) where are the ends, or in other words, wouldn't it be better
  1504.      to develop a new protocol with enhanced performance (e.g
  1505.      larger packet, high speed lines, parallel activities on the
  1506.      lines)?
  1507.  
  1508. Martin Knoblauch
  1509. TH-Darmstadt, D-6100 Darmstadt, West Germany
  1510. EARN/BITNET: #D15 at DDATHD21 (the number sign is really part of my UID)
  1511.  
  1512. ------------------------------
  1513.  
  1514. Date: 17 JUL 85 09:34-EST
  1515. From:  BRIAN%UOFT02.BITNET@WISCVM.ARPA
  1516. Subject: New vs Classic Kermit
  1517. Keywords: Kermit Protocol Proposal
  1518.  
  1519. The proposals for large packets (and likely sliding windows) are not going to
  1520. work out well on pdp-11's as the buffers in all the execs are fairly small,
  1521. ranging from a max of 36 for rsx, 255 for rsx11m+, 140 for rt, ??? for p/os,
  1522. and max of about 500 for rsts/e (depending on available small buffer pool).
  1523. Thus xon/xoff would come into play rather soon.  Of course, xonxoff control
  1524. is no better (much worse,really) that send/ack for each packet.
  1525.  
  1526. ------------------------------
  1527.  
  1528. Date: Mon, 15 Jul 85 12:42:33 edt
  1529. From: Paul Placeway <paul%ohio-state.csnet@csnet-relay.arpa>
  1530. Subject: Re: IBM 3270/PC and Kermit
  1531. Keywords: IBM 3270/PC
  1532.  
  1533. We have been running kermit for IBM PCs and clones for 6 months on our 3270
  1534. PC with no problems whatsoever.  We run a 9600 baud line between the 3270 PC
  1535. and our Vax to do file transfers (9600 is very nice, but the Unix version is
  1536. too slow (no, we havn't gotten the latest version of Unix kermit)).  I have
  1537. one suggestion, however: get a normal PC keyboard for your 3270 PC.  The
  1538. position of ESC, Control, and some other keys is a PAIN.
  1539.  
  1540.                 Paul Placeway
  1541.                 OSU CIS Dept. Lab
  1542.  
  1543. Page 28                                                INFO-KERMIT DIGEST V3 #5
  1544.  
  1545.                 ...!cbosgd!osu-eddie!paul
  1546.                 paul@ohio-state  (CSNet)
  1547.  
  1548. ------------------------------
  1549.  
  1550. Date: 16 JUL 85 09:28-EST
  1551. From:  BRIAN%UOFT02.BITNET@WISCVM.ARPA
  1552. Subject: RSX Kermit Warning
  1553. Keywords: Kermit-11, RSX Kermit
  1554.  
  1555. A problem with RSX Kermit-11 has been  resolved  in  that  the  outgoing
  1556. line  (via  SET  LINE) must NOT have the /RPA setting enabled (read pass
  1557. all). If set, it must be disabled via  the  mcr  command  SET/NORPA=TTn:
  1558. The  characteristic is not one that would be normally set. The effect of
  1559. having it set is to force the terminal driver to pass all  flow  control
  1560. (xon   and   xoff)  characters  directly  to  Kermit,  which  is  highly
  1561. undesirable. The call to disable /RPA will be added to Kermit-11  source
  1562. in the future.
  1563.  
  1564. ------------------------------
  1565.  
  1566. Date:  Tue, 16-JUL-1985 08:55 EDT
  1567. From:    Ronald A. Jarrell  <JARRELLRA%VPIVAX5.BITNET@WISCVM.ARPA>
  1568. Subject:  Kermit for Mac L Running Unix
  1569. Keywords: MacKermit
  1570.  
  1571. Our CS department is going to be having all incoming freshman purchasing
  1572. Macintosh-L's with Unipres System V.  Has anyone tested, or suspects that
  1573. one of the flavors of kermit will work under that combination?  We plan on
  1574. setting up some semi-automated software for file transfer for them, and the
  1575. most desirable alternative would be for them to connect to a VMS Vax that
  1576. has Kermit on it.
  1577.  
  1578. -Ron Jarrell
  1579.  Systems Programming Dept,
  1580.  Va Tech
  1581.  
  1582. ------------------------------
  1583.  
  1584. 17-Jul-85 11:36:50-EDT,869;000000000001
  1585. Mail-From: EXT1.FUCHS created at 17-Jul-85 11:36:47
  1586. Date: Wed 17 Jul 85 11:36:46-EDT
  1587. From: Michael Fuchs <EXT1.FUCHS@CU20B.ARPA>
  1588. Subject: Terminal Emulator w/Kermit:  Beta-test Site Query
  1589. To: info-kermit@CU20B.ARPA
  1590. Keywords: Terminal Emulation
  1591.  
  1592. Would anyone in net.land be interested in beta-testing the latest release
  1593. of a commercial terminal emulator (full VT102) for the IBM PC incorporating
  1594. a complete implementation of Kermit?
  1595.  
  1596. Features include:
  1597.  
  1598.     * Kermit including CRC, server commands, etc.
  1599.     * XMODEM, Proprietary protocols with host software provided
  1600.     * Software (and hardware) 132 column support
  1601.  
  1602. INFO-KERMIT DIGEST V3 #5                                                Page 29
  1603.  
  1604.     * Scrolled-off screens capture buffer (80 screens' worth)
  1605.     * Terminate-stay-resident Hot key feature
  1606.     * Programmable softkeys
  1607.  
  1608. Anyone interested please contact me through net mail or at 212-777-6707.
  1609.  
  1610. Michael Fuchs
  1611. Coefficient Systems Corp.
  1612.  
  1613. ------------------------------
  1614.  
  1615. Date: Thu 18 7 85 23:30 GMT
  1616. From: Eberhard W. Lisse <zdv626@djukfa11.bitnet>
  1617. Subject: MS-Kermit 2.26 and Hercules Graphik Card
  1618. Keywords: MS-DOS Kermit, Hercules Card
  1619.  
  1620. Have you heard of any problems caused by the Hercules monochrome graphik card
  1621. on an XT DOS 2.11 ?
  1622.  
  1623. Since they installed it on our XT, Kermit does not connect any more.
  1624.  
  1625. [Ed. - Can anyone help?]
  1626.  
  1627. ------------------------------
  1628.  
  1629. End of Info-Kermit Digest
  1630.  
  1631. Page 30                                                INFO-KERMIT DIGEST V3 #6
  1632.  
  1633. Info-Kermit Digest         Mon, 22 Jul 1985       Volume 3 : Number  6
  1634.  
  1635. Departments:
  1636.  
  1637.   ANNOUNCEMENTS -
  1638.     Kermit-11 User Manual
  1639.     Kermit Distribution Updated on Okstate
  1640.  
  1641.   MISCELLANY -
  1642.     Long Packets and Sliding Windows
  1643.     Kermit Problem with Z100 MS-DOS2 Solved
  1644.     MacKermit 0.8, UNIX C-Kermit Problems
  1645.     Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
  1646.     MS-DOS Kermit vs Professional Graphics Adapter?
  1647.  
  1648. ----------------------------------------------------------------------
  1649.  
  1650. Date:     Thu, 18-JUL-1985 16:53 EST
  1651. From:     <BRIAN@UOFT02>
  1652. Subject:  Kermit-11 User Manual
  1653. Keywords: Kermit-11
  1654.  
  1655. I will send two files, K11USR.DOC and .RNO, to you after this; this is the
  1656. Kermit-11 User Manual, shaped like a Kermit User Guide chapter but written
  1657. using Runoff rather than Scribe.  You folks can do with them what you may,
  1658. though they should be placed with the rest of the k11 files on cuvma, cu20b,
  1659. and your vax that you make the tapes on.
  1660.  
  1661. [Ed. - The files are installed with the other K11 files in K2:K11USR.* on
  1662. CU20B, and on CUVMA for KERMSRV.  Thanks, Brian! ]
  1663.  
  1664. ------------------------------
  1665.  
  1666. Date: 20 Jul 85 00:23:32 CDT (Sat)
  1667. From: vasoll%okstate.csnet@csnet-relay.arpa
  1668. Subject: Kermit Distribution Updated on Okstate
  1669. Keywords: Okstate
  1670.  
  1671. I have received and installed the latest Kermit tapes (thanks for sending
  1672. them) on our system.  I have moved the distribution area into a more
  1673. "normal" location (/usr/spool/uucppublic) on our system and I have split it
  1674. into two areas, one for each tape.  The area that was generated from TAPE A
  1675. (the micro Kermits) is called /usr/spool/uucppublic/kermit-a and the area
  1676. that was generated from TAPE B (the mainframe Kermits) is called
  1677. /usr/spool/uucppublic/kermit-b.
  1678.  
  1679. The default directory for our "kermsrv" login will be changed to
  1680. /usr/spool/uucppublic/kermit-a and users will be allowed to CWD to
  1681. /usr/spool/uucppublic/kermit-b.  UUCP users will just have to specify the
  1682. full path (although ~uucp/kermit-a and ~uucp/kermit-b should also work on
  1683. most systems...).  To summarize:
  1684.  
  1685.  -  The files that were on TAPE A are in /usr/spool/uucppublic/kermit-a/*
  1686.  
  1687.  -  The files that were on TAPE B are in /usr/spool/uucppublic/kermit-b/*
  1688.  
  1689.  
  1690. INFO-KERMIT DIGEST V3 #6                                                Page 31
  1691.  
  1692.  -  The Kermit server login "kermsrv" has been modified to use the kermit-a
  1693.     area as its default directory and
  1694.  
  1695.     REMOTE CWD /usr/spool/uucppublic/kermit-b
  1696.  
  1697.     will take you to the other area.  For those systems not supporting
  1698.     REMOTE commands, the server will also accept full pathnames in GET
  1699.     requests.
  1700.  
  1701. Mark
  1702.  
  1703. [Ed. - Thanks Mark, and thanks again for providing this service.]
  1704.  
  1705. ------------------------------
  1706.  
  1707. Date: Fri, 19 Jul 85 09:19:04 EDT
  1708. From: Brian_Borchers%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
  1709. Subject: Long Packets and Sliding Windows
  1710. Keywords: Sliding Windows Kermit, Long Packets
  1711.  
  1712. We use Kermit here for host to host transfers over Telenet and Datapac, and
  1713. the long packet extension seems ideal for this purpose.
  1714.  
  1715. Unfortunately, our operating system (MTS) doesn't really allow asynchronous
  1716. reads, which might cause problems with a sliding window scheme.  I'm
  1717. interested in seeing the actual proposal.
  1718.  
  1719. [Ed. - It will appear in the next digest.]
  1720.  
  1721. ------------------------------
  1722.  
  1723. Date: Fri, 19 Jul 85 10:17:49 PDT
  1724. From: klee@sri-spam (Ken Lee)
  1725. Subject: Kermit Problem with Z100 MS-DOS2 Solved
  1726. Keywords: Z100 Kermit
  1727.     
  1728. Thanks to all those who responed to my request for help with Kermit on
  1729. MS-DOS2.  My version of Kermit worked fine on ZDOS, but failed when I
  1730. tried to use it with DOS2.  Apparently, DOS2 causes the Z100 to drop
  1731. the data terminal ready (DTR) signal to the modem when Kermit attempts
  1732. to receive a file.  The modem interpets this as a signal to quit and
  1733. drops the telephone line.  By optioning the modem to ignore the DTR
  1734. signal from the Z100, I now have kermit working properly.
  1735.     
  1736. Ken Lee
  1737.     
  1738. [Ed. - Thanks for the pointer; I've placed it in MSZ100.BWR so others can
  1739. benefit from it.]
  1740.  
  1741. ------------------------------
  1742.  
  1743. Date: Sun, 21 Jul 85 12:24:17 pdt
  1744. From: westjw%frog@Nosc (Joel West c/o NOSC San Diego)
  1745. Organization: CACI, Inc. (home of SIMSCRIPT II.5)
  1746. Subject: MacKermit 0.8, UNIX C-Kermit Problems
  1747. Keywords: MacKermit, C-Kermit, UNIX Kermit
  1748.  
  1749. Page 32                                                INFO-KERMIT DIGEST V3 #6
  1750.  
  1751.  
  1752. Before I nit-pick, I'd like to say how much I like the keymap program, even
  1753. if it was only designed for EMACS hackers. :-) I've chosen the assignment
  1754. BS=^H; Shift-BS=DEL; Ctl-BS, Enter=<esc>; although I may change this for vi
  1755. later.  (in BSD, you use ~ and ` a lot, and the Ctl-Shift-~ of MacTerminal
  1756. is a real pain).
  1757.  
  1758. [Ed. - Of course, you can have as many different settings files as you like;
  1759. just double-click the one you want to start up Kermit with the appropriate
  1760. settings and key map.]
  1761.  
  1762. Two problems with MacKermit:
  1763.  
  1764.     #1  files never go into folders, always desktop.  This must
  1765.     be a "feature", since it's easier to default the file to
  1766.     the disk (FlFldr=0) than to the desktop (FlFldr=-2)
  1767.  
  1768. [Ed. - Like it says in the manual, they go into whatever folder the settings
  1769. file was in that you started Kermit from, otherwise on the desktop.]
  1770.  
  1771.     #2    if you receive a file (interactive), toggle disk drives
  1772.     and insert a new disk, it bombs during initialization.
  1773.     The only time this happened was using RAM Disk "RamStart"
  1774.     off of net.sources.mac.
  1775.  
  1776. [Ed. - This will be added to the beware file.]
  1777.  
  1778. Also, I'm using the April C-Kermit (BSD 4.2) off of mod.sources.  When I
  1779. upload files from UNIX to the Mac, I'm not getting a size packet -- or at
  1780. least, the Mac isn't printing the expected size.  This is the only thing I
  1781. like better about MacTerminal than Kermit -- but the keymap and more
  1782. reliable transfers means I've thrown MacTerminal away.
  1783.  
  1784. [Ed. - Unfortunately, this requires the sender to include an "attribute
  1785. packet", which C-Kermit does not yet do.]
  1786.  
  1787. Keep up the good work.
  1788.  
  1789.     Joel West    CACI, Inc. - Federal
  1790.  
  1791. ------------------------------
  1792.  
  1793. Date: Thu, 18 Jul 85 21:18:22 PDT
  1794. From: VSS7853@UCLAVM
  1795. Subject:  Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
  1796. Keywords: TSO Kermit, ASCII/EBCDIC Translation Tables
  1797.  
  1798. Enclosed are three Fortran 77 programs I wrote as aids to installing TSO
  1799. Kermit when non-standard TCAM tables are used by MVS to communicate with
  1800. Ascii terminals.
  1801.  
  1802. The first two programs, ATOE.FOR and ETOA.FOR take the actual tables used by
  1803. TCAM, which are obtained from the communication's people at one's
  1804. installation, and generate assembler source code to replace the tables in
  1805. Kermit.  The third, TCAM.FOR, takes the output of the first two and checks
  1806. whether the ETOA table is indeed the inverse of the ATOE on the printable
  1807.  
  1808. INFO-KERMIT DIGEST V3 #6                                                Page 33
  1809.  
  1810. subset as required for Kermit to operate.
  1811.  
  1812. If the test fails, Kermit will not run with the existing TCAM tables.  I
  1813. suspect, however, that so long as all of the Ascii printables map to
  1814. distinct Ebcdic representations, and so long as the range of the Ebcdic-
  1815. to-Ascii contains all the Ascii printables, that Kermit could still be made
  1816. to work by employing an ETOA which is the inverse of TCAM's Ascii-to-Ebcdic,
  1817. an ATOE which is the inverse of TCAM's Ebcdic-to-Ascii, and an additional
  1818. ETOA with range contained in the printable subset (and null).  This would
  1819. require a bit of analysis and a modest amount of reprogramming on someone's
  1820. part but it might add to the number of mvs systems which support Kermit.
  1821.  
  1822. The listings include actual output which includes an echo of the input.  The
  1823. programs were developed on VAX but the language should be standard 77 except
  1824. for the Z format extension.
  1825.  
  1826. I hope this helps someone.
  1827.  
  1828.  Glenn E. Thobe
  1829.  EE dept. UCLA
  1830.  iva3get.uclamvs (bitnet)
  1831.  
  1832. [Ed. - Listings omitted; they're collected together in K2:TSOETOA.FOR.]
  1833.  
  1834. ------------------------------
  1835.  
  1836. Date: 22 Jul 1985 1354-EDT
  1837. From: LCG.KERMIT@MARKET
  1838. Subject: MS-DOS Kermit vs Professional Graphics Adapter?
  1839. Keywords: MS-DOS Kermit, Professional Grpahics Adapter
  1840.  
  1841. We are having trouble with MS-DOS Kermit V2.27 on an IBM AT with the
  1842. professional graphics adapter/display.  At speeds above 1200 baud characters
  1843. are lost in terminal emulation mode.  Has anyone else seen this problem?
  1844.  
  1845. Carl Houseman
  1846. GENICOM Corporation
  1847. 703-949-1323
  1848.  
  1849. [Ed. - On the IBM PC/AT, terminal emulation is very slow if EGA card is
  1850. present because the program waits for the vertical retrace operation to
  1851. complete, which should not be done with the EGA.  Apparently the same is true
  1852. of the Professional Graphics Adapter.  Until this is fixed in the next
  1853. release, EGA (and PGA?) users can patch the routine SCRWAIT in MSYIBM to
  1854. just return.  If anyone with the PGA tries this, please report the results
  1855. to Info-Kermit.]
  1856.  
  1857. ------------------------------
  1858.  
  1859. End of Info-Kermit Digest
  1860.  
  1861. Page 34                                                INFO-KERMIT DIGEST V3 #7
  1862.  
  1863. Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  7
  1864.  
  1865.                     Kermit Sliding Window Proposal
  1866.  
  1867. ----------------------------------------------------------------------
  1868.  
  1869. Date: Tue 23 Jul 85 10:30:00-EDT
  1870. From: Frank da Cruz
  1871. Subject: Kermit Sliding Window Proposal
  1872. Keywords: Sliding Windows Kermit
  1873.  
  1874. This digest presents a proposal from a group at The SOURCE Telecomputing in
  1875. McLean, Virginia, for a sliding window extension to the Kermit protocol
  1876. (if you're not interested in protocol issues, skip the rest of this digest).
  1877. Like other extensions, this one is designed for "upward compatibility" with
  1878. Kermits that do not support this extension.  It may be viewed as an
  1879. alternative to the long-packets extension proposed in V3 #4, or as
  1880. complementary to it.  The question raised by the latter proposal also applies
  1881. here: Is the cost in complexity worth the improvement in performance? --
  1882. complexity not only in program size and logic, but also in explaining the
  1883. options to the user: even when Kermit programs implement windowing, when and
  1884. to what degree should it be used?  When must it not be used?
  1885.  
  1886. The following proposal is not the only way to do sliding windows or to adapt
  1887. windows to Kermit.  The method outlined is certainly not cast in concrete,
  1888. although Leslie's group is working on some prototype implementations.  The
  1889. proposal is being put forth now to solicit ideas, suggestions, and opinions
  1890. from the world at large.  Some areas to think about include:
  1891.  
  1892. . What is the effect on the portability of current Kermit programs?  Since
  1893.   windowing implies packets flowing in both directions at once, it will be
  1894.   necessary to run separate input and output forks or else to handle packet
  1895.   i/o at interrupt level.  Neither of these techniques will be as portable
  1896.   as the simple input-output sequences now used by most Kermit programs.
  1897.  
  1898. . What will be the effect in the many and varied environments in which
  1899.   Kermit operates, and will operate in the future?  These include public
  1900.   networks, satellite links, local area networks, terminal concentrators,
  1901.   TACs, PBX's, high-speed full-duplex error-correcting modems, ATT 56Kb
  1902.   digital service, etc etc.  In some cases windowing (or long packets)
  1903.   could boost performance dramatically, in others it could prevent Kermit
  1904.   from working at all.
  1905.  
  1906. . Does the particular method suggested strike the best balance among
  1907.   improved performance, upward compatibility, and simplicity?  Are there
  1908.   obvious simple improvements to the proposed algorithms and heuristics?
  1909.  
  1910. . Can sliding (lurching) windows be done on half-duplex channels?  Are
  1911.   any modifications to the proposal required?
  1912.  
  1913. This digest will be followed closely by another, which will contain some
  1914. questions and answers about this proposal.  Please read both digests before
  1915. responding.
  1916.  
  1917. ------------------------------
  1918.  
  1919.  
  1920. INFO-KERMIT DIGEST V3 #7                                                Page 35
  1921.  
  1922. Date: Mon 22 Jul 85 11:29:46-EDT
  1923. From: Leslie Spira <OC.SOURCE@CU20B>
  1924. Subject: Kermit Sliding Window Proposal
  1925. Keywords: Sliding Windows Kermit
  1926.  
  1927.                       KERMIT WINDOWING PROTOCOL
  1928.  
  1929.                          DRAFT SPECIFICATION
  1930.  
  1931.                 Hugh Matlock, The SOURCE Telecomputing
  1932.  
  1933.                             June 12, 1985
  1934.  
  1935.  
  1936. 1 INTRODUCTION
  1937.  
  1938. The windowing protocol as defined for the Kermit file transfer protocol
  1939. is based on the main premise of continuously sending data packets up to
  1940. the number defined by a  set  window  size.   These  data  packets  are
  1941. continuously acknowledged  by  the  receive side and the ideal transfer
  1942. occurs as long as they are transmitted with good  checksums,  they  are
  1943. transmitted in  sequential  order and there are no lost data packets or
  1944. acknowledgements.  The various error conditions define the  details  of
  1945. the windowing protocol and are best examined on a case basis.
  1946.  
  1947. There are  five  stages that describe the overall sequence of events in
  1948. the Kermit protocol.  Three of these stages deviate from  the  original
  1949. protocol in order to add the windowing feature.  Stages 1 through 5 are
  1950. briefly described on the following page.  The three stages (1, 3 and 4)
  1951. which deviate  from the original protocol are then described in greater
  1952. detail in the pages that follow.
  1953.  
  1954.  
  1955. 2 OVERALL SEQUENCE OF EVENTS
  1956.  
  1957. STAGE 1 - Propose and Accept Windowing
  1958.  
  1959. The send  side  requests  windowing  in   the   transmission   of   the
  1960. Send-Initiate (S)  packet.   The  receive  side  accepts  windowing  by
  1961. sending an acknowledgement (ACK packet) for the  Send-Initiate  packet.
  1962.  
  1963. STAGE 2 - Send and Accept File-Header Packet
  1964.  
  1965. The send  side  transmits  the File-Header (F) packet and waits for the
  1966. receive side to acknowledge it prior to transmitting any data.
  1967.  
  1968. STAGE 3 - Transfer Data
  1969.  
  1970. The sending routine transmits Data (D)  packets  one  after  the  other
  1971. until the  protocol  window  is  closed.   The receiving side ACKs good
  1972. data, stores data to disk as necessary and NAKs bad data.
  1973.  
  1974. When the sender receives an ACK, the window may be rotated and the next
  1975. packet sent.  If the sender receives a NAK, the data  packet  concerned
  1976. is retransmitted.
  1977.  
  1978.  
  1979. Page 36                                                INFO-KERMIT DIGEST V3 #7
  1980.  
  1981. STAGE 4 - Send and Accept End_of_File Packet
  1982.  
  1983. As the  sender is reading the file for data to send, it will eventually
  1984. reach the end of the file.  It then waits until  all  outstanding  data
  1985. packets have  been  acknowledged,  and  then  sends  an End-of_File (Z)
  1986. packet.
  1987.  
  1988. When the receive side gets the End-of-File packet it stores the rest of
  1989. the data to disk, closes the file, and ACKs the End-of_File packet.
  1990.  
  1991. The protocol then returns to Stage 2,  sending  and  acknowledging  any
  1992. further File-Header (F) packets.
  1993.  
  1994. STAGE 5 - End of Transmission
  1995.  
  1996. Once the  End-of-File  packet  has been sent and acknowledged and there
  1997. are no more files to send, the sender transmits the End-of-Transmission
  1998. (B) packet in order to end the ongoing transaction.  Once the  receiver
  1999. ACKs this  packet,  the transaction is ended and the logical connection
  2000. closed.
  2001.  
  2002.  
  2003. 3 PROPOSE AND ACCEPT WINDOWING (STAGE 1)
  2004.  
  2005. The initial connection as currently defined  for  the  Kermit  protocol
  2006. will need  to change only in terms of the contents of the Send-Initiate
  2007. packet.  The receiving Kermit waits for the sending Kermit to  transmit
  2008. the Send-Initiate  (S)  packet  and the sending packet does not proceed
  2009. with any additional transmission until the ACK has been returned by the
  2010. receiver.
  2011.  
  2012. The contents  of  the  Send-Init  packet,  however,  will  be  slightly
  2013. revised.  The data field of the Send-Init packet currently contains all
  2014. of the configuration parameters.  The first six fields of the Send-Init
  2015. packet are fixed as follows:
  2016.  
  2017.    1        2        3        4        5        6
  2018.   +--------+--------+--------+--------+--------+--------+
  2019.   | MAXL   | TIME   | NPAD   | PADC   | EOL    | QCTL   |
  2020.   +--------+--------+--------+--------+--------+--------+
  2021.  
  2022. Fields 7  through  10  are  optional  features  of  Kermit and fields 7
  2023. through 9 will also  remain  unchanged  as  defined  for  the  existing
  2024. protocol:
  2025.  
  2026.    7        8        9        10
  2027.   +--------+--------+--------+--------+
  2028.   | QBIN   | CHKT   | REPT   | CAPAS  |
  2029.   +--------+--------+--------+--------+
  2030.  
  2031. Field 10  is  the  capability  field  and  requires  N  number of bytes
  2032. depending on the number of capabilities defined for kermit.   Each  bit
  2033. position of these 6-bit fields corresponds to a capability with the low
  2034. order bit  used  to  indicate  whether  or  not another capability byte
  2035. follows.  If the low order bit is  "1"  then  another  capability  byte
  2036. follows.  If the low order bit is "0" then the current byte is the last
  2037.  
  2038. INFO-KERMIT DIGEST V3 #7                                                Page 37
  2039.  
  2040. capability byte.   The  second  through  sixth  bit positions represent
  2041. capabilities in the same way.  If a bit position is set to 1  then  the
  2042. capability it  represents  is present.  If the bit position is set to 0
  2043. then the capability it represents does not exist.  Currently, there are
  2044. only 3 capabilities defined for Kermit as follows:
  2045.  
  2046.     #1  Reserved
  2047.     #2  Reserved
  2048.     #3  Ability to accept "A" packets (file attributes)
  2049.  
  2050. The windowing capability will constitute a fourth  capability  and  the
  2051. fourth bit  of  the  capability  field  will  be set to 1 if the kermit
  2052. implementation can handle windowing.
  2053.  
  2054.     #4  Ability to handle windowing.
  2055.  
  2056. The remaining fields of the Send-Init packet are  either  reserved  for
  2057. future use  by  the standard Kermit protocol or reserved for local site
  2058. implementations.  The four fields following the  capability  field  are
  2059. reserved for the standard Kermit protocol.  We propose the use of field
  2060. 11 to be used to specify the "Window Size" for all kermits
  2061.  
  2062.    11       12       13       14       15       16 - N
  2063.   +--------+--------+--------+--------+--------+------------------+
  2064.   | WINDW  | RESV1  | RESV2  | RESV3  | RESV4  | LOCAL Reserved   |
  2065.   +--------+--------+--------+--------+--------+------------------+
  2066.  
  2067. 11. WINDW - The window size to be used encoded printably using
  2068.     the char() function.  The window size may range from 1 to 31
  2069.     inclusive.
  2070.  
  2071. The sender  will  specify  the  window  size  it  wishes to use and the
  2072. receiver will reply (in the ACK packet) with the window size it  wishes
  2073. to use.   The window size actually used will be the minimum of the two.
  2074. If the receiver replies with a window size of 0 then no windowing  will
  2075. be done.
  2076.  
  2077.  
  2078. 4 TRANSFER DATA (STAGE 3)
  2079.  
  2080. The sequence  of  events  required for the transmission of data packets
  2081. and confirmation of receipts  constitute  the  main  functions  of  the
  2082. windowing protocol.   There  are  four  main  functions  which  can  be
  2083. identified within this stage.  These are:
  2084.  
  2085.      - the sender's processing of the data packets,
  2086.      - the receiver's handling of incoming packets,
  2087.      - the sender's handling of the confirmations,
  2088.      - the error handling on both sides.
  2089.  
  2090. The following discussion details the specific actions required for each
  2091. of these functions.  Refer to the  state  table  at  the  end  of  this
  2092. document for  the  specific  action taken on a "received message" basis
  2093. for the full protocol.
  2094.  
  2095.    4.1 The Sender's Processing of Data Packets
  2096.  
  2097. Page 38                                                INFO-KERMIT DIGEST V3 #7
  2098.  
  2099.  
  2100.    The sender instigates the transmission by  sending  the  first  data
  2101.    packet and  then  operating in a cyclical mode of sending data until
  2102.    the defined window is closed.
  2103.  
  2104.    Data to be sent must be read from the file, encoded into the  Kermit
  2105.    Data packet, and saved in a Send-Table.  A Send-Table entry consists
  2106.    of the  data  packet itself (which makes convenient the re-send of a
  2107.    NAKed packet), a bit which keeps track of  whether  the  packet  has
  2108.    been ACKed (the ACKed bit), and a retry counter.  The table is large
  2109.    enough to hold all the packets for the protocol window.
  2110.  
  2111.    Before each transmission, the input buffer is checked and  input  is
  2112.    processed, as  described  below.   Transmission  is  stopped  if the
  2113.    protocol window "closes", that is, if the Send-Table is full.
  2114.  
  2115.    4.2 The Receiver's Handling of Incoming Packets
  2116.  
  2117.    The receiver keeps its  own  table  as  it  receives  incoming  data
  2118.    packets.  This  allows  the  receiver  to receive subsequent packets
  2119.    while it is waiting for a re-send of an erroneous  or  lost  packet.
  2120.    In other  words,  the incoming packets do not have to be received in
  2121.    sequential order and can still be written to disk in order.
  2122.  
  2123.    A Receive-Table entry consists of the data packet, a bit which keeps
  2124.    track of whether a good version of the packet has been received (the
  2125.    ACKed bit), and a retry counter for the  NAKs  we  send  to  request
  2126.    retransmissions of  the  packet.   The table is large enough to hold
  2127.    all the packets for the protocol window.
  2128.  
  2129.    The different possibilities for a received packet are:
  2130.  
  2131.       1. A new packet, the next sequential one (the usual case)
  2132.       2. A new packet, not the next sequential one (some were lost)
  2133.       3. An old packet, retransmitted
  2134.       4. An unexpected data packet
  2135.       5. Any packet with a bad checksum
  2136.  
  2137.    These are discussed separately below.
  2138.  
  2139.    1.  The next new packet has sequence number  one  past  the  <latest
  2140.    table entry>.  The packet is ACKed, and the Receive-Table is checked
  2141.    for space.   If  it  is  full (already contains window_size entries)
  2142.    then the oldest entry is written to disk.  (This entry  should  have
  2143.    the ACKed  bit set.  If not, the receiver aborts the file transfer.)
  2144.    The received packet is then stored in the  Receive-Table,  with  the
  2145.    ACKed bit set.
  2146.  
  2147.    2.  If the packet received has sequence number  in  the  range  <two
  2148.    past the  latest  table entry> to <window_size past the latest table
  2149.    entry> then it is a new packet, but some have been lost.  (The upper
  2150.    limit here represents the  highest  packet  the  sender  could  send
  2151.    within its  protocol  window.  Note that the requirement to test for
  2152.    this case is what limits the maximum  window_size  to  half  of  the
  2153.    range of  possible  sequence numbers) We ACK the packet, and NAK all
  2154.    packets that were skipped.  (The skipped packets are those from <one
  2155.  
  2156. INFO-KERMIT DIGEST V3 #7                                                Page 39
  2157.  
  2158.    past the latest table entry> to <one before  the  received  packet>)
  2159.    The Receive-Table is then checked.  The table may have to be rotated
  2160.    to accomodate the packet, as with case 1.  (This time, several table
  2161.    entries may  have  to  be written to disk.  As before, if any do not
  2162.    have the ACKed bit set, they will trigger an abort.)  The packet  is
  2163.    then stored in the table, and the ACKed bit set.
  2164.  
  2165.    3.  A retransmitted packet will have sequence number  in  the  range
  2166.    <the oldest table entry> to <the latest table entry>.  The packet is
  2167.    ACKed, then placed in the table, setting the ACKed bit.
  2168.  
  2169.    4.  A packet with sequence number outside of  the  range  from  <the
  2170.    oldest table  entry> to <window_size past the latest table entry> is
  2171.    ignored.
  2172.  
  2173.    5.  If the packet received  has  a  bad  checksum,  we  must  decide
  2174.    whether to  generate  a  NAK,  and if so, with what sequence number.
  2175.    The best action may depend on the configuration  and  channel  error
  2176.    rate.  For  now,  we  adopt  the  following heuristic:  If there are
  2177.    unACKed entries in our Receive-Table, we send a NAK for  the  oldest
  2178.    one.  Otherwise  we ignore the packet.  (Notice that this will occur
  2179.    in a common case:  when things have  been  going  smoothly  and  one
  2180.    packet gets  garbled.   In this case, when we later receive the next
  2181.    packet we will NAK for this one as described under Case 2 above.)
  2182.  
  2183.    4.3 The Sender's Handling of Confirmations
  2184.  
  2185.    The sender's receipt of confirmations controls the rotation  of  the
  2186.    Send-Table and  normally returns the sender to a sending state.  The
  2187.    sender's action  depends  on  the  packet  checksum,  the  type   of
  2188.    confirmation (ACK  or  NAK),  and whether the confirmation is within
  2189.    the high and low boundaries of the Send-Table.
  2190.  
  2191.    If the checksum is bad the packet is ignored.
  2192.  
  2193.    When the sender receives an ACK, the sequence  number  is  examined.
  2194.    If the  sequence  number is outside of the current table boundaries,
  2195.    then the ACK is also ignored.  If the sequence number is  inside  of
  2196.    the current  table  boundaries then the ACKed bit for that packet is
  2197.    marked.  If the entry  is  at  the  low  boundary,  this  enables  a
  2198.    "rotation" of  the  table.   The low boundary is changed to the next
  2199.    sequential entry for which the ACKed bit is  not  set.   This  frees
  2200.    space in the table to allow further transmissions.
  2201.  
  2202.    When the sender receives a NAK, the table boundaries are checked.  A
  2203.    NAK outside  of  the  table boundary is ignored and a NAK inside the
  2204.    table boundary indicates that the sender must  re-send  the  packet.
  2205.    The sender  first tests the packet's retry counter against the retry
  2206.    threshold.  If the threshold has been reached, then the transfer  is
  2207.    stopped (by going to the Abort state).  Otherwise, the retry counter
  2208.    is incremented and the packet re-sent.
  2209.  
  2210.    4.4 Error Handling for Both Sides
  2211.  
  2212.    Three situations  are  discussed  here:   Sender  timeout,  Receiver
  2213.    timeout, and invalid packets.
  2214.  
  2215. Page 40                                                INFO-KERMIT DIGEST V3 #7
  2216.  
  2217.  
  2218.    If certain packets are lost, each side may "hang", waiting  for  the
  2219.    other.  To  get  things  moving  when  this  happens each may have a
  2220.    "timeout limit", the longest they will wait for something  from  the
  2221.    other side.
  2222.  
  2223.    If the sender's timeout condition is triggered, then  it  will  send
  2224.    the oldest  unACKed  packet.   This  will  be  the  first one in the
  2225.    Send-Table.
  2226.  
  2227.    If the receiver's timeout condition is triggered, then it will  send
  2228.    a NAK  for the "most desired packet".  This is defined as either the
  2229.    oldest unACKed packet, or if none are unACKed, then the next  packet
  2230.    to be received (sequence number <latest table entry plus one>).  The
  2231.    packet retry  count  is  not  incremented  by  this NAK;  instead we
  2232.    depend on the timeout retry count, discussed next.
  2233.  
  2234.    For either the sender  or  receiver,  the  timeout  retry  count  is
  2235.    incremented each  time a timeout occurs.  If the timeout retry limit
  2236.    is exceeded then the side  aborts  the  file  transfer.   Each  side
  2237.    resets the retry count to zero whenever they receive a packet.
  2238.  
  2239.    In addition, as with the existing Kermit, any invalid  packet  types
  2240.    received by either side will cause an Error packet and stop the file
  2241.    transfer.
  2242.  
  2243.  
  2244. 5 SEND AND ACCEPT END_OF_FILE PACKET (STAGE 4)
  2245.  
  2246. There are  several  ways  to  end  the file transfer.  The first is the
  2247. normal way, when the sender encounters an  end-of-file  condition  when
  2248. reading the  file  to  get  a  packet  for transmission.  The second is
  2249. because of a sender side user interrupt.  The third  is  because  of  a
  2250. receiver side user interrupt.  Both of these cause the received file to
  2251. be discarded.   In  addition  either side may stop the transfer with an
  2252. Error packet if an unrecoverable error is encountered.
  2253.  
  2254.    5.1 Normal End of File Handling
  2255.  
  2256.    When the sender reaches the end of file, it must wait until all data
  2257.    packets have been acknowledged before sending  the  End-of-File  (Z)
  2258.    packet.  To  do this it must be able to check the end-of-file status
  2259.    when it processes ACKs.  If the ACK  causes  the  Send-Table  to  be
  2260.    emptied and  the  end-of-file has been reached, then a transition is
  2261.    made to the Send_Eof state which sends the End_of_File packet.
  2262.  
  2263.    When the  receiver  gets  the  End_of_File  packet,  it  writes  the
  2264.    contents of  the  Receive-Table  to  the file (suitably decoded) and
  2265.    closes the file.  (If any entries do not have the ACKed bit set,  or
  2266.    if errors  occur  in  writing the file, the receiver aborts the file
  2267.    transfer.)  If the operation is successful, the  receiver  sends  an
  2268.    ACK.  It  then  sets  its  sequence number to the End_of_File packet
  2269.    sequence number and goes to Rcv_File state.
  2270.  
  2271.    5.2 Sender User Interrupt
  2272.  
  2273.  
  2274. INFO-KERMIT DIGEST V3 #7                                                Page 41
  2275.  
  2276.    Whenever the sender checks for input from  the  data  communications
  2277.    line, it  should  also check for user input.  If that indicates that
  2278.    the file transfer should be stopped, the sender goes directly to the
  2279.    Send_Eof state and sends an  End_of_File  packet  with  the  Discard
  2280.    indication.  It  will not have to wait for outstanding packets to be
  2281.    ACKed.
  2282.  
  2283.    When the receiver gets  the  End_of_File  packet  with  the  Discard
  2284.    indication it  discards  the  file,  sets its sequence number to the
  2285.    End_of_File packet sequence number, and goes to RcvFile state.
  2286.  
  2287.    5.3 Receiver User Interrupt
  2288.  
  2289.    Whenever the receiver checks for input from the data  communications
  2290.    line, it  also  should check for user input.  If that indicates that
  2291.    the file transfer should be stopped, the receiver sets an "interrupt
  2292.    indication" of X (for "stop this file transfer") or of Z (for  "stop
  2293.    the batch  of  file  transfers").   When the receiver later sends an
  2294.    ACK, it places an X or Z in the data field.
  2295.  
  2296.    When the sender gets this ACK, it goes to  the  Send_Eof  state  and
  2297.    sends the  End_of_File packet with the Discard indication, as above.
  2298.  
  2299.    When the receiver gets  the  End_of_File  packet  with  the  Discard
  2300.    indication, it  discards  the  file, sets its sequence number to the
  2301.    End_of_File packet sequence number, and goes to RcvFile state.
  2302.  
  2303.    5.4 LOW LEVEL PROTOCOL REQUIREMENTS
  2304.  
  2305.    The Kermit windowing protocol, as defined in  this  document,  makes
  2306.    certain assumptions  about the underlying transmission and reception
  2307.    mechanism.
  2308.  
  2309.    First, it must provide a full-duplex channel so that messages may be
  2310.    sent and received simultaneously.
  2311.  
  2312.    Second, it will prove advantageous to  be  able  to  buffer  several
  2313.    received messages  at  the  low  level before processing them at the
  2314.    Kermit level.  This is for two  reasons.   The  first  is  that  the
  2315.    Kermit windowing  level  of the protocol may take a while to process
  2316.    one input, and meanwhile several  others  may  arrive.   The  second
  2317.    reason is  to  support XON/XOFF flow control.  If Kermit receives an
  2318.    XOFF from the data communications line, it  must  wait  for  an  XON
  2319.    before sending  its  packet.   While  it  is  waiting, the low level
  2320.    receive must  be  able  to  accept  input.   Otherwise  a   deadlock
  2321.    situation could  arise  with  each side flow controlled, waiting for
  2322.    the other.
  2323.  
  2324.    5.5 KERMIT WINDOWING PROTOCOL STATE TABLE
  2325.  
  2326.    The following defines the inputs expected,  the  actions  performed,
  2327.    and the  succeeding  states for proposed new Send_Data_Windowing and
  2328.    Rcv_Data_Windowing states.
  2329.  
  2330.    If both sides agree on windowing in the  Send  Init  exchange,  then
  2331.    instead of  entering  the  old  Send_Data  or  Rcv_Data  states from
  2332.  
  2333. Page 42                                                INFO-KERMIT DIGEST V3 #7
  2334.  
  2335.    Send_File or Rcv_File,  we  enter  the  new  Send_Data_Windowing  or
  2336.    Rcv_Data_Windowing.
  2337.  
  2338.  
  2339.    SEND_DATA_WINDOWING
  2340.  
  2341.    Rec'd Msg  Action     Next State
  2342.    ---------  ------     ----------
  2343.  
  2344.    No input/Window closed  (1) Wait for input     SDW
  2345.    No input/Window open    (2) Read file, encode packet, SDW
  2346.    Place in table, mark unACKed,
  2347.    Send packet
  2348.  
  2349.    ACK/ X or Z      (3) set interrupt indicator (X/Z)  Send_Eof
  2350.    ACK/outside table -ignore-SDW
  2351.    ACK/inside table (4) mark pkt ACKed,  SDW or Send_Eof
  2352.    if low rotate table,
  2353.    if file eof & table empty
  2354.       then goto Send_Eof
  2355.  
  2356.    NAK/outside table -ignore-SDW
  2357.    NAK/inside table (5) test retry limit,  SDW
  2358.    re-send DATA packet
  2359.  
  2360.    Bad checksum     -ignore- SDW
  2361.  
  2362.    Timeout   (6) re-send oldest unACKed pktSDW
  2363.  
  2364.    User interrupt   (7) set interrupt indicator (X/Z)  Send_Eof
  2365.  
  2366.    Other     (8) send Error Abort
  2367.  
  2368.  
  2369.    RCV_DATA_WINDOWING
  2370.  
  2371.    Rec'd Msg  Action     Next State
  2372.    ---------  ------     ----------
  2373.  
  2374.    DATA/new  (1) send ACK    RDW
  2375.    if table full: file & rotate
  2376.    store new pkt in table
  2377.    DATA/old  (2) send ACK, store in table  RDW
  2378.    DATA/unexpected  -ignore- RDW
  2379.  
  2380.    Z/discard (3) discard file     Rcv_File
  2381.    Z/ (4) write table to file & close    Rcv_File
  2382.    if OK send ACK, else Error     or Abort
  2383.  
  2384.    Bad checksum     (5) send NAK for oldest unACKed      RDW
  2385.  
  2386.    Timeout   (6) send NAK for most desired pkt    RDW
  2387.  
  2388.    User Interrupt   (7) Set interrupt indicator X or Z   RDW
  2389.  
  2390.    Other     (8) send Error pkt    Abort
  2391.  
  2392. INFO-KERMIT DIGEST V3 #7                                                Page 43
  2393.  
  2394.  
  2395. ------------------------------
  2396.  
  2397. End of Info-Kermit Digest
  2398.  
  2399. Page 44                                                INFO-KERMIT DIGEST V3 #8
  2400.  
  2401. Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  8
  2402.  
  2403. Departments:
  2404.  
  2405.   PROPOSAL FEEDBACK -
  2406.     Sliding Window Proposal, Cont'd
  2407.     Sliding Window Proposal Q & A
  2408.  
  2409.   MISCELLANY -
  2410.     Conversion Tables, Liberalized Requirements
  2411.     More about IBM Professional Graphics Controller (several msgs)
  2412.     Using Kermit with Ungermann-Bass Net One?
  2413.  
  2414. ----------------------------------------------------------------------
  2415.  
  2416.  
  2417. Date: Tue 23 Jul 85 13:12:23-EDT
  2418. From: Frank da Cruz <SY.FDC@CU20B>
  2419. Subject: Sliding Window Proposal, Cont'd
  2420. Keywords: Sliding Windows Kermit
  2421.  
  2422. The proposal in Info-Kermit V3 #7 should have been dated July 19, not June
  2423. 12, and the formatting of the state table at the end appears to have been
  2424. messed up -- apologies.
  2425.  
  2426. The next message (about 10K long) gives some informal information about
  2427. the proposal in the form of questions and answers.  Comments, reactions,
  2428. suggestions on both the long-packets and the windowing proposals encouraged.
  2429.  
  2430. ------------------------------
  2431.  
  2432. Date: Mon 22 Jul 85 09:30:00-EDT
  2433. From: Leslie Spira <OC.SOURCE@CU20B>
  2434. Subject: Sliding Window Proposal Q & A
  2435. Keywords: Sliding Windows Kermit
  2436.  
  2437.  
  2438.                            KERMIT WINDOWING PROTOCOL
  2439.  
  2440.                  DRAFT PROPOSED DEFINITION DATED JULY 19, 1985
  2441.  
  2442.                              QUESTIONS AND ANSWERS
  2443.  
  2444.                     John Mulligan, The SOURCE Telecomputing
  2445.  
  2446.                                  July 19, 1985
  2447.  
  2448. Q.  What is the purpose of the "windowing" extension?
  2449.  
  2450. A.  The object is to speed up file transfers using KERMIT.  The increase
  2451.     will be especially noticeable over the data networks (such as Telenet
  2452.     and Tymnet) and over connections using satellite links.  This is
  2453.     because there are long communications delays over these connections.
  2454.  
  2455.  
  2456. Q.  How does it work?
  2457.  
  2458. INFO-KERMIT DIGEST V3 #8                                                Page 45
  2459.  
  2460.  
  2461. A.  Basically, it allows you to send several packets out in a row before
  2462.     getting the first acknowledgment back.  The number of packets that can
  2463.     be sent out is set by the "window size", hence the name windowing.
  2464.  
  2465.  
  2466. Q.  Could you explain in more detail?
  2467.  
  2468. A.  Right now, a system sending a file transmits one packet of data, then
  2469.     does nothing more until it gets back an acknowledgment that the packet
  2470.     has been received.  Once it gets an acknowledgment, it sends the next
  2471.     packet of data.  Over standard direct-dial land-based phone lines, the
  2472.     transmission delays are relatively small.  However, the public data
  2473.     networks or satellite links can introduce delays of up to several
  2474.     seconds round trip.  As a result, the sending system ends up spending
  2475.     much more time waiting than actually sending data.
  2476.  
  2477.     With the new windowing enhancement, the sending system will be able to
  2478.     keep sending data continuously, getting the acknowledgments back
  2479.     later.  It only has to stop sending data if it reaches the end of the
  2480.     current "window" without getting an acknowledgment for the first
  2481.     packet in the current "window".
  2482.  
  2483.  
  2484. Q.  What size is the "window"?
  2485.  
  2486. A.  The window size can vary depending on what the two ends of the
  2487.     connection agree on.  The suggested standard window size will be 8
  2488.     packets.  The maximum is 31 packets.
  2489.  
  2490.     The KERMIT sequence numbering is modulo 64 (it "wraps" back to the 1st
  2491.     sequence number after the 64th sequence number).  It is helpful to
  2492.     limit the maximum window size to 31 to avoid problems (ambiguous
  2493.     sequence numbers) under certain error conditions.
  2494.  
  2495.  
  2496. Q.  Is windowing in effect throughout a KERMIT session?
  2497.  
  2498. A.  No, it is only in effect during the actual data transfer (data
  2499.     packets) portion of a file transfer.  Windowing begins with the first
  2500.     data packet (D packet type), and stops when you get an End-of-File
  2501.     packet (Z packet type).
  2502.  
  2503.  
  2504. Q.  Why does it stop when you get to the End-of-File packet?
  2505.  
  2506. A.  This is done primarily to avoid having more than one file open at
  2507.     once.
  2508.  
  2509.  
  2510. Q.  Why will windowing be especially helpful at higher baud rates over
  2511.     communications paths that have delays?
  2512.  
  2513. A.  As you increase the baud rate, the transmission speed of the data
  2514.     increases, but you do not change the delay caused by the
  2515.     communications path.  As a result, the delay becomes more and more
  2516.  
  2517. Page 46                                                INFO-KERMIT DIGEST V3 #8
  2518.  
  2519.     significant.
  2520.  
  2521.     Assume, for example, that your communications path introduces a delay
  2522.     of 1 second each way for packets, for a total delay of 2 seconds round
  2523.     trip.  Assume also that your packets have 900 bits in them so it takes
  2524.     you 3 seconds to send a packet at 300 baud (this is roughly equivalent
  2525.     to a typical KERMIT packet).
  2526.  
  2527.     WITHOUT windowing, here is what happens:
  2528.  
  2529.     If at 300 baud you transmitted data for 3 seconds (sending 900 bits),
  2530.     then waited 2 seconds for each acknowledgment, your throughput would
  2531.     be roughly 180 baud.  (Total time for each transmission = 5 seconds.
  2532.     900/5 = 180).
  2533.  
  2534.     Howver, if you went to 2400 baud, you would transmit data for 3/8
  2535.     second, then wait 2 seconds for an acknowledgment.  (Total time for
  2536.     each transmission = 2 and 3/8 seconds).  The throughput would increase
  2537.     only to about 378 baud. (900 / 2.375 = 378).
  2538.  
  2539.     The delay becomes the limiting factor; in this case, with this packet
  2540.     size, the delay sets an outside limit of 450 baud (900 / 2 second
  2541.     delay = 450), no matter how fast the modem speed.
  2542.  
  2543.     WITH windowing, the throughput should be close to the actual
  2544.     transmission speed.  It should be possible to send data nearly
  2545.     continuously.  The exact speed will depend on the window size, length
  2546.     of transmission delays, and error rate.
  2547.  
  2548.  
  2549. Q.  Are there any new packet types introduced by this extension?
  2550.  
  2551. A.  No, the only change is to the contents of the Send-Init packet, to
  2552.     arrange for windowing if both sides can do it.  If either side cannot,
  2553.     KERMIT will work as it does now.  Adding an extension such as this was
  2554.     provided for in the original KERMIT definition.  See section 3 of the
  2555.     windowing definition for details.
  2556.  
  2557.  
  2558. Q:  On the receive side, in section 4.2, why does the definition say that
  2559.     writing to disk is done when the Receive-Table becomes full rather
  2560.     than as soon as you get a good packet?
  2561.  
  2562. A:  The definition was phrased this way because it makes the logic of the
  2563.     receive side clearer and simpler to implement.
  2564.  
  2565.     Actually, you could also write a packet to disk when it is a good
  2566.     packet and it is the earliest entry in the receive table.  This
  2567.     approach has the disadvantage that you don't know at this point that
  2568.     the sender has received your ACK, so you have to be prepared to handle
  2569.     the same packet later on if the sender never gets the ACK, times out,
  2570.     and sends the same packet again.  Thus you have to be prepared to deal
  2571.     with packets previous to the current window; you will have to ACK such
  2572.     a packet if it has been received properly before.
  2573.  
  2574.     By writing packets to disk only when the receive table becomes full,
  2575.  
  2576. INFO-KERMIT DIGEST V3 #8                                                Page 47
  2577.  
  2578.     (the oldest packet) you know that the sender has received your ACK
  2579.     (otherwise the sender could not have rotated the window to the n+1
  2580.     position to send the current packet, where n is the window size).
  2581.     This makes it very easy to stay in synch with the sender.  The
  2582.     disadvantage of this approach is that when you receive the End-of-File
  2583.     packet, you have to take the time to write all the remaining packets
  2584.     in the Receive-Table to disk.
  2585.  
  2586.  
  2587. Q.  Could you briefly explain what happens if a single packet gets
  2588.     corrupted?
  2589.  
  2590. A.  In essence, the receiver will ignore the bad packet.  When it gets the
  2591.     next good packet, it will realize (because packets are numbered) that
  2592.     one or more packets were lost, and NAK those packets.  The receiver
  2593.     continues to accept good data.
  2594.  
  2595.     As long as the sender's window does not become "blocked", the only
  2596.     loss of throughput will be the time it takes to transmit the NAKed
  2597.     packets.
  2598.  
  2599.     For a full description, see section 4.2 of the windowing definition.
  2600.  
  2601.  
  2602. Q.  There are currently two proposals for KERMIT extensions: the Windowing
  2603.     extension and a proposal for extended packet lengths.  What are the
  2604.     relative advantages and disadvantages of sliding windows and extended
  2605.     packet lengths?
  2606.  
  2607. A.  What is best depends on the exact conditions and systems involved in a
  2608.     particular file transfer.  There are some general rules however.
  2609.  
  2610.     Windowing helps more and more as the communications path delays get
  2611.     longer.
  2612.  
  2613.     Windowing is also more and more helpful as the baud rate goes up.
  2614.  
  2615.     Increased packet length is most helpful on circuits with low error
  2616.     rates.  If the error rate is high, it is difficult for a long packet
  2617.     to get through uncorrupted.  Also, it then takes longer to re-transmit
  2618.     the corrupted packet.
  2619.  
  2620.     On some machines, the CPU time to process a packet is relatively
  2621.     constant no matter what the packet length, so longer packets can
  2622.     reduce CPU time.
  2623.  
  2624.  
  2625. Q.  Are extended packet lengths and sliding windows mutually exlusive?
  2626.  
  2627. A.  No, there is no real reason that they would have to be.  As a
  2628.     practical matter, it is slightly easier to implement windowing if you
  2629.     know the maximum packet size ahead of time, since you can then just
  2630.     use an array to store your data.  In standard KERMIT, you know
  2631.     automactically that your maximum packet length is 94, so you can just
  2632.     go ahead and dimension an array at 94 by Window-size.
  2633.  
  2634.  
  2635. Page 48                                                INFO-KERMIT DIGEST V3 #8
  2636.  
  2637.     If you are going to use both extended packet length and windowing, you
  2638.     need to select the maximum packet length and window-size so that the
  2639.     combination does not exceed the available memory for each side of the
  2640.     transfer.
  2641.  
  2642.     In addition, it is possible to see the desired relationship between
  2643.     packet size and windowing for various baud rates and communications
  2644.     delays.  For the common case of an error corrected by one
  2645.     retransmission of the corrupted packet, the minimum window size needed
  2646.     for continuous throughput (the window never gets "blocked") can be
  2647.     calculated by:
  2648.  
  2649.                     4 x delay x baud rate
  2650.       WS  >   1 +  ------------------------
  2651.                        packet-size x 10           ;(this is the # of bits)
  2652.  
  2653.  
  2654.     Windowing always helps (the minimal continuous throughput window size
  2655.     is always greater than 1).
  2656.  
  2657.     In the above equation, the "4" derives from the fact that a corrupted
  2658.     packet has 4 transit times involved:
  2659.  
  2660.          Original (bad checksum) packet
  2661.          NAK for the packet
  2662.          Retransmission of packet
  2663.          ACK for retransmission.
  2664.  
  2665.     All of this must happen before the window becomes blocked.
  2666.  
  2667.     The "delay" is the effective maximum one-way communications path
  2668.     delay, which includes any CPU delays.
  2669.  
  2670.     Strictly speaking, the "packet-size" should have the length of the ACK
  2671.     packets added to it.
  2672.  
  2673.     As an example, if you assume a 2-second (one-way) delay, at 1200 baud,
  2674.     with a packet size of 94, the minimum window size for continuous
  2675.     throughput would be:
  2676.  
  2677.               4 x 2 x 1200
  2678.        WS  >  ------------    =   10.2
  2679.                 94 x 10
  2680.  
  2681.     Under these circumstances, a window size of at least 11 should be
  2682.     chosen, if possible.
  2683.  
  2684.  
  2685. ------------------------------
  2686.  
  2687. Date: Sat, 20 Jul 85 10:47:19 PDT
  2688. From: VSS7853@UCLAVM
  2689. Subject: Conversion Tables, Liberalized Requirements
  2690. Keywords: ASCII/EBCDIC Translation Tables
  2691.  
  2692. Regarding the message I sent the other day with the programs for
  2693.  
  2694. INFO-KERMIT DIGEST V3 #8                                                Page 49
  2695.  
  2696. constructing and analyzing ATOE and ETOA tables, I think I could have
  2697. expressed my thesis a bit more clearly.
  2698.  
  2699. Kermit-TSO and Kermit-CMS require that the TCAM (or whatever) tables
  2700. be, loosely speaking, inverses of one another.  I claim that this
  2701. requirement is too restrictive and prevents Kermit from working on
  2702. systems where it otherwise might.
  2703.  
  2704. On Ebcdic machines, Kermit performs the following four translations:
  2705.  
  2706. 1. (e to a) predict the Ascii form of an outgoing message so that a packet
  2707.             can be constructed in Ascii.
  2708. 2. (a to e) map the packet back to Ebcdic for outputting and final
  2709.             reconversion by TCAM.
  2710. 3. (e to a) reconstruct the Ascii form of an incoming packet already
  2711.             converted by TCAM, so that the packet can be analyzed in Ascii.
  2712. 4. (a to e) map the incoming message back into its final Ebcdic form.
  2713.  
  2714. Presently these four internal transformations are done with only two tables,
  2715. each identical to the corresponding TCAM table.  Whence the requirement that
  2716. the two TCAM tables be inverses of one another.
  2717.  
  2718. I claim that by constructing four tables, one for each of the above numbered
  2719. functions, two benefits would accrue:
  2720.  
  2721. 1. The requirements on the TCAM tables would be weakened.  Each table would
  2722.    have to be invertable separately, but they would no longer have to be
  2723.    inverses of each other.
  2724.  
  2725. 2. Kermit could guarantee a standard correspondance between the two character
  2726.    codes for messages transmitted from Ascii machines to Ebcdic and vice
  2727.    versa, instead of accepting the correspondance imposed by the local TCAM
  2728.    tables.
  2729.  
  2730. In the other message I attempted to give precise weakened mathematical
  2731. requirements for the TCAM tables so that this method would work.
  2732.  
  2733. Also tools would have to be developed to construct the necessary translation
  2734. tables to be used by Kermit.  These tools ought to be included in the
  2735. distribution.
  2736.  
  2737. What do you think?
  2738.  
  2739. Glenn Thobe
  2740. EE dept., UCLA
  2741. 818-888-8434
  2742.  
  2743. p. s. Please address replies to both IVA3GET@UCLAMVS and VSS7853@UCLAVM
  2744. (BITNET).
  2745.  
  2746. ------------------------------
  2747.  
  2748. Date: Mon 22 Jul 85 16:55:26-EDT
  2749. From: Charlie C Kim <US.CCK@CU20B>
  2750. Subject: IBM Professional Graphics Controller
  2751. Keywords: Professional Graphics Card
  2752.  
  2753. Page 50                                                INFO-KERMIT DIGEST V3 #8
  2754.  
  2755.  
  2756. It's called a Professional Graphics Controller (not Adapter).  Waiting for
  2757. the vertical retrace on the EGA isn't a bad thing to do--it's just
  2758. unnecessary in the enhanced mode.  It isn't so clear that it's the wrong
  2759. thing to do when it is emulating the CGA.
  2760.  
  2761. The problem with losing characters above 1200 baud on the PGC is well known.
  2762. The following message from the IBM-PC bulletin board should clarify the
  2763. issue:
  2764.  
  2765.   Date:  Thu, 4 Jul 85 13:54 EDT
  2766.   From:  "Roger C. King" <RCKing@MIT-MULTICS.ARPA>
  2767.   Subject:  Professional Graphics Controller Fix
  2768.  
  2769. We have had IBM replace more than a dozen Professional Graphics controllers
  2770. with corrected units which work correctly with previous communications
  2771. packages at 9600 baud. The old unit did not work correctly at all, but sort
  2772. of worked on an AT at 2400 baud (sort of means some dropped characters) and
  2773. sort of worked on an XT at 1200 baud. It takes an individual, case by case,
  2774. interface with IBM to get this resolved, but it is possible for a field
  2775. office to get someone at Boca to send out corrected boards for a swap. A
  2776. good controller can be recognized as follows:
  2777.  
  2778.     Looking at a controller with the output on the right, the top left
  2779.     corner of the board has a 'REV' number, probably 6323698, whited out
  2780.     with white paint or something similar. A bad board(s), does not have
  2781.     this number modified.
  2782.  
  2783. As an aside, we have found the Professional Graphics Controller to be an
  2784. almost perfect emulator of the old Color Graphics controller. Even
  2785. low-res software seems to work correctly.
  2786.  
  2787. Roger King
  2788.  
  2789. ------------------------------
  2790.  
  2791. From: Herm Fischer <hermix!fischer@RAND-UNIX>
  2792. Subject: Professional Graphics Controller
  2793. Date: Mon Jul 22 16:02:42 1985
  2794. Keywords: Professional Graphics Card
  2795.  
  2796. Carl Houseman reports problems over 1200 baud with this display.  He should
  2797. be aware that the async ports dont work over 1200 at all unless he gets
  2798. replacement PGA cards from IBM.  The original cards had hardware/firmware
  2799. problems which interfered with comm activity; IBM has "recalled" those
  2800. cards.
  2801.  
  2802. I am using the EGA on Xenix and on MSDOS with kermit.  So far no problems,
  2803. but have not tried EGA with MSDOS above 1200...
  2804.  
  2805. ------------------------------
  2806.  
  2807. Date: 23 July 1985 1350-PDT (Tuesday)
  2808. From: germar@nprdc.arpa (Marcelo Germar)
  2809. Subject: Using Kermit with Ungermann-Bass Net One?
  2810. Keywords: Ungermann-Bass Net One
  2811.  
  2812. INFO-KERMIT DIGEST V3 #8                                                Page 51
  2813.  
  2814.  
  2815. Does anybody have experience using ibm pc kermit with ungermann-bass net one
  2816. to transfer files between a vax with 4.2bsd unix and an ibm pc?
  2817.  
  2818. What should be the configuration of the ungermann-bass hardware/software
  2819. to enable a successful file transfer?
  2820.  
  2821. All your help will be sincerely much appreciated.
  2822.  
  2823. thanks,
  2824. marcelo
  2825.  
  2826. ------------------------------
  2827.  
  2828. End of Info-Kermit Digest
  2829.  
  2830. Page 52                                                INFO-KERMIT DIGEST V3 #9
  2831.  
  2832. Info-Kermit Digest         Fri, 26 Jul 1985       Volume 3 : Number  9
  2833.  
  2834. Departments:
  2835.  
  2836.   ANNOUNCEMENTS -
  2837.     Kermit for the PDP-8
  2838.  
  2839.   PROPOSAL FEEDBACK -
  2840.     Lurching Windows?
  2841.     About the New Proposals
  2842.     Kermit Windowing Questions and Answers...Continued
  2843.  
  2844.   MISCELLANY -
  2845.     Tranferring a MacPaint or MacDraw Document
  2846.     MS-Kermit and the Hercules Monochrome Graphics Card
  2847.  
  2848. ----------------------------------------------------------------------
  2849.  
  2850. Date: Fri 26 Jul 85 17:07:42-EDT
  2851. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  2852. Subject: Kermit for the PDP-8
  2853. Keywords: PDP-8 Kermit
  2854.  
  2855. This is to announce Kermit-8 for the DEC PDP-8 with OS8 or RTS8, written in
  2856. the PAL-8 assember by Jerry Sands and Randy Hippe of the Bureau of
  2857. Engraving, Inc., Minneapolis, MN.  It works in local mode only, includes
  2858. CONNECT, BYE, EXIT, SEND, GET, and RECEIVE commands, and can do wildcard
  2859. sends.  There is no documentation to speak of.  The program is in
  2860. K2:K08MIT.PAL (and .HLP) on CU20B, available via anonymous FTP.
  2861.  
  2862. This means that Kermit is now available for every single existing DEC
  2863. machine operating system, with the exception of IAS-11 (soon to be
  2864. contributed, I hope).  (I hope there aren't any PDP-1's, -4's, -6's, -7's,
  2865. 9's, -12's, or 15's left out there...  If you have one, why haven't you
  2866. written Kermit for it?)  And if you count WPS-8 as an operating system,
  2867. maybe someone who knows something about it could convert this program for
  2868. the benefit all the poor DECmate users who need to transfer their WPS
  2869. "documents" to systems that don't have DX.
  2870.  
  2871. ------------------------------
  2872.  
  2873. Date: Thu, 25 Jul 85 12:49:49 pdt
  2874. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  2875. Subject: Lurching Windows?
  2876. Keywords: Lurching Windows
  2877.  
  2878. I didn't see any discussion of how to extend this to half-duplex lines
  2879. ("lurching windows").  Is any forthcoming?
  2880.  
  2881. Ken Poulton
  2882.  
  2883. [Ed. - See below.]
  2884.  
  2885. ------------------------------
  2886.  
  2887. Date: 24 Jul 1985 1257-EDT
  2888.  
  2889. INFO-KERMIT DIGEST V3 #9                                                Page 53
  2890.  
  2891. From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
  2892. Subject: About the New Proposals
  2893. Keywords: Kermit Protocol Proposal
  2894.  
  2895. Yes, I have seen the stuff only "fly by" on the screen - so my comments will
  2896. be "fast and [maybe] not fully founded".  [By the way, I like both proposals
  2897. and believe, they both will work together.]
  2898.  
  2899. I would like to introduce the "bulk" ACK from the Receiver [didn't see that
  2900. mentioned - or "lost it on the screen"], i.e. the Receiver has the freedom
  2901. to "ACK" every X packets, where X can be between 1 and the agreed upon
  2902. maximum window-size.
  2903.  
  2904. Receipt of the "BULK" ACK forces a "sliding" of the SENDER's window, so that
  2905. it "starts" after receipt with the next packet.
  2906.  
  2907. The Receiver will discard packets with packet-nr's LESS than current "BULK"
  2908. ACK and "BULK" ACK minus MAX Window-size.  I will regard receipt of packets
  2909. with even smaller numbers a "serious errror" - i.e. stop receiving.
  2910.  
  2911. [To be "discussed more" : It might be also a good rule to FORCE an ACK on the
  2912. last two PACKETS BEFORE crossing the 64-magic to make sure, that the SENDER's
  2913. window slides nicely..]
  2914.  
  2915. I believe, that the above rules "get rid" of the receivers duty to keep a
  2916. "table" plus a relatively large buffer - it also leaves it open for the
  2917. receiver to "write to the 'disk' whenever he feels necessary"
  2918.  
  2919. It doesn't complicate SENDER behaviour - but the hightest overall "gain" is
  2920. anyhow at the 90% of down-loads from distribution-points, which typically
  2921. are slightly larger than "micro's" - and can afford the "extra" coding.
  2922.  
  2923. It also [as a side effect] eases handling of "larger packets" on the micro
  2924. [I just hate to debug the logic of a "floating table" depending on memory-
  2925. limits {relatively easy} plus "agreed upon" package size {slightly more
  2926. muggy} aggravated by [either] unexpected RE-Sends because I was too long
  2927. occupied didling the floppy or expected - i.e. I saw a bad packet , sent
  2928. a NAK but was not allowed to "throw away the rest".
  2929.  
  2930. Which leads to an "addendum" for the SENDER - all in the view of keeping
  2931. the coding EASY for all the micro-versions...
  2932.  
  2933. On receipt of a NAK - all PACKETS INCLUDING the NAKed one and [maybe already
  2934. sent other ones] will be re-sent.
  2935.  
  2936. If we are clever - remember the "bulk" number for the ACK didn't have to be
  2937. established - we can "train" the receiver to "trim down" the "bulk" number
  2938. depending on the amount of NAKs per X packets - thereby allowing a "macro"
  2939. adjustment to line-quality.
  2940.  
  2941. I will not go into "calculations" - but as a rule of thumb:
  2942.  
  2943. On SLOW channels [300 Baud] - there typically will be only ONE MORE packet
  2944. sent after the receiver sees the NAK - and its NOW the msg "Lets redo it
  2945. after the last good one" - so thats tolerable.
  2946.  
  2947.  
  2948. Page 54                                                INFO-KERMIT DIGEST V3 #9
  2949.  
  2950. On "faster" channels [4800 Baud and UP] - there "might be" another packet
  2951. "sneaking in" - but "channel quality" typically tends to be better anyhow,
  2952. so "better quality" and "higher speed" make the overhead of above
  2953. simplification tolerable again.
  2954.  
  2955. ... and last not least - one probably can even under CP/M with ist 64K
  2956. limitation handle both LARGER PACKETS and "floating ACKs"
  2957.  
  2958. Rgds,
  2959. Bernie.
  2960.  
  2961. --------------------------------------
  2962.  
  2963. Date: Fri 26 Jul 85 16:50:48-EDT
  2964. From: Leslie Spira <OC.SOURCE@CU20B.ARPA>
  2965. Subject: KERMIT Windowing Questions and Answers...continued.
  2966. Keywords: Sliding Windows Kermit
  2967.  
  2968. FORWARD:
  2969.  
  2970. The two proposed extensions to KERMIT, Windowing and Extended Packet
  2971. Length, are both useful.  They seem to me to be complementary, and each
  2972. solves certain problems that the other cannot.
  2973.  
  2974. The purpose for the development of the windowing protocol was to solve the
  2975. problem of how to increase throughput over circuits with long delays that
  2976. also had a potentially noisy section of the circuit.
  2977.  
  2978. The discussion of the Windowing protocol, and of Extended Packet Lengths,
  2979. should keep in mind the environments in which each would be useful.  In
  2980. some cases, a combination would provide optimum performance.
  2981.  
  2982. The extensions will only be implemented for situations that make sense.
  2983. In all cases, KERMIT Classic will still be available, with all its utility
  2984. of being able to handle varied enviroments.
  2985.  
  2986. While reading the following questions and answers, keep in mind that this
  2987. windowing definiton was developed to handle a common situation of long
  2988. circuit delays with possible moderate error rates.  KERMIT does not need
  2989. this type of extension for clean lines with insignificant delays - KERMIT
  2990. could be left alone, or use Extended Packet Lengths, in such environments.
  2991.  
  2992. Long delays with significant error rates will occur under two obvious and
  2993. common conditions:
  2994.  
  2995.     A.   Local phone line (of uncertain quality) to Public Data Networks
  2996.          (such as Telenet).
  2997.  
  2998.     B.   Satellite phone links.  These often occur with the lower-priced
  2999.          phone services, which often also have noisier lines.  In
  3000.          addition, satellite links will increase as more people need to
  3001.          transfer data overseas.
  3002.  
  3003. The above conditions will become more common, as well increased baud
  3004. rates, which make the delays more significant.
  3005.  
  3006.  
  3007. INFO-KERMIT DIGEST V3 #9                                                Page 55
  3008.  
  3009. As an aside, note that the benefit of Extended Packet Lengths over the
  3010. Public Data Networks is limited by the number of outstanding bytes the PDN
  3011. allows.  (Internally, the PDNs require end-to-end acknowledgement.  They
  3012. use their own windowing system within the network.)  I don't currently
  3013. know the exact impact of this.
  3014.  
  3015. Now on to the questions...
  3016.  
  3017. Q.  Can sliding windows be done on half-duplex channels?  Are any
  3018.     modifications to the proposal required?
  3019.  
  3020. A.  An underlying assumption in the development of windowing was that
  3021.     there was a full-duplex channel.  (See section 5.4, "Low Level
  3022.     Protocol Requirements")
  3023.  
  3024.     The intent of windowing is to try to keep the sender continuously
  3025.     sending data.  Obviously, this is not possible on a half-duplex
  3026.     channel.  A better solution for half-duplex channels would be to use
  3027.     an extended packet length.
  3028.  
  3029.     An attempt to use windowing on half-duplex really is just a way of
  3030.     doing extended packet lengths.  The sender would send out a group of
  3031.     packets, then wait and get a group of ACKS.  It would be better to
  3032.     simply send out a large packet, which would have less overhead.
  3033.  
  3034.  
  3035. Q.  Is the cost in complexity for sliding windows worth the increase in
  3036.     performance?
  3037.  
  3038. A.  Under the conditions described above (long delays and possibly
  3039.     significant error rates) windowing can increase performance by a
  3040.     factor of 2, 3, or more, especially at higher baud rates.  This
  3041.     increase is necessary to make KERMIT viable under some conditions.
  3042.     With classic KERMIT over the Public Data Networks, I have had
  3043.     througput as low as 250 baud over a 1200 baud circuit (with a
  3044.     negligible error rate).  Windowing should allow throughput close to
  3045.     the maximum baud rate.
  3046.  
  3047.     Windowing is most helpful when the delay is significant in relation to
  3048.     data sending time.  Any delay becomes more significant as users move
  3049.     to higher baud rates (2400 baud and beyond).
  3050.  
  3051.     The complexity of implementing windowing has yet to be fully
  3052.     evaluated.  The first implementation (for the IBM PC using C-KERMIT)
  3053.     proved to be fairly manageable.  It appears that the windowing logic
  3054.     can be implemented so that KERMIT Classic uses the same code, but with
  3055.     a window size of 1, which should avoid having to keep separate
  3056.     sections of code.
  3057.  
  3058.     The windowing definiton was developed with the idea of keeping changes
  3059.     to KERMIT to a minimum.  No new packet types were developed, ACKs and
  3060.     NAKS were kept the same, and windowing is in effect only during actual
  3061.     data transfer (D packets).  We tried to define the protocol so that a
  3062.     window size of 1 was the same as the current classic KERMIT.
  3063.  
  3064.     These factors should help reduce the complexity of implementing
  3065.  
  3066. Page 56                                                INFO-KERMIT DIGEST V3 #9
  3067.  
  3068.     windowing.  We currently have a working implementation of KERMIT for
  3069.     the IBM PC going through testing.
  3070.  
  3071.     It's fun to see the modem "Send" light stay on constantly!
  3072.  
  3073.  
  3074. Q.  Why doesn't the Windowing proposal use a "bulk ACK"?
  3075.  
  3076. A.  There are a couple of possibilities for ways to use some sort of
  3077.     "bulk" or combined ACK.  We looked at them when developing the
  3078.     Windowing definition.  We did not see any advantages that outweighed
  3079.     the disadvantages.
  3080.  
  3081.     Here are two possible ways of changing how ACKs would work:
  3082.  
  3083.     1.   An ACK for any packet would also ACK all previous packets.
  3084.  
  3085.     2.   A new "Bulk ACK" (BAK?) packet could be developed.
  3086.  
  3087.  1. The concept that an ACK would also ACK all previous packets seems
  3088.     attractive at first, since it would appear to reduce overhead.
  3089.     However, it has a major drawback in that you then must re-synch when
  3090.     you get errors.  This is because, once you have an error, you have to
  3091.     send a NAK, then stop and wait for a re-transmission of the NAKed
  3092.     packet, before you send out any more ACKs.  (If you sent out an ACK
  3093.     for a later packet, it would imply that you had received the NAKed
  3094.     packet.  Not until you safely get the re-transmission can you go ahead.)
  3095.  
  3096.     This would negate one of the nicest parts of windowing as it is
  3097.     defined now, which is that the sender can transmit continuously,
  3098.     including during error recovery, as long as the window does not become
  3099.     blocked.
  3100.  
  3101.     It does not appear to us that the reduction in the number of ACKs sent
  3102.     is worth this penalty.
  3103.  
  3104.     In addition, this is a departure from the way ACKs in KERMIT work
  3105.     now.  It seemed best to make as few changes to KERMIT as possible.  If
  3106.     this facility turns out to be useful, it would be better to introduce
  3107.     a new packet type (or other means of distinguishing regular ACKs from
  3108.     "Bulk ACKS").
  3109.  
  3110.  2. A new "Bulk ACK" packet type could be developed.  This did not seem to
  3111.     us to be a good idea, since it required defining a new packet type.
  3112.     We were trying to fit windowing in with as few changes to KERMIT as
  3113.     possible.
  3114.  
  3115.     A "Bulk ACK", in which one packet could contain a whole string of ACKs
  3116.     and NAKs, also seems like a good idea at first.  The penalty here is a
  3117.     little more subtle.  First, if you lose a "Bulk ACK" packet, you lose
  3118.     more information and it takes longer to get things flowing smoothly
  3119.     again.
  3120.  
  3121.     Second, and probably more importantly, efficient windowing depends on
  3122.     the window never becoming "blocked" (i.e., the sender can always keep
  3123.     sending).  A "Bulk ACK" interferes with this to some extent, because
  3124.  
  3125. INFO-KERMIT DIGEST V3 #9                                                Page 57
  3126.  
  3127.     if you have a long delay, the "Bulk ACK" with its multiple individual
  3128.     ACKs may not get back to the sender in time to prevent the window from
  3129.     becoming blocked.
  3130.  
  3131.     With the current definition of windowing, returning an ACK for each
  3132.     packet gets the ACKs (or NAKs) to the sender as soon as possible.
  3133.     This provides the best chance for keeping the window open so that the
  3134.     sender can transmit continually.
  3135.  
  3136.     Once again, remember the conditions under which windowing is most
  3137.     useful: long delays with significant error rates.  Under these
  3138.     conditions, individual ACKs have advantages.
  3139.  
  3140.     If these conditions don't apply, it may not be necessary to use
  3141.     windowing, or it may be better to use extended packet lengths.
  3142.  
  3143. ------------------------------
  3144.  
  3145. Date: Thu, 25 Jul 85 16:41:22 PDT
  3146. From: ucsfcca.ucsf!jd9014@ucsf-cgl.ARPA (Joe DeBattista)
  3147. Subject: Tranferring a MacPaint or MacDraw Document
  3148. Keywords: MacKermit
  3149.  
  3150. I have a question about whether it is possible to upload and/or download a
  3151. MacPaint or MacDraw document.  When I use macput or macget with Versaterm or
  3152. MacTerminal this works ok, as it seems to grab the data and resource files
  3153. together.  When I try to upload to our VAX 750, I can only specify the data
  3154. or resource from the settings menu.  When I try to download a macpaint
  3155. document, I tried sending the data file first and then the resource, but
  3156. that didn't work.  I've checked the MacKermit documentation for hints, and
  3157. have asked people around here if they have a solution.  I am currently
  3158. running version 08(32).  Thanks.
  3159.  
  3160.                                Joe DeBattista
  3161.                                BITNET: jd9014@ucsfcca
  3162.                                UUCP: ucbvax!ucsfcgl!ucsfcca.ucsf!jd9014
  3163.  
  3164. [Ed. - It says somewhere in the Mac Kermit documentation that you can only
  3165. send one fork of a file at a time.  I think what you need to do is send each
  3166. fork separately, giving each a different name (like FOO.DATA and FOO.RSRC).
  3167. When bringing them back to the Mac, get the two files separately, each into
  3168. the appropriate fork of the same file.  I realize this is less than
  3169. satisfactory, but Kermit was not designed to anticipate that a file could
  3170. actually have more than one part; the other programs you mentioned are
  3171. Mac-specific and designed to know about this.  In general, I think the
  3172. safest way to treat arbitrary Mac files is to run them through Binhex before
  3173. transmitting to a foreign system, and unBinhex them upon return.]
  3174.  
  3175. ------------------------------
  3176.  
  3177. Date:     Tue, 23 Jul 85 19:17:35 BST
  3178. From:     Ljwu@ucl-cs.arpa
  3179. Subject:  MS-Kermit and the Hercules Monochrome Graphics Card
  3180. Keywords: MS-DOS Kermit, Hercules Graphics Card
  3181.  
  3182. In response to query on MS-KERMIT with the Hercules card (vol 3
  3183.  
  3184. Page 58                                                INFO-KERMIT DIGEST V3 #9
  3185.  
  3186. #5), I must say that I have encountered no problems, at least with
  3187. version 2.27.  Our configuration is an XT, DOS 2.10, and a fully
  3188. populated QuadRam expansion card.  We dedicate 360K to a RAM disk
  3189. using AST support though.  Good luck!
  3190.  
  3191. Les Wu
  3192.  
  3193. ------------------------------
  3194.  
  3195. End of Info-Kermit Digest
  3196.  
  3197. INFO-KERMIT DIGEST V3 #10                                               Page 59
  3198.  
  3199. Info-Kermit Digest         Wed, 31 Jul 1985       Volume 3 : Number 10
  3200.  
  3201. Departments:
  3202.  
  3203.   ANNOUNCEMENTS -
  3204.     Summer Vacation
  3205.     Release 4C(057) of C-Kermit for Unix
  3206.     Update of Pascal/VS Kermit for IBM VM/CMS
  3207.  
  3208.   PROPOSAL FEEDBACK -
  3209.     Windows Considered Harmful
  3210.     Re: The New Proposals
  3211.  
  3212.   MISCELLANY -
  3213.     DDJ Article on Asynchronus Protocols
  3214.     TTSynch in VMS kermit
  3215.     VMS-Kermit and VMS 4.0
  3216.     Bug in Prime Kermit Shows Up with Kermit-MS 2.28
  3217.     Generic CP/M-80 Kermit Question (& Answer)
  3218.     Kermit-11 and IAS
  3219.  
  3220. ----------------------------------------------------------------------
  3221.  
  3222. Date: Wed 31 Jul 85 11:18:21-EDT
  3223. From: Frank da Cruz <SY.FDC@CU20B>
  3224. Subject: Summer Vacation
  3225.  
  3226. After this week, I'll be on vacation until the first week in September.
  3227. While I'm gone, some of the other people at Columbia will moderate the
  3228. Info-Kermit digest as time permits (we're all quite busy on other projects).
  3229. Let's keep the discussion of long packets and sliding windows going and see
  3230. if some concensus will emerge.  Meanwhile, address all Kermit-related
  3231. correspondence to Info-Kermit@CU20B or Info-Kermit-Request@CU20B, not to me
  3232. personally, so that it can be routed to whoever is handling the digest while
  3233. I'm gone.  - Frank
  3234.  
  3235. ------------------------------
  3236.  
  3237. Date: Mon 29 Jul 85 20:15:03-EDT
  3238. From: Frank da Cruz <SY.FDC@CU20B>
  3239. Subject: Release 4C(057) of C-Kermit for Unix
  3240. Keywords: C-Kermit, UNIX Kermit
  3241.  
  3242. This is to announce Yet Another Release of C-Kermit for Unix, 4C(057).
  3243. The changes, like last time, are minor:
  3244.  
  3245. . "set send packet-length" now overrides negotiated value, so that
  3246.   packet lengths in both directions can be controlled from one side.
  3247.  
  3248. . The Unix Kermit server now responds to all generic commands (but not
  3249.   "remote host" commands) in text mode, even if the file type is
  3250.   currently set to binary.  Remote host commands continue to obey the
  3251.   file type setting.
  3252.  
  3253. . Support for 4.1BSD, 2.9BSD, and BBN C/70 that was apparently broken
  3254.   in recent edits is (or should be) fixed again.
  3255.  
  3256. Page 60                                               INFO-KERMIT DIGEST V3 #10
  3257.  
  3258.  
  3259. . A bug that sometimes prevented 14-character filenames on non-4.2bsd
  3260.   systems from being recognized is fixed.
  3261.  
  3262. . Several other bugs fixed relating to modem control, dialing, etc.  But
  3263.   reportedly some problems still remain -- see the .BWR file.
  3264.  
  3265. Thanks to Herm Fischer and Dan Schullman for reporting and/or fixing the bugs
  3266. corrected by this release.  The files are in K2:CKU*.* and K2:CKC*.* on CU20B,
  3267. available via anonymous FTP.  CKUKER.UPD lists the changes in greater detail,
  3268. CKUKER.BWR lists the known bugs and restrictions, CKUKER.DOC (and .MSS) is an
  3269. updated Kermit User Guide manual chapter.
  3270.  
  3271. This should be the last release of C-Kermit until some time in September.
  3272. In the meantime, send suggestions, comments, complaints, bug reports and fixes
  3273. to Info-Kermit@CU20B, as usual.
  3274.  
  3275. ------------------------------
  3276.  
  3277. Date:    Mon, 29 Jul 85 11:23 EDT
  3278. From:    VIC@QUCDN.BITNET
  3279. Subject: Update of Pascal/VS Kermit for IBM VM/CMS
  3280. Keywords: VM/CMS Pascal Kermit
  3281.  
  3282. I have made a few changes to the Pascal/VS version of Kermit-CMS to correct a
  3283. few bugs.  So I am sending you updated source code for it.
  3284.  
  3285. Victor Lee, Queen's University
  3286.  
  3287. [Ed. - The updated program is in K2:CM2MIT.*.]
  3288.  
  3289. ------------------------------
  3290.  
  3291. Date: Tue, 23-Jul-85 11:44:51 xDT
  3292. From: (anonymous)
  3293. Subject: Windows Considered Harmful
  3294. Keywords: Sliding Windows Kermit
  3295.  
  3296. The windowing stuff looks far too complex; I think it will greatly
  3297. decrease one of the Kermit's main points -- its fundamental simplicity.
  3298. The interrupt stuff to make such things work can be a tremendous pain on
  3299. many systems, and it really is probably not worth the effort.
  3300.  
  3301. Large packets are OK, but I don't think people are going to see as much
  3302. of an advantage as they think, even on long hauls.
  3303.  
  3304. With every one of these mods, things get a little less compatible and a
  3305. little less universal.  I personally think that efforts in this area are
  3306. starting to show signs of "feature-itis" that would best be avoided.
  3307.  
  3308. ------------------------------
  3309.  
  3310. Date:  Sat, 27 Jul 85 00:48 EDT
  3311. From:  Bakin@MIT-MULTICS.ARPA
  3312. Subject:  Re: The New Proposals
  3313. Keywords: Kermit Protocol Proposal, Sliding Windows Kermit, Long Packets
  3314.  
  3315. INFO-KERMIT DIGEST V3 #10                                               Page 61
  3316.  
  3317.  
  3318. Hi.  I vote for both proposals, in my environment I can use both, though
  3319. probably separately.  The sliding window proposal would be great for our
  3320. communications Boston -> Tymnet -> Transpac -> Versailles which is plagued
  3321. by long long delay ... and won't allow long packets either.  Meanwhile, in
  3322. house our poor VAX is swamped when Kermit is going at 9600 baud due to
  3323. its lousy TTY input interrupt handling (per character) and at least long
  3324. packets would reduce the number of task switches and I suspect lead to
  3325. better interactive performance for the non-Kermit users.  Assuming of course
  3326. it'll eat a long package without losing characters ... that remains to be
  3327. tested.  [Anyway, the easiest way to test it would be for someone else
  3328. to implement long packets in Kermit and then ...]
  3329.  
  3330. I wanted to point out that although in kermit-digest V3 #9 it
  3331. was mentioned that long packets wouldn't be good given fast error-free
  3332. communication I disagree:  I think timesharing hosts would benefit by the
  3333. fewer task switches from OS read to application Kermit.
  3334.  
  3335. -- Dave (Bakin -at mit-multics)
  3336.  
  3337. ------------------------------
  3338.  
  3339. Date: Wed 31 Jul 85 01:28:11-PDT
  3340. From: Bob Larson <BLARSON%ECLD@ECLA>
  3341. Subject: DDJ Article on Asynchronus Protocols
  3342. Keywords: Asyncronous Protocols
  3343.  
  3344. Kermit is mentioned in the article "Asynchronous Protocols" in the
  3345. August 1985 issue of Doctor Dobbs Journal.  The article is an overview
  3346. of several asyncronous protocols.
  3347.  
  3348. It does state "It [Kermit] may become a widely used standard in the near
  3349. future," but devotes much more space to discussing versions of [x]modem[7].
  3350.  
  3351. Bob Larson <Blarson@Usc-Ecl.Arpa>
  3352.  
  3353. ------------------------------
  3354.  
  3355. Date: Mon, 22 Jul 85 09:11:50 edt
  3356. From: Steve Archer <archer@rochester.arpa>
  3357. Subject: TTSynch in VMS kermit
  3358. Keywords: VMS Kermit
  3359.  
  3360. We find here locally, that we have to do a 'set term /noTTSynch' before
  3361. we use the VMS kermit with any half duplex machine that uses Xon/Xoff
  3362. protocol.  Apparently the machines that VMS kermit was written for are that
  3363. way by default.  Having to do the set term confuses many of our casual
  3364. users of kermit.  Kermit could very easily do this automatically for the
  3365. user.  Could this be incorporated in the next VMS kermit release?
  3366.  
  3367. steve {seismo,allegra}!rochester!kodak!archer
  3368.  
  3369. ------------------------------
  3370.  
  3371. Date: Thu, 25 Jul 85 09:33:31 edt
  3372. From: <decvax!cincy!schulz@Purdue.EDU>
  3373.  
  3374. Page 62                                               INFO-KERMIT DIGEST V3 #10
  3375.  
  3376. Subject: VMS-Kermit and VMS 4.0
  3377. Keywords: VMS Kermit
  3378.  
  3379. VMS-Kermit (Version 3.1.066) was running fine under VMS 3.6, but shows
  3380. annoying habits under 4.0: in connect mode, long outputs from the remote
  3381. host are echoed by ^G (BEL) (going to the remote host). This obviously
  3382. confuses the remote host. I conjecture that the bell is the same as
  3383. the one now heard on logging in. (We set the line protections of regular
  3384. terminal lines so that they can be allocated by WORLD.)
  3385.  
  3386. I would be grateful for any suggestions.
  3387.  
  3388. Henning Schulz-Rinne
  3389. Univ. of Cincinnati
  3390.  
  3391. ------------------------------
  3392.  
  3393. Date:     Friday, 26 Jul 85 17:11:47 EDT
  3394. From:     rmcqueen (Robert C McQueen) @ sitvxb.CCNET
  3395. Subject:  Re: VMS Kermit Problems
  3396. Keywords: VMS Kermit
  3397.  
  3398. Ok, noted.  First person to have free time will look into them.
  3399.  
  3400. ------------------------------
  3401.  
  3402. Date: 26 Jul 85 09:15:06 ADT
  3403. From: CGP@UNBMVS1
  3404. Subject: Bug in Prime Kermit Shows Up with Kermit-MS 2.28
  3405. Keywords: Prime Kermit, MS-DOS Kermit
  3406.  
  3407. Prime Kermit can not be used in server mode with Kermit-MS 2.28.
  3408. The problem is that Prime kermit NAKs the Init-Info packet, instead of
  3409. responding with an Error packet as specified in the Protocol Manual.
  3410.  
  3411. Kermit-MS 2.26 does not seem to use the Init-Info packet, and did
  3412. work with Prime Kermit.  I have not tested it with 2.27.
  3413.  
  3414. I have modified Prime Kermit to honor the Init-info packet.  What is the best
  3415. way to forward the corrected source?
  3416.  
  3417.                              Carl Pottle
  3418.                              University of New Brunswick
  3419.                              Saint John, N.B.
  3420.                              Canada
  3421.                              CGP@UNBMVS1
  3422.  
  3423. [Ed. - Just send the new code by electronic mail to Info-Kermit@CU20B.]
  3424.  
  3425. ------------------------------
  3426.  
  3427. Date: 16 Jun 1985 11:33:08 EDT (Sunday)
  3428. From: Tom Reid (MS W932) <treid@mitre-gateway>
  3429. Subject: Generic CP/M-80 Kermit Question
  3430. Keywords: CP/M-80 Kermit
  3431.  
  3432.  
  3433. INFO-KERMIT DIGEST V3 #10                                               Page 63
  3434.  
  3435. To make a long, sad story short, I have an Ithaca Intersystems Z80/CPM
  3436. system with an interrupt driven serial board.  This makes the usual
  3437. direct port addressing schemes of communication packages impossible
  3438. to install.  Generic Kermit's only requirement of an installed IOBYTE
  3439. seemed a perfect solution.
  3440.  
  3441. However, Kermit goes direct to the devices crt:, tty:, etc. rather than
  3442. at the virtual CON:, RDR:, and PUN:.  I have tried to hook the II to a
  3443. Kaypro 2x direct connect through the modem port and with the KP being the
  3444. II's terminal.  (As a terminal, it is fine, but cannot establish
  3445. communication when a file transfer is initiated).
  3446.  
  3447. Any ideas of how to proceed from here?  Thank you in advance for your
  3448. help.  Please reply directly to me as I am not on the info-kermit mailing
  3449. list.  If there is interest, I will summarize and post any replies
  3450. and solutions to info-kermit.  Tom Reid.
  3451.  
  3452. ------------------------------
  3453.  
  3454. Date: 27 Jul 1985 00:12 PST
  3455. From: Charles Carvalho <CHARLES@ACC>
  3456. Subject: Re: Generic CP/M-80 Kermit Question
  3457. Keywords: CP/M-80 Kermit
  3458.  
  3459. Generic Kermit has to know what physical devices are in use because the
  3460. only way it can test the modem port for data available is to make it the
  3461. console and use the "get console status" bdos call.
  3462.  
  3463. The console port and the modem port must be different ports; if your
  3464. system doesn't have a builtin console, you'll need a terminal connected
  3465. to the console port, and the Kaypro connected to the serial port.
  3466.  
  3467. Given the physical device names (TTY/CRT/UC1/PTR/etc) of the console port
  3468. and the serial port, the proper argument for the SET PORT command may
  3469. be found in the CP/M Kermit chapter of the User's Manual.  /Charles
  3470.  
  3471. ------------------------------
  3472.  
  3473. Date: 30 JUL 85 10:52-EST
  3474. From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
  3475. Subject: Kermit-11 and IAS
  3476. Keywords: Kermit-11, IAS
  3477.  
  3478. Status of Kermit-11 for IAS v3.1:
  3479.  
  3480. I have just talked with an EPA site and they plan to have Kermit-11
  3481. running on IAS 3.1 by Sep 1. This version of Kermit-11 will not be able to
  3482. do wildcard file operations (at least at first) and some of the mcr/dcl
  3483. interface will be lost. Addtionally, sources will be separate from
  3484. Kermit-11's source as IAS 3.1 does not support some of the assembler
  3485. directives I used thus forcing the EPA to merg some source files and make
  3486. other minor (but very numerous) changes.  They are working from a very
  3487. recent copy of Kermit-11, so there should otherwise be a good measure of
  3488. compatibility.
  3489.  
  3490.                                                 brian nelson
  3491.  
  3492. Page 64                                               INFO-KERMIT DIGEST V3 #10
  3493.  
  3494.                                                 brian@uoft02.bitnet
  3495.  
  3496. ------------------------------
  3497.  
  3498. End of Info-Kermit Digest
  3499.  
  3500. INFO-KERMIT DIGEST V3 #11                                               Page 65
  3501.  
  3502. Info-Kermit Digest         Thu,  1 Aug 1985       Volume 3 : Number 11
  3503.  
  3504. SPECIAL SLIDING WINDOWS ISSUE --
  3505.     Comments on Comments on Lurching Windows
  3506.     Sliding Windows -- When to Write to Disk?
  3507.     Mutual Exclusivity of Sliding Windows and Long Packets?
  3508.     Implied ACKs, Half Duplex Windows
  3509.     Full-Duplex Windowing vs CP/M, et al
  3510.     Proposal for Half Duplex Windows
  3511.     Examination of Proposals
  3512.     Full Duplex Sliding Windows -- Let's Give Them a Try
  3513.  
  3514. ----------------------------------------------------------------------
  3515.  
  3516.  
  3517. Date: Sun, 28 Jul 85 21:32:40 pdt
  3518. From: "Scott Weikart; Community Data Processing;
  3519.  415-322-9069" <cdp!scott@Glacier>
  3520. Subject: Comments on Comments on Lurching Windows
  3521. Keywords: Sliding Windows Kermit
  3522.  
  3523. > Date: Fri 26 Jul 85 16:50:48-EDT
  3524. > From: Leslie Spira <OC.SOURCE@CU20B.ARPA>
  3525. > Subject: KERMIT Windowing Questions and Answers...continued.
  3526. >
  3527. >     The intent of windowing is to try to keep the sender continuously
  3528. >     sending data.  Obviously, this is not possible on a half-duplex
  3529. >     channel.  A better solution for half-duplex channels would be to use
  3530. >     an extended packet length.
  3531. >
  3532. >     An attempt to use windowing on half-duplex really is just a way of
  3533. >     doing extended packet lengths.  The sender would send out a group of
  3534. >     packets, then wait and get a group of ACKS.  It would be better to
  3535. >     simply send out a large packet, which would have less overhead.
  3536.  
  3537. Actually, this is not quite true.  If the channel is noisy, then longer
  3538. packets won't increase the data rate.  Tha advantage of a lurching window
  3539. scheme is that the receiver could NAK all the small packets that didn't
  3540. make it, and then the sender could resend the NAKed packets plus some new
  3541. packets in the next bundle.
  3542.  
  3543. I think that lurching windows would be a good idea.
  3544.  
  3545. -scott
  3546.  
  3547. ------------------------------
  3548.  
  3549. Date: Thu, 850725 15:11:20-EDT
  3550. From:   Peter Marshall  <21-111@uwo-d10.UWO>
  3551. Subject: Sliding Windows -- When to Write to Disk?
  3552. Keywords: Sliding Windows Kermit
  3553.  
  3554. I would like to add a question to the group produced by John Mulligan
  3555. produced in a recent Kermit-digest.  I wonder if someone could explain
  3556. why it would be so much more difficult to write a received packet to
  3557. disk, when you have correctly received it?  His explaination does not
  3558.  
  3559. Page 66                                               INFO-KERMIT DIGEST V3 #11
  3560.  
  3561. make sense to me.  Just because you write a packet to disk does not mean
  3562. that you have to clear it from the receive table at that time.  When you
  3563. actually clear the oldest message from the receive table for a new
  3564. message, then you can be assured that the sender has received the ACK.
  3565. So I don't see his argument about keeping things synchronized.  The ACKed
  3566. flag  in the table could also act as a "written to disk" flag.
  3567.  
  3568. Is it not a little unsafe to assume that you have received a packet
  3569. correctly (and send off an ACK to that effect) until you have actually
  3570. got it safely to disk?
  3571.  
  3572. ------------------------------
  3573.  
  3574. Date: Tue, 30 Jul 85 20:41:16 EDT
  3575. From: RAF@UMDC.BITNET
  3576. Subject: Mutual Exclusivity of Sliding Windows and Long Packets?
  3577. Keywords: Sliding Windows Kermit, Long Packets
  3578.  
  3579. I'm not sure that I understand what was meant by long packets and sliding
  3580. windows being mutually exclusive.  If it means that both would not be used
  3581. at the same time, that seems fairly reasonable (although packets a bit longer
  3582. than 96 characters wouldn't seem to be especially harmful).  If it means that
  3583. only one of the two proposals should be adopted, I disagree.  They are not
  3584. technically incompatible and each solves some problems that the other does not.
  3585.  
  3586. Sliding windows are best if the environment can support them.  However, some
  3587. major systems, such as the IBM 370 (TSO and, I think, CMS), do not support
  3588. the necessary full duplex channel.  TSO, at least, will support long packets.
  3589. The UCLA File Transfer Package sucessfully uses a 1K packet size on TSO and
  3590. CMS (using their own protocol).  We very much want improved Kermit performance,
  3591. but will never be able to support sliding windows on our TSO system.  On the
  3592. other hand, we also have a DECsystem-10, which can support sliding windows.
  3593. Those users would benefit from the extra performance of sliding windows over
  3594. long packets.
  3595.  
  3596. Lurching windows for half duplex channels were not addressed in the sliding
  3597. windows proposal.  It seems like sender and receiver would have to agree on
  3598. how many packets would be sent before the receiver would acknowledge.  The
  3599. sender would have to know not to try to send more packets until the previous
  3600. group was acknowledged.  I suppose that this number could be the window size.
  3601. Also, in a lurching windows environment, a way to acknowledge multiple
  3602. packets would be beneficial, as acknowledgements are not overlapped with
  3603. data.  The main difference between lurching windows and long packets seems
  3604. to be that lurching windows have more overhead bytes and that less data
  3605. might be retransmitted in case of an error.
  3606.  
  3607. One further point on lurching windows: I'm pretty sure that TSO would require
  3608. a delay of a charcater time or more between packets so that they would be
  3609. recognized as separate "lines" of input.  Otherwise, I think that everything
  3610. after the carriage return at the end of the first packet would be lost.
  3611. Also, when TSO detects a parity error it sends out a transmission error
  3612. message, which means that it would not be listening for the following packet,
  3613. so it would be lost too.  All in all, I think long packets are better for
  3614. half duplex channels and sliding windows are better for full duplex.
  3615.  
  3616. In the sliding windows proposal, I do not understand why the sending of
  3617.  
  3618. INFO-KERMIT DIGEST V3 #11                                               Page 67
  3619.  
  3620. the end of file packet is delayed until all previous packets have been
  3621. acknowledged.  It seems to introduce an unnecessary delay.
  3622.  
  3623. Both proposals are optional -- no one would have to implement either, if they
  3624. don't care about the improved performance or want to defer the additional
  3625. complexity to a later version of their Kermit.
  3626.  
  3627. ------------------------------
  3628.  
  3629. Date: Sat, 27 Jul 85 18:18:19 pdt
  3630. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  3631. Subject: Implied ACKs, Half Duplex Windows
  3632. Keywords: Sliding Windows Kermit, Long Packets
  3633.  
  3634. I have two comments on Leslie's Q+A in info-kermit #9.
  3635.  
  3636. On implied-ACKing:
  3637.     Leslie states that getting a NAK forces the protocol to
  3638.     stop sending.  I don't agree.  There's no reason for the sender to stop
  3639.     sending just because a NAK came.  The retry for the NAK'ed
  3640.     packet can be inserted (ASAP) into the stream of first-try packets.
  3641.  
  3642.     ACK's for packets successfully received after the NAK'ed packet
  3643.     will have to wait until the NAK'ed packet is successfully received.
  3644.     But this does *not* change window requirements: the window has to be
  3645.     long enough to cover the time for NAK and retransmission of packets anyway.
  3646.  
  3647.     Note that although ACK's must wait until all packets up to that point
  3648.     have been received correctly, NAK's for unsuccessful packets can
  3649.     be sent as soon as they are detected as being unsuccessful, i.e.
  3650.     upon successful receipt of the following packet.  This will help
  3651.     keep the protocol running smoothly.
  3652.  
  3653.     The only penalty is that since ACKs will be bunched by the receiver,
  3654.     the window must be longer by the number of packets implied by each
  3655.     ACK to keep the window from filling.
  3656.  
  3657. On windows in a half-duplex environment:
  3658.  
  3659.     This is dismissed as being just long packets, with the implication
  3660.     that one should just use long packets in a half-duplex environment.
  3661.  
  3662.     This is not true!  Half-duplex connections have exaclty the same problem:
  3663.     how to get good efficiency over long-delay + moderate error rate
  3664.     connections.
  3665.  
  3666.     I would like to have half-duplex sliding windows seriously considered!
  3667.  
  3668. Ken Poulton
  3669. hplabs!poulton
  3670.  
  3671. I know it's dumb, but half-duplex is the way many systems work...
  3672.  
  3673. ------------------------------
  3674.  
  3675. Date: 27 Jul 1985 1334-EDT
  3676.  
  3677. Page 68                                               INFO-KERMIT DIGEST V3 #11
  3678.  
  3679. From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
  3680. Subject: Full-Duplex Windowing vs CP/M, et al
  3681. Keywords: Sliding Windows Kermit, CP/M-80
  3682.  
  3683. Since KERMIT-protocol has been invented and is successfully used in data
  3684. transfer between "micro's" and larger machines, let me take a look at the
  3685. "windowing" proposal as seen from the "micro's".
  3686.  
  3687. As is probably known, none of our current 'Van Neuman' machines can handle
  3688. more than one task at any given instant of time.  The illusion of
  3689. 'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
  3690. possible with the existence of a sophisticated interrupt-structure
  3691. [typically combined with 'hardware assisted' context-switching] and software
  3692. delivering the book-keeping services.
  3693.  
  3694. The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
  3695. are SINGLE-tasking systems.  Although the used micro-processors typically
  3696. support a basic interrupt-structure, the lack of buffered and hardware
  3697. assisted I/O devices limits the interrupt-structure basically to ERROR
  3698. intercepts and clock-service.  -- Or in laymans terms, "A typical micro
  3699. CANNOT accept characters on the Input-port, as long as its reading or
  3700. writing to the floppy".
  3701.  
  3702. How, might You ask, did MODEM or KERMIT survive this basic flaw at higher
  3703. communication speeds ??  -- Very easily with a "trick" in ACKing a received
  3704. packet ONLY AFTER it had been written to storage [ - thereby making sure,
  3705. that NOTHING {except NOISE} could arrive at the input-port - and therefore
  3706. nothing could be lost ].
  3707.  
  3708. In view of these "basics", I would like to treat a "Window of Packets" as
  3709. one Very Large Packet, which just happens to be sliced into smaller packets
  3710. for ease of error-recovery.  And the micro only has to make sure, that it
  3711. can store the combined DATA-content of the Window in a buffer.
  3712.  
  3713. Following Frank's concerns of portability, I would like to propose "fixed"
  3714. windows ["fixed" in their "agreed upon" starting packet-Nr and their size -
  3715. in contrast to "sliding windows" , where an ACK for the first packet in a
  3716. window of packets can slide the starting-point downwards].
  3717.  
  3718. In comparison to the "large packet" proposal this technique is probably of
  3719. more immediate interest to micro-users since:
  3720.  
  3721.     a. Most Communication media are NOT totally error-free
  3722.  
  3723.     b. Most micros are quite limited in sustaining any baud-rate above
  3724.        4800 Baud between Communication-Port and File-storage [ infact
  3725.        some have even problems to sustain above rates between Comm-Port
  3726.        and terminal].
  3727.  
  3728.  
  3729. Here the "changes" in detail:
  3730.  
  3731. 1.  Extend current KERMIT-Heuristic that "A NAK for the current packet is an
  3732. implied ACK for the previous one" to "A NAK for the current packet is an
  3733. implied ACK for all previous packets inside the current window".
  3734.  
  3735.  
  3736. INFO-KERMIT DIGEST V3 #11                                               Page 69
  3737.  
  3738. 2.  Introduce a rule, that the next [ fixed ] window of packets can ONLY be
  3739. sent, AFTER receipt of the LAST packet of the previous window has been
  3740. ACKed.  [This will guarantee the needed "silence on the input-port" during
  3741. 'buffer-write to file-storage' on the micro.]
  3742.  
  3743. 3.  Change the proposed Error-Recovery rule to "On a receipt of a NAK the
  3744. SENDER will re-send packets starting with the NAKed one".  [This will remove
  3745. the need to keep a "transfer-table" AND make re-synchonisation possible for
  3746. the micro without hefty recoding].
  3747.  
  3748. I believe, that with above changes, we only encounter a minimal "extra
  3749. overhead" in case of error-retransmission - probably NO extra overhead
  3750. time-wise at all , if the MAIN-Kermit can be written to be effectively
  3751. "interrupted" by receipt of a NAK from the micro - if he only can check for
  3752. NAK's between sending of packets, we'll incur a slight degradation timewise
  3753. as compared to the current protocol - since the NAK probably will arrive in
  3754. the middle of a not fully sent packet, which has to be re-sent again
  3755. according to the above changed rules.
  3756.  
  3757. We will however enjoy even "faster" transmission in the more prevailing case
  3758. of having NO ERRORS, since the single ACKs for each packet collapse into a
  3759. single ACK per window - and we will enjoy the same savings [or better] on
  3760. packet-based channels.
  3761.  
  3762. Rgds,
  3763. Bernie.
  3764.  
  3765. ------------------------------
  3766.  
  3767. Date: Sat, 27 Jul 85 18:18:41 pdt
  3768. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  3769. Subject: Proposal for Half Duplex Windows
  3770. Keywords: Sliding Windows Kermit, Long Packets
  3771.  
  3772. A quick proposal for half-duplex sliding windows:
  3773.  
  3774.     Kermit negotiates both packet size and super-packet size
  3775.     (i.e., N packets per super-packet, where
  3776.     N should be less than half the window size).
  3777.     The sender then sends <=N packets, then the end-of-line character
  3778.     to delimit end-of-super-packet (NO end-of-line chars inside
  3779.     the super packet - this is a must for half-duplex receivers).
  3780.  
  3781.     The receiver sends back a super packet of
  3782.     ACKs and NAKs.  This could use either the implied-ACK scheme
  3783.     discussed above, or an explicit ACK or NAK for each packet
  3784.     in the super-packet.  The implied-ACK scheme has the advantage
  3785.     that, on clean lines, the returning super-packet consists of just
  3786.     one ACK packet.
  3787.  
  3788.     The sender then sends the next super-packet, starting with the
  3789.     outstanding NAK'ed packets, and filled up (to N packets max) with
  3790.     new (first-time) packets.
  3791.  
  3792.     This kind of protocol can't obtain the efficiency of the
  3793.     full-duplex sliding window protocol, since it must incur
  3794.  
  3795. Page 70                                               INFO-KERMIT DIGEST V3 #11
  3796.  
  3797.     an overhead of one round-trip delay per super-packet.
  3798.     This can, however, still gain a factor of 2 or 3 over the
  3799.     current situation with 1200 baud lines with 2 second round trip
  3800.     delays.  It's *essential* for improvement over poor half-duplex
  3801.     connections where the error rates preclude getting long
  3802.     packets to work at all.
  3803.  
  3804.     I think what I have outlined is close enough to the
  3805.     full-duplex sliding windows to allow them to coexist in the same
  3806.     code.  All the full-duplex version needs to do is:
  3807.     1) negotiate half-duplex status and super-packet size along
  3808.         with window size (maybe we can negotiate handshake at
  3809.         the same time?)
  3810.     2) bunch packets without end-of-lines to form a super-packet
  3811.     3) wait for the replying super-packet before sending the next.
  3812.  
  3813.     Another advantage to allowing this half-duplex option is that
  3814.     this opens up greater flexibility for the implementation of
  3815.     sliding window Kermits, since this protocol can be implemented
  3816.     without multiprocessing.  This might make it a good choice
  3817.     for non-multi-processing systems or systems which make that difficult.
  3818.  
  3819. Ken Poulton
  3820. hplabs!poulton
  3821.  
  3822. ------------------------------
  3823.  
  3824. Date: Thu 1 Aug 85 12:44:55-EDT
  3825. From: Leslie Spira <OC.SOURCE@CU20B.ARPA>
  3826. Subject: Examination of Proposals
  3827. Keywords: Sliding Windows Kermit, Long Packets
  3828.  
  3829. Dear Frank,
  3830.  
  3831.     Hugh Matlock and I sat down last night and studied in detail the
  3832. discussion about the proposed extensions.
  3833.  
  3834.     It seemed to us once again that there is a fundamental difference
  3835. between full-duplex environments and half-duplex environments.
  3836.  
  3837.     Looking at it, it appears that the problems in half-duplex can best be
  3838. solved by a large packet size with smaller sub-units that can be NAKed and
  3839. retransmitted as necessary.
  3840.  
  3841.     The attempts to modify windowing all ended coming around to this
  3842. concept.  We looked at three things that indicated this:
  3843.  
  3844.     1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
  3845.     (message dated July 27).  This is a effectively a super-packet with
  3846.     segmentation.  Hugh agrees with Ken Poulton that the coding on this
  3847.     suggestion would parallel well with the full-duplex coding.
  3848.  
  3849.     2. Bernie Eiben's "rewritten" reply dated 27 July.  As he notes: "...
  3850.     I would like to treat a 'Window of Packets" as one Very Large Packet,
  3851.     which just happens to be sliced into smaller packets for ease of
  3852.     error-recovery."
  3853.  
  3854. INFO-KERMIT DIGEST V3 #11                                               Page 71
  3855.  
  3856.  
  3857.     3. The original extended packet length proposal, which could be
  3858.     modified so that checksums are placed after every 94 characters.  If
  3859.     you look at that definition, MAXLX1 simply becomes the number of
  3860.     sub-units in this view.
  3861.  
  3862.  
  3863.     Note what happened as people looked at "windowing" in the half-duplex
  3864. environment:  the choice of terminology was confusing at first, but
  3865. gradually sorted itself out into the fact that true sliding windows only
  3866. works in a full-duplex environment, and the equivalent in half-duplex is a
  3867. long packet with sub-units for ease of error-recovery.  This suggests that
  3868. the extended packet length proposal can be modified to include sub-units.
  3869.  
  3870.     I believe there is something of a philosophical turning point in
  3871. KERMIT's development appearing.  The Sliding Windows proposal provides
  3872. "high-end" performance for those higher capability environments (operating
  3873. system and communications channel) that are truly able to be full-duplex.
  3874. This "high-end" situation generally reflects the capabilities of later
  3875. systems on the market, which deserve to have their power taken advantage
  3876. of.
  3877.  
  3878.     On the other hand, I think that a Super-Packet with segmentation
  3879. proposal could reflect Classic KERMIT's concern with being able to operate
  3880. in all environments.  This proposal would need to take more enviroments
  3881. into account.  In some ways it is harder to define, because it may require
  3882. more changes to the existing KERMIT definition since it is more dependent on
  3883. KERMIT and less dependent on the operating system environment for
  3884. performance gains.
  3885.  
  3886.     This philosophical difference is just a way of analyzing the fact that
  3887. the two proposals have somewhat different intents, both of which I think
  3888. are valid.
  3889.  
  3890.     With this in mind, I think it might be helpful to change the name of
  3891. our proposal to "Full-Duplex Windowing Extension", in order to make it's
  3892. intent clear.  This definition is more dependent on the operating
  3893. environment, but its changes to the KERMIT definition are limited, in
  3894. that windowing is only in effect during transfer of data packets, there
  3895. are no new packet types, and the ACK and NAK stay pretty much the same.
  3896.  
  3897.     The criticisms of our proposal have been with our underlying decision
  3898. to operate in a full-duplex environment, rather than with the internal
  3899. consistency of the proposal.
  3900.  
  3901.     I'm putting the following points forward in our favor:
  3902.  
  3903.     1.   We have a complete, usable definition.
  3904.  
  3905.     2.   We have a working implementation for the IBM PC, and it is based
  3906.          on CKERMIT.  We are about to finish the PRIME implementation.
  3907.  
  3908.     3.   We will be making the code available to Columbia, and will be
  3909.          actively distributing it to communications software producers.
  3910.  
  3911.     4.   We have put lots of hard work into this. (Does that count??)
  3912.  
  3913. Page 72                                               INFO-KERMIT DIGEST V3 #11
  3914.  
  3915.  
  3916.     5.   We have some unfortunate, but real, deadlines.
  3917.  
  3918.     6.   The sliding window definition can starting making some very great
  3919.          improvements in transfer times over the public data networks,
  3920.          where there currently is no other good solution to the throghput
  3921.          problem.
  3922.  
  3923.     7.   We (at The Source) currently have a chance to build additional
  3924.          momentum for KERMIT.  In a lot of ways, this opportunity
  3925.          (or window?) is much better now than it will be later.
  3926.  
  3927.     We would like to have the definition approved this week.  In
  3928. addition, we would then like to continue to contribute to the definition of
  3929. "super-packets with segmentation".
  3930.  
  3931.     I also would like to apologize for not having more time to approve
  3932. this; it was not our intent.  This is not a casual proposal however; it
  3933. has been pretty carefully thought through (indeed, the refinement of the
  3934. definition delayed it).
  3935.  
  3936.                                        Sincerely,
  3937.  
  3938.                                        John Mulligan
  3939.  
  3940. ------------------------------
  3941.  
  3942. Date: Thu 1 Aug 85 14:17:00-EDT
  3943. From: Frank da Cruz <SY.FDC@CU20B>
  3944. Subject: Full Duplex Sliding Windows -- Let's Give Them a Try
  3945. To: OC.SOURCE@CU20B, OC.Jordan@CU20B, Info-Kermit@CU20B
  3946. Keywords: Long Packets, Sliding Windows Kermit
  3947.  
  3948. John, Hugh, Leslie, Larry... Your arguments are persuasive.  You've clearly
  3949. done a lot of work (in a project like Kermit, that's usually what counts
  3950. most!).  I'd like to state my misgivings for the record, and then go ahead
  3951. grant you permission to use Bit #4 in the CAPAS field to indicate Full Duplex
  3952. Sliding Window Capability, and the field immediately after the CAPAS field
  3953. (remembering that the CAPAS field can grow) to designate window size, as you
  3954. have proposed.
  3955.  
  3956. My biggest misgiving is that we (you, I, and the Info-Kermit community) have
  3957. not had sufficient time to consider the proposal, and I will always have
  3958. nagging doubts that there may have been ways to improve it that would have
  3959. made more people happy.  As proposed, this capability requires true full
  3960. duplex operation.  In order for any computer to support this style of i/o,
  3961. it must be capable of EITHER multiprocessing OR fully interrupt-driven i/o
  3962. (or both).  Multiprocessing is something most micros can't do; it requires
  3963. certain hardware features like memory protection.  On the other hand, almost
  3964. any operating system allows access to its interrupt structure by the
  3965. programmer.  Unfortunately, the mechanisms for getting at interrupts vary
  3966. considerably among machines, operating systems, and even operating system
  3967. versions.  So a Kermit program that manages to "steal" the system's
  3968. interrupt vector in order to work correctly under version x of the operating
  3969. system might suddenly stop working when the user installs version y...  To
  3970. make matters worse, information about interrupt programming tends to be hard
  3971.  
  3972. INFO-KERMIT DIGEST V3 #11                                               Page 73
  3973.  
  3974. to come by -- it's missing from the manuals, it's proprietary, or whatever
  3975. -- so when this is true, it makes it tough for even the motivated programmer
  3976. to do the work.
  3977.  
  3978. It's unfortunate that you have such pressing deadlines, and that I will be
  3979. gone for a month.  It may well be that your proposal is exactly what is
  3980. needed to kick Kermit protocol into the big leagues, but it might have been
  3981. possible to refine it in such a way that continuous full duplex transmission
  3982. would be possible for those systems capable of it, while provision was made
  3983. for those systems (CP/M-80 springs to mind) that have to turn their backs
  3984. on the communication port from time to time in order to write to the disk.
  3985.  
  3986. As you suggest, systems like CP/M along with the systems that really have
  3987. half duplex communication channels might be accommodated by the long-packet
  3988. extension, especially if modified to allow segmented long packets (this
  3989. reminds me of SMTP vs BSMTP...).  But it would be a lot cleaner if a single
  3990. Kermit extension could take care of everyone.
  3991.  
  3992. A final misgiving is that allocation of a CAPAS bit and Send-Init field is
  3993. irrevocable.  Once Kermit programs are out in the world that use them, they
  3994. can never be used for anything else.  Therefore, I'd like to emphasize that
  3995. the full duplex sliding window feature specified in Info-Kermit V3 #7 should
  3996. still be considered EXPERIMENTAL.  The group at The SOURCE will be tuning it
  3997. as they work on their new implementations, and I'm sure that some of the
  3998. comments and suggestions from Info-Kermit will be in the back of their
  3999. minds.  I expect that all this activity will settle down in a month or two,
  4000. and a "final" copy of the sliding window specification will be available
  4001. then.  Until then, no one should attempt to work from the current
  4002. specification without first contacting the people at The SOURCE (mail to
  4003. OC.SOURCE@CU20B).  Since the CAPAS bit and the window size field will be
  4004. allocated to their windowing method, it is essential that the protocol
  4005. invoked by them is clearly, completely, and unambiguously specified before
  4006. any programs using them are distributed to the public.
  4007.  
  4008. - Frank
  4009.  
  4010. ------------------------------
  4011.  
  4012. End of Info-Kermit Digest
  4013.  
  4014. Page 74                                               INFO-KERMIT DIGEST V3 #12
  4015.  
  4016. Info-Kermit Digest         Fri,  2 Aug 1985       Volume 3 : Number 12
  4017.  
  4018. Departments:
  4019.  
  4020.   ANNOUNCEMENTS -
  4021.         C-Kermit 4C(057) Hurriedly Replaced
  4022.  
  4023.   PROPOSALS -
  4024.         Attribute Packets, Windows
  4025.         A Vote FOR Long Packets
  4026.         Sliding Windows vs. Long Packets vs. Segmentation
  4027.  
  4028.   MISCELLANY -
  4029.         VMS Kermit and VMS V4
  4030.         Problem with Stevens' Kermit for Apple //
  4031.         Bugs in Version 2.28 of MS-DOS Kermit
  4032.  
  4033. ----------------------------------------------------------------------
  4034.  
  4035. Date: Wed 31 Jul 85 18:07:00-EDT
  4036. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  4037. Subject: C-Kermit 4C(057) Hurriedly Replaced
  4038. To: Info-Kermit@CU20B.ARPA
  4039. Keywords: C-Kermit
  4040.  
  4041. One of the edits in 4C(057) apparently broke C-Kermit on 68000's and
  4042. possibly other non-VAX, non-PDP-11 machines -- the old int/char pitfall.
  4043. Anyone who ftp'd C-Kermit from CU20B between 8:00pm-EDT July 29 and
  4044. 6:00pm-EDT July 31 should pick up a new copy of K2:CKCFNS.C.  Too bad I
  4045. didn't have a 68000 to test this on -- apologies, and thanks to Philip Jeuck
  4046. <JEUCK@SRI-KL.ARPA> for pointing out the problem.  You'll know if you have
  4047. the bad version if it announces itself with the date 29 Jul 85; the
  4048. (hopefully) fixed one is dated 31 Jul 85.
  4049.  
  4050. Also, there was a minor error in conditional compilation for 4.1BSD which
  4051. should also be fixed (K2:CKUTIO.C) and there was a minor change to the
  4052. makefile (K2:CKUKER.MAK), and a minor problem with subshell invocation
  4053. on systems with ints and pointers of different sizes (K2:CKUUSR.C).
  4054.  
  4055. This should REALLY be the last release of this program for at least a
  4056. month, so those who have not been getting new versions because they keep
  4057. changing so often should pick up this one.
  4058.  
  4059. ------------------------------
  4060.  
  4061. Date: Fri 2 Aug 85 15:14:57-EDT
  4062. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  4063. Subject: Attribute Packets, Windows
  4064. To: oc.source@CU20B.ARPA, oc.jordan@CU20B.ARPA
  4065. cc: Info-Kermit
  4066. Keywords: Sliding Windows Kermit, Attribute Packets
  4067.  
  4068. I was just looking at the protocol manual and realized that the current edition
  4069. does not contain something which might be useful to you, namely two new
  4070. attribute fields:  "1" specifies the exact byte count of the file, and "2"
  4071. specifies the byte size (e.g. "7" or "8").  This will be in the next edition.
  4072.  
  4073. INFO-KERMIT DIGEST V3 #12                                               Page 75
  4074.  
  4075. Many people have asked for a somewhat finer-grained way to report the file
  4076. size than the number of K (e.g. some systems need to preallocate space, but in
  4077. some unit other than K).  - Frank
  4078.  
  4079. P.S. Bye till September.
  4080.  
  4081. P.P.S. I was waiting for a message to this effect from someone who called,
  4082. but it hasn't arrived, and I'm leaving now, so here it is in a nutshell:
  4083.  
  4084. If you have tested your sliding window algorithm with a slow (1200b or less)
  4085. line and a fast (hard or RAM) disk and it works as expected, please verify
  4086. that it ALSO works with a FAST (9600b or more) line and a SLOW (floppy) disk
  4087. before finalizing the protocol and releasing any programs that implement it
  4088. to the public.
  4089.  
  4090. P.P.P.S. To everyone -- please keep sending comments on the new proposals to
  4091. Info-Kermit@CU20B, even while I'm gone -- they'll appear in the digest on
  4092. a weekly basis, approximately.
  4093.  
  4094. ------------------------------
  4095.  
  4096. Date: Thu, 1 Aug 85 14:04:13 pdt
  4097. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  4098. Subject: A Vote FOR Long Packets
  4099. Keywords: Long Packets, Sliding Windows Kermit
  4100.  
  4101. I'd like to cast a vote FOR the long-packet proposal.
  4102.  
  4103. It seems to me to be a simple enough extension that it can be implemented
  4104. and debugged quite quickly, without massive program changes.  There are a
  4105. number of situations where it will definately help; I have one user of
  4106. ST-Kermit who has already "rolled his own" long packets, and another
  4107. champing at the bit.
  4108.  
  4109. I see long packets as complementary to (and even compatible with) sliding
  4110. windows; there is no reason to have to choose only one.
  4111.  
  4112. If someone would specify the extra bits and bytes in the send-init packet
  4113. (very clever to have left those out of the proposal), we could get some
  4114. implementations going soon.  (Anyone want to volunteer for C-Kermit?)
  4115.  
  4116. Ken Poulton
  4117. hplabs!poulton
  4118.  
  4119. [Ed. - Let's leave the proposal open for discussion, but if you want to play
  4120. with an experimental implementation, let's say that the long packets bit is
  4121. bit #5 and the length fields are the 2nd and 3rd bytes after the CAPAS
  4122. field.]
  4123.  
  4124. ------------------------------
  4125.  
  4126. Date: Fri, 2 Aug 85 09:42:58 cdt
  4127. From: knutson@ut-ngp.ARPA (Jim Knutson)
  4128. Subject: Sliding Windows vs. Long Packets vs. Segmentation
  4129. Keywords: Sliding Windows Kermit, Long Packets
  4130.  
  4131.  
  4132. Page 76                                               INFO-KERMIT DIGEST V3 #12
  4133.  
  4134. Something that hasn't been addressed in this, is the protocol negotiation.
  4135. In the past, both sides have not needed to negotiate because it was not
  4136. necessary.  Each side always transmitted what the other wanted.  If there
  4137. was disagreement over an option, the lowest common denominator was used.
  4138. Now we have several transmission schemes.  There is the normal packets
  4139. transmission with packet lengths up to 96 characters, extended packet
  4140. lengths, extended packet lengths with segmentation and sliding windows with
  4141. all the above options.  How will the correct scheme to use be decided
  4142. between the two Kermits.  Will a disagreement always bring you back to 96
  4143. character packets?  For example, if a user selects sliding windows on a
  4144. kermit that can have either sliding windows and/or extended packets and the
  4145. remote kermit can only do extended packets, will they both revert to 96
  4146. character packets?  Will extended packets be used?  What if both could have
  4147. done extended packets with segmentation but not sliding windows?  Are we
  4148. going to have a build in a priority CAPAS to prioritize the decision between
  4149. transfer schemes?
  4150.  
  4151. Jim Knutson
  4152.  
  4153. ------------------------------
  4154.  
  4155. Date: Thu, 1 Aug 85 14:04:13
  4156. From: LCG.KERMIT
  4157. Subject: VMS Kermit and VMS V4
  4158. Keywords: VMS Kermit
  4159.  
  4160. Some of the folks at RCA have been using the new VMS Kermit on VMS V4.x and
  4161. noticed odd echoing which was traced to differences in the V4 terminal
  4162. driver's echo from V3. Characters like control-O were getting screwed up and
  4163. leaving local terminals in graphics mode, as a symptom.
  4164.  
  4165. It turned out there was a workaround. The procedure to use is as follows:
  4166.  
  4167.         Set line <whatever>
  4168.         local host set term <whatever> /PASTHRU
  4169.         connect
  4170.  
  4171. The result is that things then work OK. VMS V4 users may want to take note.
  4172. Charles Garman reported this to me.
  4173.  
  4174.         Glenn Everhart
  4175.  
  4176. ------------------------------
  4177.  
  4178. Date:     Wed, 31 Jul 85 20:26:19 PDT
  4179. From:     ken@cit-hamlet.arpa
  4180. Subject:  Problem with Steven's Kermit for Apple //
  4181. Keywords: Apple II DOS Kermit
  4182.  
  4183. When sending a file (specifically, a text file in 7 bit mode) from either an
  4184. Apple ][+ or //e, to a Vax/Vms machine running V4 [with the V4 version of
  4185. Kermit], the Apple kermit gets a "WRITE PROTECTED" error AFTER the transfer
  4186. of the file (and the Vax deletes the file if the appropriate option is left
  4187. as the default) if the disk is write-protected.
  4188.  
  4189. It seems silly that write-protecting a disk should prevent the proper
  4190.  
  4191. INFO-KERMIT DIGEST V3 #12                                               Page 77
  4192.  
  4193. reading of a file. Anyone have a fix for this before I delve into the file
  4194. manager?
  4195.  
  4196.                                                 -Ken
  4197. Adelman, Caltech
  4198.                                                  ken@cit-hamlet.arpa
  4199.                                                  ken@caltech.bitnet
  4200.  
  4201. [Ed. - Anybody out there who can help?]
  4202.  
  4203. ------------------------------
  4204.  
  4205. Date: 2 Aug 1985 0653-PST
  4206. From: Pawka <PAWKA@NOSC-TECR>
  4207. Subject: Bugs in Version 2.28 of MS-DOS Kermit
  4208. To: INFO-HZ100@RADC-TOPS20.ARPA
  4209. Keywords: MS-DOS Kermit
  4210.  
  4211. I found a couple of minor bugs in the Z-100 version of MS-Kermit,
  4212. Version 2.28, here are the fixes:
  4213.  
  4214. 1) The STATUS command causes the program to wander off into never-
  4215.    never land, module MSSET.ASM had 2 instuctions missing, in routine
  4216.    BAUDPRT a push and a pop of di were missing:
  4217.  
  4218.         Was:
  4219.                 BAUDPRT   PROC   NEAR
  4220.                 call getbaud        ; read baud rate first
  4221.  
  4222.         Should be:
  4223.                 BAUDPRT   PROC   NEAR
  4224.                 push di             ; preserve this
  4225.                 call getbaud        ; read baud rate first
  4226.                 pop di
  4227.  
  4228.  2) The delete, backspace or Ctrl/H keys were not erasing characters
  4229.     in the command line. The routine that gets characters from the
  4230.     keyboard now, for some reason, puts out a space when it reads one
  4231.     of these characters. I fixed this by changing a string in
  4232.     MSXZ100.ASM:
  4233.  
  4234.         Was:
  4235.                 delstr  db  BS,' ',BS,'$'
  4236.  
  4237.         Now:
  4238.                 delstr  db  BS,BS,' ',BS,'$'
  4239.  
  4240. I hope this doesn't foul up something else, it seems o.k. for the stuff I do.
  4241.  
  4242.                                 Mike Pawka
  4243.                                 PAWKA@NOSC-TECR.ARPA
  4244.  
  4245. [Ed. - Provided only for information to H/Z-100 folks; we'll check it out and
  4246. include in the forthcoming release if ok.]
  4247.  
  4248. ------------------------------
  4249.  
  4250. Page 78                                               INFO-KERMIT DIGEST V3 #12
  4251.  
  4252.  
  4253. End of Info-Kermit Digest
  4254.  
  4255. INFO-KERMIT DIGEST V3 #13                                               Page 79
  4256.  
  4257. Info-Kermit Digest         Fri, 09 Aug 1985       Volume 3 : Number 13
  4258.  
  4259. Departments:
  4260.  
  4261.   ANNOUNCEMENTS -
  4262.     Kermit directories/files have moved
  4263.  
  4264.   KERMIT ENHANCEMENTS DISCUSSION -
  4265.     Sliding windows on micros should work
  4266.     ANY-duplex Windows
  4267.     Half-duplex windowing and large packets
  4268.  
  4269.   UNIX KERMIT -
  4270.     CKermit Statistics
  4271.  
  4272.   MS-DOS KERMIT -
  4273.     Warning: Unrecognized Baud Rate
  4274.  
  4275.   MISCELLANY -
  4276.     How do you edit pc-ix sources?
  4277.     RT-11/TSX+ Kermit
  4278.     Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.
  4279.  
  4280.  
  4281. ----------------------------------------------------------------------
  4282.  
  4283.  
  4284. Date: Sat 3 Aug 85 09:02:08-PDT
  4285. From: Douglas Edwards <EDWARDS@SU-CSLI.ARPA>
  4286. Subject: "Warning: Unrecognized Baud Rate"
  4287. Keywords: MS-DOS Kermit
  4288.  
  4289. I use MS-DOS Kermit for the IBM PC (actually I have a Compaq, but they
  4290. seem interchangeable).  I have one minor problem.  When I start up
  4291. Kermit I always get the message "?Warning: Unrecognized Baud Rate"
  4292. even though my init file clearly specifies 1200 bps.  (It works
  4293. fine--the message seems to have no significance, it's just annoying.)
  4294. What causes this?
  4295.  
  4296.     Douglas Edwards
  4297.     (edwards@su-csli)
  4298.  
  4299. [Ed. - When it starts up, MS-DOS Kermit looks at the baud rate the
  4300.   serial port is set to and tries to identify it (so that the status
  4301.   command will print the correct value if the baud rate isn't
  4302.   explicitly set).  If it can't figure out the baud rate, the message
  4303.   is printed.  This has nothing to do with what's in your init file -
  4304.   it is printed even before the init file is read.  The message won't
  4305.   affect anything else; it should probably be removed. ]
  4306.  
  4307. ------------------------------
  4308.  
  4309. Date: Sun, 4 Aug 85 15:08:17 pdt
  4310. From: "Corwin Nichols; Community Data Processing; 415-322-9069"
  4311.  <cdp!corwin@Glacier>
  4312. Subject:  sliding windows on micros should work
  4313.  
  4314. Page 80                                               INFO-KERMIT DIGEST V3 #13
  4315.  
  4316. Keywords: Sliding Windows Kermit
  4317.  
  4318. In a July 27 note, B.Eiben writes:
  4319.  
  4320. >As is probably known, none of our current 'Van Neuman' machines can handle
  4321. >more than one task at any given instant of time.  The illusion of
  4322. >'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
  4323. >possible with the existence of a sophisticated interrupt-structure
  4324. >[typically combined with 'hardware assisted' context-switching] and software
  4325. >delivering the book-keeping services.
  4326.  
  4327. >The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
  4328. >are SINGLE-tasking systems.  Although the used micro-processors typically
  4329. >support a basic interrupt-structure, the lack of buffered and hardware
  4330. >assisted I/O devices limits the interrupt-structure basically to ERROR
  4331. >intercepts and clock-service.  -- Or in laymans terms, "A typical micro
  4332. >CANNOT accept characters on the Input-port, as long as its reading or
  4333. >writing to the floppy".
  4334.  
  4335. It is true that the current crop of popular micros run MSDOS, CP/M, or
  4336. AppleDos, and that these are singletasking operating systems.  However
  4337. it is NOT necessary to have a "sophisticated interrupt-structure" or
  4338. fancy hardware in order to process a single stream of incoming characters
  4339. while performing other tasks such as monitoring the incoming stream,
  4340. calculating checksums, transmitting ACKs, etc.  All that is required is
  4341. a simple interrupt routine which captures the incoming stream in a buffer,
  4342. and which is enabled throughout disk i/o operations.
  4343.  
  4344. All machines which claim to be close to IBM PC compatibility meet this
  4345. simple criteria.  Many CP/M machines also meet these requirements, ei
  4346. Radio Shack models 2, 4, 12, and 16; all Compupros, Altos's, Cromemcos and
  4347. any other machine which uses a dma chip for disk i/o and has a serial
  4348. chip that is on an interrupt line.
  4349.  
  4350. Since most of the CP/M and MSDOS implementations are already machine dependent,
  4351. I don't foresee any major problems implementing the sliding window code
  4352. on most of the popular micros.
  4353.  
  4354. ------------------------------
  4355.  
  4356. Date: Fri, 2 Aug 85 20:18:22 pdt
  4357. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  4358.     hplabs!cc.fdc@cu20b.ARPA, hplabs!oc.source@cu20b.ARPA
  4359. Subject: ANY-duplex Windows
  4360. Keywords: Sliding Windows Kermit, Long Packets
  4361.  
  4362. I agree with Leslie et al, that they have a viable, apparently
  4363. well thought-out proposal for full-duplex sliding windows.
  4364.  
  4365. Where we differ is in whether half-duplex windows
  4366. belong to Sliding Windows or to Long Packets.  They argue that
  4367. the various half-duplex proposals all filter down to long,
  4368. segmented packets.  At the link level (what passes down the
  4369. wires, and how to synchronize it) this is true.
  4370.  
  4371. But NOT AT THE PACKET LEVEL, where most of the programming
  4372.  
  4373. INFO-KERMIT DIGEST V3 #13                                               Page 81
  4374.  
  4375. is involved.  The major part of the implementation of full-duplex
  4376. windows is in the handling of a window of "active" packets
  4377. (except when the opsys doesn't support multi-processing).
  4378. At the packet level, the handling of half-duplex windows is
  4379. nearly the same, as Leslie agrees:
  4380.  
  4381.     1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
  4382.     (message dated July 27).  This is a effectively a super-packet with
  4383.     segmentation.  ********************************************
  4384.     ************* Hugh agrees with Ken Poulton that the coding on this
  4385.     suggestion would parallel well with the full-duplex coding.
  4386.     ***********************************************************
  4387.  
  4388.  
  4389. PROPOSAL: Have the full-duplex windows allow for half-duplex
  4390. operation.  All implementations with full-duplex
  4391. windows should be able to run in half-duplex mode also, so that
  4392. we don't end up with two (probably incompatible) versions of
  4393. windows/long-packets running around.
  4394.  
  4395. I don't think this requires adding much to a full-duplex window scheme.
  4396. To repeat from my earlier proposal:
  4397.  
  4398.      All the full-duplex version needs to do is:
  4399.     1) negotiate half-duplex status and super-packet size along
  4400.         with window size
  4401.     2) bunch outgoing packets together (without end-of-lines)
  4402.         to form a super-packet
  4403.     3) wait for the replying super-packet before sending the next.
  4404.  
  4405. My immediate concern is with point (1): unless this negotiation
  4406. is added to the full-duplex windows NOW, it never will.
  4407. But once that part is defined, the implementation is easy.
  4408.  
  4409. In fact, it might be a positive benefit for future full-duplex
  4410. implementations: one could bring up half-duplex windows
  4411. first to debug the window algorithm and worry about the low-level
  4412. interrupt/process handling stuff later.  (Half-duplex windows
  4413. have got to be easier to debug than full-duplex...)
  4414.  
  4415. Adding a half-duplex option to sliding windows also makes them
  4416. more portable: half-duplex windows might still work across
  4417. operating system revs or different hardware (e.g., PC-almost-clones)
  4418. when a full-duplex implementation (that munged the interrupt
  4419. vector, or whatever) broke.
  4420.  
  4421. To argue by the numbers:
  4422.  
  4423.     1) half-duplex windows are a SIMPLE extension of
  4424.     the proposed full-duplex window proposal
  4425.  
  4426.     2) half-duplex windows ADD portability and robustness,
  4427.     even for full-duplex machines
  4428.  
  4429.     3) The only critical need *right now* is to *define* the
  4430.     bits and bytes for negotiating half-duplex windows
  4431.  
  4432. Page 82                                               INFO-KERMIT DIGEST V3 #13
  4433.  
  4434.     and add that part of the negotiation to the
  4435.     full-duplex window specification.  In the interests of
  4436.     allowing Leslie, et al to move along, implementation
  4437.     can wait.
  4438.  
  4439. If full-duplex windows go ahead without a half-duplex provision,
  4440. it seems likely that we will eventually agree to a separate segmented
  4441. long packet proposal, which may go the way of File Attribute Packets.
  4442. (Almost no one has implemented these because there is almost no
  4443. one else to exchange them with.)  Momentum is key here!
  4444.  
  4445.  
  4446. Leslie & co have made a large contribution here, and I thank
  4447. them for that.  I agree that this window proposal is indeed a
  4448. critical moment for Kermit.  We *all* benefit by making it
  4449. useful to more machines.
  4450.  
  4451. After all, isn't that what Kermit is all about?
  4452.  
  4453. Ken Poulton
  4454. hplabs!poulton
  4455.  
  4456. ------------------------------
  4457.  
  4458. Date: Wed 7 Aug 85 03:20:06-EDT
  4459. From: Ken Rossman <sy.Ken@CU20B.ARPA>
  4460. Subject: Kermit directories/files have moved
  4461. Keywords: Kermit DIR
  4462.  
  4463. Due to space shortages on our PS structure, all Kermit directories and
  4464. files have been moved to the PX/PB structure.  All system-wide logical
  4465. names have been correspondingly redirected, so if you use the system-wide
  4466. logicals for all file references, you should not notice any difference.
  4467.  
  4468. Mail questions and/or problems to info-kermit@CU20B.
  4469.  
  4470. ------------------------------
  4471.  
  4472. Date: 7 Aug 85 18:11:49 EDT
  4473. From: BL02@CMU-CC-TC
  4474. Subject: how do you edit pc-ix sources?
  4475. Keywords: Editor
  4476.  
  4477. Help!
  4478.     I have a pc-xt running pc-ix.  I can't live with INed (the editor)
  4479. anymore.  Since ckermit is a rather large program, and it has been
  4480. made to run under pc-ix, I gather someone out there has a nice editor
  4481. that runs under same.  Can someone give me a pointer to where I can
  4482. get one?  I really am looking for an emacs clone (thief, fine, jove, etc.)
  4483. or even real emacs, etc., etc., etc.  I do have some sources to thief
  4484. and jove, but not for pc-ix, and I just don't have the time right now
  4485. to fix them up.
  4486.  
  4487. Can anyone help me??  or am I just stuck with INed?  Thanks SO MUCH for
  4488. any replies or comments.
  4489.  
  4490.  
  4491. INFO-KERMIT DIGEST V3 #13                                               Page 83
  4492.  
  4493.         Bryan Lally
  4494.         bl02@cmcctc
  4495. ------------------------------
  4496.  
  4497. Date: Tue, 6 Aug 85 11:59:46 PDT
  4498. From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA
  4499.     Info-Kermit@CU20B.ARPA
  4500. Subject: Half-duplex windowing and large packets
  4501. Keywords: Long Packets, Sliding Windows Kermit
  4502.  
  4503. I'd like to make a proposal which essentially adds some details
  4504. to Ken Poulton's proposal for half-duplex sliding windows with
  4505. super-packets (Info-Kermit #11).  Extend the protocol to
  4506. negotiate both the maximum window size and the super-packet size,
  4507. using the byte following the window size for the super-packet
  4508. size.  Now, if the super-packet size is 0 or 1 (treat 0 as
  4509. equivalent to 1), then we have full-duplex windowing as in the
  4510. Source's proposal.  If the super-packet size is the same as the
  4511. window size, then we have half-duplex windowing.  If somewhere in
  4512. between, then we have full-duplex windowing using super-packets.
  4513. Note that if window size is super-packet size times 2, then
  4514. although we strictly have full-duplex windowing, we can consider
  4515. it to be half-duplex with type-ahead.  I believe that will work
  4516. on a few half-duplex systems.  It will certainly work on my MTS
  4517. system.  In this proposal the window size in terms of number of
  4518. super-packets outstanding at once is (window size)/(super-packet
  4519. size).
  4520.  
  4521. Keep the rule in the original windowing proposal that explicit
  4522. ACKs and NAKs are required for each packet.  Note that implicit
  4523. ACKing must be disabled if the environment is full-duplex,
  4524. because you really don't know if the missing packet is an ACK or
  4525. a NAK (you could change it to implicit NAKing).  The other rule
  4526. that differs between half- and full-duplex environments is that
  4527. in a half-duplex environment one should do something with a
  4528. packet with a bad checksum - sender treats it as a NAK and
  4529. receiver sends a NAK.  That prevents having to wait for a timeout
  4530. every time a packet gets mangled.  As the windowing proposal
  4531. correctly states, in a full-duplex envorinment one must simply
  4532. ignore packets with a bad checksum.  That is because one cannot
  4533. guess the correct packet number as one can in the half-duplex
  4534. environment.
  4535.  
  4536. I'd also like to propose one more extension to save money on
  4537. public data networks.  Many of those networks charge by the
  4538. packet and packet sizes are typically up to 128 or 256 bytes.
  4539. I'd like to extend the packet length field to 2 bytes when the
  4540. first length byte (decoded) is 1 or 2.  That will allow packet
  4541. sizes from the current minimum up to 284 with no loss of
  4542. efficiency on short packets.  It will allow a super-packet of
  4543. 26696 (284*94) bytes which seems more than long enough.  Two more
  4544. bytes are needed in the Init packet to negotiate the maximum
  4545. packet size just as in the original long packet proposal.
  4546.  
  4547. Note that I haven't used packet size 0 so this doesn't conflict
  4548. with the large packet proposal.  However, I'd like to see this
  4549.  
  4550. Page 84                                               INFO-KERMIT DIGEST V3 #13
  4551.  
  4552. proposal supercede that one because it is superior in several
  4553. respects.  It allows ACKing and NAKing parts of large packets and
  4554. it fits in with the windowing proposal.
  4555.  
  4556. Now, this idea complicates the negotiation process a bit, because
  4557. if one side wants to be half-duplex and the other side doesn't
  4558. care, the negotiation must be sure to end up in a half-duplex
  4559. state.  I believe the following rules will work: 1.  Use the
  4560. minimum value of window size (or smaller, see 3).  2.  Be
  4561. half-duplex (super-packet size equal to window size) if either
  4562. side requests that.  3.  Make super-packet size divide (no
  4563. remainder) window size and make super- packet size be such that
  4564. the resulting quotient is the minimum of the two quotients
  4565. requested, by adjusting the window size downward if necessary.
  4566.  
  4567. The biggest drawback to this proposal is that it doesn't allow
  4568. very large packets when one really wants a window size of 31
  4569. (since in that case one cannot use super-packets).  Nonetheless,
  4570. the 284 byte maximum packet size in that case seems sufficient.
  4571.  
  4572. I'm a bit out of touch for the next week and have been for a few
  4573. days so this proposal may not take into account everything it
  4574. should and I won't be able to respond until next week.
  4575.  
  4576. ------------------------------
  4577.  
  4578. Date: Mon, 5 Aug 85 14:19:56 pdt
  4579. From: seismo!decvax!ucbvax!ucdavis!deneb!ccrms@columbia.arpa (Michael Shulman)
  4580. Subject: RT-11/TSX+ Kermit
  4581. Keywords: RT-11 Kermit
  4582.  
  4583. We understand that there is a version of Kermit available
  4584. for the TSX+ system.  It is far easier for us to obtain a
  4585. copy of this system on 8" disk than it would be to bootstrap
  4586. it ourselves.  Are there any sites that have such a system
  4587. running and would be willing to make us a copy on 8" disk?
  4588.  
  4589. Thank you,
  4590.  
  4591. Michael Shulman
  4592. Computer Center
  4593. UCDavis ... ucbvax!ucdavis!deneb!ccrms
  4594.  
  4595.  
  4596. ------------------------------
  4597.  
  4598. Date: Thu, 8 Aug 85 03:29:24 pdt
  4599. From: Neal Holtz <holtz%cascade.carleton.cdn%ubc.csnet@csnet-relay.arpa>
  4600. Subject: CKermit Statistics
  4601. Keywords: C-Kermit
  4602.  
  4603. A statistic regarding performance of C-Kermit:
  4604.  
  4605.        source:  Vax 11/750 4.2 BSD
  4606.        dest:    Apollo DN320, Aegis SR8
  4607.        line:    9600 baud
  4608.  
  4609. INFO-KERMIT DIGEST V3 #13                                               Page 85
  4610.  
  4611.        type:    text
  4612.        # files: 53
  4613.        # chars: 684206
  4614.        time:    29 min. (+/- 1 min.)
  4615.        effective rate:  393 chars/sec
  4616.  
  4617. Notes:
  4618. 1) Apollo versions:
  4619.     C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
  4620.     C-Kermit Protocol Module 4.2(015), 5 Mar 85
  4621.     C-Kermit functions, 4.2(026) 5 Mar 85
  4622.     Unix cmd package V1.0(015) 27 Feb 85
  4623.     User Interface V4.2(038), 5 Mar 85
  4624.     Apollo Aegis tty I/O, 4C(023), 20 May 85 for Apollo Aegis SR8
  4625.     Aegis file support, 4C(024) 20 May 85 for Apollo Aegis SR8
  4626.     Connect Command for Unix, V4.2(006) 5 March 85
  4627. 2) Vax versions:
  4628.     C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
  4629.     C-Kermit Protocol Module 4.2(015), 5 Mar 85
  4630.     C-Kermit functions, 4.2(026) 5 Mar 85
  4631.     Unix cmd package V1.0(015) 27 Feb 85
  4632.     User Interface V4.2(038), 5 Mar 85
  4633.     Unix tty I/O, 4.2(016), 5 Mar 85 for 4.2 BSD
  4634.     Unix file support, 4.1(015) 28 Feb 85 for 4.x BSD
  4635.     Connect Command for Unix, V4.2(006) 5 March 85
  4636. 3) All compiler optimizing turned off on Apollo
  4637. 4) Used about 25% of CPU on Vax
  4638. 5) Used about 70% of CPU on Apollo
  4639.  
  4640. ------------------------------
  4641.  
  4642. Date:     Fri, 9 Aug 85 9:46:06 EDT
  4643. From:     David Roth (Ft. Benj. Harrison) <droth@BRL.ARPA>
  4644. Subject:  Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.
  4645. Keywords: Burroughs B2x, BTOS
  4646.  
  4647. This Sept.15 we are expecting shipment to arrive of dozens of Burroughs B-20s,
  4648. B-25s & B-26s. The operating system they run is called BTOS. We are in need
  4649. of a version of KERMIT for these systems. Anyone have a version or enough
  4650. experience in using BTOS to suggest what existing version of KERMIT we
  4651. should start with.
  4652. The Army refers to these systems as: TACCS.
  4653. Thanks in advance.
  4654.                                 David A. Roth
  4655.                                 droth@brl-bmd
  4656.                         US Mail:
  4657.                                 COMMANDER
  4658.                                 USA Soldier Support Center
  4659.                                 ATSG-DTU-S
  4660.                                 Attn: Mr. David A. Roth
  4661.                                 Fort Benjamin Harrison, IN
  4662.                                                 46216-5590
  4663.                         AUTOVON:699-4298
  4664.                         FTS:335-4298
  4665.                         COMMERCIAL:(317) 542-4298
  4666. ------------------------------
  4667.  
  4668. Page 86                                               INFO-KERMIT DIGEST V3 #13
  4669.  
  4670.  
  4671. End of Info-Kermit Digest
  4672.  
  4673. INFO-KERMIT DIGEST V3 #14                                               Page 87
  4674.  
  4675. Info-Kermit Digest         Fri, 30 Aug 1985       Volume 3 : Number 14
  4676.  
  4677. Departments:
  4678.  
  4679.   UNIX KERMIT -
  4680.     Bug (?) in C-Kermit 4C
  4681.  
  4682.  
  4683.   MS-DOS KERMIT -
  4684.     Concurrent DOS KERMIT
  4685.  
  4686.  
  4687.   CMS/TSO KERMIT -
  4688.     CMS Kermit Improvements?
  4689.     KERMIT-TSO and 7171 (2 messages)
  4690.     CMS KERMIT and Yale 2.0 (2 messages)
  4691.  
  4692.  
  4693.   MISCELLANY -
  4694.     More on sliding windows
  4695.     Kermit for the PRO
  4696.     Getting K11 on floppies
  4697.     6809 Kermit
  4698.     BTOS Kermit
  4699.     Kermit for TI 99/4A
  4700.     CompuPro KERMIT version wanted to work with Hayes Micromodem.
  4701.     CROSS and other queries
  4702.     Prime Kermit
  4703.     Plea for help
  4704.     Kermit/milnet
  4705.     Kermit over TELENET: Help Needed
  4706.     Kermit for Fortune 32:16
  4707.     Kermit on VMS
  4708.  
  4709.  
  4710. ----------------------------------------------------------------------
  4711.  
  4712. Date: 9 Aug 1985 1612-EDT
  4713. From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
  4714. Subject: More "sliding WINDOWS"
  4715. Keywords: Sliding Windows Kermit, Long Packets
  4716.  
  4717. The gist for micro's lays NOT in the fact, that they have [or haven't] an
  4718. interrupt-structure [infact having none is cleaner then having "something"].
  4719.  
  4720. The PROBLEM typically is the "floppy-controler" i.e FD17xx , which delivers
  4721. data "fast" enough , so that one has to TURN OFF interrupts during READ/WRITE
  4722. but SLOW enough to lead easily to character-loss during floppy-processing.
  4723.  
  4724. The typical coding sequence [very innocent] looks like
  4725.     DI
  4726.     Call Write/Read Sector
  4727.     EI
  4728. ... that alone makes "sliding WINDOWS" impossible - since one eventually HAS
  4729. to write the stuff to the disk - and there's NO TRICK to stop the SENDER from
  4730. sending - except for "holding back ACKs" - and that takes away most of the
  4731.  
  4732. Page 88                                               INFO-KERMIT DIGEST V3 #14
  4733.  
  4734. advertised speed-improvements.
  4735.  
  4736. Obviously the "sector-time" window is dependant on the media-speed [floppies
  4737. will be LOOSERs compared to winnies] and the amount of 'character lossage'
  4738. depends on the channel-speed [ at 1200 baud one might loose NOTHING , since
  4739. the window is about one char-time, and thats hanging around in the USART ...
  4740. at higher speeds it'll be one or more lost char's - i.e. a full NAK/resend
  4741. packet cycle ] - so as seen from the "innocent bystander" we now have
  4742. introduced a feature , which might "work for me" but "not for You" - i.e.
  4743. the same MICRO connected to the same Mainframe will "win" or "fail" depending
  4744. on storage medium and/or channel-speed == in my mind NOT A GOOD IDEA .
  4745.  
  4746. Rgds,
  4747. Bernie.
  4748. ------------------------------
  4749.  
  4750. Date: Wed 7 Aug 85 17:58:06-PDT
  4751. From: Wing Lee <WingLee%ECLD@ECLA>
  4752. Subject: KERMIT-TSO and 7171
  4753. Keywords: TSO Kermit, 7171 Protocol Converters
  4754.  
  4755. I hate to keep on bugging you about KERMIT-TSO and the 7171, but
  4756. my boss keeps on asking me if there is any news.
  4757.  
  4758. This is our situation.  We installed the Series/1 version of KERMIT-TSO
  4759. on our 3081, in March of 1985.  Everything worked fine, and everybody
  4760. was happy.  In May, we replaced our Series/1 with an IBM 7171, so
  4761. that we could have more lines going into TSO.  That's when our
  4762. problems started.  Going through the 7171, we were able to
  4763. download but not upload.  When we tried to upload, the file transfer would
  4764. hang at random places.  When I used DEBUG mode to look at the packets,
  4765. I saw that the tranfer would always stop right after a file transfer.
  4766. As soon as I discovered this, I sent a message to Columbia asking for
  4767. help.
  4768.  
  4769. In the meantime, we have put together a makeshift way to get KERMIT-TSO
  4770. to work.  On our 3081, we run both MVS/TSO and VM/CMS.  Our ascii interface
  4771. to TSO is an IBM 7171, our ascii interface to CMS is a SERIES/1.  We
  4772. have been able to have users who wish to do file transfer to TSO, to
  4773. use the CMS Series/1.  Then they would DIAL MVSA and connect to
  4774. our MVS system.
  4775.  
  4776. That works. But now our Systems people are thinking of replacing the CMS
  4777. Series/1 with another 7171.  When we told them that this would disable
  4778. are ability to use KERMIT altogether, they said that our TSO KERMIT is
  4779. not supported by Columbia, and we should not be using TSO Kermit on our
  4780. TSO system until Columbia has a supported version.  Thus we should not
  4781. even have the package on our system.
  4782.  
  4783. My question is, does Columbia support the Series/1 version of KERMIT-TSO?
  4784.  
  4785. [Ed. - No.  We don't run TSO.]
  4786.  
  4787. wing
  4788. ------------------------------
  4789.  
  4790.  
  4791. INFO-KERMIT DIGEST V3 #14                                               Page 89
  4792.  
  4793. Date: Wed 7 Aug 85 19:10:07-PDT
  4794. From: Wing Lee <WingLee%ECLD@ECLA>
  4795. Subject: kermit-tso and 7171
  4796. Keywords: TSO Kermit, 7171 Protocol Converters
  4797.  
  4798. in my last message i said, that when uploading, the transfer stops
  4799. right after a file transfer.  i meant that the transfer stops right after
  4800. a bad packet.  i should have reread my message more carefully before
  4801. i sent it out.
  4802.  
  4803. wing
  4804.  
  4805. ------------------------------
  4806.  
  4807. From: Gary Mills <mills%uofm-uts.cdn%ubc.csnet@csnet-relay.arpa>
  4808. Subject: 6809 Kermit
  4809. Keywords: 6809 Kermit
  4810.  
  4811. Does anyone have a version of Kermit for the 6809 CPU, with Flex-9 or OS/9
  4812. operating systems?  C or assembler languages would be suitable.
  4813.  
  4814.  
  4815. ------------------------------
  4816.  
  4817. Date:     Sat, 10 Aug 85 13:04 EST
  4818. From:     Larry Afrin <lbafrin%clemson.csnet@csnet-relay.arpa>
  4819. Subject:  Bug (?) in C-Kermit 4C
  4820. Keywords: C-Kermit
  4821.  
  4822. Hi,
  4823.  
  4824.     I just got the latest version of 4C a few days ago (the one
  4825. the Digest swore would be the "absolute last" release of 4C).  I compiled
  4826. it for a System V system, and the problem I noticed occurred when I
  4827. was "get"ting some stuff from SIMTEL20.  The files on SIMTEL that I was
  4828. transferring had names like ABCDEF. and GHIJKLMN.  (the point here being
  4829. that they're all upper-case, as you would expect from a TOPS-20 system).
  4830. I wanted to transfer them to my UNIX system and give them the same,
  4831. upper-case filenames, just without the dot.  I knew that if I told my
  4832. local Kermit "get ABCDEF." or "get ABCDEF", it was going to do some
  4833. funky translation of the name (for what reasons, I don't know; I just
  4834. remember seeing somewhere that Kermit adjusts filenames for the
  4835. "conventions" of your system, which in UNIX usually means all lower-case),
  4836. which isn't what I wanted.  So I figured I would just type in "get" and
  4837. let it prompt me for the remote filespec and the local filespec.  For
  4838. the remote filespec I entered "ABCDEF.", and for the local filespec I
  4839. entered "ABCDEF".  The transfer then started up ... "IRSF" and wham! my
  4840. local Kermit told me "ABCDEF. => abcdef", which wasn't what I wanted.
  4841.  
  4842.     My whole point here is, if Kermit goes to the trouble of asking
  4843. you exactly what you want your local filespec to be, shouldn't it
  4844. refrain from translating that name (in this case from uppercase to
  4845. lowercase)?  In fact, why can't the "get" command be set up so that
  4846. (1) if you don't give a command line filespec and it goes ahead and prompts
  4847. you, it shouldn't translate either the remote or local filespecs; and (2)
  4848. if you do give a command line filespec, it should be interpreted as the
  4849.  
  4850. Page 90                                               INFO-KERMIT DIGEST V3 #14
  4851.  
  4852. *exact* filespec for the local system, but it should be "appropriately"
  4853. translated to make the remote Kermit happy.
  4854.  
  4855.     I'm not 100% sure that (2) is "right", but I do feel that (1) is
  4856. right.
  4857.  
  4858.     Oh, yeah, one more thing:  Also during this transfer operation with
  4859. SIMTEL20, I tried this command: "get *.c".  Assuming my SIMTEL filenames
  4860. matching this spec were ABC.C, DEF.C, GHI.C, and JKL.C, this is what my
  4861. local Kermit reported to me during the transfer:
  4862.  
  4863.         ABC.C => *.c
  4864.         DEF.C => def.c
  4865.         GHI.C => ghi.c
  4866.         JKL.C => jkl.c
  4867.  
  4868. and yes, sure enough, my local Kermit really did create a filename called
  4869. "*.c".  Now, is this a bug, or did I just specify my "get" command
  4870. incorrectly?
  4871.  
  4872.     Thanks for any info, advice, etc., you can provide.
  4873.  
  4874.                     -- Larry Afrin
  4875.                        Dept. of Computer Science
  4876.                        Clemson University
  4877.  
  4878. Please send replies, if any, to:
  4879. lbafrin@clemson                         if you're on CSNet
  4880. lbafrin.clemson@csnet-Relay             if you're on ARPANet
  4881.  
  4882. ------------------------------
  4883.  
  4884. Date: Mon 12 Aug 85 09:15:36-EDT
  4885. From: Bill Catchings <OC.WBC3@CU20B.ARPA>
  4886. Subject: BTOS Kermit
  4887. Keywords: Burroughs B2x Kermit, BTOS
  4888.  
  4889. The best version of Kermit to work with for the Burroughs BTOS is probably
  4890. C Kermit.  I do not know for a fact that Burroughs supplies C for BTOS, but
  4891. Convergent Technologies (the maker of the B-20 series) supplies a C for CTOS
  4892. (The "parent" of BTOS).  My knowledge of BTOS is limited, but I believe that
  4893. CTOS and BTOS are pretty close.  The C for CTOS is pretty poor, based on
  4894. Mark Williams C, and the terminal/file transfer product that CT supplies is
  4895. terrible.  After 40 screens it starts over at the first screen.  Very annoying.
  4896. I plan to be working on a CTOS version of C Kermit in the next few weeks.  If
  4897. I succeed in getting one working it will be announced on Info-Kermit.  If not
  4898. you'll have to try yourself.
  4899.  
  4900.                     -Bill Catchings
  4901.  
  4902. ------------------------------
  4903.  
  4904.  
  4905. Date: Tue, 06 Aug 85 19:58:34 EDT
  4906. From: Peter DiCamillo  <CMSMAINT%BROWNVM.BITNET@WISCVM.ARPA>
  4907. Subject: CMS Kermit Improvements?
  4908.  
  4909. INFO-KERMIT DIGEST V3 #14                                               Page 91
  4910.  
  4911.  
  4912. The latest version of CMS Kermit includes features which make it very
  4913. attractive to users at Brown. These include support for Series/1
  4914. connections, binary data transfer, and server mode. As a result,
  4915. the Computer Center plans to recommend Kermit as the standard file
  4916. transfer program between CMS and  IBM PCs, Macintoshes, and other micros.
  4917. In evaluating CMS Kermit, we noticed that, as documented, server mode
  4918. only supports GET, SEND, FINISH, and BYE. This is very obvious to
  4919. the Macintosh user who has a menu of server commands, most of which
  4920. are not supported by CMS Kermit. Also, it would be useful to us if
  4921. CMS Kermit could preserve the date and time of files whenever possible.
  4922. Is any work planned or in progress to add these features? If not, I
  4923. may attempt to add them myself.
  4924.  
  4925. [Ed. - Kermit allows you to create the file on the destination
  4926.        computer with the same write date and time as on the source
  4927.        computer.  This requires however supporting attribute packet.
  4928.        At this time, CMS Kermit does not support attribute packets
  4929.        although it may do so in the future.  If you'd like to add the
  4930.        support, let us know so there won't be a duplication of effort
  4931.        on the part of some other ambitious soul. ]
  4932.  
  4933.  
  4934. ------------------------------
  4935.  
  4936. Date: 14 Aug 1985 23:45-EST
  4937. From: Sanjay Kapur <kapur%tesla%sbcs.csnet@csnet-relay.arpa>
  4938. Subject: kermit for the pro
  4939. Keywords: DEC PRO300 Kermit
  4940.  
  4941. Is there a version of kermit available for the DEC PRO350 running
  4942. the Professional Operating System? Where can I get a copy of it?
  4943.  
  4944.  
  4945. [Ed. - yes.  It's the k11 version, available on the distribution tape
  4946.        or in numerous other ways (see following message).]
  4947.  
  4948. ------------------------------
  4949.  
  4950. Date: 10 AUG 85 12:04-EST
  4951. From:  BRIAN%UOFT02.BITNET@WISCVM.ARPA
  4952. Subject: GETTING K11 ON FLOPPIES
  4953. Keywords: Kermit-11
  4954.  
  4955. In Response to Kermit Digest re RX0x dist.
  4956.  
  4957.  
  4958. Getting K11 on various media
  4959.  
  4960. K11AAA.AAA     Updated 14-JUN-1985 09:22  Brian Nelson
  4961.  
  4962.  
  4963. Kermit-11 Edit history:  K11CMD.MAC
  4964. Kermit-11 Installation:  K11INS.DOC
  4965. Kermit-11 Documentation: K11HLP.HLP  (no separate user manual)
  4966. Kermit-11 Files:         K11FIL.DOC
  4967.  
  4968. Page 92                                               INFO-KERMIT DIGEST V3 #14
  4969.  
  4970.  
  4971.  
  4972.  
  4973. Please note that while Kermit-11 uses RMS11 for all versions (RT11 excluded)
  4974. you do not need RMS on your system unless you opt to use the versions linked
  4975. to RMSRES (K11.TSK for RSTS/E and K11POS.TSK for M/M+ and P/OS).
  4976. For further information, please read K11INS.DOC
  4977.  
  4978.  
  4979.  
  4980. To get Kermit-11 and all the other Kermits:
  4981.  
  4982.   KERMIT Distribution
  4983.   Columbia University Center for Computing Activities
  4984.   7th Floor, Watson Laboratory
  4985.   612 West 115th Street
  4986.   New York, N.Y.  10025
  4987.  
  4988.  
  4989. There is also a fairly current copy of Kermit-11 available  from  DECUS,
  4990. order  number  11-731.  As  of June 1985 the DECUS library has Kermit-11
  4991. available on RX01's and RX50's (in RT and  P/OS  format).  Additionally,
  4992. the SIG tapes almost always have a current version on them.
  4993.  
  4994.  
  4995. To get Kermit-11 from the author:
  4996.  
  4997.  
  4998. Mail:
  4999.  
  5000. 800bpi          DOS-11 format
  5001. 1600 bpi tape   DOS-11, ANSI or VMS Backup
  5002. RX01            RT format, binaries only
  5003. RX50            RT or P/OS (readable on Micro/RSX), delays are possible
  5004.                 since I have only one PRO/350 and one hard disk.
  5005.  
  5006. For tapes,  VMS Backup format is preferred (default if not specified).
  5007. For RSTS/E, V9 Backup format is preferred. V9 backup is NOT compatible
  5008. with previous releases of RSTS/E, but IS compatible with VMS backup.
  5009.  
  5010. You must supply the media (extras are nice to offset the cost).
  5011.  
  5012.  
  5013. Brian Nelson
  5014. Computer Services
  5015. University of Toledo
  5016. 2801 West Bancroft
  5017. Toledo, Oh 43606
  5018. (419) 537-2841   or   BRIAN@UOFT02.BITNET
  5019.  
  5020.  
  5021. Bitnet:
  5022.  
  5023. from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
  5024.                 CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*
  5025.  
  5026.  
  5027. INFO-KERMIT DIGEST V3 #14                                               Page 93
  5028.  
  5029. from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*
  5030.  
  5031.  
  5032.  Columbia University maintains a BITNET Kermit server also,
  5033. username KERMSRV node CUVMA.  Command format is similiar to
  5034. the VMS KERMSRV on node UOFT01.
  5035.  
  5036. Dialup:
  5037.  
  5038.         (419) 537-4411
  5039.         Service class  VX785A
  5040.         User: KERMIT
  5041.         Password: KERMIT
  5042.  
  5043. Source and hex files are in KER:, binaries are in KERBIN:
  5044.  
  5045. ------------------------------
  5046.  
  5047. Date: Mon 19 Aug 85 05:33:45-PDT
  5048. From: GARGARO@USC-ECLB.ARPA
  5049. Subject: Kermit for TI 99/4A
  5050. Keywords: TI 99/4A Kermit
  5051.  
  5052. Gentlemen
  5053.  
  5054.     I  am  trying  to  locate  a  version  of  Kermit  for  the  Texas
  5055. Instruments 99/4A Home Computer.  I have been informed that one exists
  5056. or  is  currently  under  implementation.   I  would  appreciate   any
  5057. information that you may have regarding Kermit for the TI 99/4A.
  5058.  
  5059. Anthony Gargaro.
  5060.  
  5061. ------------------------------
  5062. Date: Mon, 19 Aug 85 12:23:44 EDT
  5063. From: David Roth (Ft. Benj. Harrison) <droth@BRL.ARPA>
  5064. Subject: CompuPro KERMIT version wanted to work with Hayes Micromodem.
  5065. Keywords: CompuPro Kermit, Hayes Modem
  5066.  
  5067. We need help on getting a version of KERMIT for the CompuPro running
  5068. CP/M 2.2LD to work with a Hayes Micromodem 100 using the microcoupler.
  5069. We have the source to KER:CPMPRO.M80 from Columbia University but it is
  5070. for use with Compupro Interfacer 3/4.
  5071. Thanks in advance.
  5072.                                 David A. Roth
  5073.                                 droth@brl-bmd
  5074.                         US Mail:
  5075.                                 COMMANDER
  5076.                                 USA Soldier Support Center
  5077.                                 ATSG-DTU-S
  5078.                                 Attn: Mr. David A. Roth
  5079.                                 Fort Benjamin Harrison, IN
  5080.                                                 46216-5590
  5081.                         AUTOVON:699-4298
  5082.                         FTS:335-4298
  5083.                         COMMERCIAL:(317) 542-4298
  5084.  
  5085.  
  5086. Page 94                                               INFO-KERMIT DIGEST V3 #14
  5087.  
  5088. ------------------------------
  5089.  
  5090. Date: Mon, 19 Aug 85 13:44:28 edt
  5091. From: jax-lab!jng (John N Guidi)
  5092. Subject: Concurrent DOS KERMIT
  5093. Keywords: MS-DOS Kermit, Concurrent Kermit
  5094.  
  5095. I would like to run KERMIT on a Concurrent DOS, IBM PC/AT system.
  5096. Is there a separate Concurrent DOS distribution? If not, can one
  5097. use the PC-DOS KERMIT while running Concurrent DOS? If this is the
  5098. case, are there any caveates to keep in mind?
  5099. Thanks.
  5100.  
  5101. John Guidi
  5102. The Computing Service
  5103. The Jackson Laboratory
  5104. Bar Harbor, ME  04609
  5105. phone: (207)288-3371
  5106. uucp:  ...!decvax!unh!jaxlab!jng
  5107. bitnet: jaxlab@maine
  5108.  
  5109. ------------------------------
  5110.  
  5111. Date: Friday, 16 August 1985  15:51-MDT
  5112. From: ABN.ISCAMS@USC-ISID.ARPA
  5113. Subject: CROSS and other queries
  5114. Keywords: CROSS Assembler
  5115.  
  5116. NetLandians,
  5117.  
  5118. Could someone please point me to the documentation/instructions for
  5119. CROSS - the cross assembler available on some TOPS-20 hosts, and used
  5120. extensively for KERMIT applications.
  5121.  
  5122. [Ed. - Take a look in psb:<micros>cross.* on Cu20B.]
  5123.  
  5124. Second:  Is CROSS proprietary or public domain?
  5125.  
  5126. [Ed. -  I think it's public domain.]
  5127.  
  5128. Third:  What happened to CU20B as a host?  The KERMIT archives are out there
  5129. (Columbia University), and I saw the msg they were moving the archives to
  5130. another disk... but when trying to FTP to CU20B, I get an unknown host error.
  5131. Can anyone point me right?
  5132.  
  5133. [Ed. - Cu20b underwent some disk reshuffling, but it should be back online
  5134.        now. ]
  5135.  
  5136. Thanks in advance,
  5137. David Kirschbaum
  5138. Toad Hall
  5139.  
  5140. ------------------------------
  5141.  
  5142. Date: Tue, 20 Aug 85 07:53 PDT
  5143. From: "Chase Lila"@LLL-MFE.ARPA
  5144.  
  5145. INFO-KERMIT DIGEST V3 #14                                               Page 95
  5146.  
  5147. Subject: Prime Kermit
  5148. Keywords: Prime Kermit
  5149.  
  5150. Can the Prime Kermit transfer binary files?       chase@lll-mfe.arpa
  5151.  
  5152. ------------------------------
  5153.  
  5154. From: bierma@nprdc.arpa (Larry Bierma)
  5155. Date: 20 August 1985 0953-PDT (Tuesday)
  5156. Subject: CMS KERMIT and Yale 2.0
  5157. Keywords: VM/CMS Kermit, Yale ASCII Communications Program
  5158.  
  5159. Is CMS KERMIT supposed to work through a Series/1 running version 2.0
  5160. of the Yale software?  Whenever we start the server it hangs up the
  5161. line.  Everything works fine in line mode through a 3704, and in page
  5162. mode through a 7171, it's just the series/1 that hangs up.
  5163.  
  5164. [Ed. - We use CMS Kermit through a Series/1 running the version 2.0 of
  5165.        the Yale Ascii code and version 3.2 of EDX all the time without
  5166.        any problems.  The way this works is Kermit puts the S/1 into
  5167.        transparent mode.  It sounds like you don't have the most
  5168.        up-to-date software for the S/1. ]
  5169.  
  5170.  
  5171. --Larry        ARPA: bierma@nprdc.arpa
  5172.         UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
  5173.         PSTN: (619) 225-2161
  5174.  
  5175. ------------------------------
  5176.  
  5177. Date: Tue 20 Aug 85 15:34:52-CDT
  5178. From: CMP.STARCH@UTEXAS-20.ARPA
  5179. Subject: plea for help
  5180. Keywords: VAX/VMS Kermit, HP1000 Kermit
  5181.  
  5182. Hi
  5183.  
  5184. I am trying to find a way to connect my Vax (VMS 4.1) to our HP
  5185. 1000 running the RTE-A operating system.  Is there a Kermit out
  5186. there for this OS.  I looked and found the one for a previous
  5187. HP1000 operating system (RT6/vm or some such moniker)
  5188.  
  5189. Please respond to CMP.STARCH@UTEXAS-20.ARPA, as I am not on the
  5190. INFO-KERMIT discussion.
  5191.  
  5192. Steve Kneuper
  5193. Lockheed Austin Division
  5194. (512)386-1676
  5195.  
  5196. ------------------------------
  5197.  
  5198. Date: 14 Aug 1985 1541-PST
  5199. From: Contr36 <CONTR36 at NOSC-TECR>
  5200. Subject: kermit/milnet
  5201. Keywords: C-Kermit, MILNET
  5202.  
  5203.  
  5204. Page 96                                               INFO-KERMIT DIGEST V3 #14
  5205.  
  5206. from: Paul Attermeier
  5207.       Sandia National Labs
  5208.       Albuquerque, NM
  5209.       (505) 844-1106
  5210.  
  5211. I am trying to transfer some files from a VAX at the Naval Ocean
  5212. Systems Center back to my machine using Kermit. I have had no success
  5213. so far and the problem seems to lie somewhere in the MILNET
  5214. connection.
  5215.  
  5216. I'm running Kermit on a VAX/780 under Ultrix.  (The header reads
  5217. 'C-Kermit 4.2 (030) Prerelease #2, 5 March 85, 4.2 BSD).  I've been
  5218. able to transfer files from another local 780 running VMS and a
  5219. version of Kermit (VMS Kermit-32 version 3.0.052) that appears to be
  5220. older than the one on the NOSC machine, (VMS Kermit-32 version
  5221. 3.1.062) so I don't think there is a Kermit version incompatibility
  5222. problem.
  5223.  
  5224. Whenever I try a Kermit file transfer across MILNET, it just tries
  5225. for a minute or two and then times out. Do you know of any Kermit
  5226. or MILNET parameters which need to be changed from their defaults?
  5227.  
  5228. ------------------------------
  5229.  
  5230. Date:     Fri, 23 Aug 85 09:57 EST
  5231. From:     Larry Afrin <lbafrin%clemson.csnet@csnet-relay.arpa>
  5232. Subject:  Kermit over TELENET: Help Needed
  5233. Keywords: TELENET
  5234.  
  5235. Fellow Frog Lovers,
  5236.  
  5237.     I would like to use Kermit for file transfer between my IBM PC and an
  5238. NCR Tower running System V UNIX.  Both machines are running the latest
  5239. versions of Kermit available for them.  The only problem is that GTE TELENET
  5240. is in the middle.  (From the PC's Kermit I dial TELENET's local number and
  5241. then give the connect code (host address) by which TELENET knows the Tower.)
  5242. Something with TELENET is preventing file transfer from working (the
  5243. initialization packets don't even make it through).  Does anyone out there
  5244. have either (1) a proven method for using Kermit over TELENET or (2) an
  5245. explanation of why such may be impossible?  Any help, advice, pointers, etc.
  5246. would be greatly appreciated.  Thanks in advance...
  5247.  
  5248.                     -- Larry Afrin
  5249.                        Dept. of Computer Science
  5250.                        Clemson University
  5251.  
  5252. Please send replies, if any, to:
  5253. lbafrin@clemson                         if you're on CSNet
  5254. lbafrin.clemson@csnet-Relay             if you're on ARPANet
  5255.  
  5256. ------------------------------
  5257.  
  5258. Date: Wednesday, 21 August 1985  08:59-MDT
  5259. From: Steve Westfall <ihnp4!gargoyle!sphinx!west@Ucb-Vax.ARPA>
  5260. Subject:   Kermit for Fortune 32:16
  5261. Keywords: Fortune 32:16 Kermit
  5262.  
  5263. INFO-KERMIT DIGEST V3 #14                                               Page 97
  5264.  
  5265.  
  5266. The Bulletin of the Atomic Scientists at the University of Chicago has
  5267. a Fortune 32:16 computer.  The system administrator has had problems
  5268. getting kermit to work with his Fortune and would like to get in touch
  5269. with anyone who has helpful information about this.  Please get in
  5270. touch with the following person, not me:
  5271.  
  5272.             Barry Bowen
  5273.             Bulletin of the Atomic Scientists
  5274.             5801 S. Kenwood
  5275.             Chicago, Illinois 60637
  5276.             312-363-5225
  5277.             UUCP:  ...ihnp4!gargoyle!xeno
  5278.  
  5279. Thanks.
  5280.  
  5281.  
  5282. Steve Westfall                Uucp:  ihnp4!gargoyle!sphinx!west
  5283. Senior Staff Analyst          Bitnet:  staff.westfall@UChicago.bitnet
  5284. U. of Chicago Computation Center  Mailnet: staff.westfall@UChicago.Mailnet
  5285.  
  5286. ------------------------------
  5287.  
  5288. Date: 22 Aug 1985 12:32-EDT
  5289. Subject: kermit on vms
  5290. From: ZAKAR@USC-ISI.ARPA
  5291. Keywords: VAX/VMS Kermit, C-Kermit
  5292.  
  5293.      I am trying to connect a VAX/VMS system to a VAX/UNIX 4.2 system
  5294. using KERMIT.  The UNIX side is running version 4C (CK*) and the VMS
  5295. side is running the MACRO version (VMS*.MAR).  The link is made up of
  5296. ports of DMF32s on both machines.  If someone else has tried this before,
  5297. I need to talk to them because I may not have set up the VMS environment
  5298. correctly.  From the UNIX side I can CONNECT to VMS just like a terminal
  5299. with no problems.  On the VMS side though, when I CONNECT to UNIX,
  5300. I have a problem with data overrunning buffers, as though there were no
  5301. flow control.  Any help would be appreciated.
  5302.  
  5303.   Joe Zakar
  5304. Zakar at USC-ISI
  5305.  
  5306. ------------------------------
  5307.  
  5308. End of Info-Kermit Digest
  5309.  
  5310. Page 98                                               INFO-KERMIT DIGEST V3 #15
  5311.  
  5312. Info-Kermit Digest         Thu,  5 Sep 1985       Volume 3 : Number 15
  5313.  
  5314. Departments:
  5315.  
  5316.   SLIDING WINDOWS -
  5317.     Sliding Windows Work on Fast Line with Slow Disk
  5318.     Re: ANY-duplex Windows (2 messages)
  5319.  
  5320.   MS-DOS KERMIT -
  5321.     POPDOS2 and Kermit Problem
  5322.     Problem with MS kermit on DEC Rainbow 100+
  5323.     Leading Edge & Corona Portable -- Kermit Fit?
  5324.     Kermit for the Hyperion?
  5325.  
  5326.   IBM MAINFRAME KERMIT -
  5327.     Solution to TSO Kermit vs 7171 Problem
  5328.     Kermit with Yale ASCII?
  5329.  
  5330. ----------------------------------------------------------------------
  5331.  
  5332. Date: Thu 22 Aug 85 15:42:46-EDT
  5333. From: John Mulligan <OC.SOURCE@CU20B.ARPA>
  5334. Subject: Sliding Windows Work on Fast Line with Slow Disk
  5335. Keywords: Sliding Windows Kermit
  5336.  
  5337. Frank - I tried the windowing direct connect at 9600 baud with a standard
  5338. IBM PC (Floppies) and had no problems.
  5339.  
  5340. ------------------------------
  5341.  
  5342. Date: Thu 22 Aug 85 15:46:43-EDT
  5343. From: John Mulligan <OC.SOURCE@CU20B.ARPA>
  5344. Subject: Re: ANY-duplex Windows
  5345. Keywords: Sliding Windows Kermit, Long Packets
  5346.  
  5347. Dear Ken,
  5348.  
  5349.    I would like to thank you for your messages on the windowing proposal.
  5350. They were well thought out and written, and helped us a great deal in
  5351. refining the proposal.  I have been meaning to reply before, but I was
  5352. still learning the mail system on Columbia.  Frank was the only one I
  5353. knew how to send messages to!
  5354.  
  5355.    Anyway, we have been thinking about the half-duplex situation.  I'm
  5356. sending our current thoughts to you before we go public with them.
  5357.  
  5358.    First, the Send-Init packet.  Define an additional bit in the capabilities
  5359. mask indicating half-duplex windowing:
  5360.  
  5361.    Bit        1     2     3     4     5
  5362.              reserved  ATTRIB  FULL  HALF
  5363.  
  5364.   Do a bitwise "AND" of the sender pair with the receiver pair.
  5365.  
  5366.   Full  Half
  5367.   0     0       Kermit Classic
  5368.  
  5369. INFO-KERMIT DIGEST V3 #15                                               Page 99
  5370.  
  5371.   1     0       Full-duplex as defined now
  5372.   0     1       Half-duplex extension to be elaborated
  5373.   1     1       Either full or half *
  5374.                  *If both, default to half; shouldn't happen because
  5375.                   second send-init should pick one.
  5376.  
  5377. Second, half-duplex itself:
  5378.  
  5379.    Create a new data packet type that says "this data packet is not the
  5380.    last in this group; don't answer yet".  Thus the current standard
  5381.    DATA packet can be answered right away, and our current full-duplex
  5382.    definition is consistent.
  5383.  
  5384.    I'm suggesting the new packet type be called the WATA packet, and it
  5385.    would be just like a DATA packet except that it would mean
  5386.    "WAiT A minute, I'm not done sending this group, don't reply yet".
  5387.  
  5388.    A DATA packet (as in "DAT's All for this group, go ahead and reply")
  5389.    would signal the end of a particular group of packets.
  5390.  
  5391.    The above definition is consistent with both classic KERMIT and with
  5392.    the full-duplex windowing.
  5393.  
  5394.    As the receiver processed WATA packets, it would compose the ACKs and
  5395.    NAKs in the same manner as for full-duplex windowing, but buffer
  5396.    them for sending when the half-duplex line was turned around (indicated by
  5397.    receipt of a DATA packet).
  5398.  
  5399.    This system should use almost identical code for both full and half
  5400.    duplex windowing, and would (as you mentioned) make it very
  5401.    easy to debug in half-duplex and then move to full-duplex.
  5402.  
  5403.    Error handling, window rotation, etc. appear to remain the same,
  5404.    at least at first glance.
  5405.  
  5406.    We think the maximum half-duplex window size could be 63, instead
  5407.    of 32, but we aren't totally sure.
  5408.  
  5409. Thanks again for your very helpful thoughts.  Let me know what you think of
  5410. the above.
  5411.                      -John Mulligan
  5412.  
  5413. ------------------------------
  5414.  
  5415. Date: Mon, 26 Aug 85 23:19:52 pdt
  5416. From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
  5417. Subject: ANY-Duplex Windows
  5418. Keywords: Sliding Windows Kermit, Long Packets
  5419.  
  5420. Glad to hear from you, John!
  5421.  
  5422. Here are my thoughts:
  5423.  
  5424. Repeated for the benfit of others:
  5425. >
  5426. >    First, the Send-Init packet.  Define an additional bit in the capabilities
  5427.  
  5428. Page 100                                              INFO-KERMIT DIGEST V3 #15
  5429.  
  5430. >     mask indicating half-duplex windowing:
  5431. >
  5432. >    Bit        1     2     3     4     5
  5433. >              reserved  ATTRIB  FULL  HALF
  5434. >
  5435. >
  5436. >   Do a bitwise "AND" of the sender pair with the receiver pair.
  5437. >
  5438. >   Full  Half
  5439. >   0     0       Kermit Classic
  5440. >   1     0       Full-duplex as defined now
  5441. >   0     1       Half-duplex extension to be elaborated
  5442. >   1     1       Either full or half *
  5443. >                  *If both, default to half; shouldn't happen because
  5444. >                   second send-init should pick one.
  5445.  
  5446. Yes, but I think that "1 1" should default to full duplex.
  5447. Both sides are capable, so why not use full-duplex?
  5448. (If you want to choose half-duplex with a pair of Kermits
  5449. capable of either, "SET WINDOW HALF-DUPLEX" or some such command
  5450. should cause only the half-duplex bit to be sent.)
  5451.  
  5452.  
  5453. Both sides should also send a super-packet size (S) in the
  5454. next byte following the window-size (W) byte.
  5455. If half-duplex windows are selected, then the super-packet size
  5456. used is the lower of the two super-packet sizes.
  5457.  
  5458. Super-packet size must be less than or equal to half the window size
  5459. (S <= W/2) :
  5460.     1) We must have window size (W) >= 2x super-packet size (S) in case
  5461.     the first packet of a super-packet is lost (then the next super packet
  5462.     contains packet 1 plus packets S+1 through 2S-1).
  5463.     2) We can only make use of W > 2*S in the case of multple retries
  5464.     for a particular packet.  (This could be useful in very noisy
  5465.     environments...)
  5466. The normal case (the program default) should probably be for S = W/2.
  5467. Note that S may be more limited by a machine's input buffer size
  5468. than by W (=~ memory size).   It might be less than W/2 even for full
  5469. duplex machines (i.e., how *long* can a full-duplex machine sustain
  5470. a full speed input without any pauses?).
  5471.  
  5472. Note that super-packet size is a maximum only.
  5473.  
  5474. More repeated stuff:
  5475. >
  5476. >
  5477. > Second, half-duplex itself:
  5478. >
  5479. >    Create a new data packet type that says "this data packet is not the
  5480. >    last in this group; don't answer yet".  Thus the current standard
  5481. >    DATA packet can be answered right away, and our current full-duplex
  5482. >    definition is consistent.
  5483. >
  5484. >    I'm suggesting the new packet type be called the WATA packet, and it
  5485. >    would be just like a DATA packet except that it would mean
  5486.  
  5487. INFO-KERMIT DIGEST V3 #15                                              Page 101
  5488.  
  5489. >    "WAiT A minute, I'm not done sending this group, don't reply yet".
  5490. >
  5491. >    A DATA packet (as in "DAT's All for this group, go ahead and reply")
  5492. >    would signal the end of a particular group of packets.
  5493. >
  5494. >    The above definition is consistent with both classic KERMIT and with
  5495. >    the full-duplex windowing.
  5496. >
  5497. >    As the receiver processed WATA packets, it would compose the ACKs and
  5498. >    NAKs in the same manner as for full-duplex windowing, but buffer
  5499. >    them for sending when the half-duplex line was turned around (indicated by
  5500. >    receipt of a DATA packet).
  5501.  
  5502. I'm not convinced that we gain by adding a new packet type.
  5503.  
  5504. Note that we cannot send an EOL character to the half-duplex host
  5505. between packets, because this causes the host to finish the read
  5506. and probably miss the start of the next packet.  On my system,
  5507. at least, the system not only can't send while it's receiving,
  5508. but, after completing a read, it doesn't buffer until a new
  5509. read is issued for the line.
  5510. System call overhead ensures that the next read will not be issued
  5511. until well after several characters of the next packet have gone
  5512. by, even if no processing is done on the packet in the meantime.
  5513.  
  5514. (The alternative is XON handshaking between packets, which
  5515. will defeat the whole pupose of super-packets.
  5516. Note also, that we have not gotten away from XON handshaking
  5517. between super-packets.)
  5518.  
  5519. This means that when the kermit program on a half-duplex host
  5520. gets the packet, an EOL has been received.  EOL is a de-facto
  5521. super-packet delimiter.
  5522. As soon as the end of the super-packet (the EOL) is processed,
  5523. the program knows it can proceed to reply.
  5524.  
  5525. If one side is full-duplex, it can queue up ACKs and NAKs as it reads
  5526. packets, but it must wait for the EOL (and probably XON) before
  5527. sending them.  I suppose that for a full-duplex host,
  5528. WATA/DATA is a way of providing the higher-level protocol
  5529. with the end of super-packet data which the half-duplex host
  5530. gets implicity by the nature of its i/o system.
  5531.  
  5532. It seems to me that making the send-packet routine wait for
  5533. receiving routine to get an XON is sufficent, although this
  5534. hides the super-packets from the packet-level protocol.
  5535. Is there a reason to tell it?
  5536. If so, perhaps the full-duplex kermit can implement a WATA
  5537. packet internally: a DATA packet received without an EOL gets
  5538. reported internally as a WATA,
  5539. but only DATA packets are actually sent over the wires.
  5540.  
  5541. I'm not real strong on this one way or the other;
  5542. I'm just wary of adding packet types.
  5543.  
  5544. As Bruce Cowan points out, a half-duplex receiver can NAK
  5545.  
  5546. Page 102                                              INFO-KERMIT DIGEST V3 #15
  5547.  
  5548. bad-checksum packets since it *knows* which packets were supposed
  5549. to be sent (including which ones resent).
  5550. I'm not sure whether this helps or not, since the absence of an ACK
  5551. is just as sure an indication to the sender.  *Something* (at least one
  5552. ACK/NAK) does have to be sent, however, to let the sender know
  5553. to retransmit.
  5554. The best policy is probably to send only ACK's unless no good packets
  5555. are received, in which case a NAK for the lowest-numbered outstanding
  5556. packet may be sent.
  5557. This has the advantage of agreeing with the full-duplex case,
  5558. for best commonality of coding.
  5559.  
  5560. It seems to me that where super-packets are most vulnerable is if
  5561. the EOL (or the XON) is lost.  In that case, my system, at least,
  5562. will time out and throw away the whole super-packet!
  5563. Some simple kluges will help here: send some padding followed by a
  5564. second EOL character *after* each super packet if the padding
  5565. parameter is non-zero.
  5566.  
  5567. As long as we don't get into a situation where the end of the super-packet
  5568. (and the EOL) is lost on every transmission, though, we still gain:
  5569. the critical EOL characters are a lower percentage of the
  5570. total characters sent.
  5571.  
  5572. >    This system should use almost identical code for both full and half
  5573. >    duplex windowing, and would (as you mentioned) make it very
  5574. >    easy to debug in half-duplex and then move to full-duplex.
  5575. >
  5576. >    Error handling, window rotation, etc. appear to remain the same,
  5577. >    at least at first glance.
  5578.  
  5579. I believe so, too.
  5580.  
  5581. >    We think the maximum half-duplex window size could be 63, instead
  5582. >    of 32, but we aren't totally sure.
  5583.  
  5584. I'm not sure that the gain would be worth making it different
  5585. from the full-duplex case.  Ease of coding and all...
  5586.  
  5587. One thing I have not thought about yet is how to integrate long packets
  5588. with windows.  Bruce makes a good case for allowing packets to be
  5589. close to 128 or 256 characters to take advantage of public data network
  5590. packet sizes.  I lean towards using the published long-packet
  5591. extension rather than his proposed special case for up to triple-size
  5592. packets, though.
  5593. It seems that the easy solution is to state that window and super-packet
  5594. negotiations are really for windows of 94*W *characters*;
  5595. when using longer packets, you must scale W and S down accordingly.
  5596. This is not as flexible as one might wish for, though.
  5597.  
  5598. Your turn!
  5599.  
  5600. Ken Poulton
  5601.  
  5602. Bit by bit, byte by byte, we'll figure it out...
  5603.  
  5604.  
  5605. INFO-KERMIT DIGEST V3 #15                                              Page 103
  5606.  
  5607. ------------------------------
  5608.  
  5609. Date: Tue 13 Aug 85 13:45:37-EDT
  5610. From: Fuat C. Baran <BARAN@COLUMBIA-20.ARPA>
  5611. Subject: POPDOS2 and Kermit Problem
  5612. Keywords: MS-DOS Kermit, popdos2
  5613.  
  5614. I have been testing some of the popups (Bellsoft) recently and I have
  5615. found one problem.  The problem occurs when I use Kermit (v2.28) and
  5616. popdos2.  Here is what happens:
  5617.  
  5618. I install the popup and go into kermit.  Until I use popdos2 (calling
  5619. it up with ALT-U) I have no problems.  Then I call popdos2 and do the
  5620. following: I cd to a subdirectory and a dir *.* of the subdirectory.
  5621. I then exit from popdos2 and continue with Kermit.  I try transferring
  5622. more files but later when I look at the files I see that they are all
  5623. filled with garbage.  The garbage looks like random characters and,
  5624. here and there, file names of the subdirectory that I had done the dir
  5625. on.  I tried this several times and with different files and got the
  5626. same results.  Kermit works fine until I do the cd and dir sequence in
  5627. popdos2.  Any files transferred after that point come out as garbage.
  5628.  
  5629. So far that is the only major problem I have encountered with popups.
  5630. I minor irritation is the alarm clock feature in continuous display
  5631. mode.  Every time the screen scrolls up a line it moves the clock (I
  5632. keep the display in the top right hand corner of the screen) up with
  5633. it and then it redisplays it where it should be.  (If you put the
  5634. clock in some other place, on the bottom for example, then it scrolls
  5635. up with the page and you get multiple displays on your screen.)
  5636.  
  5637. Note: I have an IBM-PC with 256K and two disk drives.  I use a TAXAN
  5638. monochrome display with a Paradise Color Card (yuk!  [The Paradise
  5639. card has been giving me problems like substituting characters on my
  5640. screen ("S." -> "S*" with the "*" flickering, etc...)])
  5641.  
  5642.                                         --Fuat Baran
  5643.                                           BARAN@Columbia-20.ARPA
  5644.  
  5645. ------------------------------
  5646.  
  5647. Date: Fri, 23 Aug 85 10:38:21 mdt
  5648. From: rgt%a@LANL.ARPA (Richard Thomsen)
  5649. Subject: Problem with MS kermit on DEC Rainbow 100+
  5650. Keywords: MS-DOS Kermit, DEC Rainbow
  5651.  
  5652. I have (am currently) using MSKERMIT on my Rainbow 100+, connecting to a
  5653. Berkley 4.2 UNIX system on a VAX.  When I run the Rand Editor under Kermit,
  5654. the cursor arrow keys do not work.  When I run the Rand Editor using the
  5655. Rainbow built-in terminal emulator, then the arrow keys work.  I suspect
  5656. that the Kermit program does not change the normal cursor keys to the
  5657. application cursor keys, but it does so with the keypad keys, which work
  5658. as expected.
  5659.  
  5660. I have not had a chance to look extensively at the code, but I guess I could
  5661. if that is desired.
  5662.  
  5663.  
  5664. Page 104                                              INFO-KERMIT DIGEST V3 #15
  5665.  
  5666.                         Richard Thomsen
  5667.                         rgt@lanl.arpa
  5668.  
  5669. [Ed. - In a pinch, you can always make a file that does "set key" commands
  5670. for the cursor keys, and "take" the file whenever you want to run the
  5671. editor.]
  5672.  
  5673. ------------------------------
  5674.  
  5675. Date: 25 Aug 1985 0040-PDT
  5676. From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
  5677. Subject: Leading Edge & Corona Portable -- Kermit Fit?
  5678. Keywords: Leading Edge D PC, Corona Portable PC
  5679.  
  5680. For reasons explained below, the new Leading Edge D machine
  5681. might be an attractive PC compatable. As might also a Corona portable
  5682. at about $1250.
  5683.  
  5684. Has anybody had experience using recent MS-Kermits (2.27 or 2.28) with
  5685. either of these machines. [I would also appreciate any comments on the
  5686. compatability or ruggedness of these machines if anybody has relevant
  5687. experience.]
  5688.  
  5689. Some dealers in Southern California are pricing the Leading Edge D Machine
  5690. rather aggresively -- with 640K, parallel & seriel port, Hercules-like board,
  5691. hefty power supply, monitor & 2 DSDD drives ... about $1300-$1400.
  5692. About $700 more for a 20MB Seagate or Rodine hard disk w/WD controller.
  5693.  
  5694. They will also take off about 25% for universities...... making the
  5695. floppy machine about $1150 and the hard disk machine about $1700.
  5696.  
  5697. These are attractive prices..... if the machine works well, is
  5698. about as compatable as anything else on the market, etc. (And if Leading
  5699. Edge doesn't go under in its endless suits with Mitsubishi.)
  5700.  
  5701. BTW. The machine has a small footprint and also comes with a 1 year warranty.
  5702. Processor is an 8088 at 4.77 MHz. No speed demon, but the aim seems to
  5703. be to aim at the highest cmpatability possible (Phoenix BIOS, ...).
  5704.  
  5705. I would apprecaite any comments on the compatability, ruggedness of the Leading
  5706. Eedge D machine from people who can share some recent experience.
  5707.  
  5708. I am told that this machine is just coming to market and that it is better (?)
  5709. than the earlier M machine which Mitsubishi manufactured for Leading Edge.
  5710.  
  5711. I'll summarize key responses for the net.
  5712.  
  5713. Rob Kling
  5714. Department of Information and Computer Science
  5715. University of California, Irvine
  5716. kling@uci-ics-a
  5717.  
  5718. PS. Corona has also recently dropped prices. I would also appreciate
  5719. comments on the IBM compatability & general value of the Corona portables
  5720. manufactured in the last year (since the ROM BIOS was changed because of the
  5721. suit by IBM).
  5722.  
  5723. INFO-KERMIT DIGEST V3 #15                                              Page 105
  5724.  
  5725.  
  5726. ------------------------------
  5727.  
  5728. Date: Wed, 4 Sep 85 11:48:05 pdt
  5729. From: Peter Ludemann <ludemann%ubc.csnet@csnet-relay.arpa>
  5730. Subject: Kermit for the Hyperion?
  5731. Keywords: Hyperion Kermit
  5732.  
  5733. Does there exist a version of Kermit for the Hyperion
  5734. (also sometimes known as Bytec Hyperion or Anderson-Jacobson
  5735. Ajile) running DOS2.11 (DOS1.x is acceptable)?
  5736.  
  5737. The generic MS-DOS Kermit gets a "write error while reading from
  5738. COM1" error - I suspect the problem is that the Hyperion uses
  5739. a Zilog SIO chip instead of whatever the IBM-PC uses.
  5740.  
  5741. Thanks in advance,
  5742.  
  5743. Peter Ludemann
  5744.     ludemann@ubc-cs.uucp (ubc-vision!ubc-cs!ludemann)
  5745.     ludemann@cs.ubc.cdn  (ludemann@cs.ubc.cdn@ubc.mailnet)
  5746.     ludemann@ubc.csnet   (ludemann%ubc.csnet@CSNET-RELAY.ARPA)
  5747.  
  5748. [Ed. - Generic MS-DOS Kermit should be able to work on any DOS machine.
  5749. It uses only DOS calls for i/o, and has no knowledge of any chip.  Try
  5750. fooling with the SET PORT command, and maybe you'll stumble upon a device
  5751. designator that will work.]
  5752.  
  5753. ------------------------------
  5754.  
  5755. Date: Wed 14 Aug 85 08:52:52-PDT
  5756. From: Wing Lee <WingLee%ECLD@ECLA>
  5757. Subject: Solution to TSO Kermit vs 7171 Problem
  5758. Keywords: TSO Kermit, 7171 Protocol Converters
  5759.  
  5760. Good News!  The problem we had with the Series/1 version of TSO-KERMIT
  5761. has been solved.  The problem we were having was that TSO-KERMIT would
  5762. hang at random places whenever you tried to upload to TSO.  One of
  5763. our Systems Programmers, Valaine Saito, discovered what we think
  5764. the problem is.  What follows is Valaine's message to me.
  5765.  
  5766. >    i looked at the kermit through the 7171 problem again since it appears
  5767. >that it really HAS to work if we're going to lose a s/1.  i stumbled through
  5768. >the assembler program, it looks like the logic is okay.  after determining
  5769. >that, i went to the s/1 and 7171 manuals to see what the difference was.  it
  5770. >turns out that there is NO logical difference, but there clearly is a
  5771. >functional difference.
  5772. >
  5773. >    both the s/1 and the 7171 have 64 char type ahead buffers.  the s/1 must
  5774. >handle it differently.  when i have both the host and micro kermits sending
  5775. >packet lengths of 60 (less than the 64 char buffer size), everything works
  5776. >fine.  when either of the kermits sends > 64 packet lengths, the familiar
  5777. >"failure to receive ackn from host" msg appears on the micro and the transfer
  5778. >stops.  (all this pertains to file transfer from micro to host, i assume the
  5779. >other way works since no one has said otherwise.)  at 9600 baud, i ran a
  5780. >largish file (60+ kb) through a number of times (10 or so) and it worked
  5781.  
  5782. Page 106                                              INFO-KERMIT DIGEST V3 #15
  5783.  
  5784. >every time with BOTH kermits sending packet sizes of less than 64.
  5785. >
  5786. >    so the solution is to send packets of size X, where x is less than 64
  5787. >(i always tried sizes of < 64, i didn't try 64).  the practical options
  5788. >are:
  5789. >
  5790. >    tell users about the packet length problem and have them set both
  5791. >    lengths themselves.
  5792. >
  5793. >    re-code the host kermit to accept a max packet size of 63 or 64.
  5794. >    (this isn't too cool because only the receive section has the
  5795. >     problem.  changing the max packet size would affect all
  5796. >     sections.)
  5797. >    
  5798. >    re-code the host kermit to utilize the RPSIZ variable correctly
  5799. >    and change the value to F'64' (or 63).  RPSIZ is the max receive
  5800. >    packet size.
  5801.  
  5802. I have tried sending packet sizes of 64 bytes and that works.  When I tried 65
  5803. byte packets, the upload failed, so it looks like 64 is the magic number.
  5804.  
  5805. wing lee
  5806.  
  5807. [Ed. - For CMS Kermit, we will look into the possibility that the program
  5808. can determine if it's a 7171 (it's not clear that it reports itself
  5809. differently from a Series/1) and in that case use the smaller packet size.]
  5810.  
  5811. ------------------------------
  5812.  
  5813. Date: Wed, 28 Aug 85 17:12 EST
  5814. From: Jim Ennis  <JIM%UCF1VM.BITNET@WISCVM.ARPA>
  5815. Subject: Kermit with Yale ASCII?
  5816. Keywords: Yale ASCII Communications Program
  5817.  
  5818. What is the oldest version of the YALE ASCII communication package that
  5819. can be used with Kermit for upload download (i.e. transparency)?
  5820. We have an old turkey implementation using Yale ASCII V2.0 running
  5821. under EDX V3.2.....    It is my understanding that I need to go to a
  5822. more recent version of the Yale ASCII support in order to utilize the
  5823. transparency capabilities of that later version.  Furthermore, I need
  5824. to go to a more recent version of EDX before I can go to the more
  5825. recent version of the Yale package.  Information on this subject will
  5826. be greatly appreciated...... The only reason this is an issue is be-
  5827. cause we have only floppies on the box (no hard drive) and I want to
  5828. get it right the first try.  Sincerely.
  5829.  
  5830. [Ed. - We run version 2.0 of the Yale ASCII package, and version 3.2 at
  5831. update level P0A of the EDX Supervisor, and have experienced no problems.
  5832. There was, however, a complaint from Larry Bierma@NPRDC in the last Info-Kermit
  5833. digest, who claimed that file transfers through the Series/1 would "hang up"
  5834. even though they worked fine through the 7171 or 3704.]
  5835.  
  5836. ------------------------------
  5837.  
  5838. End of Info-Kermit Digest
  5839.  
  5840. INFO-KERMIT DIGEST V3 #16                                              Page 107
  5841.  
  5842. Info-Kermit Digest         Fri,  6 Sep 1985       Volume 3 : Number 16
  5843.  
  5844. Today's Topics:
  5845.  
  5846.              Downloading .EXE Files Which Destroy Monitor
  5847.                            CR/LF Processing
  5848.    How to Make Kermit Work over European Packet Switching Networks
  5849.                           Kermit on NEC 8001
  5850.                         Concurrent DOS Kermit
  5851.                   New BITNET KERMSRV Command Syntax
  5852.        Kermit for Japanese Microcomputers and NTT Lisp Machine
  5853.                      Kermit for Sharp PC 1500 A?
  5854.  
  5855. ----------------------------------------------------------------------
  5856.  
  5857. Date: Thu, 15 Aug 85 11:58:49 pdt
  5858. From: reynolds@AMES-NAS.ARPA (Don Reynolds)
  5859. Subject: Downloading .EXE Files Which Destroy Monitor
  5860. Keywords: .EXE File Transfer
  5861.  
  5862. Welcome to a new user of Kermit on an IBM compatible!  We like the frog
  5863. a lot here, but he sometimes croaks!  This may not be your problem, but
  5864. the symptoms happened to me before.  By mistake I used the host command:
  5865.  
  5866.     kermit s filename.ext
  5867.  
  5868. which sends 7-bit ascii text files, but will not send 8-bit (image mode)
  5869. executable (.COM & .EXE) files, Wordstar format files, or other binary
  5870. files.  The command for image mode is
  5871.  
  5872.     kermit si filename.ext
  5873.  
  5874. If you try it without the "i" switch it really trashes the files, and gives
  5875. the results Brzozowski states a couple messages down from your message.
  5876. However, the file size still looks reasonable using the DOS DIR command.
  5877.  
  5878. Question for the net:
  5879.  
  5880. People have noted in this digest problems burning out the IBM monochrome
  5881. display trying to execute such a file.  I wonder if something like Norton's
  5882. Utilities, U-File, or some other utility that looks at disk sectors or one
  5883. that looks at memory can easily look at the header to see if the file has
  5884. been trashed?  Will DEBUG work?  What do you look for?  Note that I person-
  5885. ally have only academic interest since we have mostly color monitors here,
  5886. but someday I may have to download executables to a monochrome system.
  5887.  
  5888. Best,
  5889. Don
  5890.  
  5891. [Ed. - The Kermit protocol allows file transmission in both text and binary
  5892. mode.  Text mode means that any necessary conversions are done on the file
  5893. -- by both the sender and the receiver -- to make the file useful and
  5894. readable on the target system.  Binary mode means no conversions are done.
  5895. Unfortunately, most Kermit programs have to rely on the user to specify
  5896. whether a file is text or binary, because (a) the sending Kermit program
  5897. usually can't tell because most systems (e.g. MS-DOS) don't provide this
  5898.  
  5899. Page 108                                              INFO-KERMIT DIGEST V3 #16
  5900.  
  5901. information in the file descriptor, and (b) the receiving Kermit certainly
  5902. doesn't know (unless the sender informs it using the almost universally
  5903. unimplemented Attribute packet).  Now, it might be observed that text files
  5904. tend to contain bytes whose high-order bits are all off, whereas binary
  5905. files tend to have many bytes with this bit on.  However, for the sending
  5906. Kermit program to determine whether a file is binary by this method would
  5907. require it to make a preliminary pass through the file (the WHOLE file if it
  5908. turns out to be text) which would be undesirable for many reasons (e.g.
  5909. timeouts when files are long).  Many operating systems require executable
  5910. programs to be in a certain format or to be tagged in a certain way, and
  5911. will therefore not attempt to execute text files.  But since not all OS's
  5912. guard themselves in this way, users should also take precautions.  On a
  5913. case-by-case basis, heuristics can be added to some of the Kermit programs
  5914. but they will never be foolproof.  For instance, PDP-11 Kermit allows the
  5915. use to specify a list of filetypes to determine the mode of the file -- but
  5916. how can it know whether a .COM file is a DCL command file (text) or, say, a
  5917. CP/M-80 program image (binary)?]
  5918.  
  5919. ------------------------------
  5920.  
  5921. Date:     Fri, 23 Aug 85 15:06:18 BST
  5922. From:     Chris-on-Fridays <cjk@ucl-cs.arpa>
  5923. Subject:  CR/LF Processing.
  5924. Keywords: CR/LF
  5925.  
  5926. Info:
  5927.  
  5928.      Is there an accepted policy about when Kermit should and should not do
  5929. CR/LF (logical-end-of-record) processing?
  5930.  
  5931.      Obviously it is wanted in text-files and not in binaries.  By default
  5932. any 7-bit file is probably text, and any file sent as 8-bit image is
  5933. probably not; but what assumption do you make if 8th-bit-prefixing is
  5934. switched on?
  5935.  
  5936.      If the answer to the previous is "binary", shouldn't Kermits in general
  5937. make it rather difficult to accidentally switch on 8th-bit-prefixing?  And
  5938. if the answer to that one is "yes", then is it wise for a Kermit server, or
  5939. in fact any mainframe Kermit, to regularly offer 8th-bit-prefixing in its
  5940. I-exchange?  (This is suggested in the protocol manual.)
  5941.  
  5942.      Those of us who live on unix (with its LF as record-terminator) are
  5943. keenly aware of the problems of files which come in with CR instead.
  5944. Unsophisticated users tend to get absoultely floored; and it's they who are
  5945. most likely to get into trouble if the two Kermits they are using do not,
  5946. between them, pick sensible defaults.
  5947.  
  5948.      As an extension, what about the filing-systems which expect to find
  5949. carriage-control-characters either at the start of each line (as per
  5950. Fortran), or even at the end (older IBM formats)?
  5951.  
  5952.                                 Chris Kennington (cjk@ucl-cs)
  5953.  
  5954. [Ed. - 8th-bit prefixing is totally unrelated to text vs binary mode.  The
  5955. prefixing mechanism is just a trick to squeeze 8-bit bytes through a 7-bit
  5956. link.  Most Kermit programs do (and should) enable 8th-bit prefixing
  5957.  
  5958. INFO-KERMIT DIGEST V3 #16                                              Page 109
  5959.  
  5960. automatically if parity is not none (i.e. is even, odd, mark, or space); it
  5961. is a transmission technique akin to TELNET IAC doubling.  All Kermit
  5962. programs I know about run in text mode by default, and 8th bit prefixing is
  5963. off by default except in systems (like IBM mainframes, or Prime computers)
  5964. that always use parity.  In Unix, text mode means LF/CRLF conversion is
  5965. done, and it works Unix-to-anything, anything-to-Unix, so long as the
  5966. "anything" Kermit is also in text mode.  But see the discussion after the
  5967. previous message about the perils of automatic mode selection.  Systems that
  5968. have carriage control or other "structured text" formats bear the
  5969. responsibility for converting them to canonical (CRLF) format before
  5970. transmission; VAX/VMS Kermit (the Stevens Bliss version) does this.]
  5971.  
  5972. ------------------------------
  5973.  
  5974. Date: Fri, 30 Aug 85 10:12 MET
  5975. From: Peter Bendall, DECUS VAX SIG Europe
  5976.   <decus%v750.ira%germany.csnet@csnet-relay.arpa>
  5977. Subject: How to Make Kermit Work over European Packet Switching Networks
  5978. Keywords: European Networks
  5979.  
  5980. Since I started distributing 6800 and 6809 FLEX Kermits I have received MANY
  5981. calls to say that Kermit is not able to work over the European packet
  5982. switching networks.
  5983.  
  5984. The following "work around" does however work for the German DATEX-P system
  5985. and will probably work for other systems also:
  5986.  
  5987. For Kermit-32 on VAX/VMS systems:
  5988.  
  5989. Call the VAX using CONNECT and start Kermit-32, and issue the commands:
  5990.  
  5991. SET RECEIVE START_OF_PACKET 7
  5992. SET SEND START_OF_PACKET 7
  5993.  
  5994. and then start the server if required.  Then escape to your own Kermit and
  5995. issue the equivalent commands:
  5996.  
  5997. SET REC SOP=7
  5998. SET SEN SOP=7
  5999.  
  6000. (or whatever they look like)
  6001.  
  6002. and then it works.
  6003.  
  6004. [Ed. - Apparently DATEX-P does not pass through Control-A's, which are
  6005. used by Kermit as the start-of-packet character.]
  6006.  
  6007. In the case of the VAX systems, we have checked that the control-As are
  6008. still in the packet when they reach our machine but we have found no
  6009. simple way to get them into the packets...  If anyone knows the proper
  6010. workaround please let me know!
  6011.  
  6012. ------------------------------
  6013.  
  6014. Date: Wed 28 Aug 85 11:17:59-PDT
  6015. From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
  6016.  
  6017. Page 110                                              INFO-KERMIT DIGEST V3 #16
  6018.  
  6019. Subject: Kermit on NEC 8001
  6020. Keywords: NEC 8001
  6021.  
  6022. Some time ago there was a complaint that the Generic version of Kermit
  6023. only partially worked on the NEC 8001.  I had reason to need it recently
  6024. and found the following fix which works quite well.
  6025.  
  6026. Generic Kermit uses the iobyte to switch to the BAT console (which takes
  6027. its input from the RDR device) so that it can check the serial port input
  6028. status using the Console Status BIOS call.  The BIOS therefore must check
  6029. the iobyte twice in this situation, once to determine that the BAT console
  6030. is in use, then again to decide which physical device RDR is set to.  The
  6031. NEC 8001 does this for the Console Input routine, but not for Console Status.
  6032. The default Console Status routine always returns No Input Available, so
  6033. that Kermit never tries to receive a character even though it can send them
  6034. just fine.
  6035.  
  6036. The solution is to patch the dispatch table for the Console Status routine
  6037. so that it proceeds to the serial status routine instead of the default.
  6038. It might be hard to determine the address of the status routine if RDR is
  6039. set to the PTR, UR1, or UR2 device, but for the TTY device the address is
  6040. just two entries earlier in the table to be patched.  Fortunately Kermit
  6041. uses the TTY device by default.
  6042.  
  6043. On the NEC 8001, the serial driver is loaded dynamically, and the address
  6044. of the status routine varies depending on which driver is used.  Therefore
  6045. this patch must be made each time the system is cold-booted, after installing
  6046. the serial device driver but before running Kermit.  It's easiest to make
  6047. the patch into a simple program using DDT as follows:
  6048.  
  6049. A>DDT
  6050. DDT VERS 2.2
  6051. -A100
  6052. 0100 LHLD 1        ; get the address of the BIOS jump table
  6053. 0103 INX  H        ; step forward to the Console Status entry
  6054. 0104 INX  H
  6055. 0105 INX  H
  6056. 0106 INX  H
  6057. 0107 MOV  A,M        ; get the address of the Console Status dispatcher
  6058. 0108 INX  H
  6059. 0109 MOV  H,M
  6060. 010A MOV  L,A
  6061. 010B INX  H        ; step past the dispatcher's initial JMP instruction
  6062. 010C INX  H
  6063. 010D INX  H
  6064. 010E MOV  C,M        ; pick up the address for the TTY Status routine
  6065. 010F INX  H
  6066. 0110 MOV  B,M
  6067. 0111 INX  H
  6068. 0112 INX  H        ; step forward to the BAT entry
  6069. 0113 INX  H
  6070. 0114 MOV  M,C        ; save the TTY address in the BAT entry
  6071. 0115 INX  H
  6072. 0116 MOV  M,B
  6073. 0117 RET        ; return to CP/M
  6074. 0118 .
  6075.  
  6076. INFO-KERMIT DIGEST V3 #16                                              Page 111
  6077.  
  6078. -^C            ; Now get out of DDT
  6079. A>SAVE 1 KPATCH.COM    ;  and save the patch as a COM file
  6080.  
  6081. With this patch program available, perform the following sequence of
  6082. actions after cold boot to bring up Kermit:
  6083.  
  6084. A>INSTALL8 IRS232A TTY: [,,,,O]        ; install the driver as device TTY
  6085.                     ; set up for Object files.  The driver
  6086.                     ; name may vary.
  6087. A>KPATCH                ; Patch the BAT status routine
  6088. A>KERMIT                ; Start Kermit
  6089.  
  6090. With the interrupt-driven serial driver in place, this has worked perfectly
  6091. for me at up to 9600 baud.  Good luck.
  6092.  
  6093. -- Ron
  6094.  
  6095. [Ed. - Thanks, Ron!  I've stored this message in the Kermit distribution as
  6096. CP4NEC.HLP.]
  6097.  
  6098. ------------------------------
  6099.  
  6100. Date:  Wed, 4 Sep 85 03:14 EDT
  6101. From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
  6102. Subject:  Concurrent DOS Kermit
  6103. Keywords: Concurrent DOS, MS-DOS Kermit
  6104.  
  6105. PC-DOS Kermit seems to work fine under Concurrent DOS, with a few
  6106. qualifications, as you expect.  First, most of the 'internal' commands
  6107. that require PC-DOS interactions don't work, e.g., LOCAL DIR (wildcard
  6108. SENDs work fine).  This is, of course, less of a problem under
  6109. Concurrent than it would be under PCDOS, since, with Concurrent, you can
  6110. switch processes and do anything of these things (or even keep the
  6111. current directory or whatever in a handy window).  Second, you must use
  6112. SUSPEND=OFF if you expect to do transfers in background.  Third,
  6113. experience with the PC indicates that you may want to arrange a bit more
  6114. waiting time and/or retry count maximum with your mainframe kermit if
  6115. that is possible -- things sometimes get a little slow if there is a lot
  6116. of other stuff going on in the machine, especially if kermit is a
  6117. background, rather than foreground, process.  I would suspect that this
  6118. would be less of a problem on the AT, but haven't tried.
  6119.  
  6120. I keep fussing with a CDOS-specific version of Kermit, based on the
  6121. CP/M86 version when I manage to be around for more than a couple of
  6122. weeks (not frequent in the last year).  It is, of necessity, heavily
  6123. dependent on the operating system, and is quite slow when it works.  But
  6124. this message is coming to you from a Concurrent DOS 4.1 system, using
  6125. PC-DOS kermit, for whatever that is worth.  If someone else would like
  6126. to take that on, I would be happy to transfer everything I have done,
  6127. and try to transfer everything I know/have found out, otherwise I will
  6128. keep fussing as I have time.
  6129.  
  6130. The combination of MSDOS kermit and Concurrent also worked fine under
  6131. version 3.2 of the latter; versions before 3.2 are hopeless, since they
  6132. don't support PCDOS mode.
  6133.  
  6134.  
  6135. Page 112                                              INFO-KERMIT DIGEST V3 #16
  6136.  
  6137. ------------------------------
  6138.  
  6139. Date: Fri 16 Aug 85 11:03:59-EDT
  6140. From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
  6141. Subject: New BITNET KERMSRV Command Syntax
  6142. Keywords: BITnet KERMSRV
  6143.  
  6144.  The syntax of Kermsrv commands has changed slightly so the file
  6145.  AANETW.HLP should be modified.  Here is the command format:
  6146.  
  6147. ?
  6148. HELP
  6149. SEND { DIR | fn ft | ?}
  6150. PUNCH { DIR | fn ft | ?}
  6151.  
  6152. Send returns information in netdata format.  Punch uses punch format.
  6153. If PUNCH is used, files with LRECL 80 or under will be punched Class
  6154. A.  The others will be disk dumped Class N.  The DIR (directory
  6155. command) has been replaced by SEND DIR or PUNCH DIR.  File names may
  6156. contain wildcards.  Requests to Kermsrv can be either in the form of
  6157. messages or reader files, where the file contains a single line with a
  6158. valid Kermsrv command.
  6159.  
  6160. /daphne
  6161.  
  6162. ------------------------------
  6163.  
  6164. From: ihnp4!kddlab!nttmecl!nttmecl!NTT-20!MURAKAMI@seismo.CSS.GOV
  6165. Date: 27 Aug 1985 2023
  6166. Subject: Kermit for Japanese Microcomputers and NTT Lisp Machine
  6167. Keywords: Japanese Micro Kermit, NTT Lisp
  6168.  
  6169.  Kermit for Japanese micro computers is supported.  Kermit for the
  6170. following computers is available:
  6171.  
  6172.    (1) NEC PC8800 on CP/M-80
  6173.    (2) NEC PC9800 on CP/M-86
  6174.    (3) FUJITSU FM-8 on CP/M-80
  6175.    (4) FUJITSU FM-11 on MS-DOS
  6176.    (5) IBM5550 on MS-DOS
  6177.  
  6178. In addition to these computers, Kermit for NTT Lisp Machine ELIS
  6179. was written by its language TAO. TAO is a dialect of Lisp which
  6180. unifies an object-oriented programming paradigm and a logic
  6181. programming paradigm with a procedural programming paradigm.
  6182. NTT Lisp Machine (interpreter) runs 1.3 times faster than SYMBOLICS
  6183. LISP MACHINE (compiler).
  6184.  
  6185. If you are interested in these Kermits, please send me mail to
  6186.  
  6187.            hplabs!kddlab!nttmecl!murakami@Berkeley
  6188.  
  6189. Is it useful for you to get Kermit sources for Japanese computers?
  6190. I hesitate to send these sources because of the following reasons.
  6191.  (1) These Kermits will not be widely used in your country.
  6192.  (2) Kermit on CP/M-80 is based on the old Kermit version.
  6193.  
  6194. INFO-KERMIT DIGEST V3 #16                                              Page 113
  6195.  
  6196.  
  6197. We are translating an important part of the Kermit manuals into Japanese.
  6198. I would appreciate if you'd allow me to distribute these manuals in Japan.
  6199.  
  6200.                     Thank you for your attention
  6201.  
  6202. [Ed. - Does everyone agree that the programs listed above are not of general
  6203. interest outside of Japan?  If not, I'll try to get them into the Kermit
  6204. distribution.]
  6205.  
  6206. ------------------------------
  6207.  
  6208. DATE: 26 Aug 85 1735 WEZ
  6209. FROM: U02F%CBEBDA3T.BITNET@WISCVM.ARPA  (Franklin A. Davis)
  6210. SUBJECT: Kermit for Sharp PC 1500 A?
  6211. Keywords: Sharp PC 1500 A Kermit
  6212.  
  6213. Anyone know of a Kermit for the Sharp PC 1500 A?  A colleague needs it, and
  6214. unfortunately isn't even sure if it uses CP/M, but our guess is that it may
  6215. be a close clone.  Please answer directly.
  6216.  
  6217. Thanks -- Franklin  <U02F@CBEBDA3T.BITNET>
  6218. Institute for Informatics and Applied Mathematics
  6219. University of Bern
  6220. Laenggassstrasse 51
  6221. CH-3012  Bern
  6222. Switzerland
  6223.  
  6224. ------------------------------
  6225.  
  6226. End of Info-Kermit Digest
  6227.  
  6228. Page 114                                              INFO-KERMIT DIGEST V3 #17
  6229.  
  6230. Info-Kermit Digest         Tue, 10 Sep 1985       Volume 3 : Number 17
  6231.  
  6232. Special C-Kermit Edition:
  6233.  
  6234.                         New C-Kermit Bug List
  6235.                C-Kermit on a 3B2 - Secure Line Locking
  6236.                 Kermit/cu Incompatabilities on the 3B2
  6237.                      C-Kermit Speed on TRS-Xenix
  6238.                    C-Kermit Performance with Parity
  6239.                             C-Kermit Ideas
  6240.          C-Kermit Remote Server Commands Fail After an Abort
  6241.        Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
  6242.   Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
  6243.                      Bug in C-Kermit Line Locking
  6244.                    Bug Report For C-Kermit 4C(057)
  6245.                       Problem Installing 4C(057)
  6246.          C-Kermit Take File Control and Background Operation
  6247.                    C-Kermit on UTS vs the IBM 7171?
  6248.                   Exiting "Protocol Mode" Gracefully
  6249.  
  6250. ----------------------------------------------------------------------
  6251.  
  6252. Date: 10 Sep 85 17:00:00 EDT
  6253. From: Frank da Cruz <SY.FDC@CU20B>
  6254. Subject: New C-Kermit Bug List
  6255. Keywords: C-Kermit
  6256.  
  6257. Most of the messages in this issue report bugs and problems with C-Kermit
  6258. 4C(057), the current (since July 31) release for Unix.  The problems are
  6259. not urgent, so a new release has not yet been prepared.  The problems have,
  6260. however, been noted in the "beware" file, KER:CKUKER.BWR, available via
  6261. anonymous FTP from Internet host CU20B.  Some of the messages below are
  6262. over a month old -- apologies; I'm still catching up from the backlog of
  6263. mail after a long vacation.
  6264.  
  6265. ------------------------------
  6266.  
  6267. Date: 16 Aug 85 23:01:39 GMT
  6268. From: Robert Vidua <gatech!gitpyr!robert@Seismo.ARPA>
  6269. Subject: C-Kermit on a 3B2 - Secure Line Locking
  6270. Keywords: C-Kermit, 3B2 Kermit
  6271.  
  6272. I just recently got C-Kermit 4C(055) and brought it up on a 3B2 running
  6273. System V Rel 2.  I'm trying to use it on a line that uucp also uses and
  6274. I'm not sure how to do this without making a potential security problem
  6275. and still giving ordinary users full access to the line.  I don't want
  6276. to modify the code.  That leaves me with a two other solutions: 1) make
  6277. kermit setuid to something (it doesn't handle this correctly (i.e. no
  6278. 'setuid (getruid ())' or equivalent), so this isn't a valid solution)
  6279. and 2) make the tty line as well as /usr/spool/locks readable and writable
  6280. by everyone (nasty if someone decides to get malicious).  I'm not too
  6281. concerned about the 3B2, since I know/trust all the users on it (it's
  6282. a intra-departmental machine), but I'll soon be bringing up the same
  6283. kermit on a couple of 3B20s that's open to the whole campus and I'd like
  6284. to solve the security problem first.
  6285.  
  6286.  
  6287. INFO-KERMIT DIGEST V3 #17                                              Page 115
  6288.  
  6289. About two or three months ago, there was a discussion on this very topic
  6290. in fa.info-kermit which I, silly me, neglected to pay attention to.  Now
  6291. I need the information.  Does anyone have an archive of those messages
  6292. and is willing to send me a copy?
  6293.  
  6294. Robert Viduya
  6295. Georgia Institute of Technology
  6296.  
  6297. UUCP:   {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
  6298.         {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
  6299. BITNET:    CCOPRRV @ GITVM1
  6300.  
  6301. [Ed. - The discussions are in the Info-Kermit Digest V2 #11-12, #38-39, and V3
  6302. #2.  You should be able to pick up the archives over BITNET via KERMSRV at
  6303. host CUVMA -- V2 should be called "MAIL 85A" and V3 should be "MAIL TXT".]
  6304.  
  6305. ------------------------------
  6306.  
  6307. Date: 3 Aug 85 16:00:12 EDT
  6308. From: Eliot Lear <Lear@RUTGERS.ARPA>
  6309. Subject: Kermit/cu Incompatabilities on the 3B2
  6310. Keywords: 3B2 Kermit
  6311.  
  6312. I am running kermit on an At&T 3B2 running System V.2.  I don't know if I am
  6313. repeating what someone said but we have discovered that cu requires a line
  6314. be owned by uucp while Kermit requires that the line be owned by root.
  6315. Since the everyday average user is not allowed to root, this presents
  6316. problems.  I imagine that this has something to do with checking to see if
  6317. the line is active but I don't know.  I figured I'd mention it to you,
  6318. though.
  6319.  
  6320.                     eliot lear
  6321.  
  6322. [Ed. - See previous discussions of line locking.]
  6323.  
  6324. ------------------------------
  6325.  
  6326. Date:  Mon, 26 Aug 85 14:46 MDT
  6327. From:  RMark@DENVER.ARPA
  6328. Subject:  C-Kermit Speed on TRS-Xenix
  6329. Keywords: C-kermit, TRS-Xenix Kermit
  6330.  
  6331. After compiling the latest ckermit on TRS-80 Model 16b (v. 7 Xenix), I
  6332. timed a transfer from VAX/VMS:  16 chars/sec.  I then removed the
  6333. -DDEBUG and recompiled.  Now over 200 chars/sec at 4800 baud.
  6334.  
  6335. [Ed. - As predicted in V2 #35, building the program without the debugging
  6336. feature can result in a perceptible speed improvement -- but 1250% is more
  6337. than just perceptible!  I wonder if the difference is as great on other
  6338. systems.  In light of this report, it might make sense for every site to
  6339. build the program both ways -- use the non-debugging version for production
  6340. and the debugging version for tracking down & reporting problems.]
  6341.  
  6342. ------------------------------
  6343.  
  6344. Date: 28-AUG-1985 12:17:47
  6345.  
  6346. Page 116                                              INFO-KERMIT DIGEST V3 #17
  6347.  
  6348. From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  6349. Subject: C-Kermit Performance with Parity
  6350. Keywords: C-Kermit, Parity
  6351.  
  6352.     Here's a relayed note on C-KERMIT from Tim Green, Computer Unit,
  6353. Warwick University UK. If you want to reply send it to me and I'll forward it.
  6354.  
  6355.           Alan Phillips
  6356.             Lancaster University
  6357.  
  6358. Forwarded message:
  6359.  
  6360. I've just put up C-Kermit 4C(057) and have some comments to make regarding
  6361. its performance. The performance of C-Kermit on a VAX is fine when you use
  6362. it with no parity.  Typically I can get 480ch/s on a 9600 baud line.
  6363. However due to the local net we have here we can't use it with no parity for
  6364. binary files.  As soon as you start to use parity the performance is greatly
  6365. degraded.  This is due to the way C-Kermit tries to detect whether parity is
  6366. correct.  If you do a profile of it while it is running you find that it is
  6367. spending most of its time setting and unsetting a timer.  There are two
  6368. posible solutions to this.  One: Do not test the parity, just assume that it
  6369. is correct (leaving error detection to the checksum).  Two: provide an
  6370. option to set 7bit data when using no parity.  We are using a VAX 780 with
  6371. 4.2 Unix.
  6372.  
  6373. [Ed. - You're right about the poor performance when parity is "on".  It's
  6374. because the program is doing single-character reads rather than reading an
  6375. entire "line" (up to a carriage return).  It does this because the
  6376. terminating CR might have its parity bit on and therefore won't be
  6377. recognized as a CR.  A more clever scheme will used in a future release to
  6378. speed things up.  By the way, parity is not used by Kermit for error
  6379. checking; rather, Kermit (unlike some other protocols) "tolerates" parity
  6380. that is imposed upon it by the communication medium or one of the hosts
  6381. involved.]
  6382.  
  6383. ------------------------------
  6384.  
  6385. Date: Sat, 3 Aug 85 00:18:04 pdt
  6386. From: "Scott Weikart; Community Data Processing; 415-322-9069"
  6387.  <cdp!scott@Glacier>
  6388. Subject:  C-Kermit Ideas
  6389. Keywords: C-Kermit
  6390.  
  6391. Here's are some comments on items in the recent ckuker.bwr file.
  6392.  
  6393. > - When connecting back to C-Kermit after a transaction, or after finishing
  6394. >   the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
  6395. >   There's not much the Kermit program can do about this...
  6396.  
  6397. If XON/XOFF is enabled, why couldn't Kermit send an extra ^Q before exitting?
  6398.  
  6399. [Ed. - The problem is in the other direction.  The local PC needs to send a
  6400. ^Q to the remote end.  But you don't want the PC to do this automatically,
  6401. because it might mess things up -- e.g. suppose the remote Kermit was invoked
  6402. from within EMACS, which uses ^Q as a command, and has popped to EMACS upon
  6403. exit...]
  6404.  
  6405. INFO-KERMIT DIGEST V3 #17                                              Page 117
  6406.  
  6407.  
  6408. > - ckufio currently goes to a lot of trouble to traverse the directory in
  6409. >   order to expand "*" and "?" in wildcards.  Maybe it should just fork the
  6410. >   user's customary shell and have it do the expansion.  This would allow
  6411. >   fancier filespecs to be given, like "~/ck*.[cwh]".  But it would slow down
  6412. >   features like filename completion and menus in the interactive command
  6413. >   parser.  (Find out how Unix FTP does it...)
  6414.  
  6415. How about forking a shell that's kept around, and communicating
  6416. with it through pipes.  This way you would only incur the fork and exec
  6417. overhead the first time a file name is specified.  Various EMACS's use this
  6418. technique.  In fact, it seems like this could also be used for the
  6419. "!" command.
  6420.  
  6421. [Ed. - Right, that's the idea.  Any volunteers to submit some code for this
  6422. that fits in the current framework and works for all versions of Unix?
  6423. Would this technique work on small systems, e.g. small-memory PDP-11's?]
  6424.  
  6425. ------------------------------
  6426.  
  6427. Date: Tue, 6 Aug 85 10:46:07 PDT
  6428. From: rag@uw-june.arpa (David Ragozin)
  6429. Subject: C-Kermit Remote Server Commands Fail After an Abort
  6430. Keywords: C-Kermit
  6431.  
  6432. Running C-Kermit, 4C(057) under 4.2BSD connected to MS-DOS 2.27 Kermit.
  6433. With the C-Kermit side in server mode it responds properly to remote and
  6434. remote host commands from the MS-DOS side.  However, if I interrupt a remote
  6435. command by typing a Control-C on the MS-DOS side, all further remote or
  6436. remote host commands fail, except for "remote help". For instance, "remote
  6437. dir" elicits the message "Can't list directory", "remote space" gives back
  6438. "can't check space", "remote host...." leads to "can't do system command".
  6439. Apparantly something on the C-kermit side has been left in a strange state
  6440. by the abort.
  6441.  
  6442. [Ed. - If you read the MS-DOS Kermit chapter of the Kermit User Guide,
  6443. you'll see the explanation.  ^C typed to MS-DOS Kermit during a file
  6444. transfer returns to MS-DOS Kermit command level "immediately without sending
  6445. any kind of notification to the remote system"; it's for use when, for
  6446. instance, you give a "send" command but then realize you forgot to start up
  6447. a Kermit on the other end.  This means that the remote Kermit blithely
  6448. continues with what it was doing, in this case sending data packets.  If you
  6449. waited for a couple minutes (after the other side timed out the maximum
  6450. number of times) the situation would have cleared up by itself.  If you have
  6451. a real transaction in progress that you want to interrupt, then you should
  6452. use ^X or ^Z, which most any Kermit server will honor.  MS-DOS Kermit also
  6453. provides a ^E interrupt, which sends an error packet to the remote side,
  6454. which is guaranteed to stop any transaction (assuming it arrives).]
  6455.  
  6456. ------------------------------
  6457.  
  6458. Date: Mon, 12 Aug 85 23:30:16 BST
  6459. From: Ljwu@ucl-cs.arpa
  6460. Subject: Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
  6461. Keywords: C-Kermit
  6462.  
  6463.  
  6464. Page 118                                              INFO-KERMIT DIGEST V3 #17
  6465.  
  6466. I had a friend of mine in the US snork a copy of C-Kermit and post it to me
  6467. on floppy disks.  He must have grabbed 4C(056) just before 4C(057) was
  6468. released and re-released (see Info-Kermit Digest v3 #10/12).  Unfortunately,
  6469. the ckctio file seems to lack rtime and gtime routines.  I managed to patch
  6470. together a working ckctio by including the appropriate lines of code from
  6471. ckvtio.c.  I hope that this oversight has been remedied in 4C(057).
  6472. Script Command, V2.0(006) 14 Jun 85
  6473.  
  6474. [Ed. - It has.]
  6475.  
  6476. As a footnote, the problem reported earler with wart on a Whitechapel
  6477. (Info-Kermit Digest v2 #38) seems to have disappeared.
  6478.  
  6479.                  Les J. Wu - ljwu@ucl-cs.arpa
  6480.  
  6481. ------------------------------
  6482.  
  6483. Date: Tue, 13 Aug 85 17:37:10 PDT
  6484. From: rag@uw-june.arpa (David Ragozin)
  6485. Subject: Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
  6486. Keywords: C-Kermit
  6487.  
  6488. Setting: C-Kermit 4C(057) BSD version on VAX-11/7xx's under BSD4.2.
  6489. Problem: When receiving multiple files a Ctrl-F discards the current file, and
  6490.    all subsequent files in the same batch. (The transfer of each subsequent
  6491.    file is started, and then aborted with a discarded message.)
  6492.  
  6493. (I seem to remember a report of a problem of this sort a long time ago, but
  6494. find no mention in the .bwr file.  I have also reproduced the same behavior
  6495. between 4C(056) versions.)
  6496.  
  6497. [Ed. - Sure enough, it's a bug.  Will note this in the .bwr file and fix in
  6498. the next release.]
  6499.  
  6500. ------------------------------
  6501.  
  6502. Date: 20-AUG-1985 10:29:51
  6503. From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  6504. Subject: Bug in C-Kermit Line Locking
  6505. Keywords: C-Kermit
  6506.  
  6507. Forwarded message from Dave Osborne, Cripps Computing Centre, Nottingham U, UK
  6508.  
  6509. There is a bug in the the Version 7 unix version of the program. The
  6510. ckutio.c module, when opening the line (such as /dev/tty), in its
  6511. "ttopen" routine, does an 'ioctl' call with parameter TIOCEXCL, to hold the
  6512. line for exclusive use.  Unfortunately, it doesn't bother to
  6513. unset this condition before closing the line.
  6514.  
  6515. [Ed. - This is fixed in the current release.]
  6516.  
  6517. ------------------------------
  6518.  
  6519. Date: 28-AUG-1985 09:58:17
  6520. From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  6521. Subject: Bug Report For C-Kermit 4C(057)
  6522.  
  6523. INFO-KERMIT DIGEST V3 #17                                              Page 119
  6524.  
  6525. Keywords: C-Kermit
  6526.  
  6527.    I've had a bug report passed to me from Icarus Sparry, Electrical
  6528. Engineering Department, Bath University UK.
  6529.  
  6530. Bug in C-Kermit 4C(057) and previous releases:
  6531.  
  6532. File CKCFN2.C, routine SPACK
  6533.  
  6534. If padding is in operation then it is inserted at the start of the packet
  6535. before the ^A, as well as at the end of the packet before the EOL. However the
  6536. values at the start of the packet are counted for the checksum, (except for the
  6537. first) and the ^A is also included in the checksum.
  6538.  
  6539. The workaround is to remember where the ^A is or to start the checksum after
  6540. npad+1 characters.
  6541.  
  6542. [Ed. - Oops!  You're absolutely right.  This will be noted in the .bwr file,
  6543. and will be fixed in the next release.  By the way, padding should only be
  6544. sent before the packet, not after the end before the terminator -- I have no
  6545. idea how that line of code got in there...]
  6546.  
  6547. ------------------------------
  6548.  
  6549. Date: Wed, 4 Sep 85 16:42:51 cdt
  6550. From: Dave Rasmussen <uwmacc!uwmcsd1!dave@wisc-rsch.arpa>
  6551. Subject: Problem Installing 4C(057)
  6552. Keywords: C-Kermit
  6553.  
  6554. I have the version that supposedly corrects the 68000 architectural bugs
  6555. mentioned by Frank da Cruz on Usenet, the one marked as: C-Kermit, 4C(057)
  6556. 31 Jul 85, 4.2 BSD
  6557.  
  6558. When I tell it to "set line /dev/t1570" where t1570 is owned by uucp and mode
  6559. 666, kermit just hangs there.  The problem is on a 68000 based Integrated
  6560. Solutions box running 4.2bsd.  I tried running as the superuser in case there
  6561. were any file conflicts, but this doesn't change things.
  6562.  
  6563. I do have this version running on a Vax 750 with 4.1bsd and it talks to remote
  6564. lines with no problems or other modifications.
  6565.  
  6566. Any suggestions, or anyone else had these problems? It may well be our
  6567. environment, but I think I've looked it over thoroughly.
  6568.  
  6569. Dave Rasmussen, CSD University of WI - Milwaukee
  6570.  
  6571. [Ed. - Can anyone with a similar system offer any advicde?]
  6572.  
  6573. ------------------------------
  6574.  
  6575. Date: Tue, 3 Sep 85 18:22:15 pdt
  6576. From: tweten@AMES-NAS.ARPA (Dave Tweten)
  6577. Subject: C-Kermit Take File Control and Background Operation
  6578. Keywords: C-Kermit
  6579.  
  6580. When I read the contents of the current ckuker.bwr file, with particular
  6581.  
  6582. Page 120                                              INFO-KERMIT DIGEST V3 #17
  6583.  
  6584. attention to the two items I have previously commented on, I noticed
  6585. someone had added editorial comment to each item indicating that this
  6586. message is necessary.  Though my original message, which included code,
  6587. also covered my reasons for the suggestions, I'll repeat the reasons
  6588. here.
  6589.  
  6590.      Some users report that it would be more desirable to have an error
  6591.      during execution of a take file return directly to command level,
  6592.      rather than pop to the invoking take file (why?).
  6593.  
  6594. Kermit has no flow-of-control commands to be used in TAKE files.  It is
  6595. therefore impossible to write a TAKE file which does something
  6596. intelligent if a file IT TAKEs should die.  The result of that fact, and
  6597. of the way the unmodified Kermit works, is that multiply nested command
  6598. files with an error at the bottom level die a slow and painful death,
  6599. wasting the user's time until they work their way back up to the top
  6600. level.  In background, this is particularly wasteful, since there is
  6601. noone to hit ^C to end the nonsense.
  6602.  
  6603. My proposal, which I have implemented at our site, is simply a matter of
  6604. euthenasia for terminal TAKE files.  Where the Columbia-issue command
  6605. processor closes the current TAKE file and pops one level, I have put in
  6606. a while statement which makes it keep closing and popping until interactive
  6607. command level is reached.
  6608.  
  6609. [Ed. - Actually, what is needed is a "set" command to control whether this
  6610. is done, with which users can "declare" some errors fatal and others not.
  6611. The DEC-20 Kermit script facility has something like this.]
  6612.  
  6613.      Some users report that the program should make no internal
  6614.      distinction between running in foreground or background (why?).
  6615.  
  6616. Release C-Kermit attempts to determine if it is in background by
  6617. checking if its parent has set SIGINT to SIG_IGN.  That is not a
  6618. completely reliable indicator of being in background, and furthermore,
  6619. why would it want to know if it is in background?
  6620.  
  6621. [Ed. - So it would know whether or not to issue messages to the user's
  6622. screen.  If in background, attempting to print a message to the screen
  6623. freezes the the process.]
  6624.  
  6625. The release version changes its behavior in a couple of ways as a
  6626. function of whether it thinks it is in background.  It sets several
  6627. signals to be ignored (which are ignored by default for background
  6628. anyway), and it decides to abort immediately on any command failure from
  6629. standard input (which prevents graceful termination of a remote server).
  6630. Incidently, this is the only way release C-Kermit generates a return
  6631. value of BAD_EXIT.
  6632.  
  6633. Because C-Kermit's changed behavior in background made it difficult to
  6634. debug scripts intended to run in background, I changed ours so it
  6635. doesn't try to be different in background.
  6636.  
  6637. Ours ALWAYS returns a status value on exit.  The status value is always
  6638. GOOD_EXIT if no commands have failed, and BAD_EXIT, otherwise.  That
  6639. makes it easy to debug a shell script which uses a while loop to retry
  6640.  
  6641. INFO-KERMIT DIGEST V3 #17                                              Page 121
  6642.  
  6643. Kermit a number of times.  When a command from standard input fails, our
  6644. C-Kermit sets the eventual returned status value to BAD_EXIT and keeps
  6645. going, so later commands can gracefully shut down a remote server, if
  6646. any.
  6647.  
  6648. Over all, I believe our two changes have made C-Kermit much more
  6649. civilized, particularly when run from a script.  If Columbia would like
  6650. diffs for our changes, I would be happy to send a more recent set.
  6651.  
  6652. [Ed. - Dave has sent the diffs; does anyone else have any opinions on these
  6653. issues?  Meanwhile, I'll add a little more in the way of rationale to the
  6654. comments in the .bwr file.]
  6655.  
  6656. ------------------------------
  6657.  
  6658. From: ihnp4!inmet!ada-uts!mule@seismo.CSS.GOV
  6659. Date: 9 Aug 85 17:08:39 CDT (Fri)
  6660. Subject: C-Kermit on UTS vs the IBM 7171?
  6661. Keywords: C-Kermit, UTS Kermit, 7171 Protocol Converters
  6662.  
  6663. I am under the impression that the CMS version of Kermit knows how to talk
  6664. through the IBM 7171 protocol converter.  The 7171 allows ascii devices
  6665. (terminals or pc's running terminal emulation programs) to look to the IBM
  6666. host like an IBM 3270 type terminal.
  6667.  
  6668. We (at Intermetrics Inc 733 Concord Ave Cambridge Mass 02138) are running
  6669. UTS on a 3083 IBM host with a 7171 attached.  We would love to run a Kermit
  6670. that knew about the 7171 and was able to send files back and forth through
  6671. it.  So:
  6672.  
  6673.     * Is it true that the CMS kermit knows how to do this ?
  6674.  
  6675. [Ed. - Yes.]
  6676.  
  6677.     * If so, how hard would it be to add this capability to UTS Kermit ?
  6678.  
  6679. [Ed. - I believe Philip Murton at the University of Toronto
  6680. (MURTON@UTORONTO.BITNET) has done this, or knows someone who did.  The
  6681. UTS code uses a different technique (escape sequences) than CMS Kermit
  6682. (CCW programming).]
  6683.  
  6684.     * Are there any plans to do so?
  6685.  
  6686. [Ed. - Philip, do you have this code for the current, or a recent, release
  6687. of C-Kermit?]
  6688.  
  6689.     * Would you like us to take a shot at it (and where do we go for
  6690.       help when we need it) ?
  6691.  
  6692. [Ed. - Let's see if/how Philip responds.  If we don't hear from him, we'll
  6693. try to dig up the code he sent us long ago for the old Unix Kermit.]
  6694.  
  6695. Thanks,
  6696.  
  6697.         Fred Mueller   (617) 661-1840
  6698.  
  6699.  
  6700. Page 122                                              INFO-KERMIT DIGEST V3 #17
  6701.  
  6702. PS Thanks in general for devoting so much energy on such a worthwhile
  6703.    cause.  I hope you get lots of kudos for it.
  6704.  
  6705. ------------------------------
  6706.  
  6707. Date: Sat, 7 Sep 85 02:49:35 edt
  6708. From: ukma!sean@anl-mcs (Sean Casey)
  6709. Subject: Exiting "Protocol Mode" Gracefully
  6710. Keywords: C-Kermit
  6711.  
  6712. I think that C-kermit should have some provision for completely aborting
  6713. the protocol from the terminal.  When one is trying to figure out which
  6714. parity, flow control, handshaking, etc. settings to use with new computer,
  6715. a considerable amount of time may be spent waiting for the local kermit to
  6716. give up on the transfer.  CTRL/F and CTRL/B are provided to abort a
  6717. transfer in progress, but there is no way to abort the protocol without
  6718. also exiting kermit (and losing dtr on the line). I'd like to see another
  6719. control sequence, perhaps CTRL/X, that would cause the local kermit to
  6720. immediately exit the protocol and give the command prompt.  Then, when one
  6721. is debugging a kermit conversation, the protocol could be easily aborted
  6722. as soon as the debugger sees that the two kermits aren't talking
  6723. correctly.
  6724.  
  6725. -  Sean Casey                        UUCP:   sean@ukma.UUCP   or
  6726. -  Department of Mathematics                 {cbosgd,anlams,hasmed}!ukma!sean
  6727. -  University of Kentucky            ARPA:   ukma!sean@ANL-MCS.ARPA
  6728.  
  6729. [Ed. - I agree, this has been noted in the .bwr file for some time.  MS-DOS
  6730. Kermit has a couple options for this which are missing from C-Kermit.  They
  6731. should be added in future releases.]
  6732.  
  6733. ------------------------------
  6734.  
  6735. End of Info-Kermit Digest
  6736.  
  6737. INFO-KERMIT DIGEST V3 #18                                              Page 123
  6738.  
  6739. Info-Kermit Digest         Thu, 12 Sep 1985       Volume 3 : Number 18
  6740.  
  6741. Today's Topics:
  6742.  
  6743.         Announcing LM-KERMIT for Lispmachine Lisp Environments
  6744.                      Kermit Diskette Distribution
  6745.            HP110 Kermit Binaries & MSIBMP.BOO Name Problem
  6746.        NEC PC8800 (not 8001), APC III, & other Japanese Kermits
  6747.                        Kermit and the Far East
  6748.           Kermit and the European Packet Switching Services
  6749.                  Kermit on X.25 and Similar Networks
  6750.                          Kermit over Networks
  6751.                         CMS Kermit with 7171's
  6752.            Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
  6753.                  Kermit for Exxon Office Systems 500?
  6754.                   Kermit for Cromix and the NCR DMV?
  6755.                   MS-DOS Kermit for the Gavilan PC?
  6756.  
  6757. ----------------------------------------------------------------------
  6758.  
  6759. Date: Wed, 11 Sep 85 19:04:27 EDT
  6760. From: George J. Carrette <GJC@MIT-MC.ARPA>
  6761. Subject: Announcing LM-KERMIT for Lispmachine Lisp Environments
  6762. Keywords: LM-Kermit, Lisp
  6763.  
  6764.                               LM-KERMIT
  6765.                KERMIT and terminal emulation capability
  6766.                    for ZetaLisp based lispmachines.
  6767.  
  6768. LM-KERMIT was implemented by Mark David of LMI (Lisp Machines Inc).  The
  6769. use of KERMIT on a lispmachine can fill the gap between sophisticated (and
  6770. expensive) networking hardware and software available on lispmachines and
  6771. the other extreme, NO NETWORKING.  What we found is that many mainframe/
  6772. minicomputer installations take a long time to purchase and install
  6773. something like ethernet TCP-IP, but that KERMIT shows up almost everwhere,
  6774. already installed or in some users directory.
  6775.  
  6776. There are presently available two versions:
  6777.  
  6778. * bundled with the LMI-LAMBDA. It supports terminal emulation, KERMIT,
  6779.   and serial connections via RS-232, TCP-IP (TELNET), etc. Also
  6780.   provided is a HOST/MAINFRAME emulation capability so that PC's
  6781.   can log into the machine and use SERVER mode.
  6782.  
  6783. * A port to the Symbolics 36xx machines done by Mark Ahlstrom of Honeywell.
  6784.   It supports terminal emulation, KERMIT, and serial connections via
  6785.   RS-232.
  6786.  
  6787. The source is conditionalized in the usual manner, #+LMI, #+SYMBOLICS.
  6788. There are a few #+TI conditionalizations although they have not been
  6789. tested. A user of the TI (Texas Instruments) Explorer should be able to
  6790. bring LM-KERMIT up by changing most of the #+LMI conditionalizations to
  6791. #+(OR LMI TI).
  6792.  
  6793. A word about the programming style used.  Don't expect anything exemplary.
  6794. Parts of the code are a quick hack off of KERMIT.C, and much of the window
  6795.  
  6796. Page 124                                              INFO-KERMIT DIGEST V3 #18
  6797.  
  6798. system code is a mix of "doing while learning" combined with later added
  6799. sophistication and hair. Compiling the source gives style warnings of
  6800. various severities on both the LMI and Symbolics machines. However, the
  6801. number of phone calls I've been getting on this has forced us to either
  6802. tell people to go away or provide what we have now. The port that Ahlstrom
  6803. did to Symbolics Release 6.0 was also of the "conditionalize into the
  6804. source the equivalent Symbolics function name or feature" rather than the
  6805. other more slow route of "rewrite things to use mainline Common-Lisp
  6806. functions."
  6807.  
  6808. However, now that it is out people will no doubt be improving things.
  6809.  
  6810. -gjc
  6811.  
  6812. [Ed. - The files are in KER:LM*.*, available via anonymous FTP from CU20B.]
  6813.  
  6814. ------------------------------
  6815.  
  6816. Date: Thu 12 Sep 85 12:43:33-EDT
  6817. From: Frank da Cruz <SY.FDC@CU20B>
  6818. Subject: Kermit Diskette Distribution
  6819. Keywords: Kermit Diskettes
  6820.  
  6821. As anyone who has received a Kermit tape knows, bootstrapping the
  6822. microcomputer versions from the tape is a tricky, frustrating business.
  6823. It's even trickier if you don't have a computer with a tape drive.  To ease
  6824. the pain, we are preparing to make it easier for people to get Kermit
  6825. programs on diskette; we expect to be able to distribute IBM PC and Apple
  6826. Macintosh diskettes ourselves, and we'd like to compile a list of other
  6827. sources for diskettes or other "native media".
  6828.  
  6829. If you know of a user group or other organization that distributes Kermit
  6830. on native media for a particular system (e.g. a Heath-89 user group, a
  6831. TRS-80 user group, etc), please send me the information that would be
  6832. needed to order Kermit from that organization -- Address, pricing, order
  6833. number, etc, plus phone number (so I can verify the information and their
  6834. willingness to act as distributor).  Also, if you belong to a user group
  6835. that could be distributing Kermit but isn't, maybe you could submit it.
  6836. Individuals are also welcome to volunteer to distribute diskettes -- as
  6837. some already have been doing for the Apple II and Commodore 64 -- but when
  6838. addresses and ordering information are published, the demand might exceed
  6839. the ability of a single individual to meet it.
  6840.  
  6841. Of course, any person or group that distributes Kermit should not be doing
  6842. it for profit; the cost should be designed only to recover expenses for
  6843. media, postage, packaging, etc, plus a little margin to allow for expansion
  6844. when demand outstrips capacity.
  6845.  
  6846. P.S. If you can't reply by netmail, send it to me at
  6847.  
  6848.     Columbia University
  6849.     Center for Computing Activities
  6850.     612 W. 115th Street
  6851.     New York, NY  10025
  6852.  
  6853. ------------------------------
  6854.  
  6855. INFO-KERMIT DIGEST V3 #18                                              Page 125
  6856.  
  6857.  
  6858. Date: Wed 31 Jul 85 19:25:38-PDT
  6859. From: Jim Lewinson <a.Jiml@SU-GSB-WHY.ARPA>
  6860. Subject: HP110 Kermit Binaries & MSIBMP.BOO Name Problem
  6861. Keywords: HP110 Kermit
  6862.  
  6863. According to the documentation, KER:MSIBMP.BOO is supposed to be
  6864. MSIBMPC.BOO.  I suppose it got truncated to make it 6 characters, but
  6865. AAFILES.HLP should be updated.
  6866.  
  6867. [Ed. - Thanks for pointing this out, will change AAFILES.HLP.]
  6868.  
  6869. Also, you find an (old) .EXE file for the HP-110 MS-DOS kermit on
  6870. [SU-GSB-WHY] WHY:<KERMIT>MSHP110.EXE.  It is based on an old version of the
  6871. source code, and I'm not sure how well tested it is, but maybe it will help
  6872. someone more than nothing.  Maybe when I get back to the west coast I can
  6873. get someone working on rebuilding it with the latest sources.
  6874.  
  6875.                     Jim
  6876.  
  6877. [Ed. - Thanks.  The 8-bit binary .EXE file is now available as
  6878. KB:MSHP11.EXE, and a hex encoding (straight two-hex-digits per 8-bit byte)
  6879. is in KER:MSHP11.HEX.  There is also source and documentation which may or
  6880. may not correspond to the binaries in KER:MSXHPX.*.]
  6881.  
  6882. ------------------------------
  6883.  
  6884. Date: Fri 6 Sep 85 22:33:03-PDT
  6885. From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
  6886. Subject: NEC PC8800 (not 8001), APC III, & other Japanese Kermits
  6887. Keywords: Japanese Micro Kermits, NEX PC8800 Kermit, APC III Kermit
  6888.  
  6889. The NEC 8001 Generic Kermit-80 patch had a slight error, not in the patch,
  6890. but that the machine is in fact the NEC PC8800.  I got confused by the
  6891. multiplicity of models I deal with.  (I don't believe there is an 8001.)
  6892.  
  6893. As for the offer of source for Japanese computer Kermits, the NEC PC8800
  6894. has been extensively sold in this country so that source may be useful.
  6895. The PC9800 is sold here (with differences) as the APC III, which supports
  6896. only MS-DOS, making a CP/M-86 Kermit of no use.  I don't know about the
  6897. other models mentioned.
  6898.  
  6899. I received an MS-Kermit system module for the APC III (MSXAPC3.ASM) from
  6900. someone at Virginia Tech (VPI&SU).  I haven't seen it included in your
  6901. lists, so I wonder if you ever got a copy.  It seems to work acceptably
  6902. with version 2.28.  I can make it available if you wish.
  6903.  
  6904. -- Ron
  6905.  
  6906. ------------------------------
  6907.  
  6908. Date: Sat, 07 Sep 85 16:50:22 cet
  6909. From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
  6910. Subject: Kermit and the Far East
  6911. Keywords: Japanese Micro Kermits
  6912.  
  6913.  
  6914. Page 126                                              INFO-KERMIT DIGEST V3 #18
  6915.  
  6916. There are some Fujitsus and NECs over here in Germany.  I would appreciate if
  6917. you could put at least the MS-DOS version on CUVMA.
  6918.  
  6919. I have requested Mr. Murakami to send it direct, but I don't know, really if it
  6920. will work. (usenet-BITNET)
  6921.  
  6922. Eberhard W. Lisse
  6923.  
  6924. [Ed. - I tried too, but got mailer replies back with messages like "Too
  6925. many hops"...]
  6926.  
  6927. ------------------------------
  6928.  
  6929. Date: Sat, 07 Sep 85 16:21:39 cet
  6930. From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
  6931. Subject: Kermit and the European Packet Switching Services
  6932. Keywords: European Networks
  6933.  
  6934. I have no problems at all with the European packet switching service.
  6935. I have had no trouble on the Datex-P after setting both Kermits to
  6936.  
  6937.          SET PARITY EVEN
  6938.  
  6939. I have used the following hardware:
  6940.  
  6941.     IBM-PC     DOS 2.11 KERMIT 2.28
  6942.     OSBORNE 1  CP/M 80  KERMIT 4.05
  6943.     RAINBOW    DOS 2.?? KERMIT 2.26
  6944.     VAX 11/780 VMS 3.7
  6945.                    4.1  KERMIT 3.0.055
  6946.                                3.0.066.
  6947.     CYBER 175   NOS     KERMIT ???
  6948.  
  6949.     IBM         VM/CMS  KERMIT 2.??
  6950.  
  6951. ( If I dial my BITnet host [the IBM] through Datex-P I have to set
  6952.   my local parity to even. I don't set anything on the IBM.
  6953.  
  6954.   If I do it from any machine through at the Technical University
  6955.   or from the University Hospital I have to set the local parity to
  6956.   MARK.
  6957.  
  6958.   This indicates that Datex-P forces the parity to EVEN.
  6959.  
  6960.   I can't get our PDP-11/44 RMS-X11M with the new KERMIT to file
  6961.   transfer.  CONNECT works, but now way of getting one single packet
  6962.   over to the IBM or back.  Doesn't bother me though, as I'm doing
  6963.   the file transfer with the VAX anyway due to a faster line.)
  6964.  
  6965. [Ed. - I believe newer versions of PDP-11 Kermit handle IBM communications
  6966. a little better.]
  6967.  
  6968. Same thing works for Telenet I am told by LBAFRIN@CLEMSON.CSNET who
  6969. had a mail the other day.
  6970.  
  6971. Eberhard W. Lisse <zdv626%djukfa11.bitnet@wiscvm.arpa>
  6972.  
  6973. INFO-KERMIT DIGEST V3 #18                                              Page 127
  6974.  
  6975.  
  6976. ------------------------------
  6977.  
  6978. Date: Wed, 11 Sep 85 11:15:18 BST
  6979. From: "Chris.K.Now-and-Then" <cjk@ucl-cs.arpa>
  6980. Subject: Kermit on X.25 and Similar Networks
  6981. Keywords: European Networks
  6982.  
  6983.      Peter Bendall's suggestion (infodig 16) of substituting BEL (07) for
  6984. SOH (01) as Kermit start-of-packet is an interesting kludge, but not quite
  6985. the canonical way of dealing with the problem (of how to work Kermit across
  6986. text-line-oriented networks).  Admittedly almost any (terminal) network will
  6987. pass BEL, for obvious reasons; but bridges, PADs etc. often feel free to
  6988. add BELs if they see fit.  What about a PAD which stuck a BEL into any
  6989. "overlength" line?
  6990.  
  6991.      I regularly Kermit large files over UK JANET, which uses XXX (X.3,
  6992. X.28, X.29) above X.25.  In normal terminal (line) mode, SOH will be
  6993. stripped.  The easy answer is to switch to character (transparent) mode, in
  6994. which case all control characters are passed through "as sent".  For XXX
  6995. this is in fact overkill, since there are parameters to specify which
  6996. control chars are to be passed; but it is straighforward and always
  6997. supported on the user interfaces; it also switches off local echo, which is
  6998. desirable.  In principle character-mode could result in Kermit packets being
  6999. sent as several blocks each; this does not in fact happen when using a
  7000. standard JANET PAD, due to the forward-on-timeout strategy employed.
  7001.  
  7002.      I believe that every terminal network protocol includes a transparent
  7003. mode, so the solution is generally applicable.
  7004.  
  7005.                                         Chris Kennington.
  7006.  
  7007. ------------------------------
  7008.  
  7009. Date: Sat, 7 Sep 85 13:52:05 edt
  7010. From: Mike Ciaraldi <ciaraldi@rochester.ARPA>
  7011. Subject: Kermit over Networks
  7012. Keywords: MILNEY, TELENET
  7013.  
  7014. Two messages in Info-Kermit digest volume 3, number 14 asked about file
  7015. transfers over Milnet and Telenet.  I haven't used either of these, but the
  7016. symptoms sound like a problem I have run into before.
  7017.  
  7018. Sometimes you are able to log on, start up Kermit on the remote machine, and
  7019. give it commands like "DIR" with no trouble.  But when you try to do a file
  7020. transfer your local machine just sits there until it times out, as if no
  7021. packets are being received either way.
  7022.  
  7023. When this has happened to me, I can usually get it to work by EXPLICITLY
  7024. setting the parity of both Kermits, local and remote.  Naturally, if your
  7025. communications channel (e.g. Telenet) enforces a particular parity (e.g.
  7026. even), you have to set the Kermits to match each other and the comm channel.
  7027.  
  7028. Parity being slightly off doesn't seem to affect commands like DIR, but file
  7029. transfers and other things that use packets cannot handle it because the
  7030. checksums, 8th-bit prefixing, and so on are thrown off.  Thus no packets get
  7031.  
  7032. Page 128                                              INFO-KERMIT DIGEST V3 #18
  7033.  
  7034. through.
  7035.  
  7036. Mike Ciaraldi
  7037. ciaraldi@rochester
  7038. seismo!rochester!ciaraldi
  7039.  
  7040. ------------------------------
  7041.  
  7042. Date: Tue, 10 Sep 85 09:03:52 EDT
  7043. From: ostrove@umd5 (Steve Ostrove)
  7044. Subject: CMS-KERMIT with 7171's
  7045. Keywords: VM/CMS Kermit, 7171 Protocol Converters
  7046.  
  7047. We are in the process of testing out our 7171's with CMS.  Although I haven't
  7048. done extensive testing, yesterday I transfered a 65K file using KERMIT-MS
  7049. on one side and KERMIT-CMS on the other (versions 2.28 and 2.01 respectively).
  7050. The transfer was using a packet size of 94 (default).  I had no problems.
  7051. It would seem therefore that the problem with packet size and TSO, may be
  7052. a problem unique to TSO and the 7171's.  I will attempt to do more extensive
  7053. testing of them soon.
  7054.  
  7055. On a different note.  When we put KERMIT-CMS into server mode, it does not
  7056. seem to respond to any terminating command with the exception of FINISH.
  7057. Neither LOG or BYE works.  Is this normal??
  7058.  
  7059. Sincerely,
  7060. Steve Ostrove
  7061. User Services Staff
  7062. The University of Maryland Computer Science Center
  7063. Ostrove@umd5.ARPA
  7064.  
  7065. [Ed. - Thanks for the information.  No, CMS Kermit is supposed to log itself
  7066. out upon receipt of a BYE request, and it does so nicely on our CMS system.
  7067. No one here can think of a reason why it would fail to do so.  Can anyone
  7068. else?]
  7069.  
  7070. ------------------------------
  7071.  
  7072. Date: Mon, 9 Sep 85 13:40:34 BST
  7073. From: Ljwu@ucl-cs.arpa
  7074. Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
  7075. Keywords: MS-DOS Kermit, COMPAQ Portable
  7076.  
  7077.      I have encountered a slight bios incompatability between a real IBM
  7078. PC/XT and a "Compatable" Compaq Portable.  In short, MS-Kermit v2.28 with
  7079. bug fixes as advertised in .BWR file work fine on the XT.  The problem,
  7080. however, is that when sending or receiving files, the Compaq displays a
  7081. blank inverse video mode line with a single spurious character ('s') above
  7082. the transfer status displays.  The mode line displayed during connection
  7083. appears normally.
  7084.  
  7085.      The information normally contained in this mode line is rather
  7086. important in that it gives the user information on how to abort an active
  7087. file transfer.  After some digging, I traced the problem to the routine
  7088. 'putmod' in MSXIBM.ASM.  As I don't have documentation on the bios
  7089. interfaces I did a simple backout to the putmod routine in version 2.27.
  7090.  
  7091. INFO-KERMIT DIGEST V3 #18                                              Page 129
  7092.  
  7093. Below are the affected lines:
  7094.  
  7095. Original version 2.28 code:
  7096.              call    poscur
  7097.              pop     si              ; get message back
  7098.      putmo1: lodsb                   ; get a byte
  7099.              cmp     al,'$'          ; end of string?
  7100.              je      putmo2
  7101.              mov     ah,14           ; write to screen
  7102.              mov     bx,07000h       ; inverse video, page one
  7103.              int     bios
  7104.              jmp     putmo1
  7105.      putmo2: ret                     ; and return
  7106.      putmod  endp
  7107.  
  7108. Version 2.27 backout:
  7109.              call    poscur
  7110.              pop     dx              ; get message back
  7111.              mov     ah,prstr
  7112.              int     dos
  7113.              ret
  7114.      putmod  endp
  7115.  
  7116.         This fix works fine for the COMPAQ.  On a real PC, however, the
  7117. information line is displayed in normal video.  At least this backout
  7118. provides the user with the necessary information in all cases.  Has anybody
  7119. else experienced this anomolous behaviour with a Compaq or have an
  7120. explanation for the incompatability?
  7121.  
  7122.                         -- Les J. Wu <ljwu@ucl-cs.arpa>
  7123.  
  7124. ------------------------------
  7125.  
  7126. Date: Fri, 6 Sep 85 15:19:48 edt
  7127. From: Bob Sutterfield <sutter%ohio-state.csnet@csnet-relay.ARPA>
  7128. Subject: Kermit for Exxon Office Systems 500?
  7129. Keywords: Exxon Office System 500 Kermit
  7130.  
  7131. The secretary across the hall has recently been blessed with an Exxon Office
  7132. Systems 500 Series word processor.  It apparently crunches words nicely
  7133. enough, but its facilities to talk to the outside world are severely
  7134. limited.  It has some sort of asynchronous communications software, but this
  7135. won't do the job for us.
  7136.  
  7137. I don't know what kind of processor it has, nor what operating system it
  7138. runs.  We really need to get several hundred pages of publications off this
  7139. beast, and onto a usable machine.  Does anybody know of pointers to a Kermit
  7140. for this beast?
  7141.  
  7142. ------------------------------
  7143.  
  7144. Date: Mon, 09 Sep 85 03:37:14 cet
  7145. From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
  7146. Subject: Kermit for Cromix and the NCR DMV?
  7147. Keywords: Cromix Kermit, NCR DMV Kermit
  7148.  
  7149.  
  7150. Page 130                                              INFO-KERMIT DIGEST V3 #18
  7151.  
  7152. Any information regarding Kermit for Cromemco Cromixor the NCR
  7153. Decision MATE V ?
  7154.  
  7155. Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>
  7156.  
  7157. ------------------------------
  7158.  
  7159. Date: Tue, 10 Sep 85 14:08:18 PDT
  7160. From: rich@CIT-Hamlet.ARPA
  7161. Subject: MS-DOS Kermit for the Gavilan PC?
  7162. Keywords: MS-DOS Kermit, Gavilan PC
  7163.  
  7164. A professor here has the Gavilan PC with the 3" drives.  Has anyone
  7165. successfully run MS-DOS Kermit on one of these, and if so, can we possibily
  7166. get a copy of the disk?
  7167.  
  7168. Thanks is advance,
  7169.  
  7170. Rich Fagen
  7171. Caltech Computing Support
  7172. rich@cit-hamlet.arpa
  7173. rich@hamlet.bitnet
  7174. (818)-356-3896
  7175.  
  7176. ------------------------------
  7177.  
  7178. End of Info-Kermit Digest
  7179.  
  7180. INFO-KERMIT DIGEST V3 #19                                              Page 131
  7181.  
  7182. Info-Kermit Digest         Fri, 13 Sep 1985       Volume 3 : Number 19
  7183.  
  7184. Departments:
  7185.  
  7186.   MACINTOSH KERMIT -
  7187.     New Macintosh Kermit Bug List
  7188.     Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
  7189.     Garbage in Upper Left Corner on MacKermit
  7190.     MacKermit Comments
  7191.     MacKermit/ScreenSaver Incompatibility
  7192.     MacKermit Transfer Command
  7193.     Macintosh Kermit Key Configurator Limitation
  7194.     Mac Kermit Show-Response Window Too Narrow
  7195.     Bug and Nit in Macintosh Kermit
  7196.     Terminal Emulation Bug In Mac Kermit
  7197.     Double Keying Option-Keys in Mac Kermit
  7198.     Mac Kermit vs Yale ASCII
  7199.  
  7200.   IBM MAINFRAME KERMIT -
  7201.     Kermit for UTS with Series/1
  7202.     CMS Kermit with 7171's (two messages)
  7203.     Kermit-11 vs IBM VM/CMS
  7204.  
  7205.   MISCELLANY -
  7206.     Kermit Distribution in the UK
  7207.  
  7208.  
  7209. ----------------------------------------------------------------------
  7210.  
  7211. Date: Fri 13 Sep 85 17:24:56 EDT
  7212. From: Frank da Cruz <SY.FDC@CU20B>
  7213. Subject: New Macintosh Kermit Bug List
  7214. Keywords: MacKermit
  7215.  
  7216. The following messages report bugs in the current release of Macintosh
  7217. Kermit, or suggest improvements.  These have been noted in the new "beware"
  7218. file, KER:CKMKER.BWR, which is available via anonymous FTP from CU20B.  For
  7219. now, no changes are being made to the program, mainly because Mac Kermit is
  7220. still "between maintainers".
  7221.  
  7222. Although not mentioned specifically in conjunction with Mac Kermit, the
  7223. C-Kermit bug reported by Icarus Sperry (Bath Univ, UK) in Info-Kermit V3
  7224. #17, namely that checksums are computed incorrectly if padding is selected,
  7225. applies also to Macintosh Kermit.
  7226.  
  7227. ------------------------------
  7228.  
  7229. Date: Thu 15 Aug 85 11:12:12-CDT
  7230. From: Don Nash <CC.DLNASH@UT-A20.ARPA>
  7231. Subject: Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
  7232. Keywords: MacKermit, Terminal Emulation
  7233.  
  7234. I just found found this simply wonderful bug in Macintosh Kermit.  Here's how
  7235. to do it:
  7236.  
  7237.         1)  Set MacKermit 0.8(33) for 9600 baud, no parity, remote echo.
  7238.  
  7239. Page 132                                              INFO-KERMIT DIGEST V3 #19
  7240.  
  7241.  
  7242.         2)  Connect to a VAX 11/780 running VMS 4.1 and Eunice and log in.
  7243.  
  7244.         3)  Set your terminal type by having the following lines in your
  7245.             LOGIN.COM file:
  7246.  
  7247.                 $define TERM "vt100"
  7248.                 $set term /dev = vt100 /line
  7249.  
  7250.         4)  Type out a file which is long enough to fill the screen more
  7251.             once using the following command:
  7252.  
  7253.                 type /page filename.ext
  7254.  
  7255.         5)  When you are prompted to hit return, type ^C.  The word "Cancel"
  7256.             should appear, but it should be partially below the screen.
  7257.  
  7258.         6)  Type <CR> several times.  If you get the same results I did, then
  7259.             the screen of the Mac should go crazy.  It looks like snow on a
  7260.             TV set, except that it is black snow on a white background (which
  7261.             seems logical, since the Mac's screen is white).  The Mac is now
  7262.             completely wedged, the cursor does not respond to mouse movements.
  7263.             The only way out is to reset the Mac and restart MacKermit.
  7264.  
  7265. Also, the number zero and the capital letter oh were identical on MacKermit,
  7266. and the same applies to the capital letter "I" (the letter after "H"), and
  7267. the lowercase letter "l" (the letter after "k").  They are also *exactly*
  7268. the same.
  7269.                                         Don Nash
  7270.  
  7271. [Ed. - Thanks, noted in the beware file.]
  7272.  
  7273. ------------------------------
  7274.  
  7275. Date: Thu 15 Aug 85 12:25:26-CDT
  7276. From: Don Nash <CC.DLNASH@UT-A20.ARPA>
  7277. Subject: Garbage in Upper Left Corner on MacKermit
  7278. Keywords: MacKermit
  7279.  
  7280. I read the file CKMKER.BWR.8.  In the section UNDIGESTED, item #3 said that
  7281. Dan Tappan from BBN reported garbage in the upper left corner of the terminal
  7282. emulator window which eventually went away.  I have the same problem, but
  7283. it won't go away.  It is nothing serious, but it does seem to be permanent on
  7284. my copy of MacKermit 0.8(33).  It does not interfere with the display in any
  7285. way.  Hope this aids in digestion.
  7286.  
  7287.                     Don Nash
  7288.  
  7289. ------------------------------
  7290.  
  7291. Date:     Mon, 19 Aug 85 11:45:56 PDT
  7292. From:     msev%Phobos@CIT-Hamlet.ARPA
  7293. Subject:  MacKermit Comments
  7294. Keywords: MacKermit
  7295.  
  7296. I'm very pleased with the new MacKermit release.  I use it now in
  7297.  
  7298. INFO-KERMIT DIGEST V3 #19                                              Page 133
  7299.  
  7300. preference to MacTerminal.  I like the speed:  both initialization and
  7301. operation are much better than MacT.  I have set up the key map to send
  7302. the right characters for EDT.  File transfer with VMS is very smooth.
  7303.  
  7304. - Martin Ewing
  7305.  
  7306. Comments on 0.8(33) Kermit for Macintosh:
  7307.  
  7308. SERIOUS
  7309.  
  7310. 1. The VMS TYPE/PAGE command types a page of output from a file and
  7311. types "Type enter to continue" (or some such) in reverse video on bottom
  7312. line of screen.  If you ^Y at that point to terminate, Kermit writes the
  7313. next line ("Interrupt" in reverse video) on what appears to be line 25.
  7314. Kermit often dies shortly thereafter.  I don't have the exact character
  7315. sequence that VMS is putting out.
  7316.  
  7317. [Ed. - Same as Don Nash's bug.  Temporary workaround: don't use VMS
  7318. (just kidding...)]
  7319.  
  7320. NUISANCE
  7321.  
  7322. 2.  Screen is not thoroughly wiped by erase screen command.  Garbage
  7323. characters left at right of screen (sometimes).  This may have been
  7324. documented before.
  7325.  
  7326. 3.  A blinking cursor, or, better, a blinking solid cursor would be a
  7327. great help.  It's nearly impossible to find the underscore in a page
  7328. full of text.  A user-selectable cursor format would be preferable.
  7329.  
  7330. [Ed. - Good idea.]
  7331.  
  7332. SUGGESTIONS
  7333.  
  7334. 4.  It would be handy to distribute a standard VT100/numeric keypad
  7335. definitions file.  This is important for running the VMS EDT editor.
  7336. I'll donate such a file if requested.
  7337.  
  7338. [Ed. - Please do.]
  7339.  
  7340. 5.  Apparently the VT10x graphics characters are not emulated.  At least
  7341. the MONITOR command on VMS does not produce the desired line and block
  7342. characters.  This would be a useful addition for those of us who like to
  7343. stare at these status displays.
  7344.  
  7345. 6.  Emulate the VT102 printer port commands.
  7346.  
  7347. ------------------------------
  7348.  
  7349. Date: Thu, 8 Aug 85 10:14:02 mdt
  7350. From: jad%b@LANL.ARPA (John De Vries)
  7351. Subject: MacKermit/ScreenSaver Incompatibility
  7352. Keywords: MacKermit
  7353.  
  7354. I have received a report that while making long uploads from MacKermit while
  7355. ScreenSaver (a desk accessory) is active will cause the upload to bomb and
  7356.  
  7357. Page 134                                              INFO-KERMIT DIGEST V3 #19
  7358.  
  7359. will indeed screw up the Mac's system, necessitating a reboot. It happens
  7360. when ScreenSaver goes and blanks the screen...
  7361.  
  7362. Zoz
  7363.  
  7364. ------------------------------
  7365.  
  7366. Date: Fri 9 Aug 85 16:55:15-EDT
  7367. From: Don Lanini <Us.Dcl@CU20D>
  7368. Subject: MacKermit Transfer Command
  7369. Keywords: MacKermit
  7370.  
  7371. Whenever I try to use the transfer command under the transfer menu to launch
  7372. an application from another disk (a disk other than the one Kermit is on), it
  7373. blows up the machine with an ID = 26 error and hangs.
  7374.  
  7375. The version is 0.8(32)
  7376.  
  7377. ------------------------------
  7378.  
  7379. Date: Wed 19 Jun 85 16:30:52-EDT
  7380. From: Bill Schilit <BILL@COLUMBIA-20.ARPA>
  7381. Subject: Macintosh Kermit Key Configurator Limitation
  7382. Keywords: MacKermit
  7383.  
  7384. I just read a message on the net... you might want to configure a system
  7385. disk with the Dutch or German, or French international resources and check
  7386. out the results of this on MacKey...
  7387.  
  7388. I think the result will be an incorrect keyboard (check this out in
  7389. relation to the KEYCAPS display).  Since the key names are hard
  7390. coded in an array in the program...
  7391.  
  7392. ------------------------------
  7393.  
  7394. Date: Tue, 9 Jul 85 18:43:58 edt
  7395. From: Mike Ciaraldi  <ciaraldi@rochester.arpa>
  7396. Subject: Mac Kermit Show-Response Window Too Narrow
  7397. Keywords: MacKermit
  7398.  
  7399. When you give a remote command (e.g. Directory) to a server, the results
  7400. come up in a window.  You can scroll the window from side to side, but even
  7401. if you move it all the way to the left (i.e. the little box in the
  7402. horizontal scroll bar is all the way to the right), you still can't see the
  7403. right end of the line of text.  You have to stretch the window to see it.
  7404.  
  7405. [Ed. - I agree this might not be intuitively obvious to the user...]
  7406.  
  7407. When you do a "Get file from server", after the transfer is complete the box
  7408. that keeps you informed of the progress of the transfer still stays on the
  7409. middle of the screen until you click on it.  This is not really obvious as
  7410. the way to continue.  What makes it bad is that the mouse pointer still
  7411. shows as the little clock face indefinitely, implying that you ought to wait
  7412. before proceeding (maybe while it closes the file or something).
  7413.  
  7414. [Ed. - Right, this has been noted in the .BWR file all along.]
  7415.  
  7416. INFO-KERMIT DIGEST V3 #19                                              Page 135
  7417.  
  7418.  
  7419. ------------------------------
  7420.  
  7421.  
  7422. Date: 23 Jul 1985 02:04 PST
  7423. From: Charles Carvalho <CHARLES@ACC>
  7424. Subject: Bug and Nit in Macintosh Kermit
  7425. Keywords: MacKermit
  7426.  
  7427. A friend pointed out a bug and a nit in the Macintosh Kermit:
  7428.  
  7429. bug: if you call SFGetFile with the numTypes argument equal to zero,
  7430. it apparently doesn't find all files; numTypes should be -1 instead.
  7431.  
  7432. [Ed. - From one of the authors: "I haven't noticed any problems, and I
  7433. believe the code reflects the documentation."  Has anyone actually observed
  7434. files being skipped over?]
  7435.  
  7436. nit: the Close box at the left of the MacKermit window doesn't do anything;
  7437. it ought to be left out (define the window with the NoGoAway attribute).
  7438.  
  7439.                         /Charles
  7440.  
  7441. ------------------------------
  7442.  
  7443. Date: Wed 31 Jul 85 15:18:44-EDT
  7444. From: Ben Fried <UI.Ben@CU20C>
  7445. Subject: Terminal Emulation Bug In Mac Kermit
  7446. Keywords: MacKermit, Terminal Emulation
  7447.  
  7448. I don't know if i can reproduce this, but i definitely found a bug in mac
  7449. kermit 0.8(33)
  7450.  
  7451. I was in emacs, typing a command into the echo area, when a send came in.  the
  7452. first few scan lines of the text showed up at the bottom of the screen, then
  7453. it froze--i had mouse control, but the event handler must have frozen,
  7454. because i got no response to any sort of update event -- keydowns, clicking
  7455. the mouse, whatever.
  7456.  
  7457. it looks like it didn't handle the scrolling of the text i was sent correctly,
  7458. and died somewhere in there.  but i'm not sure.
  7459.  
  7460. [Ed. - "Doubt it was the event handler, more likely it is a scroll problem with
  7461. the characters being drawn off the screen."  Noted in .BWR file.]
  7462.  
  7463. ------------------------------
  7464.  
  7465. Date:  Sat, 7 Sep 85 19:10 MST
  7466. From: Barry Margolin <Margolin@HIS-PHOENIX-MULTICS.ARPA>
  7467. Subject: Double Keying Option-Keys in Mac Kermit
  7468.  
  7469. I think I've figured out why certain characters have to be doubled in
  7470. order to send them in MacKermit.  These characters are normally set to
  7471. nonspacing diacritical marks.  For instance, Option-e is normally a
  7472. nonspacing accent grave.  In the normal Macintosh text input
  7473. environment, nothing gets sent until you type the next character after a
  7474.  
  7475. Page 136                                              INFO-KERMIT DIGEST V3 #19
  7476.  
  7477. diacritical, so that it can send the appropriate accented character.  If
  7478. you type the diacritical twice, it sends just the diacritial character.
  7479. If you type a character that cannot be used with that diacritical, it
  7480. sends the diacritical followed by the character.  This is all consistent
  7481. with the behavior I have seen when I use the Option key as a Control
  7482. key.  I suspect that the same problems would exist if I used the Option
  7483. key as a Meta key, which I believe is the default.
  7484.  
  7485. [Ed. - This was also noted in the .BWR file that originally went out with
  7486. 0.8(33).]
  7487.  
  7488. ------------------------------
  7489.  
  7490. Date: Thu, 22 Aug 85 19:47:45 edt
  7491. From: Mike Ciaraldi <ciaraldi@rochester.arpa>
  7492. Subject: Mac Kermit vs Yale ASCII
  7493.  
  7494. We just started using MacKermit to talk to our IBM 4381, which uses a Series
  7495. 1 front end with the Yale Ascii package.  On the other end we installed the
  7496. version of TSO Kermit from U of Toronto.
  7497.  
  7498. File transfers work OK, it seems.
  7499.  
  7500. Big problem with terminal emulation.  The packages we use on MVS use lots of
  7501. boldface.  The CKMKER.BWR file says that boldface characters are the wrong
  7502. size, but for us it's worse than that.  The cursor proceeds along, putting
  7503. stuff on the screen, then skips back and erases several characters, leaving
  7504. a series of gaps in the line of text.  If you open up a window over the
  7505. affected area, then close it again, the text is OK.  It's not in boldface,
  7506. but it is perfectly readable and in the right place.
  7507.  
  7508. [Ed. - The problem is still probably due to the characters being a different
  7509. size from what they program thinks they are.  Some IBM/Yale-ASCII sites have
  7510. found the problem so annoying that they define a new terminal type for the
  7511. Macs, which is basically a VT100 without boldface.]
  7512.  
  7513. We tried opening up the SHOW RESPONSE window, stretching it to almost fill
  7514. the screen, then switching back and forth between it and the main window to
  7515. force refreshing of the screen image in the main window.  This works, but
  7516. the lower right corner of the SHOW RESPONSE window is "dead", i.e. clicking
  7517. on it will not bring the window to the front.  The dead area is the part
  7518. where the size-changing icon usually appears.  When the main window is in
  7519. the background, there doesn't seem to be this problem getting it back.
  7520.  
  7521. Mike Ciaraldi
  7522. ciaraldi@rochester
  7523.  
  7524. [Ed. - Mike mentioned in a subsequent message that they would try to come up
  7525. with a fix for the boldface problem.]
  7526.  
  7527. ------------------------------
  7528.  
  7529. Date: 12 September 1985, 15:31:45 EDT
  7530. From: Philip Murton <MURTON@UTORONTO.BITNET>
  7531. Subject: Kermit for UTS with Series/1
  7532.  
  7533.  
  7534. INFO-KERMIT DIGEST V3 #19                                              Page 137
  7535.  
  7536. We are no longer running UTS under VM here so that only version
  7537. of Kermit for UTS I have is based on the old UNIX Kermit.
  7538.  
  7539. [Ed. - This is the KERMIT.C from the Protocol Manual, with modifications
  7540. to support the Series/1, presumably it will also work with the 7171, 4994,
  7541. and other systems that run the Yale ASCII package.  I've put it in
  7542. K2:UTSS1.C on CU20B.]
  7543.  
  7544. ------------------------------
  7545.  
  7546. Date: Fri, 13 Sep 85 02:07:01 EDT
  7547. From: Peter DiCamillo <CMSMAINT@BROWNVM>
  7548. Subject: CMS Kermit with 7171's
  7549.  
  7550. I can confirm Steve Ostrove's experience that CMS Kermit through the 7171
  7551. does not log itself out, and only responds to FINISH.  Even with FINISH, CMS
  7552. Kermit doesn't respond with "R;" until after I enter a carriage return back
  7553. in the terminal session.
  7554.  
  7555. From what I have heard, the packet size problem with 7171s is a performance
  7556. problem which only shows up when a 7171 is loaded.  If Steve was testing
  7557. with only one or two users on the 7171, then a larger packet size would
  7558. work.  I haven't had a chance to confirm this myself yet.
  7559.  
  7560. Kermit should be able to distinguish a Series/1 from a 7171 because a
  7561. Series/1 emulates a 3277 terminal, but a 7171 emulates a 3278 terminal. This
  7562. device type information is available to a program by using DIAG X'24' to
  7563. obtain information about the virtual console.
  7564.  
  7565. Peter DiCamillo
  7566.  
  7567. [Ed. - Can anyone provide a clue as to why CMS Kermit might refuse to log
  7568. itself out when run from a 7171, but log out OK when run from a 3705???]
  7569.  
  7570. ------------------------------
  7571.  
  7572. Date: 13 September 85 14:35 EDT
  7573. From: NJG@CORNELLA.BITNET
  7574. Subject: CMS Kermit and 7171s
  7575.  
  7576. The problem with Kermit (CMS at least, and I expect the same with TSO) and
  7577. 7171s should only show up if the 7171 can not field the incoming characters
  7578. as fast as they are sent. This forces the 7171 to use a 64 character long
  7579. circular type ahead buffer. Once this buffer fills up the 7171 will not
  7580. accept further input until the buffer starts to empty.  As long as a set of
  7581. 8 terminal ports is not 'over worked' it should be able to handle input from
  7582. a terminal at 9600 baud. It is only when more than one of the terminals on a
  7583. set of 8 ports is sending large data buffers at high data rates that there
  7584. will be overrun problems. I do not know at what data rates or how many
  7585. active terminals it takes to actually cause the problems, but 1 terminal at
  7586. 9600 baud (plus the rest doing normal terminal type output traffic, not file
  7587. transfer) should not exhibit the problem. This problem has been discussed
  7588. with the IBM development team for the 7171. Personally I doubt that the
  7589. problem will be corrected in future versions of the device as it appears
  7590. that IBM does not intend to have the device support file transfer, but
  7591. rather to support attachment of dumb-terminals only.
  7592.  
  7593. Page 138                                              INFO-KERMIT DIGEST V3 #19
  7594.  
  7595.  
  7596. ":-)" Nick Gimbrone <NJG@CORNELLA.BITNET> (607)256-3747
  7597.  
  7598. ------------------------------
  7599.  
  7600. Date: 13 SEP 85 07:39-EST
  7601. From:  BRIAN%UOFT02.BITNET@WISCVM.ARPA
  7602. Subject: Kermit-11 vs IBM VM/CMS
  7603.  
  7604. The most recent Kermit digest had a comment regarding Kermit-11 and CMS.
  7605. Here is an explanation (?)
  7606.  
  7607. I should point out that Kermit-11 has never worked well with CMS  Kermit
  7608. (before  the  S/1  support) as the U of Toledo does not use standard IBM
  7609. half duplex lines, thus making testing impossible. The  controller  here
  7610. is  a  CCI  which  fakes  a FDX link. Kermit-11 does, however, work fine
  7611. with the S/1 support in the newest CMS kermit, as long as one  remembers
  7612. to set parity to anything other than the default, none.
  7613.  
  7614. brian nelson
  7615.  
  7616. ------------------------------
  7617.  
  7618. Date: 10-SEP-1985 10:39:01
  7619. From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  7620. Subject: Kermit Distribution in the UK
  7621.  
  7622. Lancaster University (UK) have just installed Columbia tapes written there
  7623. on August 3. The files are all online on a VAX 11/780 and can be accessed
  7624. freely by anyone who wishes using NIFTP or KERMIT. We can also send out
  7625. files on 9 track tape, and on floppy for some versions. The collection is
  7626. regularly updated with new tapes and files pulled from cu20b direct. For
  7627. details mail to Alan Phillips, SYSKERMIT @ LANCS.VAX1 (JANET address
  7628. 000010404000.FTP.MAIL, or PSS address 23425240101.000010404000.FTP.MAIL), or
  7629. phone 0524-65201 x 4881. Distribution is free to all educational
  7630. establishments: a small handling charge is made to commercial users.
  7631.  
  7632. ------------------------------
  7633.  
  7634. End of Info-Kermit Digest
  7635.  
  7636. INFO-KERMIT DIGEST V3 #20                                              Page 139
  7637.  
  7638. Info-Kermit Digest         Fri, 20 Sep 1985       Volume 3 : Number 20
  7639.  
  7640. Departments:
  7641.  
  7642.   ANNOUNCEMENTS -
  7643.     Kermit Available for Os9
  7644.     Commodore 64 Kermit V1.7 Available
  7645.     NEC APC III Kermit Available
  7646.  
  7647.   IBM MAINFRAME KERMIT -
  7648.     CMS Kermit Server Logout Problem Solved
  7649.     CMS Kermit 2.01 Init File Problem
  7650.  
  7651.   MISCELLANY -
  7652.     Kermit Diskette Distribution
  7653.     Kermit Diskette Distribution in UK
  7654.     Kermit-11, P/OS, and TMS
  7655.     Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD
  7656.     C-Kermit on Xenix on PC/AT?
  7657.     C-Kermit for SUN on 1/4" Tape Cartridge?
  7658.     MacKermit Beware Addition
  7659.     Apple Kermit & CCS Card
  7660.     Kermit as Mail Server?
  7661.     Kermit for Victor 9000?
  7662.     Octopus / Flex Kermit?
  7663.  
  7664. ----------------------------------------------------------------------
  7665.  
  7666. Date: Wed 18 Sep 85 00:57:23-PDT
  7667. From: BLARSON@USC-ECLB.ARPA
  7668. Subject: Kermit Available for Os9
  7669.  
  7670. Os9 kermit is ready for distribution.  It is based on old Unix Kermit, and
  7671. also has limited server functions.  Read the .doc, .hlp, and .bwr files for
  7672. known limitations.  (It should work on all os9 versions, but connect mode
  7673. has a problem with the CoCo bit banger port.)
  7674.  
  7675. I am willing to make a "s" format (hexadecimal) file available, but due to
  7676. numerous compile time options, its usefulness would be limited.
  7677.  
  7678. Bob Larson <Blarson@Usc-Ecl.Arpa>
  7679. UUcp:  ihnp4!sdcrdcf!oberon!blarson
  7680.  
  7681. [Ed. - The files are available for anonymous FTP from CU20B as KER:OS9*.*.]
  7682.  
  7683. ------------------------------
  7684.  
  7685. Date: 8 Aug 85 10:02:53 EDT
  7686. From: Eric <LAVITSKY@RU-BLUE.ARPA>
  7687. Subject: Commodore 64 Kermit V1.7 Available
  7688.  
  7689. C64 Kermit V1.7(52) is ready for release. The new edits are bug fixes to the
  7690. command parser that screwed up the disk commands, a fix to make 1200 baud
  7691. file transmission work at a full 1200 baud, and a fix to the ASCII/PETSCI
  7692. conversion tables. All fixes were done by Frank Prindle (Prindle@NADC).
  7693.  
  7694.  
  7695. Page 140                                              INFO-KERMIT DIGEST V3 #20
  7696.  
  7697. ------------------------------
  7698.  
  7699. Date: Thu 19 Sep 85 18:40:42-PDT
  7700. From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
  7701. Subject: NEC APC III Kermit Available
  7702.  
  7703. Here is the MSXAP3.ASM module for the NEC APC III.  I have only used this
  7704. briefly once, but as far as I can tell it does not implement keyboard
  7705. redefinition, does not implement any type of terminal emulation, and only
  7706. works with the standard serial port.  Terminal mode does not have backward
  7707. paging.
  7708.  
  7709. The author is RAL from Virginia Polytechnic Institute, more than that I
  7710. don't know.
  7711.  
  7712. -- Ron
  7713.  
  7714. [Ed. - Thanks, Ron.  The source file is in KER:MSXAP3.ASM on CU20B.]
  7715.  
  7716. ------------------------------
  7717.  
  7718. Date: Tue, 17 Sep 85 00:19:12 EDT
  7719. From: Peter DiCamillo <CMSMAINT@BROWNVM>
  7720. Subject: CMS Kermit Server Logout Problem Solved
  7721.  
  7722. I think I've figured out why CMS Kermit doesn't log itself out correctly
  7723. through a Series/1 or 7171.  There are two problems.  First, when CMS
  7724. Kermit sends an ack to the logout or finish command, it uses transparent
  7725. write/read, as if it expected a response.  The micro doesn't send a
  7726. response, which I believe matches the Kermit protocol, so the user
  7727. has to complete the read.  The following update to CMS Kermit corrects
  7728. this problem by sending the final ack with just a transparent write:
  7729.  
  7730. ./ R 00846000       $ 846290 290                   09/16/85 22:44:58
  7731.          DC     X'40',AL1(SBA),X'5D7F',AL1(SBA)             UPDATE1  00846290
  7732. S1ORDAD  DC     X'0001'             addr. -> 0 for write    UPDATE1  00846580
  7733. ./ I 01601000       $ 1601500 500                  09/16/85 22:44:58
  7734.          XC     S1ORDAD(2),S1ORDAD  just write when ending  UPDATE1  01601500
  7735. ./ I 02869000       $ 2869300 300                  09/16/85 22:44:58
  7736.          CLC    S1ORDAD(2),=H'0'    was write/read done?    UPDATE1  02869300
  7737.          BE     SPRET               no: return now          UPDATE1  02869600
  7738.  
  7739.              ^
  7740. [Ed. - I've removed some spaces so this will fit on the screen.]
  7741.  
  7742. The second problem affects only the logout command.  Before issuing the CP
  7743. LOG command, CMS Kermit uses the sequence of WRTERM and WAITT to send an XON
  7744. to the micro and wait for the write to complete.  However, if the console is
  7745. a Series/1 or 7171, CMS Kermit's own console interrupt handler is still in
  7746. control, so CMS hangs when the WAITT is executed.  Also, to send an XON in
  7747. this case would require another transparent write, since WRTERM cannot send
  7748. control characters through a full-screen interface.  The following update
  7749. solves this problem by bypassing the calls to WRTERM and WAITT for Series/1
  7750. and 7171 connections.  It seemed safe to skip them since they weren't
  7751. working in this case anyway.
  7752.  
  7753.  
  7754. INFO-KERMIT DIGEST V3 #20                                              Page 141
  7755.  
  7756. ./ I 01607000       $ 1607300 300                  09/16/85 22:44:58
  7757.          TM     S1FLAGS,ISS1        Is console a S/1?       UPDATE2  01607300
  7758.          BO     SERVLOG             Yes: skip line mode I/O UPDATE2  01607600
  7759. ./ R 01611000       $ 1611490 490                  09/16/85 22:44:58
  7760. SERVLOG  LA     1,=C'LOG'                                   UPDATE2  01611490
  7761.  
  7762. These updates are for CMS Kermit Version 2.01, and assume serialization
  7763. starting at 1000 with an increment of 1000.  I've tested them with success
  7764. on both a Series/1 and a 7171.
  7765.  
  7766. Peter
  7767.  
  7768. [Ed. - Thanks, Peter -- I've included your message in CMSMIT.BWR until the
  7769. next release comes out.]
  7770.  
  7771. ------------------------------
  7772.  
  7773. Date: Wed, 18 Sep 85 9:11:17 BST
  7774. From: Andrew J Cole <ajcole@ucl-cs.arpa>
  7775. Subject: CMS Kermit 2.01 Init File Problem
  7776.  
  7777. CMS Kermit 2.01 works very well with one small exception (non-feature?).
  7778. If server mode is entered directly from the CMS command line Kermit seems
  7779. to fail to read the KERMINI files.
  7780.  
  7781. Many thanks for such a useful system for a real pig of a system!
  7782.  
  7783. [Ed. - Thanks for the report; it's been added to the .BWR file.]
  7784.  
  7785. ------------------------------
  7786.  
  7787. Date: Tue, 17 Sep 85 11:47:16 EDT
  7788. From: Don_Porter%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
  7789. Subject: Kermit Diskette Distribution
  7790.  
  7791. I'd be willing to distribute Macintosh Kermit at RPI if you send me a copy
  7792. on diskette. There aren't many Macs at RPI, but there are a few. We support
  7793. Kermit on several mainframes on campus, and distribute it for IBM PCs and
  7794. some compatibles.
  7795.  
  7796.   Don Porter
  7797.   Assoc. Dir., Information Technology Services
  7798.  
  7799. [Ed. - I got a lot of responses like this to my query about Kermit diskette
  7800. distribution.  I guess I wasn't clear enough...  What I'm looking for are
  7801. organizations or individuals willing to distribute Kermit on diskette in some
  7802. particular format to the general public, e.g. by mail order, not just within
  7803. their own organizations.  I haven't received reports of any of these.  Can
  7804. anyone tell me about, say, Heath or Atari or Apple or ... user groups that
  7805. provide this kind of service, like PC SIG does for the IBM PC?]
  7806.  
  7807. ------------------------------
  7808.  
  7809. Date: 19-SEP-1985 11:17:29
  7810. From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  7811. Subject: Kermit Diskette Distribution in UK
  7812.  
  7813. Page 142                                              INFO-KERMIT DIGEST V3 #20
  7814.  
  7815.  
  7816.   Lancaster University is able to distribute some KERMITs on native media. We
  7817. can currently handle Aculab Z80B, Sirius 1 (CP/M-86 and MS-DOS), BBC micro,
  7818. DEC Rainbow (CP/M-86) and IBM PC. We also maintain a freely accessible
  7819. contact list of other UK native media suppliers for machines we don't have,
  7820. and can broadcast enquiries to the UK Kermit community at large.
  7821.   Distribution is free in the UK to educational users, but there's a small
  7822. handling charge for others: we don't supply the discs ourselves. Interested
  7823. users should contact me BEFORE sending discs, to check availability.
  7824.   The service is one person, so response might be a few weeks, especially if I
  7825. have to pass discs on to others who actually own the machines.
  7826.   We are willing to co-ordinate supply in the UK : anyone who wishes can be put
  7827. onto our contact list if they let me have details.
  7828.  
  7829.               Alan Phillips
  7830.                 Department of Computing
  7831.                   Lancaster University UK
  7832.  
  7833. E-mail to     SYSKERMIT @ LANCS.VAX1
  7834. JANET address 000010404000.FTP.MAIL
  7835. PSS   address 234252400101.000010404000.FTP.MAIL
  7836. Telephone  to 0524-65201x4881
  7837.  
  7838. (I cannot reply over UUCP and only unreliably over ARPA)
  7839.  
  7840. ------------------------------
  7841.  
  7842. Date: 18 SEP 85 12:11-EST
  7843. From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
  7844. Subject: Kermit-11, P/OS, and TMS
  7845.  
  7846. I may interest you to know that someone is adding to Kermit-11 for P/OS
  7847. to support TMS.  I, as is often the case, will be unable to test such as
  7848. I do not hav TMS on the PRO but it does sound like the mods to Kermit-11
  7849. should be quite minimal.
  7850.  
  7851. brian
  7852.  
  7853. ------------------------------
  7854.  
  7855. Date: 18 Sep 1985 1046-PDT (Wednesday)
  7856. From: Paul Graham <unr70!unrvax!pjg@seismo.CSS.GOV>
  7857. Subject: Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD
  7858.  
  7859. A nearby site using an Integrated Solutions (IS) q-bus 68000 board under
  7860. 4.2bsd has been unable to get Kermit to open the phone line.  Monitoring the
  7861. line shows behavior similar to cu and tip when the the line is first opened
  7862. (some lines are pulsed briefly) but after that kermit hangs.  It works in
  7863. remote mode just fine.  Anybody out there using an IS system successfuly?
  7864.  
  7865. Thanks for your time.
  7866.  
  7867. Paul Graham 702/784-6007
  7868. University of Nevada Reno
  7869. ucbvax!decvax!seismo!unr70!unrvax!pjg
  7870. unr70!unrvax!pjg@seismo[.CSS.GOV|.ARPA]
  7871.  
  7872. INFO-KERMIT DIGEST V3 #20                                              Page 143
  7873.  
  7874.  
  7875. [Ed. - There seems to be a lot of this going around, see below...]
  7876.  
  7877. ------------------------------
  7878.  
  7879. Date: Fri, 20 Sep 85 15:15:11 edt
  7880. From: yhe@ORNL-MSR.ARPA (Young Etheridge)
  7881. Subject: C-Kermit on Xenix on PC/AT?
  7882.  
  7883. Am encountering problem with "connect".  After connecting /dev/tty00
  7884. to a null-modem line, then "set line /dev/tty00" followed with
  7885. "set baud 4800" then "connect", results in a deadly silence thereafter.
  7886.  
  7887. The communications channel is okay since "cu" works as advertised.
  7888.  
  7889. [Ed. - Can anyone who has this working offer some tips?]
  7890.  
  7891. ------------------------------
  7892.  
  7893. Date: Mon 16 Sep 85 13:41:12-EDT
  7894. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  7895. Subject: C-Kermit for SUN on 1/4" Tape Cartridge?
  7896.  
  7897. Anyone willing to provide a working C-Kermit program for the SUN with 4.2BSD
  7898. on quarter-inch tape cartridge, please contact
  7899.  
  7900.     Peter Hiscocks
  7901.     416-979-5000 x6109
  7902.     Center for Advanced Technology (Ryerson Polytech), Toronto
  7903.  
  7904. ------------------------------
  7905.  
  7906. Date: 19 Sep 85 20:05:07 CDT (Thu)
  7907. From: ihnp4!islenet!david@Berkeley.EDU
  7908. Subject: MacKermit Beware Addition
  7909.  
  7910. Minor addition to your Mackermit BWR file: when a Settings file is saved,
  7911. it does not store the Command-Shift-1...Command-Shift-9 flag, so we have
  7912. to set it every session if we want it active.
  7913.  
  7914. [Ed. - Thanks, I've added it.]
  7915.  
  7916. ------------------------------
  7917.  
  7918. Date: Fri, 20 Sep 85 11:19:17 BST
  7919. From: Chris_K_Now-and-Then <cjk@ucl-cs.arpa>
  7920. Subject: Apple Kermit & CCS Card
  7921.  
  7922.      This note has circulated in UK.  It's obviously of general interest,
  7923. so I send if on to you.
  7924.                         Chris Kennington.
  7925.   Date: Wed 18 Sep 85 19:40:36-GDT
  7926.   From: Alan Greig <CCD-ARG@UK.AC.dct>
  7927.   Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
  7928.  
  7929. On the subject of Kermit for various Apple serial cards, the most notable
  7930.  
  7931. Page 144                                              INFO-KERMIT DIGEST V3 #20
  7932.  
  7933. ommision (to my mind anyway) is the lack of support for the California
  7934. Computer Systems Card (CCS) which seems to be almost universely used in the
  7935. UK. At DCT we added support for this card to the sources and as we have
  7936. CROSS can provide hex files with this change. The original changes were made
  7937. by Colin Bruce (Colin%DCT@UK.AC.DUNDEE) who has now left to work with Data
  7938. General and involve only a few additions to some tables. The only known bug
  7939. is that the the card needs to be specifically reset by sticking some value
  7940. in its command register before running Kermit. (PR#n,IN#n RESET will do
  7941. this). This initialisation could/should really be inside apple kermit but
  7942. I've never got round to recompiling it.
  7943.  
  7944. Anyway it works and if anybody wants it let me know or I can send down
  7945. the changes to Lancaster.
  7946.  
  7947.             Alan Greig
  7948.              (Alan%DCT@UK.AC.DUNDEE)
  7949.  
  7950. ------------------------------
  7951.  
  7952. Date: Thursday, 19 September 1985  10:05-MDT
  7953. From: <crash!bblue@nosc.ARPA>
  7954. Subject: Kermit as Mail Server?
  7955.  
  7956. I've seen several messages lately about people allegedly using Kermit as a
  7957. mail gateway to Unix systems.  Do you know how that is being done?  Seems
  7958. like there would have to be a lot more Kermit than I've ever seen to
  7959. accomplish it.  The implications are that of an almost uucp-like server.
  7960.  
  7961. Enlighten me, please?
  7962.  
  7963. --Bill
  7964.  
  7965. [Ed. - It is possible to run a Unix Kermit server as a login shell; OK
  7966. State is doing this.  Presumably, you can then have other systems dial it
  7967. up, transfer queued mail to it, and then issue the appropriate "remote
  7968. host" command to it to deliver the mail.  I don't know if anyone is actually
  7969. doing this -- is anyone???  However, I have heard of Kermit servers being
  7970. used as print spoolers, etc.]
  7971.  
  7972. ------------------------------
  7973.  
  7974. Date: Friday, 13 September 1985  14:40-MDT
  7975. From: hao!nbires!isis!galon!root@SEISMO.ARPA
  7976. Subject: Kermit for Victor 9000?
  7977.  
  7978. A friend has a Victor 9000 and is trying to talk with some IBM PC's.
  7979.  
  7980. I've been trying to get him a suite of Kermit Programs but todate have
  7981. been unsuccessful.  A tape won't do him any good and I haven't found
  7982. it on floppies.  I did locate it at Okstate, but was unable to pull it
  7983. using their uucp instructions either in kermit-a or kermit-b
  7984. directories.
  7985.  
  7986. Anyone knowing of or having a copy please contact me via email.
  7987.  
  7988. Thanks.
  7989.  
  7990. INFO-KERMIT DIGEST V3 #20                                              Page 145
  7991.  
  7992.  
  7993. Pat Gallivan @                   UUCP: ..!seismo!hao!nbires!isis!galon!fmg
  7994. Galon Exploration, Inc.
  7995. 7122 S. Fillmore,                       (303) 770-6229
  7996. Littleton, CO  80122             Data:  (303) 771-0258
  7997.  
  7998. ------------------------------
  7999.  
  8000. Date: Tue, 17 Sep 85 17:26:34 BST
  8001. From: Chris_K_Now-and-Then <cjk@ucl-cs.arpa>
  8002. To: info-kermit@cu20b.columbia.edu
  8003. cc: cjk@ucl-cs.arpa
  8004. Subject: Octopus / Flex Kermit?
  8005.  
  8006. Kermiteers:
  8007.      Anyone working on Kermits for either Octopus or Flex
  8008. machines?  Both wanted in the UK.
  8009.      Reply to "cjk@ucl-cs", a valid arpanet address.
  8010.                                         Chris Kennington
  8011.  
  8012. ------------------------------
  8013.  
  8014. End of Info-Kermit Digest
  8015.  
  8016. Page 146                                              INFO-KERMIT DIGEST V3 #21
  8017.  
  8018. Info-Kermit Digest         Tue, 24 Sep 1985       Volume 3 : Number 21
  8019.  
  8020. Departments:
  8021.  
  8022.   ANNOUNCEMENTS -
  8023.     Kermit for QNX
  8024.     Kermit for Intel System 86/380 with iRMX-86
  8025.     Kermit for HP-1000 A-Series with RTE-A
  8026.     Kermit for Zilog System 8000 Zeus (Sys V)
  8027.     Kermit for the HP Integral PC
  8028.     Update of Fujitsu Micro-16s CP/M-86 Kermit
  8029.  
  8030.   UNIX KERMIT -
  8031.     Kermit for UUCP Mail
  8032.     Changes to C-Kermit 4C(057)
  8033.     Bug Fix for C-Kermit User Interface
  8034.     C-Kermit on Masscomp Systems?
  8035.  
  8036.   MS-DOS KERMIT -
  8037.     Problem with Sanyo 555 Kermit
  8038.     MsKermit Linking Idea
  8039.  
  8040. ----------------------------------------------------------------------
  8041.  
  8042. Date: Mon, 23 Sep 85 13:14:33 edt
  8043. From: Frank da Cruz <fdc@cucca>
  8044. Subject: Kermit for QNX
  8045.  
  8046. A version of Kermit for the Quantum Software QNX operating system has been
  8047. contributed by Anthony J. Starks, Merrell Dow Research Institute,
  8048. Indianapolis IN; although he doesn't mention what system it's supposed to
  8049. run on in his transmittal letter, I believe it's for 8088-based systems like
  8050. the IBM XT or AT and/or the DEC Rainbow.
  8051.  
  8052. The program based on the "old" Unix Kermit, but the QNX-specific support is
  8053. sufficiently different from any other Unix code I've seen that I've
  8054. installed it as a separate set of files, rather than attempting to merge it
  8055. with C-Kermit.  The files are in KER:QNX*.* on CU20B, available via
  8056. anonymous FTP.
  8057.  
  8058. ------------------------------
  8059.  
  8060. Date: 23 Sep 85 13:44:04-EDT
  8061. From: Frank da Cruz
  8062. Subject: Kermit for Intel System 86/380 with iRMX-86
  8063.  
  8064. This is to announce Kermit for the Intel System 86/380 running iRMX-86,
  8065. written by Albert J. Goodman, Grinnell College, Grinnell, Iowa.  The program
  8066. is written in PL/M-86.  The source files (including built-in help) are
  8067. concatenated together into the file KER:I86KER.PLM, and a short external
  8068. help file is included as KER:I86KER.HLP, available from CU20B via anonymous
  8069. FTP.
  8070.  
  8071. ------------------------------
  8072.  
  8073. Date: Mon 23 Sep 85 13:46:33-EDT
  8074.  
  8075. INFO-KERMIT DIGEST V3 #21                                              Page 147
  8076.  
  8077. From: Frank da Cruz <SY.FDC@CU20B>
  8078. Subject: Kermit for HP-1000 A-Series with RTE-A
  8079.  
  8080. Announcing Kermit for the HP-1000 A-Series with RTE-A, written in
  8081. Pascal/1000, contributed by Tor Lillqvist, Technical Research Centre of
  8082. Finland.  Here is his cover letter:
  8083.  
  8084. This is a Kermit implementation for the HP1000 A-series machines running the
  8085. RTE-A operating system (HPAKermit). It will probably also work on the older
  8086. E-series machines running RTE-6/VM.
  8087.  
  8088. The file HPAKERMIT.SRC is a large text file into which is merged all the
  8089. source files needed to build HPAKermit (just to keep the number of files
  8090. down).
  8091.  
  8092. HPAKermit is written in the Pascal/1000 dialect. (A note to Pascal purists:
  8093. this has many "useful extensions" which makes it more suitable to "Real
  8094. Programming", but of course removes any chance of an easy port to some other
  8095. Pascal system.) I would certainly prefer 'C', but the 'C' compiler for
  8096. HP1000 seems rather oldfashioned, and in any case, we don't have it.
  8097. HPAKermit must be compiled with the Pascal/1000 compiler of revision 2410
  8098. (or later).
  8099.  
  8100. HPAKermit is based on the (old) Unix Kermit, and has only basic features
  8101. (Send, Receive and Get). Connect mode is missing, as it is very hard, maybe
  8102. impossible, to implement successfully on a HP1000. Server mode is also
  8103. missing, but that is only a "Not-Yet-Implemented" issue.
  8104.  
  8105. HPAKermit has been tested extensively with MSDOS-Kermit version 2.27 and
  8106. HP3000 Kermit.  Using 9600 bps and an IBM PC/XT a transfer rate of 470
  8107. chars/s is achieved.
  8108.  
  8109. Best regards,
  8110.  
  8111. Tor Lillqvist
  8112. Technical Research Centre of Finland
  8113. Lehtisaarentie 2 A,
  8114. SF-00340  HELSINKI, FINLAND
  8115.  
  8116. Phone:  +358 0 4566132
  8117. Telex:  122972 vttha sf
  8118.  
  8119. I have no net address, but you can reach me through a friend of mine:
  8120. mcvax!hut!jtv
  8121.  
  8122. [Ed. - The files are in K2:HPA*.*, available via anonymous FTP.]
  8123.  
  8124. ------------------------------
  8125.  
  8126. Date: Mon, 23 Sep 85 12:43:29 edt
  8127. From: Frank da Cruz <fdc@cucca>
  8128. Subject: Kermit for Zilog System 8000 Zeus (Sys V)
  8129.  
  8130. I received a tape from Mark E. Sunderlin, Internal Revenue Service,
  8131. containing C-Kermit 4C(057) revised to include support for the Zilog System
  8132. 8000 with Zeus 3.20 and later.  This will appear in the next release.
  8133.  
  8134. Page 148                                              INFO-KERMIT DIGEST V3 #21
  8135.  
  8136. Meanwhile, if anyone can't wait, the trick seems to be to build it for
  8137. System III/V ("make sys3") in the normal way, but first change all
  8138. occurrences of "setjmp" to "setret" and "longjmp" to "longret".  This might
  8139. be accomplished in the makefile without changing the program source by doing
  8140. something like...
  8141.  
  8142. zilog:
  8143.     make wermit "CFLAGS = -DUXIII -Dsetjmp=setret -Dlongjmp=longret -i" \
  8144.     "LNKFLAGS = -i -w"
  8145.  
  8146. (and also including -DDEBUG, -DTLOG, -O if desired); no one has tested doing
  8147. it this way, but the same trick works for some of the other systems.
  8148.  
  8149. ------------------------------
  8150.  
  8151. Date: Mon, 23 Sep 85 12:43:29 edt
  8152. From: Frank da Cruz <fdc@cucca>
  8153. Subject: Kermit for the HP Integral PC
  8154.  
  8155. I received a tape from Robert Raymond of TransEra Corp, Provo Utah, with a
  8156. version of Kermit for HP Integral PC.  It's based on the old Unix Kermit,
  8157. but a cursory inspection of the code suggests that he's simply added System
  8158. V support to it.  Can anyone verify that the present C-Kermit runs on the HP
  8159. Integral via "make sys3"?  If so, I'll simply include that system on the
  8160. list of those supported by C-Kermit; if not, I'll be glad to make Robert's
  8161. code available to anyone with an HP Integral who would like to adapt it to
  8162. the current C-Kermit.
  8163.  
  8164. ------------------------------
  8165.  
  8166. Date: Mon, 23 Sep 85 12:43:29 edt
  8167. From: Frank da Cruz <fdc@cucca>
  8168. Subject: Update of Fujitsu Micro-16s CP/M-86 Kermit
  8169.  
  8170. This fixes an error in baud rate setting/selection.  Submitted by the
  8171. original contributor, Chris Barker, WRIST Inc, Long Island City, NY.  The
  8172. source file is in KER:C86XFJ.A86.  Would anyone on the net would care to
  8173. build and test the result and supply a hex (.H86) file?
  8174.  
  8175. ------------------------------
  8176.  
  8177. Date: Sat 21 Sep 85 14:35:52-EDT
  8178. From: Bdale Garbee <AG0B@TE.CC.CMU.EDU>
  8179. Subject: Kermit for UUCP Mail
  8180.  
  8181. I haven't finished doing it yet, but I am one of the people using/planning
  8182. to user Kermit on a UUCP host to move mail to other places.
  8183.  
  8184. The system in question is an Intel 86/330 running Xenix V2.2N, currently
  8185. working on getting implementation-specific bugs out of the latest C-Kermit.
  8186. More details when I'm done.
  8187.  
  8188. The idea is very simple.  Just create a user on the Unix/Xenix system named
  8189. something like 'kserver'.  Then build a .login or .profile for that user in
  8190. that user's home directory that fires up kermit in server mode, and then
  8191. terminates the process and hangs up when kermit exits.  A remote machine
  8192.  
  8193. INFO-KERMIT DIGEST V3 #21                                              Page 149
  8194.  
  8195. that wants to do file transfer, either of UUCP mail or anything else, just
  8196. dials in, logs in as user kserver, and issues the appropriate kermit server
  8197. commands.  When done, he issues a server terminate command, which causes
  8198. Kermit on the Unix box to exit and kill the process... which should also
  8199. hang up the phone.
  8200.  
  8201. Using cron and shell scripts makes for easy packing and unpacking of bundles
  8202. of mail to/from the UUCP mail directory.  The remote system just has to have
  8203. a similar sort of batch facility to use to do the dialup.
  8204.  
  8205. Bob Hartman of ...!vaxine!spark!bob fame is using this technique to
  8206. implement a UUCP/Fidonet bridge.  I'm working on duplicating and then
  8207. expanding his work.  Will pass along details when it works, and would
  8208. be most interested in talking to other people who have this sort of
  8209. thing working, or want help on making it work...
  8210.  
  8211. Bdale Garbee
  8212. arpa: ag0b@cmu-cc-te.arpa, soon to be ag0b@te.cc.cmu.edu
  8213. uucp: ...allegra!pitt!rensys!bdale
  8214.  
  8215. [Ed. - Thanks for the news.  You may be interested in a customized Unix
  8216. Kermit server that they run at OK State as a login shell if you dial a
  8217. certain number -- have you been in touch with them...
  8218. vasoll%okstate.csnet@csnet-relay?  Of course, none of this addresses the
  8219. real questions of mail since (I assume) you're just sending mail in batch
  8220. mode and not control information in interactive messages, like SMTP would
  8221. do.  How do you handle the various situations that SMTP or UUCP would
  8222. handle, like bad routing information, can't connect to host, no such user,
  8223. etc etc?]
  8224.  
  8225. ------------------------------
  8226.  
  8227. Date: Mon, 23 Sep 85 14:06:51 pdt
  8228. From: Ken Poulton <hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA>
  8229. Subject: Changes to C-Kermit 4C(057)
  8230.  
  8231. [Ed. - Ken Poulton has submitted code for the following changes to C-Kermit.
  8232. Some of them are obviously desirable, some are in "sensitive" areas (where
  8233. opinions are divided); I'd like to solicit a concensus in these areas, if
  8234. possible.]
  8235.  
  8236. Fixes for HP 9000:
  8237.     added "make s500" which does the things formerly listed in the make file
  8238.     added code to disable HP's enq-ack handshaking (#ifdef IENQAK) in connect
  8239.  
  8240. Connect:
  8241.     changed use of XON/XOFF slightly (now it works like BSD, and better
  8242.     with HP terminals)
  8243.  
  8244. Set Handshake:
  8245.     now turns off XON/XOFF (-t already does this)
  8246.  
  8247. !
  8248.     merged ! and other uses of fork to call new routine zexecl in ckufio
  8249.     zexecl does an exec, using 1) the shell defined by environment variable
  8250.     SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
  8251.  
  8252. Page 150                                              INFO-KERMIT DIGEST V3 #21
  8253.  
  8254.     failing that, 3) /bin/sh.
  8255.  
  8256. [Ed. - I guess this is better than the current method, which ignores the
  8257. SHELL variable because some Unix systems do not set it automatically.]
  8258.  
  8259. control chars
  8260.     added conchr to ckutio and changes in ckucmd to support using the
  8261.     user's predefined control characters as he expects
  8262. [Ed. - Seems like a good idea, assuming the method used works for the
  8263. systems the program tries to support.  For Sys III/V, it does
  8264. ioctl(0,TCGETA,&x), and then sets the interrupt, character delete, and
  8265. line delete characters to x.c_cc[0], x.c_cc[2], and x.c_cc[3] respectively;
  8266. for all others it does gtty(0,&x) and ioctl(0,TIOCGETC,&y), and sets
  8267. interrupt, chardel, linedel to y.t_intrc, x.sg_erase, and x.sg_kill.  In
  8268. the first case, x is a struct termio; in the second, x is a struct sgttyb
  8269. and y is a struct tchars.  How many systems will this break?]
  8270.  
  8271.     added code for VENIX11 to turn off driver's recognition of these
  8272.     characters.  Most Unices (BSD, SysIII, etc) do this anyway in raw mode.
  8273.  
  8274. [Ed. - I've heard reports about this before, but never saw this behavior
  8275. in Pro/Venix, which I thought was the same.]
  8276.  
  8277. prompt
  8278.     settable with -DPROMPT=
  8279.  
  8280. startup files
  8281.     1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
  8282.     settable with -DKERMRC (as before) and -DSYS_KERMRC
  8283.     Note that order of first two is intentionally changed
  8284.  
  8285. [Ed. - This looks like a touchy one.  First, it might be argued that most
  8286. people would like the program to behave consistently, no matter what
  8287. directory you're connected to.  Second, if there is to be a "system-wide"
  8288. startup file, does everyone agree that it should be in /usr/local/lib?
  8289. Third, the program searches for the startup file as above, and executes the
  8290. first one it finds.  Maybe it should execute all of them?  If there is to
  8291. be a system startup file, should the program ALWAYS execute it?  Should
  8292. there be user-selectable options to specify the order in which startup files
  8293. are executed, and how many???  How to explain all this to users?]
  8294.  
  8295. eXIT command
  8296.     added eXIT command - allows leaving Kermit w/o unlocking or dropping line
  8297.     added ttnohu to close the tty w/o hangup
  8298.     creates ~/UNLOCKttyxx to remind user
  8299.     EXIT deleted to avoid confusion
  8300.     (maybe this should be disabled on BSD systems as not needed)
  8301.  
  8302. [Ed. - This is the most controversial area of all.  First of all, case-
  8303. sensitive commands are not in the spirit of Kermit.  Second, giving the
  8304. user the power to lock a line permanently might be fine on a small friendly
  8305. system, but not on a big one with many users.  The risk of a user leaving
  8306. a line locked (intentionally or not) is much higher with this method, and
  8307. the inconvenience to other users must be weighed against the advantages
  8308. of doing this.  Opinions?  (Here we go again...) ]
  8309.  
  8310.  
  8311. INFO-KERMIT DIGEST V3 #21                                              Page 151
  8312.  
  8313. scripts
  8314.     commented out most of the messages
  8315.     user can use echo to write messages if he *wants* to
  8316.  
  8317. [Ed. - Opinions from script command users?]
  8318.  
  8319. #
  8320.     added comment command
  8321.     for documenting scripts
  8322.     (done with % by 4C(057))
  8323.  
  8324. [Ed. - I used "%" for this to avoid confusion with shell scripts.]
  8325.  
  8326. locking
  8327.     now accepts existing lock files owned by the user (to support eXIT)
  8328.  
  8329. [Ed. - This is probably not a bad idea, when it works...  But some sites
  8330. keep the locks directory write-protected (or even read-protected), and
  8331. other sites want to run Kermit, UUCP, CU, TIP, etc, set[ug]id'd, so there's
  8332. no good way to tell for sure whose lock file it is.  I truly believe that
  8333. "lock files" are the WORST thing about Unix...  It continues to amaze me
  8334. that the system was designed NOT to give exclusive access by default to
  8335. serial devices automatically upon open().]
  8336.  
  8337. VOID
  8338.     defined to null for V7, "(void)" for all others to avoid all the
  8339.     V7 ifdefs
  8340.  
  8341. [Ed. - I thought I had removed all those (void)s; they were just there for
  8342. lint's benefit, but I guess a couple are still there (in ckutio.c and
  8343. ckuus3.c); they should go too.]
  8344.  
  8345. -g rfn -a name
  8346.     changed ckcfns.c to try treating "-a name" as a directory name
  8347.     bug: zopeno gives an err msg if the name is a directory
  8348. [Ed. - This is a little tricky, not sure it's worth it...]
  8349.  
  8350. logging
  8351.     added better debug and transaction messages to clsif and clsof in ckcfns.c
  8352. [Ed. - Good messages are always nice.]
  8353.  
  8354. get
  8355.     fixed to strip newline off of -a name in take script
  8356. [Ed. - Obviously desirable.]
  8357.  
  8358. ------------------------------
  8359.  
  8360. Date: Sat, 21 Sep 85 21:28:25 PST
  8361. From: !!tweten@AMES-NAS.ARPA
  8362. Subject: Bug Fix for C-Kermit User Interface
  8363.  
  8364. We just got a new giant Amdahl machine, running the System V flavor of UTS.
  8365. So far, its only connection to the world is through 9600 baud lines.
  8366. Needless to say, my first order of business was building C-Kermit on it,
  8367. followed by Compress, followed by most of my files (it also has mucho disk).
  8368. It went mostly OK, though the lintish feature of the UTS C compiler fussed a
  8369.  
  8370. Page 152                                              INFO-KERMIT DIGEST V3 #21
  8371.  
  8372. bit.  That's not the story for today, though.  While sending files to UTS, I
  8373. got fed up with Kermit's habit of double-spaceing between lines of dots.
  8374.  
  8375. I decided to fix it while waiting for the transfer.  The context diff below,
  8376. for ckuus3.c, is the result.  The problem arose from some confusion over
  8377. whether "p" was the position of the last character or of the next character
  8378. to go into the buffer.  I tried to make everything consistant.  My rules
  8379. were as follows: 1) "p" is the zero-based position of the next character to
  8380. be put on the line, 2) It is each message type's responsibility to determine
  8381. if there is enough space for it, and to leave "p" pointed at the next
  8382. available space when it is done.  I also parameterized the line length, and
  8383. set it to 79 for our C-Kermit, so terminals with linewrap won't.
  8384.  
  8385. [Ed. - diffs omitted, but will be included in next release.  Kermit was
  8386. also brought up recently on our own UTSV system, and worked ok, except for
  8387. some cosmetic problems with command echoing, which I think we can fix.]
  8388.  
  8389. ------------------------------
  8390.  
  8391. Date: 23 Sep 85 16:34:00 EDT
  8392. From: STEVE KABERLINE <kaberline@ford-vax>
  8393. Subject: C-Kermit on Masscomp Systems?
  8394.  
  8395. Can you tell me, please, who is/has been working on the Masscomp specific
  8396. implementation of Unix Kermit?  I have a few comments/suggestions I would
  8397. like to forward (A network address, if available, would be nice) to them.  I
  8398. recall, at one time, seeing a list on CU20B of who-is-doing-what as far as
  8399. Kermit work goes, is there still such a file I can ftp over and look at?
  8400.  
  8401. [Ed. - I've lost the specific reference, but have had reports that Masscomp
  8402. systems can run the current release of C-Kermit just fine, when built with
  8403. "make sys3".  Anyone know otherwise?]
  8404.  
  8405. ------------------------------
  8406.  
  8407. Date: Fri 20 Sep 85 21:39:02-EDT
  8408. From: Andy R Raffman <EN4.AR-RAFFMAN@CU20A>
  8409. Subject: Problem with Sanyo 555 Kermit
  8410.  
  8411. I thought that I should tell you that I have tried the new Kermit 2.28 for
  8412. the Sanyo 555, and it has a bug: the backspace key does not move the cursor
  8413. back or erase the previous character in command mode.  Given that many of
  8414. the other improvements in Kermit haven't helped the Sanyo version much (no
  8415. H-19 or VT-100 emulation, no set key, no mode line), unless you have fixed
  8416. some larger bugs in v.2.26 (I know that the log function doesn't work right),
  8417. you might consider going back to it until the backspace bug is fixed.
  8418.  
  8419. [Ed. - If any Sanyo users out there have a fix for this, please let us know.]
  8420.  
  8421. ------------------------------
  8422.  
  8423. Date: Mon, 23 Sep 85 23:48:58 PDT
  8424. From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA
  8425. Subject: MsKermit Linking Idea
  8426.  
  8427. The following is the relevant part of a response in our local electronic
  8428.  
  8429. INFO-KERMIT DIGEST V3 #21                                              Page 153
  8430.  
  8431. conference (*Forum) which I think may be of interest to part of the Kermit
  8432. community.
  8433.  
  8434. 2723. MTS Kermit Now Available
  8435.       Bruce Jolliffe          16:23 Mon Aug 13/84
  8436.  
  8437. 2723/60. CORRIE KOST          21:16 Mon Sep 23/85      12 lines
  8438.  
  8439.    I would like to suggest that all versions of KERMIT be linked
  8440.    with Microsoft's LINK version 3.XX, so that they can be packed
  8441.    with Microsoft's EXEPACK utility.  This procedure can cut the
  8442.    size of the .EXE file by up to 50 %, and the .EXE file is still
  8443.    directly runnable from MS-DOS (...and it loads faster, too)
  8444.    Note that EXEPACK will produce garbage (no warning !) if you
  8445.    try to pack a file linked with LINK version 2.XX, or the
  8446.    default IBM-PC linker supplied with PC-DOS 3.0 and PS-DOS 3.1
  8447.  
  8448.                                   - Ya'akov
  8449.  
  8450. [Ed. - Does anyone know if a thus-packed file can be run transparently
  8451. under earlier versions of DOS?  Also what would the expected savings be
  8452. on a program like MS-Kermit 2.28, which has got rid of most of its static
  8453. buffers and does memory allocation at runtime?  Any other pitfalls to be
  8454. wary of?]
  8455.  
  8456. ------------------------------
  8457.  
  8458. End of Info-Kermit Digest
  8459.  
  8460. Page 154                                              INFO-KERMIT DIGEST V3 #22
  8461.  
  8462. Info-Kermit Digest         Mon, 7 Oct 1985       Volume 3 : Number 22
  8463.  
  8464. Departments:
  8465.  
  8466.   MISCELLANY -
  8467.     Half-Duplex Windowing vs Long Buffers
  8468.     Use of Kermit by the Blind (Several Messages)
  8469.     Hint for VMS Binary File Transfer using Kermit
  8470.  
  8471.   UNIX KERMIT -
  8472.     Ken Poulton's C-Kermit Changes (Several Messages)
  8473.     C-Kermit Works on HP Integral Kermit
  8474.     C-Kermit EOF Bug
  8475.     C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
  8476.     Masscomp Kermit
  8477.     TI NU Machine Kermit
  8478.     Bug in C-Kermit Remote Commands under VAX/VMS
  8479.  
  8480. ----------------------------------------------------------------------
  8481.  
  8482. Date: Thu, 3 Oct 85 19:35 EDT
  8483. From: RAF@UMDC.BITNET
  8484. Subject: Half-Duplex Windowing vs Long Buffers
  8485.  
  8486. Is everyone agreed that in half-duplex windowing, the EOL character should
  8487. not be sent until the end of a group of packets?  If an EOL character is
  8488. sent after each packet, my 370 TSO and WYLBUR systems will require some
  8489. delay before the next packet is sent.  Otherwise following packets will be
  8490. lost.  Also, if a packet received in error results in a parity error (likely,
  8491. but not certain), the resulting error message from the system will cause
  8492. the following packet to be obliterated also.  For my systems, I think it is
  8493. best not to send an EOL until the end of a group of packets.
  8494.  
  8495. However, if the EOL is not sent until the end of a group, there is another
  8496. problem which may be common to systems that check incoming parity.  Since
  8497. the whole group of packets is considered to be one "line" by the system,
  8498. an error in any packet that also results in a parity error (highly likely,
  8499. although not guaranteed), will cause the entire line (group of packets)
  8500. to be discarded.  Thus the half duplex windowing scheme results in extra
  8501. overhead for multiple packets per "line" with little corresponding benefit
  8502. in reduced retransmission when compared to the big packet proposal.
  8503.  
  8504. Therefore I prefer big buffers to half-duplex windowing.
  8505.  
  8506.  
  8507.                                  Roger Fajman <RAF@UMDC.BITNET>
  8508.                                  Computer Center
  8509.                                  National Institutes of Health
  8510.  
  8511. [Ed. - Last chance to get your comments in...  The tide of opinion seems to
  8512. be favoring long packets, distinct from sliding windows.]
  8513.  
  8514. ------------------------------
  8515.  
  8516. Date: Tue 1 Oct 85 14:17:51-EDT
  8517. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  8518.  
  8519. INFO-KERMIT DIGEST V3 #22                                              Page 155
  8520.  
  8521. Subject: Use of Kermit by the Blind
  8522. To: Info-Kermit@CU20B.ARPA
  8523. cc: Info-IBMPC@USC-ISIB.ARPA, Info-Micro@BRL-VGR.ARPA
  8524.  
  8525. I've had a call from Kenneth Reed at NASA in Greenbelt, MD (phone 301-344-8414)
  8526. asking how Kermit can be used effectively by blind people.  Back in the days
  8527. when computers had terminals, you could put a device like a Votrax or DECtalk
  8528. or whatever between the terminal and the computer, and it could try to speak
  8529. the letters and numbers, or words, as they went by.  But microcomputers don't
  8530. generally have a place to attach such a device.  Kenneth says his Apple II
  8531. has a special card that somehow gets characters just before they're about to
  8532. be put on the screen and presumably can transmit them to a speaking device,
  8533. but that's just for the Apple.
  8534.  
  8535. I'm sure there has been a lot of discussion about this elsewhere, but I must
  8536. have missed it.  How can blind people use microcomputer applications in
  8537. general?  Obviously, graphics-oriented stuff is mostly out (and therefore,
  8538. presumably, also the Macintosh).  In MS-DOS, maybe there are console drivers
  8539. that can intercept characters, strip out (or interpret) formatting information,
  8540. and send the text out the serial port to, say, a Votrax, or maybe there are IBM
  8541. PC boards that "speak the screen" directly.  Anyhow, Kenneth's department is
  8542. selecting microcomputers and he'd like to see them pick one that text oriented
  8543. applications (like Kermit) can be adapted to give comprehensible audible
  8544. output.  If you have any information, please post it and also give Kenneth a
  8545. call at the number listed.
  8546.  
  8547. By the way, the way the Kermit file transfer display is done is important here.
  8548. On MS-DOS systems, a "form" is put up on the screen at the beginning of the
  8549. file transfer, and then numbers and messages are filled in and updated
  8550. randomly throughout.  If one were to read this stuff in sequence as it appeared
  8551. on the screen, it would be a pretty confusing jumble.  Also, you'd need a
  8552. pretty fast talker at high baud rates...  The serial output of local-mode Unix
  8553. Kermit or DEC-20 Kermit would be a lot more comprehensible when interpreted
  8554. by a voice device.
  8555.  
  8556. ------------------------------
  8557.  
  8558. Date: Wed, 2 Oct 85 06:21:51 MDT
  8559. From: halff@utah-cs.arpa (Henry M. Halff)
  8560. Subject: Re: Use of Kermit by the Blind
  8561. References: <1835@brl-tgr.ARPA>
  8562.  
  8563. Let me suggest that your friend contact the following firm.
  8564.  
  8565.     Talking Computers, Inc.
  8566.     6931 North 27th Road
  8567.     Arlington, VA 22213
  8568.     703-241-8224
  8569.  
  8570. The fellow that runs the firm is Doug Wakefield.  His business is putting
  8571. speech synthesizers on computers for blind people.  He pretty much specializes
  8572. in IBM PC's, but he might be able to help with Apples.  The software that he
  8573. uses should have no problem with a screen display like Kermit's since the
  8574. user can, at any time, get a readout of the entire screen or any line
  8575. on the screen.
  8576.  
  8577.  
  8578. Page 156                                              INFO-KERMIT DIGEST V3 #22
  8579.  
  8580. Hope this helps.
  8581.  
  8582. Henry M. Halff
  8583. Halff Resources, Inc.
  8584. halff@utah-cs.ARPA
  8585.  
  8586. ------------------------------
  8587.  
  8588. Date: Sat, 5 Oct 85 10:28:24 mst
  8589. From: Kelvin Nilsen <kelvin%arizona.csnet@CSNET-RELAY.ARPA>
  8590. Subject: Kermit for the Blind
  8591.  
  8592. [Ed. - This is from the author & proprietor of VersaCom, a communication
  8593. program that includes Kermit.]
  8594.  
  8595. versacom does not run windows!  all i/o to the terminal is serialized through
  8596. the bios, write tty (except of course when it comes to terminal emulation).
  8597. this makes it possible to run versacom on a pc from a terminal and connect
  8598. to another system to transfer files.  for example:
  8599.  
  8600.  
  8601.       vt100                   dumb tty emulation
  8602.     +-------------+             +---------+            +----------+
  8603.     |home terminal|- 1200 baud -|office pc|-19200 baud-|office vax|
  8604.     +-------------+             +---------+            +----------+
  8605.  
  8606. xon/xoff handshaking is supported on both ports, in both directions and works
  8607. independently.  the amount of information reported by file transfers can be
  8608. each packet, or each file transfered.
  8609.  
  8610. anyway, this capability makes possible two solutions to the problem you
  8611. mentioned.  first, attach a votrax-type terminal to one of the com ports
  8612. of the pc.  second, modify versacom to send bios tty output to an internal
  8613. voice synthesizer instead of or in addition to the bios tty output.
  8614.  
  8615. kelvin nilsen
  8616.  
  8617. ------------------------------
  8618.  
  8619. DATE: October 07, 1985 11:29:44 EDT
  8620. FROM: NUNNALLY%VPIVM1.BITNET@WISCVM.ARPA
  8621. SUBJECT: TERMINAL FOR THE BLIND
  8622.  
  8623. WE ARE TRYING SEVERAL DIFFERENT PRODUCTS FOR THE BLIND HERE AT VA. TECH
  8624. ONE IS A PACKAGE ON THE IBM PC CALL ED FREEDOM. VERY NICE PACKAGE.
  8625. WORKS OUTSIDE OF ALMOST ANY OTHER PACKAGE ON THE PC. WE USE THE TERM
  8626. EMULATOR YTERM WITH IT NO PROBLEMS.
  8627. WE ALSO USE THE AUDIOTRONICS TALKING KEYBOARD FOR THE PC. HAVING SOME
  8628. SPEED INTERFACE PROBLEMS. QUESTIONS CALL 703-961 5961.
  8629.  
  8630. ------------------------------
  8631.  
  8632. Date:  5 Oct 1985 1454-PDT (Saturday)
  8633. From: randy@uw-bluechip.arpa (William Randy Day)
  8634. Subject: Re: Use of Kermit by the Blind
  8635.  
  8636.  
  8637. INFO-KERMIT DIGEST V3 #22                                              Page 157
  8638.  
  8639. I am part of a research project here at the University of Washington aimed
  8640. at developing software for deaf-blind (both deaf and blind) users.  The
  8641. presentation problem is severe. As you say, graphics-oriented software is
  8642. out.  As you describe in you posting, even ``non-graphics'' programs like
  8643. kermit can prove incomprehensible if a straight screen output to speech
  8644. translation is made. We have come to the conclusion that a simple
  8645. hardware/software translation unit sitting on top of normal software is
  8646. inadequate, particularly for our severely handicapped target group. We have
  8647. taken the custom software approach.
  8648.  
  8649. Randy Day.
  8650. UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy
  8651. ARPA: randy@washington
  8652. CSNET: randy%washington@csnet-relay
  8653.  
  8654. ------------------------------
  8655.  
  8656. Date: 3 Oct 85 17:20:20 GMT
  8657. From: walton%Deimos@CIT-HAMLET.ARPA
  8658. Subject: Hint for VMS Binary File Transfer using Kermit
  8659.  
  8660. If one has two VMS Vaxes connected together with RS-232 ports, binary files
  8661. will transfer OK, using 8-bit data.  The catch is that Kermit cannot possibly
  8662. be taught about all of the wild and wonderful RMS file formats (how many are
  8663. there?  1.0e10?), so making a BACKUP set (which contains the RMS formats) and
  8664. transferring it via Kermit will work fine.  Do a SET FILE TYPE FIXED in the
  8665. Kermits at both ends.  This allows .EXE files to be transferred directly, and
  8666. BACKUP save sets to be transferred and read from after fixing up the block
  8667. size.
  8668.  
  8669. ------------------------------
  8670.  
  8671. Date: Wed, 25 Sep 85 11:38:25 pdt
  8672. From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA
  8673. Subject: More Kermit Changes Comments
  8674.  
  8675. > -g rfn -a name
  8676. >     changed ckcfns.c to try treating "-a name" as a directory name
  8677. >         bug: zopeno gives an err msg if the name is a directory,
  8678. >                  even though it works.
  8679. > [Ed. - This is a little tricky, not sure it's worth it...]
  8680.  
  8681. It is consistent with other file transfer facilities such as uucp (and I
  8682. *needed* it for that reason).  The code *is* a bit messy because I didn't dare
  8683. change the machine-dependent primitives like zopeno (I can't write or test new
  8684. VMS or Mac versions).  I think adding an argument to zopeno will allow having
  8685. it do this operation (if appropriate for that opsys).
  8686.  
  8687. > eXIT command
  8688. >
  8689. > [Ed. - This is the most controversial area of all.  First of all, case-
  8690. > sensitive commands are not in the spirit of Kermit.  Second, giving the
  8691.  
  8692. The typed command is 'x' or 'xit'.
  8693.  
  8694. This is sometimes an essential feature, but not always desirable.  How about
  8695.  
  8696. Page 158                                              INFO-KERMIT DIGEST V3 #22
  8697.  
  8698. making this feature depend on a compile-time ifdef?  Then the system manager
  8699. can control the use of this as appropriate.
  8700.  
  8701. Ken Poulton
  8702.  
  8703. ------------------------------
  8704.  
  8705. Date: Tue, 24 Sep 85 18:43:32 pdt
  8706. From: "Scott Weikart; Community Data Processing" <cdp!scott@glacier>
  8707. Subject: Info-Kermit Digest V3 #21: Ken Poulton reactions
  8708.  
  8709. Here's my reactions to Ken Poulton's changes.
  8710.  
  8711. > !
  8712. >    merged ! and other uses of fork to call new routine zexecl in ckufio
  8713. >    zexecl does an exec, using 1) the shell defined by environment variable
  8714. >    SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
  8715. >    failing that, 3) /bin/sh.
  8716.  
  8717. I like it.
  8718.  
  8719. > control chars
  8720. >     added conchr to ckutio and changes in ckucmd to support using the
  8721. >     user's predefined control characters as he expects
  8722.  
  8723. I like it, for those systems that support it (and leave ^W as backward
  8724. delete word on SYSIII, etc).
  8725.  
  8726. > startup files
  8727. >     1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
  8728. >     settable with -DKERMRC (as before) and -DSYS_KERMRC
  8729. >     Note that order of first two is intentionally changed
  8730.  
  8731. I would like to have two system files, kermrc.1st and kermrc.lst.
  8732. .1st would be done first, then a user's (if any) would be done (i.e. either
  8733. 1) or 2) above), then .lst.  Basically, I want both defaults and mandatory
  8734. values, and this seems to be the only way to do it.
  8735.  
  8736. I think /etc might be a better place for the system-wide files, like
  8737. /etc/profile and /etc/cshprofile.
  8738.  
  8739. I'm not sure I like 1); it seems like a take file in the appropriate
  8740. directory would be safer.
  8741.  
  8742. > eXIT command
  8743. >     added eXIT command - allows leaving Kermit w/o unlocking or dropping line
  8744. >     added ttnohu to close the tty w/o hangup
  8745. >     creates ~/UNLOCKttyxx to remind user
  8746. >     EXIT deleted to avoid confusion
  8747. >     (maybe this should be disabled on BSD systems as not needed)
  8748.  
  8749. I don't like it.  I still think that pushing a subshell is the only reasonable
  8750. way to do it, with /usr/spool/uucp group accessible and kermit setgid (as I
  8751. described at length a while back).  Of course, I can't bitch too much since
  8752. I'm not offering to implement it.
  8753.  
  8754.  
  8755. INFO-KERMIT DIGEST V3 #22                                              Page 159
  8756.  
  8757. > #
  8758. >     added comment command
  8759. >     for documenting scripts
  8760. >     (done with % by 4C(057))
  8761. >
  8762. > [Ed. - I used "%" for this to avoid confusion with shell scripts.]
  8763.  
  8764. But I'd *rather* have it be like shell scripts; my Emacs already assumes
  8765. that files with no or unknown extionsions use # as comment, and most
  8766. UNIX types will recognize # as comment.  And I doubt that a kermit
  8767. script will often look like a shell script.
  8768.  
  8769. > locking
  8770. >     now accepts existing lock files owned by the user (to support eXIT)
  8771.  
  8772. This seems good as long as it doesn't break when files or directories
  8773. or unreadable.  At least some people could have it right.
  8774.  
  8775. ------------------------------
  8776.  
  8777. Date: Thu Sep 26 1985 17:55:58
  8778. From: Marco Papa <papa%usc-cse.csnet@CSNET-RELAY.ARPA>
  8779. Subject: Comments on C-Kermit new features
  8780.  
  8781. These are my comments about the possible additional features or chhanges to
  8782. current features of C-Kermit.
  8783.  
  8784. 1. SHELL stuff.  OK.
  8785.  
  8786. 2. Control chars. OK.
  8787.  
  8788. 3. Startup files. BAD!!! Much better like it is now.
  8789.  
  8790. 3. Exit command.  BAD too!! I do not like case sensitivity, but much more
  8791. important I do not want users to leave locked lines around. There is really
  8792. no real advantage, and the risks are enormous.
  8793.  
  8794. 4. Scripts with no echo. OK. In fact I hate to have my login script to show
  8795. right on the monitor the password I am using to login on another system.
  8796. Logging transactions is enough.  After one has found the correct login
  8797. sequence there is absolutely no need to show it everytime.
  8798.  
  8799. 5. comment command for shell scripts.  OK together with 4.
  8800.  
  8801. 6. locking. It won't work in most systems.  System managers are becoming
  8802. more restrictive in letting users create locks owned by them.
  8803.  
  8804.  
  8805. Marco Papa
  8806. USC - Computer Science Dept.
  8807.  
  8808. UUCP:  ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!papa
  8809. CSNET: papa@usc-cse.csnet
  8810. ARPA:  papa%usc-cse@csnet-relay.arpa
  8811.  
  8812. ------------------------------
  8813.  
  8814. Page 160                                              INFO-KERMIT DIGEST V3 #22
  8815.  
  8816.  
  8817. Date: Wed, 25 Sep 85 10:43:58 pdt
  8818. From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA
  8819. Subject: Use of '%' and '#' in Scripts
  8820.  
  8821. On the use of '%' or '#' for comments in scripts:
  8822.  
  8823. *Many* Unix programs allow '#' to introduce comments, not just shells.
  8824.  
  8825. In addition, some Unix systems allow "#! program" at the beginning of a file
  8826. to indicate that that file is a script for 'program' and should be executed
  8827. as such.  This is usually used for csh scripts ("#! /bin/csh") but would
  8828. allow one to write executable kermit scripts by writing
  8829.  
  8830.     #!/usr/local/bin/kermit
  8831.  
  8832. at the head of the file.  Then (on systems which support this) one need only
  8833. type the script's filename to execute it with kermit.
  8834.  
  8835. Ken
  8836.  
  8837. ------------------------------
  8838.  
  8839. Date: 25 Sep 85 09:22:11 EDT
  8840. From: GH0N@CMU-CC-TC
  8841. Subject: C-Kermit Works on HP Integral Kermit
  8842.  
  8843. This is in regard to whether C-Kermit 4C runs on the HP Integral.  I have
  8844. gotten C-Kermit to run on the Integral with very little trouble.  Make sys3
  8845. does get the job done, but you need to either remove the code that sets up
  8846. lock files, or have the lock files put in a directory that is guaranteed
  8847. to be there (such as /tmp).  Another thing that crops up is that the C
  8848. compiler for the Integral has a bug in it (at least the version I have does)
  8849. that will cause it to report the sizeof() an array as being 0.  Sizeof() on
  8850. lone variables and structures (including structures containing arrays) work
  8851. fine.  The biggest hassle with making C-Kermit for the Integral is the fact
  8852. that you can't use make if you don't have either LOTS of memory or a hard
  8853. disk.  To compile and link all the code takes about an hour.
  8854.  
  8855.     Hope this helps.
  8856.  
  8857. Gordon Haverland
  8858. GH0N % CMU-CC-TC @ Carnegie    Mailnet }
  8859. GH0N @ CMU-CC-TC        BITnet  } soon to be GH0N.TC.CC.CMU.EDU ?
  8860. ...!cmu-cs-pt!cmu-cc-tc!gh0n    uucp?
  8861.  
  8862. ------------------------------
  8863.  
  8864. Date: Tue, 1 Oct 85 11:31:06 -0100
  8865. From: mcvax!philmds!duvel!frans@seismo.css.gov
  8866. Subject: C-Kermit EOF Bug
  8867.  
  8868. I've encountered a bug in C-Kermit v57.
  8869.  
  8870. The bug is that in ckcpro.c (and .w) a test is done on the return value of
  8871. reof.  However reof() does *never* return a value.  This makes ckcpro.c barf
  8872.  
  8873. INFO-KERMIT DIGEST V3 #22                                              Page 161
  8874.  
  8875. sometimes that a file cannot be closed, but evidently there is no problem at
  8876. all.  By the way reof() is declared in ckcfns.c. I could not find other
  8877. calls except for the one in ckcpro.c
  8878.  
  8879.     Frans Meulenbroeks, Philips Microprocessor Development Systems
  8880.            ...!{seismo|philabs|decvax}!mcvax!philmds!frans
  8881.  
  8882. [Ed. - Right you are -- reof() should return the value that was returned to
  8883. it by clsof(), indicating whether the file was closed successfully or not.
  8884. Will be fixed in next release; noted in "beware file" till then.]
  8885.  
  8886. ------------------------------
  8887.  
  8888. Date: Thu, 3 Oct 85 11:07:42 PDT
  8889. From: brian@sdcsvax.arpa (Brian Kantor)
  8890. Subject: C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
  8891.  
  8892. The routine 'unchar' in ckcker.h has a name conflict with the unsigned
  8893. character typedef included from sys/types.h.  Changing it to 'myunchar'
  8894. permits Kermit to compile.
  8895.  
  8896.     Brian Kantor    UC San Diego
  8897.  
  8898.     decvax\     brian@ucsd.arpa
  8899.     akgua  >---  sdcsvax  --- brian
  8900.     ucbvax/        Kantor@Nosc
  8901.  
  8902. [Ed. - Thanks, will change this in the next release, and note it in the beware
  8903. file until then.]
  8904.  
  8905. ------------------------------
  8906.  
  8907. Date: Sat, 5 Oct 85 02:19:30 CDT
  8908. From: Stan Barber <neuro1!sob@rice.ARPA>
  8909. Subject: Masscomp Kermit
  8910.  
  8911. I submitted an version of 4.2 C-Kermit to the Masscomp Users Group that had
  8912. line-locking that would work (I hope) for most environments.  I have not had a
  8913. chance to get the most recent release of 4C to add those features to it that
  8914. deal with the line-locking problem effectively.
  8915.  
  8916. make sys3 does just fine, if line-locking is not an issue. If it is, then my
  8917. mods would probably satisfy most.  It is fortunate that the new version of UUCP
  8918. (BSD 4.3) supports a read/write by the world LCK directory to remove the need
  8919. for setuid programs.
  8920.  
  8921. I will be making the 4C version work on masscomp sometime soon, but 4.2 seems
  8922. to work for most people even with the bugs it has.
  8923.  
  8924. I will be happy to field any comments on the masscomp users group version.
  8925.  
  8926. Stan Barber
  8927. Baylor College of Medicine
  8928. sob@rice.edu
  8929. ihnp4!shell!neuro1!sob
  8930.  
  8931.  
  8932. Page 162                                              INFO-KERMIT DIGEST V3 #22
  8933.  
  8934. ------------------------------
  8935.  
  8936. Date: 20-Sep-85 14:33:10EDT
  8937. From: "KENNETH POOLE" <poole@nusc-ada>
  8938. Subject: NU-Machine Unix Kermit
  8939.  
  8940. I have done a simple mod of 4c(57) of the unix kermit for the NU-machine
  8941. unix from TI.  This Unix is the one on the LMI Lambda-Plus machines.
  8942. Please indicate how you would like me to send you the mods for adding
  8943. to the main source.  I modified ckutio,ckufio and ckuker.mak.  Also,
  8944. please add my name to the list for the info-kermit digest.  I was on
  8945. before, but we lost our arpanet software fo a while and i think i was
  8946. taken off the list.  Thanks,
  8947.             Ken Poole  849-6270
  8948.  
  8949. [Ed. - I tried to respond to this message, but couldn't seem to push a
  8950. message through.  Ken, please send me context diffs...]
  8951.  
  8952. ------------------------------
  8953.  
  8954. Date: Thu, 26 Sep 85 15:21:32 GMT
  8955. From: John Rainbow Messenger <jlm@uucp.stl>
  8956. Via: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  8957. Subject: Bug in C-Kermit Remote Commands under VAX/VMS
  8958.  
  8959. We have found a bug in the remote command execution code for the VMS version
  8960. of C-Kermit.  The symptom was a complete failure to execute remote commands,
  8961. with a message of the form %F - Can't delete file (for instance).
  8962. The enclosed fix enables remote commands to be executed.
  8963.  
  8964. The patch is a context diff, and can be installed with the patch command.
  8965.  
  8966. [Ed. - Patch omitted, but listed in KER:CKVKER.BWR on CU20B.]
  8967.  
  8968. ------------------------------
  8969.  
  8970. End of Info-Kermit Digest
  8971.  
  8972. INFO-KERMIT DIGEST V3 #23                                              Page 163
  8973.  
  8974. Info-Kermit Digest         Tue,  8 Oct 1985       Volume 3 : Number 23
  8975.  
  8976. Departments:
  8977.                     New BOO-file Maker for MS-DOS
  8978.           Further Problem with MS-DOS Kermit 2.28 GET Command
  8979.                     About MS Kermit and EXEPACK...
  8980.    Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC
  8981.                MS-DOS Kermit vs "Desk Accessory" Clocks
  8982.              How to Build Z100 MS-DOS Kermit from Source?
  8983.                        Terminals for the Blind
  8984.                    The Claimed C-Kermit Bug for VMS
  8985.           Four-Table ASCII/EBCDIC System for EBCDIC Kermits
  8986.            Request for Osborne and Kaypro Kermit Diskettes
  8987.                         MacKermit TAC Problem
  8988.                   Re: Kermit 1.7 Loses at 1200 Baud
  8989.                         Kermit for Wang 2200?
  8990.                        Kermit for DG Machines?
  8991.                          Kermit for CDS 4000?
  8992.  
  8993. ----------------------------------------------------------------------
  8994.  
  8995. Date: Thu 26 Sep 85 11:39:58-EDT
  8996. From: Frank da Cruz <SY.FDC@CU20B.ARPA>
  8997. Subject: New BOO-file Maker for MS-DOS
  8998.  
  8999. Alan Phillips at Lancaster University (UK) added Lattice C support to
  9000. MSMKBO.C, so that now MS-DOS Kermit .BOO files can be made directly on the
  9001. PC.  The new version replaces the old one, as KER:MSMKBOO.C on CU20B.
  9002.  
  9003. If you don't know what a .BOO file is, it's yet-another-printable-encoding
  9004. for binary files, the format that we distribute MS-DOS Kermit binaries in.
  9005. It features 4-for-3 encoding and 0-compression so that the resulting .BOO
  9006. file is often shorter than the original .EXE.
  9007.  
  9008. ------------------------------
  9009.  
  9010. Date: 24 Sep 1985 2221-EDT
  9011. From: Stephen H. Owades, c/o EIBEN@DEC-MARLBORO
  9012. Subject: Further Problem with MS-DOS Kermit 2.28 GET Command
  9013.  
  9014. I have had some problems with MS-DOS Kermit 2.28 on my IBM PC/AT, as I
  9015. described in a mail message some weeks ago.  I downloaded the MSKERM.BWR
  9016. file, which offered a solution to the faulty file-name truncation (in
  9017. multi-file GETs) problem.  I made the suggested changes, reassembled and
  9018. relinked, and tested the resulting program.  Apparently no truncation
  9019. whatever is performed on a GET; DOS truncates the file name passed to it by
  9020. KERMIT.  This does eliminate the problem of badly truncated file names
  9021. (wherein KERMIT was doing something bizarre to the name of the first
  9022. incoming file), but it has created a new, perhaps worse, fault.  Now
  9023. collisions (incoming file name the same as a file name already presen are
  9024. only detected when the incoming file name is valid under DOS; if the
  9025. incoming file name is longer than XXXXXXXX.XXX, KERMIT doesn't know there is
  9026. a conflict and the system hangs.  I had to reboot my AT!  Collisions are
  9027. detected and avoided with the "0-1-2-..." naming method described in
  9028. MSKERM.DOC if the incoming file name is valid under DOS--evidently KERMIT
  9029. doesn't realize that there is a collision when the incoming file name was
  9030.  
  9031. Page 164                                              INFO-KERMIT DIGEST V3 #23
  9032.  
  9033. truncated by DOS.
  9034.  
  9035. Stephen H. Owades
  9036.  
  9037. ------------------------------
  9038.  
  9039. Date: 27 Sep 1985 0912-EDT
  9040. From: LCG.KERMIT
  9041. Subject: About MS Kermit and EXEPACK...
  9042.  
  9043. I have used EXEPACK on MS Kermit 2.26 through 2.28 and it produces workable
  9044. code (note I relink from source). In the 2.27 and older versions the .EXE
  9045. file went from 80+ K to around 36K.  In V2.28 however the savings was minimal
  9046. (10% if I recall right).  Thus EXEPACK is of marginal use with V2.28.  Can't
  9047. say much about backward compatibility; it looks OK on PCDOS V2.0 on, but
  9048. could break some compatibles.  Since MSDOS Link V3.XX is not commonly
  9049. available I believe its a mistake to use it in distribution; people should
  9050. be able to recreate the distributed .EXE via source with more common tools...
  9051.  
  9052. Glenn Everhart
  9053.  
  9054. ------------------------------
  9055.  
  9056. Date:  2 Oct 1985 1152-PDT
  9057. From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
  9058. Subject: Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC
  9059.  
  9060. I normally use Kermit through COMM1 on my IBM-PC. I was trying it on a
  9061. Leading Edge PC last night which was configured to communicate through COM2.
  9062. It wouldn't send commands to the modem.
  9063.  
  9064. The Status command indicated that 1200 baud was illegal [even though we could
  9065. use PC-TalkIII to dial out on COM2].
  9066.  
  9067. I could not get Kermit to accept any baud rate (e.g., 110, 300, 1200) as
  9068. legal for COM2.  That is, the Status command indicated an error at any baud
  9069. rate when I set the port to COM2, but it would accept 1200 baud on COM1.
  9070.  
  9071. When I came home, I tried setting Kermit to use COM2 on my IBMPC at home.
  9072. I have only one serial port on this machine, but tried to set COM2 as the
  9073. active port. I received the same error messages re inappropriate baud rate
  9074. ["Baud rate not recognized" or equivalent message].
  9075.  
  9076. I couldn't find any information in the Kermit 2.28 manual to help me decide
  9077. where the problem might lie.
  9078.  
  9079. 1. What may be the problem?
  9080.  
  9081. 2. Do you know if anyone has tried to use MSKermit on one of the new leading
  9082. Edge D machines?
  9083.  
  9084. Thanks
  9085.  
  9086. Rob Kling
  9087. UC-Irvine
  9088.  
  9089.  
  9090. INFO-KERMIT DIGEST V3 #23                                              Page 165
  9091.  
  9092. [Ed. - I'm pretty sure you can set the baud rate on COM2, as many people at
  9093. Columbia have two serial ports and use both.  If the second serial board isn't
  9094. there, the status command would not be able to figure out the baud rate, since
  9095. reading the (non-existent) baud rate status port would return something
  9096. meaningless.  I don't know anything about the Leading Edge machines, but it
  9097. sounds like they're another 'almost' compatible, at least in terms of the
  9098. second serial port.  Does anyone out there know something about Leading Edge?]
  9099.  
  9100. ------------------------------
  9101.  
  9102. Date: Mon, 7 Oct 85 10:21:49 PDT
  9103. From: walton%Deimos@CIT-Hamlet.ARPA
  9104. Subject: MS-DOS Kermit vs "Desk Accessory" Clocks
  9105.  
  9106. Any program which accesses the IBM PC timer interrupt to place a real-time
  9107. clock on the screen seems to put a real strain on Kermit.  Continuous-update
  9108. programs basically trash Kermit.  I have a shareware program called Deskmate
  9109. on my PC right now, which updates the time on the screen every 10 seconds or
  9110. so.  It still badly interferes with Kermit.  I don't want to have to reboot
  9111. my system in order to use Kermit effectively.
  9112.  
  9113. Does anyone have a solution to this problem, or is it inherent in the IBM PC
  9114. architecture?
  9115.  
  9116.                     Steve Walton
  9117.                     Caltech Solar Astronomy
  9118.                     walton@citdeimo.bitnet
  9119.                     walton%deimos@cit-hamlet.arpa
  9120.                     ...!psuvax1!walton@citdeimo.bitnet
  9121.  
  9122. [Ed. - Thanks for the report; I've noted it in the "beware" file.  There may
  9123. be a way to get two or more programs that use timers to coexist, we'll have
  9124. to look into it.]
  9125.  
  9126. ------------------------------
  9127.  
  9128. Date: Mon 7 Oct 85 13:20:34-MDT
  9129. From: Dick Dysart <RDYSART@SIMTEL20.ARPA>
  9130. Subject: How to Build Z100 MS-DOS Kermit from Source?
  9131.  
  9132. I have downloaded the MS*.ASM files for Kermit for the Z-100, 13 of them..
  9133. I have run them thru MASM , each with no errors from MASM..(not sure if or
  9134. what I should modify for MY machine)..
  9135.  
  9136. Then when I LINK them, the linker responds -> I/O run error in EXE, and
  9137. aborts without creating the .EXE file...
  9138.  
  9139. I thought that I should try from the beginning as my Besterm still won't work
  9140. properly, and MAYBE a version of Kermit compiled on MY machine would work..
  9141.  
  9142. With the LINKER aborting this way, and I cant find that error message in the
  9143. MS-DOS manual as yet, I don't know what's wrong, nore do I have any idea
  9144. what to fix..
  9145.  
  9146. Any help would be appreciated......................Dick
  9147.  
  9148.  
  9149. Page 166                                              INFO-KERMIT DIGEST V3 #23
  9150.  
  9151. [Ed. - Can anybody who has experience with MS-DOS Kermit on the Z100 offer
  9152. any help?]
  9153.  
  9154. ------------------------------
  9155.  
  9156. Date: Mon, 7 Oct 85 20:31:19 EDT
  9157. From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
  9158. Subject: Terminals for the Blind
  9159.  
  9160. I don't know why nobody seems to be mentioning the VersaBraille (another
  9161. company makes a similar device).  I used to have a blind programmer working
  9162. for me, and we tried various talking terminals, optical scanners, and so
  9163. forth.  Her conclusion was that the VersaBraille (with communications
  9164. software cassette) was much easier and faster, although for graphics (yes!)
  9165. she resorted to an optical scanner (sorry, I forget the trade name).
  9166.  
  9167. This topic really seems orthogonal to KERMIT, other than to the extent to
  9168. which it points out the silliness of fancy user interfaces in what was
  9169. supposed to be a file transfer program.
  9170.  
  9171. [Ed. - So true.  By the way, I can't find any other forum for discussion
  9172. of these issues in the "list of lists", so I don't mind if the topic
  9173. continues in Info-Kermit for a while.]
  9174.  
  9175. ------------------------------
  9176.  
  9177. Date: Mon 7 Oct 85 21:47:01-EDT
  9178. From: Jin Au Kong <F.KONG%MIT-EECS@MIT-MC.ARPA>
  9179. Subject: The Claimed C-Kermit Bug for VMS
  9180.  
  9181. The problem with "! XXX" in VMS is related to the BYTLM in user authorization
  9182. file, as we discovered soon after we installed C-kermit on our system.   For
  9183. VMS to create a subprocess, the BYTLM must exceed 4096 (which is our previous
  9184. setting), and of course, PRCLM must be at least 1.  I don't know the exact
  9185. minimum for BYTLM, but after we set it to 6144, it worked.
  9186.  
  9187. But note that the created subprocess will not be stopped after you get out
  9188. from Kermit.  Hope somebody can fix the problem.
  9189.  
  9190. [Ed. - Thanks, noted in the CKVKER.BWR file.  Does this mean that the
  9191. previous report is wrong and that no change needs to be made to the code,
  9192. or that both are necessary?  Anybody want to contribute "installation
  9193. instructions" for C-Kermit under VMS, and/or a review of its usefulness?]
  9194.  
  9195. ------------------------------
  9196.  
  9197. Date: Sat, 27 Jul 85 15:55 PDT
  9198. From: IVA3GET@UCLAMVS.BITNET
  9199. Subject: Four-Table ASCII/EBCDIC System for EBCDIC Kermits
  9200.  
  9201. [Ed. - This message was recently excavated and is now belatedly published.
  9202. It was apparently provoked by the new ASCII/EBCDIC translation feature of
  9203. VM/CMS Kermit v2.]
  9204.  
  9205. The two ATOE's and two ETOA's would differ in the following way.
  9206.  
  9207.  
  9208. INFO-KERMIT DIGEST V3 #23                                              Page 167
  9209.  
  9210. First let us denote the system tables ATOE0 and ETOA0.  We will construct
  9211. ETOA1 to be the left inverse of ATOE0, i.e. for every printable ASCII
  9212. character x, ETOA1(ATOE0(x)) = x.  Similarly, we will construct ATOE1 to be
  9213. the right inverse of ETOA0, i.e. for every printable ASCII character x,
  9214. ETOA0(ATOE1(x)) = x.  The -1 tables are used to postmap incoming packets
  9215. back to ASCII and to premap outgoing packets out of ASCII.  They form an
  9216. outer layer to Kermit so it can analyze and build packets in ASCII.  If the
  9217. -0 system tables are nonstandard, then the -1 will be too.  Note that the
  9218. right inverse may not be unique and that either inverse may fail to exist.
  9219.  
  9220. The other function of translation tables is to map text messages back and
  9221. forth between ASCII and EBCDIC as packets are analyzed and synthesized.
  9222. Call these ETOA2 and ATOE2.  Ideally these should be based on the "standard"
  9223. in the IBM System 370 Reference Summary or the Appendix of the Kermit User's
  9224. Manual, and thus would differ from the -1 tables in the nonstandard
  9225. situation.  Currently, -1 tables do double duty as they perform the text
  9226. message translation function as well.  The result is various distortions in
  9227. text as it is transmitted to and from EBCDIC systems, including undesirable
  9228. substitutions and swallowing of characters.  In a four-table system as I
  9229. have outlined, these distortions would not occur.
  9230.  
  9231. What is left is to state mathematically the conditions under which the
  9232. -1 tables can be constucted, and to present the appropriate algorithms.
  9233.  
  9234. . ETOA1 exists iff ATOE0 is 1-1 (unambiguous) on the printable set.
  9235.  
  9236. . ATOE1 exists iff the range of ETOA contains the printable set.
  9237.  
  9238. With standard tables, these questions do not arise since in this case
  9239. the system tables are both left and right inverses of each other.
  9240.  
  9241. This is all I have time for now.  Hopefully, I can sketch the algorithms
  9242. later.  I ran into the problem of distorted characters at UCLA where TSO
  9243. Kermit has recently been installed with modified translation tables.  I
  9244. wanted to download Kermit-MS in the .BOO format as well as the Basic program
  9245. to decode it.  I noticed that the tilde (or degree sign) was getting
  9246. swallowed and that the backslash was being blanked out.  It would have been
  9247. easy enough to hand patch the Basic, but hardly the .BOO file.  I hope I
  9248. have convinced you that there is a problem.
  9249.  
  9250. Ciao -
  9251.  
  9252. Glenn Thobe
  9253. iva3get@uclamvs and vss7853@uclavm (bitnet)
  9254.  
  9255. [Ed. - Given the number of calls I get every day from IBM mainframe sites
  9256. who have "customized" their translate tables, I don't need convincing that
  9257. there's a problem.  But I'm not sure I understand how a 4-table system will
  9258. necessarily solve it.  Your level 1 tables that invert the system's tables
  9259. will only work if the system's tables are already unique and invertible --
  9260. in many cases they are not.  If 2 different printable ASCII characters are
  9261. mapped by the system to the same EBCDIC character, then the even the low
  9262. level stuff won't work -- some packets will be perceived has having wrong
  9263. checksums.  In such cases, the only solution is to fix the system's tables.]
  9264.  
  9265. ------------------------------
  9266.  
  9267. Page 168                                              INFO-KERMIT DIGEST V3 #23
  9268.  
  9269.  
  9270. Date: Wed, 25 Sep 85 13:10:12 PDT
  9271. From: spacerad@JPL-VLSI.ARPA
  9272. Subject: Request for Osborne and Kaypro Kermit Diskettes
  9273. To: info-kermit@cu20b.arpa
  9274.  
  9275. I have been in touch with Frank da Cruz regarding our local (Los Angeles
  9276. area) Osborne club acting as a distribution house for Osborne and Kaypro
  9277. Kermit diskettes and documentation. the details are all worked out, but
  9278. I do require copies on disk of latest versions and doc or library files
  9279. for these programs.  I would also like to obtain a copy of the Kermit
  9280. User Guide.
  9281.  
  9282. Anyone who can assist in this matter may reply directly to this message or
  9283. contact me also via:
  9284.  
  9285.                        1) dantas@jpl-vlsi.arpa
  9286.  
  9287.                        2) BOB DANTAS
  9288.                           % JET PROPULSION LAB
  9289.                           4800 OAK GROVE DRIVE
  9290.                           MAIL SLOT T-LL
  9291.                           MAIL SLOT T-1180 (CORRECT ONE)
  9292.                           PASADENA, CALIF.  91109
  9293.  
  9294.                        3) (818)354-4932
  9295.  
  9296. [Ed. - I'll send a User Guide.  Could someone who has Kermit on Kaypro or
  9297. Osborne diskette please send in a copy?  Thanks!]
  9298.  
  9299. ------------------------------
  9300.  
  9301. Date: Tue 1 Oct 85 09:07:52-PDT
  9302. From: Steve Dennett <DENNETT@SRI-NIC.ARPA>
  9303. Subject: MacKermit TAC Problem
  9304.  
  9305. The NIC has gotten several calls lately from users having trouble getting
  9306. Macintosh Kermit to work through a TAC.  I've tried doing file transfers
  9307. and have been equally unsuccessful.  The odd thing is that it's a one-way
  9308. problem.
  9309.  
  9310. Going through a TAC, files can be downloaded from host to Mac without
  9311. difficulty.  But when uploading, MacKermit sends three packets then
  9312. starts re-trying until it finally times out.
  9313.  
  9314. I've read the general information about using Kermit through a TAC and
  9315. have successfully moved files in both directions through a TAC using the
  9316. IBM PC version of Kermit, so the problem is something specific to MacKermit.
  9317. Also, I've tried all the different TAC twiddles (BIS/BOS, flow control,
  9318. varying packet sizes, etc.) but no combination seems to make a difference.
  9319.  
  9320. The version of MacKermit I'm using is .8(33) July 1985.  Since you're listed
  9321. as one of the authors, I hope you can help.  With the growing number of net
  9322. users and the popularity of the Mac, this question is certain to come up
  9323. with increasing frequency.
  9324.  
  9325.  
  9326. INFO-KERMIT DIGEST V3 #23                                              Page 169
  9327.  
  9328. Thanks for your help.
  9329.  
  9330. Steve Dennett  (  dennett@sri-nic.arpa  )
  9331. DDN Network Information Center
  9332.  
  9333. [Ed. - Well...  You've got the latest version of Mac Kermit, so that's not
  9334. the problem.  I've never used a TAC personally, so all my information is
  9335. second hand.  @B I S/@B O S makes the TAC transparent, so once you've done
  9336. that, you should be able to rule out any interference by XON/XOFF (which the
  9337. Mac doesn't do anyway), atsigns, etc.  The fact that you can download files
  9338. to the Mac seems to confirm this.  Therefore, I'd look again at the TAC's
  9339. buffers.  If there's a way to make them bigger, do that.  If not, you've got
  9340. to get the Mac to send shorter packets; to do this, tell BOTH Kermits to
  9341. reduce their packet sizes.  What may be happening is that the effect of
  9342. commands like "set send packet-length" might be the opposite of what you
  9343. expect -- some Kermits take this to mean that you want to override whatever
  9344. the other Kermit asks for, and while others do the opposite.  Let me know
  9345. how it works.  If you still have problems, find out as much as you can from
  9346. the two Kermits involved -- note all the current communications and protocol
  9347. settings, get debug and/or packet logs if possible.]
  9348.  
  9349. ------------------------------
  9350.  
  9351. Date: Wed 2 Oct 85 21:30:17-EDT
  9352. From: Robert S. Lenoil <LENOIL@MIT-XX.ARPA>
  9353. To: prindle@NADC.ARPA
  9354. cc: info-kermit@CU20B.COLUMBIA.EDU, lavitsky@RED.RUTGERS.EDU
  9355. Subject: Re: Kermit 1.7 Loses at 1200 Baud
  9356.  
  9357. I tried your suggested fix of setting the RS-232 registers to 8 so that my
  9358. modem could autobaud correctly, and then resetting them to zero.  This worked
  9359. in that my modem did autobaud correctly and go into high-speed mode.  However,
  9360. when I reset the rs-232 regs to zero, the host could no longer understand me.
  9361. Of course, if I left the registers at 8, I dropped characters.  The symptoms
  9362. are this: my transmit data light goes on, but the host does not return any
  9363. character (I am in full duplex).  After restarting with Kermit 1.5 (what I'm
  9364. using now), I saw that the DEC-20 was receiving nothing but back-quotes ("`").
  9365. I've rejected the possibility that my download went poorly, since I used
  9366. Kermit, and because the hex file has its own checksums.  Again, my modem is a
  9367. ProModem 1200, by Prometheus.  Has anyone else seen this behavior exhibited?
  9368.  
  9369. ------------------------------
  9370.  
  9371. Date: Wednesday, 18 September 1985  17:43-MDT
  9372. From: pjohnson@sdcsvax.ARPA (Paul Johnson)
  9373. Subject: Kermit for Wang 2200?
  9374.  
  9375. Does anybody have the source for Kermit on a Wang 2200?
  9376.  
  9377. paul johnson
  9378. {akgua,allegra,dcdwest,decvax,ihnp4,helios,ucbvax}!sdcsvax!pjohnson
  9379.  
  9380. [Ed. - To my knowledge, no Kermit program exists for any Wang systems other
  9381. than the PC, and no one is working on any.  Does anybody know something to
  9382. the contrary?]
  9383.  
  9384.  
  9385. Page 170                                              INFO-KERMIT DIGEST V3 #23
  9386.  
  9387. ------------------------------
  9388.  
  9389. Date: 26 Sep 1985 1331-EDT
  9390. From: LSM.DUNCAN at DEC-MARLBORO.ARPA
  9391. Subject: Kermit for DG Machines?
  9392.  
  9393. Is there ayone who could provide a copy of a Data General Kermit for an
  9394. MV4000 system in binary form?  We have a system with no compilers and a
  9395. cartridge tape.  Alternatively, is there a way to get a binary version
  9396. from a system so it could be downloaded with a 'crude' transfer program?
  9397.  
  9398.   Thanks,
  9399.      Jeff Duncan (lsm.duncan@dec-marlboro)
  9400.  
  9401. ------------------------------
  9402.  
  9403. Date: 2 Oct 85 22:13:21 EDT
  9404. From: Steven Christensen <SC1K@CMU-CC-TE>
  9405. Subject: Kermit for CDS 4000?
  9406.  
  9407. Is anyone working on a Kermit for ComputerVision's CDS-4000 computer?  It's
  9408. basically a FORTRAN generic machine, with some strange idiosyncronicities.
  9409.  
  9410.     Steven Christensen
  9411.     Phone: (513) 752-4595
  9412.     Address: 728 Stuart Lane  Cincinnati, Oh  45245
  9413.  
  9414. ------------------------------
  9415.  
  9416. End of Info-Kermit Digest
  9417.  
  9418. INFO-KERMIT DIGEST V3 #24                                              Page 171
  9419.  
  9420. Info-Kermit Digest         Thu, 17 Oct 1985       Volume 3 : Number 24
  9421.  
  9422. Today's Topics:
  9423.  
  9424.                MS-DOS Kermit for the DECmate II and III
  9425.                Crosstalk XVI 3.6 Kermit Implementation
  9426.          Kermit Throughput Problems with "Smart" Multiplexer
  9427.                           MacKermit and TACs
  9428.                         VMS Kermit 3.1.066 Bug
  9429.                      Re: VMS C Kermit problem...
  9430.                 Commodore-64 Kermit 1.7 1200 Baud Fix
  9431.                    CP/M Kermit on a Remote Machine
  9432.      File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?
  9433.           File Transfer Between VAX And IBM PC Through LAN ?
  9434.          Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)
  9435.                          MS DOS Kermit vs DTR
  9436.                   Kermit for 1750A, MOS, or Jovial?
  9437.  
  9438. ----------------------------------------------------------------------
  9439.  
  9440. Date: Thu, 17 Oct 85 10:02:47 EDT
  9441. From: Frank da Cruz <SY.FDC@CU20B>
  9442. Subject: MS-DOS Kermit for the DECmate II and III
  9443.  
  9444. An implementation of MS-DOS Kermit 2.28 (the current release) is now
  9445. available for the DECmate-II and III with the XPU (MS-DOS) option, from an
  9446. anonymous donor at DEC.  The files are in KER:MSDM2.BOO (printably encoded
  9447. .EXE file, use KER:MSPCTRAN.BAS or KER:MSPCBOO.BAS to decode it, if indeed
  9448. DECmate MS-DOS has a Microsoft-like Basic), KER:MSDMII.BAT (for building from
  9449. source), KER:MSXDM2.ASM (system-dependent source module), and KB:MSDM2.EXE
  9450. (8-bit binary).  No documentation is available, but it is said to work, and
  9451. to use the DM-II/III's built-in VT100/200 firmware for terminal emulation.
  9452.  
  9453. ------------------------------
  9454.  
  9455. Date: Wed, 9 Oct 85 08:57:06 cdt
  9456. From: blake@astro.utexas.edu (R. Blake Farenthold)
  9457. Kermit: Kermit on The Source
  9458.  
  9459. The Source (a commercial time sharing service) has just set up their
  9460. SIGS (Special interest groups) containing discussions & downloads for
  9461. people with various interests.  Aside from straight ASCII up and down
  9462. loads they offer Kermit transfers.
  9463.  
  9464. A couple of days ago I sent a 110K file to the Source using Kermit. At
  9465. 1200 baud this should have taken about 15 minutes. IT TOOK OVER AN
  9466. HOUR!  Is Kermit that inefficent, is it horribly hampered when using
  9467. a packet switching network (I used Telenet), or has The Source slowed
  9468. things way down so they can collect more per-minute connect time!
  9469.  
  9470. In otherwords who do I yell at?
  9471.  
  9472. Blake Farenthold      |    CIS: 70070,521   |  UUCP: {ut-sally,ut-ngp,noao}
  9473. P.O. Box 3027         | Source: TCX023      |        !utastro!blake
  9474. Austin, TX 78764-3027 | Delphi: blake       |  Intr: blake@astro.UTEXAS.EDU
  9475. BBS: 512-442-1116     |    MCI: BFARENTHOLD |   ESL: 62806548
  9476.  
  9477. Page 172                                              INFO-KERMIT DIGEST V3 #24
  9478.  
  9479.  
  9480. [Ed. - The people at The Source are well aware of the problem, which is
  9481. twofold: (a) TELENET, and the Prime computer itself (which is what you are
  9482. talking to) provide only 7-bit channels, so you incur the overhead of
  9483. 8th-bit prefixing for binary files, and (b) any packet-switched wide-area
  9484. public network like TELENET has its own built-in delays, which, due to the
  9485. stop-and-wait nature of the Kermit protocol in its present form, will tend
  9486. to dominate any file transfer over TELENET.  To cope with these problems,
  9487. The Source has proposed (in Info-Kermit v3 #7, with discussion in following
  9488. issues) a sliding window protocol to allow multiple packets to be sent back
  9489. to back, which can result in a dramatic performance improvement under these
  9490. conditions.  Prototype programs are running now, and should be announced
  9491. before the end of the year.  By the way, don't complain too much -- most
  9492. other protocols don't work in this environment at all!]
  9493.  
  9494. ------------------------------
  9495.  
  9496. Date: Wed, 16 Oct 85 20:02:47 EDT
  9497. From: RAF@UMDC
  9498. Subject:  Crosstalk XVI 3.6 Kermit Implementation
  9499.  
  9500. I just received a copy of Crosstalk XVI 3.6, which includes KERMIT support.
  9501. I gave it a quick try and encountered two problems.  One is that when I send
  9502. a text file from the PC to my TSO KERMIT, Crosstalk does not stop at the
  9503. Control-Z.  Thus I get a Control-Z plus some additional garbage at the end
  9504. of the file.  Microstuf customer support confirms that there is no way to
  9505. get Crosstalk to stop at the Control-Z.  Since Control-Z for end of file is
  9506. a PC convention, it seems to me that Crosstalk should support it.  Customer
  9507. support said they would pass the suggestion on for consideration.
  9508.  
  9509. The other problem is much more minor: after a Crosstalk KERMIT LIST command
  9510. is done to list KERMIT protocol options, everything put on the screen after
  9511. that is in high intensity.
  9512.  
  9513. Roger Fajman  <RAF@UMDC>
  9514. National Institutes of Health
  9515.  
  9516. ------------------------------
  9517.  
  9518. DATE: 16-OCT-1985
  9519. FROM: BRIAN@UOFT02.BITNET
  9520. SUBJECT: Kermit Throughput Problems with "Smart" Multiplexer
  9521.  
  9522. A note to those of you who support a Kermit implementation on odd modems and
  9523. muxes:
  9524.  
  9525. I recently had a call from a Kermit-11 user who found that a download from
  9526. the host to the RT11 system for a given file took 2 minutes, whereas the
  9527. upload of the same file to the host took 14 minutes.  Solution: the mux they
  9528. were using severely downgrades the uplink bandwidth in an ill conceived
  9529. attempt to improve the host to local link bandwidth.  From what I have seen
  9530. recently in the various trade rags, this seems to be an approach that some
  9531. vendors are trying out.  Beware...
  9532.  
  9533. brian
  9534.  
  9535.  
  9536. INFO-KERMIT DIGEST V3 #24                                              Page 173
  9537.  
  9538. [Ed. - One of the hardest problems Kermit or any similar protocol has to
  9539. cope with is that so much communication equipment is designed under the
  9540. assumption that input from a "terminal" will only be human keystrokes.
  9541. Another example follows...]
  9542.  
  9543. ------------------------------
  9544.  
  9545. Date: Thu, 10 Oct 85 21:35:27 EDT
  9546. From: Dave Swindell <dswindel@BBN-LABS-B.ARPA>
  9547. Subject: MacKermit and TACs
  9548.  
  9549. I've found that you have to explicitly set the send-packet length to
  9550. something less than 64 when uploading data from ANY PC over a TAC.  The TAC
  9551. input buffer just isn't big enough to handle the 90 (or is it 94?) character
  9552. default send-packet size used by MacKermit.  As was mentioned in the digest,
  9553. you also have to use the TAC commands @ B O S and @ B I S (in that order) to
  9554. allow the Kermit protocol to function correctly over a TAC.
  9555.  
  9556. Dave Swindell
  9557. BBN Laboratories
  9558.  
  9559. ------------------------------
  9560.  
  9561. Date: Tue 8 Oct 85 16:15:54-EDT
  9562. From: Michael Fuchs <EXT1.FUCHS@CU20B.ARPA>
  9563. Subject: VMS Kermit 3.1.066 Bug
  9564.  
  9565. I don't know if 3.1.066 is state-of-the-art, but it can't handle CRCs and
  9566. 8bit data simultaneously in server mode.  One can't set the micro to CRC and
  9567. send a binary file to the VAX unless one explicitly makes the micro
  9568. *request* 8-bit-prefixing.  CRC works fine with non-8bit-files, and 8bit
  9569. files can be sent micro to VAX with Checksum error detection.
  9570.  
  9571. The VAX puts a "3" in the appropriate place in the init packet.  Then, if
  9572. the data packet has bytes with the eighth bit high, it sends NAK packets
  9573. back to the micro.  (Indeed, the NAK packets correctly have CRCs.)  The only
  9574. way to use CRC error detection is to also have the micro request
  9575. 8-bit-quoting (if one is sending 8bit data to the VAX).
  9576.  
  9577. ------------------------------
  9578.  
  9579. From: Ivan Auger <augeri%rpics.csnet@CSNET-RELAY.ARPA>
  9580. To: info-kermit <@csnet-relay.arpa:info-kermit@cu20b.columbia.edu>
  9581. Subject: Re: VMS C Kermit problem...
  9582.  
  9583. There is a default mailbox buffer size on any VMS system (mailboxes are used
  9584. for process communication).  You can have kermit set the size of mailboxes,
  9585. change the defaulf mailbox size, or you can indeed increase BYTLM quotas.
  9586. (By theway on our system you can do a SET HOST with a BYTLMC quota of 4096).
  9587. Ivan Auger, NYS Dept. of Health.
  9588.  
  9589. ------------------------------
  9590.  
  9591. Date: Tue 8 Oct 85 17:20:07-EDT
  9592. From: Robert Lenoil <LENOIL%MIT-EECS@MIT-MC.ARPA>
  9593. Subject: Commodore-64 Kermit 1.7 1200 Baud Fix
  9594.  
  9595. Page 174                                              INFO-KERMIT DIGEST V3 #24
  9596.  
  9597.  
  9598. You must download the .INI file as a SEQ file. The proper parameters for the
  9599. kludge baud rates are contained in that file. 1200 baud will not work without
  9600. it.  That was the problem.  There is no way (from within Kermit) to set the
  9601. optional baud rate parameters in the .INI file, so you better download
  9602. KERMIT.INI properly, or 1200 baud won't work.  As as alternative, you might
  9603. wish to create KERMIT.INI with this small program:
  9604.  
  9605. 10 open 8,8,8,"0:kermit.ini,s,w"
  9606. 20 for i=1 to 45 : read b : print#1,chr$(b); : next
  9607. 30 close 8
  9608. 40 data 25,1,0,0,0,0,1,0,5,0,1,0,1,1,0,0,0,60,1,56,0,38,38,0,0,0,0,13,10,8,10
  9609. 50 data 93,93,4,0,35,0,0,0,0,0,0,0,0,0
  9610.  
  9611. ------------------------------
  9612.  
  9613. Date: Thu, 10 Oct 85 17:37:27 edt
  9614. From: Mike Ciaraldi  <ciaraldi@rochester.arpa>
  9615. Subject: CP/M Kermit on a Remote Machine
  9616.  
  9617. I sent this before, but I think it got lost:
  9618.  
  9619. Is there any way to run CP/M Kermit as the "remote" kermit rather than the
  9620. "local" kermit?  e.g. Suppose you had a computer bulletin board system
  9621. running under CP/M, and you wanted to use Kermit to upload and download
  9622. files.  You would use the Kermit on your own micro to call the BBS, and
  9623. could then run Kermit on the remote machine.  But when you told the remote
  9624. Kermit to, say, SEND, it would try to send the data out some communication
  9625. port, and would send only the status reports about the transfer to the
  9626. console (which is REALLY the modem ultimately connected to your local
  9627. machine).  Even if you use Generic Kermit and have it communicate with the
  9628. TTY or CRT device, it will still be sending both file data and the status
  9629. reports to the same device.  I know the IBM PC version has a flag you can
  9630. set to disable displaying the status, and the mainframe versions of Kermit
  9631. must be able to tell when to send status reports to the console and when not
  9632. to (by looking at the SET LINE perhaps?), but I couldn't find anything like
  9633. this in the CP/M Kermit 4.05 manual.
  9634.  
  9635. Thanks for your help.
  9636.  
  9637. Mike Ciaraldi
  9638. ciaraldi@rochester
  9639. seismo!rochester!ciaraldi
  9640.  
  9641. [Ed. - For now, there's no way to do this.  I've been forwarding messages
  9642. regarding CP/M-80 Kermit to the current maintainer, Charles Carvalho
  9643. (CHARLES@ACC), but haven't had a response in months.  Charles, are you
  9644. there???]
  9645.  
  9646. ------------------------------
  9647.  
  9648. Date: 11 Oct 85 02:14:56 GMT
  9649. From: wei@princeton.UUCP (P Wei)
  9650. Subject: File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?
  9651.  
  9652. We have vax running UNIX 4.2BSD , ckermit program, modem (/dev/tty18), vcu
  9653.  
  9654. INFO-KERMIT DIGEST V3 #24                                              Page 175
  9655.  
  9656. (to use modem).  The ibm3081 also has cmskermit program.  the question is:
  9657. is it possible to transfer ascii file between this two system via that
  9658. modem?  I tried to use vcu to connect to ibm3081, but when I type 'kermit'
  9659. in CMS , I got 'an ascii terminal must be used' error message.  Even if i
  9660. didn't get that message, I couldn't get (escape) back to vax to invoke
  9661. ckermit because vcu doesn't allow me to 'escape'.  Then I tried to use
  9662. 'kermit -l /dev/tty18 -b 1200'. The phone line was connected. However, when
  9663. ibm ask my terminal type, whatever I answer it warned me to check parity
  9664. etc...  I don't have time to go through further. I would like to ask if any
  9665. one knows my intention (file transfer) is possible.  If anyone has
  9666. experience, would you please mail me some sample session (as detail as
  9667. possible)? (e.g. the parameter settings...)  thanks a lot !
  9668.  
  9669. HP Wei
  9670.  
  9671. [Ed. - It is entirely possible to use Kermit to transfer ASCII text as well as
  9672. binary files between a 4.2BSD VAX and an IBM 370-Series mainframe running
  9673. VM/CMS.  Very briefly, here's how:
  9674.  
  9675. If you have a Series/1 style front end (7171, 4994, etc) running the Yale
  9676. ASCII package, you must also have version 2.00 or later of CMS Kermit on the
  9677. IBM mainframe (if you don't, you'll get the "An ASCII terminal must be used"
  9678. message.  If you're going through some other kind of 3270 protocol emulator,
  9679. then you can't use Kermit.  If you're going through a 3705-style front end
  9680. as an ordinary line mode TTY, you can use any version of CMS Kermit.
  9681.  
  9682. You should have version 4C(057) of C-Kermit on the Unix system -- certain
  9683. earlier versions had bugs that might have prevented them from working with
  9684. IBM mainframes.  To C-Kermit you should give the following commands if you're
  9685. coming in as a line-mode TTY:
  9686.  
  9687. set duplex half    (half duplex = local echo)
  9688. set flow none      (no full duplex xon/xoff flow control)
  9689. set handshake xon  (use half duplex line turnaround handshake)
  9690. set parity mark    (use whatever parity your IBM system expects)
  9691.  
  9692. or else the following commands if you're coming in through a Series/1 style
  9693. front end:
  9694.  
  9695. set parity even    (or whatever)
  9696.  
  9697. And of course you must also include whatever "set" commands are necessary
  9698. to set up the communication line ("set line", "set modem", "set baud", etc).
  9699.  
  9700. If all this seems a little strange, you can blame the IBM style of data
  9701. communications, which is different from everyone else's. ]
  9702.  
  9703. -----------------------------
  9704.  
  9705. Date: 11 Oct 85 04:49:02 GMT
  9706. From: wei@princeton.UUCP (P Wei)
  9707. Subject: File Transfer Between VAX And IBM PC Through LAN ?
  9708.  
  9709. We have several ibmpc's connected to ETHERNET LAN with the communication
  9710. program 'yterm'. I can connect the ibmpc to the vax (running UNIX 4.2) using
  9711. yterm. Therefore , the ibmpc serve as a terminal for the vax.  Now , I escape
  9712.  
  9713. Page 176                                              INFO-KERMIT DIGEST V3 #24
  9714.  
  9715. the yterm program to DOS and invoke MSKERMIT and then type 'connect'. I get
  9716. back to the unix shell. CKERMIT is then invoked.  Then type 'send filename
  9717. <CR>'; escape (^]C) back to MSKERMIT ; type 'receive <CR>'. However, there is
  9718. no packet coming in. The screen just display 'transfer in progress......'
  9719. message forever!
  9720.  
  9721. (1) Am I totally wrong ? The kermit doesn't work on LAN ??? (only on tel
  9722.     line ? )
  9723. (2) Or I forgot to set some parameters ??? Can someone mail me sample session
  9724.     if same attempt has been done?
  9725.  
  9726. Thanks in advance.
  9727. HP Wei
  9728.  
  9729. [Ed. - Kermit can indeed be used over LANs, so long as the PC's connection to
  9730. the LAN looks like a serial communication port to the PC.  This would seem to
  9731. the case in HP Wei's query, since a terminal connection can be made.
  9732.  
  9733. In general, when the Kermit CONNECT command works but file transfer does not,
  9734. the culprit is usually (a) parity, (b) flow control, (c) packet size, or
  9735. (d) interference:
  9736.  
  9737. (a) Check to see if your LAN terminal interfaces are using some kind of parity
  9738. and if so, tell BOTH Kermit programs about it, using the SET PARITY command.
  9739.  
  9740. (b) It is command for LAN terminal interfaces to want to do xon/xoff flow
  9741. control with the PC.  Make sure you PC is set up for this (MS-DOS Kermit
  9742. does this by default in most cases).  If some other kind of flow control is
  9743. required (like RTS/CTS) you could be in for trouble.
  9744.  
  9745. (c) Some LAN terminal interfaces have small buffers and can't accept a normal
  9746. Kermit packet (90-95 characters) at 9600 baud.  Try using SET SEND/RECEIVE
  9747. PACKET-LENGTH for smaller packets, or else reducing the baud rate.
  9748.  
  9749. (c) Some LAN terminal interfaces intercept a certain character for control
  9750. purposes.  If this is a printable character, a Control-A, or a carriage return,
  9751. then this will prevent Kermit file transfers from taking place.  In this case,
  9752. try to find out how to change the box's intercept character to a control
  9753. character other than ^A or CR.  If the ^A or the CR are at fault, you can use
  9754. Kermit's SET START and/or SET END to change these.  If it's a printable
  9755. character, and it can't be changed in the LAN box, you're out of luck.]
  9756.  
  9757. ------------------------------
  9758.  
  9759. Date: Sunday, 13 October 1985  06:56-MDT
  9760. From: Gijs Mos <gijs%ark.uucp@BRL.ARPA>
  9761. Subject: Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)
  9762.  
  9763. I want to get some files from our Victor 9000 computers to various other
  9764. machines. The best program to use seems to be kermit. The problem is how to get
  9765. Kermit running on the Victor.  I have a recent kermit distribution with a
  9766. V9000-CP/M 86 kermit on it. But I don't have an assembler, nor a way to get the
  9767. sources on the Victor 9000's disks.  So I guess I'm looking for a kermit CP/M
  9768. 86 executable in Victor 9000 format.  Can somebody provide such a beasty at
  9769. media/handling costs?
  9770.  
  9771.  
  9772. INFO-KERMIT DIGEST V3 #24                                              Page 177
  9773.  
  9774. Gijs Mos
  9775. Dept. of Biology
  9776. Free University
  9777. De Boelelaan 1087
  9778. 1081 HV  Amsterdam
  9779. The Netherlands
  9780. {seismo,philabs,decvax}!mcvax!vu44!gijs
  9781.  
  9782. ------------------------------
  9783.  
  9784. Date: 14-OCT-1985 11:41
  9785. From: Heather Holmback <IWTS@HNYKUN52.BITNET>
  9786. To: Problems with MS-DOS Victor Kermit
  9787.  
  9788. We have been unsuccessful in using Kermit for a connection between a VICTOR
  9789. PC with operating system MS-DOS and the VAX, at the Max-Planck-Institut for
  9790. Psycholinguistics in Nijmegen, The Netherlands.  We are using Sirius version
  9791. 1.20 by Barry Devlin, University College Dublin, April 1984, translated by
  9792. SIREXE.BAS (by Daphne Tzoar, CUCCA).  Could you please send information on
  9793. any later versions of Kermit or any recent solutions to problems.  Our main
  9794. problem is that only one file can be successfully uploaded without exiting
  9795. and reloading Kermit.  Also MSKERMIT.INI does not work as indicated in the
  9796. documentation.  Thanks.
  9797.  
  9798. [Ed. - Unfortunately, this is still the latest version of MS-DOS Victor/Sirius
  9799. Kermit.  No one has ever taken the trouble to write an MSXSIR.ASM module so
  9800. that Victor support would be included automatically in new MS-DOS Kermit
  9801. releases.  Any volunteers?]
  9802.  
  9803. ------------------------------
  9804.  
  9805. Date: Wed, 16 Oct 85 19:11:05 CDT
  9806. From: <uwmacc!uwmcsd1!u1100u!os1100!Mark=Zinzow@rsch.wisc.edu>
  9807. Subject: MS DOS Kermit vs DTR
  9808.  
  9809. MS DOS Kermit leaves the modem signal DTR high upon exit.  This is useful
  9810. if a person wishes to exit kermit and then resume an online session, however
  9811. there are times when it is useful to drop DTR when running Kermit or when
  9812. finished with Kermit.  For instance some modems will answer the phone only
  9813. when DTR is high, so you might want to drop DTR after a Kermit session so
  9814. that YOU can answer the phone rather than your modem.
  9815.  
  9816. On our campus a great many of our computers are linked together by a Gandalf
  9817. PACX communications switch.  Our switch polls all ports not in use that have
  9818. DTR high.  Since we have hundreds of micro's hard-wired to the switch, if
  9819. they keep DTR high when the switch has no active connection on that port to
  9820. a given system, they bog down the polling and after a short period produce
  9821. copious timeout error messages on the switch console.  For this reason it is
  9822. important that our users drop DTR when finished with a session.
  9823. Furthermore, on some lines it is impossible to reconect or change systems
  9824. without dropping DTR first.
  9825.  
  9826. Ideally, it would be nice to have another SET parameter called DTR or DTR-
  9827. EXIT or DTR-QUIT or DROP-DTR that could be set ON or OFF so that when Kermit
  9828. is terminated it would dictate what state DTR would be left in.  It would
  9829. also be nice to just have a command like RESET COMx or DROP-DTR COMx.
  9830.  
  9831. Page 178                                              INFO-KERMIT DIGEST V3 #24
  9832.  
  9833.  
  9834. In lieu of this facility in Kermit I have written a short COM program
  9835. which I call OFFCOM1.COM or OFF.COM for short.  The commands to create this
  9836. 8 byte COM file follow.  I suggest typing them in without the comments
  9837. (things beggining with a semicolon).
  9838.  
  9839. DEBUG OFFCOM1.COM
  9840. A
  9841. ; PROGRAM OFFCOM1
  9842. ;       by Mark Zinzow
  9843. ;
  9844. ; Provides an external DOS command to clear
  9845. ; the serial port.
  9846. ; This has been tested on a Zenith Z150 running MS Dos 2.11 and an
  9847. ; IBM PC AT running PC Dos 3.1.
  9848. ; Note that this program is hardcoded for the address of the RS232 port.
  9849. ; A better way would be to use an offset on the base address normally
  9850. ; found in memory at location 40H:0.
  9851. ;
  9852.     MOV DX,3FC   ; Port address for serial modem register.
  9853.                  ; (Use 2FC for com2 rather than com1)
  9854.     MOV AL,0     ; Store a zero as the value to output.
  9855.     OUT DX,AL    ; SEND the zero to the port.
  9856.                  ;
  9857.     INT 20       ;return to DOS
  9858.  
  9859. RCX
  9860. 8
  9861. W
  9862. Q
  9863.  
  9864. After typing the Q you should get the DOS prompt back.  A DIR should
  9865. show the 8 byte com file OFFCOM1.COM.  This program can be run after
  9866. exiting kermit or from kermit using the run command.  I use a macro to
  9867. drop DTR with the command do off.  The macro definition looks like this:
  9868. DEFINE OFF RUN A:OFF.COM
  9869.  
  9870. The first program of this kind at our site was written by Mitch Blank for
  9871. the Zenith Z100.  Here's the MASM source:
  9872.  
  9873. [Ed. - Source omitted, stored in KER:MSXZ100.DTR.  Adding DTR control for
  9874. every system that MS-DOS Kermit runs on (not to mention all the different
  9875. internal modems in use on them) would be a very big job, so little programs
  9876. like this are probably the best approach.]
  9877.  
  9878. ------------------------------
  9879.  
  9880. Date:  Thu, 10 Oct 85 13:47 CDT
  9881. From:  "David S. Cargo" <Cargo@HI-MULTICS.ARPA>
  9882. Subject: Kermit for 1750A, MOS, or Jovial?
  9883.  
  9884. Has anybody seen or heard of a version of Kermit written in Jovial, or
  9885. the assembly language of the 1750A for MOS (the MATE Operating System)?
  9886. We have some parts of the company that want such a thing.
  9887.  
  9888. [From "Burton J. Ewing" <Ewing@HI-MULTICS.ARPA>: By the way, MOS is a
  9889.  
  9890. INFO-KERMIT DIGEST V3 #24                                              Page 179
  9891.  
  9892. derivative of Unix (by way of IDRIS?). This might be more useful info to the
  9893. Kermit community than MOS. Our people who have been peering about in MOS's
  9894. innards tell me that it is largely identical to Unix in most respects. Same
  9895. structure, same subroutine names, arguments, etc. Therefore, if we could
  9896. find another Unix hosted Kermit that was written in something we can compile
  9897. to 1750A code we are in business. The last time I checked, that meant JOVIAL
  9898. - but, who knows what will happen in the future?]
  9899.  
  9900. ------------------------------
  9901.  
  9902. End of Info-Kermit Digest
  9903.  
  9904. Page 180                                              INFO-KERMIT DIGEST V3 #25
  9905.  
  9906. Info-Kermit Digest         Fri, 18 Oct 1985       Volume 3 : Number 25
  9907.  
  9908. Departments:
  9909.  
  9910.   KERMIT (ETC) FOR THE BLIND -
  9911.     Equipment for the Blind
  9912.     Use of Kermit by the Blind
  9913.  
  9914.   VM/CMS KERMIT -
  9915.     CMS Kermit V2.01
  9916.     CMS KERMIT bugs
  9917.     Kermit-CMS Fixes
  9918.     Bug Fixes for CMS-Kermit 2.01
  9919.  
  9920.   MISCELLANY -
  9921.     Dropping DTR on VMS
  9922.     Victor/Sirus Support on the Way for MS-Kermit 2.28
  9923.  
  9924. ----------------------------------------------------------------------
  9925.  
  9926. Date: Wednesday, 9 Oct 85 07:59:43 PDT
  9927. From: Robert Jaquiss <robertj%tektronix.csnet@CSNET-RELAY.ARPA>
  9928. Subject: Equipment for the Blind
  9929.  
  9930. [Ed. - Some people have complained that this discussion is inappropriate
  9931. to Info-Kermit (and/or Info-IBMPC, Info-Micro, etc), but there's no
  9932. mailing list specifically for this topic.  And a lot of useful information
  9933. is coming in.  So please tolerate this digression for a while.  I'll also be
  9934. archiving all of these messages into a special file, KER:AABLIND.HLP.]
  9935.  
  9936.      I am a blind programmer at Tektronix Inc.  I have used Kermit on
  9937. several occations.  For my work I use a Thiel braille printer from Maryland
  9938. Computer Services.  To the computer it looks like a teletype that can send
  9939. and receive upper and lowercase.  Of course graphics are useless cursor
  9940. movement is impossible.  It is possible to deal with numbered or lettered
  9941. menus where you select the item you want by entering some character.  I have
  9942. a Versabraille as a backup terminal on which I have also used kermit it
  9943. worked fine.  The micro I am using runs CP/M so I don't have to contend with
  9944. menus.
  9945.  
  9946.      Here are some equipment sources that have reliable hardware.  Maryland
  9947. Computer Services sells a very good braille printer.  They have a specially
  9948. modified HP150 that talks and a accessory for a PC that will allow users to
  9949. use screen oriened software.  Telesensory Systems Inc. sells the
  9950. Versabraille (a refreshable braille display) and the Optacon (a hand held
  9951. scanner that will show you the shape of letters).  Vtek sells a tactile
  9952. display device for use on a ibm PC or Apple.
  9953.  
  9954.         Maryland Computer Services Inc.
  9955.         2010 rock Springs Road
  9956.         Forest Hills, Md. 21050
  9957.         Phone (301) 879-3366
  9958.  
  9959.         Telesensory Systems Inc.
  9960.         455 N. Bernardo
  9961.         Mountainview, Ca. 94039
  9962.  
  9963. INFO-KERMIT DIGEST V3 #25                                              Page 181
  9964.  
  9965.         Phone (415) 960-0920
  9966.  
  9967.         Vtek
  9968.         1610 26th
  9969.         Santa Monica, Ca. 90404
  9970.         Phone (213) 829-6841
  9971.  
  9972.      If you need moe help call me at (503)  627-6346  (work).
  9973.  
  9974.         Robert S. Jaquiss
  9975.  
  9976. ucbvax!tektronix!robertj (uucp)
  9977. robert jaquiss@tektronix (csnet)
  9978. robert jaquiss.tektronix@rand-relay (arpanet)
  9979.  
  9980. ------------------------------
  9981.  
  9982. Date: Fri, 11 Oct 85 9:34:53 EDT
  9983. From: Robert I. Isakower (IMD-SEAD) <isakower@Ardc.ARPA>
  9984. Subject: Use of Kermit by the Blind
  9985.  
  9986. The following letter was sent to Kennith Reed 10/10/85 at your request.
  9987. 9 October 1985
  9988.  
  9989. Dear Mr. Reed,
  9990.  
  9991. Recently  a request was forwarded to me from Frank da Cruz asking if I
  9992. had any information on the use of Kermit or the MS-DOS system by the Blind.
  9993.  
  9994. Perhaps this request was directed to me because I have tunnel vision (Retinitis
  9995. Pigmentosa).  I also have a degenerative hearing problem which places very
  9996. demanding requirements on any voice synthesizers used with visual aids for my
  9997. eyesight problems.  I have found SMOOTHTALKER on the Mac difficult to
  9998. understand.  DECTALK provides, for my personal use, the best voice output.
  9999. Please realize that I am not a judge of what constitutes good speech because
  10000. everything sounds to me as if it were coming from a distorted radio receiver.
  10001.  
  10002. The following information that I am including in my letter are my notes and
  10003. results of my own findings of a computer show that I attended in Ewing, New
  10004. Jersey this past September.  I have no corporate nor financial interest in any
  10005. of the company products and the information and comments that I am offering is
  10006. my personal opinion.
  10007.  
  10008. I sincerely hope that my enclosure will be of some assistance to you in your
  10009. research.  If I can be of any further assistance, please feel free to contact
  10010. me.
  10011.         Robert I. Isakower
  10012.         C,  Technical Systems Division
  10013.  
  10014. Four vendors featuring "talking computers" were at the show for aids for the
  10015. blind and the visually impaired.  I was unable to get prices for all the
  10016. equipment.
  10017.  
  10018. VTEK (formerly VISUALTEK)
  10019. 1625 Olympic Boulevard
  10020. Santa Monica, CA   90404
  10021.  
  10022. Page 182                                              INFO-KERMIT DIGEST V3 #25
  10023.  
  10024. 1-800-345-2256
  10025.  
  10026.      VOYAGER Electronic Magnifiers:  $2,395 to $2,895
  10027.  
  10028.      Large Print Display Processor  (*) :  $2,695
  10029. (This device magnifies, up to 16X, whatever is on the screen, with
  10030. character enhancement.  It recognizes the ASCII code and redraws it as
  10031. a solid line vector, instead of an enlarged matrix of dots and spaces.)
  10032.  
  10033.      MBOSS-1 Braille Printer:  $3,225
  10034.  
  10035.      Braille Display Processor (*):  $3,495
  10036. This is a neat paperless braille output with a 20 cell tactile refreshable
  10037. braille readout.  It will provide the braille equivalent of 20 contiguous
  10038. character spaces on the computer display.  Audio signals indicate the
  10039. "position" of the 20 cell braille window on the video display.
  10040.  
  10041.      (*) for APPLE II, II+, IIe and IBM PC, PC-XT, PC-AT
  10042.  
  10043. COMPUTER CONVERSATIONS
  10044. 2350 N. Fourth St.
  10045. Columbus, Ohio   43202
  10046. (614) 263-4324 (after 6 PM)
  10047.  
  10048.      ENHANCED PC TALKING PROGRAM:  $500
  10049.  
  10050.      Written by a blind programmer, (Ronald Hutchinson), this is interfacing
  10051. software only, and requires the user's own computer, voice synthesizer, and
  10052. application progams.  Application programs are the programs that you wish to
  10053. use in a speaking mode and would be an additional expense with all talking
  10054. computers.  This company's program interfaces with the most used computers,
  10055. speech synthesizers and application software in the marketplace.  The company
  10056. will offer to recommend the configuration best suited to your needs and budget.
  10057.  
  10058. MARYLAND COMPUTER SERVICES
  10059. 2010 Rock Spring Rd
  10060. Forest Hill, Maryland    21050
  10061. (301) 879-3366
  10062.  
  10063.      TOTAL TALK PC (microcomputer, display, speech synthesizer, keyboard)
  10064.  
  10065. AUDIODATA/IBM PC KEYBOARD (2 slider keys, speech synthesizer, speaker, and
  10066. display magnification with optional low cost monitor)-provides audio output
  10067. from your IBM PC.  The vertical slider key locates the desired line and the
  10068. horizontal key locates the character on the line. In this manner, the user can
  10069. hear the screen, one line at a time, character by character.
  10070.  
  10071.      THIEL BRAILLE (high speed-120 cps) EMBOSSER
  10072.  
  10073.      CRANMER-PERKINS BRAILLER (4000 character memory typewriter, braille
  10074. printer, plotter, smart terminal, portable):  $2,350.
  10075.  
  10076.      READY READER optical character reader (typewritten material to braille
  10077. or voice):  $11,500.
  10078.  
  10079.      MCS computer systems are based upon Hewlett-Packard computers which are
  10080.  
  10081. INFO-KERMIT DIGEST V3 #25                                              Page 183
  10082.  
  10083. very well constructed.  Unfortunately, none of the above equipment was
  10084. demonstrated to me, for one reason or another.
  10085.  
  10086. A fourth vendor was demonstrating a speech synthesizer that works with
  10087. the APPLE II.  I wasn't stirred by it and left early, not being offerred
  10088. any literature.
  10089.  
  10090. COMMENTS: VTEK and MCS have been around a long time, know the business of
  10091. electronic visual aids, have the most varied product line and are probably
  10092. my best bet for the future.  They have equipment for both the visually
  10093. impaired and the totally blind.  MCS's AUDIODATA/IBM KEYBOARD promises the
  10094. simplest, cheapest and quickest fix for IBM PC users. Although it is a very
  10095. competitive computer marketplace, a small software manufacturer and system
  10096. iterfacing company such as Computer Conversations, probably with lower
  10097. production costs and more self-motivating talent, cannot be discounted.
  10098. Another company that should be investigated is the one that manufactures a
  10099. portable tactile (pins) readout device called the OPTICON.  I've watched
  10100. this used with great success and speed on printouts and teletypewriters (on
  10101. line), and I heard of some sort of adaptation to a computer display.  Note
  10102. that the OPTICON is difficult to learn to use.
  10103.  
  10104. ------------------------------
  10105.  
  10106. Date: 9 October 1985, 13:36:52 EDT
  10107. From: Philip Murton             (416) 978-5271       MURTON   at UTORONTO
  10108. Subject: CMS Kermit V2.01
  10109.  
  10110. I think I found a small bug that is related to your edit [25],
  10111. if you have FILE set to BINARY and have compression ON.  Here's the fix:
  10112.  
  10113. [Ed. - Thanks!  Code omitted, but included in KER:CMSMIT.BWR.]
  10114.  
  10115. ------------------------------
  10116.  
  10117. Date: Wed, 9 Oct 85 23:04 CDT
  10118. From: Brick Verser <BAV@KSUVM>
  10119. Subject: CMS KERMIT bugs
  10120.  
  10121. Here is another small CMS KERMIT problem.  If running on the 7171 (or
  10122. Series/1, I think), CMS KERMIT 2.x doesn't work if the virtual machine
  10123. console is not at address 9.  While all of the diagnoses know to use
  10124. the dynamically determined console address, the HNDINT SET has address
  10125. 9 hard coded.  The fix is simple and obvious, except that HNDINT doesn't
  10126. allow a register for the console address field, so the HNDINT macro
  10127. has to be replaced by the hand coded equivalent.
  10128.  
  10129. [Ed. - See below.]
  10130.  
  10131. ------------------------------
  10132.  
  10133. Date:         Tue, 15 Oct 85 09:13 EST
  10134. From:         Dave Elbon  <SYSDAVE%UKCC.BITNET@WISCVM.ARPA>
  10135. Subject:      Kermit-CMS Fixes
  10136.  
  10137. I have some fixes for Kermit-CMS 2.01.
  10138.  
  10139.  
  10140. Page 184                                              INFO-KERMIT DIGEST V3 #25
  10141.  
  10142. 1) Kermit-CMS is confused when TERMINAL LINESIZE is set to OFF.
  10143.  
  10144. 2) The actual virtual console address is not used in a call to HNDINT,
  10145.    which prevents Kermit-CMS from working if the address is not 009.
  10146.    (Many, many thanks to Brick Verser of KSU for this.)
  10147.  
  10148. 3) CP SET ACNT should be turned OFF along with MSG, WNG, and IMSG.
  10149.  
  10150. When Series/1 mode is on it might be possible to set TERMINAL BREAKIN to
  10151. GUESTCTL rather than changing all of the message settings.
  10152. Acknowledge-To: Dave Elbon <SYSDAVE@UKCC>
  10153.  
  10154. [Ed. - Thanks, the code that was included with this message has been added
  10155. to KER:CMSMIT.BWR.]
  10156.  
  10157. ------------------------------
  10158.  
  10159. Date: Wed, 16 Oct 85 14:25:24 pdt
  10160. From: gts@ucbopal.Berkeley.EDU
  10161. Subject: Bug Fixes for CMS-Kermit 2.01
  10162.  
  10163. [Ed. - Each of these paragraphs came with code to correct the reported
  10164. problem.  The code has been omitted here, but has been added to
  10165. KER:CMSMIT.BWR.]
  10166.  
  10167. Fix bug at RPACK4. Calculation of crck (block=3) must begin at the first
  10168. actual packet character not at RECPKT+1. Leading pad or junk characters move
  10169. it further down.  Use pointer RECPKTP.
  10170.  
  10171. Fix confusion and conflicts in use of MAXOUT and LRECL.  MAXOUT controls the
  10172. amount of data collected for a write and LRECL is used only during padding
  10173. of recfm F records.  During SET FILE BIN, MAXOUT was set to LRECL and during
  10174. SET FILE TEXT it was set to MAXTXT!  This is clearly wrong.  Also, MAXOUT
  10175. was set to LRECL during SET LRECL which causes recfm V writes to be blocked
  10176. to LRECL.
  10177.  
  10178. This fix removes the MAXOUT change during SET FILE. SET LRECL is changed to
  10179. set MAXOUT to MAXTXT for recfm V or to LRECL for recfm F.  SET RECFM is
  10180. changed to do the same.
  10181.  
  10182. Fix maximum LRECL to 65535 not 65536.  CMS allows only 65535 (64k-1). CMS
  10183. aborts the write if lrecl 65536 for recfm V.  And although CMS allows the
  10184. write if lrecl 65536 for recfm F, most products cannot handle such records.
  10185.  
  10186. Fix MAXTXT to be 65535 not 64536 (typo)!  Remove unused MAXBIN.    
  10187.  
  10188. Change receive to expand tabs each 8 spaces (unix,cp/m,pcdos) for text file
  10189. receives.
  10190.  
  10191. Redisplay the send or receive command at completion, followed by the status
  10192. message, then the completed or failed message.  This gives the user
  10193. everything they need to know at one glance.  Initial status is "No send /
  10194. receive done yet".
  10195.  
  10196. Fix recfm f to pad lines with spaces not nulls.        
  10197.  
  10198.  
  10199. INFO-KERMIT DIGEST V3 #25                                              Page 185
  10200.  
  10201. Change DECODE to interpret CR and LF from the EBCDIC after translation with
  10202. ATOE instead of from the seven bit ASCII. This allows receive of text files
  10203. that contain characters with the eight bit set with the normal ATOE table,
  10204. or by altering the the ATOE table allows receipt of text in any eight-bit
  10205. code.  Also CR LF LF gives two lines based on CR LF then LF.
  10206.  
  10207. Fix receive to discard the trailing control-Z for text files This catches
  10208. all cases except where the control-Z has already been written to disk, e.g.
  10209. the 65535th character of the last recfm V record or the lreclth character of
  10210. the last recfm F.
  10211.  
  10212. Greg Small                                    (415)642-5979
  10213. Microcomputer Networking & Communications     gts@ucbopal.Berkeley.ARPA
  10214. 214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
  10215. University of California                      SPGGTS@UCBCMSA.BITNET
  10216. Berkeley, Ca 94720
  10217.  
  10218. ------------------------------
  10219.  
  10220. Date: Thu, 17 Oct 85 21:53:16 edt
  10221. From: faron!sidney@mitre-bedford.ARPA
  10222. Subject: Dropping DTR on VMS
  10223.  
  10224. We have the latest VMS Kermit running under VMS 4.whatever, talking to
  10225. an autodial modem through a DMF-32 mux. The only way the VAX can get
  10226. the modem to hang up the phone is by dopping DTR. Can anyone help with
  10227. a way to do that, perhaps with a little program like the one that was
  10228. in the last info-kermit digest for MSDOS? Are there any VMS SET TERM
  10229. parameters that are involved?
  10230.  
  10231.                     Sidney Markowitz
  10232.  
  10233. ------------------------------
  10234.  
  10235. Date: 18-OCT-1985 13:58:48
  10236. From:SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
  10237. Subject: Victor/Sirus Support on the Way for MS-Kermit 2.28
  10238.  
  10239. Brian Steel of Logic Programming Associates (UK) is doing an MSXSIR.ASM at the
  10240. moment - no idea when it will be ready though.  Will let you know as soon as I
  10241. hear from him.
  10242.  
  10243.         Alan
  10244.  
  10245. ------------------------------
  10246.  
  10247. End of Info-Kermit Digest
  10248.  
  10249. Page 186                                              INFO-KERMIT DIGEST V3 #26
  10250.  
  10251. Info-Kermit Digest         Thu, 24 Oct 1985       Volume 3 : Number 26
  10252.  
  10253. Departments:
  10254.  
  10255.   ANNOUNCEMENTS -
  10256.     CU20B Internet Address Changed
  10257.  
  10258.   MS-DOS KERMIT -
  10259.     MS-DOS Kermit Files Reorganized
  10260.     Request for Kaypro 2000 Information
  10261.     Revised HP 110, Portable Support for MS-DOS Kermit 2.28
  10262.     New TI Pro Support for MS-DOS Kermit 2.28
  10263.     Fix for Z100 MS-DOS Kermit
  10264.     MS-DOS Kermit Key Definitions for EDT
  10265.     MS-DOS Kermit and DTR
  10266.  
  10267.   MISCELLANY -
  10268.     C-Kermit 4C(056/057) and MacKermit 0.8(33)
  10269.     2400 Baud Modems with MNP "Protocol"
  10270.     Update on Crosstalk Problems
  10271.     CMS Kermit "Enhancements"
  10272.     Kermit for the Blind
  10273.     Kermit for the Texas Instruments 99/4A??
  10274.     Kermit on Diskette for Terak?
  10275.  
  10276. ----------------------------------------------------------------------
  10277.  
  10278. Date: Thu, 24 Oct 85 15:33:59 edt
  10279. From: Frank da Cruz <SY.FDC@CU20B>
  10280. Subject: CU20B Internet Address Changed
  10281.  
  10282. Because Columbia is splitting its overburdened campus network into several
  10283. discrete but interconnected chunks, the Internet host address for CU20B
  10284. has changed, effective yesterday (23 Oct 85, 7:00PM EDT), from
  10285. [192.5.43.128] to [128.59.32.128].
  10286.  
  10287. The change has been reported to the NIC in hopes that they will get out a
  10288. revised host table in a day or so.  Until CU20B's new address is in your
  10289. host table, you can refer to it numerically (but then you don't get the
  10290. automatic recognition of what type of host it is; e.g. people coming in
  10291. from other DEC-20s will have to explicitly tell FTP "STRUCTURE PAGE",
  10292. "TENEX", or something to that effect.)
  10293.  
  10294. ------------------------------
  10295.  
  10296. Date: Wed 23 Oct 85 14:13:21-EDT
  10297. From: Frank da Cruz <SY.FDC@CU20B>
  10298. Subject: MS-DOS Kermit Files Reorganized
  10299.  
  10300. Several recent submissions of MS-DOS Kermit material (see below) have
  10301. prompted me to reorganize the MS-DOS Kermit files a bit, so now they have
  10302. more consistent names.  The names are now in the following form:
  10303.  
  10304.     MScxxx.typ
  10305.  
  10306. The file name is no longer than six characters, the file type is 3 or less.
  10307.  
  10308. INFO-KERMIT DIGEST V3 #26                                              Page 187
  10309.  
  10310. MS is the common prefix for all the file names.
  10311.  
  10312. "c" is a single-letter code that categorizes the file:
  10313.  
  10314.   A - General information, "read me" files, etc. (like this file)
  10315.   B - Files related to Bootstrapping
  10316.   I - Initialization or command files to be read by Kermit
  10317.   K - General program documentation (Kermit User Guide chapter, etc)
  10318.   R - Release notes
  10319.   S - System-independent Source code
  10320.   V - Binaries, .BOO files, documentation for a particular Version
  10321.   X - System-dependent source code & related documentation
  10322.   Y - System-dependent terminal emulation code
  10323.   Z - System-and-modem-dependent modem control code
  10324.  
  10325. "xxx" is a 3 letter code to designate which system an MSV, MSX, MSY, or MSZ
  10326. file applies to:
  10327.  
  10328.   AP3 - NEC APC-3
  10329.   APC - NEC APC
  10330.   APR - ACT Apricot
  10331.   DM2 - DECmate II or III with MS-DOS Option
  10332.   GEN - "Generic" MS-DOS (DOS calls only)
  10333.   HP1 - HP-150
  10334.   HPX - HP-110 and HP Portable Plus
  10335.   IBM - IBM PC, XT, AT, and PCjr (note, only works on RS-232 port of PCjr)
  10336.   MBC - Sanyo MBC-550
  10337.   RB1 - DEC Rainbow-100 series
  10338.   TIP - Texas Instruments Professional
  10339.   WNG - Wang PC
  10340.   Z10 - Heath/Zenith 100
  10341.  
  10342. "typ" is the file type, e.g.
  10343.  
  10344.   ASM - Assembler source (for Microsoft or IBM Assembler)
  10345.   H   - An assembler header file (included at assembly time)
  10346.   C   - A C language source file (e.g. Lattice C)
  10347.   BAS - A Basic language source (e.g. Microsoft Basic)
  10348.   BOO - An .EXE file encoded into printable characters for bootstrapping
  10349.   BWR - A "beware" file - list of known bugs or limitations
  10350.   HLP - A help file
  10351.   DOC - A longer documentation file
  10352.   MSS - Scribe text formatter source for a HLP or DOC file
  10353.   INI - An initialization or command file to be read by Kermit
  10354.   BAT - An MS-DOS Batch file (e.g. for building from source)
  10355.   UPD - A program update history file
  10356.  
  10357. KER:MSAAAA.HLP has been updated to reflect the changes, as well as the new
  10358. releases.  No changes were made to the programs themselves (except as
  10359. reported below), but I expect a new release of MS-DOS Kermit to be ready in
  10360. about a month.
  10361.  
  10362. ------------------------------
  10363.  
  10364. Date: Tue, 22 Oct 85 16:30:24 pdt
  10365. From: Harvey A. Iwamoto <iwamoto%trout@nosc.ARPA>
  10366.  
  10367. Page 188                                              INFO-KERMIT DIGEST V3 #26
  10368.  
  10369. Subject: Request for Kaypro 2000 Information
  10370.  
  10371. I have been patching the Generic Kermit for the built-in modem in the HP 110
  10372. with minor success.  I was able to get the modem port in the Grid Compass
  10373. working with yet another patched Generic Kermit but the file transfer would
  10374. not work.  There is some problem with either parity, number of stop or data
  10375. bits.  It seems that each one of these built-in modems behave differently
  10376. and are located in differently addresses.  I am currently trying to get a
  10377. version of Kermit working for the Kaypro 2000 but I lack address information
  10378. about the modem port.  I called Kaypro directly but they would like users to
  10379. ask their dealers.  The only Kaypro rep got fired so there is no direct line
  10380. to information.  I need to know where the modem is located (memory or
  10381. ioport) and what the busy bits are.  Also, if it must be initialized.  In
  10382. short, the type of modem if any does it emulate.  If and when I get the
  10383. patched version working, I will make it available to any or all interested
  10384. parties.
  10385.  
  10386. Harvey Iwamoto
  10387.  
  10388. [Ed. - Internal modems are poison, but if you're stuck with one I guess this
  10389. is what you have to do.  Meanwhile, see below about HP-110 modem port.]
  10390.  
  10391. ------------------------------
  10392.  
  10393. Date: Tue, 22 Oct 85 21:17:23 mdt
  10394. From: dwf%b@LANL.ARPA (Dave Forslund)
  10395. Subject: Revised HP 110, Portable Support for MS-DOS Kermit 2.28
  10396.  
  10397. Attached is the assembler source for the HP110 Kermit (MSHPX.ASM).  It works
  10398. both on the HP110 and the new HP Portable Plus.  Port 1 is the serial port
  10399. and Port 2 is the internal modem.  Defaults are even parity and 9600 baud on
  10400. the serial port and 1200 baud on the internal modem.  We should have a
  10401. version shortly which will also drive the HP-IL RS-232 interface as Port 3.
  10402. This new code correctly handles different parity settings and works without
  10403. modification on both the HP110 and the Portable Plus.  All of the work on
  10404. this code was done by Chuck Aldrich here at Los Alamos.  The separate
  10405. assembler source is assembled with MicroSoft MASM and linked with LINK just
  10406. has described in the MSKERMIT documentation.  This executable has also been
  10407. compressed with MicroSoft's EXEPACK utility before being processed with
  10408. MSBMKB.C into a .BOO file.
  10409.  
  10410. [Ed. - Thanks Dave!  The files are in KER:MS*HPX.*, available via anonymous
  10411. FTP from CU20B (by those who have fixed their host tables as shown above).]
  10412.  
  10413. ------------------------------
  10414.  
  10415. Date: Sun 20 Oct 85 22:13:21-EDT
  10416. From: Joe Smith (415)794-2512 <LSM.SMITH@MARLBORO.DEC.COM>
  10417. Subject: New TI Pro Support for MS-DOS Kermit 2.28
  10418.  
  10419. About 6 months ago, my colleague Dan Smith tried sending you the updated
  10420. versions of the sources for MS-DOS Kermit 2.28 running on the Texas
  10421. Instruments Professional.  Apparently they did not get there.  The version
  10422. in question has H19 and Tektronix emulation and works at 9600 baud.  I have
  10423. uploaded them again. Please delete KER[MIT]:MSXTEK.ASM on both MARKET and
  10424. COLUMBIA - that file has been replaced by MSYTIP.ASM.  Please update
  10425.  
  10426. INFO-KERMIT DIGEST V3 #26                                              Page 189
  10427.  
  10428. MSAAAA.HLP and MSBUILD.HLP to reflect the new name.
  10429.  
  10430.                 Joe Smith
  10431.  
  10432. [Ed. - Thanks, Joe!  The files are available on CU20B as KER:MS*TIP.*.]
  10433.  
  10434. ------------------------------
  10435.  
  10436. From: John Voigt, Tulane Univ. Systems Group <SYSBJAV@TCSVM.BITNET>
  10437. Date: 10/20/85 13:02:43 CDT
  10438. Subject: Fix for Z100 MS-DOS Kermit
  10439.     
  10440. August Treubig of Middle South Services discovered a bug in the Z100
  10441. version of KERMIT.  It caused MS-DOS to crash.  The fix is in the GETBAUD
  10442. routine; the call to bios_auxfunc should be surrounded by "push di" and
  10443. "pop di".
  10444.  
  10445. [Ed. - Thanks; the change has been made in the source file, MSXZ10.ASM, and
  10446. added to the Z100 Kermit beware file.  The .BOO file is still based on the
  10447. original source until the next release of MS-DOS Kermit.]
  10448.  
  10449. ------------------------------
  10450.  
  10451. Date: 11 Oct 1985 0118-EDT
  10452. From: (Carl Houseman, GENICOM Corp., via) EIBEN@DEC-MARLBORO
  10453. Subject: MS-DOS Kermit Key Definitions for EDT
  10454.  
  10455. I've uploaded two files which make life for the IBM-PC/Kermit user
  10456. who also uses EDT a little easier.  Together they provide all the keypad
  10457. editing functions of EDT to the PC user.  They are:
  10458.  
  10459. MSIVT1.EDT    - An EDT initialization file which defines the numeric
  10460.                 keypad functions to match a VT-100 layout.  Use of this
  10461.                 file when editing on a VT-100/VT-220 is harmless, but
  10462.                 those using "real" VT-52's should not invoke it.
  10463.  
  10464. MSIVT1.INI    - Defines the numeric keypad and function keys as to
  10465.                 match VT-100 function keys as closely as possible, as
  10466.                 follows:
  10467.  
  10468.                 F1=PF1  F2=FP2  F3=PF3  F4=PF4  F5=backspace  F6=linefeed
  10469.                 F7=up-arrow  F8=down-arrow  F9=left-arrow  F10=right-arrow
  10470.  
  10471.                 The numeric keypad is the same as a VT-100 where the keys
  10472.                 are the same, with the PRTSC key acting for the VT-100
  10473.                 keypad comma, and the "+" key acting for ENTER.  The
  10474.                 8, 4, 6 and 2 keys become cursor keys when SHIFT is held.
  10475.  
  10476. If the 5 key fails to work correctly (can't effect BACKUP while in EDT),
  10477. press the NUM-LOCK key.  Also note that an "=" will appear at the top left
  10478. of the screen after starting EDT; this is a problem with Kermit's VT-52
  10479. (Heath-19) emulation, and the "=" is not really in the file.  It does
  10480. not re-appear after scrolling off the screen.
  10481.  
  10482. Carl Houseman
  10483. GENICOM Corp.
  10484.  
  10485. Page 190                                              INFO-KERMIT DIGEST V3 #26
  10486.  
  10487. 703-949-1323
  10488.  
  10489. [Ed. - These files available in KER:MSIVT1.* on CU20B.]
  10490.  
  10491. ------------------------------
  10492.  
  10493. Date: Sun 20 Oct 85 13:08:20-PDT
  10494. From: Carl Fussell <G.FUSSELL@SU-SCORE.ARPA>
  10495. Address: Santa Clara University
  10496. Subject: MS-DOS Kermit and DTR
  10497.  
  10498. If anyone is interested, we have added a SET DTR ON/OFF command to the IBM
  10499. PC version of Kermit...  we also found that it was needed for some of the
  10500. communication we do.  We did not submit it back to Columbia since it was
  10501. only added to this one version.  If you would like a copy, contact me.  If
  10502. anyone is interested, I will upload it to my guest account at Score where it
  10503. can be ftp'd.  As I recall, the changes were only in a couple modules.
  10504.  
  10505. Carl
  10506.  
  10507. [Ed. - Again, the problem here is that in inordinate amount of research and
  10508. effort would be required to add DTR control to all the different versions of
  10509. MS-DOS Kermit; the MSX*.ASM system-dependent modules would have to be
  10510. redesigned, possibly resulting in damage to systems that the new design
  10511. could not be readily tested on, etc.  Far better to supply a trivial little
  10512. program for toggling DTR, and define macros in Kermit for running it with
  10513. Kermit's RUN command.]
  10514.  
  10515. ------------------------------
  10516.  
  10517. Date: Mon, 21 Oct 85 20:06:40 est
  10518. From: George Wyncott <aaj@purdue-asc.ARPA>
  10519. Subject: C-Kermit 4C(056/057) and MacKermit 0.8(33)
  10520.  
  10521. Two of our staff members with Macintoshes reported the following problem:
  10522.  
  10523. C-Kermit 4C(056/057) seems to fail when used with MacKermit 0.8(33).
  10524. C-Kermit version 4.2(030) PRERELEASE #2 works correctly under normal
  10525. conditions.  Here's what happens with versions (056) and (057):
  10526.  
  10527. 1. C-Kermit is executed interactively and given the "r <file>" command.
  10528.  
  10529. 2. MacKermit is directed to send the file.
  10530.  
  10531. 3. C-Kermit receives the file completely.
  10532.  
  10533. 4. MacKermit continues to resend the end-of-file packet (B) continuously.
  10534.  
  10535. It appears that C-Kermit is not acknowledging the B packet correctly,
  10536. causing MacKermit to cycle endlessly and preventing the end-of-transmission
  10537. (Z) packet from being exchanged.
  10538.  
  10539. HERE'S THE STRANGE PART: If you give C-Kermit the "log debug" command
  10540. before the "r <file>", the exchange takes place without error - C-Kermit
  10541. gets the Z packet.
  10542.  
  10543.  
  10544. INFO-KERMIT DIGEST V3 #26                                              Page 191
  10545.  
  10546. NOW HERE'S ANOTHER STRANGENESS: C-Kermit 4.2(030) works the opposite.
  10547. You get a correct transfer UNLESS "log debug" is commanded.  Then it
  10548. hangs up just like versions (056) and (057).
  10549.  
  10550.      George Wyncott
  10551.      aaj@asc.purdue.edu
  10552.  
  10553. [Ed. - The problem can probably be traced to how C-Kermit sends out the ACK
  10554. to the B packet, and then closes the line.  Unfortunately, Unix tends to
  10555. close the line while sending out the packet is still on its list-of-things-
  10556. to-do-when-it-gets-around-to-them...  Solution: flush the output queue
  10557. before closing the line.  Or if that adds too much system-dependent hair,
  10558. sleep(n) before the close.  The program currently does a sleep(1), but it
  10559. may be that more than a second is needed for busy systems and/or low baud
  10560. rates, so maybe n should be some function of these.]
  10561.  
  10562. ------------------------------
  10563.  
  10564. Date: Mon Oct 21 21:55:09 1985
  10565. From: Herm Fischer <hermix!fischer@rand-unix.ARPA>
  10566. Reply-To: HFischer@USC-ECLB
  10567. Subject: 2400 Baud Modems with MNP "Protocol"
  10568.  
  10569. I looked (briefly) into the new 2400 baud modems for use with my Xenix
  10570. system.  The dealers all push versions with a built-in protocol called
  10571. MNP.  This protocol handles retries of bad characters, BUT (e.g., beware)
  10572. it is not really suitable for use on communications where the underlying
  10573. software already has a protocol.
  10574.  
  10575. With uucp, the MNP flow control will be incompatible, and thus one will
  10576. have to disable MNP.
  10577.  
  10578. With Kermit, MNP is likely to play havoc particularly where the end-to-end
  10579. flow control needs to be preserved (likely at 2400 baud on systems which
  10580. might become busy), because MNP only appears to support modem to computer
  10581. flow control.
  10582.  
  10583. For interactive computer access, if you need control-s or control-q, e.g.,
  10584. if you use an editor like emacs ever, then again you might have difficulties.
  10585.  
  10586. The people who produced the MNP protocol, and whose marketing has caused the
  10587. modem suppliers to energetically advertise its features (without being
  10588. knowledgable of its operation), ended up recommending that I buy some other
  10589. modem without the feature.
  10590.  
  10591. Finally, be aware that MNP is only a retry on error protocol; it is not a
  10592. forward error correction device with Hamming codes (as I expected from its
  10593. sales literature).
  10594.  
  10595. [Ed. - Thanks for the comments, Herm.  Any further discussion of MNP and/or
  10596. X.PC in relation to Kermit would be most welcome here.]
  10597.  
  10598. ------------------------------
  10599.  
  10600. Date: Fri, 18 Oct 85 19:42:31 EDT
  10601. From: RAF@UMDC
  10602.  
  10603. Page 192                                              INFO-KERMIT DIGEST V3 #26
  10604.  
  10605. Subject: Update on Crosstalk Problems
  10606.  
  10607. The latest word from Microstuf customer support is that both problems
  10608. that I encountered with Crosstalk XVI 3.6 Kermit support will be fixed
  10609. "soon".  The two problems are not stopping at the Control-Z in a text
  10610. file and setting the wrong screen intensity in the KERMIT LIST command.
  10611.  
  10612. Roger Fajman  <RAF@UMDC>
  10613. National Institutes of Health
  10614.  
  10615. ------------------------------
  10616.  
  10617. Date: Sat, 19 Oct 85  23:07 EDT
  10618. Subject: CMS Kermit "Enhancements"
  10619. From: ("Bob Shields <VBOB@UMDB>") <@UMD2.UMD.EDU:VBOB@UMDB.BITNET>
  10620.  
  10621. In one of the latest "info-kermit" digests I read that someone had modified
  10622. CMS Kermit to "automatically" expand tab characters to 8 column boundaries.
  10623. If this is being considered as a standard operation, I would like to cast my
  10624. vote against it.  I have found that XEDIT will expand tabs just fine (see
  10625. the "EXPAND" and "COMPRESS" commands), and will do it to whatever columns
  10626. *I* specify, not just every *8*.  I more often use a tab setting of every 4
  10627. columns, and sometimes use ones that are not at fixed intervals (like 10,
  10628. 16, 30,...  for CMS ASSEMBLE files).  Maybe this can be resolved with "yet
  10629. another SET command" in CMS Kermit.
  10630.  
  10631. [Ed. - You're right, it shouldn't be hardwired into the program.]
  10632.  
  10633. ------------------------------
  10634.  
  10635. From: Sheldon Talmy <talmy@rand-unix.ARPA>
  10636. Date: 19 Oct 85 18:36:58 PDT (Sat)
  10637. Subject: Kermit for the Blind
  10638.  
  10639. In response to your msg about "Kermit for the blind", there is a great deal
  10640. being done for the visually handicapped in conjunction with computers.
  10641.  
  10642. One company I suggest is IRTI:
  10643.  
  10644. Innovative Rehabilitation Technologies Inc.
  10645. 26699 Snell Lane, Los Altos Hills,Ca, 94022
  10646. 415-948-8588
  10647.  
  10648. They have a huge catalog of products for the visually impaired, including
  10649. synths & entire turn-key systems.  If nothing else, the man who owns
  10650. the company is an excellent resource for info on the latest products.
  10651.  
  10652. I've been writing articles on computers for the handicapped for the last couple
  10653. of years, & have gathered several sources for products, that are ready to go
  10654. now.  If I can be of any help, send me a msg, & I'll be happy to assist you.
  10655.  
  10656. I note from other messages on the subject, that some research is going on that
  10657. could conceivably come under the heading of "re-inventing the wheel".
  10658. As i'm involved in the field, I might possibly be able to save time & effort,
  10659. so contact me if you like.
  10660.  
  10661.  
  10662. INFO-KERMIT DIGEST V3 #26                                              Page 193
  10663.  
  10664. Shel Talmy<>Talmy@Rand-Unix
  10665.  
  10666. ------------------------------
  10667.  
  10668. Date: Sat, 19 Oct 85 09:07:59 EST
  10669. From: pur-ee!mjs@UCB-VAX.Berkeley.EDU (Mike Spitzer)
  10670. Subject: Kermit for the Texas Instruments 99/4A??
  10671.  
  10672. I've heard someone mention this... does Kermit exist for the 99?  If not,
  10673. why not?
  10674.  
  10675.           Mike
  10676.  
  10677. ------------------------------
  10678.  
  10679. Date: Wed 23 Oct 85 16:01:10-EDT
  10680. From: MG1K%CMCCTC@TC.CC.CMU.EDU
  10681. Subject: Kermit on Diskette for Terak?
  10682.  
  10683.      I have a Terak which I am trying to use as terminal for the flourscence
  10684. center vax.  I would like to be able to transfer Kermit to the Terak.  If you
  10685. know of anyone who has(had) a Terak and has Kermit on 8 inch single density
  10686. floppies, please send me mail.
  10687.  
  10688.                      Thank you,
  10689.                           Miriam Gulotta  ( MG1k@cmcctc)
  10690.  
  10691. [Ed. - Can anyone help?]
  10692.  
  10693. ------------------------------
  10694.  
  10695. End of Info-Kermit Digest
  10696.  
  10697. Page 194                                              INFO-KERMIT DIGEST V3 #27
  10698.  
  10699. Info-Kermit Digest         Mon, 29 Oct 1985       Volume 3 : Number 27
  10700.  
  10701. Departments:
  10702.  
  10703.   ANNOUNCEMENTS -
  10704.     CU20B Address, Info-Kermit-Request Mail Trouble
  10705.     New Release of BBC Acorn Kermit
  10706.     Kermit for GEC-4000 Minicomputers
  10707.     New ACT Apricot Support for MS-DOS Kermit 2.28
  10708.     Kermit for RMX86
  10709.  
  10710.   MISCELLANY -
  10711.     MacKermit vs Cray
  10712.     C-Kermit 4.2(030) Source Wanted
  10713.     VMS Kermit-32 bug fix
  10714.     CMS-Kermit Expanding Tabs on Receive
  10715.     C-Kermit on Diskette for Chromatics 7900?
  10716.  
  10717. ----------------------------------------------------------------------
  10718.  
  10719. Date: Mon 28 Oct 85 12:42:42-EST
  10720. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10721. Subject: CU20B Address, Info-Kermit-Request Mail Trouble
  10722.  
  10723. Apologies to all who have had trouble with the host address change for CU20B.
  10724. It was announced correctly in the last issue of Info-Kermit, but unfortunately
  10725. it was reported incorrectly to the NIC, which had CU20B listed as [128.59.32.1]
  10726. rather than [128.59.32.128] for several days.  Apologies also to those who
  10727. had trouble mailing to Info-Kermit or Info-Kermit-Request at CU20B, even when
  10728. the host address was right -- it all started when a disk filled up...
  10729. Everything should be back to normal now.
  10730.  
  10731. ------------------------------
  10732.  
  10733. Date: Mon 28 Oct 85 12:42:30-EST
  10734. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10735. Subject: New Release of BBC Acorn Kermit
  10736.  
  10737. This is to announce Version 1.02 of BBC Acorn Kermit from Alan Phillips of
  10738. Lancaster University, UK.  It includes significant improvements and bug
  10739. fixes over the current release, and is in extensive use in the UK.  The files
  10740. are in KER:BBC*.* on CU20B, available via anonymous FTP.
  10741.  
  10742. ------------------------------
  10743.  
  10744. Date: Mon 28 Oct 85 12:45:02-EST
  10745. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10746. Subject: Kermit for GEC-4000 Minicomputers
  10747.  
  10748. This is to announce Kermit for the British GEC 4000 Series minicomputers with
  10749. OS4000/RAL from Martin Loach of Rutherford-Appleton Laboratories.  The files
  10750. are in KER:GEC*.* on CU20B.
  10751.  
  10752. ------------------------------
  10753.  
  10754. Date: Mon 28 Oct 85 12:50:08-EST
  10755.  
  10756. INFO-KERMIT DIGEST V3 #27                                              Page 195
  10757.  
  10758. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10759. Subject: New ACT Apricot Support for MS-DOS Kermit 2.28
  10760.  
  10761. This is to announce a new release of the ACT Apricot support for MS-DOS
  10762. Kermit 2.28 from Ralph Mitchell of Brunel University, Uxbridge, Middlesex,
  10763. UK.  The files are in KER:MS*APR.* on CU20B.
  10764.  
  10765. ------------------------------
  10766.  
  10767. Date: Mon 28 Oct 85 12:52:52-EST
  10768. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10769. Subject: Kermit for RMX86
  10770.  
  10771. This is to announce a second Kermit program for Intel x86/xx systems with
  10772. the RMX86 operating system.  This one is written in PL/M by Robert Schamberger,
  10773. Wilson Lab, Cornell University, Ithaca NY 14583.  It is available on CU20B as
  10774. KER:RMX*.* (the other one is in KER:I86*.*; they are completely different
  10775. programs -- reviews or comparisons would be appreciated).
  10776.  
  10777. ------------------------------
  10778.  
  10779. Date: Tue, 22 Oct 85 12:18 pst
  10780. From: "pugh jon%b.mfenet"@LLL-MFE.ARPA
  10781. Subject: MacKermit vs Cray
  10782.  
  10783. I have been trying to use the MacKermit version 0.8(33) with our Cray
  10784. supercomputers and it has failed to go.  I have an earlier version of
  10785. Kermit from Stanford that does work.  The PC Kermit also works, but only
  10786. version 2.27 which is because it ignores an echoed packet, or so I am told.
  10787.  
  10788. I have tried using Kermit-PC version 2.26 with our Crays and it exhibits
  10789. the same symptoms MacKermit does.  I was wondering if MacKermit could be
  10790. modified by the creator there at Columbia to ignore the echoed packet that
  10791. gets returned.  Perhaps an investigation into the changes between the two
  10792. versions of Kermit-PC would be helpful.  I am willing to help in any way
  10793. that I can, including lots of testing.
  10794.  
  10795. For information purposes, I am a consultant at the National Magnetic Fusion
  10796. Energy Computer Center in Livermore, California, and we have users all over
  10797. the country using our four Crays.  It would be beneficial if we could have
  10798. Kermit working for all the physicists trying to use their Macs with our
  10799. Crays.  I would personally hate to see people forced to use a PC.  Yuck!
  10800.  
  10801.                                                 Yours Truly,
  10802.                                                   Jon Pugh
  10803.  
  10804. [Ed. - MacKermit suffers from a bug endemic to all the current releases of
  10805. C-Kermit, having to do with padding.  The problem is that whenever padding
  10806. is being used, and the padding character is not null (0), the checksum is
  10807. calculated incorrectly, and seems to only effect the Crays, since they are
  10808. the only ones that need non-null padding on Kermit packets.  The problem
  10809. will be fixed in the next release.]
  10810.  
  10811. ------------------------------
  10812.  
  10813. Date: Wed, 23 Oct 85 10:34:39 CDT
  10814.  
  10815. Page 196                                              INFO-KERMIT DIGEST V3 #27
  10816.  
  10817. From: Gregg Wonderly <gregg%okstate.csnet@CSNET-RELAY.ARPA>
  10818. Subject: C-Kermit 4.2(030) Source Wanted
  10819.  
  10820. We want to update our Kermit server to the current release level, but have
  10821. misplaced the original source we worked from, preventing us from getting
  10822. diffs to show the changes we have to install to the current release.  Does
  10823. anyone out there have vanilla source for the C-Kermit which announces itself
  10824. as "C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85"?
  10825.  
  10826. ------------------------------
  10827.  
  10828. Date: Fri, 25 Oct 85 16:35:33 edt
  10829. From: jso@edison.Berkeley.EDU (John Owens)
  10830. Subject: VMS Kermit-32 bug fix
  10831.  
  10832. Here is code for two changes to VMS Kermit 3.1.066.  In the diffs I changed
  10833. the version number to 3.1.067, but you should do whatever is appropriate with
  10834. that.  The first change is to the VMSMSG module to correct a bug with CRC mode.
  10835. Previously, if you sent 8 bit data without 8 bit quoting, the CRC would be
  10836. computed incorrectly, since the code stripped the high bit if parity was none.
  10837. The fix is just to reverse the condition and strip the high bit if the parity
  10838. is NOT none.  Diffs to the .MAR file are enclosed, but you should rebuild it
  10839. from the .BLI file instead - my changes are just hacks by hand, since I don't
  10840. have a BLISS compiler.
  10841.  
  10842. [Ed. - Code omitted, but added to KER:VMSMIT.BWR.]
  10843.  
  10844. The second change is optional, and is just my preference.  This change, to
  10845. the VMSMIT module, makes FINISH not cause the program to exit, but just to
  10846. return to the Kermit-32 prompt, so that, for example, statistics could
  10847. be printed.  This agrees with what C-Kermit does, but I believe Kermit-20
  10848. exits the program on a FINISH....  Remember not to even bother with the diffs
  10849. to the .MAR file if you have access to a Bliss-32 compiler - my changes are
  10850. definitely not what the compiler would do.
  10851.  
  10852. [Ed. - Code also omitted, but added to KER:VMSMIT.BWR.]
  10853.  
  10854. John Owens                UUCP:
  10855. General Electric Company          ...!decvax!mcnc!ncsu!uvacs!edison!jso
  10856. Factory Automated Products Division    Compuserve: 76317,2354
  10857. Charlotesville, VA            Phone:    (804) 978-5726
  10858.  
  10859. ------------------------------
  10860.  
  10861. Date: Sun, 27 Oct 85 21:44:59 pst
  10862. From: gts%ucbopal@columbia.arpa
  10863. Subject: CMS-Kermit Expanding Tabs on Receive
  10864.  
  10865. I struggled over whether to expand tabs during receive or not.  Clearly
  10866. leaving the file alone is more flexible for the experienced CMS user.
  10867. However, most of our users do not want to bring up XEDIT and EXPAND tabs on
  10868. every file they upload.  Most of the systems that use Kermit to send to CMS
  10869. use the tab8 convention and use it freely without the users direct knowledge
  10870. of it (msdos,cpm,unix).  I have decided to make tab expansion on receive the
  10871. default and use a modeless prefix to disable it.
  10872.  
  10873.  
  10874. INFO-KERMIT DIGEST V3 #27                                              Page 197
  10875.  
  10876. Also, that mod I submitted (UCB09) is flawed because it depends on being
  10877. able to overflow the ARBUF by 8 characters which is only OK because
  10878. CMS-Kermit 2.01 misallocates the buffer in the first place.  Please remove
  10879. UCB09 until I fix it.
  10880.  
  10881. Greg Small                                    (415)642-5979
  10882. Microcomputer Networking & Communications     gts@ucbopal.Berkeley.ARPA
  10883. 214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
  10884. University of California                      SPGGTS@UCBCMSA.BITNET
  10885. Berkeley, Ca 94720
  10886.  
  10887. ------------------------------
  10888.  
  10889. Date: Fri 25 Oct 85 13:14:50-EDT
  10890. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10891. Subject: C-Kermit on Diskette for Chromatics 7900?
  10892.  
  10893. Gina Morinaka of Hercules Aerospace in Utah needs to get C-Kermit on an
  10894. 8" diskette for the Chromatics 7900 workstation.  If you can help her,
  10895. please call 801-250-3776.
  10896.  
  10897. ------------------------------
  10898.  
  10899. End of Info-Kermit Digest
  10900.  
  10901. Page 198                                              INFO-KERMIT-DIGEST V3 #28
  10902.  
  10903. Info-Kermit Digest         Fri,  1 Nov 1985       Volume 3 : Number 28
  10904.  
  10905. Departments:
  10906.  
  10907.   ANNOUNCEMENTS -
  10908.     Pascal/VS Kermit/CMS
  10909.     7171 Support for IBM Mainframe MUSIC Kermit
  10910.     Another Kermit for Intel Micro Development Systems
  10911.  
  10912.   MISCELLANY -
  10913.     We Are Working on a Robust Kermit for IBM MVS/XA TSO
  10914.     7171/Series 1 and Kermit-MS interaction
  10915.     Problems with New HP-110 MS-DOS Kermit Support
  10916.     Commodore-64 Kermit V1.7
  10917.  
  10918.   QUERIES -
  10919.     Need Kermit Diskette for IBM PC with Xenix
  10920.     Need Kermit 3.5" Diskette for HP-9816
  10921.     Need Kermit Diskette for HP-9000/S500 HP-UX System
  10922.  
  10923. ----------------------------------------------------------------------
  10924.  
  10925. Date:    Thu, 31 Oct 85 10:06 EST
  10926. From:    VIC@QUCDN.BITNET
  10927. Subject: Pascal/VS Kermit/CMS
  10928.  
  10929. I am sending you an updated source for my Pascal KERMIT/CMS along with an
  10930. updated FULLSERV ASSEMBLE file.  The new source will handle some additional
  10931. server commands and fixes some minor bugs.  A major bug shows up when using
  10932. the old KERMIT source with the newer version of the PASCALVS compiler which
  10933. does a more careful checking of strings.  The updated source will correct
  10934. this fault.
  10935.  
  10936. [Ed. - The files are in KER:CM2*.* on CU20B, available as usual via
  10937. anonymous FTP.]
  10938.  
  10939. ------------------------------
  10940.  
  10941. Date: 24 October 1985, 16:58:52 EST
  10942. From: SYSBJAV%TCSVM.BITNET@UCB-VAX.Berkeley.EDU
  10943. Subject: 7171 Support for IBM Mainframe MUSIC Kermit
  10944.  
  10945. Here is a new version of KERMIT for MUSIC (IMUSIC), based on the
  10946. Indiana/Purdue original, but with support for the 7171 front end added,
  10947. approved by the original author Marie Schriefer at INDYVM.
  10948.                                                     J.V.
  10949.  
  10950. [Ed. - The files are on CU20B as KER:IMUSIC.*.]
  10951.  
  10952. ------------------------------
  10953.  
  10954. Date: Fri 1 Nov 85 4:21pm EST
  10955. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  10956. Subject: Another Kermit for Intel Micro Development Systems
  10957.  
  10958. This is to announce yet another version of Intel Microcomputer Development
  10959.  
  10960. INFO-KERMIT-DIGEST V3 #28                                              Page 199
  10961.  
  10962. System (MDS) Kermit, for the ISIS operating system, written in PL/M.  It's
  10963. an upgrade to the original version, and adds the ability to talk to a Kermit
  10964. server (GET, FINISH, BYE, (remote) CWD) and a way to send multiple files
  10965. using a special command LSEND that reads the list of files to send from the
  10966. specified file.  It was submitted by
  10967.  
  10968.   Hanh Tuan Truong
  10969.   Leigh Instruments ltd.
  10970.   2680 Queensview Dr.
  10971.   Ottawa, Ontario
  10972.   K2B-8J9 CANADA
  10973.  
  10974. The files are in KER:MD2*.* on CU20B.  The MDS*.* files are still there too.
  10975. It seems that this new version is based on the original release of MDS
  10976. Kermit, which in the interim was updated & fixed at Intel's DSSO department.
  10977. If anyone who cares about these systems would care to do a comparitive
  10978. review for Info-Kermit, it would be most welcome.  Better still would be an
  10979. integration of the two programs into a single one.
  10980.  
  10981. ------------------------------
  10982.  
  10983. Date: 29 Oct 85 1500 WEZ
  10984. From: U02F%CBEBDA3T.BITNET@WISCVM.ARPA  (Franklin A. Davis)
  10985. Subject: We Are Working on a Robust Kermit for IBM MVS/XA TSO
  10986.  
  10987. We have a robust version of Kermit for TSO systems that is adapted from the
  10988. CMS Pascal Kermit.
  10989.  
  10990. It includes server mode with most of the possible remote commands.  In local
  10991. mode you can execute TSO commands from within Kermit.  Coming soon will be
  10992. wildcards, though that is tough on an IBM...
  10993.  
  10994. MVS and CMS are so different that it will not be possible to have a single
  10995. version for both systems.  However, Fritz will be maintaining it for at
  10996. least the next couple of years.
  10997.  
  10998. Anyone interested in 'Beta test' of TSO kermit, please contact us directly.
  10999.  
  11000. -- Fritz & Franklin <U02F@CBEBDA3T.BITNET>
  11001. Institut fuer Informatik und angewandte Mathematik
  11002. Universitaet Bern
  11003. Laenggassstrasse 51
  11004. CH-3012  Bern
  11005. Switzerland
  11006.  
  11007. [Ed. - How about Series/1 (4994, 7171, ...) front-end support?  We're
  11008. getting such a proliferation of MVS/TSO IBM mainframe Kermits -- versions in
  11009. assembler, Pascal, and PL/I, with and/or without Series/1 support, ...
  11010.  
  11011. 1. U of Chicago's, based on Columbia's original (primitive) CMS Kermit, only
  11012.    for use on line-mode TTYs.
  11013.  
  11014. 2. U of Toronto's, based on Chicago's but only for use thru Series/1 or 7171.
  11015.  
  11016. 3. Rice University's, supposedly fancy, in PL/I, but you have to buy their
  11017.    support functions from them.
  11018.  
  11019. Page 200                                              INFO-KERMIT-DIGEST V3 #28
  11020.  
  11021.  
  11022. 4. University of Maryland is working on yet another completely different,
  11023.    fancy TSO Kermit (in assembler?).
  11024.  
  11025. 5. And now this one.  Not to mention the two versions for VM/CMS; when it
  11026.    rains...]
  11027.  
  11028. ------------------------------
  11029.  
  11030.  
  11031. Date: Fri, 01 Nov 85 11:05:31 cet
  11032. From: PCSC%WUVMD.BITNET@WISCVM.ARPA
  11033. Subject: 7171/Series 1 and Kermit-MS interaction
  11034.  
  11035. We have found that our new 7171 protocol converters work much less well for
  11036. us than the Series 1 boxes for Kermit file uploading with the newer
  11037. generation of IBM-like PCs.  The symptoms are a 7171 hang up when uploading
  11038. files from the PC AT or Zenith 158s over 9600 bps direct connect lines.  We
  11039. have been using Kermit heavily for about a year, and normally these devices
  11040. upload fine, but if the Kermit-MS 2.28 they are running is YAKing faster
  11041. than normal due to (1) use of a mono screen (2) use of a faster crystal (3)
  11042. use of FANSI-CONSOLE to speed screen writing, then the 7171 hangs in a
  11043. pretty big way.  Multiple master resets must be sent to the 7171 to get
  11044. session control back again.  If one SETs DEBUG ON in Kermit-MS, then the
  11045. time spent writing the packets to a color screen slows things down enough
  11046. to work unless FANSI-CONSOLE is in there speeding things up again.  The
  11047. evidence is as follows:
  11048.  
  11049. Connected through 7171 to Kermit-CMS 2.01:
  11050. IBM PC AT, 8mhz, EGA & ECD, with DEBUG OFF --> failure
  11051. IBM PC AT, 8mhz, EGA & ECD, with DEBUG ON  --> success
  11052. As above w/ FCONSOLE, DEBUG ON or OFF      --> failure
  11053. Zenith 158, 8mhz, monochrome, DEBUG ON|OFF --> failure
  11054. Zenith 158, 8mhz, color, DEBUG OFF         --> failure
  11055. Zenith 158, 8mhz, color, DEBUG ON          --> success
  11056.  
  11057. Connected through a Series 1 all of the above succeed.  The SEND PACKET in
  11058. all cases was 64 since the 7171's won't work from my AT under any
  11059. conditions with a larger size.  The only conclusion I have been able to
  11060. draw is that the slow screen writing routines of the color BIOS slow
  11061. Kermit-MS down enough such that when DEBUG is ON the YAK packet from
  11062. Kermit-MS does not go back until the 7171 is ready.  I assume this is
  11063. because the incoming packet is being written to the screen before the YAK
  11064. is sent (though I have not checked the Kermit code to verify this).  I am
  11065. inferring that the problem is due to the 7171 because (1) it works through
  11066. the Series 1 (2) many Master Resets are required to wrest control back, but
  11067. conceivably the issue is one of CMS Kermit's control of the 7171 rather
  11068. than the box's internals.
  11069.  
  11070. Any suggestions or relevant experiences would be appreciated.
  11071. Michael Palmer
  11072. Washington University Computing Facilites
  11073. Bitnet address:  PCSC@WUVMD
  11074.  
  11075. ------------------------------
  11076.  
  11077.  
  11078. INFO-KERMIT-DIGEST V3 #28                                              Page 201
  11079.  
  11080. Date: 26 Oct 1985 2242-EDT
  11081. From: LCG.KERMIT@DEC-MARLBORO
  11082. Subject: Problems with New HP-110 MS-DOS Kermit Support
  11083.  
  11084. Took the new version of MSXHPX.ASM last night.  Unfortunately, in being
  11085. compatible with both the 110 and the PLUS, it develops several problems on
  11086. the plus.  In particular:
  11087.  
  11088. 1. PORT 2 is set to AUX.  On the plus, this is not the INTERNAL MODEM
  11089. necessarily, but is the default modem set in the system configurator.  To
  11090. insure that the internal modem is used, the PORT selection logic should
  11091. select COM3, not AUX.
  11092.  
  11093. 2. All character output is being sent to the punch via MSDOS PUNOUT call.
  11094. This is slow, and, worse, will direct output to AUX even if the serial port
  11095. is in use.
  11096.  
  11097. 3. Minor points: the program starts with even parity and 7 bit words.  This
  11098. causes chaos in every situation we tried.
  11099.  
  11100. Changes are shown below by giving at least one line before and after each
  11101. change.  Would appreciate your forwarding to appropriate authority.
  11102.  
  11103. Also, leaving DTR on on the PLUS is not just a nuisance, it is deadly, since
  11104. you also leave on the MODEM or SERIAL interface, which eats the battery at
  11105. incredible rates.  I have attached to the end of this a short program to
  11106. turn those off.  I run KERMIT on the plus from a command file KERMIT.BAT
  11107. which contains the following:
  11108.  
  11109.     MSXHPX 1%
  11110.     MODEMOFF
  11111.  
  11112. This guarantees modem/serial port doesn't run down battery.
  11113.  
  11114. Mike Mellinger  800-325-0888
  11115.  
  11116. Modified MSXHPX follows:
  11117.  
  11118. [Ed. - Code omitted, included in KER:MSXHPX.BWR for now; see next message.]
  11119.  
  11120. ------------------------------
  11121.  
  11122. Date: Mon, 28 Oct 85 23:08:28 mst
  11123. From: dwf%b@LANL.ARPA (Dave Forslund)
  11124. Subject: Re: Problems with New HP-110 MS-DOS Kermit Support
  11125.  
  11126. In response to the problems with MSXHPX on the Portable Plus:
  11127.  
  11128. 1. We felt the choice of the AUX port was an advantage because one could
  11129. also choose the HP-IL loop RS-232 interface from the PAM without having to
  11130. add an additional port in kermit itself.  It is true to use the modem with
  11131. Kermit one must have selected it in the PAM.  However, if it is selected
  11132. then port 1 is the serial port and port 2 is the modem (or HP-IL RS-232).
  11133. Choosing COM3 for the Portable makes the code incompatible with the HP-110.
  11134.  
  11135. 2. We used this call as it was in the generic Kermit.  We will try this
  11136.  
  11137. Page 202                                              INFO-KERMIT-DIGEST V3 #28
  11138.  
  11139. suggested fix.
  11140.  
  11141. 3. Our choice of even parity and 7 bit words is what works on our network
  11142. here at Los Alamos and avoided us having to have a .ini file to modify the
  11143. defaults.  If others like other defaults, so be it.
  11144.  
  11145. 4. Thanks for the modemoff file.  It will be a big help.
  11146.  
  11147. By the way, for this code to work properly on the internal modem in the
  11148. HP110 still requires some work, as the modem does not respond
  11149. conversationally but requires special ioctl commands to dial, etc.  We have
  11150. not pursued this any further.
  11151.  
  11152. Dave (dwf@lanl.arpa)
  11153.  
  11154. ------------------------------
  11155.  
  11156. Date: Sat 26 Oct 85 13:05:13-EDT
  11157. From: RP0Q@TD.CC.CMU.EDU
  11158. Subject: Commodore-64 Kermit V1.7
  11159. To: remarks@TD.CC.CMU.EDU
  11160.  
  11161. Kermit 1.7 for the Commodore 64 is completely non-functional.  There is a
  11162. bug in the VT52 emulation routines which crashes the program every time I
  11163. attempt to use Emacs.  This same bug crashes the program whenever I try to
  11164. send or receive a file, since the current packet, number of packets sent,
  11165. etc, are displayed on the screen using the same routines.  Does a quick fix
  11166. exist for this problem, or do I have to wait for the next version of Kermit
  11167. for the problem to be fixed.  As it stands, Kermit 1.7 is completely useless
  11168. for file transfer.  HELP!!!!
  11169.  
  11170.                 Roger Preisendefer
  11171.                 RP0Q @ CMU-CC-TD
  11172.  
  11173.  
  11174. [From Eric <LAVITSKY@BLUE.RUTGERS.EDU> - C64 Kermit-65 V1.7 works fine at
  11175. 300 baud or 1200 baud.  There are no bugs in the VT52 emulation, and no
  11176. 'serious' (or well known) bugs in the file transfer routines.  Chances are
  11177. this person did not download the files correctly to his C64 - I use Kermit
  11178. with Emacs extensively and send files all the time with much sucess.  I
  11179. suggest that this person send away to Robert Lenoil for a C64 Kermit
  11180. diskette -- 229 Commonwealth Ave, Boston MA 02116 -- $7.00 incl postage.]
  11181.  
  11182. ------------------------------
  11183.  
  11184. Date: Tuesday, 29 October 1985 07:30:30 EST
  11185. From: Duvvuru.Sriram@cive.ri.cmu.edu
  11186. Subject: Need Kermit Diskette for IBM PC with Xenix
  11187.  
  11188. I would like to have a kermit on my IBM PC running under Xenix (and
  11189. talk to the MS-DOS PC).  Where can I get a copy of one?
  11190.  
  11191. Sriram
  11192.  
  11193. ------------------------------
  11194.  
  11195.  
  11196. INFO-KERMIT-DIGEST V3 #28                                              Page 203
  11197.  
  11198. Date: Tue 29 Oct 85 14:28:43-EST
  11199. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  11200. Subject: Need Kermit 3.5" Diskette for HP-9816
  11201.  
  11202. Marilyn Evans, Polaroid Corp, Cambridge MA, 617-577-3662 or -2262, needs
  11203. Kermit for the HP-9816.  She thinks the HP-Pascal version that was written
  11204. for the 9836 a while back might work.  Could anyone send it to her on a
  11205. 3.5" diskette so she can try it out?  Thanks!
  11206.  
  11207. ------------------------------
  11208.  
  11209. Date: Tue 29 Oct 85 11:39:33-PST
  11210. From: David Liu <DLIU@SU-SIERRA.ARPA>
  11211. Subject: Need Kermit Diskette for HP-9000/S500 HP-UX System
  11212.  
  11213. Is there anyone ever installed and run Kermit on HP-9000/500 computer (which
  11214. runs HP-UX)?  This is what I am trying to do and may save me some of the
  11215. efforts if I can get some advise.
  11216.  
  11217. Dave Liu@SIERRA-SU
  11218.  
  11219. [Ed. - Again, the best thing would be for someone to send him a diskette.
  11220. Any volunteers?  (Contact Dave directly)]
  11221.  
  11222. ------------------------------
  11223.  
  11224. End of Info-Kermit Digest
  11225.  
  11226. Page 204                                              INFO-KERMIT DIGEST V3 #29
  11227.  
  11228. Info-Kermit Digest         Wed, 13 Nov 1985       Volume 3 : Number 29
  11229.  
  11230. Today's Topics:
  11231.                            Kermit the Frog
  11232.                            Kermit the Book
  11233.                          New Kermit-11 Coming
  11234.                          Kermit for NEC APC-3
  11235.            C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD
  11236.                  Okstate's Kermit Server Active Again
  11237.        Binary File Transfer Between C-Kermit and VMS Kermit-32
  11238.                   Kermit Problems, Notes and Praises
  11239.                       Osborne Executive Kermit?
  11240.                           Kermit & MUSIC SP
  11241.  
  11242. ----------------------------------------------------------------------
  11243.  
  11244. Date: Tue 12 Nov 85 15:26:44-EST
  11245. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  11246. Subject: Kermit the Frog
  11247.  
  11248. The new (December 1985) MACWORLD Magazine features a cover story on Kermit
  11249. -- no, not Kermit the file transfer protocol, but Kermit the Frog, the
  11250. proprietor of a whole new line of Muppet-based educational software.
  11251. "Kermit" is a trade mark for some of this software, like "Kermit's
  11252. Electronic Story Maker."  This is one among the many good reasons why "our"
  11253. Kermit should (and can) not become a commercial product.
  11254.  
  11255. ------------------------------
  11256.  
  11257. Date: Wed 13 Nov 85 17:02:22-EST
  11258. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  11259. Subject: Kermit the Book
  11260.  
  11261. I'm writing a Kermit book for Digital Press.  I hope it will be out in
  11262. Spring or Summer 1986, and I hope the price will be relatively low (it
  11263. can't be set yet, because the manuscript isn't done, but there is general
  11264. agreement that it should not be a high-priced item).  I hope the book will
  11265. be a big improvement over the Kermit User Guide and Protocol Manual; it
  11266. will contain all the information from these manuals, plus a lot more --
  11267. background in data communications, file organization, etc; more cohernet
  11268. organization, lots of illustrations, tables, code fragments, etc etc.  But
  11269. it will lack the detailed descriptions of the various Kermit programs found
  11270. in the User Guide; that information will continue to be supplied along with
  11271. each program.  Anyhow, the idea is for the book to "work" for everyone from
  11272. the utter novice to the Kermit programmer, pehaps in conjunction with a
  11273. program-specific handout, and to promote Kermit a little more as a serious
  11274. protocol and maybe encourage future Kermit program contributors to stick to
  11275. the "standard" command syntax a little better and provide code examples to
  11276. make it easy for them to include server mode, 8th-bit quoting, etc etc.
  11277.  
  11278. Preparing the manuscript, plus doing my "real job," is keeping me pretty
  11279. busy, which partly explains the lag between Info-Kermits (the rest of the
  11280. explanation is that there hasn't been a lot of activity recently anyway).
  11281. Occasionally I might bother someone for a bit of specific information to
  11282. round out some table or other.  Here's one tidbit I haven't been able to
  11283. dig up anywhere -- what multiplexing technique is used by VA-3400 1200bps
  11284.  
  11285. INFO-KERMIT DIGEST V3 #29                                              Page 205
  11286.  
  11287. modems (frequency division?) and at what baud rate does it transmit (some
  11288. 1200bps modems actually transmit at 600 baud).  Here's another one -- does
  11289. anyone know the etymology of "D-Connector" or "DB-xx" (as in DB-25)?
  11290.  
  11291. Also, if anyone wants to fill in the following questionnaire and send it
  11292. back to me, I'd be most grateful.  This is just for purposes of filling in
  11293. some illustrative tables, contrasting the diverse communication and
  11294. file architectures of various machines and OS's.  I've already got info
  11295. for the common ones, like DEC-20, VAX/VMS, IBM VM/CMS, MS-DOS, etc etc, but
  11296. am looking more for the "strange" ones -- HP minis, DG minis, P-E minis,
  11297. Prime computers, mainframes of Burroughs, Honeywell, Sperry, CDC, etc.
  11298.  
  11299. Machine, Model(s):
  11300. Operating System:
  11301. Version of OS following info applies to, if it makes a difference:
  11302. Machine Word Size:
  11303.  
  11304. Text Byte Size, and how many bits within byte are used for a character, and
  11305. what happens to any leftover bits:
  11306.  
  11307. Directory structure (flat file system, 1 level of directory, hierarchical):
  11308.  
  11309. Filespec format (indicate punctuation and max length of each field, e.g.
  11310. DEV:[DIR]NAME.EXT;n with DEV=6, DIR=12, NAME=8, EXT=3, n=numeric generation.
  11311.  
  11312. Text code: (7-bit ASCII, 8-bit extended ASCII, 8-bit EBCDIC, etc):
  11313.  
  11314. Normal record separation technique for text files (CRLF, LF, CR, RCW, fixed
  11315. block, etc):
  11316.  
  11317. EOF indication (nearest character, word, block); what happens at EOF if
  11318. EOF not recorded exactly (e.g. CP/M ^Z trick):
  11319.  
  11320. Asynchronous Communications (But first please indicate if the system
  11321. normally prefers some other style, like IBM-style synchronous block mode
  11322. terminals):
  11323.  
  11324. Duplex (full, half):
  11325.  
  11326. Flow Control (half duplex line turnaround handshake char, XON/XOFF, ENQ/ACK,
  11327. ETX/ACK, etc):
  11328.  
  11329. Required or default parity:
  11330.  
  11331. Special or unusual characteristics worth noting about file system,
  11332. text representation, or communications:
  11333.  
  11334.  
  11335. Thanks to anyone who responds!  Also, any suggestions of a general (or
  11336. specific) nature would be most welcome, especially from people who have had
  11337. problems with some aspect of Kermit that could have been avoided by better
  11338. documentation.
  11339.  
  11340. - Frank
  11341.  
  11342. ------------------------------
  11343.  
  11344. Page 206                                              INFO-KERMIT DIGEST V3 #29
  11345.  
  11346.  
  11347. Date: 8 Nov 1985
  11348. From: BRIAN@UOFT02.BITNET
  11349. Subject: New Kermit-11 Coming
  11350.  
  11351.  There currently is a version 2.38 of Kermit-11 available.  The version will
  11352. only be available via Bitnet or dialup to UOFT02 until December 85 as I am
  11353. waiting for modifications from some other people regarding M+ v3 and also
  11354. PRO/TMS support. As always, the file K11CMD.MAC has the edit trail.
  11355.  
  11356. How to get it:
  11357.  
  11358. Bitnet:
  11359.  
  11360. from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
  11361.                 CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*
  11362.  
  11363. from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*
  11364.  
  11365. Dialup:
  11366.  
  11367.         (419) 537-4411
  11368.         Service class  VX785A
  11369.         User: KERMIT
  11370.         Password: KERMIT
  11371.  
  11372. Source and hex files are in KER:, binaries are in KERBIN:
  11373.  
  11374. [Ed. - I imagine Brian will be sending the successor to 2.38 to Columbia
  11375. when it's ready; will announce it when it arrives.]
  11376.  
  11377. ------------------------------
  11378.  
  11379. Date: Fri, 8 Nov 85 13:55:55 est
  11380. From: Phil Johnson <johnson@LL-XN.ARPA>
  11381. Subject: Kermit for NEC APC-3
  11382.  
  11383. Since you had the source but not the binary for NEC APC-3 Kermit,
  11384. I built the binary for you.
  11385.  
  11386. Phil Johnson
  11387.  
  11388. [Ed. - Thanks!  It's in KER:MSVAP3.BOO ("boo" file) and KB:MSVAP3.EXE
  11389. (8-bit binary).]
  11390.  
  11391. ------------------------------
  11392.  
  11393. From: Vic Abell <abe@purdue-asc.ARPA>
  11394. Date:  8 Nov 1985 1438-EST (Friday)
  11395. Cc: abe@purdue-asc.arpa, ach@purdue-asc.arpa, acu@purdue-asc.arpa
  11396. Subject: C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD
  11397.  
  11398. C-kermit 4C(057) does not work properly with 2.9BSD, as distributed
  11399. by Berkeley.  It may work with the Harvard, Seismo distribution, but
  11400. I haven't tested that.
  11401.  
  11402.  
  11403. INFO-KERMIT DIGEST V3 #29                                              Page 207
  11404.  
  11405. One problem is that the Berkeley 2.9BSD distrubution does not support
  11406. the 4.2BSD timeval and timezone structures and the functions that
  11407. surround them.  Thus, all of the #if tests in ckutio.c that assume
  11408. 2.9 to 4.2 equivalence in that area must be undone.
  11409.  
  11410. A second problem is that the protocol rule for <rdata>Z in ckcpro.w
  11411. tests for a return value from the function reof() in ckcfns.c  Reof()
  11412. does not return a value.  The protocol rule works on 4.2BSD out of
  11413. happenstance - apparently the return value register happens to be
  11414. non-negative.  Under 2.9BSD it doesn't work - apparently because
  11415. the return value register happens to be negative.
  11416.  
  11417. I am enclosing diffs that show the changes necessary to eliminate
  11418. these two problems.  The diffs for ckcpro.w also include a fix to the
  11419. <rfile>B protocol rule that I reported earlier to this mailing group.
  11420. It prevents the EOT ack from being lost in interactive mode when the
  11421. terminal is switched from cbreak to cooked.  Note that the sleep time
  11422. was raised to five seconds on the slower 11/70s.
  11423.  
  11424. Vic Abell, abe@asc.purdue.edu
  11425.  
  11426. [Ed. - Thanks!  Diffs omitted, appended to KER:CKUKER.BWR, will be
  11427. included in the next release.]
  11428.  
  11429. ------------------------------
  11430.  
  11431. Date: Sun, 10 Nov 85 17:42:19 CST
  11432. From: Gregg Wonderly <gregg%okstate.csnet@CSNET-RELAY.ARPA>
  11433. Subject: Okstate's Kermit Server Active Again
  11434.  
  11435.     Due to an obscure bug in some modifications made to the KERMIT SERVER at
  11436. OKSTATE, the server has not been able to service GET requests from users.
  11437. This problem has been located, and fixed.  We appologize for any headaches
  11438. caused (We had a few here in finding this one).  Thanks to those who pointed
  11439. the problems out initially.
  11440.  
  11441. Gregg Wonderly
  11442. Department of Computing and Information Sciences
  11443. Oklahoma State University
  11444.  
  11445. UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
  11446. ARPA:  gregg%okstate.csnet@csnet-relay.arpa
  11447.  
  11448. ------------------------------
  11449.  
  11450. Date: Fri, 1 Nov 85 21:55:26 pst
  11451. From: daver@cit-vax.ARPA (David Robinson)
  11452. Subject: Binary File Transfer Between C-Kermit and VMS Kermit-32
  11453.  
  11454. I am having troubles transfering files to and from a SUN-2/170 running
  11455. Ckermit 4C(57) and a VAX/VMS3.7 running Kermit-32(66).
  11456.  
  11457. Transfering both ways one side or the other is mapping ALL ^J's to ^M's
  11458. which reaks havic on my binary data.  I have set file type to binary on
  11459. both machines with no success.  When I set file type fixed on the VAX (A
  11460. suggestion from a friend) The file makes it thru the data transfer part but
  11461.  
  11462. Page 208                                              INFO-KERMIT DIGEST V3 #29
  11463.  
  11464. dies on the final handshaking with an error "unimplemented server command".
  11465.  
  11466. We are constrained to use only the VAX as a server, our connection allows
  11467. logins only on the VAX side.
  11468.  
  11469. Any and all help on this problem would be appreciated.
  11470.  
  11471. "How to get raw binary files from Ckermit to kermit-32?"
  11472.  
  11473.                 David Robinson
  11474.                 daver@cit-vax.arpa
  11475.  
  11476. [Ed. - I've heard complaints like this before, but don't have a VMS system
  11477. to track them down with, and the folks at Stevens Inst of Tech are badly
  11478. bogged down in other work for the time being.  Anybody out there can help?]
  11479.  
  11480. ------------------------------
  11481.  
  11482. Date: Wed 6 Nov 85 21:25:42-EST
  11483. From: Christopher Lent  (LENT@CUPHOA.CCNET)
  11484. Subject: Kermit Problems, Notes and Praises
  11485.  
  11486. PROBLEMS:
  11487. *****
  11488. MSRVRB1.BOO - MS-DOS Rainbow-100 boot file.
  11489. The first line of KER:MSVRB1.BOO contains:
  11490.     KER:MSRB10.EXE
  11491. rather than
  11492.     MSVRB1.EXE
  11493. A minor oops but it could give a first time user a problem.
  11494.  
  11495. [Ed. - Thanks, I fixed it.]
  11496.  
  11497. *****
  11498. MSSDEF.H - MS-DOS KERMIT macro assembler (MASM) source header file.
  11499.     Perhaps a stronger warning should be included that KER:MSSDEF.H
  11500. must be renamed to MSDEFS.H before compiling.
  11501.  
  11502. [Ed. - Thanks, I put warnings in appropriate places.]
  11503.  
  11504. *****
  11505. MSIBMP.EXE - Compiling your own:
  11506. I compiled MSIBMP.EXE on an IBM/PC-XT using V2.0 MASM with the suggested /S
  11507. option and have experienced no problems with the resultant V2.28 IBM-PC KERMIT.
  11508. *****
  11509.  
  11510. notes:
  11511. +++++
  11512. MSIBMP.EXE - IBM/PC KERMIT through a DECServer 100:
  11513.     I have been using KERMIT V2.27 and now V2.28 through DEC's new
  11514. DECServer 100 terminal server.  All I can say is WOW!!  The configuration
  11515. consists of a VAX-11/780 with VMS 4.1 running KERMIT-32 V3.1.066 and IBM/PC's,
  11516. and XT's running PC-DOS 3.1 and KERMIT V2.27 and V2.28.
  11517.  
  11518.     Kermit works fine with the initial settings on the terminal server.
  11519. The server doesn't interfere with the KERMIT protocol.  KERMIT file transfers
  11520.  
  11521. INFO-KERMIT DIGEST V3 #29                                              Page 209
  11522.  
  11523. exhibit no visible loading of either the terminal server or VMS, even at 19.2K
  11524. baud.  The local CWD command has greatly aided doing incremental PC/XT backups
  11525. to corresponding VMS directories.
  11526. +++++
  11527. Note - Converting "BINARY" Text files on VAX/VMS created by KERMIT-32.
  11528.  
  11529.     Most users doing backups of PC's to our VAX use the KERMIT-32 SET
  11530. FILE TYPE BINARY option so the .COM and .EXE files will transfer properly.
  11531. This results in a minor problem when text file transferred as "BINARY" files
  11532. are to be edited or revised on the VAX.  A workaround procedure for this
  11533. follows using the age-old editor TECO.  Since TECO's calling sequence has
  11534. changed in VMS 4.x two versions are given.
  11535.  
  11536. VMS 3.x:
  11537.  
  11538. $ ! Untested
  11539. $ TECO :== $SYS$SYSTEM:TECO.EXE
  11540. $TOP:
  11541. $if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
  11542. $if "''p1'" .eqs. "" then goto TOP
  11543. $WRITE SYS$OUTPUT "Converting file ''p1' to text format."
  11544. $! the line after edit/teco 'p1' should contain EX<ESC><ESC>
  11545. $! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
  11546. $TECO 'p1'
  11547. EX$$
  11548. $write sys$output "File ''p1' converted to text format."
  11549. $exit
  11550.     
  11551. VMS 4.x
  11552.  
  11553. $! Works!
  11554. $TOP:
  11555. $if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
  11556. $if "''p1'" .eqs. "" then goto TOP
  11557. $WRITE SYS$OUTPUT "Converting file ''p1' to text format."
  11558. $! the line after edit/teco 'p1' should contain EX<ESC><ESC>
  11559. $! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
  11560. $edit/teco 'p1'
  11561. EX$$
  11562. $write sys$output "File ''p1' converted to text format."
  11563. $exit
  11564.  
  11565. Usage:
  11566.     If the above file is called CVT.COM in the current directory
  11567. simply type type following to convert the "BINARY" text file FILE.BIN
  11568.     $ @CVT.COM FILE.BIN
  11569. and the new version of file.bin will be in VMS's default text file format.
  11570.  
  11571. Beware:
  11572.     If the "BINARY" text file has lines which exceed 255 characters,
  11573. VMS's EDIT/EDT editor will truncate these lines during editing.
  11574. +++++
  11575. Praises:
  11576. #####
  11577. Ckermit - general praises
  11578.     Nice Job!!!  I was previously using the version now relegated to the
  11579.  
  11580. Page 210                                              INFO-KERMIT DIGEST V3 #29
  11581.  
  11582. to the documentation.  The new version work fabulously on our AT&T 3b5
  11583. computer.   I've even managed to get a version running on a V6 UNIX system.
  11584. The V6 version was compiled using a modified V7 compiler so I doubt it would
  11585. be of any use to others.  With quite a bit of emulating V7 system calls,
  11586. I produced a working version of Ckermit.  Just a warning, in split I/D spaces
  11587. on the PDP-11, some V6 system calls do NOT work.
  11588. #####
  11589. Final comments:
  11590.     Kermit is fabulous.  I now try to get it to friends as a matter of
  11591. course.  At first they're a little confused as to why they need Kermit, but
  11592. about a month after they come back and say "Wow, how can I get Kermit for
  11593. machine XYZ-123/X?" and we figure out how to load the initial copy.
  11594.     I must admit I'm a convert.  When I originally read about Kermit in
  11595. BYTE, I thought "Oh, yet another ASCII file transfer package".  Reading on I
  11596. thought, "Hmm, sounds pretty easy to implement".  Then I put these thoughts on
  11597. the back burner for a few years.
  11598.     In March of 1985, I found Kermit source on a FIDO BBS system and tried
  11599. it on the PC.  It worked wonderfully. They also had 'C' source for a Unix
  11600. Version of Kermit. I loaded it on our 3b5 and our V6 system and it worked with
  11601. only minor modifications. The BYTE articles made the debugging much more
  11602. simple.
  11603.                     Keep up the good work!
  11604.                     Chris Lent
  11605.                     lent@cuphoa.ccnet
  11606.                     Care of:
  11607.                     oc.pedhem@cu20b
  11608.  
  11609. ------------------------------
  11610.  
  11611. Date: Wed, 6 Nov 85 20:38:02 pst
  11612. From: George Cross <cross%wsu.csnet@csnet-relay.arpa>
  11613. Subject: Osborne Executive Kermit?
  11614.  
  11615. Can someone inform me of the status of the Osborne Executive version
  11616. of Kermit?  Browsing through the mail archives (83/84 Epoch) one finds
  11617. a flurry of interest when the OE  was alive but it seems to have faded
  11618. out.  My questions are:
  11619.  
  11620. 1. Does the Osborne 1 version work on the Osborne Executive?
  11621. 2. Does the Generic CPM version work on the Executive? If so how?
  11622.  
  11623. I don't receive this list regularly, so a mail reply to me would be preferred.
  11624. Thanks,
  11625.  
  11626.  George R. Cross        cross@wsu.CSNET
  11627.  Computer Science Department    cross%wsu@csnet-relay.ARPA
  11628.  Washington State University    faccross@wsuvm1.BITNET
  11629.  Pullman, WA      99164-1210    Phone: 509-335-6319 or 509-335-6636
  11630.  
  11631. ------------------------------
  11632.  
  11633. Date: Fri, 08 Nov 85 08:57:21 cet
  11634. From:  PCSC%WUVMD.BITNET@WISCVM.ARPA
  11635. Subject: Kermit & MUSIC SP
  11636.  
  11637. Does anyone know if Kermit-MUSIC 1.0 is compatible with the new
  11638.  
  11639. INFO-KERMIT DIGEST V3 #29                                              Page 211
  11640.  
  11641. release of MUSIC (MUSIC SP)?  I realize that it contains its own
  11642. communications program PCWS, but sites with several operating systems
  11643. like ours would prefer to use one program (Kermit!) for all
  11644. micro to mainframe communication if possible.
  11645.  
  11646. Michael Palmer, Washington University Computing Facilities
  11647. BITNET address:  PCSC@WUVMD
  11648.  
  11649. ------------------------------
  11650.  
  11651. End of Info-Kermit Digest
  11652.  
  11653. Page 212                                              INFO-KERMIT DIGEST V3 #30
  11654.  
  11655. Info-Kermit Digest         Wed, 20 Nov 1985       Volume 3 : Number 30
  11656.  
  11657.                             BITNET Things
  11658.                      Kermit Over Public Networks?
  11659.                         Kermit for the HP-87?
  11660.                 MVS/TSO Kermit with Protocol Converter?
  11661.                         Kermit for Tandy 6000?
  11662.                            Cromix Kermit???
  11663.  
  11664. ----------------------------------------------------------------------
  11665.  
  11666. Date: Wed 20 Nov 85 18:44:10-EST
  11667. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  11668. Subject: BITNET Things
  11669.  
  11670. Due to a change that was made in CU20B's host tables some time between Oct 24
  11671. and Oct 29, Info-Kermit mail destined for BITNET was lost.  The affected
  11672. issues were V3, Numbers 27, 28, and 29.  The problem is now fixed.  I will
  11673. remail these three issues to all the BITNET members after this issue goes out.
  11674. Sorry for the inconvenience.
  11675.  
  11676. Speaking of BITNET, those who access the Kermit file collection via the
  11677. BITNET Kermit file server, KERMSRV at CUVMA, may have noticed two things, one
  11678. good, one bad: (a) the KERMSRV server itself has been behaving a lot better
  11679. lately, and (b) the Kermit files have not been updated in several weeks to
  11680. reflect recent announcements.  (a) is because our IBM systems folks have
  11681. been working on KERMSRV, mostly in an effort to reduce network overhead by
  11682. queuing files according to length, discarding duplicated requests etc.  An
  11683. announcement about exactly what was done should appear shortly.  In the
  11684. meantime, send the HELP command to KERMSRV to learn about any changes or
  11685. new commands.  (b) is because the person who used to keep the BITNET area up
  11686. to date has changed jobs and has not been replaced yet; I hope the situation
  11687. will be remedied soon.
  11688.  
  11689. ------------------------------
  11690.  
  11691. Date: Wed 20 Nov 85 18:44:10-EST
  11692. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  11693. Subject: Kermit Over Public Networks?
  11694.  
  11695. I know this has been hashed over before several times in the past, but I'd
  11696. like the gather all the relevent information together into one place
  11697. (the Kermit book)...  What experiences have people had using Kermit over
  11698. the public networks?  These include Tymnet, Telenet, Uninet, Datapac,
  11699. Transpac, Datex-P, and all the ones I don't even know about.  Here's a short
  11700. questionnaire:
  11701.  
  11702. Name of Network (spelled and capitalized as the vendor prefers):
  11703.  
  11704. Company or Organization that "owns" it:
  11705.  
  11706. Country or Area covered:
  11707.  
  11708. What are the characteristics and peculiarities of the network?  Sacred
  11709. characters, delay, transmission wakeup (does a Kermit packet correspond to
  11710. a network packet?), etc...
  11711.  
  11712. INFO-KERMIT DIGEST V3 #30                                              Page 213
  11713.  
  11714.  
  11715. Could you make Kermit file transfer work at all?  If not, what was the fatal
  11716. impediment?  If so, what tricks were necessary?  These include SET commands
  11717. to Kermit itself (for parity, packet length, retry threshold, timeout, flow
  11718. control, handshake, etc; what particular parameters and values are necessary?),
  11719. and commands to the network (the local or remote node or PAD).
  11720.  
  11721. If anyone would like to answer the same questions as they apply to RS-232
  11722. connections through local area networks -- Sytek, DEC LAT, etc -- please do.
  11723.  
  11724. Thanks in advance!
  11725.  
  11726. P.S. And thanks to all those who responded to my previous questionnaire about
  11727. computer file systems and communications -- I learned about Honeywell/MULTICS;
  11728. Sperry 1100/OS 1100; HP-1000 (partly); PDP-11/RT/RSX/RSTS/POS; UCSD p-System;
  11729. Prime/Primos; Os9.  Any more out there?  HP-3000?  Data General?  CDC?  Cray?
  11730. Gould?  Perkin-Elmer?  PDP-8?  Burroughs?  Honeywell GCOS?  Lisp Machine?  Etc?
  11731.  
  11732. ------------------------------
  11733.  
  11734. Date: Thu, 14 Nov 85 02:18:55 -0100
  11735. From: hans@oslo-vax (Hans A. ]lien)
  11736. Subject: Kermit for the HP-87?
  11737.  
  11738. Kermit for Hewlett Packard Series 80 is needed by a colleague.
  11739. A version working on the CP/M-extension card would also be of some help...
  11740.  
  11741. ------------------------------
  11742.  
  11743. Date: Thu 14 Nov 85 11:39:37-EST
  11744. From: Michael Fuchs <EXT1.FUCHS@CU20B.COLUMBIA.EDU>
  11745. Subject: MVS/TSO Kermit with Protocol Converter?
  11746.  
  11747. Does anyone have any experience using either the U of Chicago or the
  11748. U of Toronto MVS/TSO Kermit in the following enviroment (or similar):
  11749.  
  11750.     AMDAHL V8470
  11751.     MVS/SP3 (will have MVS/XA)
  11752.     using TSO
  11753.     through protocol converter (asynch to SNA) to COMTEN
  11754.  
  11755. Any tips, assurances, bewares, "no problem, pal"'s, or "won't work"'s
  11756. gratefully appreciated.
  11757.  
  11758. Michael Fuchs
  11759. Coefficient Systems Corp.
  11760.  
  11761. [Ed. - If the protocol converter is a Series/1 or equivalent running the
  11762. Yale ASCII Communication system or equivalent, then the Toronto version
  11763. should do the trick.  Other sites are reportedly adding support for additional
  11764. protocol converters to MVS/TSO or VM/CMS Kermit or both.  Again, recall that
  11765. this can only be done for those protocol converters that all the host to
  11766. put them in transparent (pass-through) mode and take them out again.]
  11767.  
  11768. ------------------------------
  11769.  
  11770.  
  11771. Page 214                                              INFO-KERMIT DIGEST V3 #30
  11772.  
  11773. Date: 12 Nov 85 01:52:34 GMT
  11774. From: Yosef Gold <ihnp4!aecom!gold@seismo.CSS.GOV>
  11775. Subject: Kermit for Tandy 6000?
  11776.  
  11777. I am looking for the tandy 6000 version of Kermit.  The Tandy is running
  11778. Xenix.  I have no way to load it off tape.  The ideal would be either a
  11779. floppy or email.
  11780.  
  11781.       Yosef Gold
  11782.       ...{ihnp4,rocky2,philabs,esquire,cucard,pegasus,spike}!aecom!gold
  11783.  
  11784. ------------------------------
  11785.  
  11786. Date: 20 November 1985, 17:08:08 MEZ
  11787. From: Eberhard W. Lisse <ZDV626@DJUKFA11.BITNET>
  11788. Subject: Cromix Kermit???
  11789.  
  11790. Has anybody got a net-adress for the
  11791.  
  11792.            Losinger, AG in Berne/Switzerland
  11793.  
  11794. who are according to a rumor ( AAWAIT HLP on CUVMA.BITNET ) working
  11795. on an implementation for CROMIX?
  11796.  
  11797. As I am based in Germany a surface mail adress would do as well.
  11798.  
  11799. Also does anybody know about an implementation for an ICL 2900 under TME ?
  11800.  
  11801. Thanks in advance,
  11802.  
  11803. el
  11804.  
  11805.  
  11806. Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>
  11807.                    <psuvax1.uucp!djukfa11.bitnet!zdv626>
  11808.  
  11809. ------------------------------
  11810.  
  11811. End of Info-Kermit Digest
  11812.  
  11813. INFO-KERMIT DIGEST V3 #31                                              Page 215
  11814.  
  11815. Info-Kermit Digest         Wed, 27 Nov 1985       Volume 3 : Number 31
  11816.  
  11817. Departments:
  11818.  
  11819.   ANNOUNCEMENTS -
  11820.     PDP-11 Kermit Now Available for IAS 3.1
  11821.     Kermit in C for DG MV Series with MV/UX
  11822.     New Release of Burroughs B7900 Kermit
  11823.     Another Kermit for Intex RMX Systems
  11824.     VMS Hexify/Dehexify Fix
  11825.     IMUSIC - MUSIC Kermit w/7171 support
  11826.  
  11827.   UNIX KERMIT -
  11828.     More notes on C-Kermit 4C(057)
  11829.     More on Masscomp Running C-Kermit 4C(057)
  11830.     Zilog Zeus Kermit, Os9 Kermit Warning
  11831.     Problems with MacKermit for the Macintosh version 0.8(33)
  11832.  
  11833.   MS-DOS KERMIT -
  11834.     MS-DOS Kermit V2.28
  11835.     Hardware Upgrade for some Professional Graphics Controllers
  11836.     ROMing MS-DOS Kermit
  11837.  
  11838.   MISCELLANY -
  11839.     ETX/ACK Flow Control?
  11840.     Problem Downloading Files with Apple II Kermit
  11841.  
  11842. ----------------------------------------------------------------------
  11843.  
  11844. DATE: 25-NOV-1985
  11845. FROM: BRIAN@UOFT02
  11846. SUBJECT: PDP-11 Kermit Now Available for IAS 3.1
  11847.  
  11848. This is to announce that a version of Kermit-11 for IAS 3.1 is available.
  11849. Due to source incompatibility, only the task image and hexified task image
  11850. will be made generally available.  The complete sources will be archived at
  11851. UOFT02 in directory KERIAS: available from dialup access, and a copy of the
  11852. sources will be sent to Frank when I send the K11 update the first week of
  11853. December.  Doc and HEX files are in KER: as K11I31.* and KERBIN:K11I31.TSK.
  11854.  
  11855. Many thanks to Gene Costello and Bruce Wright of the EPA for this version of
  11856. Kermit-11.
  11857.  
  11858. Brian Nelson
  11859.  
  11860. [Ed. - This was the last current DEC operating system that did not have
  11861. a Kermit program -- now they all do.  The hex, odl, cmd, and doc files are
  11862. in KER:K11I31.* on CU20B.]
  11863.  
  11864. ------------------------------
  11865.  
  11866. Date: Wed, 27 Nov 85 09:44:53 est
  11867. From: John Sambrook <uw-beaver!entropy!gandalf>
  11868. Subject: Kermit in C for DG MV Series with MV/UX
  11869.  
  11870. This is a Kermit for Data General MV Series computers.  In order to use this
  11871.  
  11872. Page 216                                              INFO-KERMIT DIGEST V3 #31
  11873.  
  11874. Kermit you need the MV/UX product installed on top of your AOS/VS system.
  11875.  
  11876. If you don't have the MV/UX product but do have Data General's C compiler
  11877. you can modify the source to eliminate all calls to the UNIX emulator.
  11878. While this should not be too difficult, it will require some work.  I would
  11879. have done it for you but my schedule is just too tight.
  11880.  
  11881. If you don't have a C compiler feel free to translate this to another language.
  11882. Note that you will need to provide a multitasking environment.
  11883.  
  11884. This version of Kermit was created from an older version of Kermit.  It may or
  11885. may not be up to date.  It was tested at our site with a Kermit on a 4.2BSD
  11886. system and seemed to work fine.  As our site is moving to native UNIX (DG/UX)
  11887. we will not be using this Kermit for very long.  I will answer questions about
  11888. this version as my schedule permits.
  11889.  
  11890. John Sambrook
  11891. Department of Bioengineering WD-12
  11892. University of Washington
  11893. Seattle, Washington  98195
  11894. Work: (206) 545-2018
  11895. UUCP: uw-beaver!entropy!gandalf
  11896.  
  11897. [Ed. - Thanks!  The files are in KER:DGM*.* on CU20B, available via
  11898. anonymous FTP.  The program is based mostly on the old Unix Kermit.]
  11899.  
  11900. ------------------------------
  11901.  
  11902. Date: 24 Nov 85 09:44:53 est
  11903. From: J.M.H. Smeets, Technische Hogeschool Eindhoven (THE), Netherlands
  11904. Subject: New Release of Burroughs B7900 Kermit
  11905.  
  11906. Enclosed is a tape containing our final implementation of Kermit for
  11907. the Burroughs B7900.  It includes file compression and binary transport.
  11908.  
  11909. [Ed. - The program, which is written in Burroughs Algol, is available on
  11910. CU20B as KER:B79*.*.]
  11911.  
  11912. ------------------------------
  11913.  
  11914. DATE:    85/11/25
  11915. FROM:    3GTLBTL@CALSTATE.BITNET
  11916. SUBJECT: Another Kermit for Intex RMX Systems
  11917.  
  11918. I'm releasing RMXKERMIT this week.  I'll get a tape off to you as soon as I can
  11919. get DP to do it.  Our campus bookstore will send out 5 1/4" DSDD RMX format
  11920. disks for $6/disk.  Disk 1 contains the executable program & documentation.
  11921. Disk 2 contains source code for those who want it.  Orders can be sent to:
  11922.  
  11923.      University Bookstore
  11924.      6049 E. 7th St.
  11925.      Long Beach, CA 90840
  11926.  
  11927.      Attn: Lyle Bartlett
  11928.  
  11929. [Ed. - This yet-another-RMX-Kermit will be announced again when it shows up
  11930.  
  11931. INFO-KERMIT DIGEST V3 #31                                              Page 217
  11932.  
  11933. at Columbia.  This one differs from the others in being an adaptation of
  11934. MS-DOS Kermit, rather than a PL/M implementation.]
  11935.  
  11936. ------------------------------
  11937.  
  11938. Date: 29 Oct 85
  11939. From: Andrew L. Burke, Tektronix MS 63/196, Wilsonville OR 97070
  11940. Subject: VMS Hexify/Dehexify Fix
  11941.  
  11942. Here are fixed versions of the VMS HEXIFY and DEHEXIFY programs.  While
  11943. these programs worked correctly on small files (files with less than 65535
  11944. lines, or thereabouts), failed on large files.  The problem was as follows:
  11945. the programs both used a longword (four bytes) internally to record the
  11946. current line number while reading/ writing the hexified file.  However, both
  11947. only read/wrote a word (two bytes) to/from the hexified file.  So, when it
  11948. came time for the VMSDEH program to read a line past the 65535th, it found
  11949. that the line number had wrapped back to line one.  This causes prolems
  11950. because the program uses the line index to decide whether to expand
  11951. compacted nulls or not, and when it found the next line index not equal to
  11952. the current plus the current line length, it starts writing out nulls
  11953. (counting from 65535 to 1, or therabouts...).  To make a long story short,
  11954. it didn't work.  The fix is simply to read and write a longword.  The other
  11955. modification is to VMSDEH is that it reports an end of file error when it
  11956. finished reading the hex file.
  11957.  
  11958. [Ed. - The fixed versions replace the old ones as KER:VMSHEX.MAR and
  11959. KER:VMSDEH.MAR on CU20B.  This came up because Tektronix is including Kermit
  11960. with its TekniCAD product on its 4100 series systems with CP/M-86.]
  11961.  
  11962. ------------------------------
  11963.  
  11964. Date: Sat, 23 Nov 1985 18:06 CST
  11965. From: John Voigt - Systems Group Tulane <SYSBJAV%TCSVM.BITNET@WISCVM.ARPA>
  11966. Subject: IMUSIC - MUSIC Kermit w/7171 support
  11967.  
  11968. We have discovered a bug in the new version of KERMIT for MUSIC which
  11969. supports the 7171 and Series/1 protocol converters.  This bug does not
  11970. always seem to cause a problem but it should be fixed in your code.  The
  11971. error is a result of a non-initialized control block field when sending
  11972. the first packet.  If you are trying to use this version of KERMIT with
  11973. the 7171 and you get a message FSIO ERROR - 0B1000 then this fix should
  11974. correct the problem.
  11975.  
  11976. In routine INTRINI find the following lines: (near line number 2565)
  11977.          LA    R1,RECPKT
  11978.          ST    R1,KERMFSRB
  11979. add the following lines after the above two:
  11980.          LA    R1,L'RECPK2     GET LENGTH OF INITIAL SEND PACKET
  11981.          ST    R1,KERMFSRL     SET RECORD LENGTH IN CONTROL BLOCK
  11982. This should correct the above error.
  11983.  
  11984. We have also found that if the terminal is defined to MUSIC as a "B" model
  11985. (with APL graphics characters) the 7171 will incorrectly translate data
  11986. causing KERMIT to fail altogether.  This is a permanant restiction and
  11987. should be noted in a BWR file.
  11988.  
  11989.  
  11990. Page 218                                              INFO-KERMIT DIGEST V3 #31
  11991.  
  11992. [Ed. - Noted, along with above fix.]
  11993.  
  11994. Also, in answer to several questions from other MUSIC sites, I would like
  11995. to let everyone know that KERMIT is running on MUSIC/SP without any
  11996. modifications so if you are considering a software upgrade it should not
  11997. cause any proplems for your KERMIT users.
  11998.  
  11999. ------------------------------
  12000.  
  12001. Date: Sun, 24 Nov 85 04:16:02 CST
  12002. From: Stan Barber <neuro1!sob@rice.ARPA>
  12003. Subject: More Notes on C-Kermit 4C(057)
  12004.  
  12005. One more suggestion:
  12006.  
  12007. I would provide some mechanism to allow SYSIII compatible sites to
  12008. configure what signal that might like to use to allow the child and
  12009. parent to notify each other of problems. At my site, SIGUSR1 can not
  12010. be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
  12011. SIGUSR2. That fixes everything just fine.
  12012.  
  12013. At least a warning should be noted somewhere (in the .bwr file, I guess)
  12014. so that people will know to change it.
  12015.  
  12016. Alternatively, I would suggest a unique name (SIGKERMIT) that the
  12017. installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
  12018. keep people from mucking in the source file.
  12019.  
  12020. ------------------------------
  12021.  
  12022. Date: Sun, 24 Nov 85 23:07:42 CST
  12023. From: Stan Barber <neuro1!sob@rice.ARPA>
  12024. Subject: More on Masscomp Running C-Kermit 4C(057)
  12025.  
  12026. There is one more difference that masscomp users should check if they make
  12027. Ckermit. Using the masscomp FIONREAD (when in connect mode) my cause characters
  12028. to be dropped.  Using myread generally works better. This is certainly true if
  12029. the masscomp has the imux or jmux installed on it. It may not be true with the
  12030. new HPSMux installed. We don't have one yet, so I don't know.
  12031.  
  12032. In any case, I suggest a line for masscomp be added to the makefile of this
  12033. form:
  12034.  
  12035. rtu:
  12036.     make wermit "CFLAGS= -UFIONREAD -DUXIII -DDEBUG -DTLOG -O" "LNKFLAGS ="
  12037.  
  12038. [Ed. - Thanks Stan, both your messages have been added to the .BWR file, and
  12039. are on the list for the next release.]
  12040.  
  12041. ------------------------------
  12042.  
  12043. Date: Tue Nov 26 11:45:41 EST 1985
  12044. From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV
  12045. Subject: Zilog Zeus Kermit, Os9 Kermit Warning
  12046.  
  12047. I am the contributer of the Zilog Zeus support for C-Kermit.  Kermit WILL NOT
  12048.  
  12049. INFO-KERMIT DIGEST V3 #31                                              Page 219
  12050.  
  12051. WORK with the newest version of the Zeus operating system, i.e. 3.21.  We have
  12052. gotten C-Kermit to run under this new release but we had to rewrite ckutio.c.
  12053. Do you want us to submit this new mod?
  12054.  
  12055. [Ed. - Sure, especially if the new ckutio.c also works with the old release
  12056. of Zeus.  Or do we have to have two separate compile-time options for Zeus
  12057. systems?]
  12058.  
  12059. Also we think(!?) we have found two bugs in ckermit.  One is in ckcpro.c.  In
  12060. this module, C-Kermit sends an initial NAK to the other system rather than
  12061. waiting for the other side to make the first move.  We simply commented this
  12062. line out and now C-Kermit will talk to older Unix kermits.  Could this be made
  12063. public so that C-Kermit can be made a little more universal?  Some systems may
  12064. never be able to port C-Kermit (ala Os-9 Level I) and need to be able to talk
  12065. to C-Kermit.  Can this be done without losing any other comapatibility?
  12066.  
  12067. [Ed. - Are you talking about when C-Kermit is given the RECEIVE command,
  12068. or the SERVER command?  In the former case, I don't see how we can get
  12069. around sending NAKs -- if the expected first packet doesn't come, Kermit
  12070. has to NAK it, in case it was lost on the way and the sender of it doesn't
  12071. do timeouts.  If your local Kermit does timeouts, you can turn C-Kermit's
  12072. timer off all together with SET RECEIVE TIMEOUT 0.  In the latter case,
  12073. you're right, there should be a SET SERVER TIMEOUT command to turn off the
  12074. periodic NAKing function of the server, but still let it time out during
  12075. a protocol transaction.  Something like this should appear in a future
  12076. release.]
  12077.  
  12078.   The 2nd bug is in ckutio.c  In this mod, ckermit waits to get the other
  12079. side's eol char but then ignores it and expects its own: see the following
  12080.  
  12081. #ifdef ZILOG
  12082.     seol = (len-- > 0) ? unchar(data[4]) : '\r';      /* Terminator  */
  12083.     if ((seol < 2) || (seol > 037)) seol = '\r';
  12084. #else
  12085.     eol = (len-- > 0) ? unchar(data[4]) : '\r';            /* Terminator  */
  12086.     if ((eol < 2) || (eol > 037)) eol = '\r';
  12087. #endif
  12088.  
  12089. the ifdef ZILOG is our correction.  It was our experience that C-Kermit
  12090. would not work with any system that did not use <CR> as eol or would
  12091. convert eol to <CR>.  Hope this helps!
  12092.  
  12093. [Ed. - Thanks.]
  12094.  
  12095. ------------------------------
  12096.  
  12097. Date: 26 November 1985, 08:43:52 CST
  12098. From: Tim Klosowski, Argonne National Laboratory <B34885@ANLVM.BITNET>
  12099. Subject: Problems with MacKermit for the Macintosh version 0.8(33)
  12100.  
  12101. I have been testing version 33 of the Kermit program for the Macintosh
  12102. computer prior to its release to our users.  I have encountered no problems
  12103. using the program on a 9600-baud X.25 line hookup to our IBM 3033 mainframe.
  12104. The problems surfaced when using a 1200-baud line.  I found three cases
  12105. during the course of my testing.
  12106.  
  12107.  
  12108. Page 220                                              INFO-KERMIT DIGEST V3 #31
  12109.  
  12110. FIRST, normal execution and normal completion.
  12111. The file transferred sucessfully, the message stating this appeared and, after
  12112. a mouse-click, returned to the KERMIT-CMS prompt.
  12113.  
  12114. SECOND, normal execution and abnormal completion.  The file transfers
  12115. successfully and the message appears.  Instead of the KERMIT-CMS prompt
  12116. after a mouse-click, the program displays odd characters (such as %B..) and
  12117. necessitates several carriage returns to get action on the screen.  The
  12118. characters continue until a file transfer error message appears followed by
  12119. the KERMIT-CMS prompt.  The error message states that the transfer did not
  12120. complete, but closer examination indicates that the files did indeed
  12121. transfer successfully.
  12122.  
  12123. THIRD, abnormal execution and completion.  The program stalls after a few
  12124. packets are transferred.  The emergency exit is the only recourse.
  12125.  
  12126. The first case is what should ideally happen.  The third is a known problem
  12127. (occurring after an emergency exit is invoked).  The one that truly puzzles me
  12128. is the second.  If this is a known problem or if there is something I can do to
  12129. eliminate the problem, please let me know.
  12130.  
  12131. [Ed. - Thanks for your report.  I think that problem #2 has something to do
  12132. with closing down the line before the acknowledgement of the B (Break
  12133. Transmission) packet has been completely sent.  This would only occur during
  12134. uploading, and can be cured by using an even longer delay between sending
  12135. the ACK and closing the line.  It could also occur if this final ACK were
  12136. lost for some reason; again, a delay could cure this too.  The problem
  12137. should be fixed in the next release.]
  12138.  
  12139. ------------------------------
  12140.  
  12141. Date: Monday, 25 November 1985  13:46-MST
  12142. From: Dick McGee (MMW) <dickmc@BRL.ARPA>
  12143. Subject: MS-DOS Kermit V2.28
  12144.  
  12145. Has anyone successfully ported kermit v2.28 to a Z100?  I fixed the reported
  12146. bugs in the source code and assembled it.  I can upload and download with it
  12147. okay.  If I do a DIRECTORY, PUSH, SPACE or any command that temporarily exits
  12148. to DOS it goes into the twilight zone and I have to hard reset.  I'm running
  12149. MS-DOS 2.18.
  12150.  
  12151. I'm quite satisfied with the 2.26 version of Kermit, but since like
  12152. Mt. Everest, version 2.28 was there I thought I would try it.
  12153.  
  12154. s/Richard McGee    dickmc@BRL.ARPA
  12155.  
  12156. [Ed. - Sounds like another casualty of version 2.28's new dynamic memory
  12157. allocation.  Did you use the /S switch on the assembler?]
  12158.  
  12159. ------------------------------
  12160.  
  12161. Date: 17 November 85 15:46-PST
  12162. From: Don Pelton (415) 854-3300 x2901 <DEP%SLACVM.BITNET@WISCVM.ARPA>
  12163. Subject: Hardware Upgrade for some Professional Graphics Controllers
  12164.  
  12165. [Ed. - Excerpted from a posting on Info-IBMPC.]
  12166.  
  12167. INFO-KERMIT DIGEST V3 #31                                              Page 221
  12168.  
  12169.  
  12170. If you have bought, or plan to buy, IBM's Professional Graphics Controller
  12171. and Display, you may be interested in this.  Several of us who bought this
  12172. board early this year discovered, through some painstaking research, that
  12173. there was a hardware bug on the board that caused it to interfere with ANY
  12174. terminal emulation program making use of the asynch port.
  12175.  
  12176. The old PGC cards have the numbers 6323697 and 6323698 on the top left of
  12177. the memory card. The new cards have these two numbers inked out and the
  12178. number 6448811 replaces them.  The two old numbers are not always inked out
  12179. and if your board has the 6448811 number, you have a new board.
  12180.  
  12181. ------------------------------
  12182.  
  12183. Subject: ROMing MS-DOS Kermit
  12184. Date: 25 Nov 85 10:38:57 EST (Mon)
  12185. From: jcmorris@mitre.ARPA
  12186.  
  12187. [Ed. - This message picked up from Info-IBMPC in response to a query from
  12188. ad0r@cmu-cc-te about installing Kermit ROMs in IBM PCs...]
  12189.  
  12190. It's probably not worth it.  If you are willing to forgo the file upload/
  12191. download functions of KERMIT and use it to emulate a dumb terminal, it
  12192. shouldn't be too difficult to replace the screen and keyboard interfaces
  12193. with BIOS calls (I think that KERMIT uses DOS calls for these functions,
  12194. but I don't have the code at hand).
  12195.  
  12196. If you do this, why bother with KERMIT?  There are several other packages
  12197. around which provide X3.64 interfaces; the real advantage to KERMIT is the
  12198. popularity of its file transfer capabilities.
  12199.  
  12200. If you want the file transfer capabilities, on the other hand, you will
  12201. have to write your own file subsystem and burn it on the PROM.  For all
  12202. its faults, DOS does provide a mechanism for device-independent disk
  12203. access.  Unless you are going to dedicate significant staff time (spelled
  12204. with dollar signs) to the project, you will wind up with a package which
  12205. will support only a few device types.
  12206.  
  12207. I see occasional articles in the press which describe central-server systems
  12208. where the node PC's have no hard disk (or sometimes no DASD at all).  The
  12209. nodes, when booted, go to the central server for their copy of DOS; this
  12210. might be a better technique for you.
  12211.  
  12212. Ciao.
  12213.  
  12214. Joe Morris (jcmorris@mitre)
  12215.  
  12216. ------------------------------
  12217.  
  12218. Date: Thu 21 Nov 85 11:11:21-EST
  12219. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12220. Subject: ETX/ACK Flow Control?
  12221.  
  12222. Does anybody know what ETX/ACK flow control is, and what systems use it?
  12223. Is it like XON/XOFF, or ENQ/ACK, or is it something completely different?
  12224.  
  12225.  
  12226. Page 222                                              INFO-KERMIT DIGEST V3 #31
  12227.  
  12228. ------------------------------
  12229.  
  12230. Date: 24 Nov 85 00:07:26 GMT
  12231. From: Jeff Hollingsworth <hollings%ucbcory.ucb-vax.arpa@brl.arpa>
  12232. Subject: Problem Downloading Files with Apple II Kermit
  12233.  
  12234. I am having trouble using kermit to transfer files between an Apple IIe, and
  12235. UNIX. When I try to send files from UNIX to my Apple, all occurences of the
  12236. "&" (ascii 38) character are removed.  This happens in both the image and
  12237. text mode.  However, all goes ok when I transfer a file from the Apple TO
  12238. UNIX.  Does anyone have an idea what is happening.  The Apple has a Super
  12239. Serial card if that helps.
  12240.  
  12241. Thanks in advance.
  12242.  
  12243. Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
  12244.             ARPA:   hollings%cory@ucbvax.BERKELEY.EDU
  12245.             AT&T:   (415) 653-3723
  12246.  
  12247. [Ed. - Sounds like the two sides are not agreeing about 8th-bit prefixing.
  12248. The Apple thinks it's doing it, Unix doesn't.  You didn't say what versions
  12249. of Kermit you're running, so the problem may be fixed by now.  In any case,
  12250. you might be able to work around it by saying SET PARITY ODD on both sides
  12251. to force 8th-bit prefixing.]
  12252.  
  12253. ------------------------------
  12254.  
  12255. End of Info-Kermit Digest
  12256.  
  12257. INFO-KERMIT DIGEST V3 #32                                              Page 223
  12258.  
  12259. Info-Kermit Digest         Thu,  5 Dec 1985       Volume 3 : Number 32
  12260.  
  12261. Departments:
  12262.  
  12263.   ANNOUNCEMENTS -
  12264.     New MS-DOS Kermit Available for Evaluation
  12265.     VT-220 .INI File for MS-DOS Kermit
  12266.  
  12267.   MISCELLANY -
  12268.     Forthcoming NIH TSO Kermit
  12269.     Apple Kermit Problem
  12270.     Fix for Apple Kermit Problem
  12271.     Os9 Kermit on Os9/68000
  12272.     Xenix Kermit Modem Control
  12273.     MULTICS Kermit?
  12274.     Professional 350 Kermit w/o Hard Disk?
  12275.     HP 9836 Kermit Diskette Needed
  12276.     Osborne 1 SD Kermit Diskette Needed
  12277.     Kermit Praises and Uses
  12278.  
  12279. ----------------------------------------------------------------------
  12280.  
  12281. Date: Thu 5 Dec 85 15:55:21-EST
  12282. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12283. Subject: New MS-DOS Kermit Available for Evaluation
  12284.  
  12285. I have the following letter from Joe R. Doupnik, Professor, Center for
  12286. Atmospheric and Space Sciences, Utah State University:
  12287.  
  12288. The enclosed tape ... holds an updated version of Kermit for MS-DOS
  12289. microcomputers.  This version is based on your MS-DOS Kermit 2.28 [the
  12290. current version]... and is identified internally as "version 2.28 jrd".
  12291. The updates include full DOS 2.0 file support thoughout, a nearly complete
  12292. set of advanced server functions, much cleaned up displays (Help, Status,
  12293. Set, etc), a much better file renaming algorithm, and quite a few bug
  12294. fixes.  All of the problems known [in 2.28 as of August 85] have been fixed
  12295. and some unreported ones were as well.  Internally the code has been
  12296. strengthened and cleaned up generally.
  12297.  
  12298. Kermit 2.28 jrd was built for IBM PC clones (a Zenith 151 here) and for
  12299. generic machines (I have one like this using a terminal and it is not at
  12300. all close to an IBM PC).  However, my updates affect the modules common to
  12301. all versions, [and there are also minor changes to] MSXIBM and MSYIBM.
  12302. There is a READ.ME file as well.
  12303.  
  12304. [End of letter.]  I have put these files in a special place on CU20B,
  12305. PS:<KERMIT-MS>*.*, available on the Internet via anonymous FTP.  I only
  12306. received the source files, but I built a version on the Rainbow, which (so far)
  12307. seems to work just fine.  The file names are the old ones, not the new
  12308. consistent ones (see KER:MSAAAA.HLP).  Since the people who used to take care
  12309. of MS-DOS Kermit here have quit, I am inclined to make this the new base
  12310. version.  It seems to be better than July-vintage 2.28 in all respects, but I'd
  12311. appreciate it if people could check it on different machines to verify this,
  12312. including the IBM family (with various graphics adapters), the Wang PC, the
  12313. HP-150 and 110, TI Pro, NEC APC, etc, and report back as to whether it would
  12314. be a good idea to switch to this version (and point me at an .EXE and/or
  12315.  
  12316. Page 224                                              INFO-KERMIT DIGEST V3 #32
  12317.  
  12318. .BOO file).  The PS:<KERMIT-MS> directory includes 8-bit binary .OBJ files
  12319. (assembled with MASM 1.10 on the Rainbow) and MSVRB1.EXE, the 8-bit binary
  12320. Kermit .EXE file for the Rainbow.  The binary files are *.OBJ, *.EXE; the
  12321. text files are *.ASM, *.H, *.ME.
  12322.  
  12323. I still have a version of MS-Kermit laying around that has built-in VT100
  12324. (102?) emulation, but it's based on 2.27, and the emulation only works on the
  12325. IBM PC family, but effects all the others.  I figure we'd better first get a
  12326. clean base to work from, and then worry about how to add new stuff to it.
  12327.  
  12328. ------------------------------
  12329.  
  12330. Date: Mon, 2 Dec 85 18:17:58 pst
  12331. From: Joel West <westjw%frog@nosc.ARPA>
  12332. Subject: VT-220 .INI File for MS-DOS Kermit
  12333.  
  12334. I'm not the original author, but I'm told that if this is made
  12335. the KERMIT.INI for MS-DOS kermit on the Rainbow, it will make the
  12336. keyboard act like that of a DEC VT-220.
  12337.  
  12338. You might wish to include it in the FTP directory at Columbia-20.
  12339.  
  12340.     Joel West    CACI, Inc. - Federal
  12341.     westjw@nosc.ARPA
  12342.     {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw
  12343.  
  12344. [Ed. - It's in KER:MSIVT2.INI, the author is listed as Ken Bass
  12345. <bass_kr@nosc-turtle.arpa>]
  12346.  
  12347. ------------------------------
  12348.  
  12349. Date: Mon, 2 Dec 85  19:46 EST
  12350. From: RAF@UMDC
  12351. Subject: Forthcoming NIH TSO Kermit
  12352.  
  12353. I would like to correct an error that appeared in a recent Info-Kermit.
  12354. It is not the University of Maryland that is doing a TSO KERMIT, but
  12355. rather the National Institutes of Health in Bethesda, Maryland.
  12356. The confusion most likely arose because my BITNET mailing address is at
  12357. the University of Maryland until we get our BITNET connection running.
  12358. A description of our TSO KERMIT follows:
  12359.  
  12360. I spoke to you about our KERMIT on the phone some time ago.  It is based
  12361. on the University of Chicago TSO KERMIT, but we have really ripped it
  12362. apart - so it wouldn't be recognizable.  I spoke to Ron Rusnak about it
  12363. before we started development.  He said that they had no plans to do any
  12364. further development and planned to go to the Rice TSO KERMIT.  I tried
  12365. to get a copy of that KERMIT, but they were unwilling to send me one at
  12366. that time (but did later for $75).  Since we were unwilling to wait some
  12367. unspecified period of time just to look at the Rice KERMIT, we went ahead
  12368. with our plans.  Our TSO KERMIT has server mode, CRC, wildcard send and
  12369. receive, ability to issue TSO commands, timeout (without polling),
  12370. compression, 8th bit quoting, optional tab removal on upload, optional tab
  12371. insertion on download, support for NIH WYLBUR edit format, a SET
  12372. VOLUME command, binary file support, handling of line errors that
  12373. generate a break signal, multiple records per packet, handling of lines
  12374.  
  12375. INFO-KERMIT DIGEST V3 #32                                              Page 225
  12376.  
  12377. 500 or more characters long.  We also plan support for PDS members
  12378. and are reworking the help info to make it more helpful.  Another item
  12379. is an interface to the TSO CLIST facility for KERMIT command lists.
  12380. I'm no expert on CMS, but I'm not sure that TSO and CMS aren't different
  12381. enough to make separate programs the most reasonable way to go.  An awful
  12382. lot of the program is concerned with the system interface rather than the
  12383. KERMIT protocol.  Anyway, ours is almost done.  We will make it available
  12384. to you when it is finished
  12385.  
  12386. Roger Fajman
  12387. National Institutes of Health
  12388. (301) 496-5181
  12389. RAF@UMDC.BITNET
  12390.  
  12391. ------------------------------
  12392.  
  12393. Date: Saturday, 23 November 1985  17:07-MST
  12394. From: Jeff Hollingsworth <hollings%cory@ucbvax.BERKELEY.EDU>
  12395. Subject: Apple Kermit Problem
  12396.  
  12397. I am having trouble using kermit to transfer files between an Apple
  12398. IIe, and UNIX. When I try to send files from UNIX to my Apple, all
  12399. occurences of the "&" (ascii 38) character are removed.  This happens
  12400. in both the image and text mode.  However, all goes ok when I transfer
  12401. a file from the Apple TO UNIX.  Does anyone have an idea what is
  12402. happening?  The Apple has a Super Serial card if that helps.
  12403.  
  12404. Thanks in advance.
  12405.  
  12406. Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
  12407.             ARPA:   hollings%cory@ucbvax.BERKELEY.EDU
  12408.             AT&T:   (415) 653-3723
  12409.  
  12410. [Ed. - See next message.]
  12411.  
  12412. ------------------------------
  12413.  
  12414. Date: Wed, 27 Nov 85 15:18:06 PST
  12415. From: Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA
  12416. Subject: Fix for Apple Kermit Problem
  12417.  
  12418. In this message I've enclosed an update to your Apple Kermit program.
  12419. Versions 2.0 and 2.1 of the program do not handle eighth bit quoting
  12420. correctly. A student, Sam Lam, who was working for me during the
  12421. summer found the error. Below is the correction.
  12422.  
  12423. In the procedure Rpar three operands have to be changed from "rparrt"
  12424. to "rpar8" as indicated by the arrows.
  12425.  
  12426.                         -- Bruce Jolliffe
  12427.  
  12428. [Ed. - Thanks!  Code omitted, added to KER:APPLE.BWR.]
  12429.  
  12430. ------------------------------
  12431.  
  12432. Date: Wed 4 Dec 85 15:05:39-PST
  12433.  
  12434. Page 226                                              INFO-KERMIT DIGEST V3 #32
  12435.  
  12436. From: Bob Larson <BLARSON%ECLD@USC-ECL.ARPA>
  12437. Subject: Os9 Kermit on Os9/68000
  12438.  
  12439. The current version of os9 kermit can't be compiled by the current version
  12440. of os9/68k C (1.3) because "remote" is a reserved word.  (What version of
  12441. os9/68k C introduced this "feature"?)  Even after this problem is solved,
  12442. kermit doesn't work properly.  I'll be fixing this asap.  (I now have a
  12443. QT+ 68000 system.)
  12444.  
  12445. Bob Larson
  12446. Arpa: Blarson@Usc-Ecl.Arpa
  12447. Uucp: ihnp4!sdcrdcf!oberon!blarson
  12448.  
  12449. [Ed. - This message added to KER:OS9KER.BWR.]
  12450.  
  12451. ------------------------------
  12452.  
  12453. Date: Mon 25 Nov 85 17:10:21-EST
  12454. From: Yoram Eisenstadter <Yoram@CS.COLUMBIA.EDU>
  12455. Subject: Xenix Kermit Modem Control?
  12456.  
  12457. I'm trying to bring up Unix Kermit on my PC/AT running XENIX, but
  12458. I'm having difficulties.
  12459.  
  12460. I got ahold of the source, and compiled everything successfully using
  12461. "make xenix".
  12462.  
  12463. First problem: the machine hung when I tried to do a "set line /dev/tty00".
  12464. I was able to do a set line only after saying "set modem-dialer hayes",
  12465. even though I have a direct connection and not a modem.
  12466.  
  12467. 2nd problem: after set line, I did a "set speed 9600".  Then I did a connect.
  12468. Kermit immediately came back with the message "Communication Disconnect",
  12469. and returned me to the C-Kermit> prompt.
  12470.  
  12471. I know that the hardware is O.K.  I use the same communication port with
  12472. MSKERMIT under DOS, and it works just fine (I'm using it now...)
  12473. I was also able to use the port (/dev/tty00) from Unix with the "cu"
  12474. command, by saying "cu -s 9600 -l /dev/tty00 dir".
  12475.  
  12476. What am I doing wrong?
  12477.  
  12478. [Ed. - See next message...]
  12479.  
  12480. --------------------
  12481.  
  12482. Date: Wed Nov 27 12:10:47 1985
  12483. From: Herm Fischer <hermix!fischer@rand-unix.ARPA>
  12484. Subject: Re: Xenix kermit difficulties
  12485.  
  12486. Ahh, the saga of carrier detect, clear to send, and data set ready continues...
  12487.  
  12488. If you fire up kermit, when you do a set modem-dialer, you place kermit into
  12489. the "clocal" (ignore carrier detect absence) state.  If you fire up kermit on
  12490. a direct connection without a modem, then be sure carrier detect is present
  12491. on the pins of the cable before firing kermit up.
  12492.  
  12493. INFO-KERMIT DIGEST V3 #32                                              Page 227
  12494.  
  12495.  
  12496. I suggest purchasing one of those widget connectors with the led's which
  12497. goes between the rs232 cable and the computer to see which signals are present.
  12498. Often on direct connections, it is common to hot-wire carrier detect to some
  12499. other signal to get it to come up.  If you're on a LAN, then there might
  12500. be a LAN option to raise the carrier signal...
  12501.  
  12502. Your communications disconnection message comes from the UNIX operating
  12503. system notifying kermit that the carrier signal has dropped!  Same problem.
  12504.  
  12505. cu may override the "clocal" flag; I haven't looked at its code.  kermit
  12506. cannot override that flag because it must know when a remote modem hangs
  12507. up, lest it tie up a system or hang it...
  12508.  
  12509.   Herm Fischer
  12510.   HFischer@isif.arpa; {ihnp4, decvax, randvax}!hermix!fischer
  12511.  
  12512. [Ed. - Herm not only wrote the Xenix modem support in C-Kermit, but he
  12513. also uses it all the time -- an existence proof that it works.]
  12514.  
  12515. ------------------------------
  12516.  
  12517. Date:  Fri, 29 Nov 85 12:24 EST
  12518. From:  Wiedemann@RADC-MULTICS.ARPA
  12519. Subject:  MULTICS Kermit
  12520.  
  12521. I have recently moved to Maui and been out of touch with my usual
  12522. MULTICS machine for about two months.  In that time, a new release of
  12523. the operating system was installed.  This came with KERMIT.  The new
  12524. KERMIT does not respond to my PC KERMIT, even though I have successfully
  12525. used this repeatedly with the previous version of MULTICS KERMIT.  I
  12526. have made every effort to ensure that the file parameters match at both
  12527. ends.
  12528.  
  12529. Could the fact that I'm now using a TAC have something to do with it?
  12530. Transfer has failed both ways using either an ASCII or binary file.
  12531.  
  12532. Anyone have a systematic approach to a solution??  I'd appreciate the
  12533. help as Maui is a veritable computer "wasteland"!
  12534.  
  12535. Wolf Wiedemann RADC-MULTICS
  12536.  
  12537. [Ed. - TACs are always a pain.  But I also keep hearing about all these
  12538. different versions of MULTICS Kermit that are in use "out there" that I
  12539. have never seen personally, so it might just as likely be the culprit.
  12540. Anybody care to clear up the MULTICS Kermit confusion?  Which is the
  12541. "real" one, and where does it come from?]
  12542.  
  12543. ------------------------------
  12544.  
  12545. Date: Mon, 2 Dec 85 17:20:32 EST
  12546. From: Chris_Moore%UB-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
  12547. Subject: Professional 350 Kermit w/o Hard Disk
  12548.  
  12549.   I presently use Kermit on my Digital Pro-350, however I don't have a
  12550. hard disk on this system thus it operates as a Pro-325.  While Kermit
  12551.  
  12552. Page 228                                              INFO-KERMIT DIGEST V3 #32
  12553.  
  12554. functions just fine with the obvious exception on interfacing with the
  12555. other utilites which it expects on disk, I can not get kermit to retain
  12556. its communications settings so it ALWAYs uses the defaults.
  12557.   The problem seems to be that Kermit wants to store its settings in
  12558. a file somewhere, but I can't figure out what that file is named or
  12559. where it is supposed to be;  if I could, then I could create it and
  12560. suspect all would be fine!
  12561.   Any help with this would be greatly appreciated.
  12562.   --chris
  12563.  
  12564. ------------------------------
  12565.  
  12566. Date: Thu 5 Dec 85 08:44:31-EST
  12567. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12568. Subject: HP 9836 Kermit Diskette Needed
  12569.  
  12570. If anybody has HP9836 Kermit on a diskette and is willing to send a copy
  12571. to someone who can't get it any other way, please call Steve Masticola
  12572. at RCA, Somerville NJ, 201-685-6594, collect if desired.  And if you're
  12573. willing to send Steve a disk, how about also sending one to the HP98x6
  12574. user group (is there such a thing?) so they can handle these requests?
  12575.  
  12576. ------------------------------
  12577.  
  12578. Date: Thu 5 Dec 85 11:27:12-EST
  12579. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12580. Subject: Osborne 1 SD Kermit Diskette Needed
  12581.  
  12582. I got a letter from Norway that was addressed like this:
  12583.  
  12584.     Columbia University
  12585.     Columbia, USA
  12586.  
  12587. It actually, came to me...  Somebody in Norway figured out that CU was in
  12588. New York, and then somebody at Columbia opened it up and saw the word Kermit
  12589. in it...  Anyhow, this guy lost his only copy of Kermit because of a power
  12590. hit, and can't find a single-density copy of it anywhere in Norway.  If some
  12591. kind soul would send one to
  12592.  
  12593.     Einar
  12594.     Norway
  12595.  
  12596. I'm sure he'd appreciate it.  Just kidding, his full address is
  12597.  
  12598.     Einar Fredriksen
  12599.     Edvard Griegsvei 34
  12600.     N-5037 Solheimsvik
  12601.     NORWAY
  12602.  
  12603. Thanks!
  12604.  
  12605. ------------------------------
  12606.  
  12607. Date: Thu 5 Dec 85 13:46:34-EST
  12608. From: Chris Lent <OC.PEDHEM@CU20B.COLUMBIA.EDU>
  12609. Subject: Kermit Praises and Uses
  12610.  
  12611. INFO-KERMIT DIGEST V3 #32                                              Page 229
  12612.  
  12613.  
  12614. KERMIT in the trenches:
  12615.     We've been using KERMIT down at Cooper Union quite a bit.
  12616. (We're at 3rd Ave and East 8th Street).
  12617. After I bought a copy of the tapes,  I put it on our systems
  12618. down at Cooper.  These are:
  12619.     VAX 11/780 VMS 4.2
  12620.     ATT 3b5 System V UNIX R 2.0.211
  12621.     PDP-11/45 UNIX V6 (plus)    ! This took a good bit of work
  12622.     PDP-11/23 UNIX V6 (plus-more)    ! Same as 11/45
  12623.     IBM-PC's, and PC-Jr's PC-DOS 2.0,2.1,3.0,3.1
  12624.     ATT 6300 (Very IBM compatible AND FAST!!!)
  12625.     Apple Mac's ! The VT102 emultator comes in very handy.
  12626.     Intel Blue Boxes "MDS-80" (ISIS-II)(8" Floppy only)
  12627.         ! We transfered this via a block-by-block copy
  12628.         ! from our VAX RX01 Console Floppy
  12629.     Intel 310's    ! DON'T EVEN THINK ABOUT BUYING THESE TURKEYS!!!!
  12630.         ! The 310's run MS-DOS BADLY (We had to write drivers
  12631.             for the serial port and winchester that Intel put in!!)
  12632.         ! Intel also foists IRMX-86 on you (Everyone needs an
  12633.             archaric multi-user Operating System on a
  12634.             machine that one person uses?)
  12635.         ! Kermit is having a hard time here only because the
  12636.         ! port drivers still are bug-infested. We tend to
  12637.         ! transfer to an IBM-PC and take the MS-DOS floppy
  12638.         ! and read that instead.
  12639.     Intel 380's ! BIGGER Multi-User TURKEYS!!
  12640.         ! Intel hasn't managed to port MS-DOS to these yet!!!!
  12641.  
  12642. Now we do a multitude of daily and regular transfers like:
  12643. STUDENT USE:
  12644.         Student archiving of programs.  This works wonderfully as
  12645.     we don't have to hunt through age-old backups for their stuff.
  12646.     It also has the added benefit that if the programs are written
  12647.     portably in 'C', Fortran, Pascal or Basic, they can do development
  12648.     work on PC's and other micros around the school or at home.
  12649.     The archiving is done at local PC's. This is necessary as our
  12650.     money for dialin facilities is limited and our computers are
  12651.     brought down each night because the building is closed.
  12652.  
  12653.         Students talking to FIDO bulletin board systems from home.
  12654.     This way they can get the latest shareware utlities.
  12655.  
  12656.         Students talking to each other's systems.  One interesting
  12657.     case is a lab group where the guy with the MAC did the diagrams,
  12658.     and printed the final version of the paper while another
  12659.     member typed the paper on his IBM. The third member
  12660.     proof-read the text on his Commodore-64.  Let's hear it for
  12661.     two wonderful standards: ASCII and KERMIT!!!!
  12662.  
  12663. COURSE AND PROJECT USE:
  12664.         Sending GTSTRUDL plotting files from our VAX to the 11/45
  12665.     where our CALCOMP plotter is.  This lets our civil engineers
  12666.     make giant plots of their structures and how they will deform
  12667.     under load.
  12668.  
  12669.  
  12670. Page 230                                              INFO-KERMIT DIGEST V3 #32
  12671.  
  12672.         Sending Digitized maps and data from the 11/45 to IBM-PC's and
  12673.     the VAX. There a lot of this.  The students in the CAD/CAM
  12674.     course have to design a simple packeage and many of them
  12675.     digitize their intial shape library on the 11/45 before moving
  12676.     them to the final machine.
  12677.  
  12678.         Sending sample bitmapped image data from RT-11 format tapes
  12679.     read in on our VAX to Intel 380's for work in developing medical
  12680.     imaging systems.
  12681.  
  12682. MORE STUDENT USE:
  12683.         Sending and receiving programs under development from grad and
  12684.     undergrad students machines out at Bell Labs (and AT&T clones) for
  12685.     course work (complier design, programming languages, data structures,
  12686.     and of course the infamous Master's thesis).  Bell Labs
  12687.     machines at Whippany, Homdel, and Parsippany get the new
  12688.     versions from us as we get them from you.  Once Kermit'ed
  12689.     to a Usenet machine, the programs flow over Usenet to the
  12690.     apporiate machines.  Most times they just type
  12691.         % make sys3
  12692.     or the make for Berkley 4.2 and the Kermit works perfectly
  12693.     right away.  Many times the user DOESN'T know what type of
  12694.     machine he's running on (VAX, 3bx or whatever) and it STILL
  12695.     works well even though the "RIGHT" version wasn't used.
  12696.         The first version when over via the UNIX 'cu'(CALL UNIX)
  12697.     utility which talked through the VAX's modem via KERMIT in CONNECT mode.
  12698.     After fixing up the transmission errors,  we compiled it and
  12699.     got a reliable version of KERMIT via our 'cu'ed version.
  12700.  
  12701. FACULTY USE:
  12702.     The faculty computer program.  Professor's develop programs
  12703.     at home that the students use in their classes on the main
  12704.     computers.  The number of these programs we support now is getting
  12705.     huge.
  12706.     
  12707.     Faculty work on remote machines in places like Texas and Califonia.
  12708.     Usually they have older versions of KERMIT, so we ship a new
  12709.     version to our faculty member's account via the old KERMIT
  12710.     and then tell the remote staff where to find it for system-wide
  12711.     installation.
  12712.  
  12713.  
  12714.     And even more every day.
  12715.  
  12716.  
  12717. It seems like every third word out of my mouth is KERMIT.
  12718. My policy is now whenever someone has a machine or an account on
  12719. a machine which doesn't have KERMIT, we find some way of moving
  12720. KERMIT to them.  I must admit I thought the demand would be large
  12721. but it just seems to be growing in leaps and bounds.
  12722.  
  12723.  
  12724. The thing is that I've learned about so many strange operating
  12725. systems while installing KERMIT, but I rarely (once a month)
  12726. have to examine individual KERMIT packets when porting a new
  12727. KERMIT version.
  12728.  
  12729. INFO-KERMIT DIGEST V3 #32                                              Page 231
  12730.  
  12731.  
  12732. We just seems to be trashing more old file transfer programs
  12733. every day.  It doesn't matter if they we purchased or hacked
  12734. together,  KERMIT is in general better and makes MUCH more
  12735. sense to maintain.  We usually keep the old one around until
  12736. we figure out how to send strange file formats (VMS is famous
  12737. for these.)
  12738.  
  12739. Well, I'll keep KERMITing the rest of the Universe.
  12740.  
  12741.                 Thanks,
  12742.                 Chris Lent
  12743.                 Care of:
  12744.                 OC.PEDHEM@CU20B.COLUMBIA.EDU
  12745.                 (VAXmail) CUPHOA::LENT
  12746. (I'm working on tailoring utilities and EUNICE for them up here)
  12747.  
  12748. ------------------------------
  12749.  
  12750. End of Info-Kermit Digest
  12751.  
  12752. Page 232                                              INFO-KERMIT DIGEST V3 #33
  12753.  
  12754. Info-Kermit Digest         Wed, 11 Dec 1985       Volume 3 : Number 33
  12755.  
  12756. Departments:
  12757.  
  12758.   MS-DOS KERMIT 2.28 JRD -
  12759.     MS-DOS Kermit 2.28 jrd Not on BITnet
  12760.     MS-DOS Kermit 2.28 jrd Bug with X Packets
  12761.     Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT
  12762.     Suggestion for MS-DOS 2.29
  12763.     Minor Mod to New MS-DOS Kermit
  12764.  
  12765.   MISCELLANY -
  12766.     Apple-II Kermit Bugs
  12767.     Multics Kermit
  12768.  
  12769. ----------------------------------------------------------------------
  12770.  
  12771. Date: Wed 11 Dec 85 10:13:20-EST
  12772. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12773. Subject: MS-DOS Kermit 2.28 jrd Not on BITnet
  12774.  
  12775. In response to numerous requests from BITnet for Joe Doupnik's improved
  12776. version of MS-DOS Kermit 2.28, I'm sorry to say I can't put it on BITnet
  12777. just yet, for a variety of reasons which are too complicated to explain.
  12778. It looks as though this version will wind up replacing the current one --
  12779. one or two minor bugs need fixing, plus checkout is still required on the
  12780. Wangs, HP's, NECs, etc -- and at that time it will replace the current
  12781. version on BITnet.
  12782.  
  12783. I'm also sorry I mentioned the MS-DOS Kermit 2.27 that had VT100 support
  12784. added to it.  In response to numerous requests for it, let me just say that
  12785. in order to avert utter chaos, I would prefer to get the fixed 2.28
  12786. installed as the standard, base version, and then call for volunteers to
  12787. take the VT100 support and fit it into the new base version.  If we don't do
  12788. it that way, we'll have multiple proliferating divergent versions of the
  12789. program which will be impossible to support.  Those of you who whose phone
  12790. doesn't ring 500 times a day with MS-Kermit questions might not appreciate
  12791. why this is important, so you'll just have to take my word for it.
  12792.  
  12793. Once again, I apologize for the reduced level of support for MS-DOS Kermit
  12794. and the BITnet Kermit files.  Like I said before, it's because the people
  12795. who used to take care of these things have left Columbia.  They will be
  12796. replaced, but I can't say when.  Soon, I hope.
  12797.  
  12798. ------------------------------
  12799.  
  12800. Date: Tue 10 Dec 85 18:02:07-EST
  12801. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  12802. Subject: MS-DOS Kermit 2.28 jrd Bug with X Packets
  12803.  
  12804. First real bug -- if you send a generic command to a server which the server
  12805. does not support, and it sends back an error packet (which is the proper
  12806. behavior for servers under the circumstances), then the next file sent by
  12807. MS-DOS Kermit has its name in an X packet rather than an F packet, which of
  12808. course the server is not prepared to handle.  MS-DOS Kermit is apparently
  12809. setting its "X flag" in anticipation that the generic command will elicit a
  12810.  
  12811. INFO-KERMIT DIGEST V3 #33                                              Page 233
  12812.  
  12813. X packet or a data-bearing ACK from the server, and then not resetting it
  12814. when the transaction is terminated by an error.  In fact, it should not set
  12815. this flag until such a response actually occurs, and it should reset the
  12816. flag at the beginning of each transaction.  Reportedly, the same behavior
  12817. crops up randomly (not reproducibly) at other times.
  12818.  
  12819. Thanks also to others who reported this problem.  If anybody develops a fix
  12820. (it should be real simple, something like setting the X-Flag to 0 at the top
  12821. of the command loop), please send it in.
  12822.  
  12823. ------------------------------
  12824.  
  12825. Date: 9 Dec 85 08:57:00 PST
  12826. From: ALEX WOO <wu@ames-aero>
  12827. Subject: Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT
  12828.  
  12829. The new MS-DOS kermit seems to work fine on a 4.77MHz PC but it coughs on a
  12830. 18MHz PC AT with the error message
  12831.     "? Not enough memory to run kermit"
  12832. The PC AT has about 2MB of memory.
  12833.  
  12834. [Ed. - Beats me, anybody have any ideas?  Doesn't sound like anything that
  12835. would involve timing loops...  Do all your other programs work on your
  12836. souped up AT???  Does the old Kermit?]
  12837.  
  12838. Also, if there a Makefile for the MS-DOS version of Kermit, perhaps using
  12839. one of the Info-IBMPC makes.
  12840.  
  12841. [Ed. - There isn't, sorry.  Does anyone know if there is a "make" that will
  12842. support command line arguments, so you can say "make ibm", "make rainbow",
  12843. "make tipc", etc?  If so, which one is it, where is it?]
  12844.  
  12845. Alex.
  12846.  
  12847. ------------------------------
  12848.  
  12849. Date: Mon 9 Dec 85 04:18:07-EST
  12850. From: Joe Smith (415)794-2512 <LSM.SMITH@MARLBORO.DEC.COM>
  12851. Subject: Suggestion for MS-DOS 2.29
  12852.  
  12853. If you do plan to use MSKERMIT 2.28 jrd as the basis of the next release of
  12854. MS-DOS KERMIT, please add "SET TERMINAL mumble" and "SET DTR mumble" to the
  12855. system independent code.  Define dummy entry points in all the system
  12856. dependent modules so they can parse "mumble" or say "not implemented".  Then
  12857. the developers could add system specific arguments to these commands, such
  12858. as:
  12859.  
  12860.     SET TERMINAL NO-WRAPAROUND
  12861.     SET TERMINAL WIDTH 132
  12862.     SET TERMINAL ID VT125
  12863.     SET DTR ON
  12864.     SET DTR OFF
  12865.     SET DTR HANGUP-ON-EXIT
  12866.  
  12867. We need a general way to get to system-specific functions thru KERMIT's
  12868. command scanner.
  12869.  
  12870. Page 234                                              INFO-KERMIT DIGEST V3 #33
  12871.  
  12872.  
  12873. /JMS
  12874.  
  12875. [Ed. - These sound like useful hints for whoever is going to volunteer to
  12876. fit the VT100 support into 2.28 jrd.]
  12877.  
  12878. ------------------------------
  12879.  
  12880. Date: Sun, 8 Dec 85 01:23 EST
  12881. From: Larry Afrin <lbafrin%clemson.csnet@CSNET-RELAY.ARPA>
  12882. Subject: Minor Mod to New MS-DOS Kermit
  12883.  
  12884. The new MS-DOS Kermit (jrd's rewrite/mod of 2.28) has a minor problem when
  12885. it invokes COMMAND.COM to do stuff like TYPEing out files, DELeting files,
  12886. running CHKDSK, and RUNning any other program: when you type in the command
  12887. line in response to the "Kermit>" prompt, and then hit Enter, only a
  12888. carriage return is echoed.  No line feed.  This means that the first line of
  12889. output (either from COMMAND.COM or from the program loaded in by
  12890. COMMAND.COM) overwrites the "Kermit>" prompt and the command you typed.
  12891. Trivial, I admit, but aesthetically displeasing.  I made the following mod
  12892. in the location of the "run3" label in the MSKERM.ASM module in
  12893. PS:<KERMIT-MS> to output the needed line feed.
  12894.  
  12895. [Ed. - I've appended your code to the MSKERM.BWR file, but I can't reproduce
  12896. the problem, either on a PC/AT or a Rainbow.]
  12897.  
  12898. Other than this minor problem, I haven't found anything wrong yet with
  12899. jrd's version.  I'm running PC-DOS 3.10 on a plain vanilla PC.
  12900.  
  12901. Still waiting for a VT100 emulator to replace the Heath-19, though... (hey,
  12902. we can dream, can't we?)
  12903.  
  12904. [Ed. - Yes, but can we volunteer?]
  12905.  
  12906. P.S.  I'm running MASM version 1.00 (from the Dark Ages of 1981), and in
  12907. order to get the segments in the right order for the linker, I had to change
  12908. all references to segment name STACK to segment CTACK.  These references are
  12909. in modules MSKERM.ASM (4 references) and MSXDMB.ASM (2 references).  If you
  12910. don't make this change, the machine winds up taking a long walk off a short
  12911. pier when you hit Control-] C to come back from on-line mode to command
  12912. mode.
  12913.  
  12914. [Ed. - Anyone else have this problem?  I assembled the files with Microsoft
  12915. MASM 1.10 (1981,82) using no switches, and not renaming any segments, and
  12916. the result worked fine.  Also, has anybody ever heard of the /DOS switch
  12917. that Joe mentioned in his letter?]
  12918.  
  12919. ------------------------------
  12920.  
  12921. Date: Fri 6 Dec 85 01:25:39-EST
  12922. From: Peter G. Trei <OC.TREI@CU20B.COLUMBIA.EDU>
  12923. Subject: Apple-II Kermit Bugs
  12924.  
  12925. In reference to Sam Lam and Bruce Jolliffe's fix for the Apple ][ Kermit's
  12926. 8th bit quoting bug, here is a way to install it in version 2.1a without
  12927. doing another download. I have not yet had the opportunity to perform
  12928.  
  12929. INFO-KERMIT DIGEST V3 #33                                              Page 235
  12930.  
  12931. thorough checking and testing of this fix, so be cautious!
  12932.  
  12933. [This patch only works for version 2.1a]
  12934. Make a copy of your kermit-65 disk.
  12935. Boot with the new disk.
  12936. Enter the following DOS commands:
  12937.  
  12938. ] UNLOCK KERMIT
  12939. ] BLOAD KERMIT
  12940. ] POKE 17303,35
  12941. ] POKE 17317,21
  12942. ] POKE 17329,9
  12943. ] POKE 17399,194
  12944. ] DELETE KERMIT
  12945. ] BSAVE KERMIT,A$801,L$4E9B
  12946.  
  12947. As soon as I have finished checking this fix, I will ask Frank to put the
  12948. updated source and hex files into the download area on CU20B for
  12949. distribution. This may be related to the bug that strips out '&' on
  12950. reception of files.
  12951.  
  12952.                             Peter Trei
  12953.                             oc.trei@cu20b
  12954.  
  12955. ------------------------------
  12956.  
  12957. Date:  Fri, 6 Dec 85 17:20 EST
  12958. From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
  12959. Subject:  Multics Kermit
  12960.  
  12961. As of approximately now, the 'real' Multics kermit is the one with which
  12962. problems were reported in V3#32.  It is a version created at Calgary and
  12963. being distributed with the system and supported by Honeywell (it is,
  12964. consequently, unlikely to be released to the Columbia archives).
  12965.  
  12966. It supports many options that the various older versions and kludges do not,
  12967. incluing server mode, 8th-bit-quoting, etc., and is structured much more
  12968. like other Multics commands that do similar things, such as the Internet FTP
  12969. command.  Its default option settings, however, tend to be a little more
  12970. optimized for Multics<->Multics transfers over X.25 and dial circuits than
  12971. for PC->Multics or Internet TAC use.  Users with problems should probably
  12972. bug Honeywell over conventional channels, as this is a supported product.
  12973.  
  12974. Does that help?
  12975.  
  12976. [Ed. - I guess.  Columbia, by the way, has never received this version of
  12977. Multics Kermit.  I suppose if all Multics sites get it automatically, no
  12978. harm is done.]
  12979.  
  12980. ------------------------------
  12981.  
  12982. End of Info-Kermit Digest
  12983.  
  12984. Page 236                                              INFO-KERMIT DIGEST V3 #34
  12985.  
  12986. Info-Kermit Digest         Thu, 19 Dec 1985       Volume 3 : Number 34
  12987.  
  12988. Departments:
  12989.  
  12990.   ANNOUNCEMENTS -
  12991.     New Honeywell CP-6 Kermit
  12992.     New version of IMUSIC
  12993.  
  12994.   MS-DOS KERMIT -
  12995.     MS-DOS Kermit 2.28 jrd Problems and Fixes
  12996.     IBM-PC Kermit V2.28 jrd Display Problems
  12997.     TopView Support for MS-DOS Kermit
  12998.     More MS-DOS Kermit 2.28 jrd Problems
  12999.     MSBOOT.FOR for Unix f77
  13000.  
  13001.   MISCELLANY -
  13002.     DEC-20 File Naming Problem
  13003.     Os9 kermit warning!
  13004.     Bugs in the CP/M Turbo-Pascal Kermit V1.00
  13005.     Re: Apple-II Kermit Bugs
  13006.  
  13007. ----------------------------------------------------------------------
  13008.  
  13009. Date: Thu, 18 Dec 85  10:50 EST
  13010. From: Frank da Cruz <SY.FDC@CU20B>
  13011. Subject: New Honeywell CP-6 Kermit
  13012.  
  13013. This is to announce a new Kermit program for Honeywell CP-6 systems from Lee
  13014. Hallin at Honeywell (Lee-Hallin%LADC@CISL).  This one is written in PL/6, a
  13015. PL/I-like language, and includes text/binary file transfer, wildcards, all
  13016. the prefixing options, server and client operation, command files, etc, but
  13017. lacks CRC, file interrupt, attributes.  (The other CP-6 Kermit is written in
  13018. Pascal and comes from Bucknell University.)
  13019.  
  13020. Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*.
  13021. Again, apologies to everyone on BITNET for the hiatus in getting new files
  13022. on KERMSRV; we should be back in business on that end after the holidays.
  13023.  
  13024. ------------------------------
  13025.  
  13026. Date: Mon, 16 Dec 85  20:14 EST
  13027. From: John Voigt - Systems Group Tulane <SYSBJAV@TCSVM.BITNET>
  13028. Subject: New version of IMUSIC
  13029.  
  13030. I have a new version (1.2) of IMUSIC KERMIT available.  This version
  13031. incorporates several fixes as well as enhancing the set ? function.  I have
  13032. sent you the complete source with all the new changes.
  13033.  
  13034. JV/
  13035.  
  13036. [Ed. - Thanks!  This replaces the previous version (1.1) on CU20B.  It's
  13037. in KER:IMUSIC.ASM.]
  13038.  
  13039. ------------------------------
  13040.  
  13041. Date: 12 Dec 85 21:23:04 PST (Thu)
  13042.  
  13043. INFO-KERMIT DIGEST V3 #34                                              Page 237
  13044.  
  13045. Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes
  13046. From: donovan@aero
  13047.  
  13048.    I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send
  13049. protocol.  The problem occurs when a send command follows a Kermit generic
  13050. command which causes flags.xflg to be set.  This happens whenever a remote
  13051. server displays output on the local screen.  The GENRIC procedure in MSSSER
  13052. is the culprit, but the simplest fix is to reset xflg in the SEND command
  13053. processor just before the server entry point at SEND11.  Here are diffs for
  13054. MSSSEN.
  13055.  
  13056. ..........mssend.old
  13057. ;    Send command
  13058.  
  13059. ..........msssen.asm
  13060. ;    Send command - protocol handler to send a file
  13061. ; Normal entry - SEND does file transfer preceded by "F" packet
  13062. ;         resets xflg
  13063. ; Server entry - SEND11 does file transfer preceded by "X" packet
  13064. ;         set xflg = 1 before call
  13065.  
  13066. ..........mssend.old
  13067. send11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
  13068.     mov ah,setdma        ; set dta address [jrd]
  13069.  
  13070. ..........msssen.asm
  13071.     mov flags.xflg,0    ; Reset flag for normal file send [mtd]
  13072. SEND11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
  13073.     mov ah,setdma        ; set dta address [jrd]
  13074.  
  13075. [Ed. - Thanks!  This was the most glaring bug in this version.]
  13076.  
  13077. Also, the Z-100 version has had a bug in backspace processing since v2.27.
  13078. When entering Kermit commands at the prompt, backspace (^H) won't back up
  13079. over characters on the screen.  The problem is caused by a change made to
  13080. MSSCMD.ASM near the label "cmge11".  Backspace was removed from the set of
  13081. characters which are echoed.  The fix is to change MSXZ10.ASM to send an
  13082. extra backspace.  "diff"s below.
  13083.  
  13084. ..........msxz10.old
  13085. delstr  db    BS,' ',BS,'$'     ; Delete string. [21d]
  13086. home    db    ESC,'H$'
  13087.  
  13088. ..........msxz10.asm
  13089. delstr  db    BS,BS,' ',BS,'$'     ; Delete string. [21d]
  13090. home    db    ESC,'H$'
  13091.  
  13092. The MS-DOS version with Joe Doupnik's modifications works with both HP150
  13093. and, with this fix, Z-100 modules.  Joe's modifications are a major
  13094. improvement to MS-DOS Kermit.  I suggest that once the documentation catches
  13095. up with the programming, the revised Kermit should be accepted as MS-DOS
  13096. Kermit v2.29.
  13097.  
  13098. [Ed. - Well, a couple more problems remain, and the contributions keep
  13099. pouring in.  But you're right, we have to draw the line somewhere.
  13100. See below...]
  13101.  
  13102. Page 238                                              INFO-KERMIT DIGEST V3 #34
  13103.  
  13104.  
  13105. ------------------------------
  13106.  
  13107. Date: Sat 14 Dec 85 05:33:09-EST
  13108. From: Kathleen Connors <GS4.K-CONNORS@CU20A.COLUMBIA.EDU>
  13109. Subject: IBM-PC Kermit V2.28 jrd Display Problems
  13110.  
  13111. I tried the new 2.28 version of Kermit for the IBM PC tonight.  It still has
  13112. some of the same problems (2 out of 3) that the old 2.28 version had, which I
  13113. reported to you last June.
  13114.  
  13115. 1) When you GET a file the file transfer screen puts an "s"
  13116.    in upper left hand corner of the screen.
  13117.  
  13118. 2) The mode line under the same conditions displays nothing
  13119.    except a single "^" in the first position.
  13120.  
  13121. The truncation of the file name upon receiving a file has been fixed.  I am
  13122. using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal
  13123. Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still
  13124. exist I will probably continue to version 2.27.
  13125.  
  13126. [Ed. - Has anyone else ever seen this?  I haven't, and I've been running
  13127. both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.]
  13128.  
  13129. Suggestions for future Kermits:
  13130.  
  13131. 1) A means of clearing the terminal screen buffer from the local Kermit.
  13132.  
  13133. 2) The Kermit initialization file should be allowed to be
  13134.    called KERMIT.INI instead of MSKERMIT.INI.
  13135.  
  13136. [Ed. - The reason it's called MSKERMIT.INI is that if you accidentally
  13137. transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty
  13138. surprises the next time you started Kermit up on your PC.]
  13139.  
  13140. 3) The ability to send a file "raw" without the Kermit protocol just xon/xoff.
  13141.  
  13142. [Ed. - Everybody wants this, along with login scripts and a DIAL command.
  13143. Maybe someday someone will write the code.]
  13144.  
  13145. ------------------------------
  13146.  
  13147. Date: 12/16/85  6:10:45 E.S.T.
  13148. From: TUCBOB@TUCCVM.BITNET
  13149. Subject: TopView Support for MS-DOS Kermit
  13150.  
  13151. Here is a new MSYIBM terminal emulation module; the following changes
  13152. were made:
  13153.  
  13154. . ANSI set graphics rendition support extended to handle color attributes
  13155.    in addition to monochrome
  13156.  
  13157. . Direct moves to and from the video buffer modified to use TOPVIEW
  13158.    interrupt codes, so that KERMIT can run in the background under
  13159.    TOPVIEW and take advantage of TOPVIEW windowing support.
  13160.  
  13161. INFO-KERMIT DIGEST V3 #34                                              Page 239
  13162.  
  13163.  
  13164. The following parameters are used in a TOPVIEW Program Information File to run
  13165. KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added.
  13166.  
  13167. Memory:  Variable.  Suggest min and max be set to 128K to allow 'run' support.
  13168.  Set system memory to about 20K
  13169.  
  13170. Screen type: D
  13171.  Pages: 4
  13172.  Window size: 25 by 80
  13173.  Offsets:     0     0
  13174.  
  13175. Writes directly to screen:   no
  13176.  Accesses system keyboard buffer:  no
  13177.  Runs only in the foreground:   no
  13178.  Uses math coprocessor:    no
  13179.  
  13180. [Ed. - Thanks!  I haven't had a chance to try this out, but if these are the
  13181. only changes, then it should be compatible with JRD's new stuff, except for
  13182. one minor change that JRD made about Heath line wrap.  If anybody wants to
  13183. try this out, the file is with JRD's Kermit, stored as
  13184. PS:<KERMIT-MS>MSYIBM.TOP on CU20B only -- If you take it, please report back
  13185. about how/if it works, and whether it's safe to distribute as the standard
  13186. version.]
  13187.  
  13188. ------------------------------
  13189.  
  13190. Date: Thu 19 Dec 85 09:24:23-EST
  13191. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  13192. Subject: More MS-DOS Kermit 2.28 jrd Problems
  13193.  
  13194. Beyond the bugs reported already (like the X-Flag bug), there are at least
  13195. two subtle problems with the new MS-DOS Kermit.  First, even when assembled
  13196. correctly with the "right" assembler and switches, it will sometimes (very
  13197. rarely) start executing garbage after a CONNECT command.  This happened to
  13198. me exactly once in several weeks of constant use -- I had escaped back from
  13199. a connection to the DEC-20, gave the DO IBM command, switched my port
  13200. contention unit to the IBM mainframe, gave the CONNECT command, and poof --
  13201. system totally dead, had to be rebooted.  A few other people have reported
  13202. similar occurrences.  I can't reproduce it; can anybody else?
  13203.  
  13204. The second problem applies to earlier releases as well, but only shows up
  13205. on a PC/AT, and (for us at least) only when communicating with a half duplex
  13206. system at 9600 baud using handshake.  The sympton is that, after the end of a
  13207. file transfer session from the mainframe to the PC, after the mainframe sends
  13208. the B (Break transmission) packet, the AT responds with its ACK, but the ACK
  13209. shows up as garbage at the mainframe.  If on the AT you SET DEBUG ON, the
  13210. problem goes away.  When the connection is run through a line monitor,
  13211. everything appears normal; the AT responds to each packet from the mainframe
  13212. immediately as the XON handshake appears, and ACK is in correct format.
  13213.  
  13214. The speculation is that the AT is somehow ACKing the B packet "too fast".
  13215. Even though we haven't caught it sending the ACK prematurely on the line
  13216. monitor, the behavior is exactly what you'd expect if a transmission
  13217. occurred before the line was fully "turned around".  Why would this happen
  13218. after a B packet, but not after any other packet?  Several possible
  13219.  
  13220. Page 240                                              INFO-KERMIT DIGEST V3 #34
  13221.  
  13222. explanations suggest themselves: (a) unlike most other packets, the B packet
  13223. requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit
  13224. somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is
  13225. handling the UART incorrectly.
  13226.  
  13227. I think (b) is unlikely; we never saw any supporting evidence on the line
  13228. monitor.  While (c) is a possibility, it would take a lot of digging through
  13229. the low-level code to show up a problem; a cursory inspection reveals
  13230. nothing obvious (the UART's output holding register is always tested for
  13231. emptiness before giving it the next character).
  13232.  
  13233. If (a) is true, it would imply that the host is sending its XON before it is
  13234. really and truly ready for input.  Unlikely as this may seem (it's a
  13235. lightly-loaded IBM 3083), the fact that the problem only happens with the AT
  13236. -- which is much faster than the PC or the Rainbow -- lends some credence to
  13237. this theory.  If this is the real explanation, then the thing to do would be
  13238. to insert a brief sleep in MS-DOS Kermit before ACKing the B packet.  But
  13239. there are also some other packets that don't require any processing, namely
  13240. those that arrive with bad checksums; thus we might have to sleep before
  13241. retransmitting or NAKing as well.
  13242.  
  13243. If anyone can offer any insight or evidence to support any of these
  13244. theories, it would be much appreciated.  But beyond that, we may have here a
  13245. presage of things to come.  As microcomputers get faster and faster, they
  13246. may begin to strain the assumptions underlying the design of our
  13247. communications equipment.
  13248.  
  13249. ------------------------------
  13250.  
  13251. Date: 13 Dec 1985 1427-EST (Friday)
  13252. From: Tom Putnam <ac4@purdue-asc.ARPA>
  13253. Subject: MSBOOT.FOR for Unix f77
  13254.  
  13255. The subject FORTRAN program is supposed to be run on a host machine in
  13256. conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download
  13257. MSKERMIT.BOO and similar binary files.  The program requires several
  13258. modifications to operate under UNIX.  (We are running UNIX 4.2 BSD).
  13259. In particular:
  13260.  
  13261.  * The variable ACK is declared as a 4-element array, but only the
  13262.    first element is ever used.  The initial READ statement:
  13263.           READ (5,200) OK, SPACE, COMMA, ACK
  13264.     200   FORMAT(4A1)
  13265.    implies that the whole array ACK will be read.  Since the format does
  13266.    not allow enough elements, a second "line" or "record" of input is
  13267.    requested, so file transfer never gets off the ground.
  13268.  
  13269.  * The write statements include a blank for carriage control.  Although
  13270.    some systems strip this character on output to the terminal, UNIX terminal
  13271.    output includes the blank and thus fouls up the character count check.
  13272.  
  13273. I corrected these problems, converted the program to FORTRAN-77, and
  13274. cleaned-up the logic a little so that we could use it on our systems.
  13275. The modified version of the program is available via anonymous ftp from
  13276. ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f".
  13277.  
  13278.  
  13279. INFO-KERMIT DIGEST V3 #34                                              Page 241
  13280.  
  13281. [Ed. - It's also on CU20B as KER:MSBOOT.F.]
  13282.  
  13283. Tom Putnam, Manager of User Services
  13284. Purdue University Computing Center
  13285.  
  13286. ARPANET: ac4@asc.Purdue.EDU
  13287.      or  ac4@purdue-asc.ARPA
  13288. BITNET:  PUTNAMT@PURCCVM
  13289. CSNET:   ac4@purdue-asc-tn
  13290. USENET:  ac4@pucc-j.UUCP
  13291. USMAIL:  Mathematical Sciences Bldg.
  13292.      West Lafayette, IN 47907
  13293. PHONE:     317/494-1787
  13294.  
  13295. ------------------------------
  13296.  
  13297. Date: Tue, 17 Dec 1985  13:34 EST
  13298. From: CPH%MIT-OZ@MIT-MC.ARPA
  13299. Subject: DEC-20 File Naming Problem
  13300.  
  13301. I am using TOPS-20 Kermit version 4.1 and running into the following problem:
  13302.  
  13303. The filenames that I am using on my microcomputer are in the same format as
  13304. TOPS20 filenames, that is, "<name>.<type>.<version>".  The software system
  13305. maintains the version numbers in the usual way.  As we have quite a few of
  13306. these computers, which are not tied together with a network, we use Kermit
  13307. to transfer files to and from MIT-OZ, our DEC 20.  This gives us all a
  13308. shared file system to work from.
  13309.  
  13310. Now, my problem is that I want to transfer files from my local machine to the
  13311. 20, retaining the version number (note that this works fine when transferring
  13312. from the 20 to the local machine).  This is so the version numbers on the 20
  13313. will match the version numbers on the local machine.
  13314.  
  13315. Unfortunately, TOPS20 Kermit doesn't have an option to do this.  As far as I
  13316. can tell, the only options I have are "set file naming unconverted" and "set
  13317. file naming normal-form".  In neither case is the version number I specify
  13318. used to write the output file on the 20.  Instead, the file is forced to be
  13319. a "newest" generation -- either "FOO.BAR.34.0" (where the <type> is
  13320. "BAR.34") or "FOO.BARX34.0", respectively.
  13321.  
  13322. Could this be changed?  It seems to me that if the version number is
  13323. explicitly specified, it does no harm to open the output file under that
  13324. name if one does not already exist.  Or, if that is not reasonable, could
  13325. you add an option, say, "set file naming literal", that does what I want?
  13326. It is really a pain for me to have to rename all my files after I transmit
  13327. them.
  13328.  
  13329. Thanks,
  13330. Chris Hanson
  13331.  
  13332. [Ed. - Thanks for the suggestion.  I'll try to add another file-naming
  13333. option to Kermit-20 in the next release.]
  13334.  
  13335. ------------------------------
  13336.  
  13337.  
  13338. Page 242                                              INFO-KERMIT DIGEST V3 #34
  13339.  
  13340. Date:  Mon Dec 16 10:58:59 EST 1985
  13341. From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV
  13342. Subject: Os9 kermit warning!
  13343.  
  13344.    A warning about using kermit under os9 on a tandy CoCo: If you use kermit
  13345. with the multi-pak and the delux rs-232 pak, that is you intend to use /t2
  13346. as your outgoing device you MUST have the rs-232 pak in slot 1 of the
  13347. multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be
  13348. in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot
  13349. 1. Also it appears that you must have the carrier forced on BEFORE you run
  13350. kermit if you are using sometype of smartmodem. (maybe some os9 wizard out
  13351. there can find a patch to the device driver to let /t2 look for the rs-232
  13352. pak in another slot).
  13353.  
  13354.   Kermit on the CoCo is still (as far as I know - maybe bob larson knows
  13355. more) untested using device /t1, the so called "bit banger" port.
  13356.  
  13357. ~ Addresses:  USmail: IRS, 1111 Constitution Ave. NW    Washington, DC 20224 ~
  13358. ~             Atten: M. Sunderlin PM:S:D:NO             Office Phone:        ~
  13359. ~ UUCP:  ...seismo!dolqci!irsdcp!scsnet!sunder          (202) 634-2529       ~
  13360. ~        ...decvax!philabs!ubbs!sund                    (FTS) 634-2529       ~
  13361. ~ CIS:   74026,3235                                                          ~
  13362.  
  13363. ------------------------------
  13364.  
  13365. Date: Wed, 18 Dec 85 13:32:59 cst
  13366. From: Jeff Woolsey <woolsey%umn.csnet@CSNET-RELAY.ARPA>
  13367. Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00
  13368.  
  13369. I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80,
  13370. and made some simple but useful enhancements.
  13371.  
  13372. Bug #1: Binary file transfers "worked" (everybody was happy with checksums)
  13373. but the file was missing the 8th bit sometimes.  &X would not get the 8th
  13374. bit set, but &#X would.  The code that checked for control characters in
  13375. this case forgot that this was an &-quoted character if it wasn't also
  13376. #-quoted.  The fix in the else clause should be obvious.  See procedure
  13377. expand_packet in file KREC1.PAS here:
  13378.  
  13379. [Ed. - Code omitted.]
  13380.  
  13381. Bug #2: This first showed up as filenames listed by the DIR command being
  13382. separated by linefeeds.  The solution eluded me until I realized that I was
  13383. in user area 10 (= ASCII linefeed) at the time.  Fix it by not writing the
  13384. first "character" of the file name.  See procedure writefilename in file
  13385. KDIR.PAS.
  13386.  
  13387. Bug #3: The scourge of all machines using 16-bit signed integers.  The
  13388. displays of bytes (remaining to be) transferred wrap to negative integers
  13389. above 32767.  Since this number is calculated by multiplying blocks by 128
  13390. (an integer), you really only get 9 bits of information there.  This can be
  13391. remedied by multiplying by 128.0 (a real) and formatting the result.  See
  13392. procedure update in file KDISPLAY.PAS.  See procedure open_file in file
  13393. KOPEN.PAS.
  13394.  
  13395. Enhancement #1: I got tired of having to tell the host explicitly the name
  13396.  
  13397. INFO-KERMIT DIGEST V3 #34                                              Page 243
  13398.  
  13399. of each file I was downloading when I should have been able to use
  13400. wildcards.  The impediment here is that Turbo Kermit goes to receive_init
  13401. state when it gets the EOF packet, and expects a send_init packet from the
  13402. host. Instead, it gets a file_header packet, and aborts.  A two-line change
  13403. allows Kermit to receive multiple files in this case.  Find the
  13404. repeat/case/until block that processes the incoming packets.  Only one of
  13405. the cases ever sets the state variable (to receive_init). Change it to
  13406. receive_header, and add a clause to the until condition checking for state
  13407. <> receive.  See procedure rfile in file KREC1.PAS here
  13408.  
  13409. [Ed. - Code omitted.]
  13410.  
  13411. Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to
  13412. be able to see the name of the file being transferred along with all the
  13413. other statistics being displayed.  I stuck "gotoxy(58,2); write(fileref);"
  13414. at the front of procedure open_file in file KOPEN.PAS.
  13415.  
  13416. The above should be of general interest.  What follows summarizes the other,
  13417. more machine-specific changes that I needed to make.
  13418.  
  13419. I undid the IOBYTE stuff so that I could support all 4 of the serial ports
  13420. on my system.  I have a 1200 bps autodialing modem and a dumb 2400 bps modem
  13421. and I wanted to be able to autodial 2400 bps systems.  I support searching
  13422. through the various PAMS/PDSE/et.al. BBS lists and extracting the phone
  13423. numbers.  I rewrote pieces of the command processor to make it easier to add
  13424. new commands while retaining the ability to abbreviate them to uniqueness,
  13425. and I implemented meaningful semantics for commands like CONNECT 1 or
  13426. RECEIVE FRED.PAS .  I have a text capture mode, and if I desire the terminal
  13427. handler converts ANSI escape sequences into H19 sequences for my console.
  13428. ...
  13429. The aim of Nuclear Freeze is to prevent Nuclear Winter.
  13430.  
  13431.                 Jeff Woolsey
  13432.                 ...ihnp4{!stolaf}!umn-cs!woolsey
  13433.                 woolsey@umn-cs.csnet
  13434.  
  13435. [Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on
  13436. CU20B, and have also passed it along to the Turbo Pascal Kermit authors.]
  13437.  
  13438. ------------------------------
  13439.  
  13440. Date: Wed, 11 Dec 85 16:55:16 PST
  13441. From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA
  13442. Subject: Re: Apple-II Kermit Bugs
  13443.  
  13444. >This may be related to the bug that strips out '&' on reception of files.
  13445.  
  13446. This IS the bug that strips out '&' on reception regardless of the setting
  13447. of text/binary and 7/8 bit data path.  When it sees an '&' in the incoming
  13448. data stream, it just unconditionally strips it and turns on the 8th bit of
  13449. the next character.
  13450.  
  13451. Sam Lam
  13452.  
  13453. ------------------------------
  13454.  
  13455.  
  13456. Page 244                                              INFO-KERMIT DIGEST V3 #34
  13457.  
  13458. End of Info-Kermit Digest
  13459.  
  13460. INFO-KERMIT DIGEST V3 #35                                              Page 245
  13461.  
  13462. Info-Kermit Digest         Tue, 24 Dec 1985       Volume 3 : Number 35
  13463.  
  13464. Departments:
  13465.  
  13466.   MS-DOS KERMIT -
  13467.     Kermit 2.28 jrd Bug Report
  13468.     Fast Kermit for AT?
  13469.     IBM-PC Kermit v2.28 Display Problems
  13470.     Kermit for Victor
  13471.  
  13472.   MISCELLANY -
  13473.     Kermit for Apples with StarCard
  13474.     Request for KERMIT binary for Radio Shack 6000 Xenix
  13475.     Set File 8-Bit in Kermit-20
  13476.  
  13477. ----------------------------------------------------------------------
  13478.  
  13479. Date: 23 DEC 85 13:15-MST
  13480. From: JRD@USU.BITNET
  13481. Subject: Kermit 2.28 jrd Bug Report
  13482.  
  13483. 1. Thanks for the mail messages and nice words. Using Bitnet here is magic
  13484. of a rather dark hue, alas.  Given that you seem to have a shortage of
  13485. MS-DOS folks perhaps I can get the mail via Bitnet and help solve the sundry
  13486. bugs as they arrive and then send responses to you for editing.
  13487.  
  13488. 2. Bugs of various kinds in "MS Kermit 2.28 jrd" are discussed below.
  13489.  
  13490. 3. Rare computer hangups when engaging IBM mode and then entering the
  13491. Connect state. Peering at the interrupt level code in file MSXIBM shows
  13492. several places of difficulty if the mainframe were to have sent a char
  13493. before Kermit was ready to accept one. Some changes were made to hopefully
  13494. avoid problems; all involve completing work before interrupts can interfere.
  13495. The hangup problem seems to be like a corrupted segment register (ds?),
  13496. which could happen I suppose if a char arrived during serial port
  13497. initialization.  Actually, I or someone needs to have a hard look at the
  13498. code in SERINT to see if all UART conditions are properly serviced and if
  13499. the 8259 interrupt controller chip is attended to in an manner consistent
  13500. with both IBM PCs and ATs. ISRs are such fun! My quick changes are as
  13501. follows.
  13502.  
  13503.   Procedure SERINI:
  13504.    - flush UART received character BEFORE turning on interrupts,
  13505.    - change allowable UART interrupting conditions to avoid interrupts on
  13506.      TX Holding Buffer Empty (a nonsense interrupt for us) but allow them
  13507.      on Data Available, RX Line Change, and Modem Change,
  13508.    - move push/pop es to allow quicker procedure exit,
  13509.    - replace call to proc Clrbuf with separate code since Clrbuf turns on
  13510.      interrupts within the body of SERINI (a likely culprit).
  13511.   Procedure SERRST:
  13512.    - move push/pop es to allow quicker procedure exit.
  13513.   Procedure SERINT:
  13514.    - send 8259 chip End-of-Interrupt signal as almost last item in the proc,
  13515.    - remove strange Enable Interrupts (sti) instruction within proc body;
  13516.      after all, we got here via an interrupt.
  13517.  
  13518.  
  13519. Page 246                                              INFO-KERMIT DIGEST V3 #35
  13520.  
  13521. 4. Data overrun when turning around line between IBM mainframe and IBM
  13522. PC/AT.  An obvious thing to do here is insert a small wait interval before
  13523. sending a packet (sending filler chars could still upset the host during
  13524. line turn around); this is usually called pacing.  In terms of fast micros
  13525. and sluggish mainframe terminal handlers, pacing seems to be one of the
  13526. solutions.  I added a 3 millisecond wait routine at the very beginning of
  13527. procedure OUTPKT in file MSCOMM; it may not be enough, but the delay is
  13528. easily adjusted.  If it's too long then we will lose the time slice, if too
  13529. short then mainframe loses the first part of a packet.
  13530.  
  13531. 5. Files sent while in server mode do not use repeat prefixing.  My goof due
  13532. to misunderstanding the non-standard protocol of setting the prefix char.  Two
  13533. lines of code were added in procedure SERVER (in file MSSERV) to force the
  13534. default prefix char into the active prefix after each server command.
  13535.  
  13536. 6. Items not clearly explained in original read.me file for 2.28 jrd.
  13537.  -- GET allows both file names to be on the same line; ex. GET theirs mine.
  13538.  -- GET allows ? chars in filenames after the first char, but I forgot to
  13539.     invoke the # --> ? translation. I think earlier versions omitted this
  13540.     also. Similarly, I parse both file names on whitespace (can be fixed)
  13541.     which is probably painful for IBM users.
  13542.  
  13543. 7. All these changes affect three files: MSXIBM, MSCOMM, and MSSERV. Below is
  13544. the output of MSDOS utility FC on the new and original "2.28 jrd" files. The
  13545. complete files, with extension of .NEW, are being sent as well.
  13546.  
  13547. 8. Happy holidays.  Joe
  13548.  
  13549. [Ed. - Now that we have established network connection with Joe, we can send
  13550. files back and forth rather quickly.  There may well be a few more
  13551. contributions from him in the coming weeks.  I've put the new files in
  13552. PS:<KERMIT-MS> on CU20B, in case anybody wants to check them out -- feedback
  13553. solicited and appreciated!]
  13554.  
  13555. ------------------------------
  13556.  
  13557. Date: Thu 19 Dec 85 16:51:47-PST
  13558. From: Ed Pattermann <PATTERMANN@sumex-aim.arpa>
  13559. Subject: Fast Kermit...
  13560.  
  13561. Does anyone have a patch for MS-KERMIT that allows it to work with IBM AT's
  13562. that have faster crystals installed, like a 18MHZ crystal? Kermit fails
  13563. to work after installing the new crystal.
  13564.  
  13565. [Ed. - Some of the changes mentioned in the previous message might go a long
  13566. way towards helping here.]
  13567.  
  13568. ------------------------------
  13569.  
  13570. Date: 19 Dec 85 16:39:48 PST (Thu)
  13571. From: Mike Iglesias <iglesias@UCI.EDU>
  13572. Subject: IBM-PC Kermit v2.28 Display Problems
  13573.  
  13574. I've seen the display problems that Kathleen Connors has seen with the original
  13575. v2.28 Kermit on both a IBM PC-I and a Compaq.  It appears to only happen on the
  13576. old motherboard PCs (we have only one of those here) and the Compaq (which must
  13577.  
  13578. INFO-KERMIT DIGEST V3 #35                                              Page 247
  13579.  
  13580. do something the same way that the PC-I does).  It does not happen on the newer
  13581. PCs (PC-II; 256k motherboard) or a Compaq 286, so I suspect it may have
  13582. something to do with the ROM BIOS.
  13583.  
  13584. Mike Iglesias
  13585. University of California, Irvine
  13586.  
  13587. ------------------------------
  13588.  
  13589. Date: 20 Dec 85 02:13:23 +0100
  13590. From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU  (YD14@BR1.THDNET)
  13591. Subject: Kermit for Victor?
  13592.  
  13593. I'm using a Vicky with "BIOS Version 2.9 February 4,1984 for V9000" and
  13594. MSDOS 2.11. I've tried to run the SIRIUS ASM available from KERMSRV
  13595. at CUVMA but it doesn't work. The CONNECT corrupts a lot of keys
  13596. (I'm using a German keyboard) and the RECEIVE doesn't work at 2400 baud.
  13597. The generic MSDOS kermit is running up to 2400 baud.
  13598.  
  13599. Has anyone a special kermit version for the Vicky (Victor 9000) PC?
  13600.  
  13601. Thanks
  13602.  
  13603. Reinhard Goeth (Techn. Univ. of Darmstadt/Fed. Rep. of Germany)
  13604.  
  13605. P.S. I wish you a merry chrismas and a happy new year.
  13606.  
  13607. ------------------------------
  13608.  
  13609. Date:     Fri, 20-DEC-1985 08:53 MST
  13610. From:     Eric Zurcher <REHABIV@USU.BITNET>
  13611. Subject:  KERMIT for Apples with StarCard
  13612.  
  13613.         I thought I'd pass along a few things that I've learned while trying
  13614. to implement KERMIT on an Apple ][+ with a StarCard CP/M board.  All of this
  13615. may already be familiar to you, but I provide it to you on the chance that it
  13616. may keep someone else from having to reinvent the wheel.
  13617.  
  13618.         "Official" versions of KERMIT exist for Apples using the SoftCard CP/M
  13619. board, but I could not locate any for the StarCard.  The SoftCard versions do
  13620. not work, since the two CP/M boards use quite different approaches in gaining
  13621. access to the Apple's ports.  I have found that the "generic" CP/M KERMIT can
  13622. be made to work quite well with the StarCard, but only after making a minor
  13623. alteration in the BIOS of the operating system provided with the card.  In its
  13624. standard configuration, the BAT: device is identical to the CRT: device, both
  13625. refering to the Apple's monitor and keyboard.  However, changing a single byte
  13626. in the BIOS will cause the BAT: device to refer to a serial card in slot 2 of
  13627. the Apple, which is of course the sort of arrangement that generic KERMIT
  13628. needs.  The byte in question is located at an offset of 63H from the start of
  13629. the JMP tables of the BIOS (that is, it can be easily located by adding 60H to
  13630. the address pointed to by the JMP instruction at address 0).  This address
  13631. normally contains the value CC - changing it to C8 will result in the
  13632. definition of the BAT: device being changed to slot 2 of the Apple.  (I have
  13633. not seen this "feature" documented anywhere, though I have not requested
  13634. technical documentation from the manufacturers of the StarCard.)  Once this
  13635. change is made, generic KERMIT works quite well.
  13636.  
  13637. Page 248                                              INFO-KERMIT DIGEST V3 #35
  13638.  
  13639.  
  13640.         I'm currently working (though not very hard) on the rather simple task
  13641. of developing a KERMIT that will handle the task of modifying this byte, if
  13642. necessary.  At present, I get around the problem by booting the system with a
  13643. disk that contains a version of the BIOS in which I have already modified the
  13644. byte.  I've also managed to combine a few features of the SoftCard KERMITs with
  13645. the generic KERMIT, to allow VT52 emulation to work and to "tidy up" the
  13646. display during file transfers.  It works reasonably well.  If you wish, I will
  13647. send a version to you once I get everything working the way I'd like.
  13648.  
  13649.         There are a few caveats (aren't there always?): (1) an 80-column
  13650. display enhancer is almost a necessity for reasonable terminal usage;  the
  13651. StarCard can try to produce a 70-column display using software, but this is too
  13652. slow to keep up at even 1200 baud.  (2) I have not thoroughly tested this, but
  13653. I suspect that a DC Hayes MicroModem II will not work with this arrangement -
  13654. the problem is that you can't dial a number.  It does appear to be possible to
  13655. first dial and establish the connection under Apple DOS, then reboot the
  13656. machine to run CP/M.  In any case, whatever serial interface is used must be in
  13657. slot 2 of the Apple.  (3) I have not tested this arrangement at speeds above
  13658. 1200 baud, but I suspect that faster speeds will not work well.  (4) Most of
  13659. the VT52 emulation features work as they should, but the "home and clear
  13660. screen" operation is a bit slow - at 1200 baud I usually lose the next dozen or
  13661. so characters received after this operation.  (5) It appears that data is
  13662. restricted to 7-bit, and not 8-bit bytes.  For transfer of non-ASCII files,
  13663. parity should be set to space.
  13664.  
  13665.         I hope somebody, somewhere, finds some of this useful.  In the long
  13666. run, it would be preferable to have a KERMIT for this system which accesses
  13667. the serial port a bit more directly, rather than through twiddling the IObyte,
  13668. but I will leave that task to someone else.
  13669.  
  13670.                                         Regards, and Merry Christmas!
  13671.                                         Eric Zurcher
  13672.                                         Dept. of Biology
  13673.                                         Utah State University
  13674.                                         Logan, Utah 84322-5305
  13675.                                         REHABIV@USU
  13676.  
  13677. [Ed. - Thanks for the information; I've added your message to the APPLE.BWR
  13678. file for the time being.  USU seems to be a beehive of Kermit activity these
  13679. days...]
  13680.  
  13681. ------------------------------
  13682.  
  13683. Date: Sun, 22 Dec 85 11:41:56 EST
  13684. From: Glenn Ricart <glenn@mimsy.umd.edu>
  13685. Subject: Request for KERMIT binary for Radio Shack 6000 Xenix
  13686.  
  13687. I'd like to run KERMIT under Xenix on a Radio Shack 6000 (previously
  13688. known as the 16B before some magic happened).  Unfortunately, this
  13689. system does not have a C compiler so I can't start from the sources.
  13690. Could someone contribute the binary?  . . . . Thanks!
  13691.  
  13692. ------------------------------
  13693.  
  13694. Date: Sun, 22 Dec 1985  13:29 MST
  13695.  
  13696. INFO-KERMIT DIGEST V3 #35                                              Page 249
  13697.  
  13698. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  13699. Subject: Set File 8-Bit in Kermit-20
  13700.  
  13701. Request for change in next update of Kermit-20:  Because I do a lot of
  13702. uploading to Simtel20 and frequently use SEND *.* to do it, I have my
  13703. KERMIT.INI do SET FILE BINARY.  No problem so far, as I can use ASCIFY
  13704. later to fix the ascii files - meantime I can go away from the
  13705. computer and let things transfer automatically (of course my Kermit-80
  13706. is set to default to SET FILE BINARY).
  13707.  
  13708. Now the problem: When downloading from Simtel20, that INI is still in
  13709. effect and I get garbage on ascii files sent to me.  I need to be
  13710. able to tell Kermit-20 to use SET FILE 8-BIT for sends from me to
  13711. Simtel20, and SET FILE AUTO for sends from Simtel20 to me.
  13712.  
  13713. Suggest it might be added as SET FILE SEND AUTO and SET FILE RECEIVE
  13714. 8-BIT.
  13715.  
  13716. --Keith
  13717.  
  13718. [Ed. - Good idea, will probably be added to the next release.]
  13719.  
  13720. ------------------------------
  13721.  
  13722. End of Info-Kermit Digest
  13723.  
  13724. Page 250                                                                       
  13725.  
  13726.  
  13727. Index                                                                  Page 251
  13728.  
  13729. .EXE File Transfer, 107
  13730. 3B2 Kermit, 114-115
  13731. 6809 Kermit, 89
  13732. 7171 Protocol Converters, 88-89, 105, 121, 128
  13733. APC III Kermit, 125
  13734. Apple II DOS Kermit, 16-17, 76
  13735. ASCII/EBCDIC Translation Tables, 32, 48
  13736. Asyncronous Protocols, 61
  13737. Attribute Packets, 74
  13738. BITnet KERMSRV, 112
  13739. BTOS, 85, 90
  13740. Burroughs B2x, 85
  13741. Burroughs B2x Kermit, 90
  13742. C-Kermit, 7-9, 14, 32, 59, 74, 84, 89, 95, 97, 114-119, 121-122
  13743. Checksums, 25
  13744. Commodore 64, 15
  13745. COMPAQ Portable, 128
  13746. CompuPro Kermit, 93
  13747. Concurrent DOS, 111
  13748. Concurrent Kermit, 94
  13749. Corona Portable PC, 104
  13750. CP/M-80, 68
  13751. CP/M-80 Kermit, 62-63
  13752. CR/LF, 108
  13753. Cromix Kermit, 129
  13754. CROSS Assembler, 94
  13755. DEC PRO300 Kermit, 91
  13756. DEC Rainbow, 103
  13757. Editor, 82
  13758. European Networks, 109, 126-127
  13759. Exxon Office System 500 Kermit, 129
  13760. Fortune 32:16 Kermit, 97
  13761. FTP Server, 1
  13762. Gavilan PC, 130
  13763. Hayes Modem, 93
  13764. Hercules Card, 29
  13765. Hercules Graphics Card, 57
  13766. HP1000 Kermit, 95
  13767. HP110 Kermit, 125
  13768. HP9000, 7
  13769. Hyperion Kermit, 105
  13770. IAS, 63
  13771. IBM 3270/PC, 18, 27
  13772. Japanese Micro Kermit, 112
  13773. Japanese Micro Kermits, 125
  13774. Kermit DIR, 82
  13775. Kermit Diskettes, 124
  13776. Kermit Protocol, 19
  13777. Kermit Protocol Proposal, 24-27, 53, 61
  13778. Kermit-11, 1, 28, 30, 63, 91
  13779. Leading Edge D PC, 104
  13780. Lisp, 123
  13781. LM-Kermit, 123
  13782. Long Packets, 21, 24-26, 31, 61, 66-67, 69-70, 72, 75, 80, 83, 87, 98-99
  13783. Lurching Windows, 52
  13784. Macintosh, 5
  13785.  
  13786. Page 252                                                                  Index
  13787.  
  13788. MacKermit, 2, 14, 28, 32, 57, 131-135
  13789. MASM, 7
  13790. MicroVAX-I, 12
  13791. MicroVAX-I Kermit, 17
  13792. MILNET, 95
  13793. MILNEY, 127
  13794. Modem, 4, 11
  13795. MS-DOS Kermit, 2-3, 6, 12, 29, 33, 57, 62, 77, 79, 94, 103, 111, 128, 130
  13796. NCR DMV Kermit, 129
  13797. ND Kermit, 3
  13798. NEC 8001, 110
  13799. NEX PC8800 Kermit, 125
  13800. NTT Lisp, 112
  13801. Okstate, 5, 30
  13802. Parity, 116
  13803. PDP-8 Kermit, 52
  13804. popdos2, 103
  13805. Prime Kermit, 11, 62, 95
  13806. Pro-3xx P/OS Kermit, 10
  13807. Professional Graphics Card, 50
  13808. Professional Grpahics Adapter, 33
  13809. RSX Kermit, 28
  13810. RT-11 Kermit, 84
  13811. Sharp PC 1500 A Kermit, 113
  13812. Sliding Window Kermit, 24
  13813. Sliding Windows Kermit, 4, 31, 34-35, 44, 54, 60-61, 65-70, 72, 74-75, 80, 83,
  13814.  87, 98-99
  13815. TELENET, 96, 127
  13816. Terminal Emulation, 28, 131, 135
  13817. TI 99/4A Kermit, 93
  13818. TRS-Xenix Kermit, 115
  13819. TSO Kermit, 32, 88-89, 105
  13820. Ungermann-Bass Net One, 51
  13821. UNIX, 1, 6
  13822. UNIX Kermit, 14, 32, 59
  13823. UTS Kermit, 121
  13824. UUCP, 9
  13825. VAX/VMS Kermit, 95, 97
  13826. VM/CMS Kermit, 95, 128
  13827. VM/CMS Pascal Kermit, 60
  13828. VMS Kermit, 14, 61-62, 76
  13829. Yale ASCII Communications Program, 95, 106
  13830. Z100 Kermit, 12, 17, 31
  13831.