Revised: 04/26/88 Return to HOST between sessions. 04/11/88 To include errorlevel info, causes of multiple netmail calls, off hook simplification. TO: GT Sysop FROM: Jim Rash, 004/000 SUBJ: Netmail Help I am putting together this help file, primarily to answer some of the questions that I frequently hear. Most are the same ones that I have struggled with myself previously. This help is not intended to replace the documentation available with GT or Netmail, but to supplement it, and offer further explanation and suggestions. What I will do here is walk thru the various control files used for netmail and echomail, giving examples and options. Please note that the examples will be for a node operating as a LOCAL hub. I will note differences that may apply for a single, non-hub, node. Consider the example of NET/NODE 038/00. This LOCAL Hub delivers mail through REGIONAL Hub 004/000. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE: SCHEDULE.BBS NET=038 NODE=000 AREA=515 CITY=DES_MOINES NAME=PAGEMILL - Des Moines, IO. - (515) 287-1489 - Maxine Dudley 03:10-03:50 QUIT 2 04:00-04:40 QUIT 3 05:00-05:35 QUIT 4 05:45-06:50 QUIT 5 In the above example, there are four separate events scheduled to execute, at four distinct times. The advantage of doing a "QUIT" instead of a direct execution of a batch file, is that when you fully QUIT GT, you will be freeing a lot of memory that may be needed, depending on what programs you want to run during your netmail and maintenance routines. Now the ending times specified do not actually force the event to STOP. The time range will cause GT, if it should become active diring the time range, to START or RESTART the event. Once started, the event, or event's batch file (usually the time specified with MDRIVER) will control when the event STOPS. Therefore, the ending time in the schedule file need not, and should not, last as long as the event will actually take. Notice that there is not a QUIT 1. The reason is that when a Turbo Pascal program abends, it sets errorlevel to 1. I test for level 1 and use it to loop the GTHOST.BAT to reload GT. The "NAME" line serves as a "signature" on all echo and netmail messages originating from your BBS. It may be what ever you wish. For the QUITS to function properly, you must indicate each QUIT in the bat file that is used to start your GT software. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE GTHOST.BAT REM *** (comments for demo only) REM *** LOADS GT HOST FROM DOS :RELOAD C: CD\GT\BULLET default dir ECHO ATH0 >com1 Phone on hook GT1300 !xxxx C:\GT\SCR\HOST.SCR /S /R99 IF ERRORLEVEL 5 GOTO FIVE IF ERRORLEVEL 4 GOTO FOUR Errorlevel works with the IF ERRORLEVEL 3 GOTO THREE schedule.bbs QUIT times. IF ERRORLEVEL 2 GOTO TWO IF ERRORLEVEL 1 GOTO RELOAD Some put "WARMBOOT" here GOTO END :TWO NETM2.BAT Start NETMAIL session 1 GOTO END :THREE NETM3.BAT Start NETMAIL session 2 GOTO END :FOUR NETM4.BAT Start NETMAIL session 3 GOTO END :FIVE MAINT.BAT Start MAINTENANCE GOTO END :END In the above, we change the default dir to one that is either empty, or contains something harmless, like general bullets. I use a little trick at various places in my batch files to force my modem ON and OFF HOOK. This prevents the phone from ringing when a batch file is busy doing something and neither GT nor MDRIVER is available to answer. Next line loads GT and executes the script file "HOST" that places GT in the host mode. Use the /S to specify "small memory" which saves memory for external file transfer and DOOR programs. Also, use /R999 so the phone will be answered by the modem and not GT itself. Now when GT ends either by your ALT-X or by a SCHEDULED "QUIT", the batch file will check to see which errorlevel was set and branch accordingly. NOTE: the checking for errorlevel must be done in descending order because the test is a equal to or greater than condition. If everything is operating smoothly, the ONLY quit that the batch will ever see will be "QUIT 2". You will see why shortly. Assume that it is now 03:10 and "QUIT 2" has occured. The batch will branch and execute NETM1.BAT. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE NETM1.BAT (comments only) REM *** REM *** rev. 03/07/88 REM *** QUIT 2 - NETM2.BAT *** REM *** MBAGGER *** C: CD\GT ECHO ATH1 >COM1 Phone OFF HOOK DEL C:\GT\MAILOUT\B1*.* I delete certain files to DEL C:\MAILIN\FILEIN\NODE*.ARC save space or to prepare to DEL C:\MAILIN\FILEIN\NETCHAIN.ARC receive new files. COPY ROUTE1.BBS ROUTING.BBS Choose a routing file MBAGGER /D10 Run MBAGGER (ONCE DAILEY ONLY!) JDNET /S Supercharge multiple mailbags C: CD\GT ECHO ATH0 >COM1 Phone ON HOOK MDRIVER xxxx-xxxx 0315 0359 /D10 Run from 3:15 to 3:59 GTHOST.BAT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE NETM2.BAT REM *** REM *** QUIT 3 - NETM3.BAT C: CD\GT COPY ROUTE2.BBS ROUTING.BBS Choose a routing file ECHO ATH0 >COM1 Phone ON HOOK MDRIVER xxxx-xxxx 0400 0459 /D10 Run from 4:00 to 4:59 GTHOST.BAT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE NETM3.BAT REM *** REM *** QUIT 4 - NETM4.BAT *** C: CD\GT COPY ROUTE3.BBS ROUTING.BBS Choose a routing file ECHO ATH0 >COM1 Phone ON HOOK MDRIVER xxxx-xxxx 0500 0359 /D10 Run from 5:00 to 5:59 REM *** REM *** QUIT 5 - MAINT.BAT *** MAINT Execute MAINT.BAT Now, for more explanation of the above. The batch has several minutes of work to do before ready to start MDRIVER, so I protect my sleep by taking the phone OFF HOOK. I now clean out certain files. You may not want to do this. The "B1*.*" and "B2*.*" bags are a "record" for your own of the last TWO bags sent to EACH node. I delete these each night only to conserve disk space. In the example, we will run 3 session. Two echomail, with a regular netmail session in between. The only difference will be your ROUTING.BBS file. I will discuss this later. Suffice to say now that you will COPY a different ROUTE file to ROUTING.BBS before each session. Notice that the scheduled QUIT was at 3:10. This will allow 5 min. just to run MBAGGER and what ever else needs to be done to be ready for the 3:15 echomail session. That is more than enough time for most systems. You may want to adjust it to something closer to what it takes on your system. MBAGGER must be run ONLY ONCE a day, unless subsequent runs use MBAGGER /N to indicate "next" run. The /D10 switch tells MBAGGER that any bags undelivered for "10 days" should be moved to the "dead letter" dir. JDNET /S or the previous release GTNET /S will combine multiple mail bags for the same node into a single bag to save transfer overhead time. Now, the first sessions begins by placing that the modem ON HOOK and beginning MDRIVER. When the time specified in the MDRIVER parameter is reached the batch activates GTHOST.BAT and returns to HOST mode. The SCHEDULE.BBS immediately sees it is time to QUIT to session 2. NETM2.BAT copys the next version of routes to routing.bbs. and begins MDRIVER. Control again passes back to the HOST when completed. The final session begins exactly as above, except when fininshed, control passes to MAINT.BAT. I originally suggested a single batch file run your sessions non-stop with multiple MDRIVER sessions in the file. This can cause several porblems as I discovered! Imagine, for a moment, "what if", while netmail is running at perhaps 4:20, there is a brief power outage. When your system reboots and comes back up, if there were a single schedule event from 03:15 - 05:45 with a single batch file, it would start over, running MBAGGER again (NO, NO), and then would proceed to MDRIVER 0315 0359. This would result in a 24 hour wait as it is now 04:20! For this reason, and also should your system require a manual reboot for any reason, multiple scheduled quits, and multiple batch files will allow your system to restart at the proper place. Another problem is that with multiple sessions and a single batch is that some connect with a remote my occur near the end of a session, and continue until after the scheduled END of the next session (particularly if you are running a short, 15-30 min session). When the next MDRIVER in the batch file gets control, it will be AFTER its range, and it will WAIT for 24 hours until time to kick in! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE MAINT.BAT (comments only - remove them) REM ++++ MAINTENANCE rev. 03/05/88 ECHO ATH1 >COM1 Phone OFF HOOK JDNET /U UnBag any "Super Bags" MDIST Message Distribution c: cd\mailin\filein pkxarc /r node*.arc UnArc /replace new nodelist.arc copy nodelist.bbs \gt Copies where you want them copy node*.arc \mailout\fileout Make available for .FA copy netchain.arc \mailout\fileout copy gteco*.* \mailout\fileout del c:\mailout\b2*.* I don't keep "B2*.* bags c: cd\gt GTCTL prn Print current ANSWER.BBS del answer.bbs Delete/reset ANSWER.BBS CHAINEXT Pgm that prepares echo chain report REM on the 10th & 25th REM *** HARD DISK MAINT **** CHKDSK /F COM1 PHONE ON HOOK GTHOST.BAT Restart GT :FINISH You should be able to follow the above MAINT.BAT from the comments on the right. (Be sure to delete those comments before using the batch files.) A few comments must be made, however. The "INP" or "Input" file examples are found below. Mine are set up to handle all message areas. When you modify or create your own, they should be tested manually to be sure they do what you want them to do. The INP files are created much like you create LOTUS macros, if you are familiar with them. As you perform any task using any GT utility, write down everything you do, from inputs to an ENTER. These are then placed into a file and redirected into the utility control program. You can see what each will do by printing off the INP files and then running the utilities manually, typing what you see in the INP file as you go. That will give you the best understanding of them. For the backup option, be sure you have preset your defaults before you let it run automatically the first time. Also, unless you have a second hard disk to use for the target, or have very few messages, you may not be able to run backup automatically to a single floppy. The user maint not only deletes inactive users, but it also gives everyone in netmail a few credits each night. As for the disk organizer, I use DOG, and set it for "FAST" to de-fragment files only. It will take a few times, but eventually, the time required will be down to no more that 1-2 minutes per day. Once a month I run PC-TOOLS "COMPRESS" with "ascending, date order". This places all files subject to change near the free area of the disk. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE CTL1D.INP 2B1231 00 FILE CTL2W.INP 3stat01.JAN S101 3stat02.JAN S201 3stat03.JAN S301 3stat04.JAN S401 00 FILE CTL3W.INP 2760 2 YN0 790 0 YN0 81Y8330 NY042 2472 S08315 YY043 283180 NY044 28315 YY045 28315 YY046 28315 YY047 28315 YY048 28315 YY049 28315 YY0410 28315 YY0411 28315 YY0412 28315 YY0413 28315 YY0414 28315 YY0415 28315 YY0419 28315 YY0420 28315 YY00 FILE NET2W.INP 3STAT05 13STAT06 33STAT07 63STAT09.JAN 201 3STAT08.JAN 701 3STAT10.JAN 801 3STAT11.JAN C01 N00 FILE NET3W.INP 2921 YY2922 YY2923 YY2924 YY2925 YY2926 YY2927 YY2928 YY2929 YY29210 YY29211 YY29212 YY29213 YY29214 YY29215 YY29216 YY29217 YY29218 YY00 FILE CHKDSK.INP Y +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FILE ROUTING.BBS The primary difference between the ROUTE files used in each session is the "INBOUND" section. This section lists those net/nodes that you DO NOT want YOUR system to place a call to. You must be sure that any node that you take OUT of the INBOUNDS is avilable for a netmail session at the time your session is running. In the ROUTEING INSTRUCTIONS you have the option to specify "alternate" routings. This is NOT advisible in most cases for ECHO. It tends to waste MDRIVER time by requesting echo days that you may already have. An appropriate alternate for echos would be the sponsor, assuming that you collect your echo from only 1-3 sources, and do not normally contact that sponsor. It is best to limit your sources and not try to contact every sponsor direct. You would probably experience considerable delays in PCP and miss being able to connect and update frequently. This is not true for regular netmail routes. The proper use of alternate redirects may present an opportunity to shave some forwarding time off of some mailbags. Your PRIMARY redirect should be your assigned HUB in most cases. The exceptions are the nodes that you support and any other nodes that you connect to nightly for other purposes such as echo requests. These should have no redirect, but you should deliver to them directly. Each node that is redirected to your upstream hub could have alternates that would include the appropriate continental hub, regional hub, and local hub for that net. Alternate routings do NOT force a call to be made, but should your node come into contact with an alternate for any reason, then it would allow netmail to transfer. You must be careful to follow the "rules" and not try to redirect mail ACCEPTed for a node to itself. Generally, the "ACCEPT" should be used by HUB systems only. All others should use "FORWARD". There is a sample file, ROUTE2.BBS, included in this archive. It would be used in the examples previously covered by a local hub during regular NETMAIL. Note that the ECHOMAIL hours allow echomail in this example because local hubs in non PCP areas often collect echo for others in their local net, minimizing long distance calls. Finally, as for timing, Local Hubs may request their local nodes to begin their netmail sessions early, say 3:45 so the local hub can collect all outbound mail before the call to the Regional Hub. This will help to eliminate a second call for late collected mail. Multiple calls to the a node during a single session with no transactions may be caused by having that node both with an outound and with echo requests. The echo request will force the call by itself, and the outbound should be eliminated. Another condition that creates multiple calls with no mail, is requesting an echo (primary routing) that a system does not carry. Please refer to the "Echochain" report available from Rusty Stone (001/018) and participate in its generation. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Well, if I have missed anything in this that still causes you trouble, or if you see a mistake, let me know! -END-