|
Bill,
yes, I did but I've only
just got my test queue manager back. I've just been testing with your
sample today and it works fine with MQFMT_IMS !
I'm running your sample on an
NT box connecting to a NT queue manager to get to the m/frame queue
manager, whereas my attempt was running as a direct client connection to
the m/frame. But as I have data conversion on the channel turned off I
guess there should be no difference, conversion
wise.
at least I've seen it working
now!
many thanks for your help and
the sample,
Pete
MQFMT_IMS_VAR_STR worked
for me. Did you get the sample code I sent last week?
Bill Beinert
Systems
Programming
Con
Edison
(212)
460-4853
When they took the fourth amendment,
I was quiet because I didn't
deal drugs!
When they took the
sixth amendment,
I was
quiet because, I was innocent.
When
they took the second amendment,
I was quiet because I didn't own a gun!
Now they've taken the first amendment,
and I can say (or do) nothing
about it.
The Second Amendment is in
place in case they ignore the others.
MODWN DAbE
Hi Martha,
the symptom I get is the message is rejected with a IIH
Error as follows...
CSQ2005I &ME04 CSQ2QCP0 ERROR PROCESSING
MESSAGE,
FEEDBACK=296, XCFGNAME=CGTEST2
XCFMNAME=EBAIMSY TPIPE=CSQ0008D
(296 = MQFB_IIH_ERROR)
when I look at the message on the DLQ, the IIH and the
user message is garbled (unconverted
from the ASCII) which I am assuming is the problem. If I input the
from an MVS program with the same IIH set up it works
fine! I can also get a message into
IMS successfully from my windows client if I use MQFMT_IMS_VAR_STR.
The OTMA side looks fine (I'm really an IMS sys prog by
trade so I'm comfortable with the IMS
set up just not the MQ programming....which may explain the problem !!)
I'm trying the C program kindly sent by William,
unfortunately my test queue manager is
broken at the moment (not my fault this time!). However if I use this and send the message into a
non-OTMA local queue on another MVS queue manager and look at the message
there the IIH and user data is still unconverted, would I expect
to see this data converted here or does something magical happen only if it
is a OTMA queue ? Doing the same thing with MQFMT_IMS_VAR_STR when I
look at the message on the queue its converted there. I'm confused as
to when and where conversion happens for
MQFMT_IMS.
many
thanks,
Pete
Peter,
A copy of a message showing what a 100-byte message
without an IIH header should look like for IMS transaction PGMXTSCA is
attached (used Sun box at the time). Perhaps placing your
existing message in a local queue, displaying it with amqsbcg0 and
comparing to the attached could help (adjusting for the message
length).
Few questions - assuming the problem at this time is that a message is being
sent to the mainframe and nothing returns.
- What is the actual symptom or error encountered?
- Is the message getting to the mainframe at
all? Does it show up in the DLQ for the mainframe queue
manager?
- The bridge (OTMA) should be configured on the
mainframe for the MQ and IMS subsystems being utilized. Has this
configuration been verified? If the IMS command /DIS
OTMA is entered on the mainframe, does the MQ member of the OTMA group
(representing the MVS queue manager) display "ACCEPT TRAFFIC"
- If the previous reply is yes, it may be necessary to
engage a mainframe resource who can issue MQ and IMS commands to work
with you while you attempt to recreate the problem.
- If OTMA is configured and the message is getting to
the mainframe, are there any CSQxxxxx or other errors on the mainframe
side at the time the message attempts to go to the bridge queue? This
will determine wether the message was rejected by the bridge and
why.
- Is the id being used authorized for the bridge on
the mainframe?
- Are there any IMS OTMA exits in place that could be
altering the expected bridge behavior? This is an often overlooked
factor that can sometimes create errors that are difficult to
debug.
There is a support pack (bridge exerciser) at
- initially made for the mainframe but comments
indicate it should run in most platforms - includes directions plus an
IIH if you care to use it.
Hope this helps!
Regards,
Martha M. Mora
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.
|
