Awesome Scott - cheers. That gives me some good ideas and some things to
look at. I have to make sure any solution not only solves my problem but
also works with my 3rd party testing tool (who I've also asked about
this specific problem today). If I come up with anything I'll share. The
'override' idea sounds like it could go somewhere...
Thanks
Jim
If you forget you have to struggle for improvement you go backward.
Hickson, Geoffrey
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, 11 February 2011 10:31
To: Midrange Systems Technical Discussion
Subject: Re: System Date - can it be 'intercepted' ?
Hi Jim,
On 2/10/2011 1:59 PM, Jim Wiant wrote:
I did some digging and I can't find a way to override or control the
system date other than changing the date, which again is not my first
choice because it will affect all testing not just the one I want and
the impact on the journals scare me anyway.
Back during the time when we were testing Y2K stuff, we bought a product
called "AnyDate" that let us override the system date. That product
appears to still be for sale today (though, I haven't used it since
1999)
http://www.sequel-software.com/products/anydate
I don't know if it changed, but back in 1999, it essentially consisted
of two commands:
OVRSYSDATE = override system date
DLTDATEOVR = delete date override.
So you'd run OVRSYSDATE to override the system date. While that command
is in effect, %DATE(), %TIMESTAMP(), the TIME opcode, RTVSYSVAL QDATE,
etc, would return the date you provided on the OVRSYSDATE. When you ran
DLTDATEOVR, it'd revert to getting the date from the clock as normal.
So that might help you?
midrange.com
