ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Error 2110 when processing message from receive Q. URGENT!!

Post new topic  Reply to topic Goto page 1, 2  Next
 Error 2110 when processing message from receive Q. URGENT!! « View previous topic :: View next topic » 
Author Message
gertvangaever
PostPosted: Tue Nov 18, 2003 4:56 am    Post subject: Error 2110 when processing message from receive Q. URGENT!! Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

Hello,

We have the following environment:
10 POPS Client pc's, all with the same MQ client installed (5.2)
These pc's connect to the qmgr using PATEST.CLIENT server connection channel.
Via an application, they put a message in LOGBOOK.SEND.QUEUE.
This is an alias for LOGBOOK.RECEIVE.QUEUE on the same qmgr.

The put works.

Workstation LGBPGTW1 should read & interpret the message from the logbook.receive.Queue on the qmgr. This workstation connects to the qmgr with LGBPGTW1.CLIENT (with security exits installed, so only THIS client can connect to the qmgr, using this server connection channel)
This is also done via an application.

When we try that last step (which normally executes automatically), we get error 2110, 'Message format not valid.'.

Strangely enough, we DO NOT get the error if we send the message from another pc! We have not yet seen a diference between the pc's that send a 'correct' message and the ones that don't!

What I have tried is to look at a message sent by a POPS pc (that doesn't send it correctly). There I see the following values in 'data' tab:
- Message data length: 1527
- format: (empty)
- Coded character set ID: 850
- Encoding: 546

In the explanation about error 2110 I read '
Possible errors include:
- ...
- the format name in the message is MQFMT_NONE,
- the message contains data that is not consistent
with the format definition.

The format being 'empty', is that the same as MQFMT_NONE?
Maybe that's the problem. Where is decided what the format is? Is it while sending the message or ...?

Or maybe some1 has another possible solution?

Please some1 help me with this, as I'm a bit stuck here!

Tnx.
Gert.
Back to top
View user's profile Send private message
JasonE
PostPosted: Tue Nov 18, 2003 5:30 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

It probably is due to the format being blank.

Are both pc's in the same system locale? Perhaps one machine is ccsid 437 and the other 850? Compare the replies in both cases before the program tries to get them, and what is the difference?
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Tue Nov 18, 2003 5:32 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

JasonE:

Unfortunately, I can not do a test from another workstation, so I can't see what a 'correct' messages looks like.

How can I see the ccsid on a client? It it sent along with the message, is it in the registry, or...??

Tnx for your reply...
Back to top
View user's profile Send private message
JasonE
PostPosted: Tue Nov 18, 2003 5:45 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

All of the above... We query the console cp, and get a value from the registry if that fails, and put it in the message. Try running 'chcp' from a command prompt on the machine which generates the failing message, the machine which generates a message and it works, and the machine processing the message.

Quote:

Strangely enough, we DO NOT get the error if we send the message from another pc! We have not yet seen a diference between the pc's that send a 'correct' message and the ones that don't!


Are you saying you can no longer do this from another machine? That would be the simplest solution (ie generate one from working machine, one from failing machine and then amqsbcg the queue and compare the messages).
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Tue Nov 18, 2003 7:16 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

At the moment we can't check from another workstation, because the LGBPGTW1 workstation is back in production now.

Where in the registry can I find the FORMAT that is sent along with the messages sent from that workstation?
Maybe I can compare the value in the registry of a workstation with 'correct' messages, and of a workstation with 'incorrect' messages.

What exactly do you mean by 'we query the console CP'??

Tnx
Gert
Back to top
View user's profile Send private message
JasonE
PostPosted: Tue Nov 18, 2003 7:32 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Ah - ok.

The format is supplied by the putting application, and is purely an application issue, MQ will honour whatever you put in there.

The ccsid is the value returned from GetConsoleCP() call and if 0 we go off to the registry to look it up, I believe (talking from memory, could be wrong) - Thats why 'chcp' from a command line is useful info as its the same value in most cases.
Back to top
View user's profile Send private message
bower5932
PostPosted: Tue Nov 18, 2003 8:59 am    Post subject: Reply with quote

Jedi Knight

Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA

You can get the format of the message by using the shipped amqsbcg sample program. Any time you encounter errors about funny messages on the queue, amqsbcg is probably the first program to run so that you can see what the message actually looks like.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger
gertvangaever
PostPosted: Wed Nov 19, 2003 12:14 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

OK.
So to make sure I understood it right:

* When there's nothing filled in in the FORMAT field (also not when I try to read them with amqsbcgc), there's something wrong?
* MQFMT_NONE is the same as an empty FORMAT field?

Now where exactly can I find the FORMAT value in the registry?
The applications on the client PC's are exactly the same, so I guess the FORMAT value is from the registry!

For the CCSID; Is it possible to get this value from the registry? I cannot carry out commands on the client pc's, because they are in a production environment. But I cán query the registry!

Can you answer these last questions please?
Tnx
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Wed Nov 19, 2003 12:43 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

I have also noticed that on the
MQServer, the code page is 437,
on the client, the code page is 850,
and on the receiving client (that reads the messages from the LOGBOOK.RECEIVE.QUEUE), the code page is 473.

This was the same though, before we migrated the mqserver to win2000 & MQ5.2. And it worked then!
Back to top
View user's profile Send private message
JasonE
PostPosted: Wed Nov 19, 2003 2:30 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Nothing in the format fields means the MQ doesnt understand what is in the message and hence cannot provide data conversion. Its not a problem unless you ask for your messages to be converted. Having a different client and qmgr ccsid may cause data conversion to occur which would be the point in time you would see the problem you are seeing.

On the server, the consolecp is not as important as a runmqsc DIS QMGR CCSID, as you can change the ccsid the qmgr runs under.

Is the ccsid the same on the two clients where one gets it ok and one doesnt? To be honest to debug this I would probably need a trace of the working and failing clients, and the browses of the messages on the queue before they are either got or not - Anything else is guesswork.
Back to top
View user's profile Send private message
JasonE
PostPosted: Wed Nov 19, 2003 2:37 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

I just reread your last notes:

Quote:
I have also noticed that on the MQServer, the code page is 437,
on the client, the code page is 850,
and on the receiving client, the code page is 473.


So Do I understand correctly:
The "the receiving client" is the one which works (ie the code page is 473) and "the client" (the one which fails?), the code page is 850"?

If so that ties up with my last update, ie the working client and the server are the same cp so it doesnt do conversion and hence works.
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Wed Nov 19, 2003 3:20 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

The message is sent by a POPS client (we have 10) to the QMMVS queue manager. That POPS client has CP 850.
The server BEPUUMVS (with QM QMMVS) has CP 473.
The receiving client (which will read the message) has CP 437.
DIS QMGR CCSID gives me CP 437 as expected.

Are you sure (we think we are sure about this) that the problem lays in data conversion/character set.

When we run the receiving program on another client, it works (same client SENT the message). There are two differences between the original receiving client & this one: it has a CP 850 and is windows 2000 (while the original one, where we get the error, has WIN NT)

Maybe it has something to do with the conversion that doesn't work well on win NT? On Win 2000 - Regional Options, we can see 'code page conversion tabels', which I can't find in Win NT!?

Here is an amqsbcg from 2 messages that FAIL on the original receiving client:

C:\>amqsbcgc LOGBOOK.RECEIVE.QUEUE

AMQSBCG0 - starts here
**********************

MQOPEN - 'LOGBOOK.RECEIVE.QUEUE'


MQGET of message number 1
****Message descriptor****

StrucId : 'MD ' Version : 2
Report : 14336 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 850
Format : ' '
Priority : 0 Persistence : 1
MsgId : X'414D5120514D4D5653202020202020207BE2B83F2002B101'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : 'LOG.QUEUE '
ReplyToQMgr : 'QMMES1 '
** Identity Context
UserIdentifier : 'MQMcaUser '
AccountingToken :
X'1601051500000011461C61F27F754C0052CF12B607000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 'Version 2.1.0\UniBrowser.exe'
PutDate : '20031118' PutTime : '11033044'
ApplOriginData : ' '

GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'

**** Message ****

length - 1527 bytes

00000000: 4C4F 4742 4F4F 4B20 2020 2020 2020 2020 'LOGBOOK '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 3230 3033 3131 3138 2031 3230 3233 ' 20031118 12023'
00000040: 3430 3030 3031 3742 5253 2020 2020 2020 '4000017BRS '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000070: 2020 2020 2020 2020 2020 2020 2042 5253 ' BRS'
00000080: 5F41 544A 4F48 414E 2043 524F 4C4C 4554 '_ATJOHAN CROLLET'
00000090: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000A0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000B0: 2020 2020 2043 555F 5445 5354 5F49 5420 ' CU_TEST_IT '
000000C0: 2020 2020 4355 2054 6573 7420 4974 656D ' CU Test Item'
000000D0: 2050 726F 6475 6374 2020 2020 2020 2020 ' Product '
000000E0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000F0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000100: 2020 2020 2020 2020 3020 2020 2020 2020 ' 0 '
00000110: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000120: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000130: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000140: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000150: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000160: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000170: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000180: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000190: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001A0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001B0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001C0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001D0: 204D 4F44 4946 593A 2069 5F6E 723A 2743 ' MODIFY: i_nr:'C'
000001E0: 555F 5445 5354 5F49 5427 2020 2020 2069 'U_TEST_IT' i'

000001F0: 5F73 7562 6E75 6D3A 2727 2020 2020 2069 '_subnum:'' i'
00000200: 5F64 6573 6372 3A27 4355 2054 6573 7420 '_descr:'CU Test '
00000210: 4974 656D 2050 726F 6475 6374 2720 2020 'Item Product' '
00000220: 2020 695F 6661 6D3A 2754 5354 2720 2020 ' i_fam:'TST' '
00000230: 2020 6675 6E63 3A27 2720 2020 2020 7365 ' func:'' se'
00000240: 6E74 3A46 616C 7365 2020 2020 2069 5F73 'nt:False i_s'
00000250: 746F 636B 3A27 2720 2020 2020 695F 696E 'tock:'' i_in'
00000260: 6C69 6E65 3A27 2720 2020 2020 7369 6E67 'line:'' sing'
00000270: 5F69 6E73 703A 4661 6C73 6520 2020 2020 '_insp:False '
00000280: 695F 696E 7370 3A27 2720 2020 2020 695F 'i_insp:'' i_'
00000290: 6669 6C6C 7467 3A32 2020 2020 2074 725F 'filltg:2 tr_'
000002A0: 7061 6C3A 3020 2020 2020 7366 705F 7472 'pal:0 sfp_tr'
000002B0: 6179 3A30 2020 2020 2073 6670 5F72 6F77 'ay:0 sfp_row'
000002C0: 3A30 2020 2020 2071 615F 6C6F 743A 3020 ':0 qa_lot:0 '
000002D0: 2020 2020 7161 5F73 7562 6C6F 743A 3020 ' qa_sublot:0 '
000002E0: 2020 2020 7265 635F 6C69 6D3A 3020 2020 ' rec_lim:0 '
000002F0: 2020 6D61 785F 6469 6666 3A30 2020 2020 ' max_diff:0 '
00000300: 2061 6B74 5F74 726F 3A30 2020 2020 2062 ' akt_tro:0 b'
00000310: 616C 3A30 2020 2020 2062 766C 3A30 2020 'al:0 bvl:0 '
00000320: 2020 2062 7268 3A30 2020 2020 2074 6172 ' brh:0 tar'
00000330: 6765 743A 3020 2020 2020 6F72 683A 3020 'get:0 orh:0 '
00000340: 2020 2020 6F76 6C3A 3020 2020 2020 6F61 ' ovl:0 oa'
00000350: 6C3A 3020 2020 2020 6672 6571 7565 6E74 'l:0 frequent'
00000360: 6965 3A30 2020 2020 2061 616E 745F 706F 'ie:0 aant_po'
00000370: 6D70 3A30 2020 2020 2076 756C 6C69 6A6E 'mp:0 vullijn'
00000380: 3A27 2720 2020 2020 6465 7374 7275 633A ':'' destruc:'
00000390: 5472 7565 2020 2020 2063 616C 635F 6C69 'True calc_li'
000003A0: 6D3A 5472 7565 2020 2020 2063 616C 635F 'm:True calc_'
000003B0: 6661 6374 3A30 2020 2020 2061 6B74 6976 'fact:0 aktiv'
000003C0: 6974 6569 743A 3130 2020 2020 2063 755F 'iteit:10 cu_'
000003D0: 6261 6C3A 3136 302C 3520 2020 2020 6375 'bal:160,5 cu'
000003E0: 5F75 6C3A 3135 3620 2020 2020 6375 5F74 '_ul:156 cu_t'
000003F0: 6172 3A31 3530 2020 2020 2063 755F 6C6C 'ar:150 cu_ll'
00000400: 3A31 3434 2020 2020 2063 755F 6F61 6C3A ':144 cu_oal:'
00000410: 3133 392C 3520 2020 2020 6375 5F66 6163 '139,5 cu_fac'
00000420: 746F 723A 302C 3739 3136 2020 2020 2063 'tor:0,7916 c'
00000430: 755F 6161 6E74 3A31 2020 2020 2063 755F 'u_aant:1 cu_'
00000440: 6D65 7468 6F64 3A30 2020 2020 2063 755F 'method:0 cu_'
00000450: 7365 7167 7261 3A30 2020 2020 2063 755F 'seqgra:0 cu_'
00000460: 7365 7164 656E 3A30 2020 2020 2066 6C65 'seqden:0 fle'
00000470: 7374 7970 3A30 2020 2020 2066 6F63 7573 'styp:0 focus'
00000480: 3A46 616C 7365 2020 2020 2072 6F75 7469 ':False routi'
00000490: 6E67 3A27 2720 2020 2020 6161 6E74 6664 'ng:'' aantfd'
000004A0: 643A 3020 2020 2020 616D 3A46 616C 7365 'd:0 am:False'
000004B0: 2020 2020 2065 6973 6169 3A27 2720 2020 ' eisai:'' '
000004C0: 2020 655F 6765 766F 656C 3A30 2020 2020 ' e_gevoel:0 '
000004D0: 2065 5F67 6576 6F65 6C5F 623A 3020 2020 ' e_gevoel_b:0 '
000004E0: 2020 655F 7370 696E 3A30 2020 2020 2065 ' e_spin:0 e'
000004F0: 5F74 7964 7369 6E64 3A30 2020 2020 2065 '_tydsind:0 e'
00000500: 5F76 756C 686F 6F67 3A27 2720 2020 2020 '_vulhoog:'' '
00000510: 6B64 6C5F 6E72 5F70 676D 3A27 2720 2020 'kdl_nr_pgm:'' '
00000520: 2020 6B64 6C5F 736E 656C 683A 3020 2020 ' kdl_snelh:0 '
00000530: 2020 6B64 6C5F 7669 6272 6174 3A27 2720 ' kdl_vibrat:'' '
00000540: 2020 2020 6664 5F70 726F 673A 3020 2020 ' fd_prog:0 '
00000550: 2020 6873 6C5F 6265 6C74 3A30 2020 2020 ' hsl_belt:0 '
00000560: 206C 706C 5F63 6F5F 7A6E 3A30 2020 2020 ' lpl_co_zn:0 '
00000570: 206C 746C 5F68 6F5F 7A6E 3A30 2020 2020 ' ltl_ho_zn:0 '
00000580: 206C 666C 5F69 6E5F 7A6E 3A30 2020 2020 ' lfl_in_zn:0 '
00000590: 206C 666C 5F68 6F5F 7A6E 3A30 2020 2020 ' lfl_ho_zn:0 '
000005A0: 206C 666C 5F63 6F5F 7A6E 3A30 2020 2020 ' lfl_co_zn:0 '

000005B0: 2068 7A5F 6465 6C61 793A 3020 2020 2020 ' hz_delay:0 '
000005C0: 6870 6C5F 6973 6F6C 3A30 2020 2020 206C 'hpl_isol:0 l'
000005D0: 666C 5F69 736F 6C3A 3020 2020 2020 6B70 'fl_isol:0 kp'
000005E0: 6C5F 6973 6F6C 3A30 2020 2020 2066 6C65 'l_isol:0 fle'
000005F0: 7374 7970 653A 30 'stype:0 '


MQGET of message number 2
****Message descriptor****

StrucId : 'MD ' Version : 2
Report : 14336 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 850
Format : ' '
Priority : 0 Persistence : 1
MsgId : X'414D5120514D4D5653202020202020207BE2B83F20055601'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : 'LOG.QUEUE '
ReplyToQMgr : 'QMMES1 '
** Identity Context
UserIdentifier : 'MQMcaUser '
AccountingToken :
X'1601051500000011461C61F27F754C0052CF12B607000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 'Version 2.1.0\UniBrowser.exe'
PutDate : '20031119' PutTime : '07323926'
ApplOriginData : ' '

GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'

**** Message ****

length - 1527 bytes

00000000: 4C4F 4742 4F4F 4B20 2020 2020 2020 2020 'LOGBOOK '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 3230 3033 3131 3139 2030 3833 3134 ' 20031119 08314'
00000040: 3330 3030 3031 3742 5253 2020 2020 2020 '3000017BRS '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000070: 2020 2020 2020 2020 2020 2020 2042 5253 ' BRS'
00000080: 5F41 544A 4F48 414E 2043 524F 4C4C 4554 '_ATJOHAN CROLLET'
00000090: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000A0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000B0: 2020 2020 2043 555F 5445 5354 5F49 5420 ' CU_TEST_IT '
000000C0: 2020 2020 4355 2054 6573 7420 4974 656D ' CU Test Item'
000000D0: 2050 726F 6475 6374 2020 2020 2020 2020 ' Product '
000000E0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000F0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000100: 2020 2020 2020 2020 3020 2020 2020 2020 ' 0 '
00000110: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000120: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000130: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000140: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000150: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000160: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000170: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000180: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000190: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001A0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001B0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001C0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000001D0: 204D 4F44 4946 593A 2069 5F6E 723A 2743 ' MODIFY: i_nr:'C'
000001E0: 555F 5445 5354 5F49 5427 2020 2020 2069 'U_TEST_IT' i'
000001F0: 5F73 7562 6E75 6D3A 2727 2020 2020 2069 '_subnum:'' i'
00000200: 5F64 6573 6372 3A27 4355 2054 6573 7420 '_descr:'CU Test '
00000210: 4974 656D 2050 726F 6475 6374 2720 2020 'Item Product' '
00000220: 2020 695F 6661 6D3A 2754 5354 2720 2020 ' i_fam:'TST' '
00000230: 2020 6675 6E63 3A27 2720 2020 2020 7365 ' func:'' se'
00000240: 6E74 3A46 616C 7365 2020 2020 2069 5F73 'nt:False i_s'
00000250: 746F 636B 3A27 2720 2020 2020 695F 696E 'tock:'' i_in'

00000260: 6C69 6E65 3A27 2720 2020 2020 7369 6E67 'line:'' sing'
00000270: 5F69 6E73 703A 4661 6C73 6520 2020 2020 '_insp:False '
00000280: 695F 696E 7370 3A27 2720 2020 2020 695F 'i_insp:'' i_'
00000290: 6669 6C6C 7467 3A31 2020 2020 2074 725F 'filltg:1 tr_'
000002A0: 7061 6C3A 3020 2020 2020 7366 705F 7472 'pal:0 sfp_tr'
000002B0: 6179 3A30 2020 2020 2073 6670 5F72 6F77 'ay:0 sfp_row'
000002C0: 3A30 2020 2020 2071 615F 6C6F 743A 3020 ':0 qa_lot:0 '
000002D0: 2020 2020 7161 5F73 7562 6C6F 743A 3020 ' qa_sublot:0 '
000002E0: 2020 2020 7265 635F 6C69 6D3A 3020 2020 ' rec_lim:0 '
000002F0: 2020 6D61 785F 6469 6666 3A30 2020 2020 ' max_diff:0 '
00000300: 2061 6B74 5F74 726F 3A30 2020 2020 2062 ' akt_tro:0 b'
00000310: 616C 3A30 2020 2020 2062 766C 3A30 2020 'al:0 bvl:0 '
00000320: 2020 2062 7268 3A30 2020 2020 2074 6172 ' brh:0 tar'
00000330: 6765 743A 3020 2020 2020 6F72 683A 3020 'get:0 orh:0 '
00000340: 2020 2020 6F76 6C3A 3020 2020 2020 6F61 ' ovl:0 oa'
00000350: 6C3A 3020 2020 2020 6672 6571 7565 6E74 'l:0 frequent'
00000360: 6965 3A30 2020 2020 2061 616E 745F 706F 'ie:0 aant_po'
00000370: 6D70 3A30 2020 2020 2076 756C 6C69 6A6E 'mp:0 vullijn'
00000380: 3A27 2720 2020 2020 6465 7374 7275 633A ':'' destruc:'
00000390: 5472 7565 2020 2020 2063 616C 635F 6C69 'True calc_li'
000003A0: 6D3A 5472 7565 2020 2020 2063 616C 635F 'm:True calc_'
000003B0: 6661 6374 3A30 2020 2020 2061 6B74 6976 'fact:0 aktiv'
000003C0: 6974 6569 743A 3130 2020 2020 2063 755F 'iteit:10 cu_'
000003D0: 6261 6C3A 3136 302C 3520 2020 2020 6375 'bal:160,5 cu'
000003E0: 5F75 6C3A 3135 3620 2020 2020 6375 5F74 '_ul:156 cu_t'
000003F0: 6172 3A31 3530 2020 2020 2063 755F 6C6C 'ar:150 cu_ll'
00000400: 3A31 3434 2020 2020 2063 755F 6F61 6C3A ':144 cu_oal:'
00000410: 3133 392C 3520 2020 2020 6375 5F66 6163 '139,5 cu_fac'
00000420: 746F 723A 302C 3739 3136 2020 2020 2063 'tor:0,7916 c'
00000430: 755F 6161 6E74 3A31 2020 2020 2063 755F 'u_aant:1 cu_'
00000440: 6D65 7468 6F64 3A30 2020 2020 2063 755F 'method:0 cu_'
00000450: 7365 7167 7261 3A30 2020 2020 2063 755F 'seqgra:0 cu_'
00000460: 7365 7164 656E 3A30 2020 2020 2066 6C65 'seqden:0 fle'
00000470: 7374 7970 3A30 2020 2020 2066 6F63 7573 'styp:0 focus'
00000480: 3A46 616C 7365 2020 2020 2072 6F75 7469 ':False routi'
00000490: 6E67 3A27 2720 2020 2020 6161 6E74 6664 'ng:'' aantfd'
000004A0: 643A 3020 2020 2020 616D 3A46 616C 7365 'd:0 am:False'
000004B0: 2020 2020 2065 6973 6169 3A27 2720 2020 ' eisai:'' '
000004C0: 2020 655F 6765 766F 656C 3A30 2020 2020 ' e_gevoel:0 '
000004D0: 2065 5F67 6576 6F65 6C5F 623A 3020 2020 ' e_gevoel_b:0 '
000004E0: 2020 655F 7370 696E 3A30 2020 2020 2065 ' e_spin:0 e'
000004F0: 5F74 7964 7369 6E64 3A30 2020 2020 2065 '_tydsind:0 e'
00000500: 5F76 756C 686F 6F67 3A27 2720 2020 2020 '_vulhoog:'' '
00000510: 6B64 6C5F 6E72 5F70 676D 3A27 2720 2020 'kdl_nr_pgm:'' '
00000520: 2020 6B64 6C5F 736E 656C 683A 3020 2020 ' kdl_snelh:0 '
00000530: 2020 6B64 6C5F 7669 6272 6174 3A27 2720 ' kdl_vibrat:'' '
00000540: 2020 2020 6664 5F70 726F 673A 3020 2020 ' fd_prog:0 '
00000550: 2020 6873 6C5F 6265 6C74 3A30 2020 2020 ' hsl_belt:0 '
00000560: 206C 706C 5F63 6F5F 7A6E 3A30 2020 2020 ' lpl_co_zn:0 '
00000570: 206C 746C 5F68 6F5F 7A6E 3A30 2020 2020 ' ltl_ho_zn:0 '
00000580: 206C 666C 5F69 6E5F 7A6E 3A30 2020 2020 ' lfl_in_zn:0 '
00000590: 206C 666C 5F68 6F5F 7A6E 3A30 2020 2020 ' lfl_ho_zn:0 '
000005A0: 206C 666C 5F63 6F5F 7A6E 3A30 2020 2020 ' lfl_co_zn:0 '
000005B0: 2068 7A5F 6465 6C61 793A 3020 2020 2020 ' hz_delay:0 '
000005C0: 6870 6C5F 6973 6F6C 3A30 2020 2020 206C 'hpl_isol:0 l'
000005D0: 666C 5F69 736F 6C3A 3020 2020 2020 6B70 'fl_isol:0 kp'
000005E0: 6C5F 6973 6F6C 3A30 2020 2020 2066 6C65 'l_isol:0 fle'
000005F0: 7374 7970 653A 30 'stype:0 '
Back to top
View user's profile Send private message
JasonE
PostPosted: Wed Nov 19, 2003 3:47 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Am I Sure about it being data conversion? I cant be certain without seeing a trace of both sides, but my gut feeling is it is the cause - I checked where we issue that r/c from and its not too many places, and conversion is the one which sticks out.

To be honest I cant understand how it ever works to another client, as I would always expect it to fail IF the clients are in a different codepage to the putting app and no format is set. It would be easiest to resolve by changing the putting application (UniBrowser) to stick a format of MQSTR (since the records look like strings). I also dont understand how it could have worked on a previous release, as nothing I know of has changed in this area.

If you can get a working and a failing trace, I can tell you why there is a difference, but I dont believe you are in a position to do so. If you can get a failing trace (not server and client) then I can probably tell you what causes the failure, but I do believe it is that issue. I do know for certain that if you raise a problem with service, this will be one of the first thing asked for (working vs failing).
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Wed Nov 19, 2003 4:48 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

So if this is the problem, there should be 2 possible solutions?

- fill in the FORMAT parameter on the SENDING client
- change the code page of the receiving client or sending client

I don't quite understand what the FORMAT parameter has to do with the code page conversion.
The receiving client (CP 437) can't read a message from the sending client (CP 850), so there should be some kind of code page conversion. Why would this conversion work if the FORMAT is filled in, with, for example, MQSTR?

Tnx
Back to top
View user's profile Send private message
gertvangaever
PostPosted: Wed Nov 19, 2003 4:50 am    Post subject: Reply with quote

Apprentice

Joined: 28 Apr 2003
Posts: 35
Location: Puurs, Belgium

[quote="JasonE"] To be honest I cant understand how it ever works to another client, as I would always expect it to fail IF the clients are in a different codepage to the putting app and no format is set. [/quote]

It works on a receiving client with code page 850, so the same CP as the sending client. The QMGr is CP 437 though
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » Error 2110 when processing message from receive Q. URGENT!!
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.