Hi Kees,   
      
   Friday November 02 2012 15:12, you wrote to All:   
      
    KE>  For quite a while the following error shows in the Nodelist.   
    KE> ;E DOWN,779,RoadRunner_X,Grande_Cache_Alberta,Randy_Sommerfeld,   
    KE>         -Unpublished-,9600,XX,CM,V32b,V34,V42b,IBN:rrx.ca   
    KE> ;E  -- Invalid keyword -- 'FILES'   
    KE> ..   
      
    KE> Now for the feature request.   
    KE> Would it be usefull if higher level, e.g region or zone, processors   
    KE> would correct these lower level error, that are O.K. in de current   
    KE> makenl.   
    KE>   
    KE> One could look for ;E DOWN and chane it back to DOWN or Down.   
    KE> I can think of other errors, that are correctable, From the past I   
    KE> remember a case error in "Unpublished". Again an error that is now   
    KE> handled by makenl.   
    KE>   
    KE> Correcting errors like these can ofcourse also be done by a   
    KE> preprocessor.   
      
   this reminds me about a pointlist converter and checker project that   
   I've started over 20 years ago   
   It has some kind of AI installed   
   while checking in a first step field 8 (baudrate field) that probably has the   
   minimalist possible error rates to identify any field order mismatches   
   caused by   .  vs , errors or one or more missing , (often seen back in the   
   early 90's), or one missing field, or one field to much. Using the baudrate   
   field as the anchor point to validate each field seperately   
      
   With the pointlist checker I had identified over 50 potential errors   
   that can be all corrected, by sending a notification to the sender and correct   
   the segment at the next higher distribution level   
   eg special chars checking: checking for 0x00, 0x0A and other problematic   
   characters out of fts5000 allowed charset scope in distributed lines   
   Such a case we had in practice in Nodelist #035/2005 where the zone 4 segment   
   including such a char garbeled the diff distribution   
      
   I don't know if the FTS-5000 (5) content check has been yet implemented   
   within the makenl distribution, but it makes sense either way:   
      
   (from fts-5000.002 section 5. Content)   
   ..................................................................   
   For the remainder of this document, characters in the range 00h to   
   1Fh, plus 7Fh, shall be called "control characters," and characters   
   in the range 20h to 7Eh shall be called "printable ASCII."   
      
   Every line must be terminated with a carriage return (^M, 0Dh) and a   
   line feed (^J, 0Ah), in that order.  The file itself must be   
   terminated with a single EOF character (^Z, 1Ah), and no other data   
   following.  Future implementations should accept nodelists with the   
   EOF (^Z) character omitted.  No other control characters are   
   permitted anywhere in the nodelist.   
   ..................................................................   
   I've named it the fts5 or fts5000 charset test   
      
   Also I've seen other implementations, that distribute line endings   
   with a unix style line endings (fts-5000 defines  0Dh+0Ah a must)   
   so auto convert such line ending problems is another topic   
      
      
      
    KE> Regards,   
    KE> Kees van Eeten   
      
   regards, uli   ;-)   
      
   ---   
    * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)