home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / archives / researchmachines.tar.gz / researchmachines.tar / rmlnoddoc.txt < prev    next >
Text File  |  1985-07-11  |  21KB  |  423 lines

  1. File RMKNODDY.DOC
  2. -----------------        Chris Kennington    9th July 1985.
  3.  
  4.  
  5.  
  6.         Noddy Guide to the Use of KERMIT on
  7.         -----------------------------------
  8.  
  9.            RML 480Z and Nimbus Computers
  10.           ------------------------------
  11.  
  12.  
  13. 0.  Summary.
  14.     --------
  15.  
  16.      This guide tries to set out simply the steps needed to use a 480Z
  17. or Nimbus micro as a terminal to a mainframe computer or to transfer
  18. files between two micros or a micro and a mainframe.  The Kermit system
  19. used is copyrighted by the University of Columbia, New York.  They
  20. have produced a very full User Manual, a shortened version of which
  21. is in the file KUSER.DOC.  This gives a lot more explanation on some of
  22. the points covered below.  The RM Kermit program is described fully in
  23. the file RMKINFO.DOC.
  24.  
  25.  
  26.  
  27. 1.  Kermit - What It Does.
  28.     ----------------------
  29.  
  30.      The Kermit program lets you use a micro as a fairly standard terminal
  31. to (almost) any mainframe computer which runs a terminal system.  "Mainframe"
  32. here means anything from a Cray II down to a 68000 running Unix(TM).  To
  33. use Kermit in this way no special facilities at all are needed on the
  34. mainframe.
  35.  
  36.      The more important part of Kermit is that it also lets you transfer
  37. files between a micro and a mainframe, or between two micros.  To do this
  38. requires a version of the Kermit program running at both ends of the
  39. connection.  RML supplies Kermits for both 480Z and Nimbus; a version for
  40. later-model 380Zs is available from the University of Oxford.  Kermits
  41. have been written by various people for almost every micro and mainframe
  42. under the sun (except ICL equipment).  U. of Columbia maintain a distribution
  43. service at nominal cost.  In the U.K. educational users can get versions
  44. from the University of Lancaster.  Other groups which can help include
  45. DECUS (the DEC user organization) and the IBM-PC User Group.
  46.  
  47.      When sending files from one computer to another, Kermit makes sure that
  48. if the file is received at all it is received correctly.  The files can
  49. be either printable (text) files, which consist of normal printing
  50. characters and a few control-characters such as RETURN; or they can be
  51. binary files of any sort.  They must however be "sequential" files;
  52. "direct-access" files as used by some special programs cannot be moved
  53. between computers by Kermit.
  54.  
  55.  
  56.  
  57. 2.  Using the Menus.
  58.     ----------------
  59.  
  60.      When Kermit starts up, it displays a menu called "KERMIT MAIN MENU".
  61. This show you the different sorts of things it can do.  There are two
  62. other menus, "COMMANDS to SERVER" and the parameter-menu.  All work in
  63. much the same way.  An arrow on the right shows which item is currently
  64. selected; you can move this arow up and down by the up- and down-arrow
  65. keys, or by F1 and F3, or by PG UP and PG DOWN.
  66.  
  67.      The main and server menus get all their options on one screen.
  68. All you do is move the arrow and when it is on the correct line hit
  69. RETURN (480Z) or ENTER (Nimbus) to do what you want.  The parameter menu
  70. is more complicated; not only does it have many more parameters than
  71. can fit on the screen, but each parameter has values you can change.
  72. Using the arrow and F keys moves both the indicating arrow and the
  73. selection of parameters on display so that you can get at all of them.
  74. The current value of each parameter is displayed on the right of its
  75. name.  These values are changed by using the right- and left-arrow
  76. keys.  You should change any and all the parameters which you wish
  77. to, then hit RETURN or ENTER to get back to the main menu and do something
  78. useful.
  79.  
  80.      When you are viewing any menu, the bottom 5 lines are reserved for
  81. some helpful comments.  With the main and server menus these change as
  82. you go up and down the menu.  With the parameter menu you must enter
  83. "?" to get up the appropriate help-text.  In either case entering "H"
  84. will get you some general help on how to use the system.
  85.  
  86.  
  87.  
  88. 3.  Getting Started.
  89.     ----------------
  90.  
  91.      Make sure that you have got the correct version of RM Kermit for
  92. the 480Z or Nimbus that you are using.  There are different versions
  93. according to the way the communications-line is plugged in; this is
  94. described in the main documentation-file RMKINFO.DOC.  Run Kermit
  95. just as you would any other program, by typing its name (which may
  96. be KERMIT or else some recognizable derivative such as AKMIT21).
  97. If you are using a Nimbus with Piconet you will fiorst have to tell
  98. Kermit the address of the Piconet module which is connecting you to the 
  99. other computer.  Kermit will then come up with its main menu and some
  100. header information; check the item in the lower right corner
  101. "Communications:" to make sure that it corresponds with where your
  102. communications-cable is plugged in.  If it doesn't, get a new Kermit
  103. or a new communications-cable.
  104.  
  105.      The first thing that you need to do is make sure that you can
  106. actually send and receive characters to/from the other computer.
  107. All Kermit transfers require that you can both send and receive, so
  108. you will have to have a "full-duplex" cable connecting your micro to
  109. the other computer.  (This means that a "half-duplex" cable as used
  110. to connect some printers to micros is not suitable.)    Anyway, make
  111. sure that the cable used to connect the two computers is plugged into
  112. the right ports at both ends.
  113.  
  114.      There are two other fundamentals on which the computers must
  115. agree - line-speed and parity.  (Speed, measured in "baud", is the effective
  116. electronic frequency used on the connecting cable; parity describes the way
  117. that the 7-bit characters usually used for text are converted to and from
  118. the 8-bit characters sent on the communications line.)
  119. If the other computer is a mainframe, it will have firm
  120. ideas about these things and you can only set your micro-Kermit to agree.
  121. If you are running between two micros, then both must be set to the
  122. same values; if you have control in this way, use parity OFF and the
  123. fastest line-speed supplied.  (If you are connecting to the other computer 
  124. through a network or switching system, this may alter the speed and
  125. parity setting you have to use; ask the people who run it.)
  126.  
  127.      When you think that everything is correctly set, select "Connect
  128. to Mainframe" on the main menu and hit RETURN/ENTER.  Kermit will
  129. tell you that it is connecting you, and from then on everything you
  130. type will be sent and anything received will be shown on the screen.
  131. Your own type-in will not be shown on the screen unless you have 
  132. set the parameter "Local Echo" to ON.  If you are connected to a mainframe,
  133. type RETURN/ENTER (several times) and you should get whatever message
  134. it habitually displays to a newly-connected terminal.  If you are
  135. connected to another micro, type some text and see whether it is
  136. displayed on the other screen; do this in both directions.  If 
  137. these activities produce no result whatsoever, then you
  138. do not have contact.  Check that all the parameters are correctly
  139. set and the bits-and-pieces of equipment firmly plugged together
  140. and all computers alive.  If everything checks out, but you still
  141. don't get any response, you need help from your communications
  142. people.  Carry on with this document after they have sorted you out.
  143. If you are working to a mainframe and it gives ridiculous messages,
  144. try other settings of parity.
  145.  
  146.      When you are connected, all normal keys work like they would on
  147. a real terminal.  The Kermit program will only pay attention if you
  148. hit the F4 key (or on Nimbus also F6 to F10).  Hitting this causes
  149. Kermit to wake up and show a prompt "KmESC>" or "KmF4>".  It then
  150. expects you to give it either 1 or 2 more charcters to tell it what to
  151. do.  The full possibilities are described in RMKINFO.DOC, but a
  152. summary can be obtained by hitting ? after the prompt.  (This
  153. procedure is called "breaking in".)  The two most important
  154. possibilites at this point are to hit K after the prompt, which will
  155. get you back to the main menu, or Q which will let you cancel Kermit
  156. and run another program.  If you didn't mean to break in, hit
  157. RETURN/ENTER.
  158.  
  159.  
  160.  
  161. 4.  Transferring Files.
  162.     -------------------
  163.  
  164.      To transfer files you need to have a Kermit running at each end of
  165. the connection.  With two micros this just means loading Kermit into
  166. each separately, from its own keyboard.  With a mainframe it means
  167. connecting (as described above) and then working as a terminal until
  168. you have logged in and gone through any other work needed before
  169. you can start Kermit on the mainframe (or link to it if it is a
  170. permanently-running type).  You will also need to know something about
  171. how to run the mainframe Kermit - consult its helptexts or the
  172. mainframe user documentation.  In particular, find out whether it is
  173. a "server" or not.  Mainframe Kermits which are servers need only to
  174. be set going and then will take all their instructions from the Kermit
  175. running in the micro.  Other mainframe Kermits ( "simple" ones)
  176. need to be told what to do while you are still connected as a terminal,
  177. before you tell your micro Kermit what to do.
  178.  
  179.      Many mainframe Kermits work in an interactive manner.  This means
  180. that, while you are connected, they accept commands one at a time and
  181. send you back a response for each.  Others expect all their command
  182. information to be entered on the "command-line" which you type in to
  183. start them going.  In this case you have to go out of "connect" as 
  184. soon as the mainframe Kermit starts to run.
  185.  
  186.      (The official Kermit jargon for the two ends of the Kermit-Kermit
  187. link-up is that the one running in the micro, to which you talk 
  188. directly, is the "local" Kermit; the one on the mainframe is a
  189. "remote" Kermit.  This is fine until you connect two micro-Kermits,
  190. at which point you really have two locals.  However, everything still
  191. works O.K.)
  192.  
  193.  
  194.  
  195. 5.  Micro-Micro Transfers.
  196.     ----------------------
  197.  
  198.      Unless you are using two RML micros, you will need to get the
  199. instructions for the other micro's Kermit and talk to it in the way
  200. it understands.  The details of the instructions below apply only
  201. to RM (480Z and Nimbus) Kermits.
  202.  
  203.      Once you have tested out the micro-micro link in connect-mode,
  204. you can arrange for files to be transferred.  Obviously, one Kermit
  205. has to send and the other to receive.  In general you have to tell
  206. each micro what to do from its own keyboard; things tend to work
  207. better if you set the receiving end going first.
  208.  
  209.      To prepare RM Kermit to receive files, use "F4 k" to get back to the
  210. main menu and select the option "Receiving Files".  Hit RETURN/ENTER, and
  211. you will be asked whether you wish to have them stored under their own names.
  212. Usually this is so, and all you need do is hit RETURN/ENTER again.  If however
  213. you know that the names which the other Kermit will send are for some
  214. reason unsuitable, you can enter one or more replacement names (separated
  215. by spaces).  End the list with RETURN/ENTER and Kermit will start
  216. listening for the other end to get going.  It will receive as many
  217. files in one go as the other Kermit cares to send.
  218.  
  219.      To prepare RM Kermit to send files, select the main-menu item
  220. "Sending Files".  You will be asked to enter a list of filenames.
  221. Type these in (in either capitals or lower-case), separating the names
  222. by spaces and ending with RETURN/ENTER.  You can use the "wildcard"
  223. characters "?" and "*" to get Kermit to look on the disk and see what
  224. files there are to send (in which case it will tell you what it found).
  225. Up to 8 files can be sent in one go (but not more than one lot of
  226. wildcards or 80 characters on the whole line).  The files are kept
  227. separate, and will end up at the receiving end as separate files
  228. under their own names (or reasonable derivatives thereof).
  229.  
  230.      Once both ends are going, they will get in touch with each other,
  231. exchange some housekeeping information and the filenames, and then
  232. transfer the file(s).  RM Kermit will show a dot on the screen for each
  233. good block of data transferred (about 90 characters), and will also
  234. display the letters D, T, C and N to indicate various sorts of trouble.
  235. Kermit knows how to recover from problems in the communications, so
  236. provided there are only a small scattering of alphabetics mixed with the
  237. dots, you have nothing to worry about.  If there are a very large
  238. proportion of error-letters, the connection must be very bad and it
  239. is probably wise to kill the transfer, disconnect, and start again
  240. from the beginning.
  241.  
  242.      When a transfer is in progress, the name of the file being
  243. transferred is shown on line 3 of the screen, and some counts of
  244. activity so far on lines 3 & 4.  Messages are also displayed on the lower
  245. part of the screen as each significant event takes place.
  246.  
  247.      If the message "trying..." is repeated again and again, or if instead
  248. of dots only T's are displayed, it means that your local 
  249. Kermit cannot get in touch with the other one.  Go back to connect-mode,
  250. make sure the other Kermit has not collapsed and start again.
  251.  
  252.  
  253.  
  254. 6.  Transfers with a Mainframe Server.
  255.     ----------------------------------
  256.  
  257.      If the remote mainframe Kermit has a server-mode (sometimes called
  258. automatic), then there is no need to talk to it in connect-mode once
  259. you have got it started.  Get out of connect-mode on your local RM Kermit
  260. by "F4 K" and select "Commands to Server" from the main menu.  As soon
  261. as you enter this mode, you will have the command menu displayed.  The
  262. important items here are "Get Files" and "Sending Files".  Select
  263. whichever of these is appropriate.
  264.  
  265.      "Get Files" requests you to type in a list of filenames which you
  266. want the mainframe to send you.  This has to be typed in exactly as you
  267. would have done to any other program RUNNING ON THE MAINFRAME.  The list
  268. will be sent to the other end exactly as you type it.  Whether you can
  269. use wildcards, whether you should use upper or lower case etc. depends
  270. entirely on the mainframe's habits.  End the list wih RETURN/ENTER and
  271. the two Kermits will sort matters out between them.  Before the files
  272. are actually received you will have the same query "Store under own
  273. names - Yes?" which was noted above, and it must be answered in the
  274. same way.
  275.  
  276.      "Sending Files" works in apparently the same way as the sending
  277. process described between two micros.
  278.  
  279.      The actual transfer proceeds just as it did between two micros.
  280.  
  281.      At the end of a transfer, you will be asked to enter any character
  282. before Kermit returns you to the command menu.  The pause is to allow
  283. you to read the various messages before the menu wipes them out.
  284.  
  285.  
  286.  
  287. 7.  Transfers with a Simple Mainframe Kermit.
  288.     -----------------------------------------
  289.  
  290.      If the mainframe Kermit does not have server abilities, you must use
  291. it in simple mode.  This is just like the micro-micro transfer except that
  292. you work with RM Kermit in connect-mode as a terminal of the mainframe
  293. until you have finished telling the mainframe Kermit what you want it
  294. to do (i.e. send files or receive files).  When you have achieved this,
  295. the mainframe Kermit will switch into "send" or "receive" mode and probably
  296. put some strange characters on your screen; this is it prodding your local
  297. Kermit to see if it is yet ready.  You should enter "F4 K" to get back to
  298. the main menu, then select "Sending Files" or "Receiving Files" as
  299. appropriate, then carry on as between micros.  (It goes without saying
  300. that if the mainframe is set to receive, the micro must send, and vice versa.
  301. Both sending or both receiving may lead to an error or just to an unlimited
  302. sequence of "trying..." messages ot T's, or to nothing.)
  303.  
  304.      At the end of a transfer with a simple mainframe Kermit, you are again
  305. given a chance to read the completion messages before being returned to the
  306. main menu.
  307.  
  308.  
  309.  
  310. 8.  Errors and General Snafus.
  311.     --------------------------
  312.  
  313.      Provided that the two Kermits can talk to each other, they will
  314. start to transfer the file.  However, things can go wrong.  The sender
  315. will have made sure the first file exists before starting, but one of
  316. the others in its list could be missing; or the receiver may be unable
  317. to store the file; or there may be disk errors.  In any of these cases,
  318. one end or the other may decide that it can no longer carry on.  It will
  319. then try to send an error-message to the other end before collapsing
  320. gracefully.  RM Kermit will display any such error-message that it
  321. either sends or receives before going back to one of the menus.
  322.  
  323.      If the transfer which collapsed was a file-receive, RM Kermit will
  324. close the file normally and leave it on the disk in its incomplete state.
  325. Not all Kermits behave this way; some will remove the partial file, and
  326. others have parameter-settings which allow the user to decide in advance
  327. what should be done.
  328.  
  329.      You can force a transfer to be aborted by hitting F4 or ESC and
  330. then A.  Kermit will query you to make sure that you really wish to abort
  331. the transfer; if you answer Y or just hit RETURN/ENTER, it will be aborted;
  332. hitting anything else will allow it to carry on.  Similarly hitting CTRL-C
  333. at any time will give you a chance to cancel either the transfer or
  334. the whole Kermit program (after giving confirmation).
  335.  
  336.      It is always possible for a communications-line to collapse,
  337. particularly across a network.  If this happens, Kermit will try 10
  338. times to send or acknowledge the last block of data, at intervals of
  339. about 10 seconds, displaying a "T" on the screen each time.  Eventually
  340. it will abort (as explained above).  To cut this process short you can
  341. enter "ESC A", just as though you were killing a transfer which was
  342. proceeding normally.
  343.  
  344.  
  345.  
  346. 9.  Disks and Names.
  347.     ----------------
  348.  
  349.      Filesystems on different micros and mainframes have very different
  350. ideas about what files should be called and where to put or look for them.
  351. Kermit in general ignores all parts of a filename except its principal
  352. name, which is usually the last part of the complete name; and
  353. converts this to upper-case letters.  (E.g. a file
  354. in unix might have a full name "/44d/staff/cjk/documents/blurb", Kermit
  355. would send this under the name "BLURB"; an MSDOS file might be 
  356. "B:DEMO\DUCKS.BAS", which Kermit would send as "DUCKS.BAS".)
  357. This means that the CP/M disk-letter and user-number and the 
  358. MSDOS disk-letter and path do not get included in the names of
  359. files received.  You have to set these up before starting the
  360. transfer.   They can be set before loading Kermit in the micro, 
  361. or in the Kermit disk-maintenance mode (described in RMKINFO.DOC).
  362. A special case is that, when receiving, you can enter a disk-letter
  363. (complete with its trailing semicolon) in reply to the query
  364. "Store under own names - Yes?".  If you do this, all files in the
  365. current batch will be stored on that disk but with the names which
  366. were sent with them.
  367.  
  368.      Names can come in from mainframe Kermits which have odd characters
  369. in them.  To prevent trouble on the disks, RM Kermit checks all
  370. incoming names to make sure that they are in CP/M or MSDOS format
  371. and consist only of alphanumerics, "$" and the single dot which separates
  372. the two parts of the name.  Filenames which break these rules are altered
  373. so that they conform.  When a file starts to come in, Kermit tells
  374. you both the name sent with it and the name under which it is
  375. being stored.
  376.  
  377.      It is a nuisance if an incoming file overwrites one on the disk
  378. with the same name but different contents.  RM Kermit therefore checks to
  379. see if the name duplicates one already on disk.  If it does, then
  380. Kermit changes the name of the new file before storing it.  The details
  381. of this are reported to you as they happen.  (You can change the way
  382. this works by altering the parameter "File Collision".)
  383.  
  384.  
  385.  
  386. 10.  Binary Files.
  387.      -------------
  388.  
  389.      The majority of files transferred by Kermit are of text, so it is
  390. set up by default to handle such files.  This is controlled by the
  391. parameter "8th-bit mode", where the setting "7-bit stripped" is
  392. right for text files.
  393.  
  394.      If you want to transfer binary files (ones in which the bytes
  395. may have any value from 0 to 255), this can be done in two ways.
  396. The better way is to use setting "8-bit prefixed"; this is certain
  397. to result in a good transfer if the other Kermit agrees to do it.
  398. Unfortunately not all Kermits can handle this part of the protocol;
  399. if the mainframe Kermit does not agree to use prefixed mode, you
  400. will get a warning message and should assume that the transfer
  401. will probably produce garbage.  An alternative is to use "8-bit image".
  402. This assumes that 8-bit characters (values 128-255) will be received
  403. correctly as sent, a reasonable assumption over a piece of wire
  404. between two micros but very uncertain over complicated connections.
  405. The drawback is that if the 8-bit characters are received wrong,
  406. this may not be detected.  Some experimentation is called for.
  407. In any case, it is likely that both Kermits will have to be informed
  408. separately that image-mode is to be used; prefixed-mode is sorted out
  409. automatically between the Kermits.
  410.  
  411.  
  412.  
  413. 11.  Other Facilities.
  414.      -----------------
  415.  
  416.      There are a number of other parameters on the parameter menu,
  417. modes on the main menu and possible server commands in the command menu.
  418. Some of these are fairly obvious.  All are described, at least briefly,
  419. in RMKINFO.DOC.
  420.  
  421.  
  422.     *********************************************************
  423.