| Author |
Message
|
| Vanshul_MB |
 Posted: Mon Jul 04, 2011 8:12 pm Post subject: RFHUtil error |
 |
|
Acolyte
Joined: 09 Feb 2011
Posts: 68
|
Hi,
I am getting an error
09.36.52 *Error cc=1 rc=2119 Cannot StartBr
*Error cc=1 rc=2119 Cannot Get (Browse)
only for a queue on our remote queue manager.It was fine till Friday but suddenly showing this.
Could you please help. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jul 04, 2011 8:24 pm Post subject: Re: RFHUtil error |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vanshul_MB wrote: |
Hi,
I am getting an error
09.36.52 *Error cc=1 rc=2119 Cannot StartBr
*Error cc=1 rc=2119 Cannot Get (Browse)
only for a queue on our remote queue manager.It was fine till Friday but suddenly showing this.
Could you please help. |
Something changed in your data or environment
| Quote: |
2119 (0847): MQRC_NOT_CONVERTED
Explanation
An MQGET call was issued with the MQGMO_CONVERT option specified in the GetMsgOpts parameter, but an error occurred during conversion of the data in the message. The message data is returned unconverted, 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.
This error may also indicate that a parameter to the data-conversion service is not supported.
Completion Code
MQCC_WARNING
Programmer response
Check that the message data is correctly described by the Format, CodedCharSetId and Encoding parameters that were specified when the message was put. Also check that these values, and the CodedCharSetId and Encoding specified in the MsgDesc parameter on the MQGET call, are supported for queue-manager conversion. If the required conversion is not supported, conversion must be carried out by the application.
|
The error message is pretty complete... including programmer response.
So what have you done, besides asking for help here? 
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Jul 04, 2011 8:25 pm; edited 1 time in total |
|
| Back to top |
|
|
| Vanshul_MB |
| Posted: Mon Jul 04, 2011 8:25 pm Post subject: |
|
|
Acolyte
Joined: 09 Feb 2011
Posts: 68
|
I deleted and recreated the queue
Its fine now |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 04, 2011 8:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vanshul_MB wrote: |
I deleted and recreated the queue
Its fine now |
No it's probably not.
Unless you tested with the exact same message that gave you the previous response.
This may well be data sensitive. Deleting and recreating the queue will have purged it of any existing messages and as such may have removed the condition.
You may also want to make sure you're at V 7.0.1.5
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vanshul_MB |
| Posted: Mon Jul 04, 2011 8:31 pm Post subject: |
|
|
Acolyte
Joined: 09 Feb 2011
Posts: 68
|
Actually somebody manually inserted message on queue with format as MQRFH2(dont know who and why?)
I just used DispalyQ and saw that its not our messages and stopped the EG group and deleted the messages and created queue again |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 04, 2011 8:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vanshul_MB wrote: |
Actually somebody manually inserted message on queue with format as MQRFH2(don't know who and why?)
I just used DisplayQ and saw that its not our messages and stopped the EG group and deleted the messages and created queue again |
Find out or it's going to happen again. You may have to implement security to prevent the culprit from putting any messages to that queue...
Are you sure that the messages with RFH2 were correctly formatted? Including CCSID of header and data part? The list of valid CCSID values for the property/value pairs is quite limited...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 05, 2011 7:21 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| Vanshul_MB wrote: |
| Actually somebody manually inserted message on queue with format as MQRFH2(dont know who and why?) |
If they used RFHUtil then you can look at the MQMD.User and MQMD.PutDateTime attributes to determine who and when the message was put to the queue. (That is, of course, if you didn't do something silly like hard-code a UserID in the channel's MCAUSER field.)
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 05, 2011 12:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| RogerLacroix wrote: |
(That is, of course, if you didn't do something silly like hard-code a UserID in the channel's MCAUSER field.)
|
Roger is being sarcastic (I hope) when he says that would be a "silly" thing to do.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Jul 07, 2011 7:04 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
People think that if they put a value in the channel's MCAUSER field that it is securing their channel. It is not (you are just giving everybody the same UserID). If the user wants to secure the channel then they need use either a security exit or SSL.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 07, 2011 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RogerLacroix wrote: |
| People think that if they put a value in the channel's MCAUSER field that it is securing their channel. |
Even more people think that leaving it blank is fine.
Whilst I agree absolutely with your assertion that setting MCAUser is by no means a complete security solution, I would describe it as "better than nothing" rather than "silly", as the latter has an implication that it shouldn't ever be done. At least if everyone has the same non-mqm user id via MCAUser you can keep them out of the SYSTEM queues. If you follow best practice and use 1 SVRCONN per application, you can prevent one application trampling another (and yes I know without SSL you can't prevent application A connecting to application B's SVRCONN!).
I'm just saying it's not a worthless exercise especially if Java's in use.
I'm also saying you're quite right that a channel with an MCAUser is not "secured". It's just "more secure" than one without.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Jul 07, 2011 7:58 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
95% of the people that don't understand MQ security will have a UserID as you suggested in the channel's MCAUSER field and also put it in the 'mqm' group. 
Without proper MQ security of either a security exit or SSL, (1) having a blank MCAUSER field or (2) having a UserID in the MCAUSER field, is like the movie 'Dumb and Dumber'. It is funny in the theater (or on DVD) but it is not funny in real life. And worse, they will happily tell their management that their MQ environment is secure.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 07, 2011 8:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RogerLacroix wrote: |
| 95% of the people that don't understand MQ security will have a UserID as you suggested in the channel's MCAUSER field and also put it in the 'mqm' group. |
I'd say the %age is nearer 50% but I take your point.
| RogerLacroix wrote: |
| Without proper MQ security of either a security exit or SSL, (1) having a blank MCAUSER field or (2) having a UserID in the MCAUSER field, is like the movie 'Dumb and Dumber'. |
I stand, with all possible respect, on my assertion that an MCAUser (which does not have mqm authority) is better than nothing even if it isn't full security. Which I agree it isn't.
| RogerLacroix wrote: |
| And worse, they will happily tell their management that their MQ environment is secure. |
I'll certainly agree that 95% of people with a non-mqm MCAUser will describe their environment as "secure". I can think of a couple of sites (which I'm legally obliged not to name) who pass monthly security audits on that basis.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 07, 2011 8:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
A blank MCAUSER means you are allowing the other end to administratively control your QM. Filling the value in is therefore not silly if the channel is not intended to allow this level of control to the remote end of the connection.
Use SSL or an Exit to control who can use the channel.
Fill in the MCAUSER with an ID with limited rights to control what they can do.
If the channel is using an MCAUSER with no access or such limited access that you don't care who uses it, then SSL or an Exit might be optional for that channel.
If the channel is meant to allow administrative control, then leave it blank, or code an ID that has mqm level access, but lock it down either way with SSL or an Exit.
Any level of access in between - code an MCAUSER with the appropriate level of access and use SSL /Exit to control who has access.
I know Vitor and Roger know this, just didn't want newbies reading this to think they should never code an MCAUSER value for fear of being "silly".
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 07, 2011 8:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| just didn't want newbies reading this to think they should never code an MCAUSER value for fear of being "silly". |
It was for exactly this reason I stuck my nose in
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jul 13, 2011 12:49 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| PeterPotkay wrote: |
| Use SSL or an Exit to control who can use the channel. |
Exactly. A UserID in the MCAUSER field of the channel is silly without using SSL or a security exit.
It is like going to an office building where everybody who gets off on floor "x" will all use the same name "abc". It is worst than the Waltons. i.e. If everybody who got off on the 5th floor used the name of "John Boy" then all you would hear is "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", "morning John Boy", etc... and everybody who gets off on the 6th floor use the name "Mary Ellen". i.e. "morning Mary Ellen", "morning Mary Ellen", "morning Mary Ellen", "morning Mary Ellen", "morning Mary Ellen", "morning Mary Ellen", "morning Mary Ellen", etc...
 
I wish IBM would remove the MCAUSER field from the channel. MQ is the ONLY middleware product that uses this strange concept. If you connect to a database or other middleware products, they do not have an equivalent field for the incoming connection (which in the case of MCAUSER, is totally misused). And to fix the issue of blank UserID being sent from the MQ client applications, simply have the MQ client library (native/.Net/Java) replace the blank UserID with "guest" UserID. The biggest security hole in MQ would be gone!!!!! 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
