Last-Accessed timestamp Updater (view_timestamp.pl)

View_q uses the Last-Accessed timestamp to determine if a view should be put into quarantine.

The Last-Accessed timestamp is not updated by read operations and as such it's not entirely trustworthy.

We need a small poll job that can sit on the ClearCase view server(s) and occasionally read out the albd log to see which views has been started, and then check if their Last-Accessed timestamp is older than some threshold value (e.g. 2 days) and if it is, then run a cleartool setcs- current command on the view.

The setcs -current command is "free" in the sense that it doesn't change the view in any way, but it recompiles the config spec, which has the desired side-effect that the Last-Accessed timestamp is updated.

Be aware that this may not be a good idea on snapshot views because it may trigger a required cleartool update on the client hosting the snapshot view tree - which we don't want! - Investigate before implementing!

Also consider that if the script need to to know when it was executed last, and only do somthing "since then" (in this case it will become a parameter to the -since switch of cleartool getlog view command). Then this is a fairly generic behavior and we could put that functionality in a separate perl module for reuse!

cleartool setcs -current works fine, although one has to be a bit patient, it takes a minute or two before the "Last Accessed" value is updated.
There is however a caveat that we will need to work around, which is the command's missing support for regions.

As it is not an option to programatically move the server executing the script from region to region (it could be the vob or view server, which must stay in the same region), we need to workaround simply by creating a temporary view tag on the fly, if the view that has been started "since" does not have a viewtag in default region, and then run setcs -current -tag TEMPTAG on the view and then remove that tag again (we already have code snippets in view_q.pl that does this - more or less).

The workaround functionality requires a list of view-storages and associated view tags, so we know whether of not to create a temp viewtag.
Luckily we already have that code snippet (for each region, list all views by view-storage-location, associate view-storage with viewtag+region)
Question is if the code should be refactored into a perl module, as we are now going to use it from more than 1 script, view_q does prepares a list of all known views, and I think this poll utility will need a similar list or hash-table, because all we have to identify a specific view is the view-storage path (please the output from getlog view below) - our key to identifying the view is the storage.

Old concept description:
The Last Acceed Timestamp in ClearCase is not actually updated on read-operations. So really the timestamp is a "last-write" timestamp.

We use this timstamp in the view_q script, and in order to be able to trust the information in this timestamp, we need a small poll job that can sit on the ClearCase view server and monitor what views the ALBD service starts up, and the do a "cleartool setcs -current" on these views. That will have the side-effect that Last-accessed timestamp is updated