大型机 pkunzip 生成 PEX013W 记录被截断为 lrecl=

Posted 2023-02-16

【中文标题】大型机 pkunzip 生成 PEX013W 记录被截断为 lrecl=

【英文标题】：Mainframe pkunzip generates PEX013W Record(s) being truncated to lrecl=

【发布时间】：2018-05-15 20:14:24

【问题描述】：

我正在通过 ftps 从 Linux 向 z/OS 发送二进制 .gz 文件。文件传输似乎没问题，但是当大型机人员 pkunzip 文件时，他们会收到警告：

PEX013W 记录被截断为 lrecl= 996。记录# 1 为 1000 字节。

目前我正在发送站点命令：

SITE TRAIL
200 SITE command was accepted
SITE CYLINDERS PRIMARY=50 SECONDARY=50
200 SITE command was accepted
SITE RECFM=VB LRECL=1000 BLKSIZE=32000
200 SITE command was accepted
SITE CONDDISP=delete
200 SITE command was accepted
TYPE I
200 Representation type is Image
... 
250 Transfer completed successfully.
QUIT
221 Quit command received. Goodbye.

他们可以在 pkunzip 之后读取文件，但出现警告并不是一件好事。

pkunzip 的输出：

SDSF OUTPUT DISPLAY RMD0063A JOB22093  DSID   103 LINE 25      COLUMNS 02- 81 
COMMAND INPUT ===>                                            SCROLL ===> CSR 
PCM123I Authorized services are unavailable.                                  
PAM030I INPUT  Archive opened:  TEST.FTP.SOA5021.GZ                        
PAM560I ARCHIVE FASTSEEK processing is disabled.                              
PDA000I  DDNAME=SYS00001,DISP_STATUS=MOD,DISP_NORMAL=CATALOG,DISP_ABNORMAL=   
PDA000I     SPACE_TYPE=TRK,SPACE_TYPE=CYL,SPACE_TYPE=BLK                      
PDA000I     SPACE_PRIMARY=4194304,SPACE_DIRBLKS=5767182,INFO_ALCFMT=00        
PDA000I     VOLUMES=DPPT71,INFO_CNTL=,INFO_STORCLASS=,INFO_MGMTCLASS=         
PDA000I     INFO_DATACLASS=,INFO_VSAMRECORG=00,INFO_VSAMKEYOFF=0              
PDA000I     INFO_COPYDD=,INFO_COPYMDL=,INFO_AVGRECU=00,INFO_DSTYPE=00         
PEX013W Record(s) being truncated to lrecl= 996. Record# 1 is 1000 bytes.    
PEX002I TEST.FTP.SOA5021                                                   
PEX003I Extracted to TEST.FTP.SOA5021I.TXT                                 
PAM140I FILES:   EXTRACTED  EXCLUDED  BYPASSED  IN ERROR                      
PAM140I                  1         0         0         0                      
PMT002I PKUNZIP processing complete. RC=00000004 4(Dec) Start: 12:59:48.86 End

是否有更好的站点命令集来将 .gz 文件从 Linux 传输到 z/OS 以避免此错误？

**** 更新****

使用下面的 SaggingRufus 的答案，事实证明，如何发送 .gz 文件并不重要，只要它是二进制文件即可。他的建议向我们指出了为输出文件发送到 pkunzip 的参数，该文件是 VB，并且正在从记录中截断 4 个字节。

【问题讨论】：

如果您没有考虑过，这是 z/OS UNIX 服务 (USS) 派上用场的领域之一……在 Linux 上，您可以使用 TAR、GZIP - 无论您使用什么像 - 然后在 z/OS 上扩展成一个 UNIX 风格的文件系统...非常方便，省去了进出传统 z/OS 数据集的麻烦。

我同意瓦莱丽的观点。如果你使用 Unix 系统服务，生活会更顺畅

@mike 同意，我没有遗漏的是，我们也带着这些文件去 MVS。再加上我们的开发人员是终生从事 MVS 的人，Unix 服务对他们来说是相当陌生的。我们快到了，只是比我希望的要慢。如果我有专门的人在这方面，我会花更多的时间来试验各种参数。很有可能，将其更改为 FB 会奏效。这里有很多不耐烦和“离开我的草坪”的心态！哈哈

【参考方案1】：

因为是可变块文件，所以有4个字节分配给记录属性。分配 LRECL 为 1004 的文件就可以了。

【讨论】：

有道理，尽管我最初确实使用了 1024 并收到了相同的警告。我应该将 RECFM 更改为其他类似 recfm=U 或 ???我不是大型机专家，所以文件中的数据由于记录格式而出现问题？该文件里面是 1000 字节的 ascii 字符。我认为格式会影响二进制文件（gz）。我并没有真正考虑解压缩的文件。

总是1000字节吗？如果是这样，您可能希望使用 LRECL 为 1000 的 FB（固定块）。这告诉大型机记录的长度固定为 1000 字节（而不是可变长度）。 RECFM 不会改变文件的“格式”，只是解释记录的方式。大型机以外的东西真的不是处理可变块文件的好方法尝试使用FB（固定块）

【参考方案2】：

与其生成 .zip 文件，不如生成 .tar.gz 文件并将其传输到 z/OS UNIX？ Tar 默认随 z/OS 一起提供，Rocket Software 提供了一个针对 z/OS 优化的 gzip 端口。

【讨论】：

Anthony，想联系你，请你看看我的 Meta 帖子“Merge/cleanup tags [zos], [mvs], [zseries], and [mainframe]”，并以比我更了解这些标签的人的身份发表评论吗？