synchro.net

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

/ synchro.net / synchro.net.tar / synchro.net / modem.madness / SMMNETML / BGNETB12.ZIP / BGNET.TXT < prev next >

Wrap

Text File | 1993-03-23 | 19.2 KB | 435 lines

BGNET 1.0 BETA 12 TUE 23 MAR 93 -------------------------------- I'm going to start taking lessons from Boris Yeltsin. (I've probably just butchered his name like mad), but, the net status fields have pushed me to the limit. In the past two weeks I've had four people send me sample QWK bags that had net status in it. Each bag was using a different format. Rather than spend the next two years trying to figure out what I'm supposed to do with all the bloody net status fields, I have taken a different step: BGNET NO LONGER CHECKS FOR NET STATUS IN QWK PACKETS! I urge you to get permission from the sysop of the other board before importing the mail to your BBS, but, I can't stop you from doing it unauthorized anymore. I got the Orkin Man to spray BGNET so BGNET no longer even knows what "net status" means. It doesn't care. It will import any d*mn packet you tell it to import now. A few cosmetic changes to both the display and log file made it into this version. Now that we have the stupid net status nonsense out of the way, I can spend time improving the display, log file, and increasing the speed of imports and exports. That'll be another day. Please note the new REGISTER.FRM for BGQWK/BGNET is included in this ARJ file. You can now register with your CREDIT CARD (Discover, VISA, Mastercard, and now, EVEN AMERICAN EXPRESS). BGNET 1.0 BETA 11 WED 13 JAN 93 -------------------------------- It's been two months since the last release of BGNET. I've fixed some bugs and made some changes and improvments. I should be writing a documentation to BGNET as it gets more stable. 1. The net status determination engine has been rewritten yet again. I saw a bug report that indicated BGNET would not recognize net status in conference 0. It should be now. Whoever reported that bug, please let me know if this beta fixes it. If you wish to import GT Power packets with BGNET, you will have to ask the sysop of the BBS you are calling to change line 299 of his SYSOP.BBS file from the default of: "Produced by Qmail...Copyright (c) 1987 by Sparkware. All Rights Reserved" ... and change it to: "MarkMail and RNet, The Logical Choice!" Doing this will make BGNET think the GT Power on the other end is really a MarkMail door which gives global net status to all conferneces. This does NOT have to be done if the other GT Power system offers the BGQWK door. 2. BGNET will now import messages (especially on big QWK packets) more quickly than before as BGNET will build a single index to use for all conferences rather than doing it one conference at a time as in the last few betas. This, however, limits the maximum number of messages in one QWK packet to 4096. If this number is too small, let me know and I'll make it bigger. 3. Added support for two environment variables ... QWKDIR and REPDIR. BGNET will default to looking for QWK files in the directory specified by the TP= directive in the GT.CNF file. REP files default to be created in the directory specified by the UP= directive in the GT.CNF file. To override this, simply do the following in AUTOEXEC.BAT or the batch files that start up BGNET: SET QWKDIR=J:\RELAY\BACKUP SET REPDIR=D:\NETTEST Will force BGNET to look for QWK files in J:\RELAY\BACKUP rather than C:\GT\SPECREQ (which is specified by TP= in GT.CNF). REPDIR is similar. Remember, using these environment variables is totally OPTIONAL. 4. Attempted to fix, yet again, the problem with PKZIP and PKUNZIP not being found at times. The PKZIP and PKUNZIP paths will be shown on the screen so the sysop knows what's been looked for where. 5. BGNET was writing to BGQWKpid.LOG rather than BGNETpid.LOG. OOOPS!!! Fixed. 6. If the work directory cannot be deleted for some reason, rather than erroring out with a Runtime 162 or Runtime 005, the error will be taking care of gracefully and added to the log file. 7. Some minor changes were made for debugging purposes. Special copies of BGNET were made for two people that helped with problems with the latest MarkMail Beta. The "fix" cannot be found in this public beta as it would compromise the security of the MarkMail door. BGNET 1.0 BETA 10 SAT 7 NOV 92 -------------------------------- It's been three months since the last BGNET ... so here's some new stuff: 1. IMPORTANT ... THIS IS NOT A DROP IN REPLACEMENT ... Your hubid.CNF configuration files must be CHANGED ... BGNET now allows you to use up to FOUR different export and import taglines. This is provided so those people that pick up more than one network from the same hub system can configure the taglines and make only one run to the same hub system rather than many more. Here is an example of the NEW format of the BGNET.CNF file: I1=001/070: Computech E1=001/040: Tranquility Base - 713-893-9124 - Houston, Tx I2=LinkNet: INCOMING .... E2=LinkNet: The Great American Tokad -----+-------+[n=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] 0003 | 01576 | 1=F:\MAIL\TEST, 0217 | 00205 | 2=F:\MAIL\E20-343, 0134 | 03435 | 1=F:\MAIL\BATMAN, 0135 | 02034 | 1=F:\MAIL\RETURNS, The only changes you'll have to make is edit the "EX=" to "E1=" and edit the "IM=" to "I1=" then go and put a "1=" in front of all your message areas in the hubid.CNF file. The way the above example file would work, any mail from your system for the 3, 134, and 135 conferences will have a "Tranquility Base..." tagline appened to it. Any outgoing mail in the 217 conference will have "The Great American Tokad" tagline appended to it. 2. All registered users of BGQWK are now registered users of BGNET! BGNET will check for a valid BGQWK registration in the BGQWK.KEY file and if it finds it, you'll be registered. Remember BGNET and BGQWK look for the BGQWK file in the LANPATH (if you have one), or the GTPATH (if you don't). 3. BGNET now verfies that both the GTPATH and DOS PATH exist before continuing with the initialization. 4. BGNET was not loading all conference information from the CONTROL.DAT file properly (it never loaded the last conference), and, in some cases, caused certain conferences that should have had net status marked without it. Special thanks to Bob Wallace for identifying this. 5. The work directory will now be called \BGNETpid.WRK. The swap file name will be BGNETpid.SWP and the new log filename will be BGNETpid.LOG where "pid" is your LAN pid number (it'll be "0" if you don't have a LAN). This is the same convention BGQWK uses (except NET is replaced with QWK). 6. Messages with GT's internal ";rep" commands in them are filtered of the ";rep" component while exported. 7. This copy of BGNET.EXE is not compressed with DIET. You may want to compress the EXE file with DIET, PKLITE or another EXE compressor to save space. BGNET 1.0 BETA 9 WED 29 JUL 92 -------------------------------- 1. Tony Reynolds reported a problem with BGNET importing packets made with the MarkMail door. A fix for this problem has now been put in place. 2. A few people reported problems with BGNET running PKZIP. I have no idea what could be causing that, but BGNET now puts a little debug information to see if we can find anything out. BGNET 1.0 BETA 8 WED 22 JUL 92 -------------------------------- 1. FINALLY --- BGNET now utilizes EMS 3.2/4.0 or disk swapping when shelling to run PKZIP/PKUNZIP, etc to give you every bit of memory you can get ... when shelled, BGNET only uses about 3K of memory giving the rest of your conventional memory for the child program. 2. FINALLY --- BGNET will now create a LOG file detailing what exactly is happening. With this, there are too new command line options: 'O', when used, will DISABLE logging. 'P', when used, will PIPE logging into the GT.LOG file. Obviously, the O and P command line options CANNOT be used at the same time. Remember how to specify command line options? BGNET hubid /x:options d: (Where "x" is E, I or R and "options" are the indiviual command line options you wish to use smushed together). Example: BGNET c-tech /i:kp5 f: Would run BGNET for the C-TECH hub in IMPORT mode using F: as the work drive. The "kp5" would indicate to kill protect ('K') incoming messages, pipe ('P') all logging information in the GT.LOG file and use GT 15 style message bases ('5'). 3. A status line has been added that shows the hub id, mode of operation, MES or MSG compatability, EMS/disk usage amount, and registration information. 4. A bug in the last beta ... If NETFLAGS.DAT existed, BGNET was having a cow trying to read the file since I "fixed" it in beta 7, <grin>. There's still more to come ... Stay tuned, same bat time, same bat channel. BGNET 1.0 BETA 7 THU 16 JUL 92 -------------------------------- Oh No! Another BGNET release in just two days! AHHHHHHHHHH! :) 1. If seems as if some mail doors are not including the NETFLAGS.DAT file for net status information, but rather are putting the information in another place. This other place is now checked. If BGQWK reports that the packet does not have net status and you are positive your hub sysop has granted you net status, please call me at 713-893-9320 and let me know. It seems as if there is not really a "standard" for net status. If anyone knows any other QWK door authors that know about net status, please let me know so I can try to get in touch with them. 2. Some cosmetic changes (when importing, the actual conference names are now read in from the CONTROL.DAT file). Again, this is just a quick bug release ... many more features will be coming soon to a BGNET near you ... BGNET 1.0 BETA 6 TUE 14 JUL 92 -------------------------------- It's been about two months since the last beta release of BGNET and that's been surprising because I just found a whole slew of nasty bugs. I've been so busy with BGQWK lately I haven't had had much time to work on it, but hopefully that will change now. 1. Major problems with the status status identification logic: it wasn't working at all! Now, the NETFLAGS.DAT file will be read by BGQWK after unpacking the MESSAGES.DAT file from the .QWK on an import run. You can not import messages into conferences you aren't granted net status for. Leave me messages in E02/758 (BG Support) if this seems to be causing problems. I've examined a few net status packets, and none of them seem to work the way they are supposed to, <ugh>. 2. Support for registration keys is finally back. If you sent in a BGNET registration, you can call my board and open door four to pick up a combo BGQWK/BGNET registration key. The file name will be BGQWK.KEY (yes, that's not a typo, even if you have NOT registered BGQWK). 3. The name of the work directory will now be \BG$NET$.pid rather than \BG$WORK$.pid so as to not confuse work directories with BGQWK and BGNET. (I'll probably end up changing BGQWK's work directory to \BG$QWK$.pid in BGQWK Beta 33). 4. The "dummy packet" identification scheme was pretty much messed up big time. I've corrected it and done a little fine tuning to make detection quicker than before. I also noticed a SHARE violation if this happened, and that has been corrected as well. 5. Some minor cosmetic changes. This has been a mainly bug fix release. I still have many many more things to do with BGNET such as adding EMS/disk swapping support, support for 'kludged' line entries, etc. I'll get to it soon. BGNET 1.0 BETA 5 TUE 19 MAY 92 -------------------------------- 1. Several new conference options have been created for help with people trying to pick up FidoNet echos. New options: S - strip high bits on characters on export A - translate ANSI <ESC>[ to `[ psuedo-ansi on export F - use one line export tag line rather than two, example: without F -> --- ■ BgNet 1.0ß1 ≈ Tranquility Base - Houston, Texas with F -> --- BgNet 1.0ß1 - Tranquility Base - Houston, Texas To use these options, like BGQWK, place the letters of the options you wish to use for a conference after the comma. Example: -----+-------+[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] 0041 | 01443 | D:\MAIL\TEST,SAF 0040 | 01455 | D:\MAIL\TESTII 0039 | 01443 | D:\MAIL\LANTEST,A 2. Some users have requested that there be a way to tell BGNET *not* to create a null packet when no outgoing messages are available. I have added a command line option to do this, but I wouldn't recommend doing this. I like the way the null rep packet logic works. To force BGNET to *not* create an empty rep packet when no outgoing messages are available, do this: bgnet tranquil /e:n f: where "tranquil" is board id (looked up in TRANQUIL.CNF file) and the /E:N means export messages and do *not* create empty packet and F: is the work drive used. BGNET 1.0 BETA 4 SUN 3 MAY 92 -------------------------------- 1. Jim Kreyling discovered the TOMCAT mail door did not like packets created with BGNET because the header of the REP .MSG packets were padded with null characters rather than spaces. 2. Douglas Pippel discovered that imported messages with psuedo-ansi codes, `[, were not being transformed into the true-ansi codes, <esc>[. BGNET 1.0 BETA 3 WED 22 APR 92 -------------------------------- <GRIN> 1. Well, Douglas Pippel informed be that BGNET was bombing out if more than so many message bases were used. I saw this problem with the /e export function and fixed it, but forgot to check it in the /r reset and /i import functions. Those functions should now be fixed. BGNET 1.0 BETA 2 TUE 21 APR 92 -------------------------------- 1. When imported messages BGNET was continuously "saving last exported pointers". This was only supposed to happen after all messages had been imported, not after everyone. Fixed. 2. The number of messages imported is now displayed. 3. BGNET was suffering the same problem TNet was suffering when exporting mail. I kept opening numerous MESSAGE.CTL files and forgetting to close them resulting in a too many files error. This is now fixed on export. 4. When importing messages, if the QWK header has the net tagline flag marked as true, BGNET will not add the "import tag". I believe this is what other QWK network utilities do. BGNET 1.0 BETA 1 SUN 19 APR 92 -------------------------------- Welcome to an all new beta test. Because TNet will no longer support the UTI interface, I have decided to write my own QWK network message tosser for GT Power systems. (This program essentially does the same thing as GTQWK aka MERLIN). I have tested this somewhat but not much at all. I canalbalized many of the routines from BGQWK, so if BGQWK didn't give you any LAN problems, this shouldn't (in theory). This supports GT 15 and beyond just as BGQWK does. Since I have decided to start this project, any reference to "TNet" and "UTI" in the original BGQWK.DOC file are now obselete and will be replaced at a later date. Well, how do we use this thing? I've tried to make this as easy to use as possible, so here is the example syntax: BGNET hubid /x[:options] d: ...where "hubid" is the eight letter identification used by the hub on its QWK and REP packets. where "/x" can have the following values: /e export (bag messages) /i import (distribute messages) /r reset (reset last exported pointers to highest message number) ...where "d:" is a drive letter for the work drive. A temporary directory will be created (d:\BG$WORK$.pid) the same as used in BGQWK. (This is okay since BGQWK and BGNET will never be used at the same time on one specific node). If you have a RAM drive, I would highly recommend you use that. ...where options can be: 5 use gt 15 message format (individual msg files) k kill protect incoming messages Here's my batch file used to send and receive mail for TexasNet: @echo off del c:\gt\specreq\hopper.qwk bgnet hopper /e f: copy c:\gt\uploads\hopper.rep d:\relay\backup %gt% hopper.scr *xxxx-xxxx if exist c:\gt\specreq\hopper.qwk goto success echo *** COMMUNICATIONS FAILTURE WITH TEXAS NET HUB *** goto end :success copy c:\gt\specreq\hopper.qwk d:\relay\backup bgnet hopper /i f: del c:\gt\specreq\hopper.qwk del c:\gt\uploads\hopper.rep :end cd %gtpath% The way this batch file works is like so: a. delete any old .qwk file in my downloads directory b. export any new messages c. copy this new (or updated) rep packet into my backup directory d. run gt and execute the script to transfer the rep packet and download a new qwk packet e. check to see if we actually downloaded a .qwk packet ... if not, exit the batch file with a communications failure if so, continue... f. copy this qwk packet to my backup directory g. import the packet h. delete the .qwk packet and .rep packet from their directories Notice that I do not delete the original .REP file if a communications failure occured. When BGNET is started in export mode, it will check to see if a .REP file already exists. If it does, BGNET will add any new outgoing messages to it rather than overwriting it, so it will be your responsibility to delete the .REP if the transfer was successfully. If you use my batch file as an outline for yours, this should be handled automatically. So, what about the config file? Here is my C-TECH.CNF file that BGNET uses when I want to send/receive GT Power mail from Russell's board: im=001/070: Computech ex=001/040: Tranquility Base - 713-893-9124 - Houston, Tx -----+-------+[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] 0006 | 01389 | D:\MAIL\E10-037 0003 | 01237 | D:\MAIL\E02-758 0001 | 01779 | D:\MAIL\E00-001 0010 | 00779 | D:\MAIL\E10-009 0011 | 01119 | D:\MAIL\E01-009 0012 | 00220 | D:\MAIL\E20-002 0013 | 00007 | D:\MAIL\NETMAIL NOTICE that the config file is called C-TECH.CNF (not BGNET.CNF)! BGNET looks for this file in the directory that your USER.CTL file is kept in (lanpath on LAN systems, GTPATH otherwise). IM= is the import tagline (which is added to incoing messages). EX= is the outgoing tagline (which is added to outgoing, exported messages). The first column of numbers is the number of the conference at the Hub system your calling. Note their are FOUR placeholders not just three as in the BGQWK.CNF file. (This is because on some PC Board systems, some people have up to 8192 conferences!) The second number is the last exported message number. This number will be automatically mantained by BGNET as needed. I suggest setting it to "00000" when first installing BGNET. And, the third row, as you can probably tell, is the pathname to the message base on your system. Well, that's about all for now. This program was put together very quickly so it's probably full of bugs. Russell has been out of town, so I haven't had a chance to do any alpha testing. The display is not pretty---pretty much just gives you raw information.