Subj : follow-up on: NCs who've updated to MakeNl_NG To : Mark Lewis From : Ulrich Schroeter Date : Sun Feb 10 2013 15:32:23 Hi Mark, Friday January 25 2013 20:34, you wrote to Wilfred van Velzen: WvV>> Btw: I never noticed that makenl_ng didn't accept a segment WvV>> because of it's date stamp. I'm currently using 3.2.9b. Is this WvV>> a recent change? ml> it isn't the date of the file... it is the julian day of year ml> extension that is looked at... marC lewis explained this recently... ml> in my testing, if you don't use generic filenames for submission ml> files, then you won't see this problem... generic filenames as in no ml> extension defined in the config... they actually come with julian day ml> of year three digit extensions zero padded left (eg: 001, 019) WvV>> I think you should make the age limit check optional and the WvV>> period configurable (or remove it all together)... ml> then it won't be drop in replacable for the original makenl it is ml> derrived from, would it? ;) the main problem is, if you migrate from another nodelist compiler or starting from scratch and copy the master directory of your previously used compiler, you probably have old segment files with julian dates far behind the 3 weeks limit eg today we have .039 with a master directory copy of 5 segments, where 3 are quite actual (with extension .039) and two older segments with julian date extension eg. ..230 and .335 only the 3 new segments will be implemented. the 2 other "older" segments will be totaly ignored (-> this relates to a rejection) caused by the algorythm used, that if julian dates extensions is configured it calculates the 3 extensions from current date, this is .039, .032 and .025 only those segments with extensions will be searched for: .039, .032 and .025 If another segment with .230 and .335 is in the master directory it makenl complains: segment not found ok, this is step 1 in processing from scratch. Once you've renamed the .230 and .335 to .025 one makenl will find these segments and still renames all segments to current julian date extension in the compile run, this is .039 for both segments. In the upcomings week execution, the segments will be renamed to .046 (if no newer inbound segment will be sent in). Thats the way makenl keeps track on updates of older segments but for starting from scratch with older segments from copied over from another nodelist compilers master directory, this did makes me nuts, once I've started with playing around with the MakeNL_NG version, that complains about files not found where they are still there :-P so current algorythm x[1], x[2], x[3] = calculate current julian date extensions + 2 weeks before :loop i = 1 search for filename+extension(x[i]) found? yes -> stop no -> i++ if i > 3 stop else goto loop prevents whatever segments from inclusion, whatever older julian date fileextension they'll have In another project where julian date extension are an issue, I've switch to an algorythm, to first search for the filename.* then check for valid julian date extensions, then sort the files based on julian date extensions and date (probably using an admin line in the segment) eg nodelist for daynr ### if admin line is not available, using the filedate and compare it to the julian date extension for plausibilty eg .335 matches 30.11.2012 then sort it by date and using the latest segment This is quite some overhead, but best fits to the requirement to find whatever valid segment file with julian date extension can be found in a master directory If you want to extend the plausibility and validity check, you can also look for the makenl config definition -> Net 244 and check the referenced segment for a line starting with Host,244,.... :) ml> )\/(ark regards, uli ;-) --- * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120) .