AutoLogout/Login (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"AREV Specific"}}

[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== AutoLogout/Login (AREV Specific) ====
=== At 06 NOV 2002 01:40:12PM Gray Cunningham wrote: ===
 
 
<QUOTE>
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
</QUOTE>
----

=== At 06 NOV 2002 01:54PM Jonathan Bird wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 06 NOV 2002 01:54PM Don Miller - C3 Inc. wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 06 NOV 2002 03:51PM Gray Cunningham wrote:  ===

<QUOTE>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...

</QUOTE>

----

=== At 06 NOV 2002 03:54PM Gray Cunningham wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 06 NOV 2002 04:43PM Paul Rule wrote:  ===

<QUOTE>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



</QUOTE>

----

=== At 06 NOV 2002 05:47PM Richard Hunt wrote:  ===

<QUOTE>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?

</QUOTE>

----

=== At 06 NOV 2002 05:48PM Warren wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 06 NOV 2002 10:32PM Gray Cunningham wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 06 NOV 2002 10:36PM Gray Cunningham wrote:  ===

<QUOTE>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.



</QUOTE>

----

=== At 07 NOV 2002 05:05AM Hippo wrote:  ===

<QUOTE>I agree with Richard Hunt

</QUOTE>

----

=== At 07 NOV 2002 11:33AM Gray Cunningham wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 07 NOV 2002 11:36AM Gray Cunningham wrote:  ===

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



Gray

</QUOTE>

----

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

<QUOTE>Gray,



  You can embed HTML inside of square brackets.  So to format code, use the 
<code>
 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

</code>


---- End of Code ----



</QUOTE>

----

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

<QUOTE>Heheh, so much for trying to repost the code...

</QUOTE>

----

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

<QUOTE>Wow! This is like deja vu all over again.

</QUOTE>

----

=== At 08 NOV 2002 09:36AM Warren wrote:  ===

<QUOTE>Maybe the old "midnight" bug has reappeared in XP?

</QUOTE>

----

=== At 08 NOV 2002 10:34AM Gray Cunningham wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 08 NOV 2002 12:20PM Hippo wrote:  ===

<QUOTE>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
 

</QUOTE>

----

=== At 08 NOV 2002 12:26PM Hippo wrote:  ===

<QUOTE>OK,OK I was tired

</QUOTE>

----

=== At 08 NOV 2002 12:51PM Hippo wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 08 NOV 2002 01:26PM Don Miller - C3 Inc. wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 08 NOV 2002 07:17PM Hippo wrote:  ===

<QUOTE>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 :) )

</QUOTE>

----

=== At 08 JAN 2003 12:43PM Hippo wrote:  ===

<QUOTE>Is the problem still open?

</QUOTE>

----

=== At 16 FEB 2005 12:56PM Hippo wrote:  ===

<QUOTE>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?

</QUOTE>

----

=== At 18 FEB 2005 02:14AM Hippo wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 18 FEB 2005 07:57AM Hippo wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 22 FEB 2005 07:16AM Hippo wrote:  ===

<QUOTE>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).

</QUOTE>

----

=== At 07 APR 2005 10:04AM Hippo wrote:  ===

<QUOTE>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). 

</QUOTE>

----

=== At 07 APR 2005 10:04AM Hippo wrote:  ===

<QUOTE>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). 

</QUOTE>

----

=== At 07 APR 2005 10:04AM Hippo wrote:  ===

<QUOTE>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). 

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=D2124A23918ACF8D85256C6900668EF4|View this thread on the  forum...]]