I've always found it hard to understand the underlying thought behind the original error levels from the old MakeNl. And it seems like we are trying to maintain those even in our new version.

Alas, let's try not to break any batch files from 20 years ago, but really?

0 = Process mode - no errors encountered
1 = Process mode - no fatal errors encountered
2 = Process mode - one or more fatal errors encountered
3 = Test mode - no errors encountered
4 = Test mode - no fatal errors encountered
5 = Test mode - one or more fatal errors encountered
254 = MakeNL aborted - I/O error
255 = MakeNL aborted - Control file error

Why the separate, otherwise identical, levels for process mode and for test mode?

Anyway, we can leave that be -- even if I doubt that there are that many systems out there that actually uses those error levels -- but one level I would like is for "Unchanged output file will NOT be submitted".

When eventually the output file is changed, I want to know, so I can delete the old one (that at least for us in zone 2 has a different file extension on a
regional level) and hatch out the new one.

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://felten.yi.org (2:203/2)

Hello Bj÷rn!

25 Nov 14 05:27, you wrote to All:

Anyway, we can leave that be -- even if I doubt that there are that many systems out there that actually uses those error levels -- but one level I would like is for "Unchanged output file will NOT be submitted".

When eventually the output file is changed, I want to know, so I can delete the old one (that at least for us in zone 2 has a different file extension on a regional level) and hatch out the new one.

With the nodelist as small as it is now, why not choose the option to force
a new nodelist. That will also give a signal to the level above, when your
net is defunct. ;)

Kees

--- FPD v2.9.040207 GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

On Tue, 25 Nov 2014, Björn Felten wrote to All:

Anyway, we can leave that be -- even if I doubt that there are
that many systems out there that actually uses those error levels
-- but one level I would like is for "Unchanged output file will
NOT be submitted".

why not detect that in your script with diff or compare?

simplistic eg:
@echo off
set newhatch=no
rem set a non-changing name to hold our current netseg
rem myseg.cur is the current netseg that is published
iff not exist myseg.cur copy myseg.now myseg.cur
makenl ; output is myseg.now
diff myseg.cur myseg.now
if errorlevel 1 set newhatch=yes
if '%newhatch%' == 'no' goto end
rem diff says there's a difference between the files
rem so let's update the current one with the new one
copy myseg.now myseg.cur
rem and hatch it
hatch area whatever file myseg.cur desc "my new netseg" replace myseg.cur
rem all done!
:end


)\/(ark


* Origin: (1:3634/12)

why not detect that in your script with diff or compare?

That's what I've been doing for more than two decades now. 8-)

A clumsy work-around if you ask me...

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://felten.yi.org (2:203/2)

On Tue, 25 Nov 2014, Björn Felten wrote to mark lewis:

why not detect that in your script with diff or compare?

That's what I've been doing for more than two decades now. 8-)

so what's the problem?

A clumsy work-around if you ask me...

clumsy? i view it as much more elegent than other methods... in fact, i've been
switching a lot of my processing over to such methods... for many i also calculate a md5 and store it in a file so that it can be checked before the data file is downloaded... if the md5 hasn't changed, the file hasn't changed and pulling the md5 file is less intensive on the system and the pipeline ;)

)\/(ark


* Origin: (1:3634/12)

Hello Bj÷rn!

25 Nov 2014 05:27, Bj÷rn Felten wrote to All:

I've always found it hard to understand the underlying thought behind
the original error levels from the old MakeNl. And it seems like we
are trying to maintain those even in our new version.

if we change them scripts would fail

Alas, let's try not to break any batch files from 20 years ago, but really?

+1

0 = Process mode - no errors encountered
1 = Process mode - no fatal errors encountered
2 = Process mode - one or more fatal errors encountered
3 = Test mode - no errors encountered
4 = Test mode - no fatal errors encountered
5 = Test mode - one or more fatal errors encountered
254 = MakeNL aborted - I/O error
255 = MakeNL aborted - Control file error

feel free to not use return codes :)

echo "war" && echo "done"

Why the separate, otherwise identical, levels for process mode and
for test mode?

its not same test

Anyway, we can leave that be -- even if I doubt that there are that
many systems out there that actually uses those error levels -- but
one level I would like is for "Unchanged output file will NOT be submitted".

bad for daily updates

When eventually the output file is changed, I want to know, so I
can delete the old one (that at least for us in zone 2 has a different file extension on a regional level) and hatch out the new one.

check for not zerro return codes there would be error, so dont delete source, but if zerro return its updated, what ever dont know if bash on windows changes
that


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/3.17.3-gentoo (i686))
* Origin: duggi.junc.org where qico is waiting (2:230/0)