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 tree as
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
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
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
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?'
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
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
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 question
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
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
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
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,
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
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,
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
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
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]
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
mailto:[EMAIL
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
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
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 decided
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
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]
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
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
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
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
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. I'm
28 matches
Mail list logo
