Hello mark!   
      
   Sunday November 04 2012 16:01, mark lewis wrote to Andrew Leary:   
      
    KvE>> Had the host segment been processed, by a current makenl, then   
    KvE>> DOWN would have been converted to "Down" and the line a valid   
    KvE>> entry.   
      
    AL>> No, the line in question is not a valid entry, as the standards   
    AL>> are currently documented.   
      
    ml> isn't that an ugly oversight?? most *C's will simply alter the   
    ml> existing line and add or change the first field without editing the   
    ml> rest of the line... "Down" should be allowed with "-Unpublished-" as   
    ml> "Hold" and "Pvt" are...   
      
   Personally, I agree that Down, -Unpublished- should not be flagged as an   
   error. To that end, I will be drafting a proposed update to FTS-5000.   
      
    ml> then there's the problem of coding to the specs when the program being   
    ml> coded is the one that sets the specs which are then documented by a   
    ml> completly different body that has nothing to do with the program... so   
    ml> i say that makenl-ng should not "code to the specs" in this particular   
    ml> case but it should allow "Down" with "-Unpublished-" and let the specs   
    ml> catch up... that'll fix that...   
      
   That is the quick fix, although at some point the logic error in the code   
   needs to be tracked down and fixed.   
      
    ml> now, with all that said... i just tested using the following versions   
    ml> of makenl... the numbers in parenthesis are the actual file dates of   
    ml> the binary on the disk...   
      
    ml> MakeNL -- Version 2.51 -- Jun 14 1992 16:55:25 (28 Nov 1999 y2k patch)   
    ml> MakeNL -- Version 2.51 -- Jun 14 1992 16:55:25 (16 Jun 1992)   
    ml> MakeNL -- Version 2.50 -- Feb 11 1991 11:54:28 (12 Feb 1991)   
      
    ml> all of them *DO* allow "Down" with "-Unpublished-"... no bitchin',   
    ml> gripin', or complainin'... i manually checked the output file and they   
    ml> were all exactly the same... this indicates a problem with the current   
    ml> code that needs to be fixed so as to conform to the old version(s)...   
    ml> that takes case of one problem...   
      
   At one point I intended to research this; you've saved me the trouble.   
      
    ml> this also indicates that something is not right with the specs... at   
    ml> least in this particular case anyway... this needs to be brought up   
    ml> "over there" and fixed as well...   
      
   Most likely, nothing will happen on that front until after the FTSC election   
   is concluded.   
      
   Andrew   
      
   ---   
    * Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)