Hello everybody!

I use makenl 3.5.1 under Linux and the o/p file region25.nnn has a binary value
at the end of file that Ward (2:0) cannot handle in his Dos environment.

Does any one have a fix for it as I have tried using unix2dos and cannot find setting to omit it.

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

0000930 7265 2e73 656e 2c74 4249 0d4e 1a0a

Above from hexdump

Short of hacking the makenl code (assuming I find the code).

Vincent


--- Mageia Linux v9 X64/Mbse v1.1.0/GoldED+/LNX 1.1.5-b20240309
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

* Originally in FTSC_PUBLIC
* Crossposted in MAKENL_NG

Hi Vincent,

On 2025-03-04 17:23:04, you wrote to All:

I use makenl 3.5.1 under Linux and the o/p file region25.nnn has a
binary value at the end of file that Ward (2:0) cannot handle in his
Dos environment.

Sure he can. Every "normal" nodelist or segment ends with that character, and always has! It's even documented in: http://ftsc.org/docs/fts-0005.003
The Z2 nodelists I get from Ward also end with that character...

So I think something else is going on.

Does any one have a fix for it as I have tried using unix2dos and
cannot find setting to omit it.

There is no need to.

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

0000930 7265 2e73 656e 2c74 4249 0d4e 1a0a

Above from hexdump

Short of hacking the makenl code (assuming I find the code).

There is no need to.


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

0000930 7265 2e73 656e 2c74 4249 0d4e 1a0a

That's a <CTRL>Z. At one time it was widely used as an end of file marker.

I suppose you could just remove that last line.

My net segments also have those on the last line.

--- BBBS/Li6 v4.10 Toy-7
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Alan Ianson wrote to Vincent Coen <=-

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

0000930 7265 2e73 656e 2c74 4249 0d4e 1a0a

That's a <CTRL>Z. At one time it was widely used as an end of file
marker.

I suppose you could just remove that last line.

That would likely "break" the CRC value shown on the top line of a
segment. Not sure if that matters, but...

That actually raises a question I've wondered about... Is there
actually a need these days to create segments/nodelists with something
like 'makenl'? I use it, and understand it, but is it really required?
Could not the segments just be edited like any other text file, with a
normal text editor? I think the CRC is maybe used in "diff" processing,
but who actually needs/uses a diff file any more?

My net segments also have those on the last line.

Same here.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Hello Vincent!

04 Mar 25 17:23, you wrote to All:

I use makenl 3.5.1 under Linux and the o/p file region25.nnn has a binary value
at the end of file that Ward (2:0) cannot handle in his Dos environment.

????

Does any one have a fix for it as I have tried using unix2dos and
cannot
find setting to omit it.

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

0000930 7265 2e73 656e 2c74 4249 0d4e 1a0a

That is correct. I find the same in your REGION25.066, that I received on
March 3 at 19:18 CET

Above from hexdump

Short of hacking the makenl code (assuming I find the code).

As someone has alredy mentioned the a Dos files hould end with "CTRL-Z null"
as the last two characters.

There were problems with your March 2 file. I received 4 copies.
The first only contained net 263 with errors complaining about -Unpublished-
being an invalid phonenumber.

As you have probably found already that that is solved by adding

allowunpub 1

to your control file.

The file I received later that evening was correct, but hat Net 263 missing.

If one edits a net or region file on a contemporary system it is wise to
add:

removebom 1

Some systems add two specific bytes as the first two charaters of a file,
assuming that it will he encoded in UTF.
When only ascii characters are used the file is no different from an
ASCII file.

The two files are called "Byte Order Mark" and are used to signal the
Endian order of the bytes in the file.

the "rememovebom 1" makes shure that makenl removes the marker.

Kees

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

Hi Kees,

On 2025-03-04 21:23:54, you wrote to Vincent Coen:

As someone has alredy mentioned the a Dos files hould end with
"CTRL-Z null" as the last two characters.

There is never a null as the last character (or anywhere) in a segment/nodelist file!

The last three characters are: 0D 0A 1A


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Dan,

but who actually needs/uses a diff file any more?

You would be surprized how many hardliners still exist.

There's a guy in Z2 who refuses to take the zone2-nodediff here because he claims i'm playing with it. So he takes it from my RC, who gets it from me.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

I use makenl 3.5.1 under Linux and the o/p file region25.nnn has a binary value
at the end of file that Ward (2:0) cannot handle in his Dos environment.

Actually, your segment arrived here as one long one-line because your Linux system uses incompatible separators.

You have had this happening before and we discussed this. The matter was solved. And now it is there again.

Of course Kees can handle it on his Linux-system but I think there's a standard somewhere which you haven't followed. There's a way for a Linux system to deliver DOS-compatible files, the way it should be.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hej Ward!

There's a way for a Linux system to deliver DOS-compatible files,
the way it should be.

Heh, heh. Used to be that it was up to DOS to convert text files to UNIX rather than the other way around. That is the REAL "way it should be", given that DOS is dead and has been since before Y2K.

Some people never learn. Tsk, tsk.

Het leven is goed,
Maurice

o- o- o- o-
/) /) /) /)
^^ ^^ ^^ ^^
... Þæt folc bið gesælig... and gesundful þurh gesceadwisne reccend.
A people is made happy and prosperous by a wise ruler.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)

On <04 Mar, 23:22>, Ward Dossche wrote to Dan Clough :

Dan,

but who actually needs/uses a diff file any more?

You would be surprized how many hardliners still exist.

There's a guy in Z2 who refuses to take the zone2-nodediff here because
he claims i'm playing with it. So he takes it from my RC, who gets it
from me.

That is funny. Maybe you should send him one of all your information in it. lol <joking>

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

-Jason

--- ProBoard v2.32
* Origin: ProBoard WHQ - SiliconUnderground - siliconu.com (1:267/310)

Hello Vincent!

04 Mar 25 17:23, you wrote to all:

I use makenl 3.5.1 under Linux and the o/p file region25.nnn has a
binary value at the end of file that Ward (2:0) cannot handle in his
Dos environment.

Does any one have a fix for it as I have tried using unix2dos and
cannot find setting to omit it.

Out of interest it is 1a hex that is just after hex 0d oa i.e.,

That is the CTRL-Z End Of File marker, which is supposed to be there. See FTS-5000.001 section 4.

Andrew

--- GoldED+/LNX 1.1.5-b20240209
* Origin: From the Desk of the FTSC Administrator (1:320/219)

That's a <CTRL>Z. At one time it was widely used as an end of file
marker.

I suppose you could just remove that last line.

That would likely "break" the CRC value shown on the top line of a
segment. Not sure if that matters, but...

I'm not sure if the first and last lines are part of the CRC but they are best left alone.

That actually raises a question I've wondered about... Is there
actually a need these days to create segments/nodelists with something
like 'makenl'?

My and I suppose most NC's segments are done by hand but processing it with makenl includes the CRC and that's a plus. It's a requirement I think.

I use it, and understand it, but is it really required?

RC's and ZC's lives are much easier with makenl. :)

Could not the segments just be edited like any other text file, with a
normal text editor? I think the CRC is maybe used in "diff" processing,
but who actually needs/uses a diff file any more?

The CRC is a way to make sure you got the file without error, as intended.

--- BBBS/Li6 v4.10 Toy-7
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

My and I suppose most NC's segments are done by hand but processing it
with makenl includes the CRC and that's a plus. It's a requirement I
think.

When a segment arrives and it has a CRC, the CRC is checked. If it checks-out, fine. If it doesn't, my system will compute it and replace.

@ALL ... please don't tell me that it's wrong, you have no idea the amount of crap that sometimes is delivered and needs to be re-processed although times have improved.

If a segment arrives without CRC, idem ditto.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hi Alan,

On 2025-03-05 00:44:22, you wrote to Dan Clough:

That's a <CTRL>Z. At one time it was widely used as an end of file
marker.

I suppose you could just remove that last line.

That would likely "break" the CRC value shown on the top line of a
segment. Not sure if that matters, but...

I'm not sure if the first and last lines are part of the CRC but they are best
left alone.

The first line (containing the CRC) is _not_ part of the CRC calculation.

The last line (ending in 0D 0A) is part of the CRC calculation.

The line ending characters (should always be 0D 0A for a nodelist or segment) are part of the CRC calculation.

(So when you use for instance the dos2unix command on a nodelist file, you will invalidate the CRC.)

The ending CTRL-Z / 1A character is _NOT_ part of the CRC calculation.

So the ending CTRL-Z could be left out without affecting the CRC. But it is part of the standard, so it is best left in.


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Alan Ianson wrote to Dan Clough <=-

That's a <CTRL>Z. At one time it was widely used as an end of file
marker.

I suppose you could just remove that last line.

That would likely "break" the CRC value shown on the top line of a
segment. Not sure if that matters, but...

I'm not sure if the first and last lines are part of the CRC but they
are best left alone.

Yes, I agree, but hence my question...

That actually raises a question I've wondered about... Is there
actually a need these days to create segments/nodelists with something
like 'makenl'?

My and I suppose most NC's segments are done by hand but processing it with makenl includes the CRC and that's a plus. It's a requirement I think.

I'm an NC, and when changing my segment I use a normal text editor, save
it, and then process it with makenl. What I'm asking is: Is the
"processing" by makenl really needed? All it really does is generate
this CRC, and I'm asking if that CRC is actually needed by anything.

I use it, and understand it, but is it really required?

RC's and ZC's lives are much easier with makenl. :)

Maybe, assuming they set it up with incoming dir's and files, etc... I
bet many of them just use the 'data' keyword and have all the entries
below that.

Could not the segments just be edited like any other text file, with a normal text editor? I think the CRC is maybe used in "diff" processing,
but who actually needs/uses a diff file any more?

The CRC is a way to make sure you got the file without error, as
intended.

Yes, I know, but.... if you can't trust your downlink *C, who can you
trust? It's not like we have to deal with "line noise" corrupting a
file while it's in transit. ;-)




... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Ward Dossche wrote to Alan Ianson <=-

My and I suppose most NC's segments are done by hand but processing it with makenl includes the CRC and that's a plus. It's a requirement I think.

When a segment arrives and it has a CRC, the CRC is checked. If it checks-out, fine. If it doesn't, my system will compute it and replace.

So it sounds like the CRC has no meaning. If your system is
re-computing the CRC, then the segment could be invalid because of
in-transit corruption (or any other reason). If I'm wrong about that,
please explain more about it.

@ALL ... please don't tell me that it's wrong, you have no idea the
amount of crap that sometimes is delivered and needs to be re-processed although times have improved.

This sounds like RCs not doing their job properly. Why are they not
being held accountable to do it correctly?

If a segment arrives without CRC, idem ditto.

So this is the crux of my (original) question. If it arrives without a
CRC, then one can assume that MakeNL was not used to produce the
segment. To repeat my original question, is MakeNL really needed? A
segment is just a text file that gets "processed" by MakeNL, and it
sounds like all that MakeNL is actually doing is calculating a CRC. Is
that serving any valid purpose, especially now that we know the validity
of the CRC is ignored anyway?

In other words, can't the *C's just edit their segments with their text
editor of choice, and then get it to the upstream *C via whatever method
they like (netmail or email)? What role does MakeNL perform in this
process that actually matters?

Thanks for any info you can provide!



... Users come in two types: Those who have lost data, and those who will.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

So it sounds like the CRC has no meaning. If your system is
re-computing the CRC, then the segment could be invalid because of in-transit corruption (or any other reason). If I'm wrong about that, please explain more about it.

@ALL ... please don't tell me that it's wrong, you have no idea ...

You have bypassed the reaction to your statement by inserting your reaction in front of my prior statement.

Thanks for any info you can provide!

Yes, I do think that WestVleteren12 is the best beer in the world.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hello Dan!

05 Mar 25 08:29, you wrote to Ward Dossche:

So this is the crux of my (original) question. If it arrives without
a CRC, then one can assume that MakeNL was not used to produce the
segment. To repeat my original question, is MakeNL really needed? A
segment is just a text file that gets "processed" by MakeNL, and it
sounds like all that MakeNL is actually doing is calculating a CRC.
Is that serving any valid purpose, especially now that we know the validity of the CRC is ignored anyway?

MakeNL does more than just compute a CRC for the segment file. It does some basic error checking of segments, to include insuring there are no duplicate node numbers in the segment, checking that any phone numbers have the correct number of parts, making sure that there are no invalid keywords, etc.

In other words, can't the *C's just edit their segments with their
text editor of choice, and then get it to the upstream *C via whatever method they like (netmail or email)? What role does MakeNL perform in this process that actually matters?

MakeNL was designed to automate the submission process. If you email or netmail the segment, the upstream coordinator most likely has to manually save it on their system in the proper place for MakeNL to find and process it. Sending it as a file attach to your coordinator is the best way to allow it to be processed automatically. In fact, MakeNL's SUBmit directive in the .CTL file automates the creation of a file attach netmail to get the file where it needs to go.

It is certainly possible to edit a segment in a text editor, save it as an ASCII text file, and manually send it to your upstream coordinator by creating a file attach or copying it into a filebox directory, as appropriate for the mailer you are using. In this case, you would lose the benefits of MakeNL error-checking your segment prior to submission. Potentially this could cause your updates to be delayed if there is a typo or other error in your submission.

Andrew

--- GoldED+/LNX 1.1.5-b20240209
* Origin: From the Desk of the FTSC Administrator (1:320/219)

Andrew Leary wrote to Dan Clough <=-

So this is the crux of my (original) question. If it arrives without
a CRC, then one can assume that MakeNL was not used to produce the
segment. To repeat my original question, is MakeNL really needed? A
segment is just a text file that gets "processed" by MakeNL, and it
sounds like all that MakeNL is actually doing is calculating a CRC.
Is that serving any valid purpose, especially now that we know the validity of the CRC is ignored anyway?

MakeNL does more than just compute a CRC for the segment file. It does some basic error checking of segments, to include insuring there are no duplicate node numbers in the segment, checking that any phone numbers have the correct number of parts, making sure that there are no invalid keywords, etc.

Okay, yes.

In other words, can't the *C's just edit their segments with their
text editor of choice, and then get it to the upstream *C via whatever method they like (netmail or email)? What role does MakeNL perform in this process that actually matters?

MakeNL was designed to automate the submission process. If you email
or netmail the segment, the upstream coordinator most likely has to manually save it on their system in the proper place for MakeNL to find and process it. Sending it as a file attach to your coordinator is the best way to allow it to be processed automatically. In fact, MakeNL's SUBmit directive in the .CTL file automates the creation of a file
attach netmail to get the file where it needs to go.

Understood, and that is all very useful. I use it that way myself
(automated file attach / netmail to RC).

I guess what got me down this path was how Ward is describing that he
receives garbage segments, and then "fixes" them, which I understand is
needed and not "wrong". The value of the CRC function seems to be
compromised (useless, in fact) in that scenario, and if a *C is going to
edit a segment (or even a whole nodelist) as they see fit, what's the
point of the CRC or even MakeNL? Seems like it would be more correct
for upstream *Cs to hold the segment submitter accountable for doing it correctly, and fire them if they're unable or unwilling to do so.

It is certainly possible to edit a segment in a text editor, save it as
an ASCII text file, and manually send it to your upstream coordinator
by creating a file attach or copying it into a filebox directory, as appropriate for the mailer you are using. In this case, you would lose the benefits of MakeNL error-checking your segment prior to submission.
Potentially this could cause your updates to be delayed if there is a typo or other error in your submission.

Agreed. Thanks for your explanation and information.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Hi Dan,

On 2025-03-06 08:04:52, you wrote to Andrew Leary:

Seems like it would be more correct for upstream *Cs to hold the
segment submitter accountable for doing it correctly, and fire them if they're unable or unwilling to do so.

There would be nobody left by now! ;-)


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Wilfred van Velzen wrote to Dan Clough <=-

Seems like it would be more correct for upstream *Cs to hold the
segment submitter accountable for doing it correctly, and fire them if they're unable or unwilling to do so.

There would be nobody left by now! ;-)

Then we wouldn't need NCs any more, just let the RCs do it. Most of
them have fewer nodes now than many/most NCs had back in the day.

And.... eventually we'll be down to just ZCs... ;-)



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.23-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)