Re: Queue Managers on zOS and duplexing of MQ datasets

[Jim Nuckolls]

All of the accounts I have been involved with still use the
dual-write attributes. I have seen Shark's crash so I wouldn't
bet my shop and installation on that one.
Cheers...
Jim Nuckolls
Donald Blake wrote:
Currently, we're running duplexed BSDS's, Active Logs and Archive logs.
The dasd behind that is IBM Shark. Considering the error correction and
duplexing inside the DASD array, I'm considering going to a single BSDS,
Active and Archive logs. How many running queue managers on the
mainframe are still using duplexing on their MQSeries datasets on zOS?
If you are, what is your rationale for doing so?
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ RC '2080' and '2010'

[Jim Nuckolls]

When you define a channel and take the default it is 4,194,304.
That is true for both sender and receiver. However, you can
override that and go up to the maximum message size specified for
the Queue Manager. If the 2 sides of the channel are not the same
then the smaller number is taken.
Cheers...
Jim Nuckolls
Tony.Allison wrote:
Good morning,
The maximum message length across a channel is still 4MB. If you want to
send a larger message you must use segmentation (break your message into
segments).  This is done within your application code setting the
message grouping and segmentation allowed.
Hope this helps
Tony Allison
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Fleck
Sent: Friday, October 15, 2004 7:42 AM
To: [EMAIL PROTECTED]
Subject: MQ RC '2080' and '2010'
Hi list members,
I've a problem with MQ 5.3 CSD 4 on a Windows 2000 Server.
I've defined a Maximum Message Length of 100 MB on the Queue Manager,
the channels and the queues. Although the client gets an error '2010',
if the message is longer than 10 MB.
Another client wants to get the message out of this queue. This client
gets a RC '2080'. This also happens, if the message 6 MB. 4MB seems to
work.
Any ideas?
Thanks in advance
Michael Fleck
Landschaftsverband Rheinland
InfoKom
email: [EMAIL PROTECTED]
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Cluster Question

[Jim Nuckolls]

Dave,
If CICS transactions are putting to a queue that is a cluster
queue and local copies are hosted on multiple Qmgr's, you may
want to consider whether or not there is a need to set the
"Bind-on-Open" option when you open the queue. That is entirely
application dependent. If all the messages put by that particular
instance of the transaction need to go to the same instance of
the cluster queue then you will need to set that option. If the
transactions are just doing gets, then it will require no change.
Cheers...
Jim Nuckolls
Williams, Dave (Systems Management) wrote:
I asked this the other day, but saw no response - Thought I'd try again.
thanks.
We have a CICS region connected to Queue Manager QM1. We decided to add
QM1 to a cluster. Do we have to change anything in MQ API statements in
application code running in our CICS region?
And although I don't there to believe to be one - is there a limit to
the # of QMGRs you can create on an NT/Win2000 box?
Thanks,
Dave
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: QSTATUS

[Jim Nuckolls]

I think you want to use the TYPE(HANDLE) instead of TYPE(QUEUE).
Cheers...
Jim Nuckolls
Robert Broderick wrote:
Tried "DIS QSTATUS(QUEUE) TYPE(QUEUE) PID" against a queue that had in and
out counts against it. Display showed no PID's. What gives?? I
was trying to find the PIDs on the UNIX box that had the queu open.
  bobbee
_
MSN Toolbar provides one-click access to Hotmail from any Web page   FREE
download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Debugging Help on OS/390 Needed

[Jim Nuckolls]

I am afraid that it is not a DB2 problem. It is a problem with a
developer not understanding the concepts and rules governing a
logical unit of work in a CICS transaction.
Cheers...
Jim Nuckolls
Jim Ford wrote:
I posted a question to the list last week about help in debugging a CICS
app that's having problems. More than anything else, I was venting my
spleen. But since I posted it, I thought I'd post the cause of the problem,
now that I've found it.
The top level program in the problem transaction inserted some data into
DB2. Down in the fourth layer of called programs, a subroutine put a
message on a queue and waited for a response. The program that got the
message off the queue, in some circumstances, needed access to the data
inserted by the first program in the transaction. But that data wasn't
committed, so the two programs could be stuck in a deadlock.
Eventually the program waiting for a response would get a 2033, and abort.
At that point the getting program would get access to the DB2 data it
needed and faithfully send the reply (the reply that no one wanted any
more). The other issue was that while this was going on, more responsible
messages were backing up in the queue, leading to the general feeling of
slowness in the application.
So now the developers responsible for this mess are saying "it's a DB2
problem." But I'm not a DBA, so it's not my problem any more. In the
meantime, I'm keeping several of those "getting" transactions running so
that if one message gets stuck it won't jam up everything.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: amqcrsta processes

[Jim Nuckolls]

I am going to make an assumption that you are running on HP-UX.
We experienced the problem as well on MQ 5.2.6 and found that it
was a known problem at the time. I believe it was fixed in CSD8
and is also fixed in MQ V5.3.
Cheers...
Jim Nuckolls
W Samuel wrote:
Hi everyone,
On our Unix system, we have 5 active queue managers
We've reached a state where none of these queue are
responding anymore
I've noticed that there are around 200 amqcrsta
processes. I know that amqcrsta is related to channels
but cant understand why so many processes are running
Any idea how come so many amqcrsta processes are
running and how can this be controlled/tuned ?
Thanks,
WS


___ALL-NEW Yahoo! Messenger - 
so many all-new ways to express yourself http://uk.messenger.yahoo.com
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ trigger at EVERY

[Jim Nuckolls]

The real problem with TRIGGER=EVERY is when a transaction gets a
message under syncpoint and either abends or explicitly does a
syncpoint rollback, the trigger message that launched that
particular instance of the transaction is gone. If your
transaction is designed to read only 1 message that could leave
orphaned messages. If your transaction has been designed to read
messages until it receives a 2033 reason code it will alleviate
the above mentioned condition, however, you will have a number of
transactions that are started receive an immediate 2033 (i.e. -
they have been started but perform no useful work).
P.S. - If any of the old crew that worked at ACSC from 1970 to
1980 are still there tell them I send my greetings. I helped Tom
McKernan out with Asembler Language coding when he was on the
Insurance Team.
Cheers...
Jim Nuckolls
Wang.James wrote:
Are there anyone using TRIGGER=EVERY for MQ to trigger CICS transactions?
Years back, we were told that TRIGGER=EVERY can introduce problems to
the application therefore, we only use TRIGGER=FIRST and have the
triggered CICS transaction behaves like a driver which get a message and
spins out a secondary transaction to process that message. The driver
transaction will do this until the queue is empty.
James Wang
ESD - Technical Services
Automobile Club of Southern California
( (714) 850-2851
. [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Availability of BlockIP2 ?

[Jim Nuckolls]

Is the BlockIP2 exit code ready for prime time as yet? I
have an upcoming need for IP address filtering and would
sure like to use the latest code if it is ready.
Cheers...
Jim Nuckolls
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ and TXSeries....

[Jim Nuckolls]

We ran TxSeries and MQ at a prior customer of mine, however,
without the XA interface. We of course had no problems as
far as performance was concerned, even with DCE and a PPC
Gateway for SNA LU6.2 connections in the mix. As is always
the case, some questionable coding in the applications
caused intermittent problems. The biggest problems came from
locks being held in the Sybase database server which could
be traced most of the time back to the application. This was
v4.2, prior to the workload manager being a part of the
product. I thought the product performed extremely well.
Charles Schwab is a heavy TxSeries user as well and runs
about a 6,000 transactions per second aggregate rate across
their complex of TxSeries regions. Not bad in my book.
Cheers...
Jim Nuckolls
Capodicci, Dan (GE Commercial Finance) wrote:
Hi All
Onto a "fun" new projectI am trying to configure CICS in TXSeries to use MQ. I 
have written small C and Cobol programs to test and they run but abnormally slowseveral 
minutes to complete. I put some displays in and could see the time was being spent in connecting 
to the qmanager so I removed the XA switch file from the region and they run normally, sub 
second as expected. I built the switch file according to the TXSeries CICS Admin docs and what 
is strange is that when the region starts up, I can see in the console output that the XA 
connections are established without any errors or warnings. Obviously, the problem must be in 
the switch file but was wondering if anyone is doing this and whether they came up with any 
similar problems and what they did to correct.
Also, as a general question, I was wondering how many people are using TXSeries and 
MQ?!? Even if you haven't had this problem, would appreciate to hear your thoughts 
about this.
Thanks
Dan
Dan Capodicci
GE Corporation
Vendor Financial Services
10 Riverview Drive, Danbury, CT. 06810
Tel: 203-749-6516, DC: 8*662-6516
[EMAIL PROTECTED]
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

WMQ z/OS 5.3.1 & Shared Queues Question

[Jim Nuckolls]

We just implemented shared queuing in the development system
at my customer and the DB2 folks noticed what they
determined was a "significant" (technical term) increase in
thread activity on the DB2 subsystem. Would anyone that has
gone before me know what kind of DB2 thread activity I
should anticipate in the shared queuing environment?
BTW, they are running DB2 V7.

Cheers...
Jim Nuckolls
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Channel Connection name resolution

[Jim Nuckolls]

WE had the same problem some time back and found that MQ was caching the
IP address. If I remember correctly, we recycled the channel initiator
and the address was resolved correctly.
Cheers...
Jim Nuckolls
Adiraju, Rao wrote:

Hi Neil

If my understanding goes TTL is applicable at global level and not at MQ
manager level. As I mentioned in my original mail, when I look at the DNS
resolution at SOLARIS level it is pointing to the latest IP address which
confirms the TTL value is small and DNS alteration has been detected by the
Solaris box. But some how, MQ still holds the old IP address. Even after
STOP and START the channels, it is still trying to establish the connection
with the OLD address (I can see this in MQ Error logs). Hence the question.
Correct me if there is a parameter specific to MQ.

Cheers

Rao

-Original Message-
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: 19 April 2004 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Channel Connection name resolution
Hi Rao,

your initial problem description looks more like a DNS resolver problem than
an MQ problem.
Check with your network support people to find out what is the TTL (Time To
Live) value for the specific DNS entry you are using. Default values for DNS
can be several hours. Application programs which use DNS and the libraries
which interface to DNS can cache the results for as long as the TTL value.
If you want to be able to fail over to an alternate site using DNS
alteration, then you need to set the TTL for that name to a small value (say
5 minutes).
Regards,

Neil Casey
National Australia Bank
Southern Star Technology
WebSphere MQ Support
1/122 Lewis Rd Wantirna South
office. +61 3 9886 2375 (x82375)
mobile. +61 414 615 334


  "Adiraju, Rao"
  <[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  .CO.NZ>  cc:
  Sent by: MQSeriesSubject:  Re: Channel
Connection name resolution
  List
  <[EMAIL PROTECTED]
  n.AC.AT>
  19/04/2004 09:16
  Please respond to
  MQSeries List




Chris

Call me "Rao".

The spoke is on Windows machine with MQ V5.3 CSD06. And I can't locate any
"adoptmca" parameter on that platform. There is one for Z/OS but not for
windows.
I don't want to DELETE and re-DEFINE channels either because then channel
sequence numbers will be out of whack.
Cheers

Rao

-Original Message-
From: Christopher Warneke [mailto:[EMAIL PROTECTED]
Sent: 19 April 2004 10:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Channel Connection name resolution
Adiraju,
What kind of machine is at the other end of the channel?  Could this be an
adoptmca issue?  Why not have a "failover" script cycle the channel when it
fails?  It could interogate the primary ip and secondary ip when the channel
has a retry event trigger it.  Then make a failover or alert you to a bad
channel.  Do you have any monitoring on your system?
Just some thoughts,
Chris
--- "Adiraju, Rao" <[EMAIL PROTECTED]> wrote:

Fellows

Last night I was testing our Disaster Recovery strategy for MQ and
stuck with a problem and need (as well as appreciate) some help from
the forum:
Situation:

I have a MQ hub running on Solaris with MQ version
5.3 CSD04. It is talking
to a spoke using SDR and RQSTR pair of channels. The connection name
for these channels are defined with a sudo(alias) DNS entry to
facilitate Disaster Recovery switch for the spoke box (I am not
talking of DR switch for HUB).
Eg: Spoke-live box tcp-ip address is - 100.20.20.200
 spoke disaster box tcp-ip address is - 100.20.35.350
 Created a DNS entry called "Spoke1.co.nz" and put this name in
connection name field for both the above channels.
Initially the DNS entry "Spoke1.co.nz" is directed to 100.20.20.200.

Every thing was working OK and then we brought down the first box and
restarted the second box (with the same Queue Manager name with disk
mirroring etc..).Also changed the DNS entry to
point to 100.20.35.350.
When I go to Nslookup on Solaris box, it shows correctly the changed
the TCP-IP address for this "Spoke1.co.nz".
Initially the channels on the HUB was in "retrying"
state which I stopped
and started again. But somehow, MQ is still trying to resolve with old
TCP-IP address, as if something is cashed.  I failed to refresh this
cashing and couldn't able to redirect my channels to connect to new
box.
Being a production system, I have to bring it back quickly and hence
temporarily changed the channel definitions to physical address
"100.20.35.350" (no more DNS alias) and then restarted the channels,
MQ is happy.
Is there something I need to do, to force the Queue Manager to
recognise the new TCP-IP address.  Restarting the queue manager is not
a 

Re: MQ Triggering in CICS

[Jim Nuckolls]

Oops,

Should have been "EXEC CICS ASSIGN STARTCODE"

Cheers...
Jim Nuckolls
Jim Nuckolls wrote:

Use the "EXEC CICS STARTCODE" command. If you were triggered, you will
be started-with-data (which is the trigger message in temp storage.
Cheers...
Jim Nuckolls
Dawson, John wrote:

Folks,

In a CICS program, how can I tell that the CICS program was started
from a
MQ trigger?
Thanks,

John Dawson

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ Triggering in CICS

[Jim Nuckolls]

Use the "EXEC CICS STARTCODE" command. If you were
triggered, you will be started-with-data (which is the
trigger message in temp storage.
Cheers...
Jim Nuckolls
Dawson, John wrote:
Folks,

In a CICS program, how can I tell that the CICS program was started from a
MQ trigger?
Thanks,

John Dawson

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Two Wolves

[Jim Nuckolls]

Sorry about the slip up in addressing that one, however, not
a bad commentary on human nature was it?
Cheers...
Jim Nuckolls
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

[Fwd: TWO WOLVES INSIDE]

[Jim Nuckolls]

 Original Message 
Subject:TWO WOLVES INSIDE
Date:   Mon, 16 Feb 2004 07:27:55 -0700
From:   Dana Miller <[EMAIL PROTECTED]>
To: Battias, Christopher J <[EMAIL PROTECTED]>, beverlybland
<[EMAIL PROTECTED]>, Bobby Walton
<[EMAIL PROTECTED]>, ceverroad
<[EMAIL PROTECTED]>, Chyreese Ductan
<[EMAIL PROTECTED]>, Dale
Sigfusson <[EMAIL PROTECTED]>, Danielle Elliott
<[EMAIL PROTECTED]>, Desmond
Hinton <[EMAIL PROTECTED]>, Donna Inkster
<[EMAIL PROTECTED]>,
Doris Walton <[EMAIL PROTECTED]>, Faithann
<[EMAIL PROTECTED]>, Fernando
Archer <[EMAIL PROTECTED]>, James Carter
<[EMAIL PROTECTED]>, Jackie Lindsey-Pittman
<[EMAIL PROTECTED]>,
Jay Cox <[EMAIL PROTECTED]>, Jan Elliott
<[EMAIL PROTECTED]>, Jeff
Miller <[EMAIL PROTECTED]>, Jim Nuckolls
<[EMAIL PROTECTED]>,
Jimmy Elliott <[EMAIL PROTECTED]>, Joe Mejia
<[EMAIL PROTECTED]>, Jojo
Gallegos <[EMAIL PROTECTED]>, Jonathan Bauman
<[EMAIL PROTECTED]>, Judy Calhoun Miiller
<[EMAIL PROTECTED]>, Mark Richards
<[EMAIL PROTECTED]>,
Mike Burns <[EMAIL PROTECTED]>, Mike Wall
<[EMAIL PROTECTED]>, Milton D Rosenberger
<[EMAIL PROTECTED]>, Mom &
Clark Griffith <[EMAIL PROTECTED]>, Olaf Muller
<[EMAIL PROTECTED]>, Orlando Archer
<[EMAIL PROTECTED]>, pdavis
<[EMAIL PROTECTED]>, Ralph and Marilyn Siegel
<[EMAIL PROTECTED]>, Rebecca Carr
<[EMAIL PROTECTED]>, Scott &
Stacey Lindsay <[EMAIL PROTECTED]>, Scotty Walford
<[EMAIL PROTECTED]>,
Tim Hodnett <[EMAIL PROTECTED]>, Tim Scott <[EMAIL PROTECTED]>,
Tonia Banks
<[EMAIL PROTECTED]>, Victor Moore <[EMAIL PROTECTED]>




Subject: Received this from a sister in La Pine, Oregon, and
thought it
was good
TWO WOLVES

An elderly Choctaw Native American was teaching his
grandchildren about
life. He said to them, "A fight is going on inside me...it
is a terrible
fight, and it is between two wolves.
One wolf represents fear, anger, envy, sorrow, regret,
greed, arrogance,
self-pity, guilt, resentment, inferiority, lies, false
pride, superiority,
and ego.
The other stands for joy, peace, love, hope, sharing,
serenity, humility,
kindness, benevolence, friendship, empathy, generosity,
truth, compassion,
and faith.
This same fight is going on inside you, and inside every
other person, too."
They thought about it for a minute and then one child asked his
grandfather, "Which wolf will win?"
The old Choctaw simply replied..."The one you feed."
--


Richard, Vicki and Chance


Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online
<http://us.rd.yahoo.com/evt=22055/*http://taxes.yahoo.com/filinghtml>
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: AMQ6150 MQSeries semaphore is busy

[Jim Nuckolls]

It is possible that your system is running on the edge as far as
resources (in this case semaphores) are concerned. You might want to
start  gathering statistics as far as resource usage is concerned and
begin to make a case for regen'ing the kernel and increasing your
systems resources (shared memory segments, semaphores, etc.). When you
upgrade to MQ 5.3 it will most likely exacerbate the situation since it
uses more resources.
Cheers...
Jim Nuckolls
Karthikeyan, T. (Karthikeyan) wrote:

Hi all,
On HP-UX  MQ 5.2,
I'm getting the following error. Please explain this error message and give
the solution.
AMQ6150: MQSeries semaphore is busy.
EXPLANATION: MQSeries was unable to acquire a semaphore within the normal
timeout period of 0 minutes.
ACTION: MQSeries will continue to wait for access. If the situation does not
resolve itself and you suspect that your system is locked then investigate
the process which owns the semaphore. The PID of this process will be
documented in the accompanying FFST.
thanks
karthik


**
PLEASE NOTE: The above email address has recently changed from a previous naming 
standard -- if this does not match your records, please update them to use this new 
name in future email addressed to this individual.
This message and any attachments are intended for the
individual or entity named above. If you are not the intended
recipient, please do not forward, copy, print, use or disclose this
communication to others; also please notify the sender by
replying to this message, and then delete it from your system.
The Timken Company
**
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: What's the best of way of renaming QMGR and Queues

[Jim Nuckolls]

Hi Adi,

Haven't talked to you in a while. Not at AmEx anymore I see.

I agree with Yvette. Back things up, change the names in
your definitions, create a new Qmgr, then create the new
objects with the changed "saveqmgr" output. If the Qmgr is
in a cluster then we have a different scenario (one that's
very ugly).
Cheers...
Jim Nuckolls
Carroll, Y. (Yvette) wrote:
Hi Rao
As far as I know, deleting and recreating, or using alias queues, are
your only two options in this case.
Do a define like to create a queue with the correct name and delete the
old queue.  Of, especially if you need to
change the name of the queue manager you're also going to have to delete
and recreate it.
I'd suggest backing up all your definitions, altering the names within
your backup file, then creating a new one
using the correct name and your backed up definitions.  Then migrate
your apps over and right at the end,
delete the original queue manager.
Use supportpacs MS03 and MS70 to do your backups on the distributed
platforms.
Kind regards
Yvette
-Original Message-
From: Adiraju, Rao [mailto:[EMAIL PROTECTED]
Sent: 15 January 2004 04:24
To: [EMAIL PROTECTED]
Subject: What's the best of way of renaming QMGR and Queues
Fellows

We are trying to bring in "unified" naming standards across all our
MQ network spanning - NT, UNIX and Z/OS platforms.
Currently we have quite a few QMGRs and Queues in production and I
am wondering what the best way (least risky way) of changing the
object names to new standards.
Deleting and re-creating objects is not a preferred option. We can
define Alias queues with the new naming standards but my question is
how do we get rid of old names down the line.
Any experiences / advises are welcome.

Thanks in advance

Rao Adiraju
MQSeries Consultant
The National Bank of NZ Ltd.
Tel:  +64-4-494 4299
Fax: +64-4-802 8509
Mbl: +64-211-216-116


This communication is confidential and may contain privileged
material.  If you are not the intended recipient you must not use,
disclose, copy or retain it.  If you have received it in error
please immediately notify me by return email and delete the emails.
Thank you.


This email and any accompanying attachments may contain confidential and
proprietary information.  This information is private and protected by
law and, accordingly, if you are not the intended recipient, you are
requested to delete this entire communication immediately and are
notified that any disclosure, copying or distribution of or taking any
action based on this information is prohibited.
Emails cannot be guaranteed to be secure or free of errors or viruses.
The sender does not accept any liability or responsibility for any
interception, corruption, destruction, loss, late arrival or
incompleteness of or tampering or interference with any of the
information contained in this email or for its incorrect delivery or
non-delivery for whatsoever reason or for its effect on any electronic
device of the recipient.
If verification of this email or any attachment is required, please
request a hard-copy version.


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Should we use large messages (up to 80MB) or segmented messages?

[Jim Nuckolls]

Also, remember that your application logic will need to
change somewhat as far as options are concerned when dealing
with segments (MQGMO_COMPLETE_MSG or MQGMO_LOGICAL_ORDER if
you want to process segments individually and in order).
Also since they are non-persistent, what do you do if a
segment in a logical message is discarded, etc.
Cheers...
Jim Nuckolls
David C. Partridge wrote:
Seriously consider sending those large messages (if you do choose to use big
messages)
over a different channel from the normal traffic.
Note that 80MB messages will have a pretty substantial (read massive) impact
on the
number of concurrent channels you can support (esp. on MVS).
David

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ IMS Bridge question

[Jim Nuckolls]

Peter,

Do you absolutely have to connect to the Qmgr that owns the
IMS Bridge queue? Can you connect to a different Qmgr and
allow distributed queuing to route the message to the Qmgr
that owns the IMS Bridge queue? That way the MCA will
convert the MQMD and MQIIH header (be sure the header and
msg data use the same code page).
Moir, Peter wrote:
Hi,

Just having a play with this for the first time from the MQ side.

I have a simple client app running on Windows that connects to a z/OS
queue manager which owns the bridge queue.
If I create & send a message in MQFMT_IMS_VAR_STRING format I believe I
do not need an IIH and ASCII/EBCDIC conversion will take place happily
assuming I have everything else correct. True ?
If I create & send a message in MQFMT_IMS format and provide a IIH then
how does the conversion happen as the manual states it doesn't. There
are CCSID & Encoding fields in the IIH but the manual states these are
of no use (!). Do I need to use a data conversion exit if I want to use
MQFMT_IMS ?
Any assistance much appreciated and a merry Christmas to you all!

Thanks,
Pete




Notice to recipient:
The information in this internet e-mail and any attachments is
confidential and may be privileged. It is intended solely for the
addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to
be taken in reliance on it, is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in
this internet e-mail are subject to the terms and conditions expressed
in any applicable governing terms of business or client engagement
letter issued by the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of
America Futures Incorporated are regulated by the Financial Services
Authority.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: PipeLineLength=2

[Jim Nuckolls]

What I would probably do is take a channel and set the
BATCHSZ to something small ( 2? ) and then use MA01 (q),
with no pausing between messages, and just begin pounding
the transmit queue and channel. That way you are certain to
drive both threads of the channel. Then just watch for any
error messages in the AMQERR logs (both /var/mqm/errors and
/var/mqm/qmgrs//errors. Kinda' crude, but in this
case "no news is good news" since the only time you see any
messages is when something goes wrong.
Cheers...
Jim Nuckolls
McCarty, Brian wrote:
Thanks Jim.  Do you know anyway to tell if the parameter is actually taking effect?  Should there be a message in the error logs or something?  We have changed it on several servers (sender and receiver sides), but I can't yet tell if it is actually doing anything.

Thanks again,

B

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Jim
Nuckolls
Sent: Monday, November 17, 2003 8:42 PM
To: [EMAIL PROTECTED]
Subject: Re: PipeLineLength=2
Brian, be sure you are on MQ 5.3 because it doesn't work on MQ 5.2
CSD06. I have been assured by the Lab that the fix was put into MQ 5.3.
With high volumes of messages on MQ 5.2 you will begin to see channel
protocol errors and receivers rejecting batches due to sequence errors.
Base problem appeared to be the wrong LUWID being presented to the wrong
thread. A fix is available from the Lab for MQ 5.2 however I have not
had the opportunity to test it at my customer as yet. The quick fix was
to turn it off since production wasn't pushing it hard enough to warrant
its use anyway.
Cheers...
Jim Nuckolls
McCarty, Brian wrote:


We are looking at adding PipeLineLength=2 to under CHANNELS: in our qm.ini files.  Has anyone had issues with this before?  How do you know the settings is actually taking effect?

Please let me know your opinions on this parameter.

Thanks,

Brian M. McCarty
USAA, Senior Systems Programmer
210.913.1678
WMQ(I) Specialist/Solutions Expert
e-business Solution Advisor/Designer/Technologist
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive




Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: PipeLineLength=2

[Jim Nuckolls]

Brian, be sure you are on MQ 5.3 because it doesn't work on MQ 5.2
CSD06. I have been assured by the Lab that the fix was put into MQ 5.3.
With high volumes of messages on MQ 5.2 you will begin to see channel
protocol errors and receivers rejecting batches due to sequence errors.
Base problem appeared to be the wrong LUWID being presented to the wrong
thread. A fix is available from the Lab for MQ 5.2 however I have not
had the opportunity to test it at my customer as yet. The quick fix was
to turn it off since production wasn't pushing it hard enough to warrant
its use anyway.
Cheers...
Jim Nuckolls
McCarty, Brian wrote:

We are looking at adding PipeLineLength=2 to under CHANNELS: in our qm.ini files.  Has anyone had issues with this before?  How do you know the settings is actually taking effect?

Please let me know your opinions on this parameter.

Thanks,

Brian M. McCarty
USAA, Senior Systems Programmer
210.913.1678
WMQ(I) Specialist/Solutions Expert
e-business Solution Advisor/Designer/Technologist
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Triggering across New Cluster not working

[Jim Nuckolls]

If you expect the arrival of a message on the queue on the
linux box to trigger a process on the NT box then you are
going to have to have a client trigger monitor running
against the initiation queue on the linux box in order to
make it happen.
Cheers...
Jim Nuckolls
[EMAIL PROTECTED] wrote:
Howdy all,

I have just put together a new cluster between two machine (NT4 and Linux)

The process to run is on the NT machine as well as the trigger monitor
and the initiation queue that it monitors.  I have place a copy of the
process definition on both machine and the queue with triggering turned
on is located on the linux box. All queues have the cluster defined.
I can see the required queues in the cluster using display qc(*)  but
when I put stuff into that queue (on the linux box) the triggering does
not appear to work.
I have 600 other queues still on the NT box which are triggering fine

Any Ideas...Please

Sid Young
Brisbane
Australia
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Segmentation via queue manager for large messages

[Jim Nuckolls]

What's the MAXMSGL on the channel. I would be sure that the
MAXMSGL on the channel and the XMIT queue are the same so
that segmentation occurs when it goes to the XMITQ.
Cheers...
Jim Nuckolls
Christopher Fryett wrote:

I am trying to send a large file and I want the queue manager to segment
the message instead of doing it at the application level.  The max. message
length for the queue manager is 100mb (AIX, WMQ 5.3) and the target queue
is 4mb.  When I set the message flag in the MQMD for segmentation I
continue to get either a 2010 or a 2030.
I am connecting via a mq client session, so is there something I am missing
or incorrectly configuring?
Your insight is greatly appreciated.

Chris

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries and Informix two-phase commit

[Jim Nuckolls]

Hi Heinz,

The last time I looked at that, AIX still wasn't a supported
platform. I hope that has changed for your sake :-)
Cheers...
Jim
Heinz Klein wrote:

Hello all.

I have two questions (and a huge fear of the answers) about transactional
integration between MQSeries and Informix:
a) This integration is provided for HP/UX and Sun Solaris by a
SupportPac. What
about AIX?
b) Can an application program generated using Informix 4GL be used for
two-phase
commit using MQSeries as a coordinator or is this supoport limited to
C/ESQL
programs?
Thank you in advance.

Heinz Klein

OLTP Tecnologia & Solucoes Ltda.
Sao Paulo/SP - Brasil
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Full Queue / Dead Letter Q

[Jim Nuckolls]

Only if it is an MCA doing the MQPUT on the receiver side.
Otherwise the application doing the MQPUT to a queue that
has resolved to the transmit queue receives a "queue-full"
condition and should be smart enough to raise some sort of
alert and back any uncommitted resources out.
Cheers...
Jim Nuckolls
Bill Anderson wrote:

I recently had a customer transmission queue fill up because there receiver
channel was down. Because I am in Atlanta Ga. and they are in Germany, it
takes time to resolve such issues.
But, I was surprised that once the transmit queue was full, messages were
not placed on the dead letter queue. The sending application was just
failing with a 2053. The queue manager dose have a default dead letter
queue defined, and that queue does exist (SYSTEM.DEAD.LETTER.QUEUE). I have
always believed that if a message cannot be delivered for any reason it
goes to the dead letter queue if one is defined. Is that true?
Bill Anderson
Senior Systems Analyst
SITA Atlanta, GA
770-303-3503 (office)
404-915-3190 (cell)
[EMAIL PROTECTED]
http://www.mconnect.aero/
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: queue manager does not exist error

[Jim Nuckolls]

You probably don't have an entry for the queue manager in
the mqs.ini file, or, in the registry if it is Windows.
Cheers...
Jim Nuckolls
Prithwiraj Basu wrote:

Hi All,

I am encountering the following problem:

A week ago I was asked to verify if one of our applications (which uses
MQSeries for inter company communication) was still set up to run for the
testers to test some stuff.  It has been a while since anyone has been
playing around with this application.  At the time when I did strmqm
queue.manager.name, I got a AMQ8118:Queue Manager does not exist error.
Then I saw that the queue manager could not be found in /var/mqm/qmgrs.
(It only had @SYSTEM listed).  Assuming that someone had erroneously blown
away the queue manager,  I had IT restore the queue manager and it again
exists at /var/mqm/qmgrs.  However upon doing strmqm I am still getting the
queue manager does not exist error.  Is there anything else I need to do
for the queue manager to be started?  I really do not want to go through
the whole MQSeries objects setup procedure if I can help it.  Thanks in
advance.
Prits

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: CopyBook with Occurs Clause

[Jim Nuckolls]

The OCCURS clause without the DEPENDING ON means just that.
It expects you to have 3 occurrences.
Juni Per wrote:
Hi,

I have the following COBOL copy book imported into WMQI 2.1 CSD 5.

01 MYCOMPOUND_ELEMENT.

05 MYREPEAT_ELEMENT OCCURS 3 TIMES.

10 TEST-ELEM PIC X(2).

CWF properties , Min Occurs and Max Occurs is set to 3. I modified
min occurs to 1.
If I send a AB12XY , it works fine. But if I send only the first set
, i.e. AB , I get an error that says , message too short. It always
seems to expect the max. Is it expected to send always a fixed
length even with Occurs clause?
I could have used the depending clause , but that would mean I get
the count from the sending application or have some logic that will
populate the count.
Does WMQI expect a fixed length equal to the max occurs whenever I
use a CWF , or is it rectified with some CSD?

Do you Yahoo!?
The New Yahoo! Shopping

- with improved product search
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Is this an MQ issue????

[Jim Nuckolls]

I'm all for getting rid of him. I don't even know Roland
Vasco but I still don't like him.
Cheers...
Jim Nuckolls
Wyatt, T. Rob wrote:
I'm guessing it's a bot.  The site claims the government is stealing time to
mess with this guy's head and his life, that they compressed ten years of
subversive intervening acts into a few seconds of actual clock time.  Big
time conspiracy theorist and crackpot.  Sites like this are famous for
trolling mailing lists with bots.  It's a very low-key method of getting
hits and results in a surprising number of links which in turn raises
rankings on Google and other search engines.  I would be very surprised if
someone that far out on the fringe had a serious career interest in MQ.
I propose that if it keeps up another day or two, we email the list owners
and have the account removed.
-- T.Rob

-Original Message-
From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 09, 2003 11:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Is this an MQ issue
I get the same thing.  I think some new lister has his email set to
automatically respond, similar to an out-of-office message.


  Larry Murray
  <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
  TNAM.COM>cc:
  Sent by: Subject: Is this an MQ
issue
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>
  10/09/2003 10:32
  AM
  Please respond
  to MQSeries List




I keep getting email from the listserv and the only thing in the email is a
link
to some evidence timeline.
I know MQ has some good points and bad points...but this seems not to be
covered in any MQ manual I have seen..
Comments?

Larry Murray
Putnam Investments
Tech Services
1-617-760-3270
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: How long does MQ hold onto a thread on zOS?

[Jim Nuckolls]

The MQ APRM for 5.3 is quite explicit about the close
options for permanent dynamic queues.
Are they using MQCO_DELETE_PURGE??

*===*
MQCO_DELETE
Delete the queue.
The queue is deleted if either of the following is true:
 It is a permanent dynamic queue, and there are no messages
on the queue and no uncommitted get or put requests
outstanding for the queue (either for the current task or
any other task).
It is the temporary dynamic queue that was created by the
MQOPEN call that returned Hobj. In this case, all the
messages on the queue are purged.
MQCO_DELETE_PURGE
Delete the queue, purging any messages on it.
The queue is deleted if either of the following is true:
It is a permanent dynamic queue and there are no uncommitted
get or put requests outstanding for the queue (either for
the current task or any other task).
It is the temporary dynamic queue that was created by the
MQOPEN call that returned Hobj.
*===*
Cheers...
Jim Nuckolls
Jeffrey Ross wrote:
Hello fellow MQers,

I need to know how long MQ takes a thread attached to a queue after an
application has ended to disconnect.  It should be short, somewhere
between instantly and 5 seconds, I would think.  Also, did this value
increase from v5.2 to v5.3?
There is one application group in our shop that processes messages via
model queues and does a get-browse on their output queues, writes the
messages to a flat file and then tries to do a delete-purge.  They do
not want to, and will not, do a regular destructive get.  This
has worked fine for years, until this week.  Three times so far it has
not been able to complete the task and ends with a 2055 error,
'MQRC_Q_NOT_EMPTY'.  A delete-purge works by first clearing the queue,
then deleting the queue.  If a thread is attached to the queue, it can
not be cleared, thus causing the error that is happening.  I would
imagine that an error of 2042, 'MQRC_OBJECT_IN_USE' occurs first, but
only the last error is reported by the application.   My thought is that
even after the application closes that loads the queue and then another
application immediately get-browses, then tries the delete-purge is
failing because MQ is keeping a th! read from the loading application
attached.  If this group tries to run the job again later it will do the
get-browse and the delete-purge th no errors.
Possible useful information:
The model queues create permanent dynamic queues because the messages
need to be persistent and the queue manager is V5R3 running on zOS 1.4.
Thanks in advance,
Jeff Ross
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: TXSeries 5.0/Win 2000 - signal 22 error

[Jim Nuckolls]

It has been quite a while since I supported a TXSeries
system (and that was on AIX), however, if I remember
correctly, you could choose where you wanted SFS to run
(i.e. - a different machine) as well as the underlying data
store (Encina flat file system or DB2). I was always able to
bring CICS up without the PPC Gateway but not without SFS.
It sounds like the SFS piece is running somewhere else which
would account for the rpc errors.
Cheers...
Jim Nuckolls
Heinz Klein wrote:
Hello.

I have CICS 5.0 CSD 3 installed on my laptop with Windows 2000
Professional (SP3
applied).
It works fine as long as the computer is connected to a network. If I
try to
start SFS or the CICS region disconnected from the network I get the
following
error messages:
   1 03628 03/09/27-10:31:18.624368 28106c36 F  Encina Internal Error --
Call yo
ur Support Representative: rpc_server_inq_bindings failed: 0xfffb
   1 03628 03/09/27-10:31:18.654411 0006 F
T:/tr/encina/5.0/source/win32_x8
6/src/client/trpc/trpc_tran.c 2745 abnormal program termination
SYMPTOMS = PIDS/5724NT620 LVLS/500 PTFS/@(#)supos, 18:48:59, Jun 30 2003
RIDS/Su
pOS_SignalHandler LINE/109 MS/058916 MSN/1 SRC/11 PRCS/0 AB/ PID/3628
TID/0 TIME
/030927103118 E. South America Standard T@
SECONDARY SYMPTOMS = Unexpected signal 22 caught
ERZ058916E/0001: Unexpected signal 22 caught
Can someone:

1 - Explain why this happens.
2 - Provide a solution to allow me to use CICS in 'standalone' mode?
Thank you in advance for any help.

Heinz Klein

OLTP Tecnologia & Solucoes Ltda.
Sao Paulo/SP - Brasil
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ v5.3 OS/390 Trigger Problem

[Jim Nuckolls]

Hi Jeff,

If I remember correctly with TRIGTYPE(EVERY), the trigger
message is generated when a message arrives on the queue
however if the transaction abends and the message is backed
out a new trigger message is not generated (that is strictly
from memory and it may have failed me). That would mean that
special provisions would have to be made for abend
conditions if you are absolutely depending on 1 trigger
message per message on the queue and the application reads
one and only one message.
I remember the "conditions for a trigger event" discussion
in the APG discussing the generation of another trigger
message in the case of an abend condition only occurring
with TRIGTYPE(DEPTH or FIRST) and not TRIGTYPE(EVERY).
Cheers...
Jim Nuckolls
Jeff Horner wrote:

Rick,

The transaction is not disabled.

The program that the transaction executes is not disabled.

I disabled another program that is called via a COBOL CALL to cause an
abend. I needed to test this condition, but it is not working out so
well. Here is more details of what is happening in the process.
Transaction WXYZ points to program PGRM001. Both are enabled.

PGRM001 is triggered by CKTI and it opens the queue with open options
INPUT-SHARED, INQUIRE and FAIL-IF-QUIESCING. It then does and MQGET to
get the message from the queue that caused the trigger condition. It
uses get options of WAIT,CONVERT,FAIL-IF-QUIESCING and SYNCPOINT. Then
it does a COBOL CALL to program PGRM999. PGRM999 is disabled in CICS.
This causes the transaction WXYZ to abend in CICS with and ABEND CODE of
4038. Then the transaction WXYZ is never triggered again.
I am at a loss at what is happening.

 >From: Rick Tsujimoto
 >Reply-To: MQSeries List
 >To: [EMAIL PROTECTED]
 >Subject: Re: MQ v5.3 OS/390 Trigger Problem
 >Date: Fri, 26 Sep 2003 09:23:57 -0400
 >
 >Is the program or transid disabled?
 >
 >
 >
 >
 > Jeff Horner
 > < [EMAIL PROTECTED] To:>> AIL.COM> cc:
 > Sent by: Subject: MQ v5.3 OS/390 Trigger Problem
 > MQSeries List
 > <>> en.AC.AT>
 >
 >
 > 09/26/2003 02:51
 > AM
 > Please respond
 > to MQSeries List
 >
 >
 >
 >
 >
 >I have a CICS transaction that is triggered by the CICS trigger monitor
 >(CKTI).
 >The local queue attribute for trigger type is EVERY.
 >When the transaction is triggered it gets a message off the queue under a
 >syncpoint (MQGMO_SYNCPOINT). It then abends and the message is rolled
back
 >to the
 >originating local queue.
 >
 >The problem is that the trigger monitor does not start the CICS
transaction
 >again (no trigger
 >message is put on the initiation queue). I know the transaction does not
 >start again because
 >the use count of the program is not incremented. Does anyone know what
 >could cause this problem as I have used this same logic before and
have not
 >came across this problem in the past?
 >
 >The CICS abend is a 4038. I thought I remembered something about this
abend
 >in CICS has something to do with this problem.
 >
 >Share your photos without swamping your Inbox. Get Hotmail Extra Storage
 >today!
 >Instructions for managing your mailing list subscription are provided in
 >the Listserv General Users Guide available at http://www.lsoft.com
Archive:
 >http://vm.akh-wien.ac.at/MQSeries.archive
 >
 >Instructions for managing your mailing list subscription are provided in
 >the Listserv General Users Guide available at http://www.lsoft.com
 >Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instant message in style with MSN Messenger 6.0. Download it now FREE!
<http://g.msn.com/8HMBENUS/2734??PS=> Instructions for managing your
mailing list subscription are provided in the Listserv General Users
Guide available at http://www.lsoft.com Archive:
http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Pricing for Q Pasa!

[Jim Nuckolls]

Does anybody know what the pricing structure is for Q Pasa!
these days. I got onto the MQSoftware website and picked the
E-mail option for sales information which immediately
presented a page of required information to fill out, one of
which was my phone number. NOT!! I am also interested in
pricing on Nastel's AutoPilot for WebSphere MQ. I sent them
an E-mail asking for a pricing matrix and got back a rather
obfuscated reply -
"Thank you for contacting Nastel. Currently our pricing is
tier based and though it takes in to account the processor
count we also have stand alone components to our solution
which necessitates pricing to be done on a case by case
basis. I will be happy to work with you on this."
No problem getting prices for BMC Patrol for WebSphere MQ
and BMC Patrol Express. Candle's website was useless as far
as I was concerned (pure marketing and not much technical
content and no pricing information either).
Any other players in the monitoring field with similar
capability that anybody knows about??
My customer has about 8 - 10 UNIX Qmgr's and approximately
the same number of Windows based Qmgr's. Nothing huge, but
the information is for law enforcement and can tend to be
critical for field operations.
Cheers...
Jim Nuckolls
Enterprise Systems Integration
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Hostnames or IP addresses for channel connection names

[Jim Nuckolls]

I personally prefer using host names because of the ease of
changing IP addresses should the need arise. However, that
being said, I have always reverted to the use of hard IP
addresses because I have never found a customer account that
maintains their Name Servers in a manner that allows for any
level of confidence in them.
Cheers...
Jim Nuckolls
Kulbir S. Thind wrote:

Hi there,

We have a very large network of MQSeries installations (> 300
installations) that are currently using a mixture of Hostnames and IP
addresses for the channel connection names.  We are in the process of
reviewing our configurations and will be looking to standardise the use
of the conname attribute, either go with Hostnames or IP addresses.
Our gut feeling is to go with Hostnames as they are more descriptive of
what the channel is connected to and also gives us the flexibility of
being able to change IP addresses of machines without effecting channel
definitions.  However, there are people in our team that seem to suggest
that using an IP address rather than a hostname would significantly
improve performance, is this true?  I can believe that there may be a
difference in channel startup times but after that there should be no
difference, is this correct?
Which do people tend to use and why?

Thanks,

Kulbir.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ usage with DB2 stored procedures with Workload manager

[Jim Nuckolls]

What I have done in the past is trigger a process that
monitors the queue depth and starts additional processes or
threads if the queue depth starts increasing. As long as the
queue depth is not greater than the prior inquire leave
things alone; if it is greater initiate another server up to
a maximum that is set as an environment variable. It was a
rather simple approach but worked quite well.
Cheers...
Jim Nuckolls
Blanding, Walter wrote:
We are currently trying to use DB2 stored procedures to pull messages
off of a queue on a Z/OS Qmgr. What we are having problems with is how
to start more then 1 stored procedure when a message gets on the queue.
We are looking for a way to have Workload Manager start more stored
procedures if the queue depth is increasing faster then we are pulling
the messages which would mean it needs to interface with MQ somehow.
Does anyone have any experience with this or any other ideas.
Thanks for any input.

Walt Blanding



Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size.

[Jim Nuckolls]

Are you taking into account the size of the Msg Exit code
itself when it is loaded into memory and remains resident?
Just a thought.
Cheers...
Jim Nuckolls
d a wrote:

Thanks very much to all who have responded thus far (Ruzi, Richard and
Neil),
A few other things to add for anyone who is following this

- I had done as Neil suggested, and run things without the exit, and in
this
case the size of the MSTR does NOT grow. So I know for sure it s caused by
the exit .specifically the MQPUT or MQPUT1.
- I also have tried to just let things be after processing is complete and
the MSTR storage increases .just to see if after x period the storage is
released by the MSTR .but it does not .well not in 12+ hours.
- After pushing the messages (1000 in each direction) through the SDR and
the RCVR, I then go and clear all the messages of the queues. Just
wanted to
see if this had any bearing, and once again nothing, the MSTR sits with
that
storage.
- Also tried to manually stop / restart the channels, this also had no
bearing on things.
- The default persistence of the queue s is  N .

- You guys (Ruzi and Neil) are both correct, but in different cases, about
the commit processing. In my case, I cannot use MQCMIT. This is an exert
from the  Intercommunication Guide :
" All MQI calls except MQCMIT/CSQBCMT and MQBACK/CSQBBAK are
allowed. They must be contained after MQCONN (with a blank queue manager
name). If these calls are used, the exit must be link-edited with the stub
CSQXSTUB.
The exception to this rule is that security channel exits may issue commit
and
backout MQI calls. To do this, code the verbs CSQXCMT and CSQXBAK in
place of MQCMIT/CSQBCMT and MQBACK/CSQBBAK."
Thanks very much .Dax.

_
Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
using MSN Messenger http://entertainment.msn.com/imastar
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: SOC 7 error while displaying S99 Fields in COBOL (WMQI 2.1)

[Jim Nuckolls]

The INTEGERSIGNED field (if memory serves me correctly) is
treated as a Zoned Decimal field. In other words, the low
order byte will have the high order 4 bits set to "C" for
positive and "D" for negative numbers (system preferred
signs). I can't remember if it accepts "A" and "F" for
positive and "B" for negative as well. Packed decimal
arithmetic will accept any of the "A" through "F" bit
configurations in the sign position. It sounds like what is
getting passed across and converted in the sign position on
the host side is resulting in a bit configuration of 0
through 9 accounting for the data exception (S0C7).
Cheers...
Jim Nuckolls
Juni Per wrote:
Hi ,

I have the following COBOL copy book imported into WMQI(2.1 WinNT)

06  TESTVARIABLES.
07  TESTINPUT.
   08  INTEGERNOSIGN   PIC 99.
   08  INTEGERSIGNED   PIC S99.
   08  DECIMALNOSIGN   PIC 99V99.
   08  DECIMALSIGNED   PIC S99V99.
   08  COMP3NOSIGN PIC 99V99 COMP-3.
   08  COMP3SIGNED PIC S99V99 COMP-3.


I assign the following values to them in a compute node

SET "OutputRoot"."MRM"."INTEGERNOSIGN" = 12;

SET "OutputRoot"."MRM"."INTEGERSIGNED" = -12;

SET "OutputRoot"."MRM"."DECIMALNOSIGN" = 1234;

SET "OutputRoot"."MRM"."DECIMALSIGNED" = -1234;

SET "OutputRoot"."MRM"."COMP3NOSIGN" = 5678;

SET "OutputRoot"."MRM"."COMP3SIGNED" = -678;

Now when a COBOL program on mainframe reads this message and moves into
the same copybook and displays the fields , I get an SOC 7 error for the
S99 field.WHat could be the problem. Pls respond.


THanks in ADvance




Do you Yahoo!?
SBC Yahoo! DSL
<http://pa.yahoo.com/*http://rd.yahoo.com/evt=1207/*http://promo.yahoo.com/sbc/>
- Now only $29.95 per month!
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Comparing IBM MQSeries to other products

[Jim Nuckolls]

I just couldn't let this one pass:-)

:soapbox on
My experience with those comparisons when I was in a
marketing situation is that they were anything but "good."
Those products are pure JMS brokers (w/o any of the depth of
the MQI) and are nowhere near the "industrial strength" that
belongs to WebSphere MQ. They furnish the "least common
denominator" if you will in the messaging world. The
benchmarks they ran used MQ "out-of-the-box" configurations
with no tuning for that environment whatsoever. If that
sounds like a little blue bias, you're right:-)
:soapbox off
Cheers...
Jim Nuckolls


Bob Kasischke wrote:
Check out Sonic Software's (http://www.sonicsoftware.com) and Fiorano's
(http://www.fiorano.com/) websites.  They have good comparisons between
themselves and MQSeries.
bob k



-Original Message-
From: Madsen, Timothy [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 6:47 AM
To: [EMAIL PROTECTED]
Subject: Comparing IBM MQSeries to other products
Hello,
We use MQSeries for our application.  This application gets sold to our
customers.  Sometimes the customers question our choice of technology.


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQRO_DISCARD_MSG option doesn't work with z/OS OTMA Bridge qu eues ?

[Jim Nuckolls]

It's the MQ-IMS Bridge (the OTMA Client code in MQ) that is
putting the message to the DLQ.
Cheers...
Jim
Potkay, Peter M (PLC, IT) wrote:

I am 5.3.

It does work with regular queues, just not OTMA queues.

I wonder if the OTMA actually puts the messages to the DLQ, and not the QM.
And its the OTMA that is not respecting the discard option, while the QM
actually does???


-Original Message-
From: Darren Douch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2003 4:49 PM
To: [EMAIL PROTECTED]
Subject: Re: MQRO_DISCARD_MSG option doesn't work with z/OS OTMA Bridge
queues ?
Peter

what MQ version are you using on z/OS ?  I certainly recall that it wasn't
supported on MVS
when it first was introduced on distributed but maybe support has been
slipped in 'recently' -
5.2 or 5.3 ?
Looking at the 5.3 manuals.. there is certainly no reference to
MQRO_DISCARD_MSG
not being supported on the mainframe - so it should work fine at that level.
Regards
Darren
- Original Message -
From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 05, 2003 9:26 PM
Subject: MQRO_DISCARD_MSG option doesn't work with z/OS OTMA Bridge queues ?


I have been trying to use this option when sending messages into my OTMA
bridge queues, but it is not working.
Is it supported on z/OS?

I seem to remember reading somewhere this option is not supported for the
mainframe, but now I cannot find that reference.
This option does seem to work on regular z/OS MQSeries queues. If I mess
with a regular local queue to force message to the DLQ, the discard option
works just fine and the QM does not put messages there. But any forced
problems with an OTMA bridge queue still cause messages to the DLQ,
regardless of the MQRO_DISCARD_MSG Report Option.


Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Any of you , WMQI folks checked out Crossworlds?

[Jim Nuckolls]

You might want to take a look at WebSphere Data Interchange
for transformation and it is MQ enabled. It is somewhat
cheaper are far as the price tag is concerned in relation to
WMQI. If later you find that you need WMQI then WDI can run
as a node in a message flow.
Cheers...
Jim Nuckolls
Enterprise Systems Integration
eai grp wrote:
Hi All,
Iam looking for a best fit product for an integration which is more like
multiple branches sending information to a central processing
applications.All branches run the same software package , different
instances at each location ,though.
And they are MQ Enabled.No process automation required , mainly
transformation.
Does WMQI score well or Crossworlds??What about Scalability?
Please Respond
Thank You

Do you Yahoo!?
SBC Yahoo! DSL
<http://pa.yahoo.com/*http://rd.yahoo.com/evt=1207/*http://promo.yahoo.com/sbc/>
- Now only $29.95 per month!
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Xa Resource manager not available

[Jim Nuckolls]

   Hm, that's not according
to design as far as I remember.  It was 2 years ago (Oracle
8 and MQ 5.2) when I was dealing with that particular
configuration. Neither side is supposed to depend on the
other partner(s) being available 100%. Sounds like time for
a PMR. I would turn on the trace facility for the XA flows
in the XA string in qm.ini as part of my data gathering
prior to opening the incident.
Here is the string in the qm.ini file I used to collect as
much detail as possible. The DbgFl=0x15 is the setting that
says to collect as much data as possible.
xaoopen:
xa_info=Oracle_XA+Acc=P/app_prod01/longliveoracle+SesTm=0+DB=PRCSMDB1+LogDir=/tmp+MaxCur=100+SQLNet=PRCSMDB1+DbgFl=0x15,rmid=1,flags=0x0
Hopefully this will get you a little further into the
problem determination process.
Cheers...
Jim Nuckolls
[EMAIL PROTECTED]
Kearns, Emile E wrote:
Hi all,

Is there another to start the XA connect between the Queue Manager and an
Oracle Database other than to restart the Queue Manager.
Often  the DBA's stops and starts a database without the MQ admin staff
knowing, this then breaks the XA connection.
After the database has been restarted, the XA connection is not there.
How can this be started with restarting the QMGR?
For information about he Standard Bank group visit our web site
www.standardbank.co.za
Disclaimer and confidentiality note

Everything in this e-mail and any attachments relating to the official business of the 
Standard Bank Group Limited  is proprietary to the group.
It is confidential, legally privileged and protected by law. Standard Bank does not 
own and endorse any other content. Views and opinions are
those of the sender unless clearly stated as being that of the group.The person 
addressed in the e-mail is the sole authorised recipient. Please
notify the sender immediately if it has unintentionally reached you and do not read, 
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been 
maintained nor that it is free of errors, virus, interception or interference.
I
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ software evolution - fill in the gaps?

[Jim Nuckolls]

From an old IBM'er:

EZ-Bridge Transact was developed by a company named SSI (no
longer in existence) to provide Release 1 MQ capabilities
for the distributed platforms while we developed the MVS
Release 1 Qmgr. IBM first marketed then bought the EZ-Bridge
code. It was a horrible monolithic piece of code but filled
the gap until Release 2.
TCAM was a communications access method with an API that was
used in developing transaction systems. It did indeed queue
up input and output messages on hardened disk queues. You
could use TCAM as the communications access method for IMS,
however, you ended up writing messages to the TCAM queues
then to the IMS message queues (not very efficient). Earlier
versions of CICS also supported the TCAM interface as well
as Bisync and VTAM.
Cheers...
Jim
[EMAIL PROTECTED] wrote:
All,

I thought ez-bridge came before MQSeries, unless it was Rel 1.0 of MQSeries
which I'm certain was Release 2.0.
By the by, TCAM (TeleCommuncationAccessMethod) wasn't messaging, it was the
precursor to IMS and CICS, I think.  I recall it was in use back in the
early 1970's.






  "Heggie, Peter"
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  NGRID.COM>   cc:
  Sent by: MQSeriesSubject:  Re: MQ software evolution - 
fill in the gaps?
  List
  <[EMAIL PROTECTED]
  n.AC.AT>
  06/10/2003 12:06
  PM
  Please respond to
  MQSeries List




Not really, although I've had that thought. I'm trying to see where the
two (or three) product lines overlap, see how that overlap has changed
and try to estimate what will be left in a year or two.
Peter Heggie
(315) 428 - 3193
-Original Message-
From: Fryett.Chris [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 11:20 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ software evolution - fill in the gaps?
Are you trying to show how ridiculous companies are getting with
renaming their product line?


-Original Message-
From: Heggie, Peter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 9:49 AM
To: [EMAIL PROTECTED]
Subject: MQ software evolution - fill in the gaps?
Can someone help fill in the gaps or correct my note below? I'm trying
to establish a timeline and show the names of the various MQ software
names and dates.
MQ: MQM (199? - 199?) -> MQSeries (199? - 2001) -> Websphere MQ (2001 -
present)
MQSI: MQSI (199? - 2000) -> WMQI (2000 - 2002) -> WMQIB (2002 - 2003) ->
WBIMB (2003 - present)
Workflow: ???

MQSI included NEON up until v2.2
Workflow now includes the Crossworlds technology? Which is named? WBIMB
includes WBIEB, or you can get WBIEB separately..?
Thanks!

Peter Heggie
National Grid, Syracuse, NY


This e-mail and any files transmitted with it, are confidential to
National Grid and are intended solely for the use of the individual or
entity to whom they are addressed.  If you have received this e-mail in
error, please contact the National Grid USA Enterprise Support Center on
508-389-3375 or 315-428-6360.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
*
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other
use of or taking action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you have
received this email in error please contact the sender and delete the
material from any computer.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.a