[Bug] [Bug] [zos_job_query] [module_utils/job.py] is not using the latest ZOAU interface for fetch_multiple

[ddimatos]

Is there an existing issue for this?

• There are no existing issues.

Bug description

Review the internal discussion here: <sanitized>/archives/CSLEJ8VGV/p1760138787897389?thread_ts=1754323020.810359&cid=CSLEJ8VGV

This issue relates, or I should say was discovered as I was trouble shooting this related issue #2367.

While I don't have a concrete bug related to this discovery at the moment, there may be one as I am still trying to understand why we are getting a CEE dump and this might be the reason, regardless, the API seems to be dated here.

ZOAU API fetch_multiple supports these options job_id=None, job_owner=None, job_name=None yet the ../module_utils/job.py here and here are only using:

entries = jobs.fetch_multiple(job_id=job_id_temp, job_owner=owner, include_extended=True)

and

entries = jobs.fetch_multiple(job_id=job_id_temp, job_owner=owner, include_extended=True) 

By updating the API usage, its possible that the surrounding code could be improved/reduced. I do see this comment but wonder if it is noting that the module is not using job_name,

    # In ZOAU>= 1.3.0, include_extended has to be set to true so we get the program name for a job.
    # Observation shows the job_name parameter is not being used, so we will drop that

As I do see the job_name later used, which might be able to see improvement in this code snippet

            if owner != "*":
                if owner != entry.owner:
                    continue
            if job_name != "*":
                if not fnmatch.fnmatch(entry.name, job_name):
                    continue
            if job_id_temp is not None:
                if not fnmatch.fnmatch(entry.job_id, job_id):
                    continue

What it comes down to is ZOAU fetch_multiple passes these options to JES and JES makes the decision on what to return, it seems like the module util at one time was trying to handle some of this logical processing and might need to be revisited. There is a chance this issue relates to something else I am looking into where a particular user is triggering a CEE dump when ZOAU is called and it might be because the Ansible code is not passing all the options it could, more on that as we dive deeper.

IBM z/OS Ansible core Version

v1.14.0

IBM Z Open Automation Utilities

v1.3.3

IBM Enterprise Python

v3.11.x

ansible-version

v2.15.x

z/OS version

v2.5

Ansible module

zos_job_query

Playbook verbosity output.

No response

Ansible configuration.

Contents of the inventory

Contents of group_vars or host_vars