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!
regards,
Dennis
-----Original Message-----
From: Dan Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 5:06 PM
To: [EMAIL PROTECTED]
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
