Re: Read all about it - 8 IBM RFE's entered. Vote now!

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Yep this would be the kind of thing I mean. There are also direct 
historical kinds of things - we have a process for downloading invoices 
to field specialist, and it has an ADDDAT and ADDTIM pair of fields.

These are kept around "forever", basically - there is a kind of purge.

These are used for an "as of" process, to know what was downloaded when 
the invoice is uploaded back. And what text values were in force when 
the download occurred.

Temporal support as in place now (system time) could likely be an 
excellent replacement (not sure in the case mentioned, there are 
considerations around the kind of changes were downloaded) for files 
like this.

Cheers
Vern

On 9/5/2017 6:45 AM, Rob Berendt wrote:
> <snip>
> Now for those of us who have already implemented some kind of history,
> this could be about the same usage, just that the system automatically
> manages more of it.
> </snip>
>
> You mean history like this?  Like our biggest library, by far, on our ERP
> machine is our journal receiver library?
>
>                               % of          Size in
> Library      Owner           Disk        1000 bytes
> #MXJRN       MIMIXOWN       39.85      2391890501.6
> QGPL         QSYS           11.27       676212596.7
> ERPLXF       SSA             9.86       591586611.2
> ERPLXSAVF    SSA             2.95       177205379.1
> QPFRDATA     QSYS            1.56        93850730.5
> ERPLXUSRF    SSA             1.39        83154870.3
> ...
>
> See RTVDSKINF and PRTDSKINF *LIB
>
> We do some crazy journal retention and analysis.  I think we are the
> target market for temporal tables.  They even have slides in their
> presentations mentioning journal scraping.
>
> Rob Berendt