Hi,

A client has a Windows XP workstation acting as a dedicated Arev 3.12 Indexer (don't ask why…they insisted on upgrading ALL workstations to XP). I would like this machine to automatically logout of Arev at a specified time for the backup and then log itself back in when the backup has had time to complete. This was working well under Windows 98, using the background process hook to check the time and logout if necessary, and using Windows task scheduler to log back into Arev. Every since the upgrade, the logging out part has only worked occasionally, whereas the task scheduler religously starts an Arev session every time, which of course results in multiple Arev sessions being run at the same time. I suspect that XP's Virtual DOS Machine has something to do with this, perhaps chewing up resources to the point where it is never idle. The Yield to Windows option in Arev is being used and I have also tried a program called Tame, but it still doesn't always log out. They have a Windows 2000 network with the Win 2000 Service v2.1, using named pipes-]TCP/IP).

Any ideas?

Gray Cunningham

If the machine is 100% dedicated to Arev indexes, why not run it on DOS? There will then be no problem with potential XP timer issues.

J

I don't know if it made it to XP, but there used to be an auto-login feature in TweakUI from Microsoft. If you find out, post a response.

Don M.

A very good question indeed! That was the first generation of this client's indexer, however, the powers that be decreed that all workstations would be upgraded, no exceptions. In their defense, the indexer will ultimately be a dedicated indexer for the new, improved, OpenInsight version of the application…which keeps getting pushed back by "gotta have now" modifcations to the Arev application. Sigh…

Don,

Logging in is not the problem, its logging out…unless the autologin routine has the ability to prevent multiple occurances from being launched…hmmm, maybe I'll try to find some info…

Thanks

Just an idea to prevent multiple logins.

Why not have a batch file that runs Arev and checks/sets a flag once you have logged in.

eg:

if exist flag.dat goto skip

echo anything]flag.dat

arev account /x etc

del flag.dat

:skip

Gary,

I am just interested…

How could AREV not log out when it is suppose to log out?

I mean, or ummmm… I would guess you are having the program check time and logout if the time exceeds a certain time??? And you are using a sentence like "EXECUTE OFF"???

Can you show the code where it is checking the time and logging off?

How is the background process running? I used to have a process on the post indexing hook that would perform several processes as well as checking the time. If within a certain time range it would execute the RBASIC LOGOFF statement.

Perhaps this method would be more reliable then the method you have in place.

The indexer was running from a batch file on a DOS machine. After the ARev statement in the batch it would execute a freeware dos utility WAITUNTL hh:mm:ss and then loop back to the arev statement. Obviously this is not necessary with the task scheduler.

Warren,

That is exactly what I am doing with the post indexing hook, although I added a little bit of code to not logoff if the login took place after the logoff time but before midnight, for the times when I might be working late. I even used a similar freeware routine and loop to log back in, when the machine was pure DOS. What puzzles me is that the RBasic code has not changed from DOS to Win 98 to Win XP, and it worked perfectly up until the upgrade to XP occurred.

Good Idea, thanks Paul. I will try that, however at the present time the "not logging out" during the backup is a bigger concern…once that is resolved I shouldn't have to worry about multiple logins.

I agree with Richard Hunt

Richard,

My question exactly! I will post my code, but I feel that it is more of an XP issue because the same code worked perfectly when the indexer was run on a pure DOS machine and even on a Win 98 machine.

—- Start of Code —-

READ LOGOUT.TIME FROM CONTROL.FILE,"INDEXER.LOGOUT.TIME" ELSE

 LOGOUT.TIME="

END

*

LOGOUT.TIME=ICONV(LOGOUT.TIME,"MTS")

*

DATE=DATE()

TIME=TIME()

*

* If this is the first time, fool the system into thinking we logged

* on one second ago

*

IF @USER2=" THEN

 IF TIME=0 THEN

    @USER2=DATE-1

    @USER2=86399

 END ELSE

    @USER2=DATE

    @USER2=TIME-1

 END

END

*

LOGIN.DATE=@USER2

LOGIN.TIME=@USER2

*

BEGIN CASE

 CASE LOGOUT.TIME="

    NULL

 CASE DATE=LOGIN.DATE AND LOGIN.TIME GE LOGOUT.TIME

    NULL

 CASE TIME GE LOGOUT.TIME

    MESSAGE.TIME=OCONV(TIME,"MTS")

*

    MSG("TC013",'','',MESSAGE.TIME) ; * Timed Message 

*

    PERFORM "OFF"

END CASE

—- End of Code —-

Thanks,

Gray

What happened to the indentation of my code that I posted in the previous response? Very hard to read like that!

Gray

Gray,

You can embed HTML inside of square brackets.  So to format code, use the 

 tag to let the browser know it is preformated.

Pat

</QUOTE>

----

=== At 07 NOV 2002 01:42PM Pat McNerthney wrote:  ===

<QUOTE>

</QUOTE>

----

=== At 07 NOV 2002 01:50PM [url=http://www.sprezzatura.com" onMouseOver=window.status= Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>mind you - getting it wrong can have interesting effects. 



[url=http://www.sprezzatura.com" onMouseOver=window.status= Click here to visit our web site?';return(true)]The Sprezzatura Group[/url]

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

=== At 07 NOV 2002 03:32PM Victor Engel wrote:  ===

<QUOTE>I suspect your read is failing. Then LOGOUT.TIME is null and the first case executes.





---- Start of Code ----


<code>


READ LOGOUT.TIME FROM CONTROL.FILE,"INDEXER.LOGOUT.TIME" ELSE
   LOGOUT.TIME="
END
*
LOGOUT.TIME=ICONV(LOGOUT.TIME,"MTS")
*
DATE=DATE()
TIME=TIME()
*
* If this is the first time, fool the system into thinking we logged 
* on one second ago
*
IF @USER2=" THEN
   IF TIME=0 THEN
      @USER2=DATE-1
      @USER2=86399
   END ELSE
      @USER2=DATE
      @USER2=TIME-1
   END
END
*
LOGIN.DATE=@USER2
LOGIN.TIME=@USER2
*
BEGIN CASE
   CASE LOGOUT.TIME="
      NULL
   CASE DATE=LOGIN.DATE AND LOGIN.TIME GE LOGOUT.TIME
      NULL
   CASE TIME GE LOGOUT.TIME
      MESSAGE.TIME=OCONV(TIME,"MTS")
*
      MSG("TC013",'','',MESSAGE.TIME) ; * Timed Message 
*
      PERFORM "OFF"
END CASE

—- End of Code —-

Heheh, so much for trying to repost the code…

Wow! This is like deja vu all over again.

Maybe the old "midnight" bug has reappeared in XP?

Victor,

I would be very surprised if it is the read, since it always worked prior to XP, but you never know. Just for fun, I'm going to throw in an error message and see what happens. If that is indeed the problem, I'll definately owe you a beer or 2. Thanks for the suggestion.

Gray

I am probably tired, but I don't undertand the 2nd case.

<code>

BEGIN CASE CASE LOGOUT.TIME=" NULL CASE DATE=LOGIN.DATE AND LOGIN.TIME GE LOGOUT.TIME

* Why not OFF here?

CASE TIME GE LOGOUT.TIME MESSAGE.TIME=OCONV(TIME,"MTS") * MSG("TC013",,,MESSAGE.TIME) ; * Timed Message * PERFORM "OFF" END CASE

I would expect something like this

BEGIN CASE CASE LOGOUT.TIME=" NULL CASE DATE ] LOGIN.DATE OR LOGIN.TIME GE LOGOUT.TIME MESSAGE.TIME=OCONV(TIME,"MTS") * MSG("TC013",,,MESSAGE.TIME) ; * Timed Message * PERFORM "OFF" END CASE

OK,OK I was tired

Your code requires @user variable (LOGIN.DATE) not to be changed.

If cleared … problems appear.

The following code seems to be more robust:

(meaning of LOGIN.TIME was changed … means first allowed logon time)

READ LOGOUT.TIME FROM CONTROL.FILE,"INDEXER.LOGOUT.TIME" ELSE

LOGOUT.TIME="

END

READ LOGIN.TIME FROM CONTROL.FILE,"INDEXER.LOGIN.TIME" ELSE

LOGIN.TIME="

END

INSIDE_LOGIC=(LOGIN.TIME<LOGOUT.TIME)

TIME=TIME()

IF (TIME<LOGOUT.TIME=TIME<LOGIN.TIME)=INSIDE_LOGIC THEN

* BETWEEN(TIME,LOGIN.TIME,LOGOUT.TIME)#INSIDE_LOGIC

code for off

END

continue

In yours and the above code examples, it is worthwhile to:

EXECUTE "OFF" and opposed to PERFORM "OFF"

The reason being is that an active select list could interfere with the code since PERFORM uses it while EXECUTE doesn't

*

Your use of logical (boolean) variables is interesting. I tend to use them a lot too

*

* the following variable LOGICAL will evaluate to 1 or 0

* the point is that a logical variable can be very complex, if need be.

LOGICAL=(A a OR a is null

LESS:

* what you do if a is less or null

.. and so forth

Don M.

The code for loging off … a tried not to prescribe the way as I am good at this:)

I agree that the code may be hard to read, but I canot remember whether between belongs to the language or not.

(a a OR a is null

LESS:

* what you do if a is less or null

.. and so forth

Some comment is wrong (a=' in both cases), but here

(in Prague is 1:33 and I am almost sleeping :) )

Is the problem still open?

The problem with INDEX.CONTROL and POST.INDEX is:

There are cases when you call INDEX.CONTROL:

A) There are pending transactions

B) There are not pending transactions

You call it with

a) @DATA='

b) @DATA#''

In cases *b the index.control does not work, it returns back

In case Aa the index.control performs some work and then calls post.index. Post.index returns to index.control.

In case Ba the index.control waits for a keystroke and does not call post.index at all.

According case Ba you mustnot invoke index.control if there are no pending transactions, otherwise you loose the control.

If there is a solution using INDEX.CONTROL, it must

In REPLACE BACKGROUND

(LOGOFF if required)

a) check for pending transactions and not call INDEX.CONTROL if there are none.

b) if there are pending transactions, invoke INDEX.CONTROL

IN POST.INDEX.CHECK

(LOGOFF if required)

a) check for pending transactions and SET @DATA:=DUMMY$KEY if there are none. (DUMMY$KEY is something what does nothing except forces return from INDEX.CONTROL through REPLACE BACKGROUND to INPUT.CHAR)

(see http://www.revelation.com/Discuss.nsf/f12696d31000b22a8525652b00831bb2/7a2af5b47b32002885256faa0049c6da?OpenDocument)

b) if there are pending transactions, return without @DATA change.

Questions:

1) Are my observations right?

2) How can I effectively test for pending transactions?

I am sure, my observations was OK.

Solution: There should be another process, which does write forcing a pending transaction (You may create a DUMMY table for this reason). This process may run as replace background on the same machine in WinXP, or on another machine when dedicated indexor is not multitasking.

Why there were not problems before update to WinXP:

There are several possibilities

a) The older machine was so slow, that there were pending transactions all the time

b) There was a process which wrote just before or the treshold time and these transactions was not indexed yet

c) There was a process which wrote during the time needed to off the indexor.

There is problem remaining:(

It seems that INDEX.CONTROL after invocation caches the tables with pending transactions. It handles one transaction per indexed field,

if it made update, it calls post.process … it does not check tables where no pending transactions were at invocation time.

So if you want to be able to force post.process, you must create pending transaction in the DUMMY table before invocation of INDEX.CONTROL. Than when another process creates pending transaction in DUMMY table, post.process is invoked.

May be post.process can create pending transactions in DUMMY table to keep INDEX.CONTROL running? (Perform cleartable DUMMY on indexor logout?)

POST.PROCESS can force INDEX.CONTROL restart (@DATA=DUMMY$KEY) to recache tables with pending transactions.

It seems to be sufficient to force it say when RAND(100)<3.

Small correction … caching … all tables with SI.MFS are cached, not only those with pending transactions, so forcing restart is not required (unless you create a new !file … but in that rare case you must reattach the volume, so manual solution is expected).

Our current implementation works as follows:

dedicated indexor writes time():RAND(1000) to an btree indexed field of a dummy record of a dummy table at startup. It does the same in post.check process. It keeps dedicated indexor indexing even on fast machines on fast environment.

Otherwise once the indexor completes his work it does not check for newly pendin transactions (it just waits for a keystroke).

Our current implementation works as follows:

dedicated indexor writes time():RAND(1000) to an btree indexed field of a dummy record of a dummy table at startup. It does the same in post.check process. It keeps dedicated indexor indexing even on fast machines on fast environment.

Otherwise once the indexor completes his work it does not check for newly pendin transactions (it just waits for a keystroke).

Our current implementation works as follows:

dedicated indexor writes time():RAND(1000) to an btree indexed field of a dummy record of a dummy table at startup. It does the same in post.check process. It keeps dedicated indexor indexing even on fast machines on fast environment.

Otherwise once the indexor completes his work it does not check for newly pendin transactions (it just waits for a keystroke).

View this thread on the forum...