Remote client sends unexpected code page

Remote client sends unexpected code page is usually a mode or code-page problem, not a network problem. The bytes arrived - they were just translated wrong.

What it means

• FTP ASCII mode translates line endings and code pages; BINARY (IMAGE) mode moves bytes untouched.
• Sending a dataset with packed or binary fields in ASCII mode corrupts the data; sending plain text in BINARY leaves EBCDIC unreadable on the ASCII side.
• SFTP always moves bytes untouched - any corruption there comes from a code-page conversion done by the application, not the protocol.

Common causes

• FTP transfer of packed-decimal or binary fields done in ASCII mode instead of BINARY.
• Text file pulled from z/OS in BINARY mode, arriving as unreadable EBCDIC on the ASCII side.
• Wrong code page in the conversion step, for example Cp037 versus Cp1047, mangling special characters.
• Fixed-width mainframe records consumed as delimited data, shifting every field after the first short record.
• Firewall rule change silently breaking the FTP data connection while the control connection still works.
• Transfer job starting before the sender finished writing the file, producing a short record count.

How to diagnose

• Compare record counts three ways: sender count, received count, and the transfer log.
• Hex-dump the first record on both sides to see whether the bytes were translated in transit.
• Check the FTP log for the TYPE actually used: A for ASCII, I for IMAGE/BINARY.
• For SFTP, check the SSH log for the login, then confirm which side performs the code-page conversion.
• Re-run the transfer to a test file in the opposite mode and compare the results.

How to fix it

• Use BINARY for anything with packed or binary fields; use ASCII for plain text that needs translation.
• Standardize one code page per interface, commonly IBM-037 for US EBCDIC, and document it in the interface spec.
• Have the sender write a trailer record with the count; the receiver validates it before processing.
• Trigger dependent jobs on file arrival plus a settle delay, not on a fixed schedule.
• Restore the firewall rule for the FTP data ports when passive-mode transfers break.

Example: FTP a dataset in the right mode

BINARY preserves every byte; ASCII translates EBCDIC to ASCII and converts line endings.

Interview tip

• Q: A file pulled from z/OS has the right record count but every packed field is garbage. Remote client sends unexpected code page?
• A: Right count with corrupted packed fields means the transfer ran in ASCII mode, which translated the packed bytes as if they were text. The fix is to re-pull in BINARY mode so bytes move untouched. Going forward I put the mode explicitly in the transfer script instead of relying on the client default.

Prevention checklist

• Put the FTP mode explicitly in every transfer script; never rely on client defaults.
• Add trailer-record count validation on every interface file.
• Document the code page per interface and re-test special characters after any change.
• Start dependent jobs on file-arrival events with a settle delay, not on the clock.