RE: QSYSOPR size

Jim:

My immediate reaction is simply that if it's "too fast" for *WRAP to work, then 
*NOMAX would be dangerous. Make certain you read and understand the 
implications of the help text for the CRTMSGQ MSGQFULL() parameter before 
choosing *NOMAX, especially as related to QSYSOPR. If nothing else, make sure 
you have a bulletproof procedure for removing huge, selected blocks of messages 
'on the fly' before making this change.

Unfortunately, it seems to me that the real fix for this is to stop 
applications from flooding QSYSOPR (or _any_ message queue) with meaningless 
messages.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   1. QSYSOPR size (Jim Damato)
>
>Has anyone ever had to resize QSYSOPR?  Our application software is drowning
>the operators message queue in meaningless messages.    The message full
>action of *WRAP doesn't work when messages are hitting to fast to wrap.
>
>I was gonna create a new message queue named QSYSOPRX in QSYS with either a
>greater number of increments than QSYSOPR's or *NOMAX.  Then I was gonna
>rename out the old QSYSOPR and rename in the new one, at a point in time
>when I could log off the operators and get the queue out of *BREAK delivery.
>
>Seems kind of scary to me.  I'm wondering whether I'd regret setting up
>QSYSOPR with size of *NOMAX.  I'm also wondering whether there's an easier
>way to tweak the size of a message queue.

-- 
-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455