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)