| Author |
Message
|
| dfailla |
 Posted: Thu Mar 02, 2006 6:45 am Post subject: MQRC_Format_Error rc=2110 |
 |
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
Forgive my ignorance on the Server side but I'm an old Mainframe programmer trying to resolve an issue with MQ for Windows V5.3.
We can send a message using Message Grouping(just one message using last_msg_in_group) with mqfmt_string from a Windows server to our Host(Z/OS) and it works fine. Using same message but with mqfmt_none and the message ends up on the Windows DLQ. Error log shows reason code 2110. I viewed previous problem logs similar to this issue posted on this website and IBM's Support site. I saw a PTF was issued for V5.2, but I haven't seen anyone describing this problem using V5.3 for Windows.
I know the Xmit queue reformats MQMD and adds MQMDE, but I don't understand why we are able to send a Message Group(msg seq no = 1 and last_msg_in_group) using mqfmt_string but can't send same message with mqfmt_none?
Will Fix pack 12(csd12) resolve this issue? Any help greatly appreciated since I am lost dealing with Windows/MQ issues. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Mar 02, 2006 6:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Quote: |
2110 (X'083E')
MQRC_FORMAT_ERROR
Explanation:
An MQGET call was issued with the MQGMO_CONVERT option specified in the GetMsgOpts parameter, but the message cannot be converted successfully due to an error associated with the message format. Possible errors include:
* The format name in the message is MQFMT_NONE.
* A user-written exit with the name specified by the Format field in the message cannot be found.
* The message contains data that is not consistent with the format definition.
The message is returned unconverted to the application issuing the MQGET call, the values of the CodedCharSetId and Encoding fields in the MsgDesc parameter are set to those of the message returned, and the call completes with MQCC_WARNING.
If the message consists of several parts, each of which is described by its own CodedCharSetId and Encoding fields (for example, a message with format name MQFMT_DEAD_LETTER_HEADER), some parts may be converted and other parts not converted. However, the values returned in the various CodedCharSetId and Encoding fields always correctly describe the relevant message data.
Completion Code:
MQCC_WARNING
Programmer Response:
Check the format name that was specified when the message was put. If this is not one of the built-in formats, check that a suitable exit with the same name as the format is available for the queue manager to load. Verify that the data in the message corresponds to the format expected by the exit. |
Try disabling conversion on the channel.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dfailla |
| Posted: Thu Mar 02, 2006 7:16 am Post subject: format error |
|
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
| We want the Sender Channel to perform the conversion. Some messages(within a single group) will contain text that needs conversion from Ascii to Ebcdic, and other messages contain TIF messages that we do not want converted. The Sender Channel on Windows IS converting successfully the mqfmt_string and we see this message on our Host Queue. When trying to send(just in test mode) the same message but with mqfmt_none the messages arrives on Windows dead letter queue. I would have expected a problem with the mqfmt_string... not the mqfmt_none. The only difference between the two messages is the format parm. Again, we don't want the Host application to perform conversion since we want the built-in function to perform this conversion from the Sender channel. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Mar 02, 2006 7:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Did you read jeff's reply?
You get 2110 because you have specified CONVERT on the channel and the msg format is MQFMT_NONE. This is published behaviour.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| dfailla |
| Posted: Thu Mar 02, 2006 7:31 am Post subject: |
|
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
| mqfmt_none will tells the Sender channel's MCA NOT to perform conversion. We are able to send "normal" messages without Message Grouping using mixtures of mqfmt_string and mqfmt_none to the Host. However, when we change mq options to use msg_in_group we are only able to send the mqfmt_string. Must be something to do with transmit queues and how they massage mqmd between vs1 and vs2. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Mar 02, 2006 8:44 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
Application data is converted within an application program when you specify the MQGMO_CONVERT option in the Options field of the MQGMO structure passed to an MQGET call, and all the following are true:
The CodedCharSetId or Encoding fields set in the MQMD structure associated with the message on the queue differ from the CodedCharSetId or Encoding fields set in the MQMD structure specified on the MQGET call.
The Format field in the MQMD structure associated with the message is not MQFMT_NONE.
The BufferLength specified on the MQGET call is not zero.
... |
I wonder if the problem is really related to grouping the messages versus having a MQ V2 structure (mqmde).... 
_________________
-wayne |
|
| Back to top |
|
|
| dfailla |
| Posted: Thu Mar 02, 2006 10:31 am Post subject: Remote queue format error 2110 |
|
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
The only thing different between a successful put of a message in group and a bad put is the format option of mqfmt_string vs mqfmt_none. Mqfmt-string DOES work... we know the MCA has MQGMO_convert and successfully puts message to a Z/OS remote queue. The same message in group with mqfmt_none does not make it and ends up on the Windows DLQ.
I did notice something strange about the Format field when viewing the DLQ header. It says the original messages' format was 'MQHMDE'. I believe when a message cannot be put to a remote destination queue the message will be put to the local DLQ with the original messages' CCSID, Encoding and Format. I do see the CCSID with 437 and Encoding as 546... so I know these settings were correct when MCA tried to send message from Windows to Z/OS. However, IF the original program that put the message to a remote queue definition used mqfmt_none... then I should see this on the DLQ header right? |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Mar 02, 2006 10:41 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
'MQHMDE' would be the correct format for a MQMD V2 message that uses the fields in the V2 portion of the MD (and the group info is an example of using that field).
What actually happens is that for messages with a V2 MQMD (and uses the V2 fields in the header), MQ actually puts the V2 portion of the MQMD in the application payload area of the message and sets the format to MQHMDE. It then puts the original "Format" in the MQMD V2 extension structure (which is in the payload area). You should see this structure in the DLQ message (after the DLQ header, I think) with an eyecatcher of "MDE". The MQMDE structure maps this extension, so you should see your MQFMT_NONE (blanks) in the Format field of the MQMDE structure...
Normally, you don't see this because MQ merges the MQMDE structure into the MQMD structure on the MQGET....
hope this makes sense....
_________________
-wayne |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Mar 02, 2006 1:14 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| mqfmt_none will tells the Sender channel's MCA NOT to perform conversion |
Wrong. MQFMT_NONE and MQGMO_CONVERT = rc 2110.
In Wayne's answer above, some of the V2's have to be V1's.
If a get with a V1 MD is done on a msg with non-default MD V2 fields, the V1 MD is returned and tve V2 fields are put in the MD extension header MQMDE. The Format in the MD is then set to MQHMDE, and the original format from the MD is put in the Format field of the MDE.
None of that, or msg groups, has anything to do with the format error.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Mar 02, 2006 3:40 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Wrong. MQFMT_NONE and MQGMO_CONVERT = rc 2110. |
almost right ... the CCSID or Encoding need to be different (between the MD in the msg and the MD spec'd on the GET) to get 2110, if they are the same, the GMO_CONVERT on MFMT_NONE gives rc-0.
dfailla ... I'm wondering how you can get MQFMT_NONE to work ok for the non-group messages, is there a chance that the ccsid and encoding match that of the m/f already in that case?
_________________
-wayne |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Mar 02, 2006 11:48 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
good extra condition wayne, thanks.
I did mean of course that if conversion is going to be done at all then the error will occur, but I did not say so explicitly.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| dfailla |
| Posted: Fri Mar 03, 2006 7:39 am Post subject: mq rc=2110 |
|
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
We send a character message(that needs ascii to ebcdic conversion) followed by one or more TIF files(that should not be converted). The messages multi-hop from a Windows NT server/scanner to a central Windows NT server(via Remote queue defs) that has a channel defined to the host. This works fine today in Prod. They do NOT use message Grouping.
For a test only... I sent a character message and TIF message with mqfmt_string and mqfmt_none to the Host queue. Character message converted fine and TIF message arrived unconverted. When I take same two messages and use mqpmo.logical_order and mqmd_last_msg_in_group... only the character message arrives. I know IBM had a problem with rc=2110 on xmit queues on messages with Grouping because there is a PTF out there for Windows V5.2. Problem I'm having is why won't V5.3 work? We installed Windows Fix Pack12 so I hope this fixes problem.
GMO.convert being performed by the MCA shouldn't care if mqfmt_none is specified since I can send messages needing conversion and messages that don't on the same sending channel. It's up to the application to decide which messages they want the sending channel to convert before delivering to Host receiving MCA. Convert=yes merely tells the channel to look for messages to convert(if applicable). Since the message hopped from one Windows server to another first... no conversion was necessary. When the sender channel initiated conversation with the Host receiver channel... the CCSID was different so it recognized conversion was necessary(only if mqmd format had a built-in function to tell it to convert or a user defined function and exit were present). Mqfmt_none says do not convert... even if channel has convert=yes |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 03, 2006 7:48 am Post subject: Re: mq rc=2110 |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| dfailla wrote: |
| Mqfmt_none says do not convert... even if channel has convert=yes |
NO.
To recap what has already been said in this thread:
MQFMT_NONE says that a message does not have a defined format.
Any application that specifies MQGMO.CONVERT and attempts to GET a message that both specifies MQFMT_NONE and has a different CCSID than the application will always receive a 2110 error code.
The receiver MCA on the host is just another MQ application, and so it will always receive the 2110 error code. The receiver MCA therefore can't properly receive the message, and will indicate this to the sender MCA. This will cause the sender MCA to put the message to the local DLQ.
This is all documented behavior.
Channel level conversion in general is a bad idea (particularly in multi-hop environments!) - and this is one reason why. Since you must be changing your host applications to receive message groups, you should also change them to specify the MQGMO.CONVERT on their GET, and disable channel conversion. Then your applications can choose to ignore the 2110 and handle the data anyway.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 03, 2006 11:06 am Post subject: Re: mq rc=2110 |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| dfailla wrote: |
| Mqfmt_none says do not convert... even if channel has convert=yes |
NO.
To recap what has already been said in this thread:
MQFMT_NONE says that a message does not have a defined format.
Any application that specifies MQGMO.CONVERT and attempts to GET a message that both specifies MQFMT_NONE and has a different CCSID than the application will always receive a 2110 error code.
|
Correct.
dfailla, if you look in the Application Programming Guide, Appendix F: Data Conversion, you will find the following quote
| Quote: |
If the Format field in the control information in the message has the value MQFMT_NONE, the message is returned unconverted, with completion code MQCC_WARNING and reason code MQRC_FORMAT_ERROR.
In all other cases conversion processing continues.
|
We relied on this behaviour for a Windows app that would have received messsages from either the mainframe or PDF files from a Windows server. It always coded MQGMO_CONVERT. If it was a MF message, conversion happened. If the GET failed with 2110, they did a quick check to see if it was a PDF file, and then ignored the error if it was and went down the PDF path of the program.[/quote]
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dfailla |
| Posted: Sat Mar 04, 2006 8:02 am Post subject: rc 2110 |
|
|
Newbie
Joined: 02 Mar 2006
Posts: 6
Location: Columbia,SC
|
Thanks Peter,
however our "getting" application is just the Sender Channel MCA between the Xmit queue and the destination queue's receiver channel.
When message hops from 1st Windows NT server to 2nd Windows NT server; the 2nd Windows NT queue is just a remote definition/xmit queue that is trying to send message to the Z/OS Qmgr(there is no application running on the 2nd box).
1st message hops from 1st NT to 2nd NT to Z/OS(mqfmt-string)
2nd message hops from 1st NT to 2nd NT to Z/OS(mqfmt-none) <<< this message arrives fine(it's a TIF record from an image scanner that should not be converted by any QMgr).
3rd message hops from 1st NT to 2nd NT to Z/OS(last_msg_in_group, mqfmt-string) <<< this works with Message Grouping
4th message hops from 1st NT to 2nd NT to 2nd NT DLQ.(last_msg_in_group,mqfmt-none) <<< this message arrives on DLQ with 2110.
The 2nd and 4th message are the same except we used Message Grouping on the 4th message. If the MCA handled mqfmt_none on 2nd message... it should work with 4th message. It does not... and I believe it's related to V2 fields now being used/creating MQMDE and Transmit queue /MCA not handling the warning(rc 2110) correctly. |
|
| Back to top |
|
|
|
|
