Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error 2110 'sometimes' when reading a message. URGENT!

Status
Not open for further replies.

gertvangaever

Technical User
Apr 3, 2002
37
0
0
BE
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.

 
If you check the pre-defined values for MQFMT_*, you will see that MQFMT_NONE equates to blanks (or empty). You should also see the available values. IMHO, it is not good practice to rely on default values, and you should set a value in this MQMD field. For most applications MQFMT_STRING is appropriate.

Are all the codepages for the POPs clients the same as the server codepage - could this be a conversion issue?

Garry.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top