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.
