Title: Message
Batch trigger monitors are usually pretty low volume.  So, if you are already using CKTI it may make sense to leverage that and save the trouble and overhead of a second trigger monitor.  You have to write a little CICS program, but it's certainly no more effort than a custom trigger monitor. Here's how:
First, create a queue for batch job submission, set it to trigger on first in the CICS initq. Map a CICS transid to your program name and specify that in applicid of the process definition. For flexibility, plan on using envdata, trigdata, and/or user data for passing runtime parameters (such as waitinterval) to your program. What you then have is a "job queue monitor".    
"Job queue monitor" is a fancy name for a Service Initiation Layer (SIL) that identifies job requests on the queue and submits appropriate JCL to an internal JES reader. The interface to the JES reader is fairly trivial using  EXEC CICS SPOOLWRITE. As with any triggered program, this one needs have a loop so that it processes the job queue until empty. 
That's the basic idea--it's very simple and it works. The fun part is designing the job request message in a way that makes sense for your business.  I encourage you think beyond the task at hand and design a general solution that has some legs.   
One thing I hardly suggest is to stick with a one message per job model. Avoid the tempation to send a jobstream as a sequence of messages. If your job request is comprised of multiple jcl records, then I propose packing them all into a single message. It's far easier to unpack one message into multipe jcl records than to assemble multiple messages into one jobstream. A message format I like is to store a record delimiter in the first byte of the message and then string together the rest of the records (separated by the same delimter, of course).  Or even use XML if that tickles your fancy or otherwise gets you points. The important thing is to get the entire job request in one message.  You can even effect moderately sized file transfers over MQ this way--by packaging an IEBGENER jobstream (including data records) into one message.  
Another thing to think about is how to control what jobs can be submitted by whom.  With some designs, you run the risk that anyone who has the capability to submit one job can submit any job, which is unacceptable to many organizations. You may want, for example, to control the userid on the job card (or other parameters on the job card, for that matter) rather than allowing them to simply flow in the message content. Some organizations also insist on routing all job requests through a scheduler.  Rather than submitting a job directly, they submit a request for the scheduler to release the job.
Your idea of basing the batch job on information in the process definition is also possible.  However, you cannot have more than one process definition for the same triggered queue. That means you need a different queue for each job you want to submit.  Maybe or maybe not a good idea.  It gives you real granular securtity on who can submit what a the expense of a signicant burden on the MQ admin.  By the way, it may not be immediately obvious, but with that method  it's the contents MQ definitions, not of the message that determines which batch job to run. In fact, the message contents may be irrelevant.  Or, you may want a design that passes the message as a parameter to the batch job... See what I mean--this is the fun part!
-----Original Message-----
From: Dan Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 5:06 PM
Subject: MQSeries triggering on z/OS

Forgive me if I am beating a dead horse, however, I've been looking high and low for 'how to' information on building a triggering setup using MQSeries on mainframe systems.  Specifically, I'm looking for information on how you would trigger JES to run a batch job based on information provided in an MQSeries process definition.  

I've looked through MQSeries manuals, tech searches, red books, etc, and can't seem to find any technical relief.  I'm guessing that their must either be setup to do on JES to provide the link to MQSeries or you have to run a custom trigger monitor program that is able to submit jobs through JES.  

Any words of wisdom are greatly appreciated.

Thanks in advance,

Daniel G. Jones

IBM Global Services
Strategic Middleware Services

Reply via email to