home *** CD-ROM | disk | FTP | other *** search
/ Media Share 9 / MEDIASHARE_09.ISO / pcboard / 150_tips.zip / MSGS.ZIP / UPDTIDX.MSG < prev    next >
Text File  |  1993-05-12  |  7KB  |  142 lines
  1. Date: 05-11-93 (23:12)              Number: 63183 of 63273 (Refer# 63163)
  2.   To: JIM ERCK
  3. From: DAVID TERRY
  4. Subj: Message indexes
  5. Read: NO                            Status: PUBLIC MESSAGE
  6. Conf: BETA (6)                   Read Type: GENERAL (+)
  7.  
  8. -> David, I saw the following today when I logged onto my system and did a
  9. -> mail scan:. These index files were already created previously and these
  10. -> message didn't appear last night.  Could something in the PCBPACK of the
  11. -> message bases have created this?
  12. ->
  13. -> Updating index file, please wait...
  14. -> 124  Language Arts         0         4
  15. -> 125  Life Skills           0         0
  16. -> 126  Mathematics           0         5
  17.  
  18. For everyone's benefit.  Please read all the way to the bottom of this message.
  19. A solution to the above problem is provided.
  20. ============================================
  21.  
  22. This is v15.0 IN ACTION taking "good care" of problems caused by outdated
  23. software.
  24.  
  25. This is v15.0 compatibility in action.
  26.  
  27. In *spite* of the fact that v15.0 uses brand new message indexes, which most
  28. mail doors and netmail software do NOT yet handle, your system will STILL run.
  29. You can STILL access the message bases with v15.0 and you can STILL add
  30. messages into them using outdated (non-15.0 compliant) software.
  31.  
  32. Version 15.0 goes out of its way to watch over its shoulder.  To check to see
  33. if the message index files have been updated or even if they have been
  34. 'trashed' (to some extent) by a third party package.
  35.  
  36. If the message index is found to be "out of synch" PCBoard will synch it right
  37. up the moment a caller tries to access the message base.  And that is EXACTLY
  38. what you just witnessed.
  39.  
  40. Where PCBoard says "Updating Index File" what it really means is this:  older
  41. software has posted new mail in the message base without updating the new index
  42. files, so it is updating those index files to cover the new messages that have
  43. been posted.
  44.  
  45. Some of your message bases will have 50 or fewer new messages.  PCBoard figures
  46. it can get away with "delaying" the caller long enough to insert that many new
  47. index records and so it does not bother informing the caller that it is
  48. updating the index files in those conference.  Generally the update procedure
  49. is fast and you will not notice it.
  50.  
  51. But if there are 50 or more new messages, or if the index has been corrupted by
  52. third party software, then PCBoard will have to spend more time on the index so
  53. it issues the "Updating Index Files" message and proceeds with its work.
  54.  
  55. How long this takes all depends on how many new messages are posted.  Or, in
  56. the case of a trashed index, how many total messages there are since a complete
  57. re-build is in order.
  58.  
  59. There are TWO solutions to this problem:
  60.  
  61. 1) Utilize v15.0-compliant software when you are importing mail.
  62.  
  63.    Again, reports from the Developer's Conference look promising.  I expect
  64.    that there should be good numbers of mail doors and other software
  65.    available now or soon that will help cure this problem.
  66.  
  67. 2) In the mean time, you can HIDE those messages from your callers with a
  68.    very simple addition to your mail import batch files:
  69.  
  70.         PCBPACK /AREA:ALL /UPDATE
  71.  
  72.    This simple command is the "essence" of having a caller JOIN EVERY
  73.    conference on the system and automatically detecting how many "new messages"
  74.    have been inserted (and need new entries in the index files) and it also
  75.    detects trashed index files.
  76.  
  77.    This process, as with PCBoard, is fairly fast and will not delay your mail
  78.    import process by a tremendous amount of time because all it has to do is
  79.    update the new index files with the new messages that were imported.
  80.  
  81. I posted a message earlier in this conference on the subject of using MAIL
  82. DOORS which imported mail without updating the new index files.  The advice I
  83. gave then, is the same advice I am giving here, that running PCBPACK with the
  84. /UPDATE option will "hide" from the caller the evidence of v15.0's need to keep
  85. the NEW indexes up to date.
  86.  
  87.   (Note the above message is included down below this message)
  88.  
  89. -> PCBPACK /FO /AREA:1 /CA:PACKMSGS.TXT /MA:500 /DAYS:60 /KD /KB /NS /NC
  90. -> /OLDINDEX
  91.  
  92. By the way, your PCBPACK command is NOT at fault here.  But here is one more
  93. tip on the subject:
  94.  
  95. If you are packing your message bases AND performing mail runs ... it is best
  96. to do the mail run FIRST and then run PCBPACK afterwards.  In which case you
  97. can FOREGO the need for the PCBPACK /UPDATE command.
  98.  
  99. In other words, if you're going to be packing ANYWAY, then there is no need to
  100. redundantly update the index files.  Just order your event processing so that
  101. the packing out process will occur AFTER the mail has been imported.
  102.  
  103.  
  104.  
  105. Date: 05-07-93 (11:19)              Number: 62286 of 63372 (Refer# NONE)
  106.   To: ALL
  107. From: DAVID TERRY
  108. Subj: PCBPACK /UPDATE
  109. Read: (N/A)                         Status: PUBLIC MESSAGE
  110. Conf: BETA (6)                   Read Type: MAIL FROM YOU (R/O) (+)
  111.  
  112. Having just mentioned the PCBPACK /UPDATE command in the previous message...
  113. This is a old message re-posted from the Developer's Conference:
  114.  
  115. Just to let everyone know what we're doing here...  QMAIL4 will execute a batch
  116. file called UPLOAD2.BAT right after a caller uploads a .REP packet.
  117.  
  118. PCBoard will update the MSGS.IDX as soon as someone tries to join a conference
  119. that received one of these replies, or if a caller was already in that
  120. conference then the update will occur when the caller tries to read messages.
  121.  
  122. In any case, there may be a slight pause while PCBoard updates the .IDX file
  123. before the caller can continue.  The length of the delay depends on how many
  124. messages were inserted from the .REP packet.
  125.  
  126. In an effort to get the MSGS.IDX files updated before someone joins one of
  127. these conferences, we modified the UPLOAD2.BAT file as follows:
  128.  
  129.         PCBPACK /AREA:ALL /UPDATE
  130.  
  131. This tells PCBPack to scan all conferences and update any .IDX files that need
  132. to be updated.  This is a fairly fast process - at least on OUR system with
  133. only 60 conferences - and will only delay the caller for couple of moments.
  134.  
  135. Of course, if you have 4000 message bases this might not be a good idea.  :-)
  136.  
  137. I hear Sparky is working on .IDX routines so this technique won't be needed at
  138. all at some point in the future.  And, of course, PCBoard gets along just fine
  139. without doing this and simply updates the .IDX file whenever someone accesses
  140. the MSGS file.  But I wanted to let everyone know how we were using the /UPDATE
  141. parameter to PCBPack in case it might help others.
  142.