RE: SAV/RST spool files function in OS/400

This entire discussion started with you wanting a SAV/RST function from IBM (see subject line), and claiming that IBM should be able to easily do it.  I was countering that by making the statement that it would not be that easy if done right.  Now your part of the discussion has turned into something entirely different.  What do you really want/need?  A SAV/RST function or a spool file archiving function with all the capabilities you discuss below?  I assure that what you are asking for below would never be included in a SAV/RST function that IBM provided.

Dave

-----Original Message-----
From: Buck Calabro [mailto:buck.calabro@aptissoftware.com]
Sent: Thursday, September 28, 2000 8:19 AM
To: MIDRANGE-L@midrange.com
Subject: RE: SAV/RST spool files function in OS/400

Dave Leland wrote:

>Hmmm, I'm not sure why you say "the
>data is hideously complicated to work
>with".  Have you attempted to use
>QSPGETF and QSPPUTF. 

I looked into it very briefly.  The "hideous" part comes in when you want to
manipulate the resultant data from QSPGETF.  I did a quickie prototype but
could not find any documentation of the output format.  Preferably, I want
to "extract" the AFP spooled file, store it in an archive of my own design
(I need to split the bills apart by customer) and then restore an
individual's customer's bill so that I can print/FAX/email it.  If I lived a
little bit west of here (the place called Utopia) I would also add a
watermark "C O P Y" across each page.

Don't forget that the overlays and page segments may have changed in the
interim and I need to use the originals.  Oh, does duplex make a difference?
When only some of the pages are duplexed?

-snip-

>Do you want IBM to write the CL
>wrapper over these 2 APIs?

<grin> Not really... I want IBM to publish the format of the returned data
so that I can work with it, or to use a format that is designed for this
purpose.  I understand that these APIs are really for backup/restore
purposes and aren't intended for me to muck around with, but my life would
have been MUCH simpler last year if I'd had access to the data in a format
that I could readily manipulate. 

As it is, I have had to store all the raw data that went into the original
bill, including the actual database data, the original page segments and
overlays, the original printer file and the original RPG program so that I
can "simply" re-generate a copy of a customer's lost bill exactly the way it
looked in 1998, not the way it would look if the 1998 data were used on
today's bill run.  Sadly, I'm told there are legal reasons for this, and
that requirement is not negotiable.  Grrr.

Anyway, for now, my business problem ("Reprint any AFP customer bill so it
looks EXACTLY like the original") is solved, and until the database
requirements get out of hand storing all that raw data, management are
putting my meagre talents to work elsewhere...

Buck Calabro
Aptis; Albany, NY
"We are what we repeatedly do.
 Excellence, then, is not an act, but a habit." --Aristotle

Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---