home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Media Share 9
/
MEDIASHARE_09.ISO
/
pcboard
/
150_tips.zip
/
MSGS.ZIP
/
UPDTIDX.MSG
< prev
next >
Wrap
Text File
|
1993-05-12
|
7KB
|
142 lines
Date: 05-11-93 (23:12) Number: 63183 of 63273 (Refer# 63163)
To: JIM ERCK
From: DAVID TERRY
Subj: Message indexes
Read: NO Status: PUBLIC MESSAGE
Conf: BETA (6) Read Type: GENERAL (+)
-> David, I saw the following today when I logged onto my system and did a
-> mail scan:. These index files were already created previously and these
-> message didn't appear last night. Could something in the PCBPACK of the
-> message bases have created this?
->
-> Updating index file, please wait...
-> 124 Language Arts 0 4
-> 125 Life Skills 0 0
-> 126 Mathematics 0 5
For everyone's benefit. Please read all the way to the bottom of this message.
A solution to the above problem is provided.
============================================
This is v15.0 IN ACTION taking "good care" of problems caused by outdated
software.
This is v15.0 compatibility in action.
In *spite* of the fact that v15.0 uses brand new message indexes, which most
mail doors and netmail software do NOT yet handle, your system will STILL run.
You can STILL access the message bases with v15.0 and you can STILL add
messages into them using outdated (non-15.0 compliant) software.
Version 15.0 goes out of its way to watch over its shoulder. To check to see
if the message index files have been updated or even if they have been
'trashed' (to some extent) by a third party package.
If the message index is found to be "out of synch" PCBoard will synch it right
up the moment a caller tries to access the message base. And that is EXACTLY
what you just witnessed.
Where PCBoard says "Updating Index File" what it really means is this: older
software has posted new mail in the message base without updating the new index
files, so it is updating those index files to cover the new messages that have
been posted.
Some of your message bases will have 50 or fewer new messages. PCBoard figures
it can get away with "delaying" the caller long enough to insert that many new
index records and so it does not bother informing the caller that it is
updating the index files in those conference. Generally the update procedure
is fast and you will not notice it.
But if there are 50 or more new messages, or if the index has been corrupted by
third party software, then PCBoard will have to spend more time on the index so
it issues the "Updating Index Files" message and proceeds with its work.
How long this takes all depends on how many new messages are posted. Or, in
the case of a trashed index, how many total messages there are since a complete
re-build is in order.
There are TWO solutions to this problem:
1) Utilize v15.0-compliant software when you are importing mail.
Again, reports from the Developer's Conference look promising. I expect
that there should be good numbers of mail doors and other software
available now or soon that will help cure this problem.
2) In the mean time, you can HIDE those messages from your callers with a
very simple addition to your mail import batch files:
PCBPACK /AREA:ALL /UPDATE
This simple command is the "essence" of having a caller JOIN EVERY
conference on the system and automatically detecting how many "new messages"
have been inserted (and need new entries in the index files) and it also
detects trashed index files.
This process, as with PCBoard, is fairly fast and will not delay your mail
import process by a tremendous amount of time because all it has to do is
update the new index files with the new messages that were imported.
I posted a message earlier in this conference on the subject of using MAIL
DOORS which imported mail without updating the new index files. The advice I
gave then, is the same advice I am giving here, that running PCBPACK with the
/UPDATE option will "hide" from the caller the evidence of v15.0's need to keep
the NEW indexes up to date.
(Note the above message is included down below this message)
-> PCBPACK /FO /AREA:1 /CA:PACKMSGS.TXT /MA:500 /DAYS:60 /KD /KB /NS /NC
-> /OLDINDEX
By the way, your PCBPACK command is NOT at fault here. But here is one more
tip on the subject:
If you are packing your message bases AND performing mail runs ... it is best
to do the mail run FIRST and then run PCBPACK afterwards. In which case you
can FOREGO the need for the PCBPACK /UPDATE command.
In other words, if you're going to be packing ANYWAY, then there is no need to
redundantly update the index files. Just order your event processing so that
the packing out process will occur AFTER the mail has been imported.
Date: 05-07-93 (11:19) Number: 62286 of 63372 (Refer# NONE)
To: ALL
From: DAVID TERRY
Subj: PCBPACK /UPDATE
Read: (N/A) Status: PUBLIC MESSAGE
Conf: BETA (6) Read Type: MAIL FROM YOU (R/O) (+)
Having just mentioned the PCBPACK /UPDATE command in the previous message...
This is a old message re-posted from the Developer's Conference:
Just to let everyone know what we're doing here... QMAIL4 will execute a batch
file called UPLOAD2.BAT right after a caller uploads a .REP packet.
PCBoard will update the MSGS.IDX as soon as someone tries to join a conference
that received one of these replies, or if a caller was already in that
conference then the update will occur when the caller tries to read messages.
In any case, there may be a slight pause while PCBoard updates the .IDX file
before the caller can continue. The length of the delay depends on how many
messages were inserted from the .REP packet.
In an effort to get the MSGS.IDX files updated before someone joins one of
these conferences, we modified the UPLOAD2.BAT file as follows:
PCBPACK /AREA:ALL /UPDATE
This tells PCBPack to scan all conferences and update any .IDX files that need
to be updated. This is a fairly fast process - at least on OUR system with
only 60 conferences - and will only delay the caller for couple of moments.
Of course, if you have 4000 message bases this might not be a good idea. :-)
I hear Sparky is working on .IDX routines so this technique won't be needed at
all at some point in the future. And, of course, PCBoard gets along just fine
without doing this and simply updates the .IDX file whenever someone accesses
the MSGS file. But I wanted to let everyone know how we were using the /UPDATE
parameter to PCBPack in case it might help others.