It has been a long road today and I am going nowhere.
I am reinstalling z/Open Source files after a install of z/OS 2.3.
I strongly suspect that the tar file is being corrupted as it bounces around on its way to z/OS.
Here are the steps I used.
A download from the Rocket web site to my downloads file directory.
A PC move from downloads to a desktop folder (for convenience)
A Win/SCP BINARY (yes BINARY) transfer from my PC to a personal directory on z/os (/u/tech905.RocketOpen)
The tar command is run (using the minimal instructions from the website AND from an example here in the forum) Both Get message
tar: checksum error on tape (got 4355, expected 0)
Of course, without gzip I cannot extract and test any of the other downloaded files.
Is there a way to do a direct download from Rocket to z/OS?
Where did this bouncing file get broken??
I just tried exactly that sequence of steps, and it worked fine. BUT - I was able to reproduce your problem with a slight change.
When you create a WinSCP session, you are given a choice of protocols: SFTP, SCP, FTP and WebDAV (at least in my version of WinSCP). If you select “SCP”, the z/OS OpenSSH server will do character set encoding translation to EBCDIC, EVEN IF YOU EXPLICITLY REQUEST A BINARY TRANSFER. AFAIK, there is no way to override this.
If you switch the transfer protocol to SFTP, this forced translation will NOT happen.
To verify that the file was correctly transferred, you can use the “od” command to look at the first few bytes of the file. When I copied the file using SCP (which produces a broken file), it looks like this:
$ od -tx1 gzip-1.9-edc_b002.180703.tar | head -1
0000000000 4B 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CEE5213S The signal SIGPIPE was received.
$ tar -C test_gzip -xoUXf gzip-1.9-edc_b002.180703.tar
tar: checksum error on tape (got 4355, expected 0)
$
Switching to the sftp protocol in WinZIP, I get:
$ od -tx1 gzip-1.9-edc_b002.180703.tar | head -1
0000000000 2E 2F 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CEE5213S The signal SIGPIPE was received.
$ tar -C test_gzip -xoUXf gzip-1.9-edc_b002.180703.tar
$ ls test_gzip
CHANGES.ZOS
README
README.ZOS
VERSION.ZOS
bin
man
share
$
HTH,
– Jerry
I just tried exactly that sequence of steps, and it worked fine. BUT - I was able to reproduce your problem with a slight change.
When you create a WinSCP session, you are given a choice of protocols: SFTP, SCP, FTP and WebDAV (at least in my version of WinSCP). If you select “SCP”, the z/OS OpenSSH server will do character set encoding translation to EBCDIC, EVEN IF YOU EXPLICITLY REQUEST A BINARY TRANSFER. AFAIK, there is no way to override this.
If you switch the transfer protocol to SFTP, this forced translation will NOT happen.
To verify that the file was correctly transferred, you can use the “od” command to look at the first few bytes of the file. When I copied the file using SCP (which produces a broken file), it looks like this:
$ od -tx1 gzip-1.9-edc_b002.180703.tar | head -1
0000000000 4B 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CEE5213S The signal SIGPIPE was received.
$ tar -C test_gzip -xoUXf gzip-1.9-edc_b002.180703.tar
tar: checksum error on tape (got 4355, expected 0)
$
Switching to the sftp protocol in WinZIP, I get:
$ od -tx1 gzip-1.9-edc_b002.180703.tar | head -1
0000000000 2E 2F 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CEE5213S The signal SIGPIPE was received.
$ tar -C test_gzip -xoUXf gzip-1.9-edc_b002.180703.tar
$ ls test_gzip
CHANGES.ZOS
README
README.ZOS
VERSION.ZOS
bin
man
share
$
HTH,
– Jerry
Thank you. My Winscp connection SAID it SFTP but there was still some translation going on.
I got around it by starting an FTP client, skipping any Secure options and doing good old fashioned binary file transfers.
So far, all of the new files sent to z/OS are good.