Peter,
 
Elegant solutions are possible on the IMS side too.  An existing IMS queue can be reordered readily, though exit code written in assembler, C, or PL/I is sometimes required.
 
A licensed IBM program product called IMS Queue Control Facility for z/Os V1R2 would have to be available, and I don't know whether ETSD at the Hartford has it installed.
 
This product also makes ISPF-based browsing facilities for IMS queues available, and they would be helpful in sorting out what is happening on the IMS side of your application. 
 
To read about QCF you can download a copy of the IBM publication
 
IMS Queue Control Facility for z/OS User's Guide, SC26-9685-02
 
from the IBM publications website.
 
John Gilmore
SystemCraft LLC 
----- Original Message -----
From: Doug Jenkins
Sent: 05 February, 2003 14:15
To: [EMAIL PROTECTED]
Subject: Re: IMS BRIDGE Queues and MQMD-PRIORITY
 
Would adding more MPR's at 6am allow faster handing of the requests?

Doug




                    "Potkay, Peter M
                    (PLC, IT)"                  To:     [EMAIL PROTECTED]
                    <Peter.Potkay@THEHAR        cc:     (bcc: Doug Jenkins/WP/Candle)
                    TFORD.COM>                  Subject:     IMS BRIDGE Queues and MQMD-PRIORITY

                    02/05/2003 09:11 AM
                    Please respond to
                    MQSeries List






An IMS bridge queue is GET disabled from 2AM to 6AM, since the IMS Onlines
are not up and running. For these four hours, the web application is
accepting requests and sending the asynchronous messages to the Bridge
queue. The Web application knows if it is between 2 AM and 6 AM, and will
not wait for a reply but instead will put up a splash screen saying an
email
will be sent to them the next morning with their reply.


So at 6 AM, we have hundreds of request messages queued up on the bridge
queue. As soon as the IMS onlines come back up, the queue is enabled and
the
messages flow into the OTMA. However, all these hundreds of messages take
some time to process. If a user at the web front end sends in a request at
6:01 AM, they will wait for a reply, since the onlines are now up. But
their
request is now stuck behind all the previous night's messages.

How do I insure that the messages sent after 6 AM get prioritized to be
processed before the previous night's messages? I would like to avoid
creating a separate request queue to be used by the application between 2
and 6 AM. So I thought I might have the front end app set the priority of
the messages sent outside of 2-6 AM to be higher than the ones sent between
2 and 6.

Would this work? What if the queue is enabled at 6 AM with 100 messages of
PRIORITY zero. These messages will all "instantly" flow into the IMS queue,
where they get queued up on the IMS queue, right? Does the MQMD-Priority
get
carried over and used somehow in the IMS queue as well? So that when a
PRIORITY 9 message comes in, it goes straight into the IMS queue, and then
to the head of the IMS queue? Or is it stuck at the back of the IMS queue,
because MQMD-Priority is not translated into IMS?

Or will the messages stay queued up on the MQ bridge queue when the queue
is
enabled, going into OTMA one at a time, and as such the arriving messages
will be put to the head of the MQ queue because of their priority?




Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906



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.

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

Reply via email to