[nos-bbs] heads up 'remote disc early' possibly corrupting area index ?

[M Langelaar]

I'm seeing an instance of say 5 bulletins I forward but the remote system is
disconnecting before the 5th is done, and it would appear the (in this case)
area 'ww' index is corrupted, so any subsequent forwards to the same partner
or others forwarding that same area, result in JNOS just disconnecting after
the FS +_=+@ whatever ...

Example log entry :

09:35:21  SUMCALL @ SUMCALL - MBOX (sumcall) got response FS +++++
09:35:21  SUMCALL @ SUMCALL - MBOX (sumcall) fwd exit

Example log entry with major debugging :

09:35:21  SUMCALL @ SUMCALL - MBOX (sumcall) got response FS +++++
09:35:21  SUMCALL @ SUMCALL - about to validate FS line [FS +++++] msg cnt 5
09:35:21  SUMCALL @ SUMCALL - fsr [+] index [0]
09:35:21  SUMCALL @ SUMCALL - fsr [+] index [1]
09:35:21  SUMCALL @ SUMCALL - fsr [+] index [2]
09:35:21  SUMCALL @ SUMCALL - fsr [+] index [3]
09:35:21  SUMCALL @ SUMCALL - fsr [+] index [4]
09:35:21  SUMCALL @ SUMCALL - FS is okay, now send '+' messages
09:35:21  SUMCALL @ SUMCALL - sline [$31941_SUMCALL] index [0]
09:35:21  SUMCALL @ SUMCALL - mailbox file [./spool/mail/ww.txt]
09:35:21  SUMCALL @ SUMCALL - fbbsendmsg: truncated ww msg 103 would 
result from err 2
09:35:21  SUMCALL @ SUMCALL - fbb send msg error, why ?
09:35:21  SUMCALL @ SUMCALL - not connected, why ?
09:35:21  SUMCALL @ SUMCALL - MBOX (sumcall) fwd exit

Until I repair the index at the JNOS console using 'index www', then the 
forward
behaves again. So if you have a gazillion forwarding partners, they will 
likely ALL
behave like they're stuck and just doing nothing until you repair the 
index of the
area that they are all working on.

I'm not sure why this is happening, but after putting in some big debug 
code it's
very clear what's going on here.

Just thought this might be helpful information.

Maiko / VE4KLM