Troubleshooting a remote runtime engine for DataStage Anywhere

Use these solutions to help resolve problems that you might encounter with IBM® DataStage® Anywhere on a remote engine.

Job stuck in hanging or running

Check whether the remote engine crashed or restarted during the job run. If the container crashed during the job run, the date-time of the container start would be shortly after the job run was requested. In this case, "shortly after" means that the container start time does not exceed the expected time for the particular job run. If the start time exceeds this period or is it before the job start time, then discredit the possibility that the container went down mid-run.

If the start time of the container is earlier than the time that the job run was requested, do the following procedure:

Access the remote engine by using Docker or Kubernetes commands.

Run the following command inside the container:

ps -eo lstart,cmd | grep /opt/ibm | grep -v sh | grep -v grep

The output should list two running processes. If the output is fewer than two lines, it indicates that the current container does not work properly. If that is the case, restart the container manually to resolve the issue. If either of the processes has a date-time that is shortly after then the start of the job, it might indicate that the container crashed or started mid-run.

The mailx command on the remote engine

Before you can run the mailx command for your before-job or after-job subroutine, you must provide the SMTP server information.

Using DataStage-aaS Anywhere with other products on the same machine

When starting DataStage-aaS Anywhere with dsengine.sh, avoid using /temp as the volume mount directory since other services may interfere with DataStage operations. Instead, use the --volume-dir flag to customize the mount location and create a new directory in a different location.

FIPS incompatibility when using public cloud as the control plane

When using public cloud as the control plane, disable FIPS on your host machine. Combination of public cloud as the control plane and having FIPS enabled on host machine causes the job log upload to fail as public cloud COS does not have the FIPS compatibility.