MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Expand all | Collapse all

z/OS Batch Trigger Monitor

  • 1.  z/OS Batch Trigger Monitor

    Posted Tue October 17, 2023 04:44 PM

    Hi team, I work with MQ for long time and I remember that in sometime there were a sample with Cobol batch trigger monitor shared as supportpac. I've tried to find out Today and I found only Rexx application and the related documentation links are broken. How I can get an application sample of Batch MQ trigger monitor, please? 

    I really appreciate your input.

    Regards,

    Alex



    ------------------------------
    Alexandre Mendes de Assis
    ------------------------------


  • 2.  RE: z/OS Batch Trigger Monitor

    Posted Wed October 18, 2023 12:17 PM
      |   view attached

    Hi Alexander

    see attached file

    Tiziana Tizianel



    ------------------------------
    Tiziana Tizianel
    ------------------------------

    Attachment(s)

    zip
    ma12.zip   22 KB 1 version


  • 3.  RE: z/OS Batch Trigger Monitor

    Posted Wed October 18, 2023 12:29 PM

    Hello Tiziana, thank you very much for sharing!

    Regards,

    Alex



    ------------------------------
    Alexandre Mendes de Assis
    ------------------------------



  • 4.  RE: z/OS Batch Trigger Monitor

    Posted Mon October 23, 2023 12:53 AM

    I had a quick chat with some Hursley contacts and the response came back that MA12 was withdrawn in January 2020 and that there are no plans to make it available again.

    I see you have got a copy of it now (and I have also saved that copy!).

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 5.  RE: z/OS Batch Trigger Monitor

    Posted Mon October 23, 2023 01:54 AM

    Hi Morag, thanks for checking. I remember that I saw sometime this supportpac when I've started to work with MQ (V1.2) but I was not remember the supportpac. Again, thank you very much!

    Regards,

    Alex



    ------------------------------
    Alexandre Mendes de Assis
    ------------------------------



  • 6.  RE: z/OS Batch Trigger Monitor

    Posted 13 days ago

    Hi Morag,
    just curious: did they say why it is not available anymore? it seems a very useful support pack to me.
    Especially because the official manuals do provide other trigger monitors, and a Batch-version is lacking.
    Regards, Peter



    ------------------------------
    Peter de Wolf
    ------------------------------



  • 7.  RE: z/OS Batch Trigger Monitor

    Posted 13 days ago

    Hi Peter,

    No, they didn't say. All they were able to find out was what I quoted above. My memory doesn't recall who it was that originally created this Support Pac, but my guess would be that they are not there any more.

    Do you think there is a need for a fully supported version of a Batch Trigger Monitor?

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 8.  RE: z/OS Batch Trigger Monitor

    Posted 12 days ago

    Just curious from a design point of view. Wouldn't  the words batch and trigger monitor point to an anti-pattern?

    Either it is batch and then there is no need for a trigger monitor, or it is online, and then it should probably be written differently (as a CICS program) and can well be triggered.



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 9.  RE: z/OS Batch Trigger Monitor

    Posted 12 days ago
    Edited by Morag Hughson 12 days ago

    I guess whether it is an anti-pattern or not depends on whether you believe it is useful to automatically run a JCL invoked program (deliberately avoiding using the word 'batch" here) as a result of a message arriving on a queue.

    Another way to ask the question is whether all batch jobs are batch? How would you answer that one? Is it the name of the environment in which the program runs or the name of the type of processing system?

    Are all triggered programs considered "online" or does one trigger the start of the batch run? One is a invocation type and one is a processing type and they are not necessarily mutually exclusive.

    Would it be more appropriate to name this entity the "JCL Trigger Monitor"?

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 10.  RE: z/OS Batch Trigger Monitor

    Posted 12 days ago

    I like that name = 'JCL Trigger Monitor' 



    ------------------------------
    Lyn Elkins
    IBM
    Avon, IN
    elkinsc@us.ibm.com
    ------------------------------



  • 11.  RE: z/OS Batch Trigger Monitor

    Posted 11 days ago

    I believe that what we have here is a distinction without a difference.  

    JCL is a scripting language whose purpose is to start work, to start an application.  Isn't the same true of runmqtrrm?  
    "Batch' presupposes more than one transaction in the execution of the application.  Whether the started application processes one message, or two, or ten thousand, the processing logic (the main loop) is the same; and all this with effectively no interaction with an end-user. 
    'Online' implies a single main-loop interaction with an end-user..

    Another distinction without a difference is the flexibility (abstraction)  of both midrange and MVS o/s's to redirect input and output.  Midrange o/s's  use < > to 'allocate' the device, while MVS uses DD statements - this execution gats input from a keyboard, another execution from a disk/tape file. 

    A wide variety of job-schedulers now available may explain why the support pac is no longer supported. 



    ------------------------------
    bruce2359
    Consultant/trainer
    CTTECH - Computer & Telecommunications Technology
    West Coast, almost
    000-000-0000
    ------------------------------



  • 12.  RE: z/OS Batch Trigger Monitor

    Posted 10 days ago
    Edited by Wayne Myers 10 days ago

    Hi Bruce,

    Our site, and a few others that I've spoken to over the years, still uses the ZTM as a method to signal the job scheduling product that a batch job predecessor completed. If the batch job only has that one predecessor, it is immediately submitted. If the batch job has multiple preds, it will submit when all preds are met.

    When ready, an application will put a basic trigger message onto a Queue having a trigger process defined. That trigger process specifies the batch job name. The queue is defined with trigger data associating it to an initiation queue that the ZTM is monitoring. A trigger message WTO is then sent to the system log that is picked up by the job scheduling product and/or automation, specifying the message number, ZTM task, a message stating to submit job xxxxxxxx, the runtime environment, Queue Manager and Queue that received the trigger message. The message sits on that trigger queue until the batch job starts and clears the message. The trigger will automatically redrive every 5 minutes or so until the batch job is started and consumes that message. (Sort of like how a CICS transaction trigger will retry every several minutes until a transaction opens the queue.) 

    The ZTM approach provides a nice, consistent batch triggering mechanism that distributed applications a local host ones can use to signal when data is ready for processing--one that is not directly coupled to a scheduling product. The ZTM is still being used out in the field, now as user customized code.

    Cheers,

    Wayne



    ------------------------------
    Wayne Myers
    ------------------------------



  • 13.  RE: z/OS Batch Trigger Monitor

    Posted 11 days ago

    Even if you set aside Morag's point that the word "batch" can mean either the environment or the processing technique, there is still a valid use case for triggering with the batch processing pattern.
    Trigger on depth means that you can leave a queue with no application running until the queue depth reaches a certain point, and then trigger the application to process all the messages in a batch. 
    Since batch processing is generally used to achieve an efficiency, the choice to start your batch application by triggering in preference to another mechanism would depend on the efficiencies you're trying to achieve. If the aim of using a batch application is to run at a quiet time of day, then triggering won't help. If the aim is to avoid some overhead (e.g. opening and closing a connection to a back-end resource) for every message, then triggering the batch application is a good option.



    ------------------------------
    Doug Burns
    ------------------------------