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... 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..... .... 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) .