Hi Martin,

I need your help, again. Today, Thursday, upon delivery of the updated nodelist and the nodelist-diff, oxp locked up again after a poll.

What to I have to do to clean things up?

--- Thunderbird 2.0.0.24 (Windows/20100228)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

* 10.01.20 at 02:14, August Abolins wrote to All:

I need your help, again.

Uh-Oh :)

Today, Thursday, upon delivery of the updated nodelist and the nodelist-diff, oxp locked up again after a poll.

Hmmmmm .....

What to I have to do to clean things up?

Configure it correctly :-))

See next reply .....

Regards,
Martin

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

On 1/11/2020 6:43 AM, between "Martin Foster : August Abolins":

What to I have to do to clean things up?

Configure it correctly :-))

I deleted the nodelist entries completely.
After the next poll, it still locks up.

Here is the tail end of the DEBUG file:

2020-01-11 18:58:23 xpnetcall: backed up PKT:H:\DOWNLOADS\OPENXP\SPOOL\02210001\1897880a.pkt
2020-01-11 18:58:23 xpncfido: Converting PKT: H:\DOWNLOADS\OPENXP\SPOOL\1890e509.pkt
2020-01-11 18:58:23 zftools: converting fido to ZC
2020-01-11 18:58:23 zftools: conversion finished
2020-01-11 18:58:23 xpncfido: packet converted OK
2020-01-11 18:58:23 xpnetcall: backed up PKT:H:\DOWNLOADS\OPENXP\SPOOL\02210001\1890e509.pkt
2020-01-11 18:58:23 debug: debug level for XPFIDONL is 50
2020-01-11 18:58:23 xpfidonl: Starting DoDiffs in
H:\DOWNLOADS\OPENXP\FILES\*.*
2020-01-11 18:58:23 xpfidonl: diffDir is ExtractFilePath(files)
2020-01-11 18:58:23 xpfidonl: diffnames are ExtractFilename(files)
2020-01-11 18:58:23 xpfidonl: diffDir and diffnames done
2020-01-11 18:58:23 xpfidonl: Nodelist.Count = 1
2020-01-11 18:58:23 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-01-11 18:58:23 xpfidonl: NextNumber17 uarchive: ufile: NODEDIFF.017 2020-01-11 18:58:23 xpfidonl: NodeDiff-Routine (repeat-Schleife)
erfolgreich beendet

Why is it wanting to process a nodediff when I have cleared out the
nodelist config?

While this is still happening, none of the .PKTs are getting tossed into
the bases.

Is this the problem:

┌─ 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 │
│ [x] Hold requests if files are missing │
│ │
│ [ ] Delete hidden kludges │
│ [x] Use TZUTC kludge │
│ │
│ Default echomail recipient All │


...where "Import nodelist updates automatically" is still enabled?

[...]

I'm back. Disabling that still lock up the poll.

I deleted the *.IX1 files, the LOCKFILE.

Still locks up at next poll.

What other files need to be deleted to get a fresh start?

--- Thunderbird 2.0.0.24 (Windows/20100228)
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello August!

* 12.01.20 at 02:13, August Abolins wrote to Martin Foster:

[snip]

What other files need to be deleted to get a fresh start?

Replied netmail.

Regards,
Martin

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

Hello August!

* 12.01.20 at 02:13, August Abolins wrote to Martin Foster:

I deleted the nodelist entries completely.

Are you absolutely certain about that?

After the next poll, it still locks up.

Here is the tail end of the DEBUG file:

[snip]

2020-01-11 18:58:23 debug: debug level for XPFIDONL is 50
2020-01-11 18:58:23 xpfidonl: Starting DoDiffs in H:\DOWNLOADS\OPENXP\FILES\*.*
2020-01-11 18:58:23 xpfidonl: diffDir is ExtractFilePath(files)
2020-01-11 18:58:23 xpfidonl: diffnames are ExtractFilename(files) 2020-01-11 18:58:23 xpfidonl: diffDir and diffnames done
2020-01-11 18:58:23 xpfidonl: Nodelist.Count = 1

^^^^^^^^^^^^^^^^^^
That tells me that you still have
one nodelist installed.

2020-01-11 18:58:23 xpfidonl: Starte NodeDiff-Routine, repeat-Schleife 2020-01-11 18:58:23 xpfidonl: NextNumber17 uarchive: ufile: NODEDIFF.017 2020-01-11 18:58:23 xpfidonl: NodeDiff-Routine (repeat-Schleife) erfolgreich beendet

Why is it wanting to process a nodediff when I have cleared out the nodelist config?

Because for some reason, OpenXP thinks you have a nodelist installed.
Have you cleared everything out of the FIDO directory?

While this is still happening, none of the .PKTs are getting tossed into the bases.

Yes.

Is this the problem:

[snip]

│ [x] Import nodelist updates automatically │
│ [ ] Delete empty messages │
│ [x] Automatic TIC file processing │
│ [x] Hold requests if files are missing │
│ │
│ [ ] Delete hidden kludges │
│ [x] Use TZUTC kludge │
│ │
│ Default echomail recipient All │

...where "Import nodelist updates automatically" is still enabled?

Nope, not a problem.

Regards,
Martin

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

Re: oxp locks up, again
By: Martin Foster to August Abolins on Sun Jan 19 2020 11:08:00

I deleted the nodelist entries completely.

Are you absolutely certain about that?

i have a question that may be helpful to you guys...

instead of faffing about with nodediffs, can you simply replace the nodelist with a daily nodelist and the tool will automatically see the nodelist is different and recompile its indexes?

that'd sure be a lot easier than trying to deal with nodediffs... i wouldn't even carry/distribute nodediffs if it weren't for some of my links wanting them... my system uses a new full nodelist every day as soon as it arrives... no muss, no fuss ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hello Martin,

Thank your for your feedback below.

I deleted the nodelist entries completely.

Are you absolutely certain about that?

Yes.. Fido/Nodelist/Config table is completely empty.

2020-01-11 18:58:23 xpfidonl: diffDir and diffnames done
2020-01-11 18:58:23 xpfidonl: Nodelist.Count = 1

^^^^^^^^^^^^^^^^^^
That tells me that you still have
one nodelist installed.

Hmmmm.

ufile: NODEDIFF.017 2020-01-11 18:58:23 xpfidonl: NodeDiff-Routine

Why is it wanting to process a nodediff when I have cleared out the
nodelist config?

Because for some reason, OpenXP thinks you have a nodelist installed. MF>Have you cleared everything out of the FIDO directory?

All I have in the FIDO directory are the results of a couple of file-
requests long ago in December:

FILELIST.CFG

It's contents are:

# Directory of request file lists

3:640/1321=TFB-ALL.FL


And the file TB-ALL.FL is in the directory too. That is all.


The nodelists typically arrive in the FILES directory here. I had several full and diff files (archived and unarchived) in there. After I deleted those, the next poll went smoothly.

Which leads me to the security/bug/weakeness.

If the FILES directory is used for the arriving nodelists, and it is the
same directory for other arriving files such as attachments from other people, then anyone could arbitrarily send me a nodelist, and its presence can screw up oxp (just like the presence of the old nodelist/diffs that I still had in there did).

The entry "2020-01-11 18:58:23 xpfidonl: Nodelist.Count = 1" above tells
me that it saw my stored nodelist files in the /FILES directory, even
though oxp's Fido/Nodelist/Config table is completely empty. Hmmmm.

While this is still happening, none of the .PKTs are getting tossed
into the bases.

Yes.

But... WHY aren't the messages getting tossed? The log files report
checking to unpack them and converting them, but the content of the PKTs never show up in the databases, instead, they just get moved to the "SPOOL/<host>" directory. Maybe the developer can place the actual toss higher in priority as soon as they are converted. ???


..AA

--- OpenXP 5.0.42
* Origin: (2:221/1.58)

Hello mark,

i have a question that may be helpful to you guys...

instead of faffing about with nodediffs, can you simply replace the nodelist with a daily nodelist and the tool will automatically see the nodelist is different and recompile its indexes?

Sounds interesting. I wasn't aware that there even was a daily version of the whole of fidonet until I did a file-req for NODELIST and my boss delivered the current daily version.

(I thought file-req for NODELIST would give me the official WEEKLY version only.)

that'd sure be a lot easier than trying to deal with nodediffs... i wouldn't even carry/distribute nodediffs if it weren't for some of my links wanting them... my system uses a new full nodelist every day as
soon as it arrives... no muss, no fuss ;)

In OXP, once the config is done, there is "no muss, no fuss" too, and everything is automatic.

But in my case, in my very early use of OXP, I entered the filenames for the Z2PNT diff files (the archived name and the unarchived name incorrectly.) After I fixed that, OXP seemed to hum along very nicely.

Then, along the way, I incorporated a "new" nodelist because something else caused a glitch here (which has since been fixed in the newer version of OXP).


By then, I stopped processing the Z2 DIFF files again, and thought I don't really need those. OXP hummed along quite nicely, and incorporated the weekly updates well.

Later at some point I wanted to reintroduce the pointlist. I made a mistake in the config and had to start from scratch. I did not realize that another "new" nodelist that I pulled in manually was one of the full DAILY versions. (I had file-reg'd NODELIST from my boss system.) From that point onward, the weekly DIFF file did not know how to work with that, I guess. And/Or, maybe I missed processing one of the diffs manually.

Around the same time (probably the same day when the new diffs arrived from my boss system), I had to roll back my Win XP system to an earlier restore point - something I hadn't needed to do in over 10 years! That's when the lock up started, again. :(

But now, I have the nodelist freshly configured with the latest weekly version. I am now confident that the Z2PNT config is good and ready for the next sync.

Plus, after getting rid of any latent nodelist files lurking in the incoming directories, OXP polled properly and has not locked up.

OXP seems to be very sensitive on nodelist configuration for regular operations. Even the PKT processing stops and the messages never get tossed. :(


Meanwhile, it is good to have a couple of other reader options (nntp and WinPoint) so that I don't have to miss anything.



--- WinPoint Beta 5 (359.1)
* Origin: Please write your complaint in this box [ ] - Legibly (2:221/1.59)

Hello mark!

* 19.01.20 at 07:57, mark lewis wrote to Martin Foster:

i have a question that may be helpful to you guys...

instead of faffing about with nodediffs, can you simply replace the nodelist with a daily nodelist and the tool will automatically see the nodelist is different and recompile its indexes?

Thanks for the suggestion but that method won't work with OpenXP.

Regards,
Martin

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

Re: oxp locks up, again
By: Martin Foster to mark lewis on Sun Jan 26 2020 09:52:00

i have a question that may be helpful to you guys...

instead of faffing about with nodediffs, can you simply replace the nodelist
with a daily nodelist and the tool will automatically see the nodelist is
different and recompile its indexes?

Thanks for the suggestion but that method won't work with OpenXP.

that's kinda sad... especially in this day in time ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

instead of faffing about with nodediffs, can you simply replace the ml>nodelist with a daily nodelist and the tool will automatically see the ml>nodelist is different and recompile its indexes?

Hi marc,

I would guess that oxp doesn't know how to handle diffs if more than one arrived at a time.

The weekly process is fairly doable. There are enough days inbetween to
catch up and just get "one" and then just process that one.

Just guessing.

--- OpenXP 5.0.42
* Origin: (2:221/1.58)

Hello August!

* 26.01.20 at 18:33, August Abolins wrote to mark lewis:

instead of faffing about with nodediffs, can you simply replace the
nodelist with a daily nodelist and the tool will automatically see the
nodelist is different and recompile its indexes?

Hi marc,

I would guess that oxp doesn't know how to handle diffs if more than one arrived at a time.

Guessed wrong buddy :-)

OpenXP can apply as many contiguous diffs as you like, so long as
there aren't any missing in the sequence.

Regards,
Martin

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

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

instead of faffing about with nodediffs, can you simply
replace the nodelist with a daily nodelist and the tool will
automatically see the nodelist is different and recompile its
indexes?

Hi marc,

I would guess that oxp doesn't know how to handle diffs if more
than one arrived at a time.

Guessed wrong buddy

OpenXP can apply as many contiguous diffs as you like, so long
as there aren't any missing in the sequence.

But then why did you tell marc that oxp couldn't handle daily diffs in
this message:

Date: Sun, 26 Jan 2020 09:52:00 +0000
X-JAM-MSGID: 2:310/31.3@fidonet e0ca7838



--
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)

Re: oxp locks up, again
By: August Abolins to Martin Foster on Sat Feb 01 2020 18:22:13

But then why did you tell marc that oxp couldn't handle daily diffs
in this message:

NOTE: i was specifically trying to steer away from diffs... they really are not necessary in this day in time and one can easily get a full nodelist every day that is as up to date as possible with current processing...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

On 01/02/2020 3:22 p.m., mark lewis : August Abolins wrote:

NOTE: i was specifically trying to steer away from diffs... they
really are not necessary in this day in time and one can easily
get a full nodelist every day that is as up to date as possible
with current processing...

Hi mark!

My bad. I erroneously referred to your "daily" solution as diffs.

I rather like the idea of just implementing a daily full nodelist. But
it is rather cool to witness a program to chug away and construct an
update locally from the diffs. ;)

Sadly (or maybe to the benefit of oxp), in my case, I have uncovered
something that should be fixed.

From a user POV, a daily updated nodelist is probably overkill. A "full
daily" makes sense for a sysop who relies heavily on contacting other
systems every day. As an ex-sysop I like the notion of a nearly
real-time updated nodelist. But I would imagine that users (for which something like oxp was designed for) may not be online every day, and/or
don't really need to contact other systems very much.

As for oxp actually processing a full daily updated list automatically,
I don't understand why that can't be so. Is oxp hardcoded to expect the
full nodelist to be exactly 7 days from a previous one before it
overrides the old one? If so, THEN a full daily wouldn't work, I guess.


--
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:22, August Abolins wrote to Martin Foster:

instead of faffing about with nodediffs, can you simply
replace the nodelist with a daily nodelist and the tool will
automatically see the nodelist is different and recompile its
indexes?

Hi marc,

I would guess that oxp doesn't know how to handle diffs if more
than one arrived at a time.

Guessed wrong buddy

OpenXP can apply as many contiguous diffs as you like, so long
as there aren't any missing in the sequence.

But then why did you tell marc that oxp couldn't handle daily diffs in this message:

Date: Sun, 26 Jan 2020 09:52:00 +0000
X-JAM-MSGID: 2:310/31.3@fidonet e0ca7838

I didn't actually say that.

Marc was suggesting the use of daily *nodelists*, which OpenXP can't
handle *automatically*. It can, however, handle them if the user is
prepared to install each one every day which, of course, would be a
real PITA.

Regards,
Martin

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

Hello Martin!

** 07.02.20 - 13:05, Martin Foster wrote to August Abolins:

Marc was suggesting the use of daily *nodelists*, which OpenXP can't
handle *automatically*. It can, however, handle them if the user is
prepared to install each one every day which, of course, would be a
real PITA.

Doh! My bad. I see now in the Config that the automated updates setting only applies to "diffs". Full nodelists, when received, are NOT automatically updated.

+- Fido Options ---------------------------------+
� �
� Int. dial prefix 00 �
� Nat. dial prefix 0 �
� Your dialing code 49-631 �
� �
� [x] Import nodelist updates automatically � <--- for DIFFs only?
� [ ] Delete empty messages �
� [x] Automatic TIC file processing �
� [x] Hold requests if files are missing �
� �
� [ ] Delete hidden kludges �
� [x] Use TZUTC kludge �


Maybe that line could be:

� [x] Import nodelist DIFFs automatically �


..someday? <BG>




../|ug

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

Hello August!

*** 07.02.20 at 23:10, August Abolins wrote to Martin Foster:

[snip]

+- Fido Options ---------------------------------+
� �
� Int. dial prefix 00 �
� Nat. dial prefix 0 �
� Your dialing code 49-631 �
� �
� [x] Import nodelist updates automatically � <--- for DIFFs only?
� [ ] Delete empty messages �
� [x] Automatic TIC file processing �
� [x] Hold requests if files are missing �
� �
� [ ] Delete hidden kludges �
� [x] Use TZUTC kludge �

Maybe that line could be:

� [x] Import nodelist DIFFs automatically �

..someday? <BG>

Yeah maybe but the help topic does mention diffs :-)

Regards,
Martin

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

Hello August!

*** 19.01.20 at 11:44, August Abolins wrote to Martin Foster:

[snip]

Which leads me to the security/bug/weakeness.

If the FILES directory is used for the arriving nodelists, and it is the same directory for other arriving files such as attachments from other people, then anyone could arbitrarily send me a nodelist, and its
presence can screw up oxp (just like the presence of the old nodelist/diffs that I still had in there did).

It wasn't the presence of the old nodlists/diffs that was causing the
problem :)

However, if OpenXP sees a nodelist in the FILES directory, it ignores it
just as it ignores most other files in the FILES directory. The only files
it takes action on are nodediffs/pointdiffs and if any of them are out of sequence, it just ignores them.

Regards,
Martin

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

Hello Martin!

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

Which leads me to the security/bug/weakeness.

..then anyone could arbitrarily send me a nodelist, and its
presence can screw up oxp (just like the presence of the old
nodelist/diffs that I still had in there did).

It wasn't the presence of the old nodlists/diffs that was causing the
problem :)

Correct. The main problem was having a Z1 nodelist and using a Z2 diff
update file. But the only way I managed to clear the lock up was to
delete the latent nodelist/nodediff files I still had in the incoming
/FILES directory.

..The only files it takes action on are nodediffs/pointdiffs and if
any of them are out of sequence, it just ignores them.

It was still taking action on the NODEDIFF that was in /FILES, even though
I had cleared out the nodelist config tables. The /FIDO directory was
empty!

The following settings marked "<==THIS" were probably enabled:

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

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


Is it the presence of a .TIC file in /FILES that can trigger the "action" too?

Maybe I am worried over nothing since OXP probably takes a more secure process (ie acting on files only received from my Boss system via the TIC information) before it acts on just anything that looks like a diff file
in the /FILES directory.


../|ug

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

Hello mark!

** 26.01.20 - 08:21, mark lewis wrote to Martin Foster:

instead of faffing about with nodediffs, can you simply replace the
nodelist with a daily nodelist and the tool will automatically see
the nodelist is different and recompile its indexes?

Thanks for the suggestion but that method won't work with OpenXP.

that's kinda sad... especially in this day in time ;)

I've just learned that OXP is designed to process the diffs automatically, but not a fresh incoming full nodelist. So, in theory, I would imagine
that it could work if the daily nodelist had a matching daily diff.

I guess that importing/compiling the full nodelist manually was a concious design decision. But, we'll never know the original reason at this time.

Further to what is "sad... especially in this day", there are probably far more examples of FTN programs that are not going to get any improvements
or fixes at all, yet they are accomodated without incident, for now.

Y2K-broken programs have probably left the FTN scene gracefully.

And unless we all move to 64-bit OS/programs, will many 32-bit programs
that rely on dates (like this OXP) expire on March 19 2038 03:14:07 UTC?


../|ug

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

Hello August,

I've just learned that OXP is designed to process the diffs
automatically, but not a fresh incoming full nodelist. So, in
theory, I would imagine that it could work if the daily nodelist had
a matching daily diff.

When I first joined Fidonet in 1995 those diff's were essential. The compressed nodelists were 1.5MB and I really didn't want to transfer that on the 2400 baud modem I had at the time.. :)

I don't process diff's anymore although I have software to do it if I needed to.

Can OXP not skip processing the diff and just compile a new nodelist?

I guess that importing/compiling the full nodelist manually was a
concious design decision. But, we'll never know the original reason
at this time.

It was a different time and place. I blew my nodelist away a couple of times back then and had no choice but to go searching for a full nodelist somewhere and hope I had enough online time to grab a new one.

It was not an easy thing to find just anywhere and my BBS was offline while I got that done. Well, not offline but busy.. :)

Further to what is "sad... especially in this day", there are probably
far more examples of FTN programs that are not going to get any improvements or fixes at all, yet they are accomodated without
incident, for now.

As long as those old programs work properly we are OK. Squish is one example of an old software that is still in use today at some nodes.

Y2K-broken programs have probably left the FTN scene gracefully.

I hope so.. but we do have pktdate should the need arise.. :)

And unless we all move to 64-bit OS/programs, will many 32-bit
programs that rely on dates (like this OXP) expire on March 19 2038 03:14:07 UTC?

I don't think they'll expire but the dates they display might be wonky. I think the OpenXP developers are still developing, or at least maintaining OXP so I think OXP users will be OK. I'm not so sure about some other software.

There were 2020 problems in Mystic that were quickly fixed. These sorts of niggles can show up unexpectedly.

Ttyl :-),
Al

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

On 11/02/2020 8:16 a.m., Alan Ianson : August Abolins wrote:

According to the TZUTC, you wrote that just after 5am! You certainly
start your day very early. I have a couple of house-broken cats that
wake me up between 3a and 5a to be let out, each at their own time! But
I promptly settle back to sleep.

When I first joined Fidonet in 1995 those diff's were essential.
The compressed nodelists were 1.5MB and I really didn't want to
transfer that on the 2400 baud modem I had at the time..

I used a 2400 baud that came with my computer only briefly. But, by the
time I joined Fidonet with my own bbs I had a 14.4 kbit/s internal
modem. The increase in speed seemed amazing at the time.

I really enjoyed utilizing simultaneous upload/download. Was that with Ymodem/G...? I don't quite remember. It was cool to "chat" with
another sysop during the upload/download session too.

1.5MB seems rather large for a text-based nodelist. Were you relying on
one of the non-zip archives? But the math seems right:

Today, approx 1000 nodes = 50K
Peak, approx 40000 nodes = 2000K or 2meg

Can OXP not skip processing the diff and just compile a new
nodelist?

Processing the diff is actually preferred.

As I wrote in my original message, OXP does not seem to be designed to
offer automatic full nodelist detection upon arrival. But that's ok.
The diff processing works and is pretty magical - now that I've learned
that there are different versions of the "same" nodelist and nodediffs depending on the Zone you pull them from. I had no idea.

Y2K-broken programs have probably left the FTN scene gracefully.

I hope so.. but we do have pktdate should the need arise..

That reminds me, I recently discovered a date problem when I used
Tommi's BBS (ie logged in manually) to send a netmail few weeks ago. His Concord BBS software produced a future date of 2056. LOL

Date: Sat, 19 Feb 2056 21:45:16 GMT
Message-ID: <5473$netmail@JamNNTPd>
References: <5470$netmail@JamNNTPd>
X-JAM-From: August Abolins <2:221/360>
X-JAM-To: Martin Foster <2:310/31.3>
X-JAM-MSGID: 2:221/360 1ced0c7d
X-JAM-REPLYID: 2:310/31.3 f99352d3
X-JAM-PID: Concord 0.01 Beta-30d OS/2 ser#cc38c58d


I should drop by and see if he had a chance to hack netmails with pktdate.

..will many 32-bit
programs that rely on dates (like this OXP) expire on March 19
2038 03:14:07 UTC?

I don't think they'll expire but the dates they display might be
wonky.

It's really fun to hack a fix and witness the magic. But it's more fun
when things run right the first time.

I think the OpenXP developers are still developing, or at
least maintaining OXP so I think OXP users will be OK. I'm not so
sure about some other software.

I never really thought that I would warm up to OXP, it being a dos/texty interface requiring mostly keyboard action. But its message search capabilities are very good, among other things.

There were 2020 problems in Mystic that were quickly fixed. These
sorts of niggles can show up unexpectedly.

Lots of fun to be had!


--
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)

Hi August.

11 Feb 20 19:50:20, you wrote to Alan Ianson:

Y2K-broken programs have probably left the FTN scene gracefully.

I hope so.. but we do have pktdate should the need arise..

That reminds me, I recently discovered a date problem when I used
Tommi's BBS (ie logged in manually) to send a netmail few weeks ago. His Concord BBS software produced a future date of 2056. LOL

Date: Sat, 19 Feb 2056 21:45:16 GMT
Message-ID: <5473$netmail@JamNNTPd>
References: <5470$netmail@JamNNTPd>
X-JAM-From: August Abolins <2:221/360>
X-JAM-To: Martin Foster <2:310/31.3>
X-JAM-MSGID: 2:221/360 1ced0c7d
X-JAM-REPLYID: 2:310/31.3 f99352d3
X-JAM-PID: Concord 0.01 Beta-30d OS/2 ser#cc38c58d

I should drop by and see if he had a chance to hack netmails with
pktdate.

No, not yet. The problem is still there. Pktdate is able to fix every outbound message but it is not in operation yet.

Or I can shut down the bbs. :)

'Tommi

---
* Origin: Point One, Le Gros-Theil, France (2:221/360.1)

Hello August,

According to the TZUTC, you wrote that just after 5am!

I don't like to leave things to the last minute!

When I first joined Fidonet in 1995 those diff's were essential.
The compressed nodelists were 1.5MB and I really didn't want to
transfer that on the 2400 baud modem I had at the time..

I used a 2400 baud that came with my computer only briefly. But, by
the time I joined Fidonet with my own bbs I had a 14.4 kbit/s internal modem. The increase in speed seemed amazing at the time.

When I joined Fidonet I was a little behind everyone else but it didn't take long and I upgraded to 14.4 and then 28.8. 28.8 seemed like freedom then. :)

I really enjoyed utilizing simultaneous upload/download. Was that with Ymodem/G...? I don't quite remember. It was cool to "chat" with
another sysop during the upload/download session too.

I think that is Hydra that has bi-directional transfers and chat.

1.5MB seems rather large for a text-based nodelist. Were you relying
on one of the non-zip archives? But the math seems right:

That was the compressed nodelist, ARC format then.

Ttyl :-),
Al

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

Hello August!

*** 10.02.20 at 22:48, August Abolins wrote to Martin Foster:

[snip]

..The only files it takes action on are nodediffs/pointdiffs and if
any of them are out of sequence, it just ignores them.

It was still taking action on the NODEDIFF that was in /FILES,

Yes, that's what I said but .....

even though I had cleared out the nodelist config tables. The /FIDO directory was empty!

..... I forgot to mention that the nodelist routines still run regardless
of whether there's anything in the /FILES directory that they need to process.

The following settings marked "<==THIS" were probably enabled:

[snip]

| [x] Use internal nodelist processor |<==THIS

That's fine.

[snip]

� [x] Import nodelist updates automatically �<==THIS

As is this.

� [ ] Delete empty messages �
� [x] Automatic TIC file processing �<==THIS?

Is it the presence of a .TIC file in /FILES that can trigger the "action" too?

That has nothing to do with the nodelist routines, see the help topic for
a full explanation of what this feature is/does :)

Regards,
Martin

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

Hello Alan!

*** 11.02.20 at 05:16, Alan Ianson wrote to August Abolins:

[snip]

Can OXP not skip processing the diff and just compile a new nodelist?

Unfortunately not.

I don't think they'll expire but the dates they display might be
wonky. I think the OpenXP developers are still developing, or at
least maintaining OXP so I think OXP users will be OK. I'm not so
sure about some other software.

OpenXP is definitely still being developed/maintained.

Regards,
Martin

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

Hello Martin!

13 Feb 20 11:02, you wrote to me:

Is it the presence of a .TIC file in /FILES that can trigger the
"action" too?

That has nothing to do with the nodelist routines, see the help topic
for a full explanation of what this feature is/does :)

You are a tough teacher. As you can see, I am in Italy at this time! ;) I'll back in Finland in about 6 hours.


August


--- GoldED+/W32-MINGW 1.1.5-b20170303
* Origin: ----> Point Of VeleNo BBs (http://www.velenobbs.net) (2:333/808.7)

Hi August.

13 Feb 20 18:50:00, you wrote to Martin Foster:

As you can see, I am in Italy at this time!
;) I'll back in Finland in about 6 hours.

There is only one hour gap in time, why does it take so long? :D

'Tommi

---
* Origin: Point One, Le Gros-Theil, France (2:221/360.1)

Can OXP not skip processing the diff and just compile a new nodelist?

Unfortunately not.

Hmm.. might be a good feature suggestion.. :)

I don't think they'll expire but the dates they display might be
wonky. I think the OpenXP developers are still developing, or at
least maintaining OXP so I think OXP users will be OK. I'm not so
sure about some other software.

OpenXP is definitely still being developed/maintained.

That's good to hear. I notice I am a version behind in what I have on the BBS for OXP downloads. Is there a file echo for OXP or other point software?

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

Hello Alan!

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

Can OXP not skip processing the diff and just compile a new nodelist?

Unfortunately not.

Hmm.. might be a good feature suggestion.. :)

I'll think about that one.

I don't think they'll expire but the dates they display might be
wonky. I think the OpenXP developers are still developing, or at
least maintaining OXP so I think OXP users will be OK. I'm not so
sure about some other software.

OpenXP is definitely still being developed/maintained.

That's good to hear. I notice I am a version behind in what I have on the BBS for OXP downloads.

Thanks very much for making them available for d/load, much appreciated.

The current release version is 5.0.42, whereas 5.0.43 is a development version.

Here's a full list of the 5.0.42 releases .....

28/12/2019 10:59 8,073,696 openxp-5.0.42.src.tar.gz
28/12/2019 10:59 8,266,509 openxp-5.0.42.src.zip
28/12/2019 11:16 2,158,240 openxp-5.0.42-1.i586.rpm
28/12/2019 11:16 2,777,186 openxp-5.0.42-1.i586-lnx.zip
28/12/2019 10:59 2,285,404 openxp-5.0.42-1.x86_64.rpm
28/12/2019 10:59 3,009,424 openxp-5.0.42-1.x86_64-lnx.zip
28/12/2019 09:58 3,239,026 OpenXP5.0.42-win.zip

If you don't have them all, please feel free to grab them from my puny
little space on the Web: https://openxp.uk

Is there a file echo for OXP or other point software?

Nope.

Regards,
Martin

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

On 13/02/2020 2:05 p.m., Alan Ianson : Martin Foster wrote:

...I notice I am a version behind in what I
have on the BBS for OXP downloads. Is there a file echo for OXP
or other point software?

In addition to Martin's list, there is a collection also at the
Sourceforge site.

But look for "OpenXP 5", not "OpenXP".

The latter depository is much older.



--
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.02.20 at 20:19, August Abolins wrote to Alan Ianson:

...I notice I am a version behind in what I
have on the BBS for OXP downloads. Is there a file echo for OXP
or other point software?

In addition to Martin's list, there is a collection also at the Sourceforge site.

https://sourceforge.net/projects/openxp5/
This is the official OpenXP5 site which, in addition to all the release packages, is the official code repository. The source code can be either downloaded or checked out via 'svn'.

But look for "OpenXP 5", not "OpenXP".

Yes, that's a very good point you make, thanks.

The latter depository is much older.

It's also inactive and has been for many many years and, IIRC, all that
stuff was put on there purely for archival/historical purposes.

Regards,
Martin

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