ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RA / MULT200.ZIP / MULTNODE.DOC < prev next >

Wrap

Text File | 1991-12-11 | 31.9 KB | 619 lines

****** MultiNode Batch File Setup for 3 Nodes ****** *** 2 "Live" nodes and 1 "Local Only" node *** Copyright 1991 by Mark Lewis All Right Reserved in Time and Space first things first <sigh>...... **** LEGALITIES **** i do not guarrantee that the batch files and sample screen dumps contained in this .ZIP will work _perfectly_ on your system. the .BAT files and samples in this archive are provided as is without warranty of any kind, either expressed or implied. the only thing guarranteed about the files included in this archive is that they will take up diskspace. if you find that they do not serve your purposes, delete them. it's that easy. if they break themselves on your system, you own both parts and cannot hold myself liable for any damages to you or your system. this includes downtime and is not limited to any monies lost due to downtime. also, these .BAT files and the associated utilities mentioned *CAN NOT* and will not cause *ANY* damage to your hardware or equipment! ***** REGISTRATION ***** now, don't take this part the wrong way<grin>.... if you find that these .BAT files and/or samples help you in your quest to become a multinode system, all i ask is that you NetMail Mark Lewis 1:275/50 and let me know that you are using the basics outlined or the files included in this archive file. this way i will know that others are interested in what i can provide and will encourage me to continue the development of this and other items/programs that may help you in the development of your system for the use of your members. after all, what's the cost of a phone call compared to what you can make and/or provide for the members of your BBS? now that that is over with... on to the real stuff.... *** the REAL stuff *** you will, in most cases, need to modify these files. before doing so, make sure you are working on a *copy* not the originals. i cannot provide help on code that has been modified without knowing what modifications were done and how they are being implemented. the first modification most likely needed will be the drive and systems directories for RA and FD. the included BBS.BAT runs everything from our C: drive whereas our test site unit runs everything from D: drive. if you stick with the "basics" and use <DRIVE:>\RA and <DRIVE:>\FD as your system directories, you will find modification much easier. you will need a few utilities for these .BAT files to work correctly... a copy of DTR.COM and AT.COM will prove invaluable to help in the control of your modem at 'critical' times.... like making sure the phone is offhook when tossing mail or updating the bulletins and such. another utility that makes 'life easier' is DVCOMAND. i found it in DVCO12.ZIP a couple of months ago. also used in this setup are DVACTIVE, DAYNBR, SYSNL, and SPAZ. DAYNBR is used to calculate the day of the year for some of the processing (the nodediff merging section), SYSNL is the nodediff merge program that i use, and SPAZ is a "universal" unarchiver. and DVACTIVE is a little utility i wrote to detect if we are running under DESQview. the following archives should have been received with this package when you FREQ'd it (if you FREQ'd MULTNODE or MULTINODE). if you didn't get them, you should try to find them locally or FREQ them from 1:275/50 as DVCOMMAND, DOSMODEM, DAYNBR, SYSNL, SPAZ. in this setup, DVCOMAND is used to delay operation of the .BAT file at key points.... it can also be used to open other windows in the background for 'event processing' which opens a lot of ideas (like tossing the mail in another window opened especially for it) for me<grin>. DVCOMAND is also used to reopen any FD nodes that may be down when we go to process inbound mail. you need to have your mail tosser configured and operating correctly so that you can just put the commands you use for it into the BBS.BAT file when you go through and edit it for your setup. this package was written using IMAIL for the echomail handling. i haven't tried any other mail processing utilities like GEcho or TosScan but, you can modify the BBS.BAT where necessary to handle any other mail processing utilities you might want to use. this package was also written using MBUtil for some of the messagebase maintenance. you might want to get a copy of MBUtil110. it does the same thing as RAMsg and has several other nice features. (MBUtil 120 should be out by the new year as of this writting) i have changed the way i am packaging this stuff slightly. BBS.BAT has grown to be rather complex so i'm now including two copies of it. one, BBS.BAT, is not commented, and the other BBSCMNTD.BAT, is COMPLETELY commented. i highly recommend that you print out a copy of BBSCMNTD.BAT and read through it so you can understand what is happening where and when. it's only about 15 (fifteen) pages ( the last one was only 9 -=B-) ) and there are some loopbacks that take place and are confusing at times if you don't have a printout to follow<<grin>>... one, in particular, that was fun to do, was the ability for node 2 to toss mail if a packet came in on node 1 while node 2 was online with a user and this has been expanded so that node 3 has this ability also. one major update to this release is the capability for any of the nodes to also handle the new nodediff files and the new FIDOnews file. it was too much of a pain in the arse to have to manually process them, so i decided to add that to this package. note that the inbound/outbound mail tossing/scanning, nodediff, and FNews processing takes place As Soon As Possible... in other words, they will sit in your inbound directory until all the nodes are free of callers... then, and only then, will the LAST node out take care of them. in the case of outbound mail, the BBS.BAT looks for the ECHOMAIL.BBS and NETMAIL.BBS files in your BBS's messagebase directory... if they, either one or both exist, then your mail processor's scanning function should be run. in the case of both inbound and outbound mail waiting for processing, the inbound mail packet is tossed before the outbound packet is created. when we have completely multinode aware Tosser/Scanners at our disposal, i will include another BBS.BAT file in this archive that doesn't have all these loops controls and semaphore lockout files. at that time, being a multinode mailer/bbs system will also be a *lot* easier (i think). ok.... now on to the rest of the setup.... directory setups... with this new release of my MULTNODE package, we need several new directories that weren't necessary or mentioned in my previous releases. so i decided to include a tree structure in this version to help you see how this set up works. this is pretty much a generic setup and will work for almost any environment. below is a tree structure that will show you the relationships of the directories. here is a basic list of the directories and their purpose in the set up. RA -- this is where all the RA executable files and overlay files go. you will also have some config files in here. i also have almost all my bbs utilities located in this directory as well as the .BAT files for all the doors i run. RA\N? -- this directory is where you go to run FD and RA from... any files needed by RA will be created in this directory. FD will find and use all it's files from the FD\N? directory. it can do this because the .BAT file tells it to look in there for it's files. some of your doors and utilities may need to have seperate configuration files for operation by each node. in this case they wil probably have to be in this directory also. RA\MSGBASE -- this is where your message base and userbase files are kept. RA and any utilities that manupilate the messagebase or userbase files will probably need to be told to look here for them. there are some utilities that will look in your RA config files to find the directories they need. in those cases, they will need to be told to look in the RA\N? directory for the CONFIG.RA file, which should then direct them to any other directories they need. RA\MENUS -- this is where you have all of the menus for your setup. with RA's multiple language support, you will probably want to have seperate directories under this one with the required files for each language. this is to keep them from getting mixed up and to make editing and modification easier. RA\TXTFILES -- the same thing goes for this directory as for the menus. in some installations, there will probably also be another directory for each languages questionaire files. FD -- this is where you put all of FD's related executable and overlay files. FD\N? -- this is where all of the files are created and stored for each node. each FD node will have it's own complete setup in it's own directory and will look in it's own directory for it's control files. FD does not perform like RA in that it will not share any configuration or control files like RA does. FD\N?\PACKET -- this is where each FD node will put and maintain it's own control-packet files. these little files are created and maintained each time FD rescans the netmail directory looking for any outbound mail for the current event. this directory is NOT the same as the directory where your tosser will create the new outbound mail bundles. this directory is for each FD node's own use and should not be used by any other program or node. this directory CAN reside on a RAM disk. FD\NODELIST\SAVE -- this directories only purpose is to save a copy of last weeks nodelist before we process this weeks new one. this is in case that something happens and the processing gets FUBAR'd and your system is unable to use the newly made nodelist. it's a HECK of a lot easier to just copy last weeks from here instead of having to go download the whole thing again. -=B-) FD\NETMAIL -- this is where all your *.MSG netmail files go. this directory is shared by all FD nodes. FD\FILES -- this is the directory where FD receives all inbound mail bundles and files that you have FileREQuseted. FD\FILES\NEWS -- this is the directory that BBS.BAT will unarchive each weeks FIDO news into. personally, i read the FIDO snooze and do not really want to wait for it to be unarchived each time i get ready to read it. FD\PACKET -- this is the directory where all your outbound mail bundles are put by your mail tosser. FILES -- i have all my downloadable files in directories off this one. i like keeping everything grouped together and under "headings". FILES\DIFFS -- this is the directory where i put all the nodediff and nodelist files that i keep on my system for download. this is the directory that BBS.BAT is written to use when it does it's new nodediff processing. LOGS -- this is where i keep all my log files. each node creates and maintains their log in this directory. each node names it's .LOG file different from all the other nodes. ie: RA node 1 uses RAN1.LOG and RA node 2 uses RAN2.LOG, thus easily keeping them seperated and also easy to view. now that i've told you what they are, let's look at the tree..... C:\---|---RA----|--N1 | |--N2 | |--N3 | |--MSGBASE | |--MENUS-----|--ENGLISH | | |--<other language menu dirs> | | | |--TXTFILES--|--ENGLISH | |--<other language text file dirs> | |---FD----|--N1-----------PACKET | |--N2-----------PACKET | |--NODELIST-----SAVE | |--NETMAIL | |--FILES--------NEWS | |--PACKET | |---FILES-|--DIFFS | |--<rest of your file areas>... | |---LOGS | |---<other directories>... now, this is NOT the only way to set up your multinode system. different people do the same things different ways. this is just the way that i do it and is only shown here to give you a better understanding of how everything fits together. it is also here to point out other directories that are used by BBS.BAT in a couple of areas in it's processing. ok, i guess by now you're saying, "Come on, man! Let's get on with it!" well, i guess you're right, so here we go... first, create the individual node directories (N1, N2, and N3) needed by RA. ie: D:\RA\N1 for RA node 1, ect... copy the CONFIG.RA file from your main RA directory into each node's <DRIVE:>\RA\N? directory. this is necessary only *if* you want to have _different_ system logon prompts, different colors and echomail addresses for each node. you can share the CONFIG.RA between nodes if you like. in the case of sharing the CONFIG.RA, you won't need to put a copy in each nodes (N?) directory. in our setup, we have a different POINT number for each of our nodes. and this, plus a few node specific prompts causes us to go with the seperate copies of CONFIG.RA. If you decide to share the CONFIG.RA, the command line parameters in the BBS.BAT will take care of the port being accessed by RA. the following are the things that need to be changed in RACONFIG for each node, in the case of seperate CONFIG.RA's, you will have to be in the _specific_directory_ for the node you are modifying before you run RACONFIG. also, note that any changes to the message areas, protocals, languages, or files areas are "global" for the nodes as these files are shared in this set up... with this in mind, you could have different file areas and message areas for each node, but that kind of setup is not what this package was created for, although it is very easily accomplished once you stop and think about it<<GRIN>>... 1) your address ie: 1:275/50.0 for your node 1 and 1:275/50.1 for node 2... if you want to run your other node(s) as POINTS off of your main node. *OR* you can get another node number and use that... ie: 1:306/23 and 1:306/28... (hope you don't mind the plug, Josh<<grin>>) *OR* you can use the SAME FIDO address for all your nodes. it's entirely up to you. personally, i like "advertising" the fact that the messages originated on a multinode system <smile>... 2) the modem port and the baud rate. note that in this BBS.BAT file, we use the command line over-rides to specify the port and baud rate in use for each node but it's better safe than sorry. 3) the logfile names.....i made a directory and put *ALL* logfiles there.. ie: C:\LOGS <grin>.. each node, FD included, must have it's own logfile.... ie: node 1 - FDN1.LOG and RAN1.LOG.. makes it easy, hunh?? <<grin>> 4) the RA system directory stays the same 'cause that's where all the other configuration files are... RA looks in the current directory for it's needed configuration files and if it cannot find them, then it looks at the environment variable(s) set in the N?.BAT startup file(s). 5) MOST important of all! tell RA that you are running multinode! now, as i have only used FrontDoor, this is the only one i can comment on.... create the N1 and N2 directories for each FD node. in each FD's SETUP, make the same changes as above. the environment variable, FD, gets set to the each node's directory. FD look's for it's .FD configuration files in each nodes defined system directory. just copy the needed .FD configuration files into the node directories and configure each as an individual installation. you can share the .EXE's and .OVR's and must have your main FD directory listed in your PATH. the inbound (file), outbound (packet), nodelist, and netmail directories are all shared. each node has it's own ROUTE.FD and node 2 doesn't send or poll for *any*thing but can receive mail or files and can also handle FREQs. you will need to make a control-packet directory for each FD node. i use C:\FD\N?\PACKET. tell each copy of FD to use this as it's packet directory. your mail tosser needs to be configured to use the C:\FD\PACKET directory and put the outbound mail bundles in there. FD rescans the netmail directory each time it comes online or when there is a change of events. it then creates control-packets in it's C:\FD\N?\PACKET directory. this directory can be on a RAM disk if you like. it's contents are recreated with each netmail directory rescan that takes place. each copy of FD has it's own SETUP.FD which contains the information specific for each FD node. the main thing here is the com port. each FD node also has it's own EVENTS.FD file for node specific events. FOR EXAMPLE, node 1 is the 'master' node. it exits at 6am to handle maintenance right after Zone Mail Hour is complete. node 2 might, at this time, go into a polling routine. or, another example.... ZMH... node 1 cannot have human callers during ZMH.... but who says that node 2 cannot have them, thus you could still have your BBS open 24 hours a day and still be within policy about ZHM access. you need to tell FD to Create the .BAT file under FDSETUP->MAILER->ERRORLEVELS. without this function, you will not be able to pass the Time to Next Event from FD to RA. this also keeps you from having to duplicate your events inn both RA and FD. node 1 is your 'master' node, if you will.... it does everything including all system maintainence. you may also have to tell each node to use the address of the other as an AKA if you run into problems with the second node not receiving mail destined for node 1 and visa versa... actually, this should be done anyway. node one is set up with your main address and is AKA your other addresses or point addresses. node 2 is set up with it's main address as your other second node address or your point address and its AKA your main address. now, put the N1, N2, and N3 .BAT files that came with this package in your path and the BBS.BAT in your main RA directory. make sure your DV, FD, RA, and IMAIL directories are in your path. make SURE that you also load SHARE at bootup. any other utilities you use should be in a directory that is in your path, also.... like the DVCOMAND, DVACTIVE, SPAZ, DOSMODEM, and DAYNBR utilities that you might have received with this package. the sysnl files i recommend putting in your nodelist directory so they can be accessed during the nodelist processing portion of the .BAT file. You DID edit the .BAT files for your specific directory structure, didn't you? if not, do that now and don't forget to change the echomail handler if you don't use IMail. make sure you also get the N1, N2, and N3 .BAT files! in DV, create PIF files for each node starting them with the .BAT file for that node.... below is my DV PIF file for my node 1....note that i do NOT specify a directory.... let the .BAT file control all movement<grin>... also, note that we do NOT say anything about using com ports. the use of the FOSSIL driver negates the need for DV to even know about that. if DV is told anything about the com ports, it seems to hamper the smooth operation we seek -=B-) if you run ANY doors or other software that does direct screen writes, you will need to say Yes to Writes Directly to Screen *AND* Virtualize Text/Graphics. the reason is that you will see some strange things on the screen. if you don't say Yes to Virtualize, then the system will revert to 25 line mode which isn't too nice if you want to see several tasks running at the same time. -- *NOTE* The Keys To Use On Open Menu *NOTE* -- these are what you use to open each node with. these also become the first two characters of the P.rogram I.nformation F.ile which, using the below sample, is named N1-PIF.DVP.... this is part is VERY *IMPORTANT*. in BBS.BAT the section that checks for any nodes that are down and brings them back online uses the SAME keys that YOU do to reopen the node in question! if you do not use N1, N2, and N3 as the keys to open each of your nodes, then you MUST modify that part of BBS.BAT to use the SAME keys that you do... ============================ snip ====================================== Change a Program Program Name............: RA Node 1 Keys to Use on Open Menu: N1 Memory Size (in K): 1 Program...: n1.bat Parameters: Directory.: Options: Writes text directly to screen.......: [N] Displays graphics information........: [N] Virtualize text/graphics (Y,N,T).....: [N] Uses serial ports (Y,N,1,2)..........: [N] Requires floppy diskette.............: [N] Press F1 for advanced options Change a Program Advanced Options System Memory (in K).......: 0 Maximum Program Memory Size (in K)..: 400 Script Buffer Size.......: 0 Maximum Expanded Memory Size (in K): 256 Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF Window Position: Maximum Height: 25 Starting Height: 1 Starting Row...: 24 Maximum Width.: 80 Starting Width.: 80 Starting Column: 0 Shared Program Pathname..: Data......: Close on exit (Y,N,blank)......: [N] Uses its own colors...........: [Y] Allow Close Window command.....: [Y] Runs in background Y,N,blank).: [Y] Uses math coprocessor..........: [N] Keyboard conflict 0-F)........: [0] Share CPU when foreground......: [Y] Share EGA when forgrnd/zoomed.: [Y] Can be swapped out (Y,N,blank).: [N] Protection level (0-3)........: [0] ================================ snip =================================== here is a screen dump of my RA node 1 directory... DV BBS | D:\RA\N1 >dir Volume in drive D has no label Directory of D:\RA\N1 . <DIR> 3-21-91 5:02p .. <DIR> 3-21-91 5:02p RABIMCFG 1 739 3-21-91 6:57p */part of RABIM BiModem interface RABIMPTH 1 63 3-21-91 6:57p */ " " " " " TIMELOG BBS 71 4-10-91 2:24a */created by each node FX-CHAT CFG 67 3-21-91 6:13p POPDOOR CFG 818 3-21-91 10:25p QUICKED CFG 532 3-21-91 8:44p */Quicked config different for nodes RAMAIL CFG 160 4-10-91 2:13a */RAMail config for this node RA-BIM CTL 150 3-21-91 6:55p */part of RABIM BiModem interface USA CTL 2576 1-14-91 4:01p POPDOOR DAT 8181 4-11-91 2:21a POPUSER DAT 191 4-11-91 2:21a QUICKED HLP 2784 1-25-90 1:10a */help file for Quicked, if used CONFIG RA 3186 4-10-91 1:38a */config file for this node DORINFO1 DEF 105 4-10-91 2:24a 17 File(s) 5957632 bytes free DV BBS | D:\RA\N1 > as you can see, you also need the config and control files for some of your utilities and doors in each nodes directory.... note that the main changes in these files are the same as for the RA config file.... port assignment (in some cases) and directory to find needed drop files... experimentation is the only thing here... also note that any doors you run might need the DORINFO1.DEF and/or the EXITINFO.BBS file(s) copied into their working directory... here is a prime example of using the environmental variables that are set in the N?.BAT files and in BBS.BAT..... here is a sample from my ACFiles .BAT file that i had up for testing. note that any single node doors you run will need to use semaphore files to lockout any other node that may try to access it while it's in use. ================================ snip =================================== d: //* make sure correct drive cd\ra\acfiles //* goto the directory if %port% == 0 got regl //* check for local mode type d:\ra\helpreg.txt > com%port%: //* display "help register" to user goto regend //* jump over local display stuff :regl type d:\ra\helpreg.txt //* display reg text locally :regend dvcomand wait 30 //* delay 3 seconds for reading if exist imup.txt goto oops! //* check for lockout file rem > imup.txt //* create lockout file copy d:\ra\%node%\dorinfo1.def //* copy needed drop files acfiles //* run door del imup.txt //* remove lockout file d: //* go back to bbs drive cd\ra\%node% //* goto correct node directory goto end //* goto end of .BAT file :oops! if %port% == 0 goto oops!l echo OOPS! > com%port%: echo I'm sorry. Someone else is using this door right > com%port%: echo now. Please try back in a few minutes. > com%port%: echo Thank you > com%port%: dvcomand wait 30 goto end :oops!l echo OOPS! echo I'm sorry. Someone else is using this door right echo now. Please try back in a few minutes. echo Thank you. dvcomand wait 30 :end //* finished, return to bbs ================================= snip ================================== as you can tell above, the most used EV's (environment variables) are going to be %node% and %port%..... these are set in N?.BAT and in BBS.BAT respectively.....and also, this .BAT file makes use of a semaphore lockout file for a single node door.... multinode doors are much simpler<grin> and should include instructions for running them in a multinode situation. you CAN use %1 instead of %port% *IF* you put *B as the FIRST item after the .BAT filename in the RAMenu optional data line. ie: *C /C d:\ra\acf.bat *B *M with RA, if you are in LOCAL mode, the baud rate (*B above) will ALWAYS be 0. the above line will be sent to dos as ...... d:\ra\acf.bat 0 and the 0 will be substituted in the .BAT file everywhere %1 is used. further explanation of this feature of .BAT files is beyond the scope of this package. please refer to your DOS manual about replacable parameters in batch files for further information. RAMail is another door where using environment variables and replacable parameters is necessary. RAMail reads the config file specified on the command line. for each node this will be a different config file and a .BAT file is necessary to do this with if you keep each of the node's RAMail.CFG files in the same directory. next is a .BAT file sample for RAMail... ie: RAMail ramail%node%.cfg in the N1.BAT file, the environment variable NODE is set to N1. in N2.BAT, the same variable is set to N2. under DV, each task has it's OWN environment and is treated as if it was one individual machine. the above line, when accessed by node 1, will be sent to DOS as.... RAMail ramailN1.cfg ... for node 2 it's ... RAMail ramailN2.cfg in several cases, like RAMail and Quicked, you can also just put the .CFG files in each RA nodes directory and then just call it without having to use a .BAT file. in some cases, like above, you will have to have multiple config files for some doors. these doors will, then, either have an option for specifing which config file they should use (RAMail mentioned above does this) or will read the default config file... if they insist on reading a default config file, then your .BAT will have to copy the correct config file to the default config file name *after* locking out the other nodes and before starting the door.... there are working door .BAT files for several doors included in this archive. they can be found in DOORBATS.ZIP and can, in most cases be used as they stand. you will only need to modify the drive and directory calls. take a look at them and see how each one acts. for several of them, you will need to refer to the docs for that door to see what the command line params need to be that are passed to the .BAT file from the optional data line in the menu and then on to the door. WAR.BAT for Global War is one that DEFINATELY comes to mind. ** in closing ** this should give you a good headstart into a multinode setup.... you are free to modify the .BAT files, as needed, for *your* system. if you pass this .ZIP file on to others, it must be distributed in it's original ummodified form. you may, if you desire, convert this .ZIP to any other archive format... ie: .LZH, .ARJ, etc... if you find a unique problem or a fix for one that i haven't spotted and taken care of, i am definately interested in knowing about it.... in fact, you could send your mods/ideas to me if you like<grin>... and, i'm always interested in new ways to do things<<grin>> so if you spot a place where these .BAT files could use a little bit of streamlining, let me know. i would like to thank The Spirit of Support -=FBBS=- (1:275/20), Dawn Patrol (1:275/50), Nite Moves -=FBBS=- (1:275/22), the SysOps and CoSysOps, and the members of these three BBS' for their help, time and understanding during the development and debugging of this package. Without them, their help, wants, needs and ideas, i would never have developed this package to the extent that i have. Thank You All For Your Support! and happy multinodeing, .\\ark Lewis - CoSysOp at Large Netmailable at FIDONet 1:275/50.100 and available in these FIDONet EchoMail Conferences RA_UTIL RA_SUPPORT FDECHO the above documentation and included .BAT files brought to you by ... .\\ark's Advanced Batch File Programming Techniques -=B-) ***** Copyright Notices ***** FrontDoor Copyright 1989, 1990 by Joaquim H. Homrighausen and Peter Stewart Tosscan Copyright 1989, 1990 by Joaquim H. Homrighausen Remote Access Copyright 1989-91 by Andrew Milner and Continental Software IMail Copyright 1990, 1991 by Fabiano Fabris for Intuition Software DTR.COM Copyright 1985 by Donavon Kuhn and Jon Niedfeldt AT.COM Copyright 1985 by Donavon Kuhn and Jon Niedfeldt DVCOMAND Copyright 1989 by William E. Allen ACFiles Copyright 1991 by Ray Cole RAMail Copyright 1991 by Randy Blackmond Global War Copyright 1989, 1990 by Joel Bergen Gecho Copyright 1991 by Gerard van der Land DAYNBR Copyright 1985 by Ben Baker Spaz Copyright 1989, 1990 by Dan Thomson and Andrew Farmer SysNL Copyright 1988, 1989, 1990 by Constellation Software DVActive Public Domain Written by Mark Lewis