0

I'm sending binary .gz files from Linux to z/OS via ftps. The file transfers seem to be fine, but when the mainframe folks pkunzip the file, they get a warning:

PEX013W Record(s) being truncated to lrecl= 996. Record# 1 is 1000 bytes.

Currently I’m sending the site commands: 

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.

They could read the file after the pkunzip, but having a warning is not a good thing.

Output from 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

Is there a better set of site commands to transfer a .gz file from Linux to z/OS to avoid this error?

**** Update ****

Using SaggingRufus's answer below, it turns out it doesn't much matter how you send the .gz file, as long as it's binary. His suggestion pointed us to the parameters sent to the pkunzip for the output file, which was VB and was truncating 4 bytes off the record.

Mike
  • 3,186
  • 3
  • 26
  • 32
  • In case you hadn't considered it, this is one of those areas where z/OS UNIX Services (USS) comes in handy...on Linux, you can use TAR, GZIP - whatever you like - and then expand into a UNIX-style filesystem on z/OS...very handy and skips the headaches of going in and out of conventional z/OS datasets. – Valerie R May 19 '18 at 18:45
  • I would agree with Valerie. Life will be smoother if you use Unix System Services – mike Jul 07 '18 at 05:27
  • @mike agreed, what I did leave out, is that we also go to MVS with these files as well. Combined with the fact that our developers are life-long MVS folks, the Unix services are fairly foreign to them. We are getting there, just slower than I would have liked. If I had someone dedicated on that side, I would have spent a little more time experimenting with various parameters. Chances are, changing it to FB would have worked. Lots of impatience and "Get off my lawn" mentality here! LOL – Mike Jul 09 '18 at 11:52

2 Answers2

0

Because it is a variable block file, there are 4 bytes allocated to the record attributes. Allocate the file with an LRECL of 1004 and it will be fine.

SaggingRufus
  • 1,814
  • 16
  • 32
  • Makes sense, although I did use 1024 initially and received the same warning. Should I change the RECFM to something else like recfm=U or ??? I'm not a mainframe guy, so it's the data in the file that's getting the issue due to the record format? The file is 1000 byte ascii characters inside. I thought the format would affect the binary file (gz). I didn't really think about the unzipped file. – Mike May 16 '18 at 13:43
  • Is it always 1000 bytes? if so, you may want to use FB (fixed block) with an LRECL of 1000. This tells the mainframe that the records are fixed in length at 1000 bytes (rather than being a variable length). The RECFM wont change the "format" of the file, just how the record is interpreted. Things outside the mainframe don't really a good way to handle variable block files try using FB (fixed block) – SaggingRufus May 16 '18 at 15:20
0

Rather than generating a .zip file, perhaps generate a .tar.gz file and transfer it to z/OS UNIX? Tar is shipped with z/OS by default, and Rocket Software provides a port of gzip that is optimized for z/OS.

Anthony Giorgio
  • 1,844
  • 1
  • 15
  • 17
  • Anthony, wanted to ping you, would you please take a look at my Meta post "[Merge/cleanup tags \[zos\], \[mvs\], \[zseries\], and \[mainframe\]](https://meta.stackoverflow.com/questions/370743/merge-cleanup-tags-zos-mvs-zseries-and-mainframe)" and comment as someone who has much more knowledge about these tags than I do? – JoshMc Jul 11 '18 at 16:22