Hi Roy,   
      
   Wednesday January 01 2014 13:00, you wrote to Janis Kracht:   
      
    RW>  Janis Kracht wrote to Kees Van Eeten about MakeNL v3.4.1 Release:   
    RW>           No pseudo-French spellings, please!   
      
    JK>> After speaking voice with R19C yesterday, I was informed there is   
    JK>> still a problem with the OS/2 version of MakeNl in processing   
    JK>> segments. As I understand it right now with v.3.4.1, it  look   
    JK>> doesn't look for the most current Julian date for a particular   
    JK>> file name.  As I understand the problem, it doesn't process   
    JK>> segments older than 6 weeks.   
      
    RW> The burning question to that old segment business, why is he holding   
    RW> onto segments that are that old? If he mandates that a new seg be   
    RW> submitted per week or some other time frame we can work out with him,   
    RW> I think that most of the NCs in the region would submit them. We were   
    RW> all reluctant to do so because MNL wouldn't submit a new segment until   
    RW> the CTL file was changed. Now we know better by adding the keyword   
    RW> that makes it send an old segment with a new julian number.   
      
   there are to options for the receiving coordinator   
      
   a. an ordered submitting of new segments   -or-   
   b. a configuration option in the makenl control file -> cleanup   
      disadvantage: this requires a strict numbering schema   
      so a segment with daynumber .360 for friday nodelist .361 won't be   
      accepted :-P   
      
   but option b. exists, so the old segment .354 will be automaticly updated   
   to .361 on the receiving coordinators working directory   
   no requirement to send in a weekly segment.   
      
   There is problem: starting with the new makenl deployment, at the very first   
   time, all subsegments have to be in the timeframe of daynumbers makenl will   
   search.   
   Workaround: manualy rename the segments to the appropiate daynumber   
   This is a one-time job by the receiving coordinator   
      
      
    JK>> In Z1Regcon, we've been discussing Makenl_NG's problems with the   
    JK>> Z1 R17C and R19C who are still having problems, and Andrew I   
    JK>> believe is working on a fix...   
      
   what are the problems ?!?   
   nothing heard yet   
      
      
    JK>> R17C's problem may have been fixed by running a DOS version of   
    JK>> 3.4.1, we're waiting to hear about that.   
      
    RW>         R\%/itt   
    RW>  $ Origin: South Texas Hub - Gulf Coast Backbone (1:387/22)   
      
   regards, uli   ;-)   
      
   ---   
    * Origin: AMBROSIA - Frankfurt/Main - Germany (2:240/1120)