They want to schedule it to run every hour....so I assume some hours it will run and find nothing (that was a waste), and other hours you will be watching the queue depth climb and climb, gritting your teeth, beads of sweat forming on your forward, w-i-s-h-i-n-g the clock on the wall to hurry up a get to the top of the hour, so the job starts and drains that queue before it overflows....
 
On the other hand, you could trigger on first with a 60 second wait. No messages no trigger no waste. But if message arrive with any frequency, the job starts up once and keeps the queue clean, until no messages arrive in 60 seconds. Then it goes to sleep, possibly for hours (overnight) or days (the weekend).
 
If they are worried about wasted triggers, then adjust your wait time so that you get less than 24 triggers during a day (the amount of times your app would have started if it was scheduled every hour). If your app triggers to often, it is not a problem with triggering, it only means your Get with Wait Interval is to short.
 
 
 
 
 
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Richard Jackson
Sent: Thursday, November 18, 2004 12:50 PM
To: [EMAIL PROTECTED]
Subject: Re: BATCH messages advice requested


Janet

I have questions :-)

Are the messages timely, do they need to be proccessed when they arrive?

Do do you also update VSAM, DB2 etc.... you'll need RRS with Batch.

Getwait is a given in Batch or CICS..

Don't forget to issue Syncpoints(but maybe not for every message) and maybe before you reach Q empty.

In this model.. I happen to like long running (getwait),  triggered once, CICS tasks that read application batched messages.

Rich







"Dye, Janet E" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>

11/18/2004 12:28 PM
Please respond to MQSeries List

       
        To:        [EMAIL PROTECTED]
        cc:        (bcc: Richard Jackson/DTCC)
        Subject:        BATCH  messages advice requested



Currently, most messages received on our mainframe qmgr are destined to
CICS and are triggered 'on first' .  We are in the process of putting in
a new application that will receive large volumes (50,000+) of batch
messages from a vendor.  The messages will come in at different times of
the day, sometimes being just a few messages at a time and other times
being the large volume I just mentioned.  The developer wants to
schedule a job that runs different times throughout the day to process
these messages. My concern is that since volume is unpredictable and as
more applications do this, it will become impossible to plan disk space
to hold the number of messages that could potentially be in the queues
any point in time.  My feeling is that I need to create a policy that
messages are removed from a queue upon arrival or at least upon arrival
of a certain volume.  I have suggested to the developer that we will
need to set up a trigger to trigger 'on first' or on 'depth', and they
code the program to do a MQGET with a wait of a minute or so.  I am
getting a little resistance to this in that they are concerned about the
job being triggered a lot, and they would prefer to just schedule it to
run every hour or so.  

I am interested to know what policy, if any, other shops have for this
situation.

Thanks

Janet Dye
Infrastructure Systems Engineer - Middleware
UMB Bank, n.a.
1008 Oak Street - Mailstop 1170305
Kansas City, MO. 64106
office: 816-860-1109
cell  : 816-686-1544

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive





This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.

Reply via email to