你遇到的这个问题我之前帮别人排查过类似的，核心问题大概率出在记录拆分方式或者原始数据的完整性上，咱们一步步来拆解：

先明确几个关键前提 #

首先看你的COPYBOOK定义：

01 CCS001-DETAIL-RECORD.
05 CCS001-REC-TYPE PIC X(01).
05 CCS001-MEMB-NUM PIC S9(09) COMP.
05 CCS001-PR-CAT PIC X(03).
... 其他字段 ...

• PIC S9(09) COMP：IBM大型机里，这个类型是32位有符号二进制数，固定占4字节，你对这个字段长度的判断是对的。
• 整个记录是固定长度：算一下总字节数：1（REC-TYPE）+4（MEMB-NUM）+3（PR-CAT）+26+8+38 = 80字节。也就是说，正常情况下每个记录应该严格是80字节，所有字段的位置完全固定。

你当前遇到的问题原因分析 #

你看到PR-CAT的ABC不在同一位置，说明前面的字段总长度不一致，可能的原因有两个：

1. 错误地用换行符拆分记录

大型机生成的主文件几乎都是固定长度连续存储的，根本没有\r\n这种换行符分隔！你用data.split(b'\r\n')拆分记录，相当于把原本连续的固定长度块强行按换行符切割，很可能把一个完整的记录拆成两段，或者把多个记录合并，直接破坏了字段的位置对齐，这是最常见的错误。

2. 原始数据被转码损坏

如果工程师是把二进制文件当成文本文件复制/保存的（比如用记事本打开大型机的二进制文件然后另存），那二进制里的控制字符、EBCDIC编码的字符会被自动转成UTF-8（比如你看到的\xc2\xae这种就是UTF-8的多字节序列），直接破坏了原始的固定长度结构——原本4字节的COMP字段可能被转成了多字节的UTF-8序列，导致后面的PR-CAT字段位置偏移。

解决方案和修正代码 #

咱们先从最可能的「记录拆分错误」开始修正，再验证数据是否损坏：

第一步：按固定长度读取记录

放弃用换行符拆分，直接按COPYBOOK计算的80字节长度读取每个记录：

import struct

# 从COPYBOOK计算的单条记录总长度
RECORD_LENGTH = 1 + 4 + 3 + 26 + 8 + 38  # 等于80字节
# IBM大型机的字符字段用CP037（EBCDIC）编码，需要先安装依赖：pip install ebcdic

with open('sample.dat', 'rb') as f:
    record_count = 0
    while True:
        # 每次读取固定长度的一条记录
        record = f.read(RECORD_LENGTH)
        if not record:
            break
        # 读取到的记录长度不足80，说明文件尾部不完整，跳过
        if len(record) < RECORD_LENGTH:
            print(f"跳过不完整记录：{record}")
            continue
        
        # 解析各个字段
        # 1. 记录类型：第1字节（索引0-1）
        rec_type = record[0:1]
        # 2. MEMB-NUM：第2-5字节（索引1-5），IBM COMP是大端有符号32位整数
        memb_num_bytes = record[1:5]
        # 用struct.unpack解析大端有符号整数，'>i'表示大端（big-endian）32位有符号int
        memb_num = struct.unpack('>i', memb_num_bytes)[0]
        # 3. PR-CAT：第6-8字节（索引5-8），EBCDIC转成字符串
        try:
            pr_cat = record[5:8].decode('cp037')
        except UnicodeDecodeError:
            pr_cat = "无法解码（数据可能损坏）"
        
        print(f"第{record_count+1}条记录：")
        print(f"  REC-TYPE: {rec_type}, MEMB-NUM: {memb_num}, PR-CAT: {pr_cat}")
        
        record_count += 1
        # 只看前10条，和你之前的逻辑一致
        if record_count == 10:
            break

第二步：验证数据是否损坏

如果按固定长度读取后，PR-CAT的内容能固定出现在正确位置，说明只是记录拆分错误，数据没问题；如果还是位置不对，那大概率是原始数据被转码损坏了——这时候你需要让工程师重新提供原始二进制文件，不要用文本编辑器打开或复制，直接传输二进制格式的文件（比如FTP用二进制模式，而不是ASCII模式）。

额外注意点 #

1. IBM COMP的字节序：必须用大端（>）解析，因为大型机都是大端字节序，用小端解析的话数字会完全错误。
2. EBCDIC编码：大型机的字符字段都是EBCDIC（通常是CP037编码页），不是UTF-8，所以解码的时候要指定cp037，需要先安装ebcdic包才能用这个编码。
3. 文件传输模式：如果工程师是通过FTP传文件，一定要用二进制模式（BIN模式），ASCII模式会自动转换换行符和编码，直接破坏二进制数据。

如果按上面的代码跑了之后还有问题，你可以把解析出来的MEMB-NUM和PR-CAT结果贴出来，咱们再进一步排查！