Hello Kees,   
      
   On Wednesday February 12 2014 19:20, you wrote to me:   
      
    KE>>>  Indeed and they may have more to worry about.   
    MvdV>> So let THEM worry about it.   
      
    KE>  Dn't worry, they probably do.   
      
   My point was: let's not try to do their job, let us do what we are here for   
   and just hand them the tools. In this case the tool of MakeNl.   
      
   A sensible strategy when buying or making a new tool is to see that it can do   
   more than what is needed at the moment. When you need a pump for the tyres of   
   your car and that car needs 250 kPa, you don't buy one that can do just that   
   and no more. You buy one that can do more, in case you need more in the future.   
      
   Let's upgrade Makenl to 1024 lines to comply with FTS-5000. It does not mean   
   that *C's must allow lines that long and if it is never needed, there is no   
   harm done.   
      
    KE>>>  These packages are however still maintained, so ugrades can   
    KE>>>  be made available any time.   
      
    MvdV>> I don't see the above as an argument against raising the max   
    MvdV>> for MakeNl to 1024.   
      
    KE> No, it is just a start of an inventory, of were changes are needed and   
    KE> where there a limitations, as the software cannot be modified. This is   
    KE> not aimed at Makenl, but at the use of longer lines in the nodelist.   
      
   Makes sense, but you are barking up the wrong tree. Here we make the tools.   
   How they are used by the *Cs is a different issue that belongs in an area   
   where the sysops can meet with the *Cs.   
      
    KE> It is wonderfull if all levels can produce a nodelist with long lines,   
    KE>   
      
   Decoupling Pvt and -Unpublished- was not the only reason for the MakeNl_Ng   
   project. Another and perhaps more important reason at the time was the 157   
   bytes bug. The old MakeNl CRASHED at lines > 157 bytes. Very Annoying.   
      
    KE> but if it fails on crucial systems on the net,   
      
   That remains to be seen. Where is the spirit of the old days when we just   
   tried it and saw what happened?   
      
    KE>  where is the gain?   
      
   157 bytes has been demonstated to be too short. The gain in allowing THIS tool   
   to handle longer lines is that at least with THIS tool we will not run into   
   that problem again.   
      
   What is lost?   
      
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MINGW 1.1.5-b20110320   
    * Origin: http://www.vlist.eu (2:280/5555.6)