"Applications that connect to the queue manager
that owns the IMS bridge queuemust
provide an MQIIH structure that is in the character set and encoding of thequeue manager. This is because data conversion
of the MQIIH structure is notperformed in
this case.
Applications that connect to other queue managers
can provide an MQIIHstructure that is in
any of the supported character sets and encodings;conversion of the MQIIH is performed by the
receiving message channel agentconnected
to the queue manager that owns the IMS bridge queue."
(..........presumably only if you have data conversion on ???)
Anyhow, my case is the
first case as I'm connecting from Windows to a mainframe qmgr asa
client. I'm happy enough to keep trying on the
basis I'm just doing something wrong or missing something obvious, but this text
from the manual suggests its never going to work. Replies on the list server
suggest it does.....what does the above text refers to
?
Is anyone actually connecting
to the bridge queue owning queue manager as a client from windows and using
IIH ? in which case would you care to share the relevant parts of the
client app code (the bit that sets the MQIIH and MQMD) with
me?
many thanks for all your
help,
Pete
-----Original Message----- From: Martha M. Mora
[mailto:[EMAIL PROTECTED] Sent: 24 December 2003
00:49 To: [EMAIL PROTECTED] Subject: Re: MQ IMS
Bridge question
Hello Peter,
I agree with Jim and Gary regarding the conversion -
adding a couple of comments on the use of the IIH. Is there a specific reason to include the IIH? Usually, if
there is no need to alter the IMS defaults taken without an IIH, there is no
reason to add an IIH.
The Application Programming Guide (APG) documents the
default behaviors when no IIH is utilized. Usually, (except for
any required IIH overrides documented in the Application Programming
Reference), the most common reasons that would dictate use
of the IIH have been included in a table in the APG covering
different combinations of commit modes, message persistance, and
t-pipes used by the bridge. Familiarity with this usage is helpful
in determining wether or not to use an IIH, as well as in understanding
possible error messages that could surface due to illegal combinations of
commit mode, t-pipe type, and persistance.
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.
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.
