future date testing

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
[mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Fairlight
> Sent: Thursday, June 03, 2010 3:10 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: future date testing
> 
> When asked his whereabouts on Thu, Jun 03, 2010 at 02:51:31PM -0400,
> Boaz Bezborodko took the fifth, drank it, and then slurred:
> > Why not write the FPro routine to look at a declared variable instead of
> > @td and then load that variable to @td+"30"?
> >
> > Then, when you go into production all you have to do is remove the
> > '+"30"' to have it read the present system date.  Al the rest of the
> > routine should remain the same.
> 
> Interesting concept for processing you control--wherever there's a time
> formula, use what you're suggesting.  Creative.
> 
> The problem I see is in what you can't control-- at cd, @ud, et al.  Those
are
> set by internal time calls in *clerk/*report, and you can't manipulate
what
> they do at the record level.  So if even some of the attendant testing
> relies on anything uncontrollable by processing, you're better off just
> using a virtual environment.
> 
> mark->
> --

Mark,

You are correct.  However, if one is using select processing, one can
manipulate these dates by applying the proper formula to get them within the
date range wanted.  If it meets the criteria, select it.  If not end.

What I considered suggesting is using -r on the command line with the date
wanted and set a variable based on @pm.  If @pm is not set, revert to the
original date procedure.

Richard