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
Reading EVENT msgs using COBOL or Assembler
Has anyone come across a sample program to read/create report on SYSTEM.ADMIN.*.EVENT msgs. With Websphere MQ 5.3 for Z/OS, there is a new event queue called SYSTEM.ADMIN.CONFIG.EVENT where events are written whenever you make any change to a MQ object. I would like to create a report from the msgs on that queue, was wondering if anyone has see a sample program to read EVENT msgs. Thanks Janet E. Dye Sr. Systems Programmer UMB Mainframe Technical Services email: [EMAIL PROTECTED] voice: 816-860-1109 fax : 816-860-3934 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
Re: MQGET with wait in CICS
I have verified that when I give it an interval of 6000 that the tran ends after 60 seconds. But even if my interval was higher than I had intended, that wouldn't explain why the CPU time goes up during the wait. I believe that Jim Ford has hit the nail on the head in saying 'blame the developer'. I took a sample program that was delivered with MQ, CSQ4CVJ1, and made two lines of code changes, MQGMO-WAIT and set a 60 sec interval. When I execute it, it is NOT using CPU during the wait. So it appears that something done differently in the developers code is causing the problem. I just need to figure out what. Thanks for the help! --Original Message- From: David Awerbuch [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with wait in CICS Janet, Stefan raises a good point. Remember that the timeout interval for MQGET is measured in milliseconds (thousands of a second) and not second or minutes. PErhaps your timeout value needs to be multiplied by 1,000 or some such other order of magnitude. Let us know what the answer is. Dave A. David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] - original message - Date: Mon, 24 Jun 2002 15:54:40 -0700 From: Stefan Sievert [EMAIL PROTECTED] Subject: Re: MQGET with wait in CICS Janet, are you sure that the GET with wait in your application program is not implemented with a logic like this: while MQRC = 2033 (no msg avail.) MQGET nowait end This would explain the CPU hunger. I'd check the application to verify that the GMO_WAIT option with a reasonable WaitInterval is used. Just a thought (from nasty experiences...), ;-) Stefan From: Dye, Janet E [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQGET with wait in CICS Date: Mon, 24 Jun 2002 16:24:00 -0500 We have noticed that when a CICS program does a MQGET with wait, that during the time interval that the task is waiting, that it is using a lot of CPU resources. When I do a MQGET with wait in a batch environment, it does not appear to be using any resources during the wait. Has anyone else experienced this. For purposes of being efficient, we wait a few seconds after a MQGET to see if another messages arrives, in order to avoid the process being triggered again and having to go thru the overhead of the MQOPEN/MQCLOSE. Any suggestions? Janet Dye __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com 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
MQGET with wait in CICS
We have noticed that when a CICS program does a MQGET with wait, that during the time interval that the task is waiting, that it is using a lot of CPU resources. When I do a MQGET with wait in a batch environment, it does not appear to be using any resources during the wait. Has anyone else experienced this. For purposes of being efficient, we wait a few seconds after a MQGET to see if another messages arrives, in order to avoid the process being triggered again and having to go thru the overhead of the MQOPEN/MQCLOSE. Any suggestions? Janet Dye 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
