As we have 2 separate data volumes under one application we need 2 dedicated indexing machines to update indexes, but dont want them conflicting on common volumes, as we assume they will.

Thus we need to be able to do the equivalent of background indexing, probably using the replace background indexing process to update only selected volumes.

Is the best/only way to perform an INDEX.FLUSH on the required tables, or is there a better way?

As part of logon have a program attach only the volumes you want to index.

Begin case

Case @username=INDEXER1'

  Perform 'attachtable this_vol'

Case @username=INDEXER2'

  Perform 'attachtable that_vol'

Case 1

  Perform 'attachtable this_vol'

  Perform 'attachtable that_vol'

End Case

Each machine indexes only the files on one volume.

Hope this helps.

 Bob

Phil,

Have one indexer that indexes ALL the tables on four different but indentically (structured) sets of data. We set the cycle time to about 30 seconds then the indexer does the equivalent of counting repeatedly "1" "2" "3" "4"…."1" "2" "3" "4"………ad infinitum

while

 When counter=N" then do data set "N" (i.e. Attach indexes for

          set "N" then call INDEX.CONTROL and reset INPUT.CHAR and

          wait until the timer says time to recylcle next "N" then

          do it all over again.)

repeat until forever

See Technical Bulletin #49 for paticululars.

I have also added a switch that detaches the datatables and goes to

sleep from 10:00 pm to 7:00 am when the backup systems would be hitting the file. (Here that still causes a problem.)

I use a SYSTEM_TO_DOS (do's) table with a series of records that effectively contain TCL statements to be performed during each "N" cycle. I can control the INDEXER my manipulating the contents of this table. For example, our INDEXER is also an "AREV SERVER" for sending application triggered email messages through our Exchange Mail Server. I store the messages in an AREV file in a subroutine I created. When INDEXER cycles through each "N" it looks to see if there are any emails to generate. If so, they are sent and the message record is erased.

Our INDEXER is a P5-75 running WIN95 and AREV 2.11.

It has worked very reliably for nearly two years and it is very easy to maintain. Whether this would work for you or not could be a function of the currency requirments of your indexes. Our real index update cycle time is usually within 1.5 minutes for a dataset given that we have four cycles. I could shorten the delay but this would increase the network traffic for little advantage in our application.

Hope this helps.

Thanks Bob Carten, your method works great, simple too, I should have thought of it myself.

So Ive got a post background index process checking for the backup time and logging out where the batch file logs back in after the backup (using WAITUNTL).

The only thing is that sometimes (still trying to find out why) the indexer machines stop doing anything, ie. not indexing and not running the post indexing process.

I set @DATA after in the post process, but still need to hit a key sometimes to get the indexing going again so that it will also go on checking for time to logout.

Im trying to solve this now, do you (or anyone else) have any ideas off hand ?

Do you have a custom indexing replacement routine or just a post process?

Are using a subroutine or a X or E type call?

Does the routine use STOP?

[email protected]

Sprezzatura, Inc.

Thank you again for your prompt response Aaron.

I have the following subroutine set as the post index check (code=S", cmd=ALLOW_BACKUP") on the indexing machines, I have no replace indexing routine setup, although I do have 'Yes' against update indexes before filter, dont know if this could cause the thing to stop its index checks.

PS. Strange how I couldnt see your last reply beneath my original entry, I had to search by author before I could see the full tree.

Bye, and again, thanks for your help.

Phil.

---

SUBROUTINE ALLOW_BACKUP

DECLARE SUBROUTINE EXIT_SYSTEM, MSG

MSG("|Backup ?|","T1")

BACKUP.STARTS=ICONV("01:00:00","MT")

BACKUP.FINISH=ICONV("06:00:00","MT")

IF TIME() GE BACKUP.STARTS AND TIME() LE BACKUP.FINISH THEN

EXIT_SYSTEM("BACKUP TIME")

END ELSE

@DATA=\007D\ ;* get the thing going again, using unused Alt-6

CALL CATALYST("K","{ALT-6}") ;* not required ?

END

*@[email protected] ;* not required ??

RETURN

---

The catalyst stuff shouldn't be required. Wonder if the message timing is setting it off.

What is @INDEX.TIME and @BACKGRND.TIME set to?

Does the post get called again at all?

Where are you if you jump to the debugger?

As Aaron suggests, perhaps the problem lies with the timed messages.

Try changing them to 'UB' type messages calling the DELAY function/subroutine and then the 'DB' message call.

What does the EXIT_SYSTEM subroutine do?

Thanks Aaron and Warren.

Yes, perhaps the T1 message triggers indexing in turn and things get confused, thus I will try a UB/delay/DB instead.

I used EXIT_SYSTEM instead of LOGOFF as I have read that it does a tidier exit.

I have removed the CATALYST call and there was no change, so setting @data is enough.

I have @index.time set to 1 and @backgrnd.time set to 5, although in this post index routine @index.time had been changed to -1, dont know what this means, thus I tried restoring it from @environ.set, but guess I dont need to.

At the moment we run the indexers on one PC running win95 and I have just discovered that if I move the mouse pointer over the active window it stops indexing ! until a key is pressed.

As I dont know how to disable the mouse we will just have to keep it clear of the indexer windows.

I guess this mouse thing must have been our problem all along, unless they stop indexing again…

Phil.

See also

http://www.revelation.com/Discuss.nsf/f12696d31000b22a8525652b00831bb2/526BA835052121A585256FAA006295D7?OpenDocument

View this thread on the forum...