Subj : FastLst 2.02
To   : Mike Luther
From : Bob Jones
Date : Sun Jul 22 2001 10:26 am

BJ> I've been using QNode.  I'm looking for something that
BJ> will allow me to compile newer options, such as IP and
BJ> DNS information into the compiled nodelist, so that I
BJ> can have binkley "dial out" on VModem ports in
BJ> addition to handling POTS traffic.

ML> Likewise.

Ok....  You haven't "solved" it either.  :(

ML> On the list of some-day-over-the-rainbow, is a utility
ML> that could take the ASCI version of the NodeLists and
ML> simply parse it looking for the magic byte patterns.
ML> When it came to that .. I'd simply plug it the way
ML> needed for Qnode etc...

<GRIN>  I believe I could play the needed games if I had time and wanted to.
I've seen OS/2 REXX stuff on your board for handling the Version 7 compiled
nodelist files, if I remember right.  So, it is doable....

ML> If I recall this all right when I was thinking about
ML> it, I either had to prang the NodeList to make it work
ML> with Ray's SIO easily, or, I had to convice Ray that he
ML> should modify VMODEM to accept a "-" mark as a "."
ML> mark,or, I had to somehow get the FTSC to let us modify
ML> the NodeList formula so that we could carry the "."
ML> mark directly in the thing for the purpose.

As you mention elsewhere, Ray is working on SIO again.  Maybe you could re-ask
him about making a change to VMODEM to support '-' in addition to '*' as a
substitution for '.'.

But, that doesn't solve the "current" way that most nodelist entries are now
being made.  You now need to parse (a) the phone number (for "000-", which is
on the virge of going away), (b) the BBS name field for a real DNS entry to
look up, and (c) tagging on the DNS or IP info in one or more user flags.  So,
it gets interesting to parse the various options and come up with the "correct"
information to use.  I've yet to see any nodelist "compiler" handle these
options....

ML> I found out that some NodeList compilers keep a CRC
ML> checksum on the final source for the thing and what it
ML> produces.  They would tell me that there was a CRC
ML> error in the NodeList when I hand edited it!  But it
ML> never seemed to make any difference and ran anyway both
ML> in BINK/MAX and BBBS here.  So I wound up thinking how
ML> to patch this or that...

Yes, the CRC is a needed item to make sure you don't have a corrupt nodelist.
Any edits to the raw nodelist file is very likely to corrupt the CRC value.
[Yes, you *could* caculate a set of changes to get a good CRC, but that isn't
worth it for your purposes.]  As to what you were doing, as long as you left
each line in the file as a line, without adding or deleting any lines, you can
continue to get away with applying nodediffs.  You might have to re-edit the
nodelist after applying the diff *if* one of your edits was wiped out by a node
you had change having updated their list entry.....  <grin>....  You may have
to tweak or change your nodediff editor(s) because some of the code that
applies nodediffs I believe won't apply the diff if the CRC isn't correct to
start with....  Other diff programs will apply it (and maybe warn you that the
CRC is bad).

ML> Your thoughts?

It's about time for someone to take a publicly available version 7 nodelist
compiler and update it for use with the current nodelist flags so we can get
our Binkley programs talking both POTS and TCP/IP at the same time.....

Oh, well....  I seem to recall the Linux crowd has Fastlst compiling on that
platform.  That may be the best spot to get a free nodelist compiler updated
for OS/2....  And would support (my eventual?) usage of a Linux based system.

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)