Hi,
I'm trying to get the MQSeries trigger program for
TXSeries CICS (amqltmc0) running.
In fact, it runs, and triggers CICS transactions,
fine. The problem is stopping it.
The manuals (MQ, or TXSeries) don't seem to address
this at all. A Purge of the transaction, via CEMT, does nothing; a
I have not used this trigger monitor but the nomal approach would be to get
disable the queue that the trigger monitor is polling.
Barney
If this is under CICS go to the CICS Adapter screen (type in CKQC) and under
the heading of CKTI I believe you can stop it there.
bobbee
From: Robert X. Sloper [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL
Hi,
I came across this problem a few days ago in our
production box. Upon checking on our host log, the
message appears as 'Remote qmgr not available' and
when check at the receiver end, the qmgr is up and
running. Found the error at the receiever end with
2059 on the channels(os390 to as400). Any
Heres info on my environment
XP pro, mqseries client 5.1
Os/390 2.1 mqsersies 5.3
I am trying to send a pdf as the content of a mq message
from NT to os/390, a os/390 process needs to pick the message up unconverted. The
problem is some characters are getting converted in the
Hi,
What I am finding in the error logs and FDC files are AMQ6209: An
unexpected asynchronous signal (15) has been received and ignored.
Also receiving AMQ6183: An internal MQSeries error has occurred.
The FDC file also contained Major Errorcode
xecE_W_UNEXPECTED_ASYNC_SIGNAL
As stated, this
Perhaps you could post the content of your MSGUSR sysout from the CICS
region around the abend. As was said before, a bad message should not
terminate the bridge monitor (CKBR) but will terminate the bridge task
(CKBP), there is a separate CKBP for each message received.
Any failure in a CKBP
You could try setting the CCSID in the message to that of your QMGR on
OS/390. When MQ sees that the there's no difference in the CCSID, it
should bypass any conversion attempts.
It appears that it is written for MQ5.2? Has anyone tried it on MQV5.3?
Any precaution to take before using it for MQ5.3?
TIA
- Original Message -
From: Jan van Kemenade [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 14, 2003 11:24 PM
Subject: Re: Analysis of MQ SMF
...a os/390 process needs to pick the message up unconverted
Insure that the mainframe is not specifying MQGMO-CONVERT.
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
Sent:
But Deborah specifically said that the message format was set to MQFMT_NONE
(well actually she said blank, but that's the same), so no conversion should
apply. I suspect some form of application error reading or writing the
file (e.g. file read as text rather than binary).
Dave
Instructions
This is under CICS on AIX (aka TXSeries), so there are no CK* transactions; but Robert
Sloper's
suggestion does exactly what's needed - a clean shutdown of the trigger monitor, which
can then be
restarted OK once the initiation queue has had GETs re-enabled. Many thanks.
Barney Scott.
-
Even I too faced the same problem..See if you have any changes in
the Channel settings.
I got solved this problem by stopping and staring the
channel..Some times you may get the problem with Network as
well.Please check the log under \mqm\log\(may in As/400 the path
will be differrent)
Cheers
We had a similar problem, right down to the x'7F's. It turned out that
it wasn't MQSeries that was doing the translation. Instead, it was
because the VB program read in the file before writing it to the
queue, and the way it read it caused VB to translate the input file
into 2-byte Unicode. Some
Hi Everyone,
I have an MQI application that sends character data from Win2K (MQ 5.2, CCSID 437) to
OS/390 (MQ 2.1, CCSID 500). Conversion is requested of the qmgr by the application on
the MQGET.
The data is converted, except for one problem. An exclamation point, ASCII x'21', is
Use CCSID 037 (US EBCIDIC) on OS/390 instead of 500 (International EBCIDIC).
It solves the ! problem.
(Why ! isn't a valid international character beats me)
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Douglas Pierson
Hi Doug,
The ASCII-EBCDIC Chart is available, for instance, at:
http://www.natural-innovations.com/computing/asciiebcdic.html
You may also consider using a C/C++ snippet available, for instance, at:
http://www.cppfrance.com/article.aspx?Val=467
Vladimir Anisimov
-Original Message-
Doug -
We had a similar issue (exact same OS's on both sides). I ended up in a
crash course on character sets. Best place for an overall view of your
issue, and what IBM wants you to do about it is at :
http://www-3.ibm.com/software/ts/mqseries/support/faqs/convert.html
Depending
$)C
Hello Doug,
If the ASCI x'21' to EBCDIC x'4F' is correct, ...
This is correct, if your EBCDIC is CCSID500.
See the following char table of CodePage500. x'4F' means exclamation mark.
On the other hand, in the EBCDIC CCSID924(=CodePage924), x'5A' means
exclamation mark.
Now the powers that be want to use this type of asynchronous facility for
all communications. Even if the user MUST get a valid reply on the status
of the request and MUST get this in a timely manner.
Matching the best technology to the job at hand should be science, but taking
broad
Anant,
MQSeries for OpenVMS/VAX is release 2.1, and does NOT support segmentation.
MQSeries for OpenVMS/Alpha is release 5.1, and DOES support segmentation.
You must be on the Alpha platform.
If you need to simulate segmentation, it can easily be done a unique message or
correlation identifier
Hi,
Your code looks fine, except you are doing a programming no-no. I don't
like the following line:
memcpy(md.CorrelId, COR1, sizeof(md.CorrelId));
The string COR1 is only 4 bytes (memcpy does not copy the NULL) but you
are copying 24 bytes (because sizeof(md.CorrelId) is 24).
22 matches
Mail list logo
