Janet, The two approaches are not mutually exclusive. Go ahead and plan your disk space for some reasonable number of messages and set trigger on depth. Then the app will never exceed it's quota and your concerns are met. In addition let the developer schedule the job. As long as the schedule is adequate to process the volume, the trigger will never be exercised which should alleviate the developer's concerns. Then over time as the volume increases, the job will begin to be triggered.
The answer to the issue of potentially being triggered a lot is that this is a Good Thing. Instead of having to monitor volume trends and periodically adjust disk and QDepth requirements based on forecasts, the application automatically adjusts to usage patterns, never runs out of disk space and runs as often as needed but no more and no less. If you do batch only and no triggering what tells you that your batch interval is too large? Hitting the MAXDEPTH or filling up your disk space. Not good. On the other hand, if you trigger the job on depth and the trigger is firing several times a day you will know to decrease the batch interval until the trigger fires only during exceptionally heavy loads - but without the outages associated with exceeding MAXDEPTH or DASD. It sounds like you will need to occasionally add DASD as more applications are added. Triggering will extend the period of time between incremental DASD increases and smooth out the usage trends so that your DASD can be based on normal daily cycles and not some exceptional higher value such as month-end. Hope that helps. -- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Dye, Janet E Sent: Thursday, November 18, 2004 12:28 PM 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
