Autosys job fails using jdk-11.0.11

Products

• Autosys Workload Automation

Issue/Introduction

Autosys job fails using jdk-11.0.11 with the below error, however the same is success in lower environments, any help here is appreciated

Environment

Release : 11.3.6

Component : CA Workload Automation AE (AutoSys)

Resolution

A job was working in both UTA and Production environments.
The job's script sets JAVA_HOME.
The script was updated to point to a new JAVA_HOME.
After the above change the job continued to work in UTA but failed in Production.
The following error was seen in the std_err_file:
Error: LinkageError occurred while loading main class com.test123.example.company.codeProcessor
        java.lang.UnsatisfiedLinkError: /apps/java/jdk-11.0.11/lib/libnio.so: /apps/java/jdk-11.0.11/lib/libnio.so: undefined symbol: reuseport_available

The user created a new profile which included setting the PATH and LD_LIBRARY_PATH variables to point to the new jre.
She then updated the job definition to use that profile.
That allowed the job to run without issue in production.

Why was this only needed in UTA?

We ran test jobs that ran an "env" thru both instances.
There were differences in the environment variables between the two.
PATH and LD_LIBRARY_PATH were different between the two.
Another factor was that the agents were not the same version.
They were also different bit levels, 32 vs 64.
Their running java environments were different as well.

The job's script did not include updates or the setting of the PATH or LD_LIBRARY_PATH.
It appears they assumed the environment would be set already.

Recommendations.

Continue using the new profile in the job definition(s) as needed.
Consider setting the needed variables in the job definition using the envvars job attribute.
Consider updating the agent's WAAE.txt profile or AUTOSERV specific one(s) to include the PATH and LD_LIBRARY_PATH changes.
Consider updating the job's script itself to set the PATH and LD_LIBRARY_PATH it needs.

If the job owner wanted to dig further just for the sake of knowing how it is still working in UTA they could include additional debug in their script.  

Things like "env" before launching into the problemed call and running their command thru strace to determine where each and every library is found.  

Again this is just for the sake of knowing.  

It does not change the recommendation.