Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
|  Message 1106  |
|  Janis Kracht to Ulrich Schroeter  |
|  MakeNL v3.4.1 Release  |
|  03 Jan 14 13:44:20  |
 Hi Uli! >> Hi Ward, >>>> Discussions are underway on dealing with Marc's other issue with >>>> MakeNL; he feels that there should not be an age limit on segments. >>>> The original Ben Baker version of MakeNL would only go back 2 weeks >>>> before the upcoming week; the current MakeNL_NG release goes back 6 >>>> weeks before the upcoming week. >>> I have segments that go back years and they don't cause a problem. >>> REGION21 (Norway) dor example dates from August 22nd 2011 and its >>> full name is REGION21.238. Region-38 (Yugoslavia etc dates from >>> Jan.4 2011 and is named REGION38.077, so there even isn't any >>> serious correlation between the file-production date and the Julian >>> date. >> Interesting.. over here, REGION21.238 would have been renamed to >> REGION21.003 this week upon running Makenl for Tuesday's zone >> segment.. geez.. >this is, what I've also still wondered once got aware of this processing schem > ... after a while Ward and me discovered the difference in > defining the segments mask in the makenl.control file Ok, this makes sense as I mentioned, thank you. > with segment.* the strict daynumbering schema and automatism will be >skipped. The segment will be processed, but nothing happens with the daynumber > extension update > so there are some advantages and disadvantages of each processing method > that makenl offers Yes, I can see that. I'll mention this to Marc Lewis, R19C. It may be his whole problem with makenl not 'seeing' older segments. Let's hope :) Take care, Janis --- BBBS/Li6 v4.10 Dada-1 * Origin: Prism bbs (1:261/38) |
[ << oldest | < older | list | newer > | newest >> ]