| Author |
Message
|
| sfari |
 Posted: Mon Aug 09, 2004 12:53 am Post subject: Put Message Structure |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
With tracing the message I found out that the message structure of a put call looks like:
| Code: |
TSH... (44 bytes, TSH header)
MD... (364 bytes, MQMD header)
PMO... (132 bytes, MQPMO header)
... (Message content)
|
Can somebody tell me how the structure of the TSH header looks like. The only thing I found in the documentation was that the tenth byte indicates the call type.
Any help will be appreciated!
Silvano |
|
| Back to top |
|
 |
| marco |
| Posted: Mon Aug 09, 2004 2:30 am Post subject: |
|
|
Apprentice
Joined: 16 Feb 2004
Posts: 46
|
Hi,
I'm afraid it's IBM only.
I've also done some experimenting and the TSH changes in length.
So beware to assume that is 't always 44 bytes ! |
|
| Back to top |
|
|
| sfari |
| Posted: Mon Aug 09, 2004 3:12 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Does this mean that it is impossible to manipulate fields in the MQMD header (eg. changing a UserId) in a SendExit?
I made lot of tests with different MQ put calls and the TSH was always 44 Bytes. Is it really possible that it has differences between different put calls or put segments? |
|
| Back to top |
|
|
| marco |
| Posted: Mon Aug 09, 2004 3:22 am Post subject: |
|
|
Apprentice
Joined: 16 Feb 2004
Posts: 46
|
I did my tests with MQ5.2,
maybe the size is fixed as of MQ5.3.
The best thing to do is to search for the MQMD_STRUC_ID I guess.
Maybe you should take a look at the API-exits, I think they are more suitable for this purpose. |
|
| Back to top |
|
|
| sfari |
| Posted: Mon Aug 09, 2004 3:28 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Thanks for your proposal of parsing for the MQMD_STRUC_ID, good Idea.
I know that an API exit or probably even a message exit would be more suitable for this purpose. But my Client is written with JMS. Since there are no API or message exits for Java I have no other choice than to use a SendExit.
My SendExit will be used only for MQ 5.3. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 09, 2004 2:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I see you are referring to changing the userid of a JMS client.
How is the connection created in JMS ?
Typicall = qcf.createConnection()
Alternate passing userid
qcf.createConnection(userid,pwd)
Have you researched the differences between the two and do you think this might help? / or do you need a different userid / passwd than the user connecting?
Are you connecting in bindings mode or in client mode?
I believe on Unix machines and with Java/JMS the alternate form is only allowed in client mode connection.
 |
|
| Back to top |
|
|
| sfari |
| Posted: Mon Aug 09, 2004 10:28 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Yes I need to set a different userid than the connecting one.
I have Servlets and EJBs and the message needs to contain the userid of the person behind the session (EJB: sessionContext.getCallerPrincipal().getName(), Servlet: request.getUserPrincipal().getName()). But no alternative user authentication has to be used because these users are not unix users.
So my idea was to set this userid into the MQMD in a SendExit using a specific byte offset and manipulate that bytes. (The userid is passed with a ThreadLocal to the SendExit.) That's why the length of the TSO is important for me to know.
Are there better possibities? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 10, 2004 7:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you checked the mapping from JMS to MQMD in the using java manual.
Tried out any?
With what success / problems ?
Enjoy |
|
| Back to top |
|
|
| markt |
| Posted: Tue Aug 10, 2004 8:55 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Even if you could set the fields in the MQMD it wouldn't help you on a client connection, as the qmgr sets them based on the userid discovered/set during MQCONN. It will overwrite anything that's sent up the wire. (Unless you are also using the altusr context-setting flags.) |
|
| Back to top |
|
|
| sfari |
| Posted: Thu Aug 12, 2004 2:35 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Actually if you set MQOO_SET_IDENTITY_CONTEXT on the open call and MQPMO_SET_IDENTITY_CONTEXT on the put call you can set the userId at the client and it will not be overwritten by the QM.
MQOO_ALTERNATE_USER_AUTHORITY_OFFSET and MQPMO_ALTERNATE_USER_AUTHORITY can be set (but are not required) additionally if you also want to the autorization made with the set userId.
I checked the JMS - MQ mapping the userId is set by the JMS provider and can not be set by the JMS client. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 12, 2004 2:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Page 236 of the using Java Manual:
Property name JMSXUserID maps to MQMD user identifier !
Did you try it out ? What permissions with ? |
|
| Back to top |
|
|
| sfari |
| Posted: Fri Aug 13, 2004 1:01 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
That's correct the JMSXUserID maps to the userId in the MQMD. But for a programmer this is a read only field. It is set by the send method of the provider. Per default it gets set to mqm.
No idea why it can't be set by the programmer and wy it is set to mqm per default? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Aug 13, 2004 8:14 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| Quote: |
| JMSXUserID maps to the userId in the MQMD. But for a programmer this is a read only field. |
Correct.
Start JMSAdmin tool and go to your QCF object. The QCF has an attribute called 'ClientID'. Set it to the UserID that you want to be used in the MQMD.UserID field.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Sep 15, 2004 10:02 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Correction to my comments. I just discovered that ClientID is only valid for non 'point to point' JMS messages. Ahhh....
But I just found the the createQueueConnection() method of the QCF will properly set the MQMD UserID field.
| Code: |
| connection = cf.createQueueConnection("ROGER", null); |
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Sep 21, 2004 7:00 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
This concept does follow the Idea that each user owns a connection. When you are using Servlet you might want that multiple sessions belonging to different users share the same connection.
Do we really need to program a custom solution fo such a scenario?
Regards
Silvano |
|
| Back to top |
|
|
|
|
