|
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 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.