|
On the surface, this looks possible under OpenVMS, by "borrowing" a
couple of system service intercept vectors, and/or by recoding some
of the time-fetching routines in the kernel to be "process dependent".
(There is a central time source in OpenVMS, but there are a *number*
of routines that look at this time source directly -- making this
scheme potentially rather difficult to implement.)
This application appears more easily possible on IBM mainframes due to
the partitioning between the operating systems, the users, and even the
user-storage (DASD) partitioning that is so common in this environment.
(I'd imagine that providing a different timebase for each guest operating
system under VM would be feasible...)
However, this scheme would play havoc with shared resources, such as
the ODS2 shared file system, that are common on OpenVMS. Among other
problems likely to appear with this "skewed time" scheme, there would
be no way to "partition" all the sources of time the application might
see, and that the application might generate and save. (CMS libraries,
among other examples, tend to get "cranky" when more than a 30 second
skew is visible...) But one could obviously use "private" disks here.
--
Speaking of VM, the Galaxy project might be an option here -- this
ability to maintain different time bases would be an interesting
value-added addition to the Galaxy design center. But, Galaxy is
not yet available...
|
|
Somewhere around, I've got a jacket for COBRTL on VAX which intercepts
all time routines and adjusts them forwards or backwards according to a
logical name. A similar trick could be applied to the LIB$ routines.
This may make it possible to simulate different times on a per process
basis, without upsetting the file system and other parts of OpenVMS.
Send me MAIL if you're interested in the timeshifted COBRTL.
John Gillings, Sydney CSC
|