Re: Accessing PRTF record data buffer

Thank you Brian, Steve, Mike and Scott for excellent suggestions.

Steve and Mike, My report pgm takes a long time to finish and my
requirement is to get hold of data as and when it is written. Because of
this, CPYSPLF could not work for me.

Brian, thanks for suggesting OVRDBF. This will definitely give me immediate
access to the data, and is one solution that I will keep in the back of my
mind.

Scott, many thanks for all the excellent suggestions. The first suggestion
with SPECIAL files is one that I am investigating right now, and this seems
to fit my requirement exactly. I just read the "Using SPECIAL Files" in
Chapter 18 (Accessing Externally Attached Devices) in ILE RPG Programmer's
Guide to get a better understanding and to see an example.

I have been programming using RPG for about 12 years now, but I must say
that I am constantly surprised by the capabilities provided by the RPG
language. I have never used SPECIAL files before, but it seems amazing that
a feature as powerful as this has existed as part of the core language
itself.

Thanks once again,

Sarvapriya Tripathi


======================================================================================
Scott Klement wrote:
======================================================================================

I have a few thoughts:

a) RPG supports something called 'SPECIAL' files. The idea is that you
tell your program that it's writing data to a file (using O-specs, etc)
but instead of physically writing the data, it calls a program and
passes the data as parameters.

With (relatively) minor changes to your report program, you could
replace the existing PRINTER file with a SPECIAL file. Then the program
that it calls would get the "record buffer" as a parameter.

b) You could keep the existing program completely unchanged, but issue
an override before you call it. If you do OVRDBF you can re-direct
printer output to go to a database file. For example, if the program
prints to QPRINT, you could do OVRDBF FILE(QPRINT) TOFILE(QTEMP/MYFILE)
and instead of printing, it'd save the data to the database file named
"MYFILE" which you could then read in another program.

c) You could keep the existing program unchanged, and let the data to go
the spool -- perhaps on hold -- then use CPYSPLF to copy the data to a
PF and process it. This is useful when you still want to print the
original report, but want to use the data for another purpose as well.
(However, if you don't want to print the original report, the OVRDBF
option is faster and easier.)

d) You could let the data go to the spool and extract the data via the
QSPOPNSP API and the other APIs that go with it. That way you can get
the spooled data in it's internal format and with it's internal
structures, which gives you a ton more information that CPYSPLF does,
but of course requires much more sophisticated code to understand.

e) Yet another alternative to CPYSPLF is QShell's 'catsplf' utility. It
will dump the contents of a spooled file to stdout, which makes it
possible to use it in conjunction with other QShell tools. This can be
a very easy way to parse certain bits of data out of a spooled file --
depending, of course, on what you need to do with it.

All of these can be good alternatives, depending on your needs.

======================================================================================
------------------------------

******************************************************************************

The information contained in this electronic communication and any
accompanying document is confidential, may be attorney-client privileged,
and is intended only for the use of the addressee. It is the property of
Ryder System, Inc. Unauthorized use, disclosure or copying of this
communication, or any part of it, is strictly prohibited and may be
unlawful. If you have received this communication in error, please notify
the sender immediately by return email, and destroy this communication and
all copies of it, including all attachments. Electronic communication may
be susceptible to data corruption, interception and unauthorized tampering
and Ryder disclaims all liability of any kind for such actions or any
consequences that may arise directly or indirectly therefrom.
******************************************************************************