Expand all | Collapse all

MQ in a non sysplex mainframe

  • 1.  MQ in a non sysplex mainframe

    Posted Mon June 01, 2020 12:41 PM

    We do not have a sysplex, so I was thinking about 2 queque managers in a cluster full repository on both, that way I can stop one of them and put maintenance on.

    Does this sound like a good idea ?


    We sill be sending messages to servers also.


    David Lawrence

    z/OS Systems Programming



    1 Primerica Parkway

    Duluth GA 30099

    (470) 564-7850


  • 2.  RE: MQ in a non sysplex mainframe

    Posted Tue June 02, 2020 07:43 PM
    Hi David,

    the magic number for full repositories in a cluster is really 2. Less than 2 causes availability issues when 1 fails (quite obviously).

    Less obviously, more than 2 causes unexpected (to most people) issues when more than 1 fails. This is because of the way that partial repository queue managers communicate to FRs. Partial Repo QMs only talk to 2 FRs, even if 3 or 4 or more are defined. So, if I have 3 FRs, and PR QM1 talks to FR1 and FR2, but QM2 talks to FR2 and FR3, and QM3 talks to FR1 and FR3, what happens if FR1 and FR2 go down.

    The simple viewpoint is everything should be fine, because you still have 1 FR running.

    However, QM1 doesn't talk to any FRs, so if it gets a QFull condition, or is suspended from the cluster, the other PR and FR queue managers don't find out, because the cluster update messages get stuck on the cluster transmission queue until FR1 or FR2 come back.

    Also, cluster full repo queue managers should always be at the highest software level of any queue manager in the cluster. This can be difficult to achieve with the FR on zOS, because most organisations don't want to be too aggressive with zOS software levels.

    My preferred topology is to install a special additional installation of MQ on a couple of midrange hosts (avoid extra licensing costs by using servers which already have MQ installed), and create dedicated FR queue managers using that installation. You can keep updating the special installation to keep it at the highest level without impacting any applications or needing to regression tests your apps.

    There are some other reasons to keep dedicated FRs too, especially if your cluster gets large. There is some overheads that an FR queue manager has related to repository maintenance that can cause cluster name resolution delays if you have applications using the same queue manager.


    Neil Casey.

    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-20
    +61 (0) 414 615 334