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, [. BGNET 1.0 BETA 3 WED 22 APR 92 -------------------------------- 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.