!====================================================================! ! ! ! CCCCC TTTTTTT SSSSS AA ! ! C T S A A ! ! C T SSSSS A A ! ! C T S AAAAAA ! ! CCCCC T SSSSS A A ! ! ! ! ! ! N N EEEE W W SSSSS L EEEEE TTTTTTT TTTTTTT EEEEE RRRR ! ! NN N E W W S L E T T E R R ! ! N N N EEE W W W SSSSS L EEE T T EEE RRRR ! ! N NN E W W W W S L E T T E R R ! ! N N EEEE W W SSSSS LLLLL EEEEE T T EEEEE R R ! ! ------------------------------------------------------------------ ! ! ------------------------------------------------------------------ ! ! ! ! Volume 2 April 9, 1987 PO Box 49474 ! ! Number 8 Austin, Tx 78765 ! ! ------------------------------------------------------------------ ! ! Disclaimer: ! ! ------------------------------------------------------------------ ! ! The CENTRAL TEXAS SYSOP ASSOCIATION takes no responsibility ! ! for the contents of the articles contained here, Nor do we ! ! necessarily agree with them; everything here is subject to ! ! debate. We publish everything of interest submitted. ! ! ------------------------------------------------------------------ ! ! ! ! For further information on The CENTRAL TEXAS SYSOP ASSOCIATION ! ! or this newsletter: ! ! CALL : WRITE : ! ! CTSA HOME BBS Central Texas Sysop Association ! ! CTSA UNLIMITED P.O. Box 49474 ! ! (512) 339-7199 Austin, Texas 78765 ! ! ! !====================================================================! This Month's Features: CTSA on the GO - Gene Chesser Through the Editor's Modem - Colby Jordan File Transfer Efficiencies - Tom Scallorn GT Power Comm Host Mode - Tom Scallorn Sysops Questionnaire for Shooshan & Jackson ONA Study Conversation and How It Relates to Telecommunications What's New in RBBS Version 15.1A? -=[]=- CTSA on the GO The CTSA Unlimited Bulletin board is finally rebuilt. We will be installing new assistants sysops soon. When all areas are set we will switch it on. We still need some volunteers to man some of the areas. When the switch occurrs we will have 2 phone lines and a new Opus BBS system. Several assistant sysops will have message and file area responsibility in their areas of interest. We have a few entries for the CTSA welcome screen but many more are needed. Any entries will be appreciated as we may use some of the ideas for goodbye screens or in other areas. ANSI graphics as well as TEXT files may be submitted. Something extrodinary happened this past month. I had the opportunity to attend the BROWN SYMPOSIUM. For the past two years I have tried to express a sense of direction in the communication world. I wanted to extend the concept of adding face-to-face communication to the "MO- DEM/BBS" world. This effort has has come full circle and the benefits I have received are many. CTSA has given me a place to share these experiences. Larry Seyer, SysOp of the Recording Studio, uploaded a message to Commercial Energy BBS giving the phone number at Southwestern Univer- sity and a brief description of the Brown Symposium. The theme pre- sented was "Pandoras Box, Computers in Everyday Life". The title caught my interest and Teri, my wife and fellow SysOp, found some more information in the newspaper. The Symposium was free and open to the public. When George Brown died he set up a foundation to fund Univer- sity projects examining everyday life. All I had to do was call and register and I received a program detailing March 25th thur 27th activities. Day One came. Registratiion opened at 10:00 am and the opening re- marks were at 1:00 pm. Living in Round Rock, Georgetown was only 15 minutes away so I went early. Southwestern University is a beautiful setting. The quiet and elegance of the University seemed a strange setting for a computer symopsium. I registered, picked up my program, took a turn around the Fine Arts building, and realized I had nothing to do for almost 2 hours. I went home & studied the upcoming program. At one o'clock the auditorium was about two thirds full as Dr. Naomi Baron truly opened "Pandora's Box". The first speaker was Admiral B R Inman, recently of MCC, who gave us an hour and a half of insight into the future of computers: Optical Processing...Parellel processing... Data processing...Human Interface...Increased productivity....Explora- tion...Space...Ocean...Earth...Bio-Technology....Ethical and Religious Questions...Health....Food production...Public Jobs...National Securi- ty...SDI....Artificial Intelligence....Materials....Energy...Military. Overall Admiral Inman asked us to think broadly about computers and to open our minds to conveive the new opporturnities. A five minute break was all we were allowed and Joseph Deken, Director of Knowledge and Database Systems in the Division of Information, Robotics, and Intellient Systems at the National Science Foundation, came to the stage. Following an eloquent introduction noting his book, "The Electric Cottage", Mr. Decken massaged our minds for an hour and a half. I really didn't know what he was talking about but the words flowed like wine and amist phrases such as, "Mindstorms" "Perspective", and "Art" he explained that "returning to the vernacu- lar" meant releasing our minds to use computers to create new beauty. Three o'clock brought a short break, followed by Alan Kay, "Father of the Personal computer", current Apple Fellow, and an amazingly normal person. About 40 years old, in his Izod shirt he sauntered across the stage and talked to us as if one-on-one. Not only did he tell us about the first computers, he brought slides: the first desktop (on a strong desk), the first coffee warmer, but most importantly he showed us how early engineers thought about computers. He also got caught up with Dr. Deken's "vernacular" and while showing us where we came from, made us think about where we were going. Five o'clock was upon us and we quietly filed out of the auditorium. We had heard a lot about computers but mostly about our minds. The beauty of Southwestern University came into play as we were ushered to the atrium for punch and cookies. The group broke up quickly as ev- eryone seemed to be staring off into the sky and we left knowing our minds had been stirred a bit. A late evening lecture and music demon- strtion was scheduled but I had had too much and went home to regroup for Thursday. The next morning I missed the 9 am lecture on sports science. But settled into my third row seat around 11 for what I thought was Robotics To Come. I had my wires crossed and Artificial Intelligence was up next (not a bad mistake). Doug Lenat of MCC was a last minute substitution for Bill Turpin of Texas Insturments. It seemed like I wasn't the only one confused at this point. However, very shortly I found out Doug Lenat was a special speaker. He actually made me un- derstand what artificial intelligence meant: Paradigm Sources of Pow- er, Expert Systems, Learning Stratigies, Gathering Human Data, Langua- age Interpretaion, Large Knowledge Bases, Rules of Thumb, Breakdown Catagories, `If/Then' Rules, Additive Program Structure, Common Sense, Hard Work, Heuristic Rules, Machines Learning On Their Own, Collect Fundemental Analogies, Useful Artificial Intelligence. By 10:30 I really believed that artificial intelligence will be used and achieved in the near future. THEN ROBOTICS. Gale Slutsky from the University of Cincinnati showed us the state of the art in robotics. We watched films of Chrysler's robots making cars while we talked of science fiction and robots of the future. Truely the robots followed the artificial intelligence. Everything the robots lacked could be supplied when Doug Lenat's goals (AI) are acheived. Intelligent robots will be in our future. Art and science came quickly together with the next speaker, Dr Peter Richter, Professor of Physics at Univiversity of Bremen, West Germany. Fractals...Mathematics...Chaos...Symmetry...Simple Algorhythm...Analy- sis of types of Motion...Beauty...Art...Computer. Although confusing at times, this softspoken West German somehow connected science and art. He showed us the most beautiful pictures generated from math e- quations. In searching for physical answers a new beauty was created. I got so wrapped up in the principle that as soon as the lecture ended I zoomed in the book store and bought his $36.00 book. I was almost out of breath and pretty fired up and jumped in my truck and headed home. I didn't have to be back till 7:30 that evening to hear some guy named Issac Asimov. As I walked in the front door, there sat my 10-year-old daughter, Courtney, bored, in the living room. I thought it was time to share some of my excitment with someone. So I invited her to attend the talk that evening. She gleefully accepted. Dressed in our nicest, we headed back, discussing Pandora's Box. We settled into the third row (again) for a satellite transmission of Dr. Asimov's lecture. The noted science-fiction author of over 350 books spent an hour telling us of his futurisitc concepts of computers. He gave us reality but he made sure we were not bound by outmoded thoughts. He spoke of his "feeling robots" of the future and how we would feel about those robots. He answered questions submitted by the audience and made you feel like he was standing next to you. Somehow the satellite link and computers and science-fiction all made sense at that moment. Courtney eyes were like stars and she thought I did this all the time! We talked about computers all the way home and we decided she had to skip school and go to the symposium with me the next day. Friday - The Day. We went to a workshop on Fractals. In a group of 10 adults a 10-year-old child stuck out like a sore thumb. Michael Hart, a University of Texas graduate student, explained the concepts behind physics creating graphics. At the first break Courtney went to a computer and ran some of the programs that were discussed. Shortly thereafter Dr Richter joined the group. As the morning progressed Courtney became demonstrator and operator for Michael and Dr. Richter. She delighted in operating the machine as the workshop progressed. In a very broad sense she learned the same concepts that we did. None of us were physicists or could truely sit down and write down the pro- grams we were discussing but we could all operate a computer just like Courtney. We had a great time and Dr. Richter autographed Courtney's (now) book as we headed out to lunch. We walked about the campus, and spent the rest of the afternoon pop- ping in and out of exhibits and films. Around 4 o'clock our minds were tired. Courtney and I headed home with fractals in our minds and conversation. I had copied most of the programs presented in the workshop onto a floppie and we rushed to Courtney's computer (the one with a color monitor, of course) to experiment and revel. We began to discuss how the mind and physics and computers could be making these gorgeous pictures we were playing with. Before it was all over I had explained powers of numbers and some elementary calcu- lus to Courtney. What scared me was I think she understood it. I found my daughter and she found calculus. Pandora's Box....all the worries and evils of the world came out when Pandora opened it. But, so did a rainbow. The symposium gave me much to think about, questions to ponder, imagination to expand. What is a symposium? What is learning (Asimov)? What is Creativity? What is Art? I am not sure what CTSA is or where it's going but I'm sure enjoying the experience. Gene Chesser President - CTSA -=[]=- Through the Editor's Modem Where have all my contributors gone? Tom Scallorn was the only loyal CTSA member to contribute this month! ˙Luckily I had some other goodies to include in the April newsletter so the rest of ya'll are off the hook - until next month's deadline rolls around. ˙I ˙would like to see the May issue of the newsletter outshine all others. If we have a booth at the Computer Fair and distribute copies of the newsletter, the viewpoints of ALL CTSA members should be expressed. Once again, this is not my newsletter it is yours! ˙Though˙without participation by ˙all members it˙expresses only my thoughts˙and interests! I˙include arti- cles that˙I˙have downloaded from˙other boards and from˙on-line services but those are articles that are of interest to me (I would not spend the˙money to get˙them˙if˙they weren't!) ˙Quiet me ˙down again!! Send your contributions for the CTSA Newsletter to CP/M Lives! (512)258-8468 300/1200/2400 bps. I˙switched BBS˙software at the end of March, abandoning˙ROS after four months. I was unable to get needed support from the author and he refused to let go of his Turbo Pascal source code to allow me to custo- mize the program for my particular needs. As of March 22 I am running RBBS-PC 15.1A. I left RBBS four months ago in search of something bet- ter and now I have found it! Version 15.1A is great! A list of the new features is included in the newsletter for y'all to drool over. My one complaint - memory use. RBBS 115.1A needs 256K to run and if you use the external file transfer protocols and/or doors plan on needing at least 100K more. When a Sysop attempts to run RBBS while multi-tas- king the memory needs of RBBS leave very little for other applications. Features that I have found particularly useful are the Files Management System (FMS) and Questionnaires. Doors processing is a bit different than in the past so if you are using RBBS-14x you will have to make some changes. If you are using a Hayes 2400 modem - the auto setup for the Hayes in CONFIG did not work for me! I used the following commands: D2 V1 Q E S0=0 &C1 &S1 &J &W These are working well so far. I have not looked into the CONFIG source to see what it is sending. I have all the files for 15.1A if you would like a copy. They are on-line or I will be happy to supply them on disks, just give me a call. -=[]=- Testing Transfer Efficiencies of Various File Transfer Protocols Tom Scallorn 26 March 1987 Copyright, Tom Scallorn, 1987, rights to reproduce, granted, provided entire document is reproduced. Communications Software: GTpowerComm version 12.10 BBS Software: RBBS-PC, version 15.1a Test Software: PKarc, version PKX34A20 On 24 March 1987, I uploaded (sent) the following files to Colby Jordan, Sysop, CP/M Lives!, Austin, Texas (512)258-8468. FILENAME FILESIZE PROTOCOL ERRS EFF% CPS TSTD -------- -------- -------- ---- ----- ---- ---- GT1210-4.ARC 105472 BYTES Wxmodem 0 91.75 220 OK GT1210-3.ARC 76800 BYTES Ymodem 30 72.40 173 OK GT1210-2.ARC 131072 BYTES KERMIT * * * * GT1210-1.ARC 133120 BYTES Xmodem/CRC 1 80.86 194 OK GT1210-2.ARC 131072 BYTES Wxmodem 0 92.41 221 OK ASSUMPTIONS: All comm/bbs programs use the same formula for reporting file transfer efficiencies. COMMENTS: File transfers took place in the above sequence. All took place during the same "connect" session. The KERMIT transfer had had two, (2), N% errors prior to transferring 100807 bytes of the file; at this point it experienced ten,(10), T% errors and aborted the file transfer. Additionally GTpowerComm supports file transfer by TELINK, and 1KTELINK which were not tested because these two protocols are not supported by RBBS-PC. All percentage/time values were those reported by the GTpowerComm communications program version 12.10 tested and not by independent timers or calculations. It should be noted that both phone lines are "voice-grade", Southwestern Bell lines and that we are on separate exchanges in different switching networks. ======================================================== On 26 March 1987, I downloaded (received) the following files from Colby Jordan, Sysop, CP/M Lives!, Austin, Texas (512)258-8468. These were the same files which were uploaded on 24 March 1987, as reported above. FILENAME FILESIZE PROTOCOL ERRS EFF% CPS TSTD -------- -------- -------- ---- ----- ---- ---- GT1210-4.ARC 105600BYTES Wxmodem 20 80.88 194 ok GT1210-3.ARC 77824BYTES Ymodem 3 90.58 217 ok GT1210-2.ARC 131200BYTES KERMIT * 45.53* 109* BAD COMMENTS: The number of errors and retransmissions of "packets" because of "line-noise" prevented the completion of testing in one connect session. * The information in this area was reported, and the file transfer was labeled "successful" by the RBBS-PC program. Note however that when the file was tested it only contained about 64k of information and tested bad with PKXARC. During the file transfer 17 Q, 48 N, 6 T, and 1 E, errors were indicated on the screen. The PCKERMIT.HLP file dated Jan. 16, 1985, which is contained in the GT1210-3 file, defines these errors. Q Bad checksum or other packet error N NAK packet T Timeout E not mentioned nor defined A second call was made within approximately 10 minutes and the following information is provided. FILENAME FILESIZE PROTOCOL ERRS EFF% CPS TSTD -------- -------- -------- ---- ----- ---- ---- GT1210-2.ARC 131200BYTES KERMIT * 57.91* 138* ok GT1210-1.ARC 133248BYTES Xmodem 1 80.23 192 ok Obviously the second connection was much more reliable and less noisy! Again the (*'s) denote that the information was derived from the RBBS-PC program. During the KERMIT file transfer, 1 Q, and 2 N errors were observed on the screen. CONCLUSIONS: 1. That all comm/bbs programs do NOT use the same standard for rating file transfer efficiencies. 2. The prime cause for problems or errors in transferring files by telephone is "line-noise". This noise can come from numerous sources. The lines, switching network, and any or all other hardwire connections, including all hardware connections associated with either computer. The last of which are the responsibility of the user. 3. The most efficient protocol used for uploading files appears to be Wxmodem, while the most efficient download protocol is Ymodem. Many other factors affect file transfer efficiencies, of which the user may not be aware. i.e. The efficiency of not only the two computers at each end of the line but that of any other computer or modem which may be in the transfer line. CREDITS: GTpowerComm version 12.10 used for uploading and downloading the files may be obtained directly from the author, Paul Mieners', Programmers' Workshop, 713-772-2090. It is also obtainable from Jim's Retreat, James Davis Sysop, 713-497-2306. James Davis is the author of the excellent sysop/user utilities which are available for use with GT. The program and utility files are also available on both CP/M Lives, 512-258-8468, and Buy A boaT, 512-263- 9731. The program is User-Supported software and in my opinion well worth the $40.00 registration. RBBS-PC version 15.1a is available from Capital PC Software Exchange P.O. Box 6128 Silver Spring, MD. 20906 PKX34A20.COM is available from various BBS's and from PKWARE, Inc. 7032 Ardara Avenue Glendale, WI. 53209 CP/M Lives! is running RBBS-PC version 15.1A operating on a CompuAd XT-Turbo with some modifications. The system has 1024K RAM, two 20 meg hard disks and a Hayes 2400 Smartmodem. The operating system is MS-DOS 3.1. My thanks to Colby Jordan for his participation in this test and evaluation. My upload system is a BAB-PC (home-built pc compatible) with 512K RAM, w/Seagate 225, 20 meg hard-disk, Winchester controller, supported by US Robotics USR2400-PC internal 300/1200/2400 baud modem, using IBM-PC DOS 3.1 as my operating system. My only connection with any of the companies mentioned is that of owner or registered user of their equipment. The following trademarks, copyrights or authors are recognized: GTpowerComm (tm) P. & M. Software IBM-PC (tm) International Business Machines USR (tm) U.S. Robotics CompuAd (tm) CompuAdd Corp. Wxmodem unknown Ymodem (c) Chuck Forsberg Zmodem unknown Xmodem/CRC enhanced Xmodem protocol of original Xmodem by Ward Christensen KERMIT (c) Columbia University RBBS-PC (c) D. Thomas Mack and Jon Martin BAB-PC none assembled from commercially available hardware by Tom Scallorn. SEAGATE (tm) Seagate Mfg. PKXARC (c) PKWARE, Inc. SMARTMODEM (c) Hayes Microcomputer Products, Inc. BuyAboaT's resources and personnel are available on a contract basis for software and hardware evaluations. Please address any comments or inquiries concerning this report to: Tom Scallorn c/o BuyAboaT P.O. Box 162466 Austin, Texas 78716 Phone: 512-263-9731 BuyAboaT, RGS, data/BBS 24hrs 512-263-9732 BuyAboaT, voice/ans machine 24hrs -=[]=- A Review of GTpowerComm ver 1200, GThost. 3/16/87 GtpowerComm, from P&M Software, has had a passable Host mode for some time now. Until now it was pretty much a typical host in that it would allow someone to dial in to your computer and would provide support for downloading and uploading files with several file transfer protocols. The only thing unique was that it also supported a "call-back" mode which would allow some one to have practically free long distance access to the host system, with your approval of course. Although this was nice it did not appear to me to be any big asset to the BBS community in general. With the release of Version 1200 however I felt that a review of the Host mode was certainly appropriate. The Host mode now is what I would term a REAL Mini-BBS. It presently supports not only the files security which I felt had been lacking in previous releases but now supports a real Message base for general BBS chit-chat, additionally it supports the other features we have grown accustomed to with most BBS's. Things like Bulletins, Comments, printer support, ANSI screen support, and much more. To assist us as SYSOPS operating the GThost system as a BBS, James Davis the author of the excellent GTLOG utilities has again collaborated with Paul Meiners the author and provided another program called GTCTL. This program is a support program for handling the message base, user log, files and so forth. Again a very nice feature provided in the one package. Several individuals in the Houston area have started BBS's now using the GThost. I know of one individual in Round Rock who is in the process of setting up a system there. I have had a test system available on a request basis, in addition to my own Buy A boaT, Genesis system. I am not implying by this review that the complete program is "bug-free" or that it is so simple that a two year old can run it. It is however an excellent, total communications package. The next version which may have been released by the time you are reading this article, will contain even more. Multiple message bases, user selectable passwords, and the fixes for some known and repeatable bugs. Overall, in my opinion, this is an excellent alternative to the traditional BBS programs now out. GTpowerComm ver 1200 is User-supported software available from P & M Software Company, 9350 Country Creek #30, Houston, Texas, 77036. It is available locally on Buy A boaT, RGS, (512)-263-9731. The suggested donation is $40.00 for complete license and registration, and $10.00 for updates to previously registered users. My connection with P & M Software is that of a registered user. The system used for the evaluation of the program consisted of a BAB-PC w/512K memory, 20 meg Seagate HD w/Winchester controller, single floppy, and USR2400-PC internal modem 300/1200/2400 Baud. Tom Scallorn Buy A boaT, RGS (512)263-9731 24 hrs 300/1200, 8-N-1 Austin, Texas -=[]=- Sysops Questionnaire for Shooshan & Jackson ONA Study Introduction You ˙have ˙an opportunity to help improve the services ˙the ˙telephone company ˙provides ˙to sysops like you and to the people who ˙use ˙your BBS. In particular, we want your opinion on the ONA BSEs. What's a BSE? ˙Who cares? ˙What do BSEs and ONAs have to do with me? Please ˙read ˙on ˙a couple paragraphs and I will try to ˙make ˙it ˙all clear. Background Last June, (June 1986) the Federal Communications Commission (FCC), in its Computer Inquiry III proceeding, ˙ordered the telephone ˙companies to develop "Open Network Architecture" ˙(ONA) ˙plans which would allow for ˙the improved delivery of "Enhanced Services" ˙over the ˙telephone network. Telephone companies have to file these ONA plans by February 1988. ˙˙The FCC's order developed out of a long history which is ˙too complex ˙and detailed to recount here. ˙One way to restate what ˙they said ˙in ˙June ˙is ˙that ˙the ˙telephone ˙companies ˙should ˙take ˙any reasonable ˙steps ˙to ˙make ˙their networks ˙better ˙able ˙to ˙support information vendors on the network. ˙By enhanced service providers or information service vendors the FCC means time-sharing companies ˙such as GEnie, ˙CompuServe or the Source, value added networks (VANs) ˙such as ˙Telenet and Tymnet, ˙and a host of non-computer services ˙such ˙as telephone answering services or burglar alarm services. The FCC's order didn't refer to sysops, ˙RBBSs, ˙or FIDO nodes -- ˙but clearly these all fall into the category of enhanced service providers -- even if most of them don't charge for the service. Our ˙firm ˙was ˙hired ˙by a regional bell ˙holding ˙company ˙to ˙study enhanced service providers' needs for basic service elements (BSEs) in an open network architecture (ONA) environment. ˙We have been meeting with ˙all the major corporate enhanced service providers to understand their needs for improved network services. However, ˙˙we ˙feel that sysops have a tremendous store ˙of ˙knowledge based ˙upon their experience with the provision of data base ˙services and electronic mail over the telephone network. ˙We would like to tap into ˙that ˙resource. ˙˙Hence, ˙this questionnaire. ˙Sysops ˙and ˙the personal ˙˙computer ˙communications ˙world ˙will ˙benefit ˙from ˙˙this questionnaire ˙since they will have an opportunity for input into ˙the BSE definition process (at one regional company). If you could just edit this document -- ˙inserting your answers -- and send a plain ASCII version or a printout to me at one of the addresses below I would appreciate it. Background on Respondent (optional -- anonymous is okay -- but I can't get back to you for any clarification if your response is anonymous) Name: Address: Phone number (data): Phone number (voice): For how long have you been a sysop (years and months)? What BBS system do you operate? Computer Software How many calls a month are made to your BBS? Calls: Hours of activity: The building blocks of the ONA environment are basic service ˙elements (BSEs). ˙I ˙would like to ask you some questions about possible BSEs. These ˙have not been fully investigated for feasibility -- ˙so ˙please don't ˙regard my questions about their value as a statement about ˙the technical or economic feasibility of such BSEs. One ˙possible ˙BSE is the provision of calling ˙number ˙identification (CLI) ˙˙to the called party. ˙With CLI, ˙the telephone company ˙would signal ˙to ˙your BBS the telephone number of the calling party ˙before connecting the calling party to your machine. Would you use CLI? Without ˙regard ˙to cost, ˙on what fraction of the calls to ˙your ˙BBS would you use CLI? Would you be willing to pay two cents per call to get CLI? How would you prefer CLI be transmitted to your PC? A ˙second ˙possible ˙BSE ˙is ˙suppressed ringing ˙(though ˙it ˙may ˙be technically difficult, ˙impossible or horribly expensive on many older switches). ˙This would allow a BBS to dial-up another PC and to ˙open the connection without sending a ringing signal. Thus, you could call another ˙system at 2 a.m. ˙and download to that system without ˙waking anyone up. Would you use suppressed ringing? How many calls a month would you make using suppressed ringing? A ˙third possible BSE is "single number access" ˙which ˙would ˙provide firms ˙like ˙CompuServe and Telenet with a single seven ˙digit ˙number which would be valid over a wide area (area code region, state, etc.). Would single number access to such firms be useful to you? How would it help you? A fourth possible BSE is suppression of call waiting. In this option, call ˙waiting ˙could be turned off by dialing a specific ˙code ˙before dialing a call. Would this be useful to you? About how many calls a month would you use this feature on? Would you be willing to pay $3.00 per month for this feature? Now for the fun questions. The preceding questions have given you the basic concept of a BSE. What BSEs do you think the telephone compa- nies SHOULD offer? How much would you pay for them? Do you need them on every telephone line in your city, state, the nation or could you use them if only a few telephone lines had these features? What ˙else can telephone companies do to facilitate BBS operation ˙and the growth and health of PC communications? Please ˙feel ˙free to add any other comments you have on the ˙Computer Inquiry III/ONA/BSE definition issues. Please send completed questionnaire to me at: (US Mail) Chuck Jackson Shooshan & Jackson Inc. Suite 450, 1990 M Street, N.W. Washington, D.C. 20036 or MCI Mail CLJ or (CompuServe) Chuck Jackson [70220,271] on CompuServe or (GEnie Email) CLJ BIX AMcDonald Please forward this questionnaire to other sysops. I would prefer not to ˙see it distributed to non-sysops because they lack the ˙experience of sysops and their responses could dilute the responses from sysops. ote: ˙I ˙will prepare a summary of the responses to this questionnaire and will post that summary back into the sysop world. It should be in circulation by mid-April. Regards Chuck -=[]=- Conversation and How It Relates to Telecommunications From my own personal experience, I have seen a growing number of people becoming offended and unfriendly among the users of Bulletin Board Systems and national computer networks such as CompuServe and GEnie. Friends can too quickly become bitter enemies thanks to a message posted electronically. This article provides some interesting insights into the problem, along with steps toward a potential solution. The next time you see two people talking on the street or in a restaurant, watch them. Notice what goes on in such a conversation. You will find that they don't talk merely with words. Think about a person giving a lecture in college, or a speech at a club meeting. Again the words are only a fraction of the actual communication. How do we communicate? In the realm of speaking of any type, words are only a portion of the painting. We communicate with gestures, subtle movements of our arms and legs, facial expressions ... what has been called "body language." Through body language we can tell if the person speaking to us really believes what is being said. We can tell how devoted the speaker is to the subject material. In the case of conversation, we can tell what our partner feels about the topic of conversation, and many times about us, through these subtle keys. Tone, pitch, and volume of voice also play an important part in communication. Anger toward the listener can be expressed by an increase in volume. Fear, hatred, zealous enthusiasm ... we can tell what the speaker is feeling at the time through HOW, rather than WHAT, he is saying. Let's look now at the written word. Books and magazine articles serve a completely different purpose. Here the communication is one-way, from the writer to the reader. There is no means for an interactive discussion. Even with all that, however, the writer must make sure he communicates the underlying aspects of the subject along with the main thoughts. Unlike the spoken word, the writer has only this woefully inadequate thing we call English (or Spanish or whatever) to work with. Good authors will tell you how difficult it is to clearly express themselves using words alone. With words they must paint the picture that the spoken word, with all of its helping keys of body language and vocal inflections, naturally provides. Good writers can do this. Authors of articles in the electronic realm face the same problem as writers of printed material. Some help can come in the form of tools like editors and word processors; with these the electronic writer can look back at what he has typed, note where he is not effectively getting the point across, and make changes before the rest of the world even knows the writer is doing anything. Now we come to message bases, such as BBS's, CompuServe Forum message bases, and GEnie Roundtable bulletin boards. Here we face a subtle combination of writing and speaking. Although not as much a participation sport as regular conversation, people toss ideas about to and fro through message bases. Other people, on reading the messages, have a chance to respond. Typically there is an interaction between people that you don't find in normal writing, although not to the degree of interaction in conversation. Posting of messages, however, suffers the lack of communication that writers must face; message posters must communicate using the written word alone. Because of the popularity of message bases, relatively few of the people posting messages are professional writers. Thus, without the body language and other keys of the spoken word, the message poster is hard-pressed to communicate his or her thoughts in an unfamiliar medium; too often it works out that the person is simply speaking, but the words are recorded and transcribed in the message. Herein lies the problem. Let me give some examples of messages, and the problems they can cause. Although based on actual messages, the examples are paraphrases and conglomerations of what actually goes on in the electronic medium. First note this message: I simply cannot stand Jane. Every time I see her in one of her video parodies, I have to look away. Now, imagine you were Jane reading this. How would you take this? Would you be personally insulted by this? Would you take it as constructive criticism? Or would you take it some other way? In this case the message writer is obviously not pleased with some aspect of Jane. But is it her looks? Her costume in the video presentations? Her acting ability? Or is just an immature assault because she offended the poster? The poster is asking for a fight here. Or is he? Couldn't he be referring to some comical trait that Jane displays in many of her parodies, something so comical that the poster has to look away or die laughing? If he were chuckling when speaking this, you could tell; if he were sounding angry, you could tell. With the written word alone, though, the reader has to go on an assumption, probably that there is some offense intended. Let's look at a slightly different problem in this example: why dont we see what we can do about him i like something different Here the poster has serious trouble with the written word. The person has no idea where punctuation should go or what should be capitalized. A short message like that isn't bad on that demerit alone, but read 20 lines or more of that and you wind up with much less of a desire to continue reading anything from this person. Also, as above, the poster keeps things horrendously vague, leaving it up to the reader whether to be offended or not. I hope I've made my point in all this. Electronic communication, both through message bases and through more interactive means such as a CB simulator or conference area, has the disadvantage of limiting one to the written word alone, but promotes the interaction that the spoken word has always given us. Too many people forget this, and as a result, feelings are hurt, people are offended, and a general air of dissatisfaction begins to form. How do we solve this? The responsibility lies in part on both the writer/speaker and the reader/listener. The writer (of a message or CB line) must make sure he is saying what he means to say. The writer should read over what he just wrote to make sure it is clear. If he notices there could be something misconstrued in what he wrote, he should take the opportunity, in the case of the message base, to use the on-line editor to correct the verbiage. In the case of an interactive CB line, he should be willing to either edit the line manually or delete the line entirely. The case will arise, however, when the CB line has been transmitted, or the message posted, and later the poster notices the poor wording (or maybe a reader will notice). The poster should be ready to further explain what was intended to keep the air clear. The writer should also be conscious of standard writing etiquette, such as near-proper spelling and punctuation (nobody's perfect). The reader must also play an important part in this. As was mentioned above, there will be times when a misunderstanding will occur. A misunderstanding, literally, means that what the reader read wasn't what the writer meant to say. This doesn't necessarily mean, however, that the writer made the mistake. What you read into writing depends a lot on the reader's current mental state and attitude. If the person is, for example, angry at a parent, that person would be more likely to read anger into a message than if the reader had a good day. The reader should be willing to admit that he may have misread what was written, and be ready to ask the writer if that, indeed, was what the writer really meant. Because of the popularity of BBS's and computer networks, there will always be those who are arrogant enough to be offensive. It is rather difficult to misconstrue a line that reads, "Jane is lower than pond scum. The way she acts makes me want to puke." A suggestion in such cases is to realize that the writer has a right to know all about pond scum; typically the writer should be ignored, at least for the duration, until he/she comes to his/her senses. This may not happen, but ignoring such absurdity will, if nothing else, turn the writer away toward greener pastures. Electronic communication becomes more popular with each home computer system sold with a modem. People rejoice in the ability to communicate with others with whom they might not have any other chance to communicate. Like any new adventure, though, there are differences in traps and pitfalls. In this article I have attempted to address one of those traps, a trap that, too many times, promotes finding enemies in places where one would have no other opportunity to go, rather than finding friends in those places. Let us all be a bit more wary of the medium. (ed. I downloaded this file from GEnie. There was no author listed and therefor I can give not credit. It is well written and appropriate to our association!) -=[]=- What's New in RBBS Version 15.1A? RBBS-PC CPC15-1A will be the 28th release of RBBS-PC CPCxx since it was first published in July of 1983. RBBS-PC's policy of freely distributing the source code and continually expanding it's range of capabilities throughout these last four years represents not only the very best that is embodied in the concept of "users helping users" but an expectation of excellence that NO product in the PC industry has ever even approached. Here is a brief summary of the major enhancements in RBBS-PC CPC15-1A: o SPEED! RBBS-PC runs significantly faster. o STRUCTURE! Code has been made easier for users to modify. There is more room in the main code segment and RBBS-PC more efficiently uses string space. o MINIMUM SYSOP MAINTENANCE REQUIRED! There is a new, but optional, FILE MANAGEMENT SYSTEM (FMS) that can be set up so that the SYSOP no longer need maintain his file system "directories." User's can be allowed to automatically categorize the files they upload. The new entry will be written to the file management system and, optionally, strewn to a second file that a SYSOP might wish to edit and insert an evaluation or comments about the uploaded files. The speed of file searches has been increased from 10 to 100-fold. A caller can download in the midst of listing files, and the listing will resume where it left off after downloading is completed. o ADDITIONAL FILE TRANSFER PROTOCOLS! More error checking protocols for file exchange. Now support exists for YMODEM, WINDOWED XMODEM, YMODEMG, and IMODEM in addition to KERMIT, XMODEM (checksum) and XMODEM (CRC). o LAN ELECTRONIC MAIL! RBBS-PC can be run as a "workstation" appearing on the local PC's screen exactly as it would to a user who had dialed in as remote user. In "workstation" mode, RBBS-PC can be run on a PC without either a modem or a RS-232 interface. It can serve as an electronic mail system on a local area network in "workstation" mode (up to 36 stations) or as a teaching tool in a classroom environment to demonstrate RBBS-PC's full range of features. o ALL COMMANDS CONFIGURABLE! The symbols used for the RBBS-PC commands are configurable. Any command can be disabled. Users see only what commands they have sufficient security to execute. A SYSOP can even configure RBBS-PC so that any command can be executed from any sub-section. All of this is, as always, optional. RBBS-PC tries to strive to let each SYSOP have total autonomy (rather attempt to restrict). o MULTIPLE QUESTIONNAIRES! The new command A)nswer command allows multiple optional questionnaires to be set up that users can selectively answer. A SYSOP can put up a questionnaire at anytime that all users (both new and old) must answer. A new command has been added to the questionnaire script language that allows the SYSOP to elect to have nothing written to the script's data file. o USERS CAN VIEW ARC FILES! User's can obtain a verbose listings of the the contents of an ARCed file prior to downloading it. o TOTAL USER CONTROL OF PREFERENCES! A user can now T)oggle on or off any of his preferences. o UNIQUE USER ID'S! With RBBS-PC CPC15-1A, any field (not just the user's name) can be used to uniquely identify users. More than one user can have the same ID (everyone in a the same SIG) and still have unique names. A new field for whatever the SYSOP wants to use to identify users now exists within the USER's record. Users can be added with no pre- assigned password (i.e the first caller who uses the name is allowed to set the password). RBBS-PC can be set up so that valid accounts are pre- loaded and users can be given INSTANTANEOUS access at the discretion of the SYSOP, e.g. when the users becomes a member of a user group or SIG. o MULTIPLE UPLOADS! Just as earlier versions of RBBS-PC allowed for multiple downloads, CPC15-1A now allows multiple file names to be specified on a single command line when uploading. o BUILT-IN SUBSCRIPTION SERVICES! RBBS-PC CPC15-1A has built in support for limiting callers based on a subscription date. A subscription period can be specified for every security level, and the security a caller gets when his subscription expires is specifiable. This allows automatic support for SYSOP's who request users to purchase subscription to their boards or for time-limited privileges. Stored in each caller's record is the date the subscription began. o COMMAND-LEVEL HELP! Help files can now be specified not just by section, but by individual command, as well as a menu of SYSOP-specified special topics, such as ARC files. o MUSIC! The SYSOP can elect to have the PC running RBBS-PC to play a musical refrain each time a user selects specific functions (i.e. "Walk right in" when a new user logs on; "Dragnet" when a security violation occurs; "Goodbye Charlie" when a user logs off; "Taps" when a user is denied access; "OOM PAH PAH" when a user downloads; "Thanks for the Memories" when a user uploads). The auditory feedback enables SYSOPS to focus on other activities without having to watch the local screen. More importantly, this type of auditory feed-back is intended to aid SYSOP's who are visually impaired. o CONSTRAINTS OF EARLIER VERSIONS LIFTED! Many of the constraints that existed in versions of RBBS-PC prior to 15-1A have been lifted. some of them are: The upload directory need not be present on the same drive/subdirectory that uploaded files are written to. When the users file is full, new users need no longer be kicked off the system. Instead, they can be let on but not remembered, i.e. not be written to the user's file. On subsequent calls, they will remain new users and must re-register. RBBS-PC can be logged on to from the keyboard of the PC on which it is running (without calling through a modem) and will respond to the PC's screen in the same manner as a remote user would see it. First and last names can have interior blanks. Initial blanks are still not allowed, and trailing blanks are still ignored. The file description for uploads can be up to 46 characters long. The speed with which text files, such as menus, are displayed, can be increased by enlarging the buffer size used within 15-1A for displaying ASCII files via a parameter in CONFIG. Viewing the upload directory (or the uploads with the default category code) is controlled by the user's security level. Before, if you made the upload drive not available for downloading, only the SYSOP could view the upload directory. o BETTER ERROR TRAPPING! RBBS-PC CPC15-1A now detects and reports any problem when writing during an upload.; recovers from any problem when trying to kill a file already present before an upload; and traps all bad paths in a file name. o BETTER PROMPTS/MESSAGES! Much effort has been expended to insure that where possible prompts were clarified, messages made more meaningful, and defaults consistently shown. Some examples of this are: The "G>raphics" command was clarified. The prompt makes it clear that ASCII and color options are for IBM computers and the "help" file for the command is automatically displayed when the user is in "novice" mode. "Chat" mode now has a beginning opening and closing message. The prompt for a "P>assword" now clearly states that pressing enter quits. The "N>ulls" command now explains that it is for printing terminals. "Press [ENTER] to quit" is used more uniformly. Defaults with prompts are more uniformly indicated by putting [] around the default. The List command no longer requires that a directory be specified in advance. The list command used alone will prompt for a directory and default to the directory of directories. The editing command in messages is much easier to use. It no longer requires the user to specify new and old string together but breaks up the edit into a search for what and replace by what. The syntax from earlier versions of RBBS-PC is still supported in keeping with RBBS-PC's long-standing policy of being upward compatible. The prompt when changing page length has been clarified to indicate that the number of lines can have any value between 0 and 255. U>pload and D>ownload commands immediately respond with message "Searching for file...". In some configurations with large (and/or) slow disks a user might see a significant delay with no indication what was going on with this new response. If 1000 or more files are searched in a directory without filling the screen with "hits", the caller is asked whether he wants to continue the search. Requests for Non-stop in file searches in the L)ist and S)ubstring commands require confirmation if at least a 1000 more files remain to be searched. File searching supports true paging. No longer will the menu or multiple searches scroll away previous results. The pause properly pauses at the bottom. Callers are now informed explicitly whenever an upload or download was successful. Some novices mistakenly thought that errors during transmission mean they had to re-do the transmission. o ENHANCED SECURITY! Paths are now supported in the file security system. Kermit up/down loads no longer list drive/path where then file is located. More secure limitation of DOORS and QUESTIONNAIRES exist since RBBS-PC will no longer accept proper substrings of legitimate items. o NEW DEBUG MODE! Special debug mode has been added to allow all errors, including those that are handled within RBBS-PC, to be seen as they occur. o AUTO-NOTIFICATION! The SYSOP can elect to notify users immediately upon logging on of the number of new bulletins and new files available for downloading since the user last logged on. o TURBO-DOWNLOADING! A SYSOP can allow users to review the files that are new since the user last logged on and download them immediately (without requiring the user to see any messages). o INVALID DIRECTORIES ELIMINATED! All directories to be searched are put in one specific drive/subdirectory in order to speed up directory searches and simplify maintenance. This eliminates the possibility that data files with the same extension of true directories being considered RBBS-PC directories. o PROMPTS WIPED OFF SCREEN! "MORE" prompts are wiped away after a response, except when files to download are specified. Very useful when more interrupts continuous text, as in menu or message. o RING-NO-ANSWER MINIMIZED! As soon as carrier is lost or the SYSOP takes RBBS-PC off line via function key F1 to use the PC for other things, the phone is taken off the hook so callers will receive a busy signal (and not be charged for the call by the phone company). o AUTODOWNLOAD ENHANCED! The SYSOP can select to turn off the automatic test of every user for autodownloading. The escape sequence test for autodownloading caused problems with some communications packages and terminals. User's now can toggle autodownloading on and off during a session and their preference will be permanently remembered. o MISCELLANEOUS BUGS FIXED! While numerous bugs in 141D have been corrected, the ones that come to mind are: A TAB in messages is not allowed. A caller will not be kicked off with a sleep disconnect after chatting with the SYSOP for more than the maximum time a caller can be idle. Very long messages no longer cause RBBS-PC to hang in the middle of entering them. Uploaded files do not have a control-Z appended to them (which formerly resulted in spurious CRC errors on ARC files). The SYSOP can configure RBBS-PC for more bulletins than exist. File sizes are now properly recorded for all uploads. Failed uploads with 0 bytes are now recognized as bad uploads. KERMIT file transfers can now occur with file names (drive, path, filename) up to the full maximum of 63 characters. -=[]=- That's ˙all ˙for ˙this ˙month! ˙Until the ˙next ˙newsletter, ˙˙Happy Modeming! ˙˙Call ˙your ˙favorite BBS today - and don't forget to ˙say "Thanks" to the Sysop for running it.