How to add an xMatters shout destination on mainframe table

Not Yet Reviewed

We used the instructions on github to install and set up xMatters to integrate with Control-M.  Using the instructions in section 5.1, I successfully added an xMatters destination on a distributed shout destination table. We figured out how to access the mainframe destination tables via the Control-M EM. However, I cannot find any documentation on how to add xMatters to a mainframe table. When I try to add xMatters to the table, Server is not an option for Address. There is only Group and Nick. The options for Destination are SNMPDEST, MAILDEST, IOADEST.

I cannot find any documentation on how to add an xMatters destination to a mainframe shout destination table.  Any ideas?



Date Votes

Please sign in to leave a comment.

  • Hey Julia!

        Well that's an interesting question. I'll see if I can dig up some details. Can you select Server for any other types of shout destinations? I'm wondering if it is just a limitation of the mainframe that can't execute commands?

    I can't seem to find any docs on Control-M Mainframe. Any idea where that shout destination documentation might reside? 

    Happy Monday!

  • I can select Server for our distributed shout destination tables.  I think you are right in that the mainframe cannot execute a bat file on a server.  

    Control-M for z/OS

    We are on Version 9.0.19

    The INCONTROL for z/OS has a section that explains the three types of shout destination tables, Dynamic (IOADEST), Mail (MAILDEST), and SNMP (SNMPDEST).  But it doesn't say how to set them up.  I am still searching.

  • Ok. Interesting. I reached out to a BMC colleague and his suggestions:

    1. Maybe try to modify the active Shout destination table:

    1. Or enter the destination name manually the first time:

    Give those a shot and if you're still stuck, open a ticket with BMC and drop me an email (tdepuy at xmatters . com) I can join a webex with them and we can see about getting it sorted out. 

  • Oh, if nothing else, does that MAILDEST send an email? We could set up an email trigger:

    This would bypass the Integration Agent and go directly to xMatters for generating the event. The responses would still go through the IA, but that shouldn't be a problem. I think.

  • Yes, MAILDEST sends an email to the address specified in the Control-M On Do Actions.

  • Also, I already tried modifying the active shout table.  That is my main problem.  I don't know how to add the xMatters destination to the mainframe shout table.

    Adding the destination name xMatters manually does not work if the destination is not in the active table.  It says Destination is invalid.

  • We figured out how to implement the SNMP Trap Technique and are able to send all Control-M alerts to xMatters. The problem now is figuring out how to get the various alerts to go to the right users. We want distributed alerts to go to one group, mainframe application alerts to another group, and mainframe system alerts to another group.

    An advantage of using the shout technique in Control-M is I can easily specify who to send each job's alert to.  On the mainframe side, we have all application jobs in one folder and all system jobs in another folder.

    I like your idea of setting up an email trigger.  Can you help me figure that out or point me to the right documentation?

  • Hi Julia,

    If you can just send an e-mail to xMatters to send a notification where the content of the message is in the e-mail body then you can set something up like this:

    like Travis said before. If you go through this and you can't quite figure it out let us know.

    Happy Wednesday!


  • I was discussing this with another colleague and he mentioned:

    The problem with using a MAILDEST is that the Integration Agent only receives limited information from ctrl-m, and then the IA uses the control-m API to ask for enrichment details.  

    So I think you might not get a whole lot of information out of the MAILDEST as with the other shout methods. 

    Were you able to get the mainframe alerts sent to xMatters using that SNMP trap technique? If so, I think that might be the most desirable way, and you can target the specific users with subscriptions. Or the IA code could be updated to add some logic to inspect the incoming message from Control-M and set the recipients. 

  • Thank you, Travis.  Yes, we got the SNMP trap technique working for mainframe alerts.

    I just barely received developer role permissions in xMatters, so I have a lot to learn.  I have been studying subscriptions but what work flow do I add them to?  We have several workflows in xMatters that must have been added when integrating Control-M.

    Modifying the IA code sounds good but I definitely need help with that.

  • According to the Control-M alert messages, we can identify the Control-M Server and the Application the job came from.  Seems like we should be able to direct the message to the right people using that information.

  • Oops, sorry. I was only showing enabled workflows.  I do have one of those.  It says "You do not have permission to view this workflow."  This always happens when I want to do something.

  • Travis, I was able to add subscriptions and tested.  They work the way I set them up.  Looks like i can do a lot more with the forms, so I will have fun doing that.

    Thank you so much for your help.

  • Awesome! Great to hear. Thanks for following up. Feel free to reach out if you run into any other issues!


Didn't find what you were looking for?

New post