Release notes for RunMyJobs release 2023.2.0.0

Before: In some cases the sources to some open source third-party dependencies were ending up in the compile path, which meant that in some cases this could cause compilation failures.

After: These files no longer end up in the compile path

Before: The product shipped with guava 30.1.1, which was vulnerable to CVE-2020-8908 and CVE-2023-2976.

After: The guava library is updated to 32.0.0, which resolves these vulnerabilities.

NOTE: The product does not use the affected classes, and so is not vulnerable to either CVE, however we have decided to update the library out of an abundance of care.

The following 3rd-party libraries have been updated:

• (FasterXML) Jackson is upgraded 2.15.2
• (FasterXML) Woodstox is upgraded to 6.5.1
• Snakeyaml is upgraded to 2.0
• log4j is upgraded to 2.17.2

Before: RunMyJobs was using Tomcat 9.0.73, in which a security issue has been found (CVE-2023-28709)

After: Tomcat has been upgraded to 9.0.75, where the security issue is resolved.

NOTE: The configuration of RunMyJobs precludes the vulnerability, however the version is being upgraded out of precaution.

Before: When the process server was restarted the AS400 job is not monitored anymore. An NPE is thrown and the job will never reach a final status.

After: This has been fixed. When the Process Server is restarted the job is picked up again in the monitor tree and the job will reach a final status.

Before: If an AS400 job is started the connection can still be invalid and a SocketException is thrown. The job will end up into error.

After: If a SocketException is thrown when starting a job we will catch this exception and retry the start by creating a new connection. This is done AS400ConnectionRetry (default 5) times.

Before: The parameter AS400ConnectionRetry could only be set at ProcessServer level.
After: The parameter name is changed to AS400JobConnectionRetry so it can also be set in the script source of a Job as "ConnectionRetry"

Before: When submitting a job the jobinfo is retrieved in a separated call to the as400. It could be that the jobinfo retrieval runs into a ConnectionDroppedException. This causes to submit the job twice.

After: When the job is submitted we will retrieve the jobinfo afterwards, but if this fail the job is not resubmitted anymore.

2 new parameters can be added to a HTTP process definition:

1. HTTP_ReadTimeout: specifies the timeout for any read call, if not specified then it uses the system defaults, specified below.
2. HTTP_ConnectTimeout: specifies the connect timeout of the call, if not specified then it uses the system defaults, specified below.

Additionally two new configuration items have been for HTTP process timeouts:

1. net.HTTP.ReadTimeout: defaults to 1H, if set to zero, the read timeout will be disabled
2. net.HTTP.ConnectTimeout: defaults to 2M, if set to zero, the Java connect timeout will be disabled. Note, that the OS will likely still have its own timeout.

Both values can be specified by a string of the form: nHnMn.mS This leads to the following results:

1. 1H specifies a timeout of 1 hour
2. 2M specifies a timeout of 2 minutes
3. 20.345S specifies a timeout of 20.345 seconds
4. 15.1 specifies a timeout of 15.1 seconds

Before: When starting a job the connection can still fails to the AS400. The job will end up in error with a connection failure.
After: We now retry the connection when a job is started.

Before: Archiver processes could only be run with users that had the scheduler-administator role assigned

After: all users that have the Archiver_Manager Global Privilege (default granted to roles scheduler-administrator and redwood-administrator) have the ability to run Archiver processes.

Before: View privilege rank for Object Definition is required for viewing Object Index.

After: View privilege rank for Object Definition is not required for viewing Object Index.

Before: Occasional "DispatcherAgent.onMessage caught exception java.util.ConcurrentModificationException: null" errors and "Found InUse locks without jobs" warnings
could be reported in the scheduler log under heavy load of running jobs that made extensive use of job locks.

After: No occasional lock warning or errors reported in the scheduler log under heavy load of running jobs that made extensive use of job locks

Before: jobs where kept in the job list forever, if no system defaults where present and users did not set specific keep options on the job
After: introduced configuration options for default job retention which consist

• ad hoc option: how long to keep job without recurrence
• ranges options: how long to keep a job that runs up to X times a year
• exceeds max range option: those will be kept up to 100 last runs, jobs in statuses E K U will be kept for 10 days

Before: Under some conditions, specifically when memory usage is high, it is possible that after a compilation failure an error is generated while trying to print out the compilation error.

After: The compilation error will be generated correctly, and not suppressed.

Before: In certain cases, some modules were using a deprecated API, this API was removed in 9.2.10.0, thus causing some modules to break.

After: This API has been added back in for binary compatibility. It has been marked as DEPRECRATED, and will be removed again in a future release.

Note: The modules shipped with the product had all been updated to no longer use this API, however modules from previous upgrades still had references to this incorrect API.

Before: SOAP related jobs could run into problems as of version 9.2.11.0
After: SOAP related jobs will behave as correctly as before again.

before: Installation items from catalog set options RunAsUser and Push Acceptors.
after: Installation items from catalog ignore options like RunAsUser and Push Acceptors

BEFORE: In some circumstances, an error was shown when interrupting a thread from the support page

AFTER: No error is shown when interrupting a thread from the support page

Before: All users can use 'reply all equivalent type' to replay operator message.

After: Only users with global privilege 'reply all equivalent type' can use this option to replay operator message.

Before: Some of the builtin Mail Reactor definitions where marked as maintenance, causing them to be not visible easily by end users.

After: The Mail Reactor definitions are now always visible.

Before: Registry entry /configuration/jcs/billing/lastTimestamp was relocated to /system/UsageDataCollection/lastTimestamp.

After: Both registry entries /configuration/jcs/billing/lastTimestamp and /system/UsageDataCollection/lastTimestamp are removed.

Before: When catalog host is unknown, System_Upgrade job failed with an exception.

After: When an exception is thrown when performing the upgrade of catalog admin, System_Upgrade job proceeds with messages logged.

Before: Run Now action on processes could be run with all users

After: All users that have the Allow Run Now Global Privilege (default granted to roles scheduler-administrator, scheduler-job-administrator, redwood-administrator and redwood-operator) have the ability to run the processes immediately by selecting Run Now action.

Before: Usage data collector was possibly scheduled to run every day, after usage-data-collector.car was imported.

After: All the jobs and recurrence of usage data collector are cancelled and the Job Definition UsageDataCollector cannot be submitted anymore.

Before:
Platform agent in sudo-mode could fail to start, because of mismatches between the existence of a user-id found in local /etc/passwd vs the availability of this user in a PAM authentication backend.

After:
Environment variable 'JCS_SUDO_TEST_USER' can be set prior to starting the Platform agent in sudo-mode, to enforce a user name be used for the initial ‘sudo-mode test’.

Before:
Platform Agents doing the ‘sudo-mode verification test’, running on Suse Linux (SLES), in combination with PAM, could fail with error:

pam_unix (sudo:auth): conversation failed
pam_unix (sudo:auth): auth could not identify password for [nobody] 
pam_sss (sudo:auth): received for user nobody: 10 (User not known to the underlying authentication module)

After:
User ‘nobody' has been excluded as possible target user to perform the ‘sudo-mode verification test’.

Before:
Platform Agent did not correctly request a client certificate for verification when 'verify_peer_cert' was set to either 'client' or to 'both', in a secure_connection setup.
After:
Platform Agent now correctly requests and verifies a client certificate for incoming client connections when 'secure_connection' is set to true and 'verify_peer_cert' is set to 'client' or 'both'.

Before: Some files in the Platform Agent directory were world readable.
After: Removed world read/write permissions from files in the Platform Agent where there is no necessity for it.

Before: Old style Redwood branding was used for the Windows Platform Agent installer and Windows Platform Agent Service Manager.

After: New Redwood branding is used for the Windows Platform Agent installer and Windows Platform Agent Service Manager.

Before: Platform Agent and jtools were using OpenSSL version 1.1.1t
After: Platform Agent and jtools are now using OpenSSL version 3.0.9, except for OpenVMS.

Note that the following cipher suites are no longer supported:

DHE-RSA-SEED-SHA DHE-DSS-SEED-SHA ADH-SEED-SHA ECDHE-ECDSA-RC4-SHA ECDHE-RSA-RC4-SHA AECDH-RC4-SHA ADH-RC4-MD5 SEED-SHA IDEA-CBC-SHA ECDHE-PSK-RC4-SHA RSA-PSK-RC4-SHA DHE-PSK-RC4-SHA RC4-SHA RC4-MD5 PSK-RC4-SHA

Before:
Submitting a ‘jmail’ job without specifying the ‘-port’ parameter and without explicitly specifying a port entry in the scheduler’s registry, would result in an error like:
jmail] opsys.socket - Cannot find IP address of ‘mail-relay.example.org:-1' service 25: Name or service not known

After:
Submitting a 'jmail’ job without explicitly providing a port number, will use port 25 as default.

Before:
jtool scp, using credential lookup, could fail when receiving unknown SSH server prompt, raising error: 'Credential system does not yet handle prompt of type SSH server: Password authentication'

After:
jtool scp will now recognize the prompt and continue looking for available credentials to establish a connection

Before: Since 9.2.9 XBP transport is not required to be installed, ISU transport cannot be installed properly without XBP transport

After: ISU transport is now independent of XBP transport.

Before: Cannot monitor skipped processes in process chains.

After: Process chains with skipped processes are properly monitored

Before: SAP BOBJ DataSercices processes can potentially end up in an endless loop when session id gets invalidated

After: Always get new session id by invalid session id.

Before: Potential NPE by create/remove BW Chain operator messages

After: Fixed NPE

Before: Running SAP_Info against some SAP systems would cause it to error out with a NullPointerException.

After: Running SAP_Info against these systems works correctly.

Before: To create a report with specific columns, the user previously had to manually click or unclick each checkbox, even for reports with numerous columns.

Now: The user can quickly select or deselect all columns at once to streamline the process.

Before: When using the product over https, the CSRFTOKEN cookie was not set with the secure flag.

After: When using the product over https, the CSRFTOKEN cookie now has the secure flag set, thus making it harder for the cookie to be intercepted.

Before: In the user settings, “Use basic HTML Chain Editor” option is not deprecated.
After: the setting “Use basic HTML Chain Editor” is now marked as deprecated.

Before: JDBC jobs always apply a ‘commit’ after the job is run. JDBC connections could not be influenced to to set the ‘auto commit’ function disabled.

After: On a Database connection it is now possible to specify the Auto Commit option. The options are:
Transaction Based (Default): A commit is applied at the end of a job.
AutoCommit On: Each SQL statement will be executed in its own transaction and is implicitly committed.
AutoCommit Off: No commit is done. If you want to commit your SQL commands, you must commit the transaction explicitly.

Add the “Depreciation Run” in RMJ. The “Depreciation Run” is started from a form in EBS. To start this in RMJ a JobChain has been build to start the “Depreciation Run”. Depending on the parameters we start the corresponding Concurrent programs and Request Sets.

Before:
For on-premise installation, where platform agent runs in server initiated mode, firewall and/or proxy servers might limit the connectivity for jtools from the platform agent host back into the server.

After:
An additional Process Server parameter called ‘AlternativeJobContextURL’ is added to allow customers, with on-premise installations, to specify an alternative JobContext URL.
This alternative URL will be used by jtools to connect to the server, instead of the actual ‘ContextURL’ of the server.

Before: Dataservice job cannot get final status when the session id becomes invalid or the batch job is not started
After: Handle invalid session id and batch job not starting exception properly, set data service job to final status.

In order to optimise user experience, we introduced heap.io for tracking ergonomics, thus enables us to fine tune most frequently used interactions. Anonymized data on feature use is analyzed by Redwood’s Product Management Team to best prioritize, plan and design future features for our products. This data is not shared with any other external parties.