future date testing

[John Esak]

Again, I shouldn't be sticking my 2 cents in on this thread... But...

Yes, the + "30" is a nifty idea. Like it.

For Mark's comment, true the system maintained fields are a problem.. @cd,
and @ud being the two related to the problem.  He said you can't adjust them
on a record level.  True, normally, very true. However, with the new(er)
GETBUF/PUTBUFF() routines, it would be a cinch to change them to anything
you wanted just minutes before you go live with a current dating mechanism.
If you're not a full blown low level programmer, it takes a bit of playing
around to get the format just right, but with a little help *from* a low
level programmer it would be a simple 2 or three line program to change the
@cd, @ud (and oh yes, @bd) of every record . If that helps.

Also, by the way, it would only take a very little while to simply write all
the "used" records to a new file using only file i/o processing commands to
a new key file touching any of the system maintained fields along the way to
what you want them to be, and then copying this new "shrunk" key back to the
original key name, then re-freechaining and re-indexing.  

John Esak


> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] 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->
> -- 
> Audio panton, cogito singularis,
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>