Hello Martin!

I've been operating with nodelist .024 all week quite smoothly.

Along comes the DIFF:

18:33:25 PHN rbb.fidonet.fi
18:33:25 TIME Fri, 31 Jan 2020 01:32:44 +0200
18:33:25 VER binkd/1.1a-99.1/OS2 binkp/1.1
18:33:26 TRF 0 2265
18:33:26 OPT EXTCMD GZ BZ2
18:33:26 secure
* 18:33:26 Rcvd NODEDIFF.Z31, 1453b
* 18:33:26 Rcvd 0srh4h4o.tic, 812b


Everything is configured to "Use internal processor", "

..but I get this error:

+- Error ------------------------------------------------------
|
| NODELIST.024: Wrong version/date of nodelist or nodediff ?


My nodelist tables look like this:

+------------------------------------------------------------------
Ý Z2PNT.### 024 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
Ý NODELIST.### 024 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
Ý
Ý +- Configure Node/Pointlist ------------------------+
Ý Ý Ý
Ý Ý List name Z2PNT.### Number 024 Ý
Ý Ý Ý
Ý Ý Format of list FD Pointlist ? Ý
Ý Ý Zone/Address Ý
Ý Ý Ý
Ý Ý Update file Z2PNT_D.### Ý
Ý Ý Update archive Z2PNT_D.Z## Ý
Ý Ý Ý
Ý Ý Process by Ý
Ý Ý Ý
Ý Ý [x] Use internal nodelist processor Ý
Ý Ý [x] Delete update after processing Ý
Ý Ý Ý
Ý +-------------------------------------------- [F2] -+

Ý +- Configure Node/Pointlist ------------------------+
Ý Ý Ý
Ý Ý List name NODELIST.### Number 024 Ý
Ý Ý Ý
Ý Ý Format of list Nodelist ? Ý
Ý Ý Zone/Address Ý
Ý Ý Ý
Ý Ý Update file NODEDIFF.### Ý
Ý Ý Update archive NODEDIFF.Z## Ý
Ý Ý Ý
Ý Ý Process by Ý
Ý Ý Ý
Ý Ý [x] Use internal nodelist processor Ý
Ý Ý [x] Delete update after processing Ý
Ý Ý Ý
Ý +-------------------------------------------- [F2] -+


WHY isn't the nodediff (to bring me up to .031) getting applied?


../|ug

--- OpenXP 5.0.43
* Origin: /|ug's EuroPoint (2:221/1.58)

Hello August!

* 30.01.20 at 19:19, August Abolins wrote to Martin Foster:

I've been operating with nodelist .024 all week quite smoothly.

Along comes the DIFF:

18:33:25 PHN rbb.fidonet.fi
18:33:25 TIME Fri, 31 Jan 2020 01:32:44 +0200
18:33:25 VER binkd/1.1a-99.1/OS2 binkp/1.1
18:33:26 TRF 0 2265
18:33:26 OPT EXTCMD GZ BZ2
18:33:26 secure
* 18:33:26 Rcvd NODEDIFF.Z31, 1453b
* 18:33:26 Rcvd 0srh4h4o.tic, 812b

Everything is configured to "Use internal processor", "

..but I get this error:

+- Error ------------------------------------------------------
|
| NODELIST.024: Wrong version/date of nodelist or nodediff ?

Hmmm, never seen that error before ???

[snip]

WHY isn't the nodediff (to bring me up to .031) getting applied?

Try applying the diff manually and then have a look at your
debuglog.txt and see if there's anything in there that gives a clue?

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 01/02/2020 4:46 a.m., Martin Foster : August Abolins wrote:

I've been operating with nodelist. 024 all week quite smoothly.
Along comes the DIFF:

+- Error ------------------------------------------------------
| | NODELIST. 024: Wrong version/date of nodelist or nodediff?

Hmmm, never seen that error before???

Hi Martin,

So, all the lock ups I've been having were probably based on this very
issue. :( And maybe it only applies to the Win/32 version, since you run
the Linux version?

BTW, the Z2PNT diffs *are* working, and .024 automatically recompiled to
..031 just fine.

When I first installed and operated oxp (with a nodelist *and* z2pnt
list installed), I still wasn't signed up to the diff updates.

I probably registered for the pointlist updates first, and witnessed
smooth operations for weeks. But, as soon as I started receiving a new
NODELIST diff, the lockups started.

Could this also be partially related to the nodelist (parsing/search)
issue I discovered a few days ago?

WHY isn't the nodediff (to bring me up to. 031) getting
applied?

Try applying the diff manually and then have a look at your
debuglog.txt and see if there's anything in there that gives a
clue?

I couldn't figure out how to *just* trigger a diff update if the file is sitting in the /FILES directory. I am sure I tried "recompile" or
something, but the .024 number in the config panel stayed the same.

Instead, I deleted the whole entry, and just pointed oxp to the .031
edition. I'm good until this Friday. :/


--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68/Win7 (just keeping things short!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

* 01.02.20 at 18:53, August Abolins wrote to Martin Foster:

I've been operating with nodelist. 024 all week quite smoothly.
Along comes the DIFF:

+- Error ------------------------------------------------------
| | NODELIST. 024: Wrong version/date of nodelist or nodediff?

Hmmm, never seen that error before???

[snip]

Could this also be partially related to the nodelist (parsing/search) issue I discovered a few days ago?

Possibly.

WHY isn't the nodediff (to bring me up to. 031) getting
applied?

Try applying the diff manually and then have a look at your
debuglog.txt and see if there's anything in there that gives a
clue?

I couldn't figure out how to *just* trigger a diff update if the file is sitting in the /FILES directory. I am sure I tried "recompile" or something, but the .024 number in the config panel stayed the same.

- Go to Fido -> Nodelists -> Update
- Navigate your way to the directory which contains the diff file
- Cursor over the diff file and press <Enter>

Instead, I deleted the whole entry, and just pointed oxp to the .031 edition. I'm good until this Friday. :/

Yeah and we both know what happened :-((

This is looking like a Windows specific problem because I can
reproduce the problem in my Windows install of OpenXP but I cannot
reproduce the problem in my Linux install of OpenXP ??????

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 07/02/2020 7:57 a.m., Martin Foster : August Abolins wrote:

Try applying the diff manually..

I couldn't figure out how to *just* trigger a diff update..

- Go to Fido - > Nodelists - > Update -
- Navigate your way to the directory which contains the diff file
- Cursor over the diff file and press <Enter>

Thank you. I sort of figured that out before I read this. Forgive me,
but manual update was not something I thought could be done with the
diffs too!

This is looking like a Windows specific problem..

Good to know that I am *not* imagining things. But it looks like I'm
the only Windows user in the vast expanse of OXP users?

Too bad the linux code doesn't port directly to the Windows version.


--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello Martin!

** 07.02.20 - 12:57, Martin Foster wrote to August Abolins:

This is looking like a Windows specific problem because I can
reproduce the problem in my Windows install of OpenXP but I cannot
reproduce the problem in my Linux install of OpenXP ??????

The Z2PNT diff worked, but not the main NODELIST diff:


07.02.20 17:17:00
Extracting Z2PNT_D.038 from H:\DOWNLOADS\OPENXP\FILES\Z2PNT_D.Z38
07.02.20 17:17:00
Z2PNT.031 + H:\DOWNLOADS\OPENXP\FILES\Z2PNT_D.038 -> Z2PNT.038
07.02.20 17:17:00
Extracting NODEDIFF.038 from H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z38
07.02.20 17:17:02
NODELIST.031: Wrong version of node/point list or diff


../|ug

--- OpenXP 5.0.43
* Origin: /|ug's EuroPoint (2:221/1.58)

Hello August!

*** 07.02.20 at 18:19, August Abolins wrote to Martin Foster:

[snip]

Too bad the linux code doesn't port directly to the Windows version.

Errrrm, the same code is used irrespective of architecture.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 07.02.20 at 17:22, August Abolins wrote to Martin Foster:

[snip]

Extracting NODEDIFF.038 from H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z38 07.02.20 17:17:02
NODELIST.031: Wrong version of node/point list or diff

Finally, finally, finally, I've figured this out .....

Are you aware that three different versions of the Fido nodelist are
released each week, along with their corresponding nodediffs. One for use
in Z1, one for use in Z2 and one for use in Z3.

Snippet from the prolog of the Z1 version of the nodelist:
---------- 8< ----------
;S o-------------------------------------------------------------o
;S | Begin Zone 1 PROLOG-section for Friday, January 24th, 2020: |
;S o-------------------------------------------------------------o
;S
;S
;S Note: THIS PARTICULAR LIST/SEGMENT ORIGINATES FROM AND IS INTENDED
;S FOR ZONE 1 USAGE.
;S
;S ------------------------------------------------------------------------ ---------- 8< ----------

Snippet from the prolog of the Z2 version of the nodelist:
---------- 8< ----------
;S +-------------------------------+
;S | PROLOG-DATE : 19 JAN 2019 |
;S +-------------------------------+
;S
;S +------------------------------------------------------------+
;S * THIS LIST HAS BEEN COMPILED IN AND FOR ZONE-2 *
;S +------------------------------------------------------------+
[snip]
;S +------------------------------------------------------------+
;S | INFORMATION RE: THE WEEKLY NODELIST.jjj AND NODEDIFF.jjj |
;S +------------------------------------------------------------+
;S | THE REGULAR WEEKLY NODELIST IS PRODUCED ON FRIDAY. |
;S | |
;S | SYSOPS FROM OUTSIDE ZONE-2 BUT NEVERTHELESS USING THE |
;S | ZONE-2 VERSION OF THE WORLD-NODELIST, PLEASE CHECK THAT |
;S | YOU UPDATE IT WITH THE CORRESPONDING DIFF ORIGINATING |
;S | IN ZONE-2. |
;S | |
;S | SYSOPS INSIDE ZONE-2 PLEASE MAKE CERTAIN YOU DO "NOT" |
;S | UPDATE IT WITH A DIFF ORIGINATING IN ANOTHER ZONE. |
;S +------------------------------------------------------------+ ---------- 8< ----------

It seems to me that you used a Z1 version of the nodelist as a starting
point and that you're trying to update it with Z2 nodediffs. This is why I could reproduce the problem in my Windows install using your copy of the nodelist(Z1 version) you sent me. I've just tried this again but this time
I used my own copies of the nodelist and nodediffs, which are all Z2 versions. Just as an additional "stress test", I used an old nodelist together with 26 consecutive nodediffs to bring it up to date and there
were no errors.

Over to you :-)

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 08.02.20 - 13:32, Martin Foster wrote to August Abolins:

Finally, finally, finally, I've figured this out .....

Are you aware that three different versions of the Fido nodelist are
released each week, along with their corresponding nodediffs. One for use
in Z1, one for use in Z2 and one for use in Z3.

No, I was not aware of that. I fetched my main nodelist from my boss node (Tommi, Zone2) and the diffs automatically arrive from there too.

When this first started, I may have grabbed the list from Z1 Filegate
site. Then, I may have grabbed a subsequent nodelist from Terry Roati's system in Zone 3 (but I don't remember).

My .017 copy (in WinPoint) looks like a Z1 version
My .024 copy looks like a Z1 version.
My .031 copy is a Z1 version.
My .038 copy is a Z2 version, but it says..

;A FidoNet Nodelist for Friday, February 7, 2020 -- Day number 038 : 00105
;A The FidoNet DAILYLST, a listing of the systems within FidoNet.
;A
;A This is the DAILYLST produced at 2:2/0

Is the latter compatible with the diff process?

And, am I to understand that Diffs from my Boss/uplink cannot be used with full-nodelists offered from Z1 sources?

Thanks for quoting the header info in each. The Z2 version has a very
clear warning about its usage, but I must confess to say that I never read the darn thing for leisure! I never noticed anything similar to the Z2
info in the header of the Z1 version.

Let me know if I must replace the current Z2 DAILY .038 that I have
inorder for the diffs to work.

Good sleuthing!
Thanks.

../|ug

--- OpenXP 5.0.43
* Origin: /|ug's EuroPoint (2:221/1.58)

On 08/02/2020 7:58 a.m., Martin Foster : August Abolins wrote:

[snip]

Too bad the linux code doesn't port directly to the Windows
version.

Errrrm, the same code is used irrespective of architecture.

I thought so too! ..until you said that you were able to reproduce the
problem in your Win install but not in Linux.

But now we know the nodelist problem is rooted in the Zversion
(zone-version) being used. :(



--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

On 08/02/2020 8:32 a.m., Martin Foster : August Abolins wrote:

Finally, finally, finally, I've figured this out .....

Let me know if I must replace the current Z2 DAILY. 038 that I
have inorder for the diffs to work.

NEVERMIND. Looking at the DIFF files and reading about how they work,
the first line of the new diff *has* to match the first line of the
previous full nodelist to which it applies.

The first line of the full .038 from Ambrosia (Z2) does not match the
first line of Tommi's .038.

Apparently, freq'ing for NODELIST from Tommi's sytem produces a DAILY
version (which I only realized a couple weeks ago), which according to
the first line discovery above, will not be a match for next week.

In the past, I had noticed that the order of the zone segments were
different depending on where I grabbed "the" nodelist. I attributed
that to a "my zone is better than your zone" thing, or to a timing issue
when each zone segment arrived for "global" processing. I put that
matter behind me. But it didn't occur to me that they wouldn't work
with "the" scheduled diff later on.

In the past, I thought there was only one "full" global nodelist. Now
there is a version for each zone. I am not sure if that is an
improvement. When did the zone-specific versions start?

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

*** 09.02.20 at 11:08, August Abolins wrote to Martin Foster:

[snip]

If the nodelist you're trying to update is the z1 version, z1 version
diffs must be used. If the nodelist you're trying to update is the z2
version, z2 version diffs must be used.

I don't think THAT is stated so clearly anywhere in fidonet land as you have just done! Thank you.

You're welcome :)

The nodelist masters should cut'n'paste THAT at the very top of those files!

Well, I'm not going to tell them :)

..or it should be part of the ftsc family of docs,

I'm not going anywhere near that one either.

somewhere -because I could not find this subtlety meantioned anywhere obvious.

I'll try and add it to one of the OpenXP nodelist-related help topics but don't hold your breath.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 08.02.20 at 09:22, August Abolins wrote to Martin Foster:

Finally, finally, finally, I've figured this out .....

Are you aware that three different versions of the Fido nodelist are
released each week, along with their corresponding nodediffs. One for
use in Z1, one for use in Z2 and one for use in Z3.

No, I was not aware of that. I fetched my main nodelist from my boss
node (Tommi, Zone2) and the diffs automatically arrive from there too.

When this first started, I may have grabbed the list from Z1 Filegate site. Then, I may have grabbed a subsequent nodelist from Terry Roati's system in Zone 3 (but I don't remember).

My .017 copy (in WinPoint) looks like a Z1 version
My .024 copy looks like a Z1 version.
My .031 copy is a Z1 version.
My .038 copy is a Z2 version, but it says..

;A FidoNet Nodelist for Friday, February 7, 2020 -- Day number 038 :
00105 ;A The FidoNet DAILYLST, a listing of the systems within FidoNet.
;A
;A This is the DAILYLST produced at 2:2/0

Is the latter compatible with the diff process?

I'm not sure about that because I've never used the daily nodelist but why would anyone want to use diffs on a daily nodelist?

And, am I to understand that Diffs from my Boss/uplink cannot be used
with full-nodelists offered from Z1 sources?

If the nodelist you're trying to update is the z1 version, z1 version
diffs must be used. If the nodelist you're trying to update is the z2 version, z2 version diffs must be used. From what you've said, the diffs
you receive from Tommi are z2 version diffs which cannot be used to update
a z1 version nodelist.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 08.02.20 at 19:44, August Abolins wrote to Martin Foster:

[snip]

In the past, I thought there was only one "full" global nodelist. Now there is a version for each zone. I am not sure if that is an
improvement. When did the zone-specific versions start?

I've no idea when they started but there's someone in this echo who may be able to answer the question ..... cue Marc :-))

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 09.02.20 - 08:36, Martin Foster wrote to August Abolins:

;A FidoNet Nodelist for Friday, February 7, 2020 -- Day number 038 :
00105 ;A The FidoNet DAILYLST, a listing of the systems within FidoNet.
;A
;A This is the DAILYLST produced at 2:2/0

Is the latter compatible with the diff process?

I'm not sure about that because I've never used the daily nodelist but why
would anyone want to use diffs on a daily nodelist?

It would be silly to have a diff for a nodelist that is produced daily.
But that is a different topic. ;)

I was asking if the next scheduled weekly diff could be used on the
current .038 full nodelist that Tommi's system offers (which happens to be
a daily version).

Apparently there are TWO versions of .038 to be had - "the" weekly, or a daily. But a freq for "NODELIST" produces a daily version.

Anyway, I think I answered my own question based on the analysis of the
first line in each version of the nodelist. I replaced Tommi's .038 with
the one from Ambrosia. It should be smooth operations this coming friday.

If the nodelist you're trying to update is the z1 version, z1 version
diffs must be used. If the nodelist you're trying to update is the z2
version, z2 version diffs must be used.

I don't think THAT is stated so clearly anywhere in fidonet land as you
have just done! Thank you.

The nodelist masters should cut'n'paste THAT at the very top of those
files! ..or it should be part of the ftsc family of docs, somewhere - because I could not find this subtlety meantioned anywhere obvious.


../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Greetings All!

*** 08.02.20 at 13:32, Martin Foster wrote to August Abolins:

[snip]

Are you aware that three different versions of the Fido nodelist are released each week, along with their corresponding nodediffs. One for use in Z1, one for use in Z2 and one for use in Z3.

Before I set about updating the OpenXP help file, I would be obliged if someone could confirm that z3 do actually create their own version of the world nodelist.

Additionally, does anyone know if z4 create their own version of the world nodelist?

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Before I set about updating the OpenXP help file, I would be obliged if someone could confirm that z3 do actually create their own version of the world nodelist.

Yes, the ZC of each zone creates a nodelist for their zone. The only difference
is that each zone lists their zone first making nodelist lookups faster. That's not an issue today.. but it was at one time.. :)

Additionally, does anyone know if z4 create their own version of the world nodelist?

I'll see if I can find some Z3 and Z4 nodelists and diffs and get a good answer
to that question.

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

Hello Martin.

<On 09Feb2020 08:39 Martin Foster (2:310/31.3) wrote a message to August Abolins regarding oxp: nodediff fails :( >

Hello August!

*** 08.02.20 at 19:44, August Abolins wrote to Martin Foster:

[snip]

In the past, I thought there was only one "full" global nodelist. Now there is a version for each zone. I am not sure if that is an
improvement. When did the zone-specific versions start?

I've no idea when they started but there's someone in this echo who
may be able to answer the question ..... cue Marc :-))

There is in fact one "global" official NodeList that includes all Zones and it hatches out early on each Friday morning. There is, at least in Zone 1 a "daily" list called Z1Daily; the same may be true in Zone 2; but the actual working NodeList is the one that shows up on Friday.

I am unaware of anyone publishing a separate exclusive Zone 2 list...

Best regards,
Marc

... MegaHertz: Many pains.
--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

Before I set about updating the OpenXP help file, I would be obliged if someone could confirm that z3 do actually create their own version of the world nodelist.

Yes they do. I grabbed a nodelist from Z3 and it does start listing nodes in Z3
bofore the others.

Additionally, does anyone know if z4 create their own version of the world nodelist?

I don't think they do. I grabbed a nodelist from a BBS in Z4 and found it was a
Z1 nodelist. I did find an up date ZONE4.Z38 so they are current but no Z4 nodelist that I could find.

Someone in Z4 might correct me but that's what I saw looking from a distance.

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

Hello Martin!

13 Feb 20 09:04, you wrote to all:

are released each week, along with their corresponding nodediffs.
One for use in Z1, one for use in Z2 and one for use in Z3.

Before I set about updating the OpenXP help file, I would be obliged
if someone could confirm that z3 do actually create their own version
of the world nodelist.

Additionally, does anyone know if z4 create their own version of the
world nodelist?

Each zone creates there own version of the nodelist.

If someone was using a zone 2 nodelist, then a zone 2 nodediff is required to update it.

The same goes for the other zones.



Stephen


--- GoldED+/LNX 1.1.5-b20170303
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)

Hello Martin!

** 08.02.20 - 13:32, Martin Foster wrote to August Abolins:

[snip]

Extracting NODEDIFF.038 from H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z38
07.02.20 17:17:02
NODELIST.031: Wrong version of node/point list or diff

Finally, finally, finally, I've figured this out .....

I hate to be the bearer of bad news, ..but right after NODEDIFF.Z45 arrived, it locked up, again! :(

Here are the details:

13.02.20 19:19:31 Extracting NODEDIFF.045 from H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45
13.02.20 19:19:32 NODELIST.038 + H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.045 -> NODELIST.045


2020-02-13 19:19:31 xpncfido: Decompressiong packets: H:\DOWNLOADS\OPENXP\SPOOL\NODEDIFF.Z45 H:\DOWNLOADS\OPENXP\SPOOL\0ss71rpr.tic 2020-02-13 19:19:31 xpncfido: H:\DOWNLOADS\OPENXP\SPOOL\NODEDIFF.Z45 is a requested file
2020-02-13 19:19:31 xpncfido: H:\DOWNLOADS\OPENXP\SPOOL\0ss71rpr.tic is a requested file
2020-02-13 19:19:31 xpncfido: Files decompressed:
2020-02-13 19:19:31 xpncfido: Converting to fido:
2020-02-13 19:19:31 xpncfido: no files to process
2020-02-13 19:19:31 xpfidonl: Starting DoDiffs in H:\DOWNLOADS\OPENXP\FILES\*.* 2020-02-13 19:19:31 xpfidonl: diffDir is ExtractFilePath(files)
2020-02-13 19:19:31 xpfidonl: diffnames are ExtractFilename(files)
2020-02-13 19:19:31 xpfidonl: diffDir and diffnames done
2020-02-13 19:19:31 xpfidonl: Nodelist.Count = 2
2020-02-13 19:19:31 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-02-13 19:19:31 xpfidonl: NextNumber45 uarchive: ufile: Z2PNT_D.045 2020-02-13 19:19:31 xpfidonl: NodeDiff-Routine (repeat-Schleife) erfolgreich beendet
2020-02-13 19:19:31 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-02-13 19:19:31 xpfidonl: NextNumber45 uarchive: H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 ufile: NODEDIFF.045
2020-02-13 19:19:31 xpfidonl: Using H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 2020-02-13 19:19:31 xp1s: shell, prog:<unzip H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 NODEDIFF.045>, cls:<3>
2020-02-13 19:19:31 xp1s: shell, screenlines:41,ScreenWidth:100
2020-02-13 19:19:31 maus2: maus_tasten_aus
2020-02-13 19:19:31 xp1s: shell, calling sichern(sp)
2020-02-13 19:19:31 xp1s: shell, calling clwin(1,ScreenWidth,4,screenlines-2) 2020-02-13 19:19:31 xp1s: shell, calling Xec(unzip H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 NODEDIFF.045>
2020-02-13 19:19:31 xp1s: Xec, command:<unzip H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 NODEDIFF.045>, prompt:>[XP]>
2020-02-13 19:19:32 openxp: OpenXP 5.0.43 (Win32)
2020-02-13 19:19:32 xp1s: called program "H:\DOWNLOADS\OPENXP\UNZIP.EXE" with parameters "H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z45 NODEDIFF.045": result 0 2020-02-13 19:19:32 xp1s: shell, Xec returns Errowlevel:0
2020-02-13 19:19:32 xp1s: shell, calling SetScreenSize, ScreenLines:41, ScreenWidth:100
2020-02-13 19:19:32 xpwin32: ---- SysSetScreenSize, Cols:100, Lines: 41 2020-02-13 19:19:32 xpwin32: GetConsoleScreenBufferInfo , scrb x: 100, scrb y: 41, MaxWinS x: 100, MaxWinS y:41
2020-02-13 19:19:32 xpwin32: GetLargestConsoleWindowSize x: 116, y: 49 2020-02-13 19:19:32 xpwin32: no initial SetConsoleScreenBufferSize needed 2020-02-13 19:19:32 xpwin32: SetConsoleWindowInfo Okay
2020-02-13 19:19:32 xpwin32: second SetConsoleScreenBufferSize not needed 2020-02-13 19:19:32 xp1s: shell, after calling SetScreenSize, ScreenLines:41, ScreenWidth:100
2020-02-13 19:19:32 maus2: maus_tasten_an
2020-02-13 19:19:32 xpfidonl: Using H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.045 2020-02-13 19:19:32 xpfidonl: NextNumber52 uarchive: ufile: NODEDIFF.052 2020-02-13 19:19:32 xpfidonl: NodeDiff-Routine (repeat-Schleife) erfolgreich beendet

..and promptly locked up at this point.

After another poll a few minutes later, this happens:

2020-02-13 19:31:01 debug: debug level for XPFIDONL is 50
2020-02-13 19:31:01 xpfidonl: Starting DoDiffs in H:\DOWNLOADS\OPENXP\FILES\*.* 2020-02-13 19:31:01 xpfidonl: diffDir is ExtractFilePath(files)
2020-02-13 19:31:01 xpfidonl: diffnames are ExtractFilename(files)
2020-02-13 19:31:01 xpfidonl: diffDir and diffnames done
2020-02-13 19:31:01 xpfidonl: Nodelist.Count = 2
2020-02-13 19:31:01 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-02-13 19:31:01 xpfidonl: NextNumber45 uarchive: ufile: Z2PNT_D.045 2020-02-13 19:31:01 xpfidonl: NodeDiff-Routine (repeat-Schleife) erfolgreich beendet
2020-02-13 19:31:01 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-02-13 19:31:01 xpfidonl: NextNumber52 uarchive: ufile: NODEDIFF.052 2020-02-13 19:31:01 xpfidonl: NodeDiff-Routine (repeat-Schleife) erfolgreich beendet

..and promptly locks up.


The ONLY way I could prevent the lock up happening with the next normal
poll was by making sure I delete the .TIC file: 0ss71rpr.tic

..which contained:

Created by HTick, written by Gabriel Plutzar
File NODEDIFF.Z45
Area NODEDIFZ
Areadesc FidoNet Z2 NodeDiffs (ZIP)
Desc Fidonet NODEDIFF for this week (ZIP)
From 2:221/1
To 2:221/1.58
Origin 2:292/854
Size 1857
Crc 55C435F2
Path 2:292/854 1581657300 Fri Feb 14 05:15:00 2020 GMT
Path 2:221/0 1581635940 Thu Feb 13 23:19:00 2020 UTC htick/os2-emx 1.9.0-cur 2019-12-05
Seenby 2:2/0
Seenby 2:203/0
Seenby 2:221/0
Seenby 2:221/1
Seenby 2:221/1.58
Seenby 2:221/1.59
Seenby 2:221/360
Seenby 2:230/0

..etc, etc, etc..


The new updated nodelist number in oxp looks good:

+----------------------------------------------------------------------+
Ý Z2PNT.### 038 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist Ý
Ý NODELIST.### 045 NODEDIFF.### NODEDIFF.Z## Diff Nodelist Ý
Ý Ý


The top few lines of NODELIST.045 look like:

;A FidoNet Nodelist for Friday, February 14, 2020 -- Day number 045 : 12455
;Aú
;A MakeNL 3.4.5 (Win32)ú
;Aú
;A The FidoNet NodeList, a listing of the systems within FidoNet.ú
;Aú
;A This is the nodelist produced at 2:2/0ú


SEE? So.. the .TIC file in /FILES *could* be a problem.

Therefore, maybe I should disable "THIS" below?:

+- Fido Options ---------------------------------+
Ý Ý
Ý Int. dial prefix 00 Ý
Ý Nat. dial prefix 0 Ý
Ý Your dialing code 49-631 Ý
Ý Ý
Ý [x] Import nodelist updates automatically Ý
Ý [ ] Delete empty messages Ý
Ý [x] Automatic TIC file processing Ý<==THIS?
Ý [x] Hold requests if files are missing Ý

Maybe the system is trying to create "Area NODEDIFZ" and is failing? Bug?


../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hello Martin!

** 13.02.20 - 09:04, Martin Foster wrote to All:

Before I set about updating the OpenXP help file, I would be obliged if
someone could confirm that z3 do actually create their own version of the
world nodelist.

I found this one from 3:712/0


;A FidoNet Nodelist for Friday, February 7, 2003 -- Day number 038 : 07643
;A
;A The FidoNet NodeList is a listing of the members of FidoNet.
;A
;A Copyright of the contributing coordinators of FidoNet Zone 3.
;A The following restrictions on distribution and use of this list apply:

[snip]

;S
;S Zone Region segments in this nodelist
;S -------------------------------------
;S
;S ZONE1 day 038
;S ZONE2 day 038
;S ZONE3 day 038
;S ZONE4 day 038
;S ZONE5 day 038
;S ZONE6 day 024
;S


I guess some people didn't get the "memo"? :/



../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hi August,

On 2020-02-13 23:30:00, you wrote to Martin Foster:

I found this one from 3:712/0

;A FidoNet Nodelist for Friday, February 7, 2003 -- Day number 038 : 07643 ;A
;A The FidoNet NodeList is a listing of the members of FidoNet.
;A
;A Copyright of the contributing coordinators of FidoNet Zone 3.
;A The following restrictions on distribution and use of this list apply:

[snip]

;S
;S Zone Region segments in this nodelist
;S -------------------------------------
;S
;S ZONE1 day 038
;S ZONE2 day 038
;S ZONE3 day 038
;S ZONE4 day 038
;S ZONE5 day 038
;S ZONE6 day 024
;S

I guess some people didn't get the "memo"? :/

Maybe you missed the "2003" part above?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Alan!

*** 13.02.20 at 11:01, Alan Ianson wrote to Martin Foster:

Before I set about updating the OpenXP help file, I would be obliged if
someone could confirm that z3 do actually create their own version of the
world nodelist.

Yes, the ZC of each zone creates a nodelist for their zone.

Many thanks for clarifying that.

The only difference is that each zone lists their zone first making nodelist lookups faster.

Yes, that's hinted at in the last paragraph of the Nodelist Compilation section of FTS-0005, although it's worded somewhat differently.

That's not an issue today.. but it was at one time.. :)

Yup.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Marc!

*** 13.02.20 at 13:59, Marc Lewis wrote to Martin Foster:

[snip]

There is in fact one "global" official NodeList that includes all Zones and it hatches out early on each Friday morning. There is, at least in Zone 1 a "daily" list called Z1Daily; the same may be true in Zone 2; but the actual working NodeList is the one that shows up on Friday.

I am unaware of anyone publishing a separate exclusive Zone 2 list...

It's not exclusive per se, it's just that the entries are ordered differently. Z2 systems are listed at the top of the list, whereas in the
Z1 version of the nodelist, Z1 systems are listed at the top of the list
and in the Z3 version of the nodelist, Z3 systems are listed at the top of the list.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Alan!

*** 13.02.20 at 13:00, Alan Ianson wrote to Martin Foster:

Before I set about updating the OpenXP help file, I would be obliged if
someone could confirm that z3 do actually create their own version of the
world nodelist.

Yes they do. I grabbed a nodelist from Z3 and it does start listing nodes in Z3 bofore the others.

Many thanks for confirming that.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Stephen!

*** 14.02.20 at 11:41, Stephen Walsh wrote to Martin Foster:

are released each week, along with their corresponding nodediffs.
One for use in Z1, one for use in Z2 and one for use in Z3.

Before I set about updating the OpenXP help file, I would be obliged
if someone could confirm that z3 do actually create their own version
of the world nodelist.

Additionally, does anyone know if z4 create their own version of the
world nodelist?

Each zone creates there own version of the nodelist.

Thanks for confirming.

If someone was using a zone 2 nodelist, then a zone 2 nodediff is
required to update it.

Yes, precisely :)

The same goes for the other zones.

That should clear up any confusion, thanks :)

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 13.02.20 at 20:06, August Abolins wrote to Martin Foster:

[snip]

Extracting NODEDIFF.038 from H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z38
07.02.20 17:17:02
NODELIST.031: Wrong version of node/point list or diff

Finally, finally, finally, I've figured this out .....

I hate to be the bearer of bad news, ..but right after NODEDIFF.Z45 arrived, it locked up, again! :(

FFS :-((((((((((((
Sorry, just had to say that.

Here are the details:

[snipped]
Didn't see anything wrong in your debuglog, in fact, it's very similar to mine when NODEDIFF.Z45 arrived on my system.

..and promptly locked up at this point.

After another poll a few minutes later, this happens:

[snipped]
Didn't see anything wrong in there either.

..and promptly locks up.

The ONLY way I could prevent the lock up happening with the next
normal poll was by making sure I delete the .TIC file: 0ss71rpr.tic

In all my years(26 of them) of using OpenXP, FreeXP, XP2 and CrossPoint,
I've never ever come across anything quite like this before - Hmph!

..which contained:

[snipped]
Everything looked good in there.

The new updated nodelist number in oxp looks good:

+----------------------------------------------------------------------+
Ý Z2PNT.### 038 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist Ý
Ý NODELIST.### 045 NODEDIFF.### NODEDIFF.Z## Diff Nodelist Ý
Ý Ý

Yep, nothing wrong with that.

The top few lines of NODELIST.045 look like:

;A FidoNet Nodelist for Friday, February 14, 2020 -- Day number 045 : 12455 ;Aú
;A MakeNL 3.4.5 (Win32)ú
;Aú
;A The FidoNet NodeList, a listing of the systems within FidoNet.ú
;Aú
;A This is the nodelist produced at 2:2/0ú

Yep, same as my copy.

SEE? So.. the .TIC file in /FILES *could* be a problem.

Therefore, maybe I should disable "THIS" below?:

+- Fido Options ---------------------------------+
Ý Ý
Ý Int. dial prefix 00 Ý
Ý Nat. dial prefix 0 Ý
Ý Your dialing code 49-631 Ý
Ý Ý
Ý [x] Import nodelist updates automatically Ý
Ý [ ] Delete empty messages Ý
Ý [x] Automatic TIC file processing Ý<==THIS?
Ý [x] Hold requests if files are missing Ý

Maybe the system is trying to create "Area NODEDIFZ" and is failing?
Bug?

All I can suggest you do is to disable it and see what happens next
Friday. I have it disabled, so I'll enable it and see what happens here
next Friday.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 14/02/2020 3:08 a.m., Wilfred van Velzen : August Abolins wrote:

 AA> I found this one from 3:712/0


 AA> ;A FidoNet Nodelist for Friday, February 7, 2003 -- Day number 038
: 07643
 AA> ;A
 AA> ;A The FidoNet NodeList is a listing of the members of FidoNet.
 AA> ;A
 AA> ;A Copyright of the contributing coordinators of FidoNet Zone 3.

I guess some people didn't get the "memo"?: /

Maybe you missed the "2003" part above?

Not "me"! ;) I saw the date, and gaped in surprised.

I just freq'd for NODELIST from my OXP system and that's what I got.

I first tried a couple of higher up 3:3/* systems but was not offered
anything. Maybe it's a "no points allowed" thing.


--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello Martin!

On 14/02/2020 7:04 a.m., Martin Foster : August Abolins wrote:

I hate to be the bearer of bad news,.. but right after
NODEDIFF.Z45 arrived, it locked up, again!

FFS :-(((((((((((( Sorry, just had to say that.

^^^
Another new brit term for me. We use WTF here. ;)

In all my years(26 of them) of using OpenXP, FreeXP, XP2 and
CrossPoint, I've never ever come across anything quite like this
before - Hmph!

Yes.. I seem to have this effect on people and things.


 AA> SEE?   So.. the .TIC file in /FILES *could* be a problem.
 AA> Maybe the system is trying to create "Area NODEDIFZ" and is failing?
 AA> Bug?

All I can suggest you do is to disable it and see what happens
next Friday. I have it disabled, so I'll enable it and see what
happens here next Friday.

Another week of s u s p e n c e !

BTW.. The pointdiff arrived a littler later, and processed fine (as it
always has), but this time I forgot to keep the .TIC processing enabled.

I am pretty sure that I have *always* had the tic proccessing enabled,
but the lockups were only happening with the main nodelist.



--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

14 Feb 20 20:30, you wrote to Wilfred van Velzen:

I first tried a couple of higher up 3:3/* systems but was not offered anything. Maybe it's a "no points allowed" thing.

Frequing "nodelist" from this system should give you the current (Z45) nodelist, and I've not put in
any restrictions.




Stephen


--- GoldED+/LNX 1.1.5-b20170303
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)

Hello August!

*** 14.02.20 at 20:59, August Abolins wrote to Martin Foster:

I hate to be the bearer of bad news,.. but right after
NODEDIFF.Z45 arrived, it locked up, again!

FFS :-(((((((((((( Sorry, just had to say that.

^^^
Another new brit term for me. We use WTF here. ;)

So do we but FFS is a rather more emphatic version of WTF ;)

[snip]

All I can suggest you do is to disable it and see what happens
next Friday. I have it disabled, so I'll enable it and see what
happens here next Friday.

Another week of s u s p e n c e !

Yep, stay tooooned for the next thrilling episode :-)

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Frequing "nodelist" from this system should give you the current (Z45) nodelist, and I've not put in
any restrictions.

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon as I save this message. Let me know if you detect a request!

--- D'Bridge 4
* Origin: Mans Mazais Eiropas D'Bridge Punkts (2:221/1.59)

Hi! August,

On 02/18/2020 01:37 AM, you wrote to Stephen Walsh:

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon as I save
this message. Let me know if you detect a request!

How did you go with your attempts to my main node the other day? As near as I figure you received an error response, twice. A FREQ for either NODELIST or Z3DAILY should have succeeded.

What happened?

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello Paul!

** 17.02.20 - 23:50, Paul Quinn wrote to August Abolins:

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon as I save
this message. Let me know if you detect a request!

How did you go with your attempts to my main node the other day? As near
as I figure you received an error response, twice. A FREQ for either
NODELIST or Z3DAILY should have succeeded.

What happened?

The freq for NODELIST from my 2:221/1.59 (D'Bridge) system, seemed to connect, but it disconnected immediately.

The freq for NODELIST from my 2:221/1.58 (OpenXp) system was more
eventful. I received a file named, respff85.txt, containing:

--[begin]--
Hi! Sysop,

Here is the result of your request(s):

Requested "NODELIST":
- nodelist.z91 (currently not available)
- nodelist.z91NODELIST.Z91 (currently not available)
- nodelist.z84NODELIST.Z84 (currently not available)
- nodelist.z77NODELIST.Z77 (currently not available)

Totals:
- 0 files
- 0 Bytes


File requests are available for these magic file names:
allfiles/files Latest listing of all FREQ-able files.
Begin3 A fun old Windows game, I'm told... I never played it.
crashmail CrashMail II 0.71 tosser.
fidonews or SNOOZE latest weekly Fidonews issue.
jamnntpd JamNNTPd 1.0 by Johan Billing & optional perl scripts.
mfreq mfreq tools for FTS file requesting, by Markus Reschke.
nl2binkd nl2binkd by Markus Reschke (Fidonet 2:240/1661).
nodelist The _latest_ Zone 3 nodelist.
z3daily The latest all zones *_daily_* nodelist.

Reasonable FREQs _will_be_ honoured during ZMH: 0300-0400AEST.
(limits: Files 20 Bytes 900MB)

Reasonable FREQs _will_be_ honoured during ZMH: 0300-0400AEST.

Cheers,
Paul.
--[end]--

BUT, I didn't receive any nodelist file.

These are the highlights of that transaction:

(All lines = date 2020-02-17 below)

16:03:24 xpnetcall: function Netcall, BoxName:<3:54/0>, PerformDial: True, DialOnlyOnce: False, FidoCrash: True
16:03:24 xpncfido: fido netcall starting: 2:221/1
16:03:25 xpncfido: server file name is 02210001, boxname 2:221/1
16:03:25 xpncfido: AKAs: 2:221/1.58@fidonet
16:03:25 xpncfido: Outgoing files: 00360000.REQ
16:03:25 ObjCOM: Pquinnsrock.nodelist.net:24555:24554 S57600 8N1
16:03:28 ncmodem: Log: = CONNECT
16:03:28 netcall: Output mcVerbose: Authenticating...
16:03:29 ncmodem: Log: OPT CRAM-MD5-9bab755b9c3255033677f8cc2872b8ee
16:03:29 ncmodem: Log: SYS Quinn's Rock
16:03:29 ncmodem: Log: ZYZ Paul Quinn
16:03:29 ncmodem: Log: LOC Maryborough, Queensland, Australia
16:03:29 ncmodem: Log: NDL MO,CM,IBN:24555
16:03:29 ncmodem: Log: TIME Tue, 18 Feb 2020 07:02:57 +1000
16:03:29 ncmodem: Log: VER binkd/1.0a-551/Linux binkp/1.1
16:03:29 ncfido: got binkp frame M_ADR 3:640/1384@fidonet 3:54/0@fidonet 16:03:30 ncmodem: Log: OPT EXTCMD GZ BZ2
16:03:30 ncfido: sent binkp command frame M_FILE 00360000.REQ 10 1581955406 0, size 29
16:03:31 ncfido: got binkp frame M_GOT 00360000.REQ 10 1581955406
16:03:31 ncmodem: Log: * Sent 00360000.REQ, 10b
16:03:33 ncfido: got binkp frame M_FILE respff85.txt 1313 1581973381 0
16:03:33 netcall: Output mcVerbose: Receiving respff85.txt
16:03:34 netcall: Output mcVerbose: Receiving respff85.txt 100%
16:03:34 ncfido: sent binkp command frame M_GOT respff85.txt 1313 1581973381, size 29
16:03:34 netcall: Output mcInfo: respff85.txt received
16:03:34 ncmodem: Log: * Rcvd respff85.txt, 1313b

../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hi! August,

On 02/18/2020 09:19 AM, you wrote:

PQ>What happened?

Thank you for your full report.

The freq for NODELIST from my 2:221/1.58 (OpenXp) system was more
eventful. I received a file named, respff85.txt, containing:

Okay. When all else fails that will happen.

Requested "NODELIST":
- nodelist.z91 (currently not available)
- nodelist.z91NODELIST.Z91 (currently not available)
- nodelist.z84NODELIST.Z84 (currently not available)
- nodelist.z77NODELIST.Z77 (currently not available)

These statements are true. I only keep the three most recent weekly lists, together with the six most recent -daily- lists. OTOH these reported lists are
totally out of date. Weird.

BUT, I didn't receive any nodelist file.

I am disappointed by this. The system has worked well for many years already.
It needs fixing, which I will start on later today. Unfortunately the author of
the system left Fidonet recently, so I am hamstrung WRT expert assistance.

I apologise for its failure.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello Paul,

Requested "NODELIST":
- nodelist.z91 (currently not available)
- nodelist.z91NODELIST.Z91 (currently not available)
- nodelist.z84NODELIST.Z84 (currently not available)
- nodelist.z77NODELIST.Z77 (currently not available)

These statements are true. I only keep the three most recent weekly lists, together with the six most recent -daily- lists. OTOH these reported lists are totally out of date. Weird.

Looks like mfreq-index is failing to run, maybe?

Unfortunately the author of the system left Fidonet recently, so I am hamstrung WRT expert assistance.

I think you are the expert assistance now.. :)

Is there a windows build of mfreq?

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello Paul!

** 18.02.20 - 01:44, Paul Quinn wrote to August Abolins:

BUT, I didn't receive any nodelist file.

I am disappointed by this. The system has worked well for many years
already. It needs fixing, which I will start on later today.
Unfortunately the author of the system left Fidonet recently, so I am
hamstrung WRT expert assistance.

Like Alan said, YOU are the expert now! ;)

I apologise for its failure.

I'm glad my report was helpful. I am sure you will figure it out!



../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hello August!

17 Feb 20 10:37, you wrote to me:

Frequing "nodelist" from this system should give you the current
(Z45) nodelist, and I've not put in any restrictions.

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon as I
save this message. Let me know if you detect a request!

Besides taking a long time and showing an error, it looks like it worked!


17-Feb-2020 00:59:23 mbcico[28157] MBCICO v1.0.7.13
17-Feb-2020 00:59:23 mbcico[28157] Cmd: mbcico -t ibn
+ 17-Feb-2020 00:59:23 mbcico[28157] Options: Call WaZOO EMSI Freqs Zmodem ZedZap Hydra PLZ GZ/BZ2 NoNR CRC
+ 17-Feb-2020 00:59:23 mbcico[28157] Incoming IBN/TCP connection from 67.69.69.34
+ 17-Feb-2020 00:59:23 mbcico[28157] Start inbound Binkp session
+ 17-Feb-2020 00:59:23 mbcico[28157] Binkp: start session
+ 17-Feb-2020 00:59:23 mbcico[28157] System : /|ug's Point
+ 17-Feb-2020 00:59:23 mbcico[28157] Sysop : August Abolins
+ 17-Feb-2020 00:59:23 mbcico[28157] Uses : OpenXP/5.0.43/Win32 binkp/1.1
+ 17-Feb-2020 00:59:23 mbcico[28157] address : 2:221/1.58@fidonet
+ 17-Feb-2020 00:59:23 mbcico[28157] Options: Call WaZOO EMSI Freqs Zmodem ZedZap Hydra PLZ GZ/BZ2 NoNR CRC
+ 17-Feb-2020 00:59:24 mbcico[28157] Binkp: MD5 unprotected session
+ 17-Feb-2020 00:59:24 mbcico[28157] Binkp: mail 0, files 0 bytes
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: receive file "02790118.REQ" date Feb 16 19:59:24 size 10 offset
0 comp No
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: OK 10 bytes received in 0.001 seconds (9.766 Kb/s)
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: receiver starts batch 2
+ 17-Feb-2020 00:59:26 mbcico[28157] Magic request: nodelist (update ((null)), password "(null)")
+ 17-Feb-2020 00:59:26 mbcico[28157] File request : NODELIST.Z45 (update ((null)), password "(null)")
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: mail 0, files 46840 bytes
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: send "/opt/mbse/tmp/5A0A8435.rpl" as "5A0A8437.PKT"
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: size 791 bytes, dated Feb 17 00:59:26, comp No
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: OK 791 bytes sent in 0.001 seconds (772.461 Kb/s)
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: send "/opt/mbse/ftp/pub/fidonet/nodelist/nodelist.z45" as
"nodelist.z45"
+ 17-Feb-2020 00:59:26 mbcico[28157] Binkp: size 46049 bytes, dated Feb 14 11:00:06, comp No
+ 17-Feb-2020 00:59:28 mbcico[28157] Binkp: OK 46049 bytes sent in 1.292 seconds (34.806 Kb/s)
? 17-Feb-2020 01:07:59 mbcico[28157] tty_read: hanged_up flag
? 17-Feb-2020 01:07:59 mbcico[28157] Binkp: receiver status Hangup
+ 17-Feb-2020 01:07:59 mbcico[28157] Binkp: session finished, rc=108
+ 17-Feb-2020 01:08:01 mbcico[28157] Incoming call failed (rc=108)
+ 17-Feb-2020 01:08:01 mbcico[28157] Terminated with error 108
+ 17-Feb-2020 01:08:01 mbcico[28157] Sent 46840 bytes, received 10 bytes, avg 90 cps
+ 17-Feb-2020 01:08:01 mbcico[28157] Connected 8:38
17-Feb-2020 01:08:01 mbcico[28157] MBCICO finished in 8:38





Stephen


--- GoldED+/LNX 1.1.5-b20170303
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)

Hello Stephen!

** 18.02.20 - 12:40, Stephen Walsh wrote to August Abolins:

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon as I
save this message. Let me know if you detect a request!

Besides taking a long time and showing an error, it looks like it worked!

Not really! :( Here is a copy of the session as recorded from my side:

11:09:31 xpncfido: Processing sendaka 2:221/1
11:09:31 xpncfido: server file name is 02210001, boxname 2:221/1
11:09:31 xpncfido: AKAs: 2:221/1.58@fidonet
11:09:31 xpncfido: Converted files:
11:09:31 xpncfido: Outgoing files: 02790118.REQ
11:09:31 netcall: Output mcVerbose: Opening comm channel
11:09:31 ObjCOM: Pftn633.vk3heg.net:24554 S57600 8N1
11:09:31 ncmodem: Log: = CONNECT
11:09:31 netcall: Output mcVerbose: Authenticating...
11:09:31 ncfido: sent binkp command frame M_NUL SYS /|ug's Point, size 17 11:09:31 ncfido: sent binkp command frame M_NUL ZYZ August Abolins, size 19 11:09:31 ncfido: sent binkp command frame M_NUL VER OpenXP/5.0.43/Win32 binkp/1.1, size 34
11:09:31 ncfido: sent binkp command frame M_ADR 2:221/1.58@fidonet, size 19 11:09:32 ncmodem: Log: OPT CRAM-MD5-32dc1f817755e68e01acef216ad5bf34
11:09:32 ncmodem: Log: OPT CRC
11:09:32 ncmodem: Log: SYS Dragon's Claw FTN HUB
11:09:32 ncmodem: Log: ZYZ Stephen Walsh
11:09:32 ncmodem: Log: LOC Melbourne, Australia
11:09:32 ncmodem: Log: NDL IBN,IFC,ITN,XX,CM
11:09:32 ncmodem: Log: TIME Tue, 18 Feb 2020 03:09:29 +1100
11:09:32 ncmodem: Log: VER mbcico/1.0.7.13/GNU/Linux-x86_64 binkp/1.1 11:09:32 ncmodem: Log: PHN ftn.vk3heg.net
11:09:32 ncfido: got binkp frame M_ADR 3:633/280@fidonet 3:633/0@fidonet
39:901/280@amiganet 39:901/0@amiganet 46:3/101@agoranet 21:1/195@fsxnet 11:09:32 ncfido: binkp session setup state 2
11:09:32 ncfido: Challenge: 32dc1f817755e68e01acef216ad5bf34
11:09:33 ncmodem: Log: non-secure
11:09:33 netcall: Output mcInfo: Secure authentication successful
11:09:33 ncmodem: Log: OPT EXTCMD GZ BZ2 PLZ CRC
11:09:33 ObjCOM: CharCount: 13 bytes
11:09:33 ncmodem: Log: TRF 0 0
11:09:33 netcall: Output mcInfo: Sending 02790118.REQ
11:09:34 ncfido: got binkp frame M_GOT 02790118.REQ 10 1581937772
11:09:34 ncfido: got binkp frame M_FILE 5A0A8644.PKT 796 1581955771 0
11:09:34 ncfido: got binkp frame M_FILE nodelist.z45 46049 1581638406 0 11:09:34 ncmodem: Log: * Sent 02790118.REQ, 10b
11:09:34 netcall: Output mcInfo: Sent 02790118.REQ
11:09:35 ncfido: got binkp frame M_EOB
11:09:35 ncfido: binkp txstate TxGNF => TxDone
11:16:37 xpcrt: KeyPressed: 67 46 3 3
11:16:37 xpcrt: ReadKey: 3
11:16:37 xpcrt: KeyPressed: 67 46 3 3
11:16:37 xpcrt: ReadKey: 3
11:16:37 maus2: mouse moved (buttons=0x00000000)

..But, after 11:09:33 when the .REQ file was sent, I never received the
nodelist.z45. I killed the session manually after about 8 minutes of
inactivity at the 11:16:37 mark.

:(

BTW, the above is from my OpenXP system, 2:221/1.58.
My other system, D'Bridge as 2:221/1.59, seemed to connect briefly, but
then the connection dropped immediately.

:(





../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hi! Alan,

On 02/18/2020 10:02 AM, you wrote:

PQ> These statements are true. I only keep the three most recent weekly
PQ> lists, together with the six most recent -daily- lists. OTOH these
PQ> reported lists are totally out of date. Weird.

Looks like mfreq-index is failing to run, maybe?

Give the man a cigar! :)

PQ> Unfortunately the author of the system left Fidonet recently, so I am
PQ> hamstrung WRT expert assistance.

I think you are the expert assistance now.. :)

Dammit, yeah. I miss Markus (the author). BTW, I'm willing to share my configs with anyone. T'ain't no secrets.

Is there a windows build of mfreq?

You bet. Fred Riccio (1:132/174@fidonet) did a beauty that mirrors a DOS BATch solution I used for BinkleyTerm/W32, binkD, Argus and finally with Radius
(till I found the voodoo to make it do FREQs 'au natural').

Fred's is called FREQ-U. He claims versons for Unix and Mac as well as Windows. It's FREQ-able here as FU_32 (with or without the .zip siffix). It's
dated from 2007, so you might like to chase him for a later version?

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hi! August,

On 02/18/2020 10:29 AM,you wrote:

Like Alan said, YOU are the expert now! ;)

Crikey! Yep, oh right: ex-spurt. ;)

PQ>I apologise for its failure.

I'm glad my report was helpful. I am sure you will figure it out!

Alan got it first. By an half-hour. :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

17 Feb 20 21:16, you wrote to me:

I will try a FREQ with D'Bridge to your 3:633/280 addr as soon
as I save this message. Let me know if you detect a request!

Besides taking a long time and showing an error, it looks like it
worked!

Not really! :( Here is a copy of the session as recorded from my
side:

[...]

BTW, the above is from my OpenXP system, 2:221/1.58.
My other system, D'Bridge as 2:221/1.59, seemed to connect briefly,
but then the connection dropped immediately.

Just heard back from the hosting provider for my server. They had some scumbag doing a DDS on the network.

Things have now settled down, so perhaps try again.




Stephen


--- GoldED+/LNX 1.1.5-b20170303
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)

Hello Martin!

** 15.02.20 - 10:48, Martin Foster wrote to August Abolins:

Another week of s u s p e n c e !

Yep, stay tooooned for the next thrilling episode :-)

This week's nodediff arrived, processed, and succeeded (with TIC
processing DISABLED) ..and no lockup!

= 18:59:00 CONNECT
18:59:00 OPT CRAM-MD5-85d5178717594d4d3eb75f9faf5b92ee
18:59:00 SYS RBB/2
18:59:00 ZYZ Tommi Koivula
18:59:00 LOC Lake Ylo, Finland
18:59:00 NDL IBN,CM
18:59:00 PHN rbb.fidonet.fi
18:59:00 TIME Fri, 21 Feb 2020 01:58:54 +0200
18:59:00 VER binkd/1.1a-99.1/OS2 binkp/1.1
18:59:01 TRF 0 2457
18:59:01 OPT EXTCMD GZ BZ2
18:59:01 secure
* 18:59:01 Rcvd NODEDIFF.Z52, 1645b
* 18:59:01 Rcvd 0ssk0o0o.tic, 812b
= 18:59:02 hangup
- 18:59:02 exiting

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 045 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 052 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³


Waiting for your results with the "TIC" processor enabled.



../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hello Stephen!

*** 19.02.20 at 12:42, Stephen Walsh wrote to August Abolins:

[snip]

Just heard back from the hosting provider for my server. They had some scumbag doing a DDS on the network.

Ah, that might explain why I've been having problems f'reqing "NODELIST"
from your system with WinPoint.

Things have now settled down, so perhaps try again.

I tried it again with WinPoint using my 2:240/2188.31 AKA on 20.02.20,
here's what happened .....

---------- 8< ----------
20.02.20 09:17:28 TBNK Using BinkP protocol
20.02.20 09:17:28 DSYS Connecting to Stephen Walsh (Net-633-Hub)(3:633/280) 20.02.20 09:17:28 HOST Connecting to host ftn633.vk3heg.net:24554
20.02.20 09:17:28 MAKE Making Connection
20.02.20 09:17:29 CONN Connected
20.02.20 09:17:30 BNUL OPT CRAM-MD5-3ccc050072a86ed7e3f13668b10d60ff
20.02.20 09:17:30 BNUL OPT CRC
20.02.20 09:17:30 RSYS Dragon's Claw FTN HUB
20.02.20 09:17:30 RSOP Stephen Walsh
20.02.20 09:17:30 RLOC Melbourne, Australia
20.02.20 09:17:30 RFLG IBN,IFC,ITN,XX,CM
20.02.20 09:17:30 BNUL TIME Thu, 20 Feb 2020 20:17:29 +1100
20.02.20 09:17:30 RVER mbcico/1.0.7.13/GNU/Linux-x86_64 binkp/1.1
20.02.20 09:17:30 BNUL PHN ftn.vk3heg.net
20.02.20 09:17:30 RAKA 3:633/280 - Sending 10 bytes in 1 files
20.02.20 09:17:30 RAKA 3:633/0 - Nothing to send
20.02.20 09:17:30 RAKA 39:901/280 - Nothing to send
20.02.20 09:17:30 RAKA 39:901/0 - Nothing to send
20.02.20 09:17:30 RAKA 46:3/101 - Nothing to send
20.02.20 09:17:30 RAKA 21:1/195 - Nothing to send
20.02.20 09:17:31 SESS Session established, remote reports "non-secure" 20.02.20 09:17:31 SEND Sending 02790118.req (10 bytes)
20.02.20 09:17:31 BNUL OPT EXTCMD GZ BZ2 PLZ CRC
20.02.20 09:17:31 BNUL TRF 0 0
20.02.20 09:17:31 RDON Receive complete
20.02.20 09:17:31 SENT File 02790118.req sent
20.02.20 09:17:31 DELE Deleted 02790118.req
20.02.20 09:17:31 SDON Send complete
20.02.20 09:17:31 SDON Send complete
20.02.20 09:17:31 BNUL TRF 0 46859
20.02.20 09:17:31 RECV Receiving 5A0A8B96.PKT (810 Bytes)
20.02.20 09:17:31 RECD Received 5A0A8B96.PKT
20.02.20 09:17:31 RECV Receiving nodelist.z45 (46049 Bytes)
20.02.20 09:17:32 RECD Received nodelist.z45
20.02.20 09:17:32 RDON Receive complete
20.02.20 09:17:32 SDON Send complete
20.02.20 09:17:33 RDON Receive complete
20.02.20 09:17:33 ENDS Session complete
20.02.20 09:17:33 DISG Disconnecting
20.02.20 09:17:33 DISC Disconnected
20.02.20 09:17:33 TIME Connected for 4 s
---------- 8< ----------

Kewl! :-))

That leaves me wondering why both August and I are having problems when we try it with OpenXP ??

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin,

That leaves me wondering why both August and I are having problems
when we try it with OpenXP ??

File requests haven't been implemented in binkp mailers as well as they were in
EMSI mailers.

In the case of BBBS, it supports file requests when talking to an EMSI mailer, either over POTS or an ITN mail session.

It will send a file request (an *.req) to a binkp mailer and then hangs up before the remote side can return the file.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello Alan!

*** 13.02.20 at 13:00, Alan Ianson wrote to Martin Foster:

[snip]

Additionally, does anyone know if z4 create their own version of the world
nodelist?

I don't think they do. I grabbed a nodelist from a BBS in Z4 and found it was a Z1 nodelist. I did find an up date ZONE4.Z38 so they are current but no Z4 nodelist that I could find.

A few minutes ago, I grabbed a copy of the current nodelist from Z4C's
system and I can confirm that it's a Z1 version of the nodelist.

I now have all the information I need to update the OpenXP help file and I would like to thank everyone for their input on this matter.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 20.02.20 at 19:04, August Abolins wrote to Martin Foster:

Another week of s u s p e n c e !

Yep, stay tooooned for the next thrilling episode :-)

This week's nodediff arrived, processed, and succeeded (with TIC processing DISABLED) ..and no lockup!

Excellent! :-)

[snip]

Waiting for your results with the "TIC" processor enabled.

[small section of my areas list *before* my poll to Richard]
---------- 8< ----------
/FIDO/FIDOTEST
/FIDO/FTSC_PUBLIC
---------- 8< ----------

[poll to Richard]
---------- 8< ----------
= 09:56:20 CONNECT
09:56:20 OPT CRAM-MD5-82ca5b19a95994ea74548f7e82beeaee
09:56:20 SYS fido.ricsi.priv.at
09:56:20 ZYZ Richard Menedetter
09:56:20 LOC Vienna,Austria
09:56:20 NDL XW,CM,MO,IBN,INA:fido.ricsi.priv.at
09:56:20 TIME Fri, 21 Feb 2020 10:56:19 +0100
09:56:20 VER binkd/1.1a-99/Linux binkp/1.1
09:56:20 TRF 10052 74714
09:56:20 OPT EXTCMD GZ BZ2
09:56:20 secure
* 09:56:20 Rcvd 9af199a1.pkt, 10052b
* 09:56:20 Rcvd 4eb3b600.th0, 14515b
* 09:56:20 Rcvd NODEDIFF.Z52, 1645b
* 09:56:20 Rcvd bj08l13b.tic, 977b
* 09:56:21 Rcvd NODELIST.Z52, 56746b
* 09:56:21 Rcvd bj08l13d.tic, 831b
* 09:56:21 Sent 21095620.PKT, 3021b
= 09:56:21 hangup
- 09:56:21 exiting
---------- 8< ----------

[small section of my areas list *after* my poll to Richard]
---------- 8< ----------
¯/FIDO/FIDOTEST
¯/FIDO/FILES/NODEDIFZ
¯/FIDO/FILES/NODELISZ
/FIDO/FTSC_PUBLIC
---------- 8< ----------

The two new file echo areas were automatically created and both the .tic files were deleted from my FILES directory.

No problems to report but let's see what happens when I pickup the Z2 Pointlist stuff on my next poll and let's also see what happens next
Friday.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello August!

*** 21.02.20 at 12:08, Martin Foster wrote to August Abolins:

[snip]

No problems to report but let's see what happens when I pickup the Z2 Pointlist stuff on my next poll

Two new file echo areas created, both .tic files deleted, no problems to report.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 21/02/2020 7:08 a.m., Martin Foster : August Abolins wrote:

[small section of my areas list *after* my poll to Richard]
---------- 8< ----------
 »/FIDO/FIDOTEST
 »/FIDO/FILES/NODEDIFZ
 »/FIDO/FILES/NODELISZ
 /FIDO/FTSC_PUBLIC
---------- 8< ----------

The two new file echo areas were automatically created and both the .tic files were deleted from my FILES directory.

And, I assume you are running the windows version of OXP?

I don't have a NODEDIFZ or NODELISZ created at all.

OR.. maybe the program *has* been trying to create them but that's when
it locks up?

I *do* have a lowercase "/nodelist" directory, but I had created that
myself.

Could it be that the program expects to operate in C: drive? My OXP is configured in my H: partition.

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

On 21/02/2020 8:17 a.m., Martin Foster : August Abolins wrote:

No problems to report but let's see what happens when I pickup
the Z2 Pointlist stuff on my next poll

Two new file echo areas created, both. tic files deleted, no
problems to report.

Hmmm.... Then, why wasn't it working for me? :( Maybe you have
another "feature" disabled/enabled that overrides the problem?



--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

--- TB68.4.1/Win7 (the abbr. string!)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

*** 21.02.20 at 17:03, August Abolins wrote to Martin Foster:

[snip]

The two new file echo areas were automatically created and both the .tic
files were deleted from my FILES directory.

And, I assume you are running the windows version of OXP?

At the moment yes but I've never had any problems with my Linux install whether the feature is enabled or not.

I don't have a NODEDIFZ or NODELISZ created at all.

OR.. maybe the program *has* been trying to create them but that's when
it locks up?

That could be a possibility because OpenXP writes an empty message in the messagebase every time a new file has been processed in a file echo .....

---------- 8< ----------
EMP: /FIDO/FILES/NODEDIFZ
ABS: FileScan@2:292/854
BET: C:\USERS\MARTIN\OPENXP\FILES\NODEDIFF.Z52
EDA: 20200221095600W+0
MID: 2002210956.1.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:292/854
Zusammenfassung: Fidonet NODEDIFF for this week (ZIP)
X_C:
X-XP-NTP: 30
X-XP-ATT: 0010
F-TO: Fidonet NODEDIFF for this week (ZIP)
LEN: 0

EMP: /FIDO/FILES/NODELISZ
ABS: FileScan@2:292/854
BET: C:\USERS\MARTIN\OPENXP\FILES\NODELIST.Z52
EDA: 20200221095600W+0
MID: 2002210956.2.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:292/854
Zusammenfassung: Fidonet NODELIST for this week (ZIP)
X_C:
X-XP-NTP: 30
X-XP-ATT: 0010
F-TO: Fidonet NODELIST for this week (ZIP)
LEN: 0

EMP: /FIDO/FILES/Z2PNT_D
ABS: FileScan@2:240/1120
BET: C:\USERS\MARTIN\OPENXP\FILES\Z2PNT_D.Z52
EDA: 20200221120900W+0
MID: 2002211209.1.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:240/1120
Zusammenfassung: Z2 PntDiff (Boss) day 052 (21.02.2020)
X_C:
X-XP-NTP: 30
X-XP-ATT: 0010
F-TO: Z2 PntDiff (Boss) day 052 (21.02.2020)
LEN: 0

EMP: /FIDO/FILES/Z2PNT
ABS: FileScan@2:240/1120
BET: C:\USERS\MARTIN\OPENXP\FILES\Z2PNT.Z52
EDA: 20200221120900W+0
MID: 2002211209.2.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:240/1120
Zusammenfassung: Z2 PntList (Boss) day 052 (21.02.2020)
X_C:
X-XP-NTP: 30
X-XP-ATT: 0010
F-TO: Z2 PntList (Boss) day 052 (21.02.2020)
LEN: 0
---------- 8< ----------

So, casting your mind back to the time when you said that you'd had some
sort of messagebase corruption, maybe one of your messagebase files is
still corrupted and maybe OpenXP is trying to write to that messagebase
file but can't.

I *do* have a lowercase "/nodelist" directory, but I had created that myself.

That shouldn't be a problem.

Could it be that the program expects to operate in C: drive? My OXP is configured in my H: partition.

Nope.

I'll try one more week with the TIC feature disabled. If that goes smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 22.02.20 - 09:36, Martin Foster wrote to August Abolins:

That could be a possibility because OpenXP writes an empty message in the
messagebase every time a new file has been processed in a file echo .....

---------- 8< ----------
EMP: /FIDO/FILES/NODEDIFZ
ABS: FileScan@2:292/854
BET: C:\USERS\MARTIN\OPENXP\FILES\NODEDIFF.Z52
EDA: 20200221095600W+0
MID: 2002210956.1.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:292/854
Zusammenfassung: Fidonet NODEDIFF for this week (ZIP)

[snip]

Oh.. OK. I *do* have /NODEDIFZ and /NODELISZ in the oxp "areas menu" on
the main screen. I just don't have them as physical directories under /FILES.

Here are the last known entries in each that I can look at:

OpenXP Re-Org Message Netcall Fido Edit Config Tools ?
All Hold Delete Kill Reference Reply PM User Info Other ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
/FIDO/FILES/NODEDIFZ
F 0 06.02 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z38
F 0 30.01 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z31
F 0 23.01 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z24
F 0 02.01 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z03
F 0 26.12 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z61
F 0 19.12 FileScan Fidonet NODEDIFF fo H:\DOWNLOADS\OPENXP\FILES\NODEDIFF.Z54


OpenXP Re-Org Message Netcall Fido Edit Config Tools ?
All Hold Delete Kill Reference Reply PM User Info Other ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
/FIDO/FILES/NODELIST

no messages


OpenXP Re-Org Message Netcall Fido Edit Config Tools ?
10
All Hold Delete Kill Reference Reply PM User Info Other
E ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
/FIDO/FILES/Z2PNT_D
F 0 07.02 FileScan Z2 PntDiff (Boss) d H:\DOWNLOADS\OPENXP\FILES\Z2PNT_D.Z38


And, I have nothing listed in the /FIDO/FILES/Z2PNT area.

So, casting your mind back to the time when you said that you'd had some
sort of messagebase corruption, maybe one of your messagebase files is
still corrupted and maybe OpenXP is trying to write to that messagebase
file but can't.

I "assumed" that I had message base corruption. According to the built-in helps, it said that I could delete the *.DB1 files and OXP would rebuild
the indexes. But I never manipulated and of the MPUFFER.nn files except
with the usual Re-Org. or Pack.

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

Maybe I should just delete both of the /FIDO/FILES entries above (or just
the /NODELISZ since that is the one that was not processing before), and
do a Re-org and then Pack, and then enable TIC, to get on with this?


../|ug

--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)

Hello Paul!

** 18.02.20 - 07:30, Paul Quinn wrote to August Abolins:

I'm glad my report was helpful. I am sure you will figure it out!

Alan got it first. By an half-hour. :)

UPDATE. It's a freq'ing success:

= 17:57:09 CONNECT
17:57:10 OPT CRAM-MD5-0a8ab915e7d0259d2fc9c6f4bf387cee
17:57:10 SYS Quinn's Rock
17:57:10 ZYZ Paul Quinn
17:57:10 LOC Maryborough, Queensland, Australia
17:57:10 NDL MO,CM,IBN:24555
17:57:10 TIME Sun, 23 Feb 2020 08:56:41 +1000
17:57:10 VER binkd/1.0a-551/Linux binkp/1.1
17:57:13 OPT EXTCMD GZ BZ2
17:57:13 non-secure
* 17:57:14 Sent 00360000.REQ, 10b
* 17:57:17 Rcvd nodelist.z52, 46048b
* 17:57:17 Rcvd respb1ad.txt, 1229b
= 17:57:17 hangup
- 17:57:17 exiting


The Z3 version:

;A Fidonet Nodelist for Friday, February 21, 2020 -- Day number 052 :
58083
;A
;A The FidoNet NodeList is a listing of the members of FidoNet.
;A


../|ug

--- OpenXP 5.0.43
* Origin: .o0O0o.o0O0o.o0O0o.o0O0o.o0O0o.o0O0o. (2:221/1.58)

Hi! August,

On 02/23/2020 09:07 AM, you wrote:

The Z3 version:

;A Fidonet Nodelist for Friday, February 21, 2020 -- Day number 052 : 58083
;A
;A The FidoNet NodeList is a listing of the members of FidoNet.
;A

It looked good from here as well. The 'daily' (available after 10:00) will be even more shiny. ;)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Guts: putting "SYSOP" in your twit filter. (3:640/1384.125)

Hello Paul!

** 23.02.20 - 09:33, Paul Quinn wrote to August Abolins:

Hi! August,

On 02/23/2020 09:07 AM, you wrote:

The Z3 version:

;A Fidonet Nodelist for Friday, February 21, 2020 -- Day number 052 :
58083
;A
;A The FidoNet NodeList is a listing of the members of FidoNet.
;A

It looked good from here as well. The 'daily' (available after 10:00)
will be even more shiny. ;)

Our 14 hour window blows my mind. I'm settling down for ZZZzzz...'s in a
few hours, you are just starting your day, tomorrow already!

I should also point out that the message file that your system delivered appears to be a bit mundged inside:

-[cut]-
Hi! Sysop,

Here is the result of your request(s):

Requested "NODELIST":
- nodelist.z52 (44 kB)
- nodelist.z52NODELIST.Z52 (currently not available)
- nodelist.z45NODELIST.Z45 (currently not available)
- nodelist.z38NODELIST.Z38 (currently not available)

Totals:
- 1 files
- 44 kB
-[cut]-





../|ug

--- OpenXP 5.0.43
* Origin: .o0O0o.o0O0o.o0O0o.o0O0o.o0O0o.o0O0o. (2:221/1.58)

Hi! August,

On 22 Feb 20 20:04, you wrote to me:

I should also point out that the message file that your system
delivered appears to be a bit mundged inside:

Requested "NODELIST":
- nodelist.z52 (44 kB)
- nodelist.z52NODELIST.Z52 (currently not available)
- nodelist.z45NODELIST.Z45 (currently not available)
- nodelist.z38NODELIST.Z38 (currently not available)

You may have to accept that the request server just doesn't like you. ;)

(P.S. I'll keep an eye on it. It may take a while for the index file(s) to resume their normal size/shape. Ta, muchly.)

Cheers,
Paul.

... Heh heh. Locked my coathanger in the car. Good thing I had a key.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hello Alan!

*** 21.02.20 at 11:54, Martin Foster wrote to Alan Ianson:

[snip]

I now have all the information I need to update the OpenXP help file and
I would like to thank everyone for their input on this matter.

Updated for the next release.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 22.02.20 - 09:36, Martin Foster wrote to August Abolins:

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

The NODEDIFF applied successfully:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 052 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 059 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³


The Z2PNT_D should go smoothly, like it always has.

This is with "Automatic TIC processing" disabled here.


../|ug

--- OpenXP 5.0.43
* Origin: .o0O0o.o0O0o.o0O0o.o0O0o.o0O0o.o0O0o. (2:221/1.58)

Hello August!

*** 22.02.20 at 10:24, August Abolins wrote to Martin Foster:

That could be a possibility because OpenXP writes an empty message in
the messagebase every time a new file has been processed in a file echo
.....

---------- 8< ----------
EMP: /FIDO/FILES/NODEDIFZ
ABS: FileScan@2:292/854
BET: C:\USERS\MARTIN\OPENXP\FILES\NODEDIFF.Z52
EDA: 20200221095600W+0
MID: 2002210956.1.Tick@2:310/31
ROT: 2:310/31!2:240/5832!2:292/854
Zusammenfassung: Fidonet NODEDIFF for this week (ZIP)

[snip]

Oh.. OK. I *do* have /NODEDIFZ and /NODELISZ in the oxp "areas menu" on the main screen. I just don't have them as physical directories under /FILES.

Neither do I because OpenXP doesn't create separate directories for file echos, it just dumps everything in the FILES directory and, over time,
things can get a bit cluttered.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 22.02.20 - 09:36, Martin Foster wrote to August Abolins:

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

This is now the THIRD week of smooth operations.


The arrivals:

20:29:34 TIME Fri, 13 Mar 2020 02:29:30 +0200
* 20:29:36 Rcvd NODEDIFF.Z73, 1406b
* 20:29:36 Rcvd 0stmwg7o.tic, 812b

08:21:11 TIME Fri, 13 Mar 2020 14:21:08 +0200
* 08:21:12 Rcvd Z2PNT_D.Z73, 901b
* 08:21:12 Rcvd 0stntkop.tic, 717b


And, the result:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 073 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 073 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³



../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello August!

*** 15.03.20 at 18:22, August Abolins wrote to Martin Foster:

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

This is now the THIRD week of smooth operations.

The arrivals:

20:29:34 TIME Fri, 13 Mar 2020 02:29:30 +0200
* 20:29:36 Rcvd NODEDIFF.Z73, 1406b
* 20:29:36 Rcvd 0stmwg7o.tic, 812b

08:21:11 TIME Fri, 13 Mar 2020 14:21:08 +0200
* 08:21:12 Rcvd Z2PNT_D.Z73, 901b
* 08:21:12 Rcvd 0stntkop.tic, 717b

And, the result:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 073 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 073 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³

Excellent and methinks it's now time to "bite the bullet" ;-)

I'd like you to do the following please .....

[1] Delete the /FIDO/FILES/* message areas but needless to say, if
there's any mail in any of them, you'll need to delete that first.

[2] Delete everything in your FILES directory but make any necessary
backups first.

[3] Enable "Automatic TIC file processing" in "Fido -> Options".

[4] Make sure that "Delete update after processing" is *disabled* in
all your nodelist/pointlist configs.

I await the outcome with bated breath :-))

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 16.03.20 - 14:10, Martin Foster wrote to August Abolins:

[1] Delete the /FIDO/FILES/* message areas but needless to say, if
there's any mail in any of them, you'll need to delete that first.

DONE.

[2] Delete everything in your FILES directory but make any necessary
backups first.

I just renamed FILES to FILES-ORIG, and created a new FILES.

[3] Enable "Automatic TIC file processing" in "Fido -> Options".

DONE.

[4] Make sure that "Delete update after processing" is *disabled* in
all your nodelist/pointlist configs.

DONE.

I await the outcome with bated breath :-))

I will keep breathing.


../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello Martin!

** 16.03.20 - 14:10, Martin Foster wrote to August Abolins:

Excellent and methinks it's now time to "bite the bullet" ;-)

The Z2PNT_D arrived and processed ok. OXP continued to work. No lockup.

The NODEDIFF hasn't arrived yet.



../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello Martin!

** 16.03.20 - 14:10, Martin Foster wrote to August Abolins:

Excellent and methinks it's now time to "bite the bullet" ;-)

I'd like you to do the following please .....

[1] Delete the /FIDO/FILES/* message areas but needless to say, if
[2] Delete everything in your FILES directory but make any necessary
[3] Enable "Automatic TIC file processing" in "Fido -> Options".
[4] Make sure that "Delete update after processing" is *disabled* in

I await the outcome with bated breath :-))

The 2nd part (the NODEDIFF) came through later today, and everything
seemed to go well.

RESULT: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 080 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 080 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³


The corresponding message areas, FIDO/FILES/NODEDIFF and FIDO/FILES/
Z2PNT_D were recreated. The contents contain "messages" that are copies
of the diff files.

The file directory /FIDO contains the incoming .Z80 diff files.

How did it go with your Linux versions?


../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello August!

*** 20.03.20 at 21:03, August Abolins wrote to Martin Foster:

Excellent and methinks it's now time to "bite the bullet" ;-)

I'd like you to do the following please .....

[1] Delete the /FIDO/FILES/* message areas but needless to say, if
[2] Delete everything in your FILES directory but make any necessary
[3] Enable "Automatic TIC file processing" in "Fido -> Options".
[4] Make sure that "Delete update after processing" is *disabled* in

I await the outcome with bated breath :-))

The 2nd part (the NODEDIFF) came through later today, and everything seemed to go well.

RESULT: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Z2PNT.### 080 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist ³
³ NODELIST.### 080 NODEDIFF.### NODEDIFF.Z## Diff Nodelist ³
³ ³

The corresponding message areas, FIDO/FILES/NODEDIFF and FIDO/FILES/ Z2PNT_D were recreated. The contents contain "messages" that are copies of the diff files.

The file directory /FIDO contains the incoming .Z80 diff files.

Well, that's a relief and I'm really really pleased for you.

I'm assuming that the .tic files were deleted?

How did it go with your Linux versions?

Same as it always goes, it didn't work :(

TIC processing has been broken in the Linux version for a very long time.
I don't know exactly when it broke or the circumstances under which it
broke but it's a completely different scenario to the one which you've experienced. One day, I might just get around to trying to figure it out
but AFAIC personally, it's of low priority.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 21.03.20 - 10:37, Martin Foster wrote to August Abolins:

I'm assuming that the .tic files were deleted?

Yes. I saw the .tic files during the transfer, but they were deleted automatically after everything settled down.

TIC processing has been broken in the Linux version for a very long time.

[snip]


At least you have a work-around: delete the .tic files manually.


../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello August!

*** 21.03.20 at 08:28, August Abolins wrote to Martin Foster:

I'm assuming that the .tic files were deleted?

Yes. I saw the .tic files during the transfer, but they were deleted automatically after everything settled down.

Excellent! :)

TIC processing has been broken in the Linux version for a very long
time.

[snip]

At least you have a work-around: delete the .tic files manually.

Hmmmmm, I wish it were that simple but there's much more to it than that.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** 24.03.20 - 13:10, Martin Foster wrote to August Abolins:

TIC processing has been broken in the Linux version for a very long
time.

[snip]

At least you have a work-around: delete the .tic files manually.

Hmmmmm, I wish it were that simple but there's much more to it than that.

You mean.. you still get a lockup even when .tic processing is turned off?


../|ug

--- OpenXP 5.0.43
* Origin: û › Ÿ (2:221/1.58)

Hello August!

*** 24.03.20 at 17:40, August Abolins wrote to Martin Foster:

TIC processing has been broken in the Linux version for a very long
time.

[snip]

At least you have a work-around: delete the .tic files manually.

Hmmmmm, I wish it were that simple but there's much more to it than
that.

You mean.. you still get a lockup even when .tic processing is turned
off?

No, I don't get a lockup under any circumstances.

With TIC processing enabled, it makes no difference to when it's disabled.
In other words, the switch does absolutely nothing.

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

Hello Martin!

** On 22.02.20 - 09:36, Martin Foster wrote to August Abolins:

Regarding our discussion about the NODEDIFZ and Z2PND_D areas...

That could be a possibility because OpenXP writes an empty message in the
messagebase every time a new file has been processed in a file echo .....

---------- 8< ----------
/FIDO/FILES/NODELISZ
/FIDO/FILES/Z2PNT_D
---------- 8< ----------

..OK, those are the file areas. And they contain a convenient way to
"view" and even E(x)tract the archives. Very nice!

..SO, are the corresponding "empty message"s that you mention in one of
the MPUFFER.nn files?

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

:::::::::
UPDATE ::
:::::::::

TIC processing has been enabled for several weeks now. Operations are
going smoothly.

BUT... I encountered another "nodelist improper sequence" or something
after I had manually updated my FSXNET nodelist.

I think I know what the problem was.. but I'll describe that in another thread.


../|ug

--- OpenXP 5.0.43
* Origin: ----------Do Not Fold, Spindle or Mutilate.---------- (2:221/1.58)

Hello August!

*** Thursday 23.04.20 at 18:37, August Abolins wrote to Martin Foster:

Regarding our discussion about the NODEDIFZ and Z2PND_D areas...

That could be a possibility because OpenXP writes an empty message in
the messagebase every time a new file has been processed in a file echo
.....

---------- 8< ----------
/FIDO/FILES/NODELISZ
/FIDO/FILES/Z2PNT_D
---------- 8< ----------

..OK, those are the file areas. And they contain a convenient way to "view" and even E(x)tract the archives. Very nice!

Yes and a very quick and handy way of reading such things as FidoNews.

..SO, are the corresponding "empty message"s that you mention in one of the MPUFFER.nn files?

Yes.

I'll try one more week with the TIC feature disabled. If that goes
smoothly, I will enable it.

Looking forward to the next thrilling installment :-)

:::::::::
UPDATE ::
:::::::::

TIC processing has been enabled for several weeks now. Operations are going smoothly.

Excellent!

Regards,
Martin

--- OpenXP 5.0.43
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 24/04/2020 6:49 a.m., Martin Foster : August Abolins wrote:

---------- 8< ----------
/FIDO/FILES/NODELISZ /FIDO/FILES/Z2PNT_D
---------- 8< ----------

..OK, those are the file areas. And they contain a convenient
way to "view" and even E(x)tract the archives. Very nice!

Yes and a very quick and handy way of reading such things as
FidoNews.

I was getting settled to hook up with the fnews_publish echo that only contained
the newsletter separated into separate messages for each page of the edition. Sometimes I am just interested to go directly to a specific heading/section.

But since the "09 Mar 2020: edition, the auto-posts stopped. :(

In this case, the more reliable delivery would be the file echo.

OXP to the rescue.


--
Kad esat sagriezis maizi, to vairs nevarat salikt.

--- TB(Stealth)/Win7
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hi August,

On 2020-04-24 20:20:43, you wrote to Martin Foster:

I was getting settled to hook up with the fnews_publish echo that only contained the newsletter separated into separate messages for each
page of the edition. Sometimes I am just interested to go directly to
a specific heading/section.

But since the "09 Mar 2020: edition, the auto-posts stopped. :(

I'm getting the weekly publications in the FNEWS_PUBLISH area just fine!?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred!

** On 24.04.20 - 20:47, Wilfred van Velzen wrote to August Abolins:

I was getting settled to hook up with the fnews_publish echo..

[snip]

But since the "09 Mar 2020: edition, the auto-posts stopped. :(

I'm getting the weekly publications in the FNEWS_PUBLISH area just fine!?

Maybe it's just the JamNNTP feed. Hey Tommi.. Wassup wid dat?

Last entry by the Fidonews Robot is "09 Mar 2020" issue.
Then, there is one last post, Subject: WebPoint Veleno BBS, on Mar 12.

I thought that maybe someone decided to abrogate the echo.




../|ug

--- OpenXP 5.0.43
* Origin: ----------Do Not Fold, Spindle or Mutilate.---------- (2:221/1.58)

Hello, August Abolins.
On 24/04/20 15.17 you wrote:

Hello Wilfred!
** On 24.04.20 - 20:47, Wilfred van Velzen wrote to August Abolins:

I was getting settled to hook up with the fnews_publish echo..

[snip]

But since the "09 Mar 2020: edition, the auto-posts stopped. :( WvV>I'm getting the weekly publications in the FNEWS_PUBLISH area just

fine!?

Maybe it's just the JamNNTP feed. Hey Tommi.. Wassup wid dat?

I killed the area, the same messages are posted weekly in FIDONEWS echo.

I thought that maybe someone decided to abrogate the echo.
../|ug

--
Tommi

--- HotdogEd/2.13.5 (Android; Google Android; rv:1) Hotdoged/1585118613000 HotdogEd/2.13.5
* Origin: nntp point (2:221/1.1)

25 Apr 20 08:17, Tommi Koivula wrote to August Abolins:

I was getting settled to hook up with the fnews_publish echo..

[snip]

But since the "09 Mar 2020: edition, the auto-posts stopped. :(

I'm getting the weekly publications in the FNEWS_PUBLISH area just

fine!? Maybe it's just the JamNNTP feed. Hey Tommi.. Wassup wid dat?

I killed the area, the same messages are posted weekly in FIDONEWS echo.

It is connected again.

'Tommi

--- hpt/os2-emx 1.9.0-cur 2020-04-15
* Origin: rbb.fidonet.fi (2:221/1)

Hello Tommi!

** On 25.04.20 - 08:47, Tommi Koivula wrote to August Abolins:

Maybe it's just the JamNNTP feed. Hey Tommi.. Wassup wid dat?

I killed the area, the same messages are posted weekly in FIDONEWS echo.

It is connected again.

Thank you very much. Although the fidonews gets posted in the chat echo,
the fnews_publish is nice with *just* the news content.


../|ug

--- OpenXP 5.0.43
* Origin: ----------Do Not Fold, Spindle or Mutilate.---------- (2:221/1.58)