Subj : MakeNL and how it works? To : Eric Renfro From : mark lewis Date : Sat Sep 05 2015 14:33:26 05 Sep 15 12:25, you wrote to All: ER> I'm trying to get into understanding just how MakeNL actually works. ER> For example, as NC, how would I get it to update just the network that ER> I'd be managing on a regular basis? ok... ER> I've taken examples from the provided hub.ctl from the documentation, ER> and modified it, but it just gives me, in a test result, a CRC of 000, ER> meaning there's no data there I'd guess. first off, what version of makenl? hopefully it is the latest ng version that is actively being developed and distributed... second, that hub.ctl is not for a hub as we might think of a hub as for mail and files... it is for a HUB node in the nodelist which is mainly for HUB routed inbound netmail... the NC is a hub in this sense and there may be other hub divisions within a net... the NC can manage the whole segment or they may have the hubs manage their little sections and send them to the NC... if you are going to be managing a whole net, you should probably start with the net-s.ctl file as that is for a ""small"" net... the net-l.ctl is for a ""large"" net that would employ the previously mentioned HUBs to delegate management of smaller segments known as hubsegs which the NC would process with the net-l.ctl file to build the netseg... there's several ways that you can do this, too... 1. for many years i just used the net-s.ctl file and in the data section, i manually created and edited the entries for each node... then i would run a test run and see of there were any errors... if not, then i ran it again to send the netseg to my RC... it was pretty manual and only done when a change was necessary... this is probably the most common net level style of operation in this day in time... 2. i also toyed around with using nodesegs where each node would send in their single line entry and be responsible for it containing the proper data... then my net control file simply included them... during the normal daily run, makenl tests and if a nodeseg was bad, makenl would send an error message back to the node and set that bad nodeseg aside... this style of operation is close to the large net and regional styles because it takes the input from downstream systems, tests it and sends back a notice that the segment is good or bad... as i noted at the start of this section, i toyed with this but never put it into real production outside of the test environment... 3. i have also used a combination of 1 and 2 where i have a Data section with some entries and then a Files section to bring in others... 4. a more elaborate version of 3 is what i'm currently using, though... i took a page from ward's playbook... he adds the year and daynumber to his Z2C entry... i thought this was a good idea because you could then easily see when that seg was updated and sent upstream... so i scripted something together to do the same for my netseg... the script builds my ctl file from a static header section, adds in the updated HOST line with the year/doy entry and finally brings in the static footer section... then makenl is run using that control file which then brings in the fairly static node entries file... with all that said, here's a rough small net ctl for ficticious net789... there's the host entry, the host's non-admin entry and one other node... ==== Begin "net789.ctl" ==== logfile n789.log loglevel 1 make network 789 outfile net789.seg submit 1:456/20 INTL netaddress 1:789/19 messages x:\ftn\netmail private ok allowunpub 1 alphaphone 0 baudrate 300,1200,2400,4800,9600,14400,16800,19200,28800,33600 copyright n789.cpy prolog n789.pro epilog n789.epi Data Host,789,Somewhere_USA,yourcity_state_USA,your_name,1-800-555-0100,33600,XA,V34,CM,ITN,INA:your.domain.invalid,IBN,IVM,PING ,19,your_bbs,yourcity_state_USA,your_name,1-800-555-0100,33600,XA,V34,CM,ITN,INA:your.domain.invalid,IBN,IVM,PING ,27,some_bbs,somecity_state_USA,some_name,1-800-555-0101,33600,XA,V34,CM,INA:your.domain.invalid,IBN ==== End "net789.ctl" ==== this is basically taken from the bottom half of Figure 2 in the original makenl documentation... we're managing all node entries in the bottom DATA section and generating a net789.seg file to send upstream to the RC... the MSG format netmail directory is where makenl will place the file attach message with the seg file for sending... in a BSO environment this netmail area needs to be processed by a mail tosser to pack the netmail out to the RC's address with the attached segment file... if you use an outbound filebox with binkd for your connection to your RC, you can throw away the file attach MSG file and just copy the net789.ctl file to the outbound filebox directory for binkd to send to the RC... this is akin to the way interbbs door game files are moved... the output of running makenl with the above control file looks like this... x:\makenlng\test> ..\makenlp net789.ctl MakeNL 3.4.1 (OS/2 32-bit) compiled with Watcom C on Oct 19 2013 10:57:21 MakeNL started No directory for master files specified -- using X:\makenlng\test No directory for output files specified -- using X:\makenlng\test Cmdline: X:\makenlng\makenlp.exe "net789.ctl" Using 'net789.ctl' in 'X:\makenlng\test' Begin processing 'net789.seg' -- 15:55, Saturday, September 5, 2015 Sending 'X:\makenlng\test\net789.seg' to 456/20 CRC = 06075 MakeNL finished (rc=0) since we did not specify the "-TEST" parameter, makenl went ahead and created the net789.seg file and attached it to a MSG netmail for sending to the specified 456/20 address of the RC... note that the parameters must start with a '-' (dash) and not a '/' (slash)... i suggest making it practice to always specify "-TEST" and "-PROCESS" when working with makenl... especially "-TEST" so that you can make sure there are no errors in the submission... once makenl has processed (vs tested) the file, it will keep up with it and will not send it again unless the seg file has actually been changed by an edit to the DATA section of the control file... there are other features and capabilities of makenl that can be quite handy as one advances in its use but i would guess that maybe 90% of the folks using makenl do it all manually like this... it does at least give a check to ensure that the data is not broken ;) if you want to delve in further, i'm available via netmail... )\/(ark .... No, Vienna sausages are not made in Vienna! --- * Origin: (1:3634/12.73) .