1) QMgr object defs,
2) Authorizations,
3) Contents of the qm.ini to capture channel, TCP and other tuning,
4) Contents of any exit directories and related parameter files,
5) SSL keyrings

Unfortunately, there is no easy way to capture some configuration tuning. For example, you can manipulate the queue buffer size by setting values in the qm.ini TuningParamater stanza prior to creating the queue. This setting is not exposed anywhere that can be queried after the fact, so far as I know, so it is very difficult to capture it and carry it forward to another QMgr instance.

If you need to tune at that level your documentation and processes are the only way to insure such tuning is captured and installed on, for example, the DR system. This is one instance where simply upgrading the license is a lot easier than rebuilding.

For critical cluster channels, I have been changing them to start a separate process. That way, they are isolated from any other channel that can cause an issue.

How can we setup, auto refresh when the queues are added, then the queeus are seen on MQ explorer.
Any idea.
Thanks
Om

Thanks!!

I think its more likely that because you are at MQ 6.0 at the new place you have less cluster problems. It wasn’t until the later fix packs of 5.3 that MQ clustering was stable.

Always use 2 and only Full Repositories. If you want to use more, there should be a technical reason why.

I’ve found your article to be very useful. For the record, here are steps I’ve taken to set up display only Explorer access on z/OS:

1) Define a new userid to be the MCAUSER for the SVRCONN channel that will get display only access (make sure the userid is not connected to a RACF group which has any access beyond that listed in the following bullets).

2) Grant the userid UPDATE access to the MQQUEUE class profile that controls access for each of these three queues (if these queues are currently protected by GENERIC profiles that provide access to many queues, you might need to define less GENERIC or fully qualified profiles so that access is limited to the queues listed here):
- SYSTEM.MQEXPLORER.REPLY.MODEL
- AMQ.* (the prefix of a temporary dynamic queue built from the previous queue)
- SYSTEM.COMMAND.INPUT (not sure, but the SYSTEM.ADMIN.COMMAND.QUEUE qalias might sometimes be used instead depending on the maintenance level).

3) Grant the userid READ access to the MQCMDS profiles that protect the DISPLAY commands

Regards,

Tom