For
queue depth I was planning on having a batch job in their job stream run that
issues the 'ALTER' command to set the trigger back on. This would be a
step that ran only if the job to read the queue was successful. If
they have an abend, they can fix there problem and run the job again. If
they rerun the job, the 'ALTER' step would run when the previous step that
read the queue ran to a successful EOJ.
-----Original Message-----
From: Ronald Weinger [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 1:16 PM
To: [EMAIL PROTECTED]
Subject: Re: BATCH messages advice requested
Another problem w/ triggering on depth is, if the job abends and the qdepth is not below the trigger depth you can not reset the trigger.
That means you need an application person to fix the abend and manually restart the job, and a MQ admin to reset the trigger.
We had the same issue and decided to go with schedules That way middleware administrators do not have to be involved if the application code abends.. When we explained the complexity of handling a job abend the application developers quickly bought into a schedule.
They run every business hour and pick up anywhere from 0 to several hundred messages. Operations monitors job abends and only need notify
the app owners. We made the pagesets large enough for a day's volume.
"Bender, Alan" <[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[EMAIL PROTECTED]>11/18/2004 01:42 PM
Please respond to "MQSeries List"
To: [EMAIL PROTECTED]
cc:
Subject: Re: BATCH messages advice requested
Not to get into the nuts and bolts of triggering on depth that has been
suggested by several already, it is not immediately obvious that your
programmers MUST reset the trigger on depth before terminating each time
or the trigger will turn OFF and never start your app again. This is
something small but it has driven many good programmers to distraction.
Alan
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dye,
Janet E
Sent: Thursday, November 18, 2004 11:28 AM
To: [EMAIL PROTECTED]
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
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
The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
