MVS Agent Job execution takes 2 minutes instead of 2 seconds after upgrading to Automic Automation v24.4.3.

Products

• CA Automic Workload Automation - Automation Engine
• Automic SaaS

Issue/Introduction

After upgrading the z/OS (MVS) Agent from version 21 to 24.4.3, users may experience a significant performance degradation regarding job execution times.

A job that previously completed in approximately 2 seconds on version 21 may take up to 2 minutes to complete on version 24.4.3.

When reviewing the job reports and logs, delays of approximately 60-second intervals between the job starting, the agent reporting status 'R', and subsequently reporting status 'E' can be noticed.

Example log behavior from an affected environment:

20260210/104454.936 - U02000003 Job '<MVS_JOB_NAME>' started with RunID '<RunID>'. 
20260210/104555.201 - U02001013 Job '<RunID>', agent reported status 'R' for job, return code '0'. 
20260210/104655.590 - U02001013 Job '<RunID>', agent reported status 'E' for job, return code '0'. 
20260210/104655.882 - U02000008 Job '<MVS_JOB_NAME>' with RunID '<RunID>' ended normally. 

Environment

 

• Product: CA Automic Workload Automation - Automation Engine

• Component: MVS Agent (z/OS)

• Versions: 24.4.3 (including HF1)

• OS: z/OS 03.01.00

• Java: IBM Semeru Runtime Certified Edition for z/OS 17.0.17

 

Cause

This performance issue occurs due to a configuration discrepancy in the agent's INI file.

The affected configuration uses the value UCXJM25M for the job end assessment parameter, rather than the expected UC4START.

The UC4START value is specifically documented for recognizing and assessing job ends for OS/390 jobs.

Resolution

To resolve the execution delay, update the parameter in the MVS agent's INI file.

1. Open the MVS agent's INI file.

2. Locate or add the UC_EX_JOB_MD parameter.

3. Set the parameter value to UC4START so that the line reads: UC_EX_JOB_MD=UC4START.

This applies to both the native and Java-based MVS agents.

Additional Information

The UC_EX_JOB_MD= parameter determines which type of job-end processing is active.

In z/OS native environments, there are two possible values:

UCXJM25M: This is the IP-based job-end processing messenger, which signals the agent that the job has started or ended.

UC4START: This is the SMF-based job-end processing. EventMonitors use this to collect SMF data (such as step and job information) from the system, allowing for much faster job start/end recognition than the IP messenger. The Agent/EventMonitor uses the name UC4START to identify Automic jobs on the system. UC4END is a small program used to print a job summary if there was an error in SMF record processing and the job status could not be properly determined.

The Java-based agent works similarly but uses a different IP messenger called JMSGR. The underlying program is identical to UCXJM25M; it is simply a load module alias (similar to a Unix symbolic link). However, the program uses its own name to determine whether it should connect to a native or Java-based agent. The communication protocol differs slightly between the two agents.

In summary:

Native Agent:
UCXJM25M: IP messenger
UC4START: SMF messenger

Java-based Agent:
JMSGR: IP messenger
UC4START: SMF messenger