Hi Murugesan,
a couple of comments
First of all, you should change the line
memcpy(md.CorrelId, "COR1", sizeof(md.CorrelId));
into
memcpy(md.CorrelId, "COR1", 4);
in both programs. You were obviously lucky that this didn't cause a GPF
(0xC5 memory fault) during execution, and that might alre
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). Theref
Hi all,
Let me explain the scenario
I have 3 MQ series client. All 3 clients post the messages on the same queue
.
The idea is, whoever posted the message only they should get the response
for that message.
To do that I group the messages by CorrelId,
For Client1 the CorrelId is COR1
Clie
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 t
>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 b
Seems to me it would not be a feature of the client, but rather a feature of the qmgr
to which the client connects. In any case, you can always accomplish that
functionality at the application level.
regards,
Dennis
> -Original Message-
> From: Joshi, A (Anant) [SMTP:[EMAIL PROTECTED
Many thanks to all that replied to my post. Excellent information. I'll be testing
with the 037 CCSID.
Thanks again!
Doug
-Original Message-
From: Kelly Urban [mailto:[EMAIL PROTECTED]]
Sent: Wed 1/15/2003 1:37 PM
To: [EMAIL PROTECTED]
$)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.
http://www-1.ib
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 on
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-
From:
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 [ma
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
conve
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 of
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
Redd
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.
- Ori
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 for
"...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: Wedn
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
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.
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 shou
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, th
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 m
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
LOOK for the deraded FDC files in /var/mqm/errors/ This may have generated
some dumps.
bobbee
From: Jeffrey Ross <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: 2195 Error
Date: Tue, 14 Jan 2003 20:08:16 -0600
Hello Fellow MQer
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 PROT
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 Sco
>Hello Fellow MQer's,
>I have this weird problem with MQ V5.2, AIX 4.3.3. Our AIX Admins
rebooted the machine. After the reboot I started MQ and the Client Server
and connected through MQ Explorer on >WIn2K. An application team that
uses this particular server informed me they have been get
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 F
it is solved, WMQI treats redefines element as choice elements.
My copy book had
07 ELEMENT1PIC X(6).
07 ELEMENT2
REDEFINES ELEMENT1.
and so only one of them, either ELEMENT1 or ELEMENT2 needed to be assinged and not
both.
Thank you
-Ursprüngliche Nachricht-
Von:T
29 matches
Mail list logo
