RE: Which Spool Files Actually Printed? -- MIDRANGE-L

Perhaps "better", since instead of a
program to process those additional data queue entries, a DSPJRN can be
performed to produce results [specific to those batch jobs] directed to
an output file, then a report produced against just the specific
information generated or selecting and reporting about only the
information of interest.

Sorry... but you're suggesting this is better because it doesn't require a
program? What is the basis? How do you propose doing these things without
such a program? It is choice, of course, but I like the DQ approach much
better because it is event-related, whereas the DSPJRN is after the fact and
relatively clumsy. Plus the issues that come about with keeping track of
what sequence number the program -- oh, sorry... whatever the entity is --
saw last, handling sequence number resets and on and on.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I always wait until a jury has spoken before I anticipate what they'll do."
-- U.S. Attorney General Janet Reno

Our printing is decentralized. I'm trying to figure out what reports
our overnight batch jobs create and which ones actually print, with
an eye to eliminating unnecessary paper usage.

Most of the time, if I have the USRDTA value I can tie it back to a
program.

If I attach a Data Q to the OUTQ I can get a type 01 record when a
spool file in ready status hits the OUTQ. From that I'm happy to
assume it printed (it's close enough for what I'm doing.) But type 01
records don't contain the USRDTA.

If I set an environment variable at the system level it looks like I
can get type 03 records (V6R1) which do contain the USRDTA, but this
is for everything that hits *every* OUTQ and *every* status.

So it looks like I need to merge the results from type 01 records
with type 03 to get what I want.

Has anyone done anything like this? Any better suggestions?

If I could, I'd like to get the number of pages, but I don't anything
about that in the data queue entries.

While the amount of data may still be large, the data automatically
written to the QACJRN *JRN when the QACGLVL system value is set to *JOB
and\or *PRINT might be valuable. Perhaps "better", since instead of a
program to process those additional data queue entries, a DSPJRN can be
performed to produce results [specific to those batch jobs] directed to
an output file, then a report produced against just the specific
information generated or selecting and reporting about only the
information of interest. Some doc references that might help to decide
if this approach is reasonable and will provide the desirable
information; to be sure the number of pages, lines, and bytes are
available with accounting level.

Journaling accounting information; QACGLVL: