From: "Kevin Solomon"
To: "Ian! D. Allen" <idallen@freenet.carleton.ca>

One thing I did find out the hard way last month was the importance
of ensuring you've coded the correct MSGCLASS.  When I was writing and
testing the statistics JCL for our IEPRINT application I coded MSGCLASS=X
so I could view the complete output in the IOF output spool queue.
X is the "hold until released" class.

Well, we released the statistics modifications to IEPRINT into production
and I neglected to change the MSGCLASS.  At the time I had the statistics
record job running as a separate job from a print request.  Therefore,
every time a print request was submitted from our 53 centres across the
country another output listing all of the messages was written to IOF.
Since we have about 3,500 to 5,500 prints a day it tends to add up.

After three days, one of the systems people called to tell us that the
mainframe was within 30 minutes of having IOF completely full.  For some
inexplicable reason they thought that it wasn't necessarily a good thing
to have the mainframe SYSs shut down and have 75 job submits/second
queue up for start on the SYS input queues.  Go figure!

They had to start purging nearly 18,000 entries off the IOF output queue.
A peculiar quirk about that was that they couldn't purge all of them at
once.  They could only issue a command for 100 max at a time.  What an
overwhelming sense of power and control!  We're a small project but,
they know who we are now!

The next day I rewrote the statistics job to integrate it as step one of
the print request job.  To be on the safe side, I coded MSGCLASS=R, which
sends all messages into oblivion.  On the EXEC statement of the first
step of the print job I added COND=(16,LT) so only a catastrophic failure
(RC 20) of the statistics step would prevent the print job from executing.

I wasn't taking any chances.