旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � _/_/_/_/_/_/_/ _/ _/_/_/_/_/ _/ _/ _/_/_/_/_/ _/_/_/_/_/ � � _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ � � _/ _/ _/ _/ _/_/_/_/_/ _/ _/ _/ _/_/_/_/ _/ � � _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ � � _/ _/ _/ _/ _/ _/ _/_/ _/ _/ � �_/ _/ _/ _/_/_/_/_/ _/ _/ _/ _/_/_/_/_/ _/ � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � MLPNet is owned and operated by Jim Coleman, Cherokee Production Studios � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 "Onward to the 21st Century . . . and beyond!" 靈컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Dedicated to the sustaining influence of William A. Velez � 聃컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� MLPNet: (21:111/0, 21:111/1) FIDONet: (1:350/111) coleman@pacific.telebyte.com A CONDENSED REPRINT of an article that appeared in DSNEWS33.ZIP Permission granted to repost in any forum, but do not change contents. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 넬컴컫컴컫커 旼컴컫컴컫컫컴컴쩡컴컴� 旼컴컫컴컴쩡컴쩡쩡컴컴쩡컴컫컴컴쩡� � 납 � � � � 悶 � � � 컴컵커 旼� � 旼캑 컴캑 � 쳐� 旼� 悶 � 悶 � � � 납 � � � � � � 잎 � � � � 旼켸 � � 굇 � � � 旼캑 � � � � � � 잎 � 잎 � � � 납 � � � 읕캑 旼캑 � � � 읕커 � � 께 � 읕캑 읕캑 � � � � � � 컴� 悶 � 읕커� 납 쳐컴� � � � � � � � � � 께 � � � � � � � � 悶 � 납 � 납 냅켸 읕좔컴컨켸 읕좔컴좔컴켸 읕� 께 읕컴컨컴컴좔좔컴� 읕� 읕牡컨켸읕좔컴켸� � 蔔栢栢白 께 蔔栢栢白 � � 蔔栢栢栢栢白굇굇蔔栢栢栢栢白 � � 넴栢栢栢栢굉께께께껑栢栢栢栢枋 � � 넴栢栢栢굉께께께께께껑栢栢栢枋 � � 賞栢旁께께꿉賽賽三께께글栢幡 � � Sysop: Jim Coleman 賞께꿀複複複複複複兵께幡 MLPNet: 21:111/0 � � Co-Sysop: Scott Berry 남껐같같같같같같같갛껙 FidoNet: 1:350/111 � � 남같같같� 같같같갛� � � No Alias Names permitted 낡같같같 같 같같같개coleman@pacific.telebyte.com � � 複複複屛같輻같같 같같霜같넵複複複 � � /굇굇굇굇굇굉께께께께께께같같같같같같같같같같께께께께께께껑굇굇굇굇굇\ � � 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 � � /�\ /猫鳧\ /�\ � � 같졀� 같牡같 같졀� � � 같졀� 같컴같 같졀� � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� NOTE, PLEASE NOTE: Everything presented here is written from an "AT THE TIME OF THIS WRITING" basis. Keith and crew are working hard to produce a bug fix version, promised several days ago, as usual. Some of the problems delineated here may well be fixed by the time you read this (but I wouldn't bet any money on it.) This review is not intended to slander any individual or entity; these are personal observations and opinions formed after using ARI's KBBS software for eight months, or so. They are presented so that current users of this software might understand better why some features work (or don't work) as they do, and so that prospective ARI customers can evaluate features of this software when making purchasing decisions. Keith Anderson was notified in advance that this review was forthcoming. This review was written in its entirety by Jim Coleman, and permission is granted to distribute or post this material in other forums, so long as changes to the text are not made. (c)1995, Jim Coleman, all rights reserved. PREFACE: KBBS, a product of Anderson Research, Springerville, UT, touts itself as being the "fastest growing BBS software in the U.S. and Europe." ARI also makes the claim that KBBS is the most "powerful and customizable BBS software in the world." Where I may question the validity of the first statement, the second may well be true. Its proprietary SEQ language and unique memory management cannot be matched (at least, not with anything I've tested) and a separate Sysop Utilities menu makes configuration a snap. The problem is, it barely works like a BBS should. I registered KBBS only after making certain its creator, Keith Anderson, understood precisely what kind of system I ran and what I expected out of my software. This was all very important to me: the system was a secondary source of income (it helped keep us afloat during the 14 months I was out of work after being hit by a car) and our MLPNet network was bringing in 2000 to 3000 messages a month at that time. We had many national and international nodes, we were frequently written about in national and local periodicals and I made dozens of new sysop friends and acquaintances from all around the country. Now, however, the system doesn't bring in revenue to cover the cost of even one node, our nodelist contains a lot of inactive nodes and NO international nodes, local sysops just sit back and get a good laugh as my message pointers wipe out over and over again and I see once-familiar names on other systems, but not MLPNet. What happened? What changed? The software changed, and changed MLPNet with it. But not productively, unfortunately. Here are my opinions on KBBS, carefully formulated after many, many months of use and literally hundreds of complaints and dozens of compliments by MLPNet users. I am very familiar with the structure of KBBS and with its proprietary SEQ language, and that is why I can claim that this is an "official" review. No, ARI did not request or authorize this review, but they are aware of it. I'll start with what I like about KBBS (and what you will too!!!) and then progress to what really cripples my system (and may cripple yours as well, until fixed. But don't worry, it's ALL coded in and just waiting for Keith to link in. [sarcasm intended]. More on that later.) Besides, this whole review has been written for weeks, months even. Let's link it all in. If you don't like what you read here, don't worry, you're the only one. Everyone else loves it. At least, that's what Keith tells me about KBBS . . . THE PROS: FIRST, IT IS IMPERATIVE THAT I POINT OUT that many of the problems I will delineate here are often pervasive in ALPHA VERSIONS. Let me explain this, to those who aren't as computer literate or familiar with computer programming. An ALPHA VERSION is a developer's version that is USUALLY tested on HIS OR HER MACHINE ONLY. Keith Anderson has been kind enough to allow the public to test his alpha versions, to help with the bug fixes, etc. A BETA version is released later to the general public to accomplish the same thing. Then, a RELEASE VERSION is made. When I address specific concerns, please remember that they are sometimes from ALPHA VERSIONS. Most specific concerns I list here have been around for a long time, meaning they have also been present in so-called "RELEASE" versions, as well. I wouldn't target anything in this forum that was confined to Alpha versions ONLY. I try to be as specific as possible with time frames and problem longevities in fairness to Keith and the ARI staff. Additionally, there is no way I can cover EVERY aspect of KBBS (good and bad) so a lot of features that DO work and work well have not been mentioned, since they work so well or are of no interest to me. For instance, I don't give a RIP about RIP, so there is no mention of KBBS RIP capabilities outside this disclaimer. I don't know if RIP works, if it works well or if it works poorly. However, if all that follows is any indication . . . ) SETUP: I'll never forget the day I first unzipped KBBS and set it up on my 486 notebook machine to evaluate it. To be honest, I didn't expect much. When I set it up on the hard drive, I was not prepared for what I found. The software LOOKED marvelous! The Sysop Utilities Menu was a thing of beauty (fortunately, I didn't have a color screen on the notebook, but a new color selection menu has since been added). With an option bar across the top and multi-tiered pull-down menus and some internal documentation with most options, I couldn't help but start setting it all up right on the spot. I ran the computer around to coworkers who wouldn't know BBS software from Benny Beanfart's favorite bass lure . . . but they shared my enthusiasm. This was IT, my TICKET OUT OF HERE, I thought, concerning CDC. I came home, cancelled my subscription to "Salt Aire BBS" and set up KBBS. A fund raising effort was started to register KBBS, but I got in a hurry and registered it out of my own pocket. Once the registration key arrived, I sent PCBoard to cyber-hell and went online with KBBS, to the exasperation of many. I lost most all of my callers right away, but I expected that. No one likes change. Most of the local ones came back. Most of the long distance ones never did, for reasons I'll explain later. You want software that is easy to set up? Well, don't expect any documentation, but if you are reasonably proficient with your operating system and BBS features (QWK, FTS, etc.) you can have KBBS up and running in a snap. I did, and I'm just a stupid, inexperienced sysop. More on that later, too. :) FLEXIBILITY: Another exciting thing that attracts a lot of new callers to KBBS (and might even attract YOU!) is that KBBS can look like (and even emulate, to a degree) other popular BBS platforms. You can make your BBS look and act like PCBoard, WildCat!, Renegade, etc. Brian Schulties, a local Port Orchard area sysop, has done a REMARKABLE job at making KBBS look and act like a Renegade system. He gives you an option at login to display PCBoard menus or Renegade. Well done, Brian. His number is 360-876-7958 if you need an example of what you can do with KBBS. Call me and (provided I'm still running it) compare my setup to his. There's no comparison, but it's the exact same software. SEQ: Well, SEQ is the ONLY REASON I have continued to run KBBS. It is the only thing of any value KBBS has that other BBS software platforms don't have and it is powerful and flexible (now that Keith has graciously accomodated my early requests for array structures, etc.) PCBoard and WildCat! have their own proprietary languages and I have done extensive programming with each, but none offer what SEQ offers in terms of memory management, etc. KBBS is by far a better driving engine for SEQ than PCBoard is for PPE, though I understand CDC is making remarkable strides in that area. They've got a way to go before catching up to SEQ, though. Like I said, it's the ONLY reason I'm running KBBS. I began writing programs in SEQ to help compliment KBBS and help promote it, but ARI apparently didn't need any help so I started writing them for profit. I've made it known to Sysops who've registered my games and programs that I will continue to support them no matter which way we go, just as I continue to support my PPE programs when requested to do so. I'm working very hard now to write my own door frame and comm routines so I can market my games and programs to ANY sysop running ANY BBS program. Once I learn this (I don't claim to be an expert programmer by any means, but it's amazing how fast you can learn if you apply yourself) I won't need SEQ any longer. THE CONS: KBBS--The BBS software for those who love to wake up to a DOS prompt! POINTERS: One persistant problem with KBBS is message pointers. This is a problem that has plagued this software throughout the eight months I've been using it as a platform for MLPNet Central. Like a bothersome intermittent drive train noise on a vehicle, the problem comes and goes and (so Keith has claimed) is sometimes absent on his system, even though numerous others are affected. Two recent messages stated that: � "Since we've finally been having the last read pointer problem start happening on Megalopolis instead of just everywhere else, we've been able to run a debugging version of KBBS on Megalopolis and we should have it fixed in the morning." (If it was, we never saw it.) Dated 07-25-95 � "After a week of running diagnoses on this and a few other machines, and getting files from several sysops having pointer setting problems, we have FOUND THE PROBLEM. It's not a file-level problem, and it wasn't even a problem in the pointer update code, but a bug in the multitasking kernel not launching the update code when it was supposed to. This has been FIXED for tonight's release." (Not released.) Dated 07-25-95 AFTER the preceding one. True, this problem has been intermittent. One RELEASE version will be so dysfunctional that you have to revert back a few Alpha's to a more stable platform . . . and the problem doesn't occur in the very next version. But the one after that has the same problem. It is obviously a difficult problem and the ARI programmers have undoubtedly expended a great amount of time to find a fix, but there's a pattern of failure here that a sysop considering this software may want to make note of. CORRUPTION: A huge problem KBBS has had since the first day I ran it is corruption. I would imagine Keith would say it's normal and to be expected, since he built in so many "Rebuild this, that and the other thing" functions into the Sysop console. Just by looking at your Sysop menu, you get a REAL BAD FEELING with all the "fixits" in place. At first, I rationed away that bad feeling by thinking, "How nice! He's got everything in place here in the unlikely event something gets mysteriously corrupted." It took no time at all to realize that important configuration and data files DO get corrupted in KBBS, and it happens over and over again. I've uploaded numerous corrupted items to Keith in the past (file trees, message bases, user records, etc.) for his crew to analyze. "Defrag your disk more often" is something he once said. This was after I COMPLETELY reinstalled KBBS onto a newly reformatted hard drive the week before. There is a propensity at ARI to blame KBBS problems on the Sysop without stopping to think it might actually be a design flaw on their part. But, more on that later. On the subject of corruption, I've heard (on more than one occasion) "It's only happening to you. I can't explain it, Jim, but no one else is reporting this." Then, frequently, a fix is found a week or two later and a celebratory message is written in ARI_KBBS about how the problem "several sysops were experiencing" has been fixed. Is "several" half their registered sysops, three quarters of them . . . or just me? I never ONCE had a file corruption problem with PCBoard. Enough said. CHAT: In all fairness to the ARI staff, there was no NODE CHAT option available when I registered KBBS and I was told it would be "awhile." I was content with that and so were my callers until ARI made it widely known that NODE CHAT would be coming in the next version. That was months and versions ago and it's still coming in the next version, I suppose . . . though they're not being as vocal about its release. Last I heard, it was being tested at several remote sites. I just figure it's one of those "it's already written, just waiting for me to link in" kinda things. I think I recall reading somewhere that all the KBBS executables and overlays already contain working node chat code, they just hadn't linked in or released the SEQ routines needed to implement it. This is one of those "I think I read this" kinda things that I probably DID read at some point, but didn't save. Right now, NODE CHAT isn't a real concern with me as there's so many "runnability" issues pending. DOCUMENTATION: It's coming. It's been coming for a long, long time and talked about often, and asked for almost DAILY in the ARI_KBBS conference. ARI recently released a VERY WELL DONE SEQ Manual, after promising (literally PROMISING) it to me several months ago. "In a few days," Keith said. That was back in April, possibly even March. This was back during early development of 'SCRAPER, my newest (and possibly last) KBBS SEQ game. Good job, guys. REALLY appreciated the manual, even though: (1) it was released in a WordPerfect format I said long ago was virtually worthless to me and (2) it's far too late. Better late than never, I suppose. Need a slogan? SCREEN COLORS If you like to use color codes in your message base, forget it. Head to your nearest software store and buy virtually any other brand of BBS software. KBBS won't remember a screen color from one screen to the next. This is something I've bugged Keith about for over half a year. In fairness to Keith, I can't remember him ever saying "it's coming." Maybe he knew that THIS time it really WASN'T coming, so why build up false hopes? It's such a simple thing, really, but has become my focus and ANYTIME KBBS's RELIABILITY comes up in discussions I have with other sysop friends, I mention the fact that KBBS doesn't remember screen colors and the programmers have known about it for a LONG time. Again, if you are seriously considering KBBS as your platform, remember this: this "little" thing is very important to me and they know it, but nothing has been done to correct it. How huge does a problem have to be before it gets upgraded to the infamous, extremely overused "it's written, just waiting for me to link in" status? (Which usually means: sometime next season, if you're lucky. If you're not Jim Coleman, because it won't work for you anyway, even though it will for everyone else. So get off your damn high horse, it's not my fault you don't make backups and why don't you defrag your hard drive more often STOOOOOOOOOOOOOPID!) RECYCLING Some versions (yes, RELEASE versions) haven't recycled properly (or at all) when a caller hangs up or an event (internal or external) is run. This problem, as I understood it, was at first confined to systems operating under one operating system, but was later expanded to several operating systems//multitaskers, including Desqview and OS/2. This, like the message pointers, is a problem that seems to come and go at random intervals spread out over many releases. Unlike the pointer problem, however, it wears a different face each time. The release I am running now (1816) STILL has the problem following an event. Weirder yet, it displays the ROBOCOMM exit screen after running an event , generates an error message and either (1) drops to the DOS prompt or (2) recycles "normally." This problem has persisted through three alpha versions now. Again, it is something ARI has been aware of, and I fully expect to see the same problem after the next alpha is released. I hope they can prove me wrong. (THEY DIDN'T PROVE ME WRONG. vZ1817--which was released AFTER DSNEWS33 still shows the RoboComm screen on recycle.) KBBS has not operated "reliably" in as long as I can remember. There have been periods of time with one alpha or another where the board was somewhat stable, but getting up five or six times a night to reboot the system was--at one point--a nightly ritual that lasted for many weeks. Even now, we STILL have to boot up nodes in the middle of the night, when coming home from work, etc. Something to think about if you are one of those who expect to run a stable system that answers the phones when you tell it to. On the other hand, if you are shopping for a program that closes down your windows and basically shuts down your computer at random intervals throughout the day and night, KBBS is for YOU! ATTITUDE AND COOPERATION: ARI needs a serious attitude adjustment, in my opinion. Of course, I read mail every day from people praising Keith and crew. Keith even forwarded me a letter one time that someone else wrote in praise of them, just to try to prove me wrong, or something. I never did quite figure out what his intentions were. In the beginning, ARI was as helpful as could be. I made many suggestions and many SIGNIFICANT changes were made. At one time, Keith thanked me, saying that they were writing something THEY thought the public wanted, but I came along and showed them what the public REALLY NEEDED. These changes are too numerous to list and I wouldn't be running KBBS today were it not for them. I am grateful for the early cooperation and efforts. However, as things seemed to unravel and become more unstable with each release, the "newness" began to wear off and I came to realize I possibly paid for something I was not gonna get in time to salvage what remained of MLPNet. Anytime you change platforms, you are bound to lose some people, as (1) people are inherently resistant to change and (2) most MLPNet callers are long distance and there is a tremendous amount of setup work to be done before mail can flow freely again. Some didn't want to invest that time, some didn't want to learn new scripts or new ways of doing things, but MOST WERE FTS NODES and we had to wait a LONG TIME for FTS to be implemented in KBBS. To this day, our international nodes can't call since KBBS won't properly gate MLPNet to them. This was something Keith told me a long time ago would be a PRIORITY "so you don't have to restructure your network or lose any more nodes." Well, Keith, thanks to your weird definition of the word "priority," we lost them all. One node from Germany still calls routinely to see if there's any mail, but KBBS doesn't recognize his node number, though it IS in the nodelist and it IS in the gate setup. At any rate, we've not recovered from the NINETY PERCENT of FTS MLPNET nodes lost as a result of no (or poorly working) FTS. Current FTS nodes still cannot utilize some areafixing and other standard features QFront, Front Door and other established, stable front end systems can. I can not talk to some other FTS systems, and mail is choked off at the source. (1:350/0, remember that one, Keith?) As I started seeing similar things going wrong, I began to get a bit more vocal about them. After awhile, they stopped listening. Mary and I played a little game sometimes: "Okay Mary, here's a letter where I'm telling Keith something is screwing up and I need it fixed ASAP or we're gonna be in trouble. Betcha we don't get a response." and "Okay, here's a nice letter full of bubbles for something they fixed." Nine times out of ten, the bubbly letter got a response and the other didn't. In fact, there were several crucial messages "lost" due to "hardware." You'll see that critical mail regarding THIS REVIEW was apparently "lost" due to the same reason. I mention over and over again in this review that ARI is a company of predictable patterns. This is yet another one. (Most of them involve some sort of failure, too . . . if that means anything.) I guess I'm riding tall, because Keith told me to "get off" my "damned high horse." This was after I made a desperate plea regarding a very serious problem we'd written back and forth about several times with no resolution. It was the last straw, a last ditch attempt to let Keith know just how seriously KBBS affected MLPNet in a negative way, operationally, financially, business-wise. Keith, apparently, believes KBBS is just a *BIT* flawed and any sysop who can't make it do what he claims it can do is either: (1) Inexperienced -- "You should defrag your hard drive more often," he once said. "No one is having this problem but you, Jim." (It was a newly reformatted disk with a fresh installation.) (2) Stupid -- "Is it MY FAULT you didn't make a backup?" he said TWO WEEKS AGO. (I had made TWO backups.) (3) Emotionally distressed -- "It seems you are using ARI as a scapegoat for all your problems," he wrote. I responded: "Fortunately, Keith, most of my problems have NOTHING TO DO with ARI. However, ARI is responsible for KBBS related problems." I guess ARI now thinks that the inexperienced, stupid, emotionally distressed sysops of this world are causing the problems with KBBS, problems they can't duplicate on their end and Hal's not complaining about them so, therefore . . . they don't exist. Except in the minds of those inexperienced and stupid enough to keep holding out for KBBS v2.0 and the OS/2 version of the same, as ARI hurdles numerous deadline obstacles and projected release dates with the ease of a gold medalist (sarcasm). I won't get into agreements made early on between Keith and myself regarding promotion of MLPNet and KBBS, my SEQ games, etc. These were personal mutual agreements made and ARI defaulted on EVERY SINGLE ONE, to the best of my knowledge. These issues were what planted the seeds of my discontent. It was only after I saw no cooperation or follow through on ARI's part that I started paying closer attention to what was not working over here and why. I will note that Keith did follow through with a request I made a month ago for an immediate SEQ UPLOAD area. Thanks, Keith. I guess it's the little things that count. One funny little sidebar: I noticed that ARI's insufficiencies began when Keith hired all the programming help; you know, the ones with the cutesy little planet names. The product and people stopped performing as they had in the past, problems were tabled, passed on, put on the infamous "todo" list and lost in the pile, which no longer exists. Unfortunately, the problems still do. I no longer expect anything from ARI, not even a working product. It's what I hope is eventually delivered (since I've already paid for it in every sense of the word), but KBBS is a classic case of "too little, far too late." Still hanging in there for UUCP, Ted? THANKS AND GRATITUDE I would like to thank Keith and crew for their efforts to improve KBBS and bring it up to a competitive and useful level. Without them, this review (and my hypertension) might very well have been impossible. I hope that the motto I follow at Cherokee Production Studios can be applied at ARI: Don't promise more than you can give. Give more than you promised . . . and do it when they least expect it. (((make it a random act of beauty, perchance???))) I do it with my writing and my programming, & that's what I'm doing here. ADDENDUM: Today is July 29, 1995, the release date for this newsletter. I released DSNEWS33 this morning, then took my girls to Annapolis to watch the surf and watch the warships pull in and out of Puget Sound Naval Shipyard. When I came home, node three was crashed with an error message, and node two was locked. I rebooted the nodes and went to REPAIR/REPACK the message bases, something I do weekly since I don't use ARI's internal continuous message packer. It locked up near the end . . . yet another corrupted message base. This is perhaps the fourth or fifth in as many weeks. I deleted the entire message base (there's no other way to do it with KBBS when you get this deep and this far) and rebooted the nodes. They crashed again with the next call. I had to restore from a backup made a week ago, copy in the current USER*.* files into C:\KBBS, then rebuild everyone's pointers and status again just to stay on top of things. It all appears to be working. I know I'll be doing this again. I could reinstall PCBoard and set that up and go thru all the rigamorole of conversion again. I've really thought very hard about this. But KBBS *might* be fantastic software, if and when it is ever written and more than just a little bit, sporadically functional. So, what are the options? Change back, then change again when they FINALLY deliver what they've been promising? Or, keep on keeping on, dealing with errors and corruption, user complaints, having bug notices ignored by ARI, taking the attitude shovelled out and shovelling it back, reading Thud Ruder's "Wildcat never crashes" messages for the rest my life, getting up all hours of the night to check on the system and reboot it so mail can flow, deleting corrupted conferences and trees, backing up and restoring from backups and listening to Keith say "It's not MY FAULT you don't back up," when, in fact, it's all I ever do anymore with this software. I'm open to suggestions. 栢� 栢� 栢栢栢� 栢栢栢� 栢栢芳 栢栢栢栢� 栢栢栢芳 栢� 栢� 栢�袴栢� 栢�袴栢� 栢�袴栢� 훤谷排袴� 栢�袴袴� 栢� 栢� 栢� 栢栢栢�� 栢� 栢� 栢栢栢舫 栢� 栢栢芳 훤� 栢� 栢� 栢�袴暠 栢� 栢� 栢�袴栢� 栢� 栢�袴� 栢� 휩栢栢排� 栢� 栢栢栢�� 栢� 栢� 栢� 栢栢栢芳 훤� 훤袴袴� 훤� 훤袴袴� 훤� 훤� 훤� 훤袴袴暠 Date: 07/30/95 (08:07) 80 of 80 From: JIM COLEMAN To: KEITH ANDERSON Subj: HASTA LA VISTA Conf: 30: MLP_NET_NEWS =================================================================== I am setting up PCBoard again, effective immediately. At least they have software that works and an OS/2 version. You can't say I wasn't patient. Wish I could say "It's been real and it's been fun, my friend," but I can't. It's been a nightmare. Good riddance for both of us. Please disconnect all my feeds and stuff, effective immediately. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴