Learn what causes Partial Record Errors when writing over NFS to z/OS and how to fix them using real configurations that actually work. Our Live Support Team is always here to help you.
Understanding Partial Record Errors when Writing over NFS to z/OS
When working with NFS and z/OS, things usually run smoothly until you hit those confusing partial record errors when writing over NFS to z/OS. They tend to appear suddenly, breaking your data flow and leaving you wondering what exactly went wrong. Let’s go straight into what this means, why it happens, and how real engineers have fixed it.
Overview
What Exactly Are Partial Record Errors on z/OS?
In simple terms, a partial record (or incomplete record) shows up when data blocks from your NFS client don’t reach the z/OS NFS server as a complete sequence.
This happens in both text and binary modes. Here’s the breakdown:
- For text mode, z/OS scans for end-of-line (EOL) delimiters in the byte stream. If the last or only record in an RPC WRITE block (starting at offset=0) has no EOL, it’s marked as a text partial record. The next block then continues the unfinished record.
- RPC WRITEs can arrive out of order. So if one data block goes missing, the z/OS NFS server can’t chain the records together. The missing block is automatically treated as a partial record.
- For binary mode, it’s even simpler. z/OS doesn’t look for EOLs, but any lost block still creates gaps in the data stream, which later get filled with zeroes.
Once the z/OS NFS server detects a missing block, it waits for the client to resend it within a writetimeout period. If that doesn’t happen, it writes whatever it has to disk, filling any missing portions with zeroes.
This means when the dataset closes, those holes remain. You’ll notice random zeroes either in the middle or at the end of the file.
Why It Happens
After speaking with IBM engineers, it turns out that the issue often comes from the z/OS receive buffer getting full. The z/OS system doesn’t like out-of-sequence data writes, even though Linux and other NFS servers can usually handle them.
When the receive buffer fills up but some expected data block hasn’t yet arrived, z/OS simply stops writing. That’s when partial record errors when writing over NFS to z/OS start showing up.
A Workable Solution That Actually Helps
The good news? You don’t have to overhaul your setup. There’s a proven workaround from the SLES 11 SP1 NFS client side that limits the dirty cache size. This tweak controls how much data is buffered before it reaches z/OS, keeping things within a safe range.
Here’s what was done in a real-world case that solved the issue completely:
echo 104857600 > /proc/sys/vm/dirty_bytes
echo 52428800 > /proc/sys/vm/dirty_background_bytesThese commands can be applied instantly, and the changes take effect right away.
To make them permanent across reboots, update your /etc/sysctl.conf file by adding or modifying the parameters:
vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 52428800Conclusion
Fix NFS Errors Instantly Today!
Conclusion
To sum it up, partial record errors when writing over NFS to z/OS are usually caused by missing or delayed RPC WRITE blocks that break the data flow between client and server. The z/OS system ends up writing incomplete data and fills the missing parts with zeroes.
By simply adjusting the dirty cache size on the NFS client side, you can keep your z/OS buffers from choking and avoid these frustrating errors altogether.
For most admins, this tweak is the cleanest and most effective way to handle partial record errors when writing over NFS to z/OS, and it’s been proven to work in production.
