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

> On Behalf Of Jim Damato
> Subject: QSYSOPR size
> 
> 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.
> 
> Any advice or warnings?  Much thanks in advance...
> 
> -Jim




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.