RE: How to save an Outq

>>  Me:
>>Most anything you need to save for reprint 
>>should be saved as data in a database.

> Colin:
>possibly as  important as backing up the 
>spooled file data to a physical file, is 
>creating an index entry somewhere for that 
>spooled file that records the information 
>that you require in the unlikely event of 
>a restore.  You dont know you need it, 
>till you need it.

I'm not talking about backing up spooled file data to a physical file.  I'm
talking about leaving the source data for the report in the database.
Instead of generating an invoice spooled file and copying the spooled file
back to a physical file, you leave the invoice data intact and write an
reprint program.  Instead of wiping out month end data and depending on
saved copies of month end reports you leave the appropriate level of detail
in the database with a closed status, so that you can run reports from
closed months.

If you're saving reports to tape, develop a save routine to save the data so
that you can restore select tables to run reprints.

Saving report output as text is a fairly inefficient, incomplete technique.
I believe it should be avoided in most instances.

> Don:
>you need to convince the vendor base of 
>this as many don't allow reruning of 
>functions that update files and print 
>on the fly...payroll checks, a/p runs, 
>etc....and not just special forms, period 
>end reports, etc....

Unless you have a development staff and are willing to modify or augment the
vendor app, this is one of those unavoidable instances.

-Jim