| Author |
Message
|
| twhusky |
 Posted: Wed Jul 29, 2009 2:57 pm Post subject: Variation in Using MA12 Example MQ Batch Trigger |
 |
|
Newbie
Joined: 24 Jun 2009
Posts: 6
|
Hi guys...thanks for your earlier advice / help...so far so good but we still have a ways to go.
This may be a bit long but if you could bear with me...
We are ready to define our Initiation Queue, Application Queue and Process Definition and have some questions.
First let me explain what we intend to do.
A web based Java App will Put a message to the Initiation Queue with the content of our intended Application Jobname. Our Mainframe scheduler Control-M, must submit the Application Job so the Application Job cannot be submitted directly from our CKTIBAT2. Our CKTIBAT2 will submit the Control-M Event Trigger job which in turn will submit the Application Job.
We want to use a single MQ Batch Trigger Initiation Queue to invoke a single CKTIBAT2 Trigger Monitor. A DB2 table will have corresponding Application and Control-M job names so we can reuse the single configuration of the Init Q and CKTIBAT2.
In the RUNDEFS and CKTIBAT2 members of the MA12 Service Pac, the instream documentation indicates that the JCL for the intended Application Job to be submitted can be specified as message content defined in the Process Definition.
I don't think we care about that additional JCL in the Process Definition.
All we want is for the Initiation Queue to invoke our CKTIBAT2 which will be running or "waiting" in a long running JES Job i.e. RUNCKTI from MA12.
Here is what I think we need for the actual MQ definitions:
* INITIATION QUEUE
DEF QLOCAL(WGH.BATCH.INITQ) -
REPLACE
*
* APPLICATION QUEUE
DEF QLOCAL(WGH.BATCH.RQSTQ) -
TRIGGER -
TRIGTYPE(EVERY) -
INITQ(WGH.BATCH.INITQ) -
PROCESS(WGH.BATCH.PROCS) -
REPLACE
*
* PROCESS DEFINITION
DEF PROCESS(WGH.BATCH.PROCS) -
APPLICID('//BTACLIB JCLLIB ORDER=USER.JOBLIB') -
USERDATA('//S1 EXEC PROC=WGHMQBAT,Q=''!''') -
APPLTYPE('MVS') -
REPLACE
In short to reiterate:
We want to Put a message to Initiation Queue WGH.BATCH.INITQ that will invoke program WGHMQBA(CKTIBAT2) running in Job WGHMQBAT(RUNCKTI).
The message payload on WGH.BATCH.INITQ will contain an Application Jobname that WGHMQBA will use to retrieve a Control-M Jobname/Jobcard and submit a Control-M IEFBR14 Dummy Event Trigger Job.
We have successfully tested submitting the Control-M job so the only remaining piece is defining and executing the MQ Batch Trigger.
Do we have what we need or is there still something I don't understanding or something further I need to do.?
Thanks in advance for your advice and support.
tw |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jul 29, 2009 5:32 pm Post subject: Re: Variation in Using MA12 Example MQ Batch Trigger |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| twhusky wrote: |
| Do we have what we need or is there still something I don't understanding or something further I need to do.? |
Why are you writing directly to the initiation queue, and does this Java app format the trigger message correctly?
If you have a single job that's either triggered, or started by the scheduler, then why are you going through this very elaborate method?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| twhusky |
| Posted: Thu Jul 30, 2009 9:22 am Post subject: MA12 Batch Trigger Re-use Variation |
|
|
Newbie
Joined: 24 Jun 2009
Posts: 6
|
Vitor,
Thank you for your reply.
Before I answer your questions let me ask you...Have ever installed or used an MQ Batch Trigger as described in IBM's MA12 Service Pac.?
Regardless, let me try to answer your questions, to wit:
Why are you writing directly to the initiation queue, and does this Java app format the trigger message correctly?
Unless I'm mistaken, the Java App(or any other MQ Batch Trigger Put) must write to the Initiation Queue. The only other possible Queue as described in MA12 is the Application Queue. Should the Java App be putting the message to the Application Queue.?
With respect to formatting the trigger message correctly...I'm not doing the Java piece but it's my understanding that there are standard Java libraries and methods for formatting and putting MQ messages.
Regardless, we are still concerned with getting the Queues properly defined. Once we have the Queues defined, we will address how Java is formatting the trigger message.?
If you have a single job that's either triggered, or started by the scheduler, then why are you going through this very elaborate method?
Perhaps I didn't explain our requirement correctly.
Our front-end is Web/Java based while some very long running, complex calculation processes we'd like the Java App to request, run in mainframe batch jobs. Due to site mainframe security restrictions, all application jobs must be submitted through our Control-M Scheduler.
Control-M must be triggered by an event. Without boring you with details about the limitations of Control-M, let me just say we explored all other options and the MQ Batch Trigger was the best/only solution. Trust me, we would not have used the MQ Batch Trigger if we had another choice.
Thanks again for taking the time to respond.
tw |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 9:28 am Post subject: Re: MA12 Batch Trigger Re-use Variation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| twhusky wrote: |
| Have ever installed or used an MQ Batch Trigger as described in IBM's MA12 Service Pac.? |
Once at a client's insistence - I find the CICS trigger more useful.
| twhusky wrote: |
| it's my understanding that there are standard Java libraries and methods for formatting and putting MQ messages. |
There are and we'll assume a) the Java guy is using them & b) is generating the correct type of message.
| twhusky wrote: |
| Control-M must be triggered by an event. Without boring you with details about the limitations of Control-M, let me just say we explored all other options and the MQ Batch Trigger was the best/only solution. Trust me, we would not have used the MQ Batch Trigger if we had another choice. |
I've met Control-M and are aware of it's capabilties. My question is why you're trying to trigger the job (via Control-M) when you can obtain the same results more simply with a scheduled task. What, when you explored this option, put you off?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 30, 2009 9:35 am Post subject: Re: MA12 Batch Trigger Re-use Variation |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can contact the maintainer of MA12. He may help with some of your confusion.
In general with MQ Triggering (and I believe that MA12 is designed to work like regular MQ triggering), you never write to the Initiation Queue. You Put a message to the Application Queue, *and the queue manager* writes to the Initiation Queue.
Almost certainly your Java Programmer is not creating an MQTMC message that they are putting on the Initiation Queue. Almost certainly they are not creating any other MA12 special format for messages that could go on the Initiation Queue (if there are any). |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 9:48 am Post subject: Re: MA12 Batch Trigger Re-use Variation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| you never write to the Initiation Queue. You Put a message to the Application Queue, *and the queue manager* writes to the Initiation Queue. |
That's certainly my experience.
| mqjeff wrote: |
| Almost certainly your Java Programmer is not creating an MQTMC message that they are putting on the Initiation Queue. Almost certainly they are not creating any other MA12 special format for messages that could go on the Initiation Queue (if there are any). |
No, but the poster's point that the facility exists to generate such a message is valid. Not best practice certainly but certainly possible as it is in any environment.
Possibly the site security requirements that require the use of Control-M prevent the use of automatically submitted jobs, so this is being spoofed via a "manually" generated trigger message. Weird but there you have it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| twhusky |
| Posted: Thu Jul 30, 2009 10:00 am Post subject: |
|
|
Newbie
Joined: 24 Jun 2009
Posts: 6
|
To answer your last question:
...why you're trying to trigger the job (via Control-M) when you can obtain the same results more simply with a scheduled task. What, when you explored this option, put you off?
In short and as I stated previously...due to security restrictions at this site, we have to submit the application jobs via Control-M. There are several much easier, more elegant options available (CICS & IMS Transactions…DB2 Stored Procedures…) but for one reason or another, all were ruled out management.
Not sure if you get Dilbert in the UK. The premise behind the comic strip is that programmers and engineers must succeed in spite of managements worst efforts.
Debating why we have chosen the MQ Batch Trigger is a moot point.
Our management has told us the MQ Batch Trigger is our solution so that's what we're trying to do.
If you have any insight as to whether the Queue definitions I’ve proposed are correct and also, whether we can use a single Initiation Queue and interrogate the message content to trigger multiple / different Control-M jobs, I would greatly appreciate it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 10:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| twhusky wrote: |
| Not sure if you get Dilbert in the UK. |
Reading the strip is all that keeps me going. I've worked for the PHB, and on one occassion gave The Dilbert Principle to a project manager when he asked for an upward review.
| twhusky wrote: |
Debating why we have chosen the MQ Batch Trigger is a moot point.
Our management has told us the MQ Batch Trigger is our solution so that's what we're trying to do. |
Management should not impose technical solutions, but business requirements. Get them to sign off on the method, include something about "accepting the problems and limitations" in the sign off and see if their nerve holds. At least get them to justify the decision, or why the others are unacceptable.
| twhusky wrote: |
| If you have any insight as to whether the Queue definitions I’ve proposed are correct |
Yes they are, but I still think you're using them in an odd way.
| twhusky wrote: |
| whether we can use a single Initiation Queue and interrogate the message content to trigger multiple / different Control-M jobs, I would greatly appreciate it. |
Yes, but not with the support pac. The supplied trigger monitors (including MA12) do not do this. You could easily write a trigger monitor to do this, but then you've got a custom Java app writting trigger messages to be processed by a custom trigger monitor. So it becomes pointless using the trigger mechanism and you're far better off simply using a normal local queue as a mechanism.
This is why I've never had much use for batch triggers. In a mainframe environment they quickly become more trouble than they're worth.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 10:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Moved to more relevant section
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 30, 2009 11:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In general, a trigger monitor running on any platform will happily execute whatever is passed to it in an MQTMC message, with whatever authority it happens to have by virtue of the user running it. This very typically ends up being the mqm user.
It is entirely possible to write a Java app that will create an MQTMC message that will call Control-M to do whatever is needed.
Likely your security auditors won't like this approach. Because now it means that any application that can write a message to the Initiation Queue can run any job they want on the mainframe, with the full authority of the user running the MA12 Trigger Monitor.
If this is the approach you are taking, you do not need to create process definitions or any queue other than the Initiation Queue at all. |
|
| Back to top |
|
|
| twhusky |
| Posted: Thu Jul 30, 2009 12:25 pm Post subject: |
|
|
Newbie
Joined: 24 Jun 2009
Posts: 6
|
Thanks mqjeff,
I've got that clear now. Our Java App needs to write to the Application Queue. The Queue Manager will write a message to the Initiation Queue that will trigger our Batch Monitor which in turn will submit the Process Definition Proc.
I've also learned that I will need a 2nd program to be executed in the Proc identified in the Process Definition to read the Application Queue message.
This 2nd program should allow us to reuse the Initation/Application Queue & Process Definition configuration to trigger any number of Application (in our case Control-M) jobs.
Thanks again guys for your advice.
tw |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 12:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| twhusky wrote: |
| This 2nd program should allow us to reuse the Initation/Application Queue & Process Definition configuration to trigger any number of Application (in our case Control-M) jobs. |
Not unless I've misunderstood what you're planning.
Java app will write to application queue. This will result in a trigger message and the process defined to the application queue being started. This 2nd program can (and should) read the application queue and decide what Control-M job needs to be started but if this application "reuses" the application queue then you'll just go round the loop again.
And you'll need to produce some kind of mechanism to prevent the kind of job spoofing that mqjeff pointed out.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| twhusky |
| Posted: Thu Jul 30, 2009 4:02 pm Post subject: Re: MA12 Batch Trigger Re-use Variation |
|
|
Newbie
Joined: 24 Jun 2009
Posts: 6
|
[quote="mqjeff"]You can contact the maintainer of MA12. He may help with some of your confusion.
mqjeff...who might the "maintainer of MA12" be.? If that is someone at my jobsite...sadly that is probably me more than anyone else.
I'm sorry to belabor this issue but I really want to be clear on this.
The way I understand things...
There is a relationship between the Initiation Queue and the Application Queue that causes CKTIBAT2 to "Wake Up" when a message is Put to the Application Queue.
It is the MQSeries Queue Manager that Puts a message to the Initiation Queue that triggers CKTIBAT2.
CKTIBAT2, executing in log running job RUNCKTI as per the MA12 example, then submits a Job / Proc that according to MA12, is identified in the Process Definition.
This Job can execute a program that will read the message content of the Application Queue or, execute a program or process that will be the end result of the initial request. In our case, we want to read the message content on the Application Queue.
RUNCKTI contains a JOBCARD DD that CKTIBAT2 reads and then submits to the INTRDR. The MA12 version of CKTIBAT2 supplies the remaining JCL cards by getting and unstringing data from the USERDATA Parm in the Process Definition.
I created a version of CKTIBAT2 that supplies the remaining JCL cards from Working Storage. The thought here was that the type of job being submitted from CKTIBAT2 will be the same regardless of the requesting App.
Either way, whether the JCL is defined in a Process Definition or comes from a Dataset or is in Working Storage, it is all submitted from CKTIBAT2 via the INTRDR DD.
Since the Initiation Queue is known to CKTIBAT2 via the Parm supplied in the execution step of RUNCKTI, I'm wondering whether there is any need for a Process Definition at all.
Once again, please forgive me for belaboring this issue.
Someday...maybe I can be the one who is able to give the expert advice.
Thank you all again...!!!
tw |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jul 31, 2009 2:42 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| There is a relationship between the Initiation Queue and the Application Queue that causes CKTIBAT2 to "Wake Up" when a message is Put to the Application Queue. |
most likely cktibat2 uses a "get wait" on the initiation queue which is then fullfilled when MQ creates a trigger message.
| Quote: |
| It is the MQSeries Queue Manager that Puts a message to the Initiation Queue that triggers CKTIBAT2. |
yes, but in common mq language an application is being triggered, not the trigger monitor itself. it just wakes up because the get wait is fullfilled
| Quote: |
| Since the Initiation Queue is known to CKTIBAT2 via the Parm supplied in the execution step of RUNCKTI, I'm wondering whether there is any need for a Process Definition at all. |
the process definition is not used to tell cktibat2 the name of the initiationqueue. as you already wrote, the cktibat2 is a long running job that has to know the initiation queue to be able to get-wait for trigger messages.
the attributes of the process definition together with some attributes of the he local application queue that causes the trigger message to be crated are used to build the trigger message. check the proper data areas in the APR manual.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2009 6:44 am Post subject: Re: MA12 Batch Trigger Re-use Variation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| twhusky wrote: |
| mqjeff...who might the "maintainer of MA12" be.? If that is someone at my jobsite...sadly that is probably me more than anyone else. |
It's the guy who maintains MA12 - check the support pac page for details.
Aside from that, I can't describe things better than my most worthy associate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
