Subj : MakeNL and how it works?
To : Eric Renfro
From : mark lewis
Date : Sat Sep 05 2015 02:33 pm
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...
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)
