𝗧𝗵𝗲 𝗖𝘂𝗿𝗶𝗼𝘂𝘀 𝗖𝗮𝘀𝗲 𝗼𝗳 𝗜𝗻𝘁𝗲𝗿𝗺𝗶𝘁𝘁𝗲𝗻𝘁 𝗦𝗙𝗧𝗣 𝗧𝗶𝗺𝗲𝗼𝘂𝘁𝘀 𝗶𝗻 𝗠𝗮𝗶𝗻𝗳𝗿𝗮𝗺𝗲 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗝𝗼𝗯𝘀

One of our customers decided to improve security by replacing plain FTP with SFTP across their production batch jobs.

 

As part of the change, all existing FTP steps were replaced with Co:Z SFTP.

 

The implementation looked straightforward. However, once the changes reached production, we started seeing an unexpected problem.

 

Some SFTP steps were intermittently timing out.

 

What made the issue more interesting was that the failures were not consistent. The same jobs could run successfully at one time and fail at another.

 

After looking at the pattern more closely, we noticed one important clue: The SFTP timeouts were occurring primarily during periods of high CPU utilization.

 

That shifted our investigation away from simply treating this as an SFTP or connectivity problem.

 

SMF 30 Provided the Clue

 

Initially, we did not have a clear explanation for why the Co:Z SFTP steps were failing.

 

We eventually decided to investigate the workload using SMF Type 30 records, and that pointed us in the right direction.

 

We found that Co:Z SFTP file transfers were running under an OMVS address space. However, there was no specific WLM classification rule covering this workload.

 

As a result, the SFTP workload was falling into the default OMVS service class, which had a Discretionary goal.

 

And that turned out to be the real problem.

 

Why the Discretionary Goal Mattered

 

A workload running with a Discretionary WLM goal receives CPU resources only when higher-priority workloads do not need them.

 

Under normal CPU conditions, this was not noticeable. There was enough CPU available, and the SFTP transfers completed successfully.

 

During peak CPU utilization, however, higher-priority workloads took precedence. The OMVS workload running the Co:Z SFTP process did not receive enough CPU in a timely manner.

 

The result?  The SFTP operations started hitting timeouts.

 

So, what initially appeared to be an intermittent SFTP problem was actually a WLM workload-classification problem exposed by CPU contention.

 

The WLM Change

 

Our production batch workloads already had three service classes based on priority:

• PRDBATHI - High-priority batch
• PRDBATMD - Medium-priority batch
• PRDBATLO - Low-priority batch

 

We decided that the OMVS workload responsible for the production SFTP transfers should receive the PRDBATHI service class.

 

We therefore added a WLM classification rule similar to the following:

 

Qualifier  Qualifier      Starting       Service   Report

type       name           position       Class     Class

---------  -------------  ---------      --------  --------

TN         PRDJOBQUAL                    PRDBATHI  SFTP

 

After installing the updated WLM definition, the behavior changed immediately.

 

The Co:Z SFTP steps began completing successfully, including during periods of high CPU utilization, and the intermittent timeout problem disappeared.

 

This incident was a good reminder that an SFTP timeout does not necessarily mean there is a network or SFTP problem.