Original message
>Date: Thu, 18 Nov 2004 18:06:19 -0700
>From: Dan Jones <[EMAIL PROTECTED]>
>Subject: MQSeries triggering on z/OS
>To: [EMAIL PROTECTED]
>
[snip]
>
> I've looked through MQSeries manuals, tech searches,
> red books, etc, and can't seem to find any technical
> relief
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
Janet,
we do batch triggering on depth and first. depends on the applications
need.
Instead of triggering the batch jobs directly, we trigger a scheduler
utility job. The utility job is pretty simple, and I've not seen it abend
once we have deployed it for each queue. Since the scheduler kn
They
want to schedule it to run every hourso I assume some hours it will run and
find nothing (that was a waste), and other hours you will be watching the queue
depth climb and climb, gritting your teeth, beads of sweat forming on your
forward, w-i-s-h-i-n-g the clock on the wall to hurry up
Title: Message
For
queue depth I was planning on having a batch job in their job stream run that
issues the 'ALTER' command to set the trigger back on. This would be a
step that ran only if the job to read the queue was successful. If
they have an abend, they can fix there problem and run
Chris,
We're using Veritas Volume Replicator (VVR)
and we're replicating the Oracle database as well.
Regards,
Kulbir.
"Christopher Warneke" <[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[EMAIL PROTECTED]>
18-Nov-2004 15:57
Please respond to "MQSeries List"
<[EMAIL PROTECTED]>
Build a 2nd qmgr, tune it for the batch processing,
route the messages to it from the 1st.
The isolation will make it easier to tune both
logging and psid storage requirements. You've got
plenty of bufferpools, psids if you're at v5.3.
Maybe even route the batch directly to a dedicated
qmgr.
Another problem w/ triggering on depth is,
if the job abends and the qdepth is not below the trigger depth you can not
reset the trigger.
That means you need an application
person to fix the abend and manually restart the job, and a MQ admin to
reset the trigger.
We had the same issue and decide
Bob,
You've got to fix that sticky "e" key!
We don't use ficon for the replication but use high-speed lines. Not that it
matters, but the Delaware mainframes are in Maryland.
Ò¿Ó
Bob Juch
Citigroup
MQ Mainframe Support Team
Weehawken, NJ
201-974-2147
mailto:[EMAIL PROTECTED]
-Original M
We had feeds coming in at all times delivering MT942 and MT950 SWIFT
statements. We set the queues up for triggering. We took the batch trigger
monitor and modified it to call AFOper. This gets you out of the scheduling
problem. The only issue you have there is jobs would be scheduled that are
outs
Thank you Bob.
Chris
--- "Juch, Robert" <[EMAIL PROTECTED]> wrote:
> IBM's fiber connections can now be 32 miles long.
>
> We mirror (not through ficon) our mainframes to both
> Long Island and Maryland.
>
> R?S
> Bob Juch
> Citigroup
> MQ Mainframe Support Team
> Weehawken, NJ
> 201-974-2147
>
>
I believe you also do it between Delaware, and Wehawkin, NJ. Which
makes me wonder about the 32 mile statement?? I know the replication was
there. I may be incorrect about the geog.
bobbee
From: "Juch, Robert" <[EMAIL PROTECTED
Not to get into the nuts and bolts of triggering on depth that has been
suggested by several already, it is not immediately obvious that your
programmers MUST reset the trigger on depth before terminating each time
or the trigger will turn OFF and never start your app again. This is
something smal
Janet,
The two approaches are not mutually exclusive. Go ahead and plan your disk
space for some reasonable number of messages and set trigger on depth. Then
the app will never exceed it's quota and your concerns are met. In addition
let the developer schedule the job. As long as the schedu
Janet,
If your vendor is able to have a periodic job remove messages from the queue,
then the messages do not belong in MQ but in a sequential file or a database.
I suggest you have them write a listener program that immediately removes the
messages from the queue and writes them to a file.
Ò
Janet
I have questions :-)
Are the messages timely, do they need to be proccessed when they arrive?
Do do you also update VSAM, DB2 etc you'll need RRS with Batch.
Getwait is a given in Batch or CICS..
Don't forget to issue Syncpoints(but maybe not for every message) and maybe before you
Currently, most messages received on our mainframe qmgr are destined to
CICS and are triggered 'on first' . We are in the process of putting in
a new application that will receive large volumes (50,000+) of batch
messages from a vendor. The messages will come in at different times of
the day, som
Mr. Caccavale,
I received the below email from your organization and I am concern your
company has violated the unwritten rules on the MQSeries List Server which
is a community of technical experts from vendors and corporations alike.
This is not a forum for vendors to obtain contact names for t
IBM's fiber connections can now be 32 miles long.
We mirror (not through ficon) our mainframes to both Long Island and Maryland.
Ò¿Ó
Bob Juch
Citigroup
MQ Mainframe Support Team
Weehawken, NJ
201-974-2147
mailto:[EMAIL PROTECTED]
-Original Message-
From: MQSeries List [mailto:[EMAIL PR
Kulbir,
Sounds like what you really need is a redundant DASD
solution and a DR center that is close enough to you
to mirror disks at both sites.
EMC and IBM both have technologies that support
having the data centers some distance from each other.
Shared Queues on z/OS can be 27km apart (I've
A M E N to that brother! ! !
From: Roger Lacroix <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Backing up "Q" files but not the "LOG" files
Date: Thu, 18 Nov 2004 09:27:35 -0500
Hi,
I would most definitely ask your management the following quest
I will be out of the office from 11/18/2004 until 11/19/2004.
I will respond to your message when I'll return.
For production emergencies please contact me at:
201-251-3892 - Home
347-563-1085 - Cell
For questions other than production emergencies
contact my manager Rommel Belen at 212-270-1
I will be out of the office starting 11/18/2004 and will not return until
11/19/2004.
I will be out of the office working at a customer site today, wth no access
to e-mail or voice mail. I will respond to your message tomorrow.
Instructions for managing your mailing list subscription are provid
Hi,
I would most definitely ask your management the following question (and get
their answer in writing - email):
'Would the business unit(s) be ok if during a DR the queue files became unused
(messages were lost) and ONLY the MQ objects (queues, channels, etc..) were
created on the DR box?'
Bec
I gueess it would all come down to your Business description of DR.
For some companies the are glad to be back up. In other cases they want to
be back up as near to, if not exactly, like production when they went down.
This is where a replication of the Logs and Queue Data directories are
required.
Chris,
Thanks a lot for this, it's quite useful.
We believe we're OK for a local failover, the scenario we're trying
to cater for is a computer center outage. In this scenario we want
to recover all messages using a hot DR site. The circular logs were
chosen previously to ease housekeeping and
Kulbir,
when you are using SAN you have to put queue data AND logs to SAN storage.
If you backup only the queue data you may have the problem, that the queue
manager does mot start at all!
Regards
Hubert
-Ursprüngliche Nachricht-
Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von
Thanks
Raul, that is what I was looking for. Don't know how I missed
that.
Andre
-Original Message-From: MQSeries List
[mailto:[EMAIL PROTECTED]Sent: Wednesday, November 17, 2004
11:07 PMTo: [EMAIL PROTECTED]Subject: Re: XML
CDATA
-- Insert the input message tre
28 matches
Mail list logo