home *** CD-ROM | disk | FTP | other *** search
- Revision history for LISTCRCS:
-
- - I never thought such a simple utility would need a revision history,
- which only goes to show how cocky I was. <GRIN> The next utility I
- write *will* have a beta-testing phase...
-
- - Version 1.0 (initial release): Advertised to Region 12 *EC's, Binkley
- beta testers and QM beta testers. Initial motivation for problem was
- a potential bug report by one NEC in Region 12 in the behavior of
- Areafix.
-
- - Version 1.1: Added detection and flagging of existing collisions
- (translate: the tinkering bug bit me good...). Additional
- distribution: Net 167 file sharing area, called QUEDIST.
-
- - Version 1.2: Expanded the definition of "blank line"; the program now
- treats as such not only true empty lines, but also lines starting with
- a semicolon (";") or a dash ("-"). Thanks to a bug report from Bob
- Davis (1:106/114), I was reminded that my habit of using truly blank
- lines as visual separators was not as widespread as I first thought.
- The QM documentation does, indeed, mention the semicolon as a comment
- line flag. As for the dash, a remark by Raymond Beriau (1:167/305)
- reminded me that ex ConfMail users may have brought such lines with
- them. I now remember that *I* did keep such a line in my AREAS.BBS
- file for a while when I first tried QM. Thank you Raymond!
-
- Any other type of non-area, non-standard lines in your AREAS.BBS file
- may still produce "interesting" output (as in the old Chinese curse:
- "May you live in interesting times..." <grin>). I will let rule #1
- of data processing, G.I.G.O. (if you don't know what it means, ask a
- local friend), take care of such situations. As I believe I have now
- accounted for all documented line formats, and one old inherited
- (from ConfMail) format, (here goes: Open Mouth, Insert Foot... 8-), I
- do not expect to have to fiddle much more with this. Unless I get
- early problem reports from Bob, Raymond or anyone else to whom I
- will now send this version, this is what will be released in the SDS
- in a few days.
-
- - Version 1.3: In the light of what the present paragraph says, you may
- have a good chuckle when reading the rest of this file... If so, well
- have a good one on me! This will only go to show that I am, after all,
- very human, in that I can make the *dumbest* mistakes... It was just
- brought to my attention that EchoMail area tag names are
- case-insensitive (as if I didn't know it... ha!). It's just that I
- made the fatal assumption that everyone would use all UPPERCASE
- conference names in their AREAS.BBS file, but in fact there is no
- obligation of doing this. My thanks to Jan Ceuleers of 2:295/53 for
- pointing this out. This and some clarifications in my useless little
- errorlevel-testing batch file are the only changes between versions
- 1.2 and 1.3.
-
- - Version 1.4: 91/09/10 (Tuesday morning, in the "wee hours"... :-)
- In the time-honored tradition of many other FidoNet utilities, I am
- only documenting the changes for version 1.4 in this addendum rather
- than redo the original documentation file, mostly because I don't have
- a minute to spare, and I want to push this thing out the door and go
- to sleep!
-
- I wholeheartedly believed that the previous version (1.3) of this
- utility would be the last to see the light of day before QM either
- was fixed, or was made obsolete by some other program. Alas, this
- was not to be! John Souvestre (1:391/1) recently came to me (via
- NetMail... :-) with requests for additional features, both for
- himself and on behalf of Tony Davis, our ZEC. As they were just
- challenging enough for an evening of tinkering, I put them in,
- and here they are:
-
- - Two optional command-line parameters are now supported. The area
- name to test is now the second one, with the first being the name
- of the file containing the list of areas. That file name can also
- contain a drive and/or path name, if so desired.
-
- - If only a file name is supplied, version 1.4 will behave with it
- exactly as 1.3 did with zero parameters, i.e. it will check all
- areas listed in that file for a possible CRC collision, which
- would guarantee a cross-link. If two parameters are supplied, the
- second one is interpreted as the name of an EchoMail area that you
- wish to create, and which is checked for cross-links against all
- areas listed in the file referenced by the first parameter.
-
- - If no parameters are supplied, the file defaults to "AREAS.BBS",
- which must then reside in the current directory.
-
- - An additional format is supported, in addition to AREAS.BBS for
- QM and QECHO. The new format is popularly known, around these parts
- anyway, as FIDONET.NA (where NA stands for "North America"), as this
- is the name of the text-format forwarding list being used by the
- North American EchoMail backbone to list all backbone areas.
-
- - The logic by which the file format is identified now starts with an
- examination of the first line of the file. If that line contains
- the character '!' anywhere, the file is presumed (NO, I won't use
- "ass-u-me-d"...! :-) to be some form of AREAS.BBS listing, and
- further testing along that path is done, just as before, to
- differentiate between the QM and QECHO formats. If no '!' is found
- on that first line, the file is presumed to be in FIDONET.NA
- format. Comments and area descriptions will be ignored if present in
- a FIDONET.NA format file.
-
- - The program's output is now split between the DOS standard output and
- standard error streams. This provides the user with the ability to
- produce a brief form of report by the simple expedient of redirecting
- the standard output to NUL. What remains is then an abbreviated header,
- and only CRC collisions are listed, while non-affected areas produce
- no visible output. Now those people with the "too fast" computers, like
- John and Tony <grin>, will be able to use LISTCRCS without fear of
- missing important error messages as the output whizzes by on their
- screens! :-)
-
- - Hopefully, the HORRIBLE holes I had left on the errorlevel logic of
- version 1.3 (but that nobody ever reported to me...) are now really
- fixed!
-
-
-