home *** CD-ROM | disk | FTP | other *** search
/ RBBS in a Box Volume 1 #2 / RBBS_vol1_no2.iso / 001g / comm.hlp < prev    next >
Text File  |  1988-09-03  |  26KB  |  493 lines

  1.  
  2.  
  3. ... In the vernacular of the communications industry, there are a few
  4. concepts that need to be understood before understanding 'HOW' is
  5. accomplished.  For example, the word BAUD.  This essentially
  6. means 'bits per second'.  In fact, it means something a little
  7. different than that, but for openers, let's say that's what it
  8. means. 
  9.  
  10. Now, whenever two machines are going to try to communicate with
  11. each other a couple of things have to be done by both.  They must
  12. both be set to send and receive at the same frequencies, for
  13. example.  The most often used frequency, today, is 1200 baud.
  14. That means 1200 bits per second, as I said before.  Well, most
  15. users have no idea what bits are involved in a file transfer or a
  16. message transfer.  Let's look at another standard word: BYTE. 
  17. There are 8 bits of information contained in a byte.  That is, a
  18. byte is merely a set of 8 bits.  Within a set of 8 bits there are
  19. 256 permutations available.  From all zeroes to all ones.  Each
  20. letter in the alphabet and each digit and each other special
  21. character is represented by a predetermined set pattern of
  22. those 8 bits.  A capital 'J' has a different pattern than a lower
  23.  
  24. case 'j', for example.  Given that that is true, it is easy to see
  25. that no more than 128 of the total possible patterns would be
  26. necessary to represent any text.  Thus, we have another 128 that
  27. may be used for 'special purposes'.  What, for example?  I'll get
  28. to that. 
  29.  
  30. The sending of bits (on or off, high or low, in other words
  31. binary information) is, by definition, a binary process.  That is,
  32. the computers need only recognize one of two states.  The
  33. telephone, on the other hand, carries information that is other
  34. than binary.  It can faithfully represent different tones, pitch,
  35. and volume.  This is called analog rather than binary.  The
  36. almost sole purpose of a modem is to translate binary signals
  37. into analog and vice versa.  When you  are going to send a set of
  38. bits across a telephone you will have to convert those binary
  39. 'states' into some form of sound (which is, after all, what the
  40. telphone is designed to best carry).  Modulating a signal from
  41. binary to analog is the 'Mo' in Modem. 
  42. Demodulating an analog signal back into binary is the reverse and
  43. is the 'Dem" in Modem. 
  44.  
  45. If we want the transmission to be highly reliable then we must do
  46. more than simply send the binary information (modulated).  We have
  47. all heard 'noise' on a telephone line and without doing more than
  48. demodulating into bits, the receiver will no doubt have a
  49. virtually impossible time of being able to tell what sounds are
  50. bits or just plain noise.  In some applications, we don't really
  51. care all that much.  Examples include the transmission of plain
  52. text files.  Recall that all that was necessary to send any
  53. letter, many special symbols and any digit was a capability that
  54. required no more than 128 different combinations of bits.  7 bits
  55. are sufficient to represent 128 permutations of those bits.  That
  56. is, if a byte were only 7 bits long then it could contain as many
  57. as 128 different sets of bits being on or off).  However, a byte
  58. is 8 bits long by definition.  So, in what is called ASCII
  59. (American Standard Code for Information Interchange)
  60. transmissions we can use the first 7 of those bits to represent
  61. data and the 8th bit to represent some form of insurance or
  62. integrity check that the first 7 were received as they were sent.
  63.  
  64. This is called using 'PARITY'.  You can establish a convention
  65. between the sender and the receiver that every byte WILL have an
  66. even number of bits (or odd) and use the 8th bit to do so at the
  67. sending end.  If the receiving end ever gets a byte that has odd
  68. parity then it knows that it received the byte in error (some bit
  69. or bits were either added or lost).  That is all there is to
  70. parity checking in an ASCII transmission.  Not at all very good,
  71. but sufficient for most text. 
  72.  
  73. Program files or data files or even text files that have been
  74. compressed (ARChived) in some way use all 8 bits in every byte to
  75. represent information.  So, we have lost the ability to use
  76. parity as an integrity check vehicle.  Instead, in every protocol
  77. other than ASCII we add either one or two full bytes to the end
  78. of a 'block' of bytes.  The block is a fixed length (usually 128
  79. bytes).  The purpose of those one or two bytes is to contain what
  80. is called a Cyclic Redundance Check (CRC) character or word.
  81. Like parity, the CRC is constructed at the sending end to create
  82. a pattern of bits that demonstrates that the preceeding entire
  83. block of bytes has been received with integrity.  The Receiving
  84. end dynamically creates its own CRC from the information received
  85. and compares it to the byte or bytes received at the end of a
  86. block.  If it doesn't match then the block must be rebroadcast (requested
  87. by sending to the sender a signal that says: "Negative Acknowledge" -
  88. NAK.  If it was ok then it sends an ACK - meaning "Acknowledge", and the
  89. next block is sent. 
  90.  
  91. Now, let's go back to the idea of baud.  At 1200 baud, the modems
  92. are able to send and receive 1,200 bits per second.  How many bits
  93. per byte? Yes, 8, but not on a telephone line if you are using
  94. modems!  Instead, we bracket a byte by sending what is called a
  95. start bit before the 8 bits of data and ending with what we call
  96. a stop bit (sometimes 2 - at 300 baud).  So, every byte requires
  97. 10 bits, not 8.  Thus, at 1200 baud your maximum possible data
  98. transfer rate is 120 characters (bytes) per second! 
  99.  
  100. OK.  Now we know what we have to send and how many bits are
  101. required and that there is something called a response from the
  102. receiver called either an ACK or NAK.  So why don't we get 120
  103. bytes per second transfers using 1200 baud modems?  Well, we
  104. already saw that for every 128 bytes of data, in most protocols,
  105. we send an additional one or two bytes of CRC.  We DO NOT count
  106. the CRC byte(s) as data!  Yet it takes time to transmit.  Also,
  107. it takes time for most protocols to turnaround and react to the
  108. ACK or NAK.  For example, assuming all is well, the sender  has a
  109. few hundred blocks to upload to the receiver.  After the first
  110. block is sent he, by convention, must wait for the receiver to
  111. analyse the CRC and decide if it is going to respond with the ACK
  112. or a NAK.  Then it takes a moment to send that to the sender who,
  113. in turn, has to receive it, verify that it got here properly (was
  114. not just noise) and decide whether to send the next block or to
  115. resend to last one that was improperly received by the receiver. 
  116. That takes time.  All time used as described above is called
  117. 'overhead'.  Overhead does not include the transmission of DATA,
  118. only control bits and time.  Thus, it is impossible to get to an
  119. effective DATA transmission rate of even 118 characters per
  120. second let alone 120 (CRC, etc).  But, we know that the telephone
  121. is capable of carrying sound in both directions simultaneously. 
  122. So, why should the sender have to wait for the receivers ACK or
  123. NAK?  This mode of operation is often called 1/2 duplex, by the
  124. way.
  125.  
  126. The answer, of course, is that it does so only by convention. 
  127. Newer protocols do not wait.  They assume that a transmission
  128. will be successful and will result in getting an ACK.  So they go
  129. immediately to the task of sending the next block.  Always
  130. listening, of course, for that ACK or NAK.  When it is received
  131. as an ACK all is well and we have gained performance.  If not,
  132. the software has to decide which block or blocks have to be
  133. rebroadcast.  In order to do that it should be obvious that the
  134. ACK or NAK is not simply a single byte.  Rather, it includes a
  135. byte that is called the packet number (0 to 255), and possibly
  136. more information.  If an ACK is received the recipient knows
  137. which of a series of blocks(packets) it is referring to. 
  138. Similarly it would know with an NAK.  Yep, more bits and more
  139. overhead! 
  140.  
  141. Well, then let's see if I can get to a few more contemporary
  142. terms and information more practical to know at this time. 
  143.  
  144. For example, almost nobody uses ASCII transfers any more.  Why
  145. should they when they are so poorly controlled and when you
  146. realize that ONLY un-compressed raw text can be sent with it?
  147. Still, a great many first time communications users try to do so.
  148.  
  149. And, while the transmissions will appear to work, the resulting
  150. files will be garbage, of course.  Only 7 oF the 8 bits are being
  151. transmitted in each byte!  Many comm programs will allow you to
  152. use ASCII even when they should know that the result will be
  153. unsatisfactory.  For example, if a filename ends with COM or EXE
  154. then, again by convention, that file is an executable program. 
  155. ALL such programs use 8 bits in every byte and could not,
  156. therefore, be transmitted via ASCII.  Some comm programs will not
  157. let you try to do something that stupid (only, of course, to a
  158. knowledgeable user). 
  159.  
  160. What are the protocols that currently exist in wide spread usage
  161. across the country?  The most frequently seen is called XMODEM. 
  162. This protocol is quite reliable (about 96%) and uses blocks of
  163. 128 bytes plus one CRC character at the end of every block.  It
  164. is because it uses only one CRC character that the reliability is
  165. only 96%. 
  166.  
  167. Another is called XMODEM/CRC.  This is exactly the same as XMODEM
  168. but it uses two CRC characters.  The result is that the effective
  169. performance is reduced insignificantly (1/130th), but the
  170. reliability is increased to about 99.6%.  In any case where you
  171. have a choice between the two you would, of course, opt for
  172. XMODEM/CRC. 
  173.  
  174. Then, and this is particulary true in environments where one of
  175. the computers being involved is either a mini or a mainframe,
  176. there is a protocol which is called Kermit.  I believe it uses
  177. 128 byte blocks and other overhead such as a 'header block -
  178. block zero' that provides control information.  It is also very
  179. reliable (99.6% I believe) but it is SLOW!!!  It is used only if
  180. that is the only protocol available. 
  181.  
  182. Then there is what is called YMODEM.  This protocol differs from
  183. the earlier ones in that it sends 8 - 128 byte blocks together as
  184. a 'super block' before it sends the two byte CRC word.  As a
  185. result it is the fastest protocol that I have ever seen for micro
  186. computers that use 'dumb' modems (ie, non self correcting ones). 
  187. There are two times when one should not use this protocol if
  188. there is a choice: 1) when the line noise is great on the
  189. telephone (for a retransmission of a 'block' that failed involves
  190. 1024+2 bytes even if only one bit was gained or lost).  That is a
  191. lot of overhead!  And 2), in an environment like PC-PURSUIT that
  192. involves long duration hand shaking turnaround delays. 
  193.  
  194. Another protocol is called Telink.  Telink uses 128 byte blocks
  195. but has an advantage over the other ones.  It results in a file
  196. that is exactly the same size and has the same date and time
  197. stamp on it as the one being sent.  Ymodem, for example, adds to
  198. (pads) a block until it is exactly 1024 bytes (the last record)
  199. even if that record only contains a few bytes of data. 
  200.  
  201. GT PowerComm has a unique protocol called 1kTelink.  It is the
  202. same as Telink except it uses 1024 byte blocks and is therefore
  203. more efficient.  Like YMODEM, 1kTelink should only be used on
  204. clean phone lines for performance, but unlike YMODEM it can be
  205. used on even a short file with efficiency. 
  206.  
  207. In the case of GT, and then only if communicating GT to GT, if
  208. either YMODEM or 1kTelink experience a set of 6 errors during the
  209. transmission of a single file then it will automatically fallback
  210. to 128 byte blocks to greatly increase the odds that the
  211. transmission can be completed and to greatly increase the
  212. efficiency on what is presumed to be a noisy line!!!  Neat!!!
  213.  
  214. The BEST protocol at this time for use in a PC-PURSUIT environment
  215. is called Wxmodem which stands for 'Windowing Xmodem'.  This uses 128
  216. byte blocks but it does not wait between blocks for a response.  It is
  217. always listening for those ACKs and NAKs, of course.  Extremely high
  218. performance is the result, relative to Xmodem or the other 1/2 duplex
  219. protocols.  Wxmodem tries to stay 4 blocks ahead of the receiver at all
  220. times while the receiver tries to get 'caught up'.  The difference
  221. between the block being sent and the most currently received ACK or NAK
  222. is called the window (a number between 1 and 4).
  223.  
  224. Then there are two more odd protocols that have become relatively
  225. visible of late.  These are called ZMODEM and Batch-YAM.  ZMODEM
  226. was designed for use in a PC-PURSUIT like environment.  Like
  227. WXMODEM, the best protocol for use in that environment, ZMODEM
  228. does not wait for ACKs and NAKs.  Unlike WXMODEM, ZMODEM is
  229. relatively slow.  For one reason, it uses no buffering.  Thus
  230. every 512 bytes of data it must make another disk access. 
  231. Batch-YAM is much like YMODEM except that it allows you to specify a
  232. set of file names (a 'batch' of them).  It is slower than YMODEM
  233. except, possibly on PC-PURSUIT. 
  234.  
  235. What must a user know to do a file transfer?  What protocol is
  236. available on BOTH ends of the transmission, the file name of the
  237. file on his end and the file name on the other end.  That is, if
  238. the receiveing end of a transmission already has a file with the
  239. name of the file you want to send to it, naturally you will call
  240. the new file something else.  Thus, every comm program allows the
  241. specification of the file name on your end and then the name on
  242. the other end.  (It is not just an irritant that you 'already'
  243. typed that in, it is necessary).  Having said that I must make an 
  244. exception  - Telink  and 1kTelink.   These protocols allow batch
  245. names,  like Batch-YAM,  but the receiving end and transmitting end
  246. file names are the same.
  247.  
  248. That's it for now. 
  249.  
  250. Wood: I have a few questions. ok? 
  251.  
  252. Davis: Sure. 
  253.  
  254. Wood: Four to be exact.  
  255.  
  256. 1- You mention date/time stamp on one of your protocol
  257. descriptions but did not define its use prior to that.  What is
  258. this and what is it used for?
  259.  
  260. PC-DOS or MS-DOS marks every file with the date and time that
  261. file was created or last modified.  So, let's say I want to send
  262. you a copy of my transmission log that was dated 12/31/86 (by
  263. DOS).  If I use any protocol other that Telink the resulting file
  264. on your end will be dated with the date and time it was created
  265. (ON YOUR SYSTEM!)  Today, now.  Telink creates that file and
  266. leaves it on your system with my date and time stamp still
  267. intact.
  268.  
  269. When I receive an ARCed file this time/date stamp is in the EXE
  270. module somewhere? 
  271.  
  272. Davis: It is several places in that example.  In the directory record on
  273. your disk is the formal residence of the stamp.  So, in the case
  274. of an ARC file, it has a date and time stamp.  Additionally,
  275. within the ARC file each record, which is merely another way of
  276. saying 'each file within the ARC file', has the date and time
  277. that THAT file had in its directory record BEFORE it had been
  278. ARCed into the ARC file.  When you unARC, the resulting file will
  279. not have todays date and time as a stamp but the one recorded
  280. within the ARC file for it. 
  281.  
  282.  
  283. Wood: Good, I understand perfectly.  I can relate it to what we
  284. sometimes do on the mainframe. 
  285.  
  286.  
  287. 2-You mentioned padding with YMODEM.  What is this?  Does the
  288. receiving end recognize the padding and discard it automatically?
  289.  
  290. Davis: Let's say the file you want to send is exactly 1025 bytes long. 
  291. Each block transmitted by YMODEM contains 1024 bytes of date plus
  292. 2 bytes of CRC.  It will, therefore, take two blocks to send that
  293. file.  The second block will contain only 1 byte of data plus
  294. 1023 padded "blanks" - actually End Of File marks.  YMODEM sends
  295. 1024 bytes every time!.  The receiver does not automatically
  296. strip those padded bytes.  Indeed, it passes them to the
  297. resulting file so that it will always be an even multiple of the
  298. 1024.  Thus, you sent a 1025 byte file and it becomes a 2048 byte
  299. file!! 
  300.  
  301.  
  302. Wood: Ok--3...You came to a conclusion without what I thought was the
  303. necessary support when you said "...thus 512 bytes result in a
  304. disk access with ZMODEM..."  I did not follow the conclusion.
  305. Help! 
  306.  
  307. Davis: Sure.  As we discussed before the tutorial when we talked about
  308. buffers, a buffer is a fixed length (amount) of memory,
  309. sufficient to contain some number of blocks of data.  In the case
  310. of ZMODEM, a block is 256 bytes, by the way.  If the protocol
  311. used buffers there could be some large multiple of 'blocks' in
  312. memory awaiting transmission.  Instead,  ZMODEM does not use a
  313. buffer.  Thus, it must have in memory only one sector of data at
  314. a time.  In the PC world, a sector is 512 bytes, or two blocks of
  315. data as far as ZMODEM is concerned.  Again, since that is the
  316. case, after two blocks (512 bytes), ZMODEM must go back to the
  317. disk to get more data to transmit. 
  318.  
  319. Wood: One of the first things we learned in programming school 20+
  320. years ago was that you could do things a lot faster with more
  321. than one buffer.  WE typically (or the system) use at least two.
  322.  
  323. Why would ZMODEM not use any?  Is there a memory problem? 
  324.  
  325. Davis: I can't speak for the authors of ZMODEM but I will say that it is
  326. typically not a protocol that is written into a program like GT
  327. PowerComm (As is Xmodem or Wxmodem, etc.).  Instead, it comes
  328. rather conveniently in the form of an EXE program that can be run
  329. independantly of the comm package or by a simple shell out of the
  330. comm package to it.  In the latter case, there is no way to know
  331. how much memory might be available in the majority of systems. 
  332. The program itself, could, of course, simply find out.  But you
  333. will recall that BOTH ends of a transmission are highly dependant
  334. upon compatible software.  It might be that the author of ZMODEM
  335. simply took the easy way out.  I don't know. 
  336.  
  337.  
  338. Wood: This leads nicely into my final question which deals with today's
  339. comm packages.  When I first bought my PC I did the necessary
  340. research by reading reviews and magazines like Software Digest. 
  341. I rejected XTALK and settled on HYPERACCESS.  After I started
  342. using it I discovered Shareware.  I have come to the conclusion
  343. that there are two classes of products in the Micro world today. 
  344. Commercially developed and other.  My company uses XTALK.  In the
  345. corporate environment you order a comm package and you get what
  346. the corporate gurus decide is best for you.   
  347. I like ProCommm.  I do not like to feel that I was ripped off by
  348. buying HyperAccess.  I just feel that I was uninformed at the
  349. time.  In this area ProComm seems to reign as King with the
  350. majority of PC users.  
  351.  
  352. 4- What are the advantages of GT over ProComm? 
  353.  
  354. Davis: Excellent question.  Let me try to deal with it professionally
  355. instead of from the bias I would naturally have for GT PowerComm.
  356.  
  357. (When I wrote the documentation for GT I twice called it ProComm
  358. - how embarrassing it would have been if I had released it
  359. without an edit). 
  360.  
  361. Let's go back a little in time.  Before the era of the PC
  362. virtually all micro computers were 8 bit in design rather than
  363. 16.  At that time the undisputed King in the area of comm
  364. packages was Crosstalk.  It enjoyed an excellent reputation and
  365. was well supported.  Further, it was not terribly expensive and
  366. it was one of the only comm packages that supported what was to
  367. become a whole set of protocol transfer methods (it was an XMODEM
  368. protocol).  Well, in those days if your comm package didn't work
  369. reliably and you were not sure if it was a hardware problem or a
  370. software problem you simply put up Crosstalk.  If it worked the
  371. conclusion was that the problem was software.  It was THAT
  372. reliable. 
  373.  
  374. Along came the PC's.  Crosstalk was ported to the 16 bit world,
  375. but in a way that made very little progress in terms of adapting
  376. to the capabilities of the PC's.  To this very day, I believe it
  377. is impossible to change directories in Crosstalk, though I could
  378. be wrong.  In essence, Crosstalk continues to be available and
  379. though it runs reliably in a 16 bit environment it runs like it
  380. was in a CP/M environment, not a DOS one. 
  381.  
  382. Then there was a leading contender from the shareware world
  383. called QMODEM.  It enjoyed an excellent following and was
  384. remarkably efficient by comparison to Crosstalk - MUCH faster, in
  385. fact.  And, it had a couple of contemporary protocols not
  386. available in Crosstalk.  It took off and has been a very
  387. successful product ever since. It is a great program.  While Procomm
  388. and others gained ground on Qmodem, it consistently comes roaring
  389. back with more features and innovations than the others.
  390.  
  391. About the same time the Hayes Modem manufacturers
  392. introduced SmartComm II as a commercial product and it was being
  393. shipped with many of their modems.  By brand identification it
  394. was accepted.  This, despite that it is the clumsiest of all the comm
  395. packages I have ever seen.  It was, furthermore, not very
  396. efficient by comparison to QMODEM.  It has essentially been
  397. unchanged since its introduction (Sound like Crosstalk all over
  398. again?) 
  399.  
  400. A new comm package hit the scene called ProComm.  In this program
  401. the author spent a great deal of attention to 'image'.  He used
  402. imaginative ideas like a whistle that announced opening and
  403. closing of windows, the windows themselves were innovative, etc. 
  404. It was no where near as efficient as QMODEM, but it captured the
  405. imagination of the users.  And, like QMODEM, the price was right
  406. - $0 to try it out, and then if you decided to, you sent them a
  407. small check - but that's shareware. 
  408.  
  409. Procomm has advanced far faster than QMODEM in terms of
  410. incorporating different protocols and the incorporation of what
  411. is called a Host mode, or unattended mode of operation
  412. (autoanswer of modem, etc.)  It became King as you call it by
  413. being both innovative and current - but not by being efficient,
  414. though it is quite respectable. 
  415.  
  416. GT PowerComm was only formally announced to the shareware world
  417. on the 21st of last month!!!(2/21/87).  It includes 8 protocols, not
  418. including the also present ASCII, of course.  At 2400 baud, I
  419. routinely establish DATA transfer rates of 235.5 characters per
  420. second with it, while the best I ever got with Qmodem was about
  421. 220 and with Procomm about 218.  Actually, I did get a 225 once
  422. with Qmodem, but only once. 
  423.  
  424. So, in terms of performance, nothing has come close to being as
  425. fast as GT PowerComm.  But that, as we saw with Procomm, is not
  426. all that the user is looking for.  We have incorporated an
  427. extremely rich function called the LOG.  Into that log is
  428. recorded all connects, disconnects, messges to the host,
  429. passwords used to gain access, bad passwords tried, and even more
  430. interesting, the names and time to trasmit every file that goes
  431. from the GT to or from another computer, and along with that is
  432. the total byes involved and the name of the protocol used in the
  433. transmission and, finally, manually created notes and messages. 
  434. So what, you might ask.  I would answer that if you were the Sysop
  435. of a board, or of a Corporate system, you MUST be able to
  436. determine who sent you a file or a messgage and when.  (Yes, date
  437. and time stamps are included in all entries in the log).  For
  438. example, what would be your reaction if you found that  a program
  439. on your disk was a trojan horse if you could not determine where
  440. it came from?  Or, say you created a proforma for your department
  441. and it has been downloaded by 18 different executives before you
  442. discover a major error in it.  Wouldn't you want to be able to
  443. determine who has received that file?  All those kinds of
  444. questions are automaticlly answered via GT's log and GTLOG.  The
  445. main reason for feeling that there is a substantial difference
  446. between GT and Procomm for the user is in the area of SUPPORT.  I
  447. take it that it has occurred to you that I have been talking to
  448. you for more than three hours already?  And I don't even know if
  449. you are a registered user of GT.  Well, I am only one of two of
  450. us that do exactly the same thing.  The author of GT PowerComm, Paul
  451. Meiners, provides 24 hour a day access to his system as I do (as the
  452. author of the companion software).  We have provided many new
  453. versions of GT powerComm over the past year and are about to
  454. provide release 12.10 only two weeks after announcing 12.00 on
  455. the 21st!  Why, because we are constantly enhancing the products
  456. and our users want us to do so.  We have several major clients
  457. already including one of the major Oil companies, one of the
  458. major airlines and one of the countries largest school
  459. districts!!!  Finally, nobody has a better Host mode than GT
  460. PowerComm!!!  I run a BBS using nothing else.  That is power and
  461. function!  Try it, you'll love it!!
  462.  
  463. Wood: I can't wait to put the system together!  Rest assured that I
  464. will register the program.  As an ex-programmer I know what is
  465. involved.  I wish the product much luck.   Did you say 3 hours?
  466.  
  467. Davis: I believe so.  I don't remember, but I reset the 1 hour time
  468. limit I gave you twice now, possibly three times.  By the way, as
  469. a favor to me in exchange for the time, would you mind terribly
  470. ARCing your capture file and sending me a copy.  I can make it
  471. available as a tutorial to others.  And if you will make it
  472. available to others as well, it is possible that they will come
  473. to know GT PowerComm as well.
  474.  
  475. Wood: No problem.  I will not be able to do this for a couple of days
  476. however.  My modem is on the blink and I am waiting for a
  477. replacement.  I will upload GT and the Log and CTL files to all
  478. of the bulletin boards that I normally deal with.  I have already
  479. uploaded it to the corporate BBS.  I do expect to get some
  480. healthy ribbing from the ProComm lovers which is why I asked the
  481. question that I did.  For now though I would like to get the Log
  482. file.
  483.  
  484.  
  485. Davis: Thanks for the opportunity to be of help.  I too  must get to
  486. work.  So, I'll take you out of chat mode.  Don't forget to
  487. 'close' your capture file.
  488.  
  489.  
  490.                          Jim Davis' Retreat    Voice 713 558-5015
  491.                                                Data  713 497-2306
  492.  
  493.