| Author |
Message
|
| cheerfulsri |
 Posted: Tue Aug 22, 2006 9:11 pm Post subject: Need help(For doing workload Balancing in Z/OS) |
 |
|
Novice
Joined: 22 Mar 2006
Posts: 13
Location: Chennai,India
|
Hi all,
I am very much new to this field.I m working on a project which involves workload balancing.
Please find time to go through the details below and suggest me acordingly:-
------------------------------------------------------------------------------------
Iam working on [b]WMQ V5.3[/b] under the platform [b]Z/OS V1.6[/b].
Requiement:
I have a local queue whose remote queue resides on UNIX Box which would receive message from front-end online applications.
After messages reach the Mainframe local queue,which is a trigger first queue - will trigger a transaction.
Now the exact scenario is as the frequency of messages coming from front end is very high,I thought of having two draining procesess.
But I need Trigger First only-So what I m planning to do is to define the same transaction in two different CICS regions -both of these cics regions would be connected to the same M/F Queue Manager.
Let us say as queue name : XXXX.XXXX
QMGR name: MQD1
Initiation Queue : MQD1.XXXX.INITQ
CICS Regions : CICSTSD1
CICSTSD2
Process Name : XXXX.TRAN
(Note that the TRAN is the transaction name - PCT's of both regions have this transaction defined)
(I will add the initiation queue MQD1.XXXX.INITQ to the trigger monitor CKTI of both CICS regions)
So the scenario would be both CKTI's would be monitoring the same Initiation queue & compete for the same-whichever succeds will trigger the TRAN in the corresponding region.
-----------------------------------------------------------------------------------
So when one cicsregion is down it can execute through other region.This is my plan.
Please advise whether it will work
Expecting many replies from experts
Thanks,
Sri [/b] |
|
| Back to top |
|
 |
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 10:42 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
I would guess, that CKTI opens the init q exclusively, but even when not, only one CKTI would receive the trigger message and start the app.
You have to define a master app, which is triggered and starts two (or even more) instances of the working app.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| cheerfulsri |
| Posted: Wed Aug 23, 2006 12:38 am Post subject: |
|
|
Novice
Joined: 22 Mar 2006
Posts: 13
Location: Chennai,India
|
Yes you are absolutely right.But I need to know which CKTI would have preference to read that trigger mesage & how can we find out?
The problem we are facing is only CKTI from CICSTSD1 always read that message .I stopped that CKTI to check whether the other CKTI would read that message-But in this case the Trigger message is not generated..
Please advise |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Aug 23, 2006 12:58 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
First of all, only one CKTI can have the initiation queue open, you can write your own trigger monitor.. I would let one CKTI do the job and include some dispatching code in the application.
So when you stop the one on CICSTSD1, this tell MQ that there are noone listing to the init.queue. Result no trigger message generated..
Next have a look in the application programming guide, on how trigger first works and when you will have trigger events generated... This is not trivial.. 
To do the workload balancing in your way what you could do is having your first stated program starting one or more helpers (just by issueing EXEC CICS START TRANS(...) etc. ) and route this to the wanted CICS region.
It's not nice, flexible, cute, but it can work. And it's a KISS solution.
I hope it can help you.
-- Lock it or Lose it -- 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 23, 2006 1:23 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| oz1ccg wrote: |
First of all, only one CKTI can have the initiation queue open, you can write your own trigger monitor.. I would let one CKTI do the job and include some dispatching code in the application.
|
There is no reason why you can't have more than one CKTI monitoring the same initiation queue. You just need to change the queues default open options to SHARE. However the trigger monitors will race to pick up the trigger message and the application will only be started on one CICS region.
Vicente Suarez has written a paper with sample code that describes how to monitor queue depth and start multiple application instances when needed to keep up with workload. See http://www.ibm.com/developerworks/websphere/library/techarticles/0511_suarez/0511_suarez.html
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Aug 23, 2006 1:28 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| bob_buxton wrote: |
| ... There is no reason why you can't have more than one CKTI monitoring the same initiation queue. You just need to change the queues default open options to SHARE. However the trigger monitors will race to pick up the trigger message and the application will only be started on one CICS region... |
I saw a similar situation on Unix. Two trigger monitors were started an both of them get half of the trigger messages.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 23, 2006 2:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Depending on your needs and if you could handle the workload in one CICS region you could implement following:
- TClass the CICS transaction. This means you are limiting the system resources to allow only X instances of the transaction to run concurrently.
- switch the trigger to every but don't change any of the program logic (logic still needs to be as if trigger first).
- on arrival of messages watch up to X instances of the transaction processing the queue
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Aug 23, 2006 3:40 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
fjb_saper wrote:
| Quote: |
TClass the CICS transaction. This means you are limiting the system resources to allow only X instances of the transaction to run concurrently.
switch the trigger to every but don't change any of the program logic (logic still needs to be as if trigger first).
on arrival of messages watch up to X instances of the transaction processing the queue
|
True, but not enought!
When using TCLASS and MAXACTIVE it's time to consider what to do with the "waiting" tasks....
To prevent flooding the "CICS input" queue with waiting transaction you should take a look on the Purgethresh() parameter.
-- lock it or Lose it --
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 23, 2006 4:23 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| fjb_saper wrote: |
Depending on your needs and if you could handle the workload in one CICS region you could implement following:
- TClass the CICS transaction. This means you are limiting the system resources to allow only X instances of the transaction to run concurrently.
- switch the trigger to every but don't change any of the program logic (logic still needs to be as if trigger first).
- on arrival of messages watch up to X instances of the transaction processing the queue
Enjoy |
With multiple CKTI monitoring the Initq and Jorgen's Purgethresh() suggestion this would also work to distribute work across multiple CICS regions and doesn't require any application change.
However this scheme does have heavy overheads:
- Queue manager has to generate a trigger message for every input message.
- Trigger monitor(s) have to read every trigger message and start a transcation
- CICS throws most of these transactions away!
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 23, 2006 4:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bob_buxton wrote: |
| - Queue manager has to generate a trigger message for every input message. |
I don't know about CICS or z/OS, but the distributed queue managers don't guarantee that there will be a 1-1 between input and initiation messages. There are cases where init msgs will be ignored.
It's why trigger on EVERY is not best practice.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Aug 23, 2006 7:53 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
| bob_buxton wrote: |
| - Queue manager has to generate a trigger message for every input message. |
I don't know about CICS or z/OS, but the distributed queue managers don't guarantee that there will be a 1-1 between input and initiation messages. There are cases where init msgs will be ignored.
It's why trigger on EVERY is not best practice. |
Another problem could be, that many input messages would cause many trigger messages. When the initq becomes full, further trigger messages would be put to the DLQ  .
_________________
Regards
Hubert |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Aug 23, 2006 7:55 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
I can only agree to the performance issue..
What could be done is extend:
Extened it to use the TRIGDATA() for controlling the trans action to start, check interval ,aggresivity, and max transaction to run.
| Code: |
| ALTER QL(XXXX.XXXX)... TRIGDATA('TR=ABCD,MAX=25,AG=2,RESCAN=10SEC') |
That could be an "extened WebSphere MQ CICS trigger monitor" feature  The only performace reduction in QCTL is MQINQ, but I'm shure that the benefit is higher than the loss when you need the parallel execution.
-- Link it or Lose it --
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| cheerfulsri |
| Posted: Wed Aug 23, 2006 9:03 pm Post subject: |
|
|
Novice
Joined: 22 Mar 2006
Posts: 13
Location: Chennai,India
|
Hi Jørgen,
Could you please explain a little further about the parameters used in trigger data(or send some liks for that) so that it will be useful for us?
Thanks,
Sri |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Aug 23, 2006 11:19 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
I would change Vicentes implementation so it would becom a generic solution. I expect you have read the description. A pattern for implementing the WebSphere MQ CICS Adapter
The description and supplied source describe how to manage a automatic balancing solution.
| Quote: |
It is the Controller that optimizes the use of CICS resources and maximizes the number of MQ messages that are processed in parallel. The following parameters are used in the scheduling logic that decides the number of Message Handler transactions that should be started to process the volume of messages arriving on the application queues. These values are hard coded in the MQCTLR program (they can be passed as user data in the trigger message or from some common storage in CICS):
Number of input handles on the application queue (IPPROCS)
Indicates how many processes are accessing the application queue for input. This is used to determine how many Message Handler tasks are active.
Queue depth (CURDEPTH)
Number of messages that are on the application queue waiting to be processed. This is used as an indication of the message load.
MAX-HANDLES
Maximum number of active Message Handlers that are allowed (high load condition). This value should include MIN-HANDLES.
MIN-HANDLES
Number of expected non-Message Handler processes that can have the application queue open for input. The Controller must be counted as one of these processes.
MAX-DEPTH
Number of messages on queue that would trigger the Controller to start a new Message Handler task.
MAX-RETRIES
Number of consecutive times that the Controller finds the queue empty before terminating. The triggering mechanism starts the Controller again when messages start arriving on the queue.
|
My impl. could look like this:
TRIGDATA('TR=ABCD,MAX=25,AG=2,RESCAN=10SEC')
where TR= is the transaction to start,
MAX= is max handles. (I would calculate both MIN and the real max-handles internally).
AG= is my way of controlling max-depth. Simple way is just to use MAX-DEPTH. There are more algorithms for controlling this.
RESCAN= is the time EXEC CICS DELAY waits.
I hope it helps.
-- Lock it or Lose it --
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
