RE: QSYSOPR size -- MIDRANGE-L

For a while it was the "job released message" when every submitted job
(thousands and thousands) was submitted on hold, then released, so that the
submitting program would have time to update a control data area with
submitted job information before the submitted job took over (got it?).
There's also a host of general, "job submitted", "job completed", "job is
processing", "job is scratching its b*tt" messages in human readable terms.
We have tons of little batches of files coming across via FTP to be launched
into little batch update streams that can send these sorts of messages.

Now, on V5R2 (upgraded last Friday) we're getting these "TCP2617 - TCP/IP
connection to remote system nnn.nnn.nnn.nnn closed" messages for most of our
network printers."  I'm still looking into them.

And every now and then one of our journals seizes when we get a "CPI70E5 -
Journal or journal receiver not available." and no new receiver is
automatically generated for 10 minutes (which I've just discovered I can fix
that now that I'm at V5R2) causing QSYSOPR to flood with "CPF7091 - Entry
not journaled to journal ..." messages for all of our active batch jobs.

QSYSOPR stopped being meaningful ages ago.  And more and more I find that
programs hang or crash because they can't send messages to a full QSYSOPR,
despite policies for clearing it.

I'll be looking into Al Barsa's recommendation for QCFGMSGQ, which looks
like something we really need to be using.

You'd be amazed by the hoops we have to jump through in the holy name of not
changing applications code.

The break handling program sounds like a neat idea.  Unfortunately they made
me a manager a while ago, and now I can't figure out how to write a break
handling program using only Microsoft Outlook.

I agree that I shouldn't set the queue to size *NOMAX.  I'd like to size it
for a day's worth of messages.  I'd also like to find the GO ASSIST cleanup
program and hijack it to do a rolling purge on QSYSOPR.

Thanks for your help.

-Jim

-----Original Message-----
From: Andy Nolen-Parkhouse [mailto:aparkhouse@xxxxxxxxx]
Sent: Tuesday, April 15, 2003 7:26 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: QSYSOPR size


Jim,

I agree with you when you say "Seems kind of scary to me."  If the
messages are hitting too fast to wrap, then you've got a serious issue
with your application.  What is it doing that buries the queue in
messages?

As an alternative, would it be possible to write a break-handling program
to receive and delete the meaningless messages?  I've always been leery
of deleting/renaming IBM-Supplied objects.  If the messages are coming in
that fast, I would also be hesitant to allow the queue to grow without
some maximum.  I do believe that you're correct that you cannot change
the size parameter of a message queue; unless there's an API I'm not
familiar with.

Regards,
Andy Nolen-Parkhouse