In some of our queue managers, on z/OS, the initiation queue for a sender channel, is defined to kick off a process definition, which executes the CSQX START command for the sender channel.  I believe this method for starting the sender was setup a long time ago, yet it's not what I am used to.  The queue is setup to trigger on the first message with trigger depth of 1.

We had a situation where a sender channel disconnected, as per the disconnect interval defined for it, and even though some MQ/FTE jobs ran that should have caused it to start, the sender channel did not start up, until almost 40 minutes later, thus causing the FTE jobs to fail, as we use an ant script to run an fteping of the destination agent, to avoid the job just hanging, if there's problem in the mq/fte environment.  If the fteping fails, the ant script will stop the execution before submitting the actual file transfers.

The lpar was very busy that the time, that the channel should have started, so that could come into play.  The queue manager and channel initiator are defined to run with the highest priority, so as to not starve it from the cpu.

At the moment, we have updated the queue for that sender channel, to not kick off the process definition, but to directly start the sender channel, as is done on our Open systems queue managers.

My question is this.  Where is there any logging of the process executions, on z/OS, so we could see why it either failed, or was delayed so much?  Or it is just left to be a guessing game.  

Thanks

Peter

------------------------------
Peter Vander Woude
------------------------------

Hi Peter,

You are correct that a long long time ago, to trigger start a channel on MVS, you needed to refer to a PROCESS object in the transmission queue definition and that PROCESS object contained the command CSQX START to indicate that it was a channel that needed to be started. However, this was changed to allow channels to be triggered simply by having the channel name in the TRIGDATA just as on the distributed platforms. Both methods are valid, and both methods cause a trigger message to be placed on the SYSTEM.CHANNEL.INITQ which your CHIN task will pick up and act upon. 

The fact that the channel eventually started (you say after 40 minutes) tells me that the configuration in the trigger message was not in error and that therefore there must have been some delay. The main question is whether there was a delay in the CHIN task picking up the trigger message or whether there was a delay in the channel actually getting into RUNNING status. Given your statement about priority of the CHIN and MSTR jobs, the latter seems more likely.

You should review the CHIN joblog for this time period to look for channel messages related to this particular channel. Did it, for example, not manage to get started immediately because of some network issue, or perhaps because too many other channels were already running and it had to wait until one ended before it could start? There are a number of possibilities, all of which are covered by channel error messages written to the CHIN joblog.

I suggest you review that and if you need more help, paste in here the portion of the CHIN joblog that covers the time period in question so we can help you interpret the error messages that you see.

Cheers,
Morag

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

Morag,

Thanks for explaining that the process method was from way back.  My experience using MQ only goes back a few years, to around v7 timeframe, in my previous shop, but we weren't running sender/receiver channels there.  

As far as messages, there are no abnormal messages in the CHIN messages saying that there were any errors or delays.  For the most recent occurrence, I was able to go back using RMF to see how busy the lpar was, and I do believe it was running at least 95% busy, at the time.  Thought I'm not sure it was that busy the entire time, as I didn't follow through all the intervals.

At present, we have changed the queue for this sender channel to use, what is now, normal triggering of the channel.  We have a lot of other Process definitions to work through and I will let our main MQ guy know what you were able to let me know.

Thanks,

Peter

------------------------------
Peter Vander Woude
------------------------------

Original Message:
Sent: Sat April 25, 2026 07:24 PM
From: Morag Hughson
Subject: Logging of Process definition executions on z/OS

Hi Peter,

You are correct that a long long time ago, to trigger start a channel on MVS, you needed to refer to a PROCESS object in the transmission queue definition and that PROCESS object contained the command CSQX START to indicate that it was a channel that needed to be started. However, this was changed to allow channels to be triggered simply by having the channel name in the TRIGDATA just as on the distributed platforms. Both methods are valid, and both methods cause a trigger message to be placed on the SYSTEM.CHANNEL.INITQ which your CHIN task will pick up and act upon. 

The fact that the channel eventually started (you say after 40 minutes) tells me that the configuration in the trigger message was not in error and that therefore there must have been some delay. The main question is whether there was a delay in the CHIN task picking up the trigger message or whether there was a delay in the channel actually getting into RUNNING status. Given your statement about priority of the CHIN and MSTR jobs, the latter seems more likely.

You should review the CHIN joblog for this time period to look for channel messages related to this particular channel. Did it, for example, not manage to get started immediately because of some network issue, or perhaps because too many other channels were already running and it had to wait until one ended before it could start? There are a number of possibilities, all of which are covered by channel error messages written to the CHIN joblog.

I suggest you review that and if you need more help, paste in here the portion of the CHIN joblog that covers the time period in question so we can help you interpret the error messages that you see.

Cheers,
Morag

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

Morag,

As a follow-up, I looked in all of the sysout in both the CHIN and MSTR started tasks, I saw no CSQX command related output.

One item I did notice, that around the time that the channel started, the queue manager MSTR address space shows that a checkpoint was started for all buffer pools.  Though the checkpoint message was 9 seconds after the channel started, so it probably is not directly related, just a coincidence.

BTW, in reference to any SMF records, what audit/trace levels would need to be active for this?  Though I would expect that this might increase the SMF records, as I know that products like Omegamon for MQ, uses it's own queues for monitoring and will issue CSQX commands, via queues.

I do have the latest version of the MP1B supportpac, but not sure where in there I might find anything that would relate to the process execution.

Peter

------------------------------
Peter Vander Woude
------------------------------

Original Message:
Sent: Sat April 25, 2026 07:24 PM
From: Morag Hughson
Subject: Logging of Process definition executions on z/OS

Hi Peter,

You are correct that a long long time ago, to trigger start a channel on MVS, you needed to refer to a PROCESS object in the transmission queue definition and that PROCESS object contained the command CSQX START to indicate that it was a channel that needed to be started. However, this was changed to allow channels to be triggered simply by having the channel name in the TRIGDATA just as on the distributed platforms. Both methods are valid, and both methods cause a trigger message to be placed on the SYSTEM.CHANNEL.INITQ which your CHIN task will pick up and act upon. 

The fact that the channel eventually started (you say after 40 minutes) tells me that the configuration in the trigger message was not in error and that therefore there must have been some delay. The main question is whether there was a delay in the CHIN task picking up the trigger message or whether there was a delay in the channel actually getting into RUNNING status. Given your statement about priority of the CHIN and MSTR jobs, the latter seems more likely.

You should review the CHIN joblog for this time period to look for channel messages related to this particular channel. Did it, for example, not manage to get started immediately because of some network issue, or perhaps because too many other channels were already running and it had to wait until one ended before it could start? There are a number of possibilities, all of which are covered by channel error messages written to the CHIN joblog.

I suggest you review that and if you need more help, paste in here the portion of the CHIN joblog that covers the time period in question so we can help you interpret the error messages that you see.

Cheers,
Morag

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

Hi Peter,

Interesting setup - using a triggered process to issue a START CHANNEL via CSQX is definitely something you still see on older IBM MQ on z/OS, but as you've noticed, it can introduce some unpredictability under load.

Regarding your main question: unfortunately, there isn't a single "central" log specifically for process definition executions in the way you might expect. However, there are a few places you can check that together usually give a good picture:

• CHINIT job logs (JESMSGLG / JESJCL / JESYSMSG)
  These often show when the trigger monitor (channel initiator) processes the initiation queue and attempts to start the process. Delays under heavy CPU load can show up here indirectly.

• Queue manager logs (CSQLOG / active logs)
  If the START CHANNEL command was actually issued, you may see related activity or command processing entries.

• System log (SYSLOG / OPERLOG)
  Sometimes command execution via CSQX or related failures (authorization, resource issues) are recorded here.

• SMF records (especially type 116)
  If you have SMF enabled for MQ, this is one of the more reliable ways to trace what actually happened with triggers, channel starts, and delays.

From your description, the ~40 minute delay strongly suggests that the trigger was not processed immediately - likely due to system load or dispatching delays affecting the channel initiator, even if it has high priority. Triggering on depth 1 can also be sensitive to timing if the first event is missed or delayed.

Your change to start the sender channel directly (bypassing the process definition) is generally the more predictable and modern approach, especially for FTE workloads where timing is critical.

If you still want to validate root cause, I'd focus on correlating CHINIT logs with SMF 116 records around the delay window - that usually gives the clearest answer.

Thanks for raising this - it's a great example of how legacy trigger setups can behave under load.

------------------------------
Noor Fatima
------------------------------

Was this written by AI? The formatting and tone certainly sound like it, and the correctness of the content leaves a suspicious finger pointing in that direction too!

For example, "Your change to start the sender channel directly (bypassing the process definition) is generally the more predictable and modern approach" - no it isn't. Trigger starting is best practice. Manual start channel is not the "modern approach".

If there is evidence of PROCESS objects causing trigger setups to behave badly under load, please provide it. I have not heard of this. There are likely thousands of channels triggered this way on z/OS queue managers all over the world, just like Peter's, because they were set up that way back in MQSeries V1 and have never changed because they just worked. The change to the product to not need that any more was a simplification of definition idea, not an issue with the channel being started.

Trigger First is designed to ensure that if the trigger message generated for the transition from zero to one is part of a transaction that gets rolled back, then the trigger message is still forward completed, so that it isn't missed. Given that your channel did start, albeit 40 minutes later, we know that the trigger message did get produced and was correctly formed and could be correctly processed by the CHIN.

Anyway, just my rant. I do not want to see this forum taken over by incorrect AI answers. If you don't know that what AI is showing you is incorrect, don't post it on here as some kind of authoritative answer!

Cheers,
Morag

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

Original Message:
Sent: Sat April 25, 2026 07:12 AM
From: Noor Fatima
Subject: Logging of Process definition executions on z/OS

Hi Peter,

Interesting setup - using a triggered process to issue a START CHANNEL via CSQX is definitely something you still see on older IBM MQ on z/OS, but as you've noticed, it can introduce some unpredictability under load.

Regarding your main question: unfortunately, there isn't a single "central" log specifically for process definition executions in the way you might expect. However, there are a few places you can check that together usually give a good picture:

• CHINIT job logs (JESMSGLG / JESJCL / JESYSMSG)
  These often show when the trigger monitor (channel initiator) processes the initiation queue and attempts to start the process. Delays under heavy CPU load can show up here indirectly.

• Queue manager logs (CSQLOG / active logs)
  If the START CHANNEL command was actually issued, you may see related activity or command processing entries.

• System log (SYSLOG / OPERLOG)
  Sometimes command execution via CSQX or related failures (authorization, resource issues) are recorded here.

• SMF records (especially type 116)
  If you have SMF enabled for MQ, this is one of the more reliable ways to trace what actually happened with triggers, channel starts, and delays.

From your description, the ~40 minute delay strongly suggests that the trigger was not processed immediately - likely due to system load or dispatching delays affecting the channel initiator, even if it has high priority. Triggering on depth 1 can also be sensitive to timing if the first event is missed or delayed.

Your change to start the sender channel directly (bypassing the process definition) is generally the more predictable and modern approach, especially for FTE workloads where timing is critical.

If you still want to validate root cause, I'd focus on correlating CHINIT logs with SMF 116 records around the delay window - that usually gives the clearest answer.

Thanks for raising this - it's a great example of how legacy trigger setups can behave under load.

------------------------------
Noor Fatima
------------------------------