synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / main / TEXT / WWIV9206.TXT < prev next >

Wrap

Text File | 2001-07-30 | 31.4 KB | 557 lines

┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐ ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐ ╔═════════════││││││││││││└─┐┌─┘││ │││ └┐│││┌───┘│││││││┌───┘═════════════╗ ║ Volume 3 ││││││││││││ ││ └┼┐┌┼┘│ └┘││└───┐│││││││└───┐ June 24 ║ ║ Issue 2 ││││││││││││ ││ ││││ │┌┐ ││┌───┘││││││└───┐│ 1992 ║ ╚═════════════│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═════════════╝ └────┘└────┘└────┘ └┘ └┘ └─┘└────┘└────┘└────┘ ┌─────────────────────┐ │This Month's Features│ ┌──────────────────────────┴─────────────────────┴───────────────────────────┐ │ Random Factors.......................................Wayne Bell (1@1) │ │ │ │ "With Our Easy Payment Plan..."......................Filo (1@5252) │ │ │ │ TAMing the WWIV Transfer Area........................Tolkien (1@3456) │ │ │ │ Eight Ball's Guide to Duplicate Net Posts............Eight Ball (1@6913) │ │ │ │ TechnOTES............................................WWIVnews Staff │ │ │ │ Filo's Mod of the Month..............................Filo (1@5252) │ │ │ │ Dateline: @#$*()#! - A Farewell From East Bay Ray....Omega Man (1@5282) │ └────────────────────────────────────────────────────────────────────────────┘ ───────────────┬─────────────────────────────────────────────┬─────────────── │ Random Factors │ │ Creative Commentary by Wayne Bell (1@1) │ └─────────────────────────────────────────────┘ I thought I'd start out here with a few extended form-letter answers to some e-mail that I've been getting recently. First off, no, I do not yet have a date for v4.21a/net31. Net31 will probably be out 2-3 weeks before v4.21a. The net31 release may be in about 1-2 months. Maybe sooner, maybe later. When available, net31 will be available (hopefully) on the SDS's and on the WWIV Support Systems. The compiled version of v4.21a (when released) should be available on the SDS's and the WWIV Support Systems, while the source code to WWIV will be available only on the SDS's. As a reminder, the current SDS's are: @1, @4, @2902, @3459, @5252, @5401, @5460, @5819, @6211, @7400, @7663, @8350, @9800, and @856 (in Japan). The WWIV source code should >NOT< be available on any system which is not in the above list of SDS's. And, the source code on the SDS's is available only to users that I have authorized to D/L it from there (leave me e-mail from your account on the SDS, giving your name, full address at time of registration, and WWIV reg #). If you see the WWIV source code anywhere else, they are >ILLEGALLY< distributing it, and I'd appreciate it if you would e-mail me telling me about it. For those interested (and I'm surprised at the number of people that are), in v4.21a, there will be a file in the DATA dir listing the networks of which you are a member. For each network (you specify network name and node number), there is a separate directory to hold the network files (*.NET, BBSLIST.*, CONNECT.*, BBSDATA.*, SUBS.LST, SUBS.1, SUBS.2, and *.NET from the GFILES dir). Net e-mail is then stored with an index into the database of networks to identify which network it came from. Subs also have an index into the networks database indicating which network the sub is on. Net-related parts of the BBS then index into this networks database. For instance, when you scan a net sub, a global variable is set to indicate which network is the current network. For e-mail, the BBS will search all available networks for the network with the node number you specify. If there is more than one network with that node number, you are presented with a list, and asked to choose one. Functions relating to calling the network executables (NETWORK.EXE, etc) are in a loop to process all networks, or to find the correct one. For networks with separate executables (the link pre-processor, or the DE1.EXE for IceNET), the separate executables go into the network directory. If you are interested in starting your own network: Do not e-mail me and ask me how to do it. There is no .doc file describing how to set up your own network, and I'm not going to write one. If you are not familiar enough with how the net software works to set it up on your own (perhaps with some help from others), then you should NOT be starting your own network. Instead, play around with the network software, get some external programs that use the net, and examine them. Look through the network data files, and figure out how they work on your own. Please feel free to ask others about specific things like, "How long can a system name be?" or "what is the highest group number possible", but don't just ask, "How do I set it up?" You'll then know a lot more about how the net works, and will be able to handle problems when (not if) you encounter them. Even if you do know enough about the network to start your own, first think: Is it worth it? Do not just start up your own network because you think you'll then have power and prestige. It isn't worth it (believe me). If you don't have anything that will make your network different from other networks already out there, then PLEASE do not start another one. I really am afraid of having lots of carbon-copy networks out there, and having arguments about, "My system is in 12 networks" - "Yeah? Well, mine is in >14< networks!" It really would be pathetic if we ended up with a few hundred systems that were all in the same set of 15 networks. What would be the point? And, for a final note, a slight clarification/update on the netup software that is being "sold" for $300. If you don't already have a network up with 20-30 systems in it, it isn't worth it. If you don't have a network up and running, don't even ask me about it - get things working first. It is $300 because I have to write a separate EN1.EXE/DE1.EXE set of programs for each network, and don't want to bother setting it up if someone isn't REALLY sure they want that. ───────────────┬─────────────────────────────────────────────┬─────────────── │ "With Our Easy Payment Plan...." │ │ How to Register WWIV The Deferred Way │ │ by Filo (1@5252) │ └─────────────────────────────────────────────┘ Editor's note: With the "register or die" deadline either passed or imminent (depending on the Group you're in), quite a number of sysops who wished to remain in WWIVnet but couldn't scrape up the $50 in one lump sum were in need of some sort of installment plan for registering. Such a plan is now in effect, and is being administered by Filo (1@5252) as part of his new duties as WWIV Software Services Coordinator. As to how this plan will work, Filo's comments below, as posted on the National Sysops' Sub sheds some light on the issue. ───────────────────────────────────────────────────────────────────────────── New Payment Option Some sysops have indicated that they just cannot get $50 together at one time to register. With this in mind, a new payment option has been developed and will be used by WWIV SOFTWARE SERVICES. A sysop who wishes to take advantage of an installment plan option, would fill in the application (see Net29 or Net30) and mail it to WWIV SOFTWARE SERVICES (see recent letter from Random to All Sysops) and write on the Application INSTALLMENT PLAN. The sysop would make 3 payments of $20 each. This is how it would work: Payment 1 -- extends the trial period for 60 days applies toward registration Payment 2 -- extends the trial period another 60 days applies toward registration Payment 3 -- completes the registration fee ($50) pays $10 for handling & postage (rather than normal $5). Total cost under payment plan must be at least $60. If a foreign node takes advantage of this, the total fee would be $65 instead of current $60. Installment Payments are NON-REFUNDABLE. If you do not make the next installment payment on time, you lose the money you have paid in. Under this arrangement, the 'poor' sysop can take as long as 4 months to pay the full amount. ───────────────┬─────────────────────────────────────────────┬─────────────── │ TAMing the WWIV Transfer Area │ │ By Tolkien (1@3456) │ └─────────────────────────────────────────────┘ Over the years, the task of keeping up with the file areas on our board had begun to get wearying. A misspelling in a description seemed to take too long to rectify. Editing or creating an extended description was even worse. And then there's virus scanning, stripping out archive comments, and inserting GIF file resolutions. As a result, I often found the sysop directory filling up with hundreds of files, which made the thought of having to laboriously wade through it all just that much less appealing. Wayne tried to make some of this easier in WWIV itself, with the upload event, but it never seemed to work all that well for me. Internal modifications to the code allowed inserting GIF resolutions and virus scanning, but then you had to do those modifications again, and again, and again, every time a new version of WWIV would come out. In 1990 I decided that there needed to be some sort of program devoted solely to making all these tasks easier, something that wouldn't have to be redone every time a new version of WWIV was released. I sat down then and began to write such a thing, but at that time the task was simply beyond me, the scope too large for me to deal with. Another year and some went by, I learned a thing or two, and I decided to try it again. I figured I'd rather spend a hundred hours writing something to make life easier forever after rather than spending a twenty hours a month just trying to keep pace. And, somewhat amazingly to me, I finally succeeded. Thus was TAM born, standing for Transfer Area Manager. Now editing descriptions, sorting, moving files, renaming directories, virus-scanning, comment-stripping, viewing docs inside archives, inserting GIF resolutions, making sure that WWIV's file size matches the actual size of the file in DOS, even viewing a GIF file to see if the description is accurate - it's all a keypress or two away. Even better, when multitasking I can go take care of the transfer area in one window while someone is online in another. The labor is vastly reduced. I don't feel like screaming when I see twenty or thirty or fifty files appear in the sysop directory. I spend a third the time taking care of the transfer area now than I ever did before. In short, if you're spending hours and hours maintaining your file areas, you shouldn't be. It's always going to take *some* work, but there's no reason anymore for it to take half the fun out of life. While I'm here, some questions that have come to mind since I first released TAM need to be addressed: "Does TAM support file-locking while operating under a multitasker?" Nope. I suppose that potentially there could be a problem with that if a directory file were being written to at exactly the same moment TAM is messing with it. In practice, however, this has not happened to me or to anyone else of whom I am aware. The odds are greatly against any such problem because TAM does things fairly quickly - read, write, bail out. Additionally, under OS/2 you are protected from any possible problems. "What about modified directory structures?" I wrote a compiled version that works for those who have Tony Godfrey's GoldSys mod installed. That executable, along with the "normal" one, is included with every TAM archive. Source availability - no one who could benefit from having the source has ever asked me for it. Even if I did give the source code to someone, to compile it would require Async Professional and Turbo Professional from TurboPower Software (at around $100 each). Obviously, I cannot give *those* away so the only people to whom I would even consider giving the source to would be those who could furnish me verifiable serial numbers for both of the above. Unlikely, but if it ever happens, I'd probably give it to that person. "Just how much overhead does TAM require?" Memory requirement is about 320K, so it would be possible to run TAM on a 512K system if shrink were available - probably. In practice, anyone who is running WWIV on a 512K system really needs to consider upgrading to 640K. TAM runs fine in 640K, although when it needs to call another program (VPIC, PKZIP, whatever) it has its own internal shrink method that swaps out of memory to expanded memory if it's available or hard drive if not. Obviously, having some EMS available makes things run at a better clip, but it works either way. Having said this, the more memory you do have available, the more files you can put in a file area and still be able to sort. TAM's upper limit in practical use is about 2000 files per file area and up to 256 file areas. The actual supported limit is 9999 files per file area but you would lose the ability to sort such a file area long before reaching that absolute limit due to memory constraint. Still, this is a simple way to overcome WWIV's default 499-file limit for a file area and doesn't require the source code or any knowledge of programming at all. "Are any of the aesthetic mods supported?" As far as colorizing file descriptions and directory names, TAM allows insertion of basically any character (via the standard control-P control-C sequence for WWIV color codes), so it's simple to create truly gruesome color combinations for file descriptions. (Come see some of ours if you want an example of icky.) "Does TAM work remotely?" No. And yes. No, in that TAM does not itself support ANSI or asynchronous communications. Yes, in that nearly any program can be run remotely if you use a piece of software that intercepts direct screen prints and sends that information out the modem. DOORWAY is the most common ShareWare program that allows this. "Does TAM convert archive types?" No. And yes. It does not do so directly, but since you can yourself define eight hotkeys that call up any program or batch file you want, you can achieve the same thing with minimal effort: once you've created the batch files that do the conversion, the process would be to hit the hotkey, then type in the new extension yourself after the batch file is done processing. However, this is not an ideal method. Depending on the support I receive, I intend to make it a simple one-key command to perform such conversions with no extra effort at all. Is this a blatant plug? Well, to some degree, yes, but not entirely. Lots of people don't even know such a utility now exists, because I haven't plastered that fact all over every sysop sub in the world. Mainly, I just want people who are tired of the drudgery of maintaining a large transfer area to know that there is a solution available. I'd have killed for such a utility two years ago, or even last year. I suspect there are quite a few who are in the same shoes I was in then. And actually, if you can find something that does the job better than what I've done with TAM, use that instead; that's the American way, after all. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Eight Ball's Guide to Duplicate Net Posts │ │ by Eight Ball (1@6913) │ └─────────────────────────────────────────────┘ As hard as it might be to believe, duplicate posts on networked subs these days are almost NEVER caused by someone screwing up with their N*.NET or NN*.NET files. Although this still happens, there are two other software-based causes that should also be considered when duplicates appear: incomplete packet transfer and LNET disuse. The three types are detailed as follows: Type I: There is a glitch in net connects somewhere. On the sending node, Zmodem or HSLINK thinks the transfer failed, but on the receiving node it got the file fine. The sending node will keep the net packet and send it again (along with new stuff, if any) on the next net connect. If it happens again this can lead to triplicate, quadruplicate, or more. Type II: N[N]*.NET file screwup. Subscriber created N*.NET file instead of NN*.NET file, or host entered node number into N*.NET file more than once. Type III: Someone deleted a post or e-mail off the local node but forgot to use LNET to remove it from the net packet (or didn't know how to, or even that he/she had to) How to tell is something is a duplicate: Look at the dates in the headers. If they're the same, it's a duplicate. If they're different, it's highly likely someone tried to delete a post but didn't remove it from the network packet using LNET. That's very rare though. (This is type III below) How to tell which type you have: Are you getting more than TWO copies of each post (i.e. 3 or more)? If so, the problem is almost certain to be Type I (very very rarely type II, and even more rarely type III). If the number varies (sometimes you get 2, sometimes you get 6, sometimes you get 3) it's almost definitely type I also. If you are a subscribing node: A. Are the duplicates only occurring on more than one sub that you carry? If yes, problem is probably type I, otherwise it's probably type II (very very very very rarely type III) B. Are the duplicates also happening in e-mail? If yes, the problem is almost _definitely_ type I (very rarely type III) In general it's easier for hosts to determine where the problem lies... If you are the host node: (using net val makes things easier...) A. Do you see single posts from more than one subscriber? If so the problem is probably type I and is happening somewhere between that subscriber and your node. B. Do you see single posts but subscribers see duplicate posts? If yes, the problem is definitely type I, and is happening somewhere between your node and the affected subscribing nodes (not all subscribers will see duplicates, and this will help you detect exactly where the problem is) C. If you have net validation turned on, do the duplicated posts say "Not Network Validated"? If yes, the problem is almost definitely type I (very very very small chance of type III). If the incoming posts do *NOT* say "Not Network Validated" then the problem is _definitely_ type II (although be SURE you didn't just validate them and forget) Fixing the problems: Type I: First you have to figure out where the problem connect is. It might be one of your connects, but not always. The only sure way to tell is to watch a connect. DSZ or HSLINK will return a successful transfer on one side but not on the other. (You won't know until the following connect, and you have to be the receiving node to find out). Solution: Make sure both nodes are running the same dated version of the transfer protocol. If you are, and the problem persists, then you should both get a different version of it. If the problem is not between you and the connect, you will have to figure out the routing between the node generating the duplicate messages and the node(s) receiving the duplicate messages (because not all subscribers might be getting them). Then you have to have each of the nodes along that path check their connects. It's best for the host to work towards the subscriber(s) while the subscribers work towards the host. If you have trouble figuring out the routing, bug someone (knowledgeable area sysop or AC ideally, less ideally GC or Wayne) Type II: Find out what node is generating duplicates. That node should check for a properly named N[N]*.NET file and ensure that there are no duplicated node numbers in it. Type III: Tell your users how to use LNET and have subscribers do the same. Hope this helps. Suggestions for additions and/or questions are welcome. ───────────────┬─────────────────────────────────────────────┬─────────────── │ TechnOTES │ │ Compiled by the WWIVnews Staff │ └─────────────────────────────────────────────┘ ...The big news the past month is Cyrix' announcement of the first of a series of 486 hybrid clone chips. This first chip, the 25mhz Cx486SLC, is a hybrid containing many of the features of both Intel's 486SX and 386SX processors. The Cyrix chip uses the 486 instruction set and lacks an internal math coprocessor, like the 486SX, but operates at 32 bits internally with a 16 bit external bus in the same manner as a 386SX. The chip is designed to be a "pop and drop" replacement for existing 386SX machines, especially those that lack Intel's "clock doubler" sockets. Cyrix also plans to release versions for 386DX machines, as well as a 33mhz version of the Cx486SLC, by the end of this year. ...It should be noted, however, that the new Cyrix chips are not without their drawbacks. Hardware-wise, the Cx486SLC only has a 1K internal cache (as opposed to Intel's 8K cache on the 486DX), and the 486 instruction set is based on microcode that is reverse-engineered to be compatible with Intel's 486 code, and is proprietary to Cyrix and raises compatibility questions. Legal-wise, Intel is attempting to secure court injunctions against Cyrix to prevent release of the chip pending further legal decision on whether the new chips infringe on Intel copyrights. Latest word on the rumor mill is that Texas Instruments, with whom Cyrix has been negotiating for rights to use the new Cyrix clones, may soon throw in their financial weight behind the Cyrix legal defense fund in exchange for a sweeter chip deal with Cyrix. ...Last month's TechnOTES touched on the drop in prices for Floptical and Flextra removable mass storage devices. This month there have been similar price cuts for other forms of removable mass storage. Removable hard drives, primarily those by Quantum, have dropped in price a bit below previous MSRP. A 50 meg drive with docking adapter can now be found for under $600 on the street, with drive sizes available up to 240 megs. Disk Technologies has a comparable product line ranging from $799 for 20 megs to $1500 for a 120 meg drive. Prices are expected to drop further on the smaller drives as the demand for Windows on laptops forces manufacturers to focus their resources on producing larger drives. ...Iomega, not to be left out in the cold, has a new Bernoulli Box out as well. Connectable to any PC with an ISA bus, this drive supports both the 44 and 90 meg formats, and sports a 19ms access time, or so claims Iomega. Prices on the street are around $900, but used Bernoulli's are beginning to show up on the used peripheral market at about half MSRP, and it's not uncommon to find used Boxes with three or four disk cartridges. At the same time, prices on 5.25" Magneto-Optical drives are expected to drop somewhat in light of the arrival of the new 3.5" format. The 5.25" M-O format can hold upwards of 600 megs a cartridge, while the 3.5" M-O disks store only a fifth of that at 120 megs. Drive prices are a bit high still (upwards of $2000 a drive, and $75 a disk), but again are expected to drop in the coming year to about half that. ...For systems that have exceeded all possible bus combinations for hard drive installation, Prima Storage Solutions offers a line of external HD's that connect through the parallel port. With prices ranging from $999 for a 85 meg drive to under $3400 for a 545 megger, this places the externals at prices per meg comparable to Bernoullis or Removable HD's, but cheaper than either the Flextras or the Flopticals. Micro Solutions offers a smaller but similar (not to mention cheaper line of parallel port externals, with the high-end price being $795 for a 100 meg drive. ...Regardless of the format, any form of removable mass storage would work well for systems that have large file sections (such as .GIF's) that are incapable of adding additional drives, and whose file sections would be better suited by frequent rotation. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Filo's Mod of the Month │ │ by Filo (1@5252) │ └─────────────────────────────────────────────┘ The 'Mod of the Month' will be my pick of the mods appearing on WWIV Modifications Net Sub (SubType 2370; host 5252) during the month or time period since the last issue of WWIVnews. It will not necessarily represent the best mod or the 'neatest' code, but it will be my pick of the mods. I do not guarantee it to be bug-free and do not make any representation regarding whether or not I tried it out. Because of the format of the news, mods that contain EXE, COM, UUcode, etc., will not be considered for selection. This month's pick was written by Lance Halle and is a fix for the failure of some high-speed modems to detect that user has ansi installed. As such, it is a highly useful mod. ───────────────────────────────────────────────────────────────────────────── Here is a FIX for the intermittent failure of WWIV 4.21 to properly detect if a caller is ANSI compatible. Edit MODEM.C as follows: Search for the following fragment at the end of void answer_phone ──────────── incom=outcom=1; if (!(modem_flag & flag_ec)) wait1(45); else wait1(2); ──────────── Change wait1(45) to wait1(72) Change wait1(2) to wait1(36) This will increase the delay after carrier detect before the BBS sends the string to detect if a caller is ANSI compatible. The delay will increased from 2.5 seconds to 4 seconds for callers with error correcting modems. It will be increased from 1/9 second to 2 seconds for callers with non error correcting modems. Error correcting modems seem to take longer than non-error correcting modems before sending their connect string to the terminal program. Also many terminal programs are just plain slow processing those connect strings. If the BBS sends out the ANSI inquiry string before the caller's terminal program is ready, that string may be missed entirely. Since there was no response to the inquiry, WWIV assumes the caller cannot handle ANSI. This mod increases the delay to allow the caller's terminal program more time to finish handshaking chores. It has been tested with numerous callers, and the BBS has not failed to correctly detect ANSI since the mod was installed. I checked with Wayne, and it has his blessing as far as safety goes. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Dateline: @#$*()#! │ │ Editor's Notes by Omega Man (1@5282) │ └─────────────────────────────────────────────┘ I had originally planed a commentary regarding the registration deadline for this month's column, but Jeff Garzik (AKA East Bay Ray) unexpectedly sent the following commentary in e-mail. It can best be described as what we journalists call a "-30-" column, which signifies that the article is the last the writer has officially written for the publication. That article usually takes the form of a "farewell address", and details what the writer feels are his accomplishments and touches on why he/she/it is departing in the first place. This, without question, is what Jeff has done. So, without further adieu, here's Jeff's "-30-" column. ───────────────────────────────────────────────────────────────────────────── First of all, I would like to say congratulations on a job well done. I just got the first issue of WWIVnews under the new "management" and I can say sincerely that it is a great deal better than mine. It helps me see where I went wrong in putting together my issues - organization. One person really can make a difference. To let you know a little about WWIVnews, you have to know a little bit about Fido. When I first joined FidoNet a year or so ago, I received this "neat-o" archive every week or so, which contained the current issue of FidoNews, the FidoNet newsletter. After the space of about a month, I realized that WWIV, growing as it was, definitely needed such a newsletter as well. So, after pestering $F4 (1@1) a lot, I got my wish. That surprised me - a (then) 16 year-old junior in high school with no journalistic/publishing experience whatsoever. I did the best I could, and I think (not my own back patting, I received a lot of 'thank you' letters during my WWIVnews's lifespan) I did a pretty good job. I also know when I see a better job. Right from the start, when I first saw Omega Man's posts, I noticed a certain degree of professionalism in them. That is the "little touch that means so much" in a publication such as this. A column by Wayne, a mod-of-the-month by Filo. Great ideas. Finally, a couple people wanted to know why I stopped doing WWIVnews. Two reasons. One, I wasn't very aggressive in my submission-hunting; and two, my senior high school graduation was fast approaching, and I had other plans besides a BBS during the summer and beyond (Ga. Tech - CompSci major). It wasn't the network, which is filled with tons of great people, or the network administrators, who work their asses off for little thanks, or even the network software, with its much-cursed 32,767 byte packet limit. Thanks WWIVnet for a great time! ┌───────────────────────────────────────────────────────────────────────────┐ │ Closing Credits │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIVnews is an independent newsletter published monthly as a service to │ │ the WWIV community of sysops and users. The opinions and reviews expressed│ │ herein are the expressed views of the respective writers, and do not │ │ necessarily reflect those of the WWIVnews staff. Reproduction in whole or │ │ in part is allowed provided proper credit is given. All rights reserved. │ ├───────────────────────────────────────────────────────────────────────────┤ │ The distribution sites for WWIVnews are the Klingon Empire BBS (512-459- │ │ 1088), WWIVnet node @5282, and the WWIVnews Editorial Desk networked │ │ subboard, subtype 15282 host 5282. Information regarding article and │ │ editorial submissions, back issue requests, and the WWIVnews Writer's │ │ Guide, can be requested in e-mail from the WWIVnews editor, 1@5282. │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIV and WWIVnet, copyright 1986,1990 by Wayne Bell │ └───────────────────────────────────────────────────────────────────────────┘