RevMedia

In the recent PC-User "Database Challenge" one of the things that impressed the judges was the comprehensive security that we were able to demonstrate. After the keyboard had been left unattended for a user-defined length of time, the screen cleared and the user was prompted for a password. Unsuccessful password attempts were logged to an audit file, and too many attempts (user-defined) logged the user out. If no password was entered for a user-defined length of time, the user was logged out and an access violation logged to the audit log.

This was implemented (perhaps "kludged" would be more accurate) by intercepting the calls to the background index processing and replacing our own routine there. To understand this it would probably be useful to reconsider the behaviour of INPUT.CHAR.

INPUT.CHAR is the standard system input routine. When it is called, it loops, waiting for a keystroke until either a key is pressed (when it processes it and/or returns it (see REVMEDIA Vol 1 Issue 2)) or the time determined as the time to wait until indexing in the environemt parameters has elapsed, the routine INDEX.CONTROL is called. This then starts updating any waiting index transactions. When it has completed it waits for the index wait time and then again starts to update index transactions (unless a key is pressed in which case index processing stops and INPUT.CHAR resumes).

Thus to have our own routine dynamically called after a period of inactivity at the keyboard, all that we have to do is copy $INDEX.CONTROL to $INDEX.CONTROL.OLD in VERBS and out our own $INDEX.CONTROL in VERBS. Once our program has completed its tasks it could then (if we wished it to) call INDEX.CONTROL.OLD.

Note that as we are putting out own $INDEX.CONTROL in VERBS we do not need to Catalog it as the system will look to VERBS before checking VOC pointers. If you feel safer leaving your $INDEX.CONTROL in BP (as then you won't forget to copy it over after amendments) don't forget to Catalog it!

There are however two major problems with this method. The first is that subsequent RevTech upgrades may overwrite our $INDEX.CONTROL. The second is that after we have called $INDEX.CONTROL.OLD, control is not returned to our program/INPUT.CHAR until a key is pressed. Thus if this were being left running overnight, our $INDEX.CONTROL would only be called once before $INDEX.CONTROL.OLD took over for the night. On a network this could be best circumvented by having one copy of VERBS for those workstations needing to background update indexes, and another for workstations needing to call out routine.

Both problems would be sorted out by one enhancement to the AREV software. What is needed is a place to insert user catalyst calls in INPUT.CHAR and INDEX.CONTROL. Once these were implemented we could have our own independent background processing tasks.

Well, I'm glad to be able to impart some good news. RevTech WILL be implementing such a hook. Because of the resource being committed to Release 2.0 this will not be in Release 2.0. but it may see its way into Release 2.1 or 2.2. As for timescales...... well, second guessing software releases is like weather forecasting, so I'll leave that to the experts, however I have noticed that there was more frog spawn in my pond than usual for the time of the year so..........