MQ 9.1.0.4 / RHEL 7

 
If I hard code a value in the MCAUSER field of a RCVR or CLUSRCVR channel (and there are no Exits or CHLAUTH rules to change that), the channel fails to enter RUNNING status with corresponding Authority Events and entries in the AMQERR01.LOG saying it's not authorized. This is expected.

If the channel is Inactive, no messages are waiting in the XMITQ and I go to the sending side to manually start the channel, the channel starts. Looking at the receiving end the channel status shows running and the MCAUSER is the value that does not have any authority whatsoever on the receiving queue manager.

 

Is this working as designed? Documented?

My memory is that the MQCONN check for a channel happens while a channel is running as mqm, before the MCAUSER is adopted for use  for the remainder of the life of the channel. This means that until you have a message to put to a target queue, and the RCVR channel has to do an MQOPEN, not authority checks are made.

When you say you see authority failures in the AMQERR01.LOG in your post, what are they failures of?

I'm not sure whether this is documented or not. Usually I have a page in mind to go looking for in KC but not this time.

It does occur to me that, if this is as I remember, this effectively protects the user ids used as MCAUSERs from being used by an application - it can't make use of MQOPEN authorities, because it can't get past the MQCONN failure.

Hopefully someone else will chime in who remembers better than me,
Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
------------------------------

Original Message:
Sent: Sat April 11, 2020 01:42 PM
From: Peter Potkay
Subject: How can a RCVR channel with no access go to Running?

MQ 9.1.0.4 / RHEL 7

 
If I hard code a value in the MCAUSER field of a RCVR or CLUSRCVR channel (and there are no Exits or CHLAUTH rules to change that), the channel fails to enter RUNNING status with corresponding Authority Events and entries in the AMQERR01.LOG saying it's not authorized. This is expected.

If the channel is Inactive, no messages are waiting in the XMITQ and I go to the sending side to manually start the channel, the channel starts. Looking at the receiving end the channel status shows running and the MCAUSER is the value that does not have any authority whatsoever on the receiving queue manager.

 

Is this working as designed? Documented?

------------------------------

Peter Potkay
------------------------------

The Authority Error related log entry on the receiving QM is shown below as well as one of the Authority Event messages from the SYSTEM.ADMIN.QMGR.EVENT queue.

 

There is one log entry like that every time the channel retries.

There is one of these Authority Event for every message in the batch. Interesting – not one Authority Event message per channel retry, one per every message in the batch per channel retry. And it's an error not for an OPEN, but for a CONN. So why wouldn't that same error be thrown on a CONN when the channel is starting with no messages to move?

 

I get enabled the XMITQ, cleared the messages in the XMITQ, and did nothing else.

On the next channel retry, the channel started and went into running mode!

Putting just one message at this time caused the channel to immediately go into retrying mode.

 

 

OK, I get it, no messages can successfully pass, so that's good. But the fact the channel even starts (with no messages to process) seems odd to me.

 

 

04/12/2020 10:39:07 AM - Process(2447.54236) User(mqm) Program(amqrmppa)

                    Host(ThisHost) Installation(Installation1)

                    VRMF(9.1.0.4) QMgr(ThisQM)

                    Time(2020-04-12T14:39:07.168Z)

                    ArithInsert1(2) ArithInsert2(2035)

                    CommentInsert1(DO_NOT_ALLOW)

                  

AMQ9557E: Queue Manager User ID initialization failed for 'DO_NOT_ALLOW'.

EXPLANATION:

The call to initialize the User ID 'DO_NOT_ALLOW' failed with CompCode 2 and

Reason 2035. If an MQCSP block was used, the User ID in the MQCSP block was ''.

If a userID flow was used, the User ID in the UID header was '' and any CHLAUTH

rules applied prior to user adoption were evaluated case-sensitively against

this value.

ACTION:

Correct the error and try again.

 

 

 

[  540 bytes] Event Header (MQCFH)

Type         :7 (Event)

Struc Length :36

Version      :1

Command      :44 (QMgr Event)

Sequence No. :1

Control      :1 (Last)

CompCode     :1 (Warning)

Reason       :2035 (Not authorized.)

Parm Count   :7

[  504 bytes] String (MQCFST)

Type         :4 (String)

Struc Length :68

Parameter Id :2015 (QMgr Name)

CCSID        :0

String Length:48

Value        :ThisQM                                        '

[  436 bytes] Integer (MQCFIN)

Type         :3 (Integer)

Struc Length :16

Parameter Id :1020 (Reason Qualifier)

Value        :1 [0x'1'] MQRQ_CONN_NOT_AUTHORIZED

[  420 bytes] String (MQCFST)

Type         :4 (String)

Struc Length :32

Parameter Id :3025 (User Identifier)

CCSID        :0

String Length:12

Value        :'DO_NOT_ALLOW'

[  388 bytes] Integer (MQCFIN)

Type         :3 (Integer)

Struc Length :16

Parameter Id :1 (Appl Type)

Value        :7 [0x'7'] MQAT_QMGR

[  372 bytes] String (MQCFST)

Type         :4 (String)

Struc Length :48

Parameter Id :3024 (Appl Name)

CCSID        :0

String Length:28

Value        :'                            '

[  324 bytes] String (MQCFST)

Type         :4 (String)

Struc Length :40

Parameter Id :3501 (Channel Name)

CCSID        :0

String Length:20

Value        :'ThatQM.ThisQM   '

[  284 bytes] String (MQCFST)

Type         :4 (String)

Struc Length :284

Parameter Id :3506 (Connection Name)

CCSID        :0

String Length:264

Value        :'IP.Address.Was.Here.....................................................................'

              '...................................................................................'

              '...................................................................................'

              '...............'

 

 

I think I figured it out.

 

It looks like a RCVR or CLUSRCV channel that starts with no messages to move (sending side issued a START CHANNEL) does not actually connect to the queue manager. The QM's Connection List does not show any evidence of a channel running like this. If it's not connecting to the QM, it's not doing Authority checking and so the MCAUSER value is irrelevant.

 

As soon as it has one message to move, only then does it attempts to connect to the QM.