Here is a new puzzler.
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
Page 1 / 1
Here is a new puzzler.
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
I'm a software developer on the open-source team at Rocket.
I find it concerning that cp behaves differently when ~/bin is at the front vs at the back of your $PATH. Because the system cp doesn't have a dependency on our software my best guess is that you have installed a package that has a cp binary in it. Internally we do have a port of GNU Coreutils which does have a port of `cp`. That package shouldn't be installed on your system though. It is not meant to be a runtime dependency of any packages.
Could you share a list of installed packages for your system (`conda list`) and/or a listing of the ~/bin directory?
I'll use that to 1) verify that GNU coreutils is causing this problem and, if it is, 2) figure out why it got there and how to safely remove it.
If that isn't what's going on then we will take a closer look.
Thanks for getting in touch,
Harrison Kaiser
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
Here is a new puzzler.
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
I am a software developer who works on open-source tools here at Rocket.
Your problem is concerning to me because, from what you've described, it seems that you've installed a package that includes `cp` as a binary. We only have one package that fits that description and it is meant only for internal use here at Rocket. We use it to test software that expects GNU coreutils like behavior from cp (not z/OS /bin/cp behavior). Let's first check that this is the problem and then determine how to proceed.
First, you can check which cp binary is being called by `which cp`. If you try that with a $PATH beginning/ending with ~/bin that will tell you if you are calling a different cp binary in each case.
Second, could you activate your conda environment and post the result of `conda list`? This will show all the packages you have installed and I can check if the package with GNU cp is included in the installed list.
Lastly, if you list the contents of `~/bin` you may see a binary named `cp`. Let me know either way. But if you do see such a binary that will be the problem.
Thanks for reaching out,
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
Hi Tom,
I am a software developer who works on open-source tools here at Rocket.
Your problem is concerning to me because, from what you've described, it seems that you've installed a package that includes `cp` as a binary. We only have one package that fits that description and it is meant only for internal use here at Rocket. We use it to test software that expects GNU coreutils like behavior from cp (not z/OS /bin/cp behavior). Let's first check that this is the problem and then determine how to proceed.
First, you can check which cp binary is being called by `which cp`. If you try that with a $PATH beginning/ending with ~/bin that will tell you if you are calling a different cp binary in each case.
Second, could you activate your conda environment and post the result of `conda list`? This will show all the packages you have installed and I can check if the package with GNU cp is included in the installed list.
Lastly, if you list the contents of `~/bin` you may see a binary named `cp`. Let me know either way. But if you do see such a binary that will be the problem.
Thanks for reaching out,
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
I am a software developer who works on open-source tools here at Rocket.
Your problem is concerning to me because, from what you've described, it seems that you've installed a package that includes `cp` as a binary. We only have one package that fits that description and it is meant only for internal use here at Rocket. We use it to test software that expects GNU coreutils like behavior from cp (not z/OS /bin/cp behavior). Let's first check that this is the problem and then determine how to proceed.
First, you can check which cp binary is being called by `which cp`. If you try that with a $PATH beginning/ending with ~/bin that will tell you if you are calling a different cp binary in each case.
Second, could you activate your conda environment and post the result of `conda list`? This will show all the packages you have installed and I can check if the package with GNU cp is included in the installed list.
Lastly, if you list the contents of `~/bin` you may see a binary named `cp`. Let me know either way. But if you do see such a binary that will be the problem.
Thanks for reaching out,
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
H905@jismvs_test-> ls -l
total 651060
lrwxrwxrwx 1 TECH905 FSTCI 8 Jan 24 15:21 2to3 -> 2to3-3.7
-rwxrwxr-x 1 TECH905 FSTCI 108 Jan 24 15:20 2to3-3.7
-rwxrwxr-x 1 TECH905 FSTCI 26604 Jan 24 15:19 autopoint
-rwxrwxr-x 2 TECH905 FSTCI 3887104 Sep 7 2017 bash
-rwxrwxr-x 2 TECH905 FSTCI 7182 Feb 14 2017 bashbug
-rwxrwxr-x 2 TECH905 FSTCI 1347584 Dec 15 2020 bunzip2
-rwxrwxr-x 2 TECH905 FSTCI 1347584 Dec 15 2020 bzcat
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:20 bzcmp -> bzdiff
-rwxrwxr-x 2 TECH905 FSTCI 2140 Dec 15 2020 bzdiff
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:20 bzegrep -> bzgrep
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:20 bzfgrep -> bzgrep
-rwxrwxr-x 2 TECH905 FSTCI 2054 Dec 15 2020 bzgrep
-rwxrwxr-x 2 TECH905 FSTCI 1347584 Dec 15 2020 bzip2
-rwxrwxr-x 2 TECH905 FSTCI 2805760 Dec 15 2020 bzip2recover
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:20 bzless -> bzmore
-rwxrwxr-x 2 TECH905 FSTCI 1259 Dec 15 2020 bzmore
-rwxrwxr-x 1 TECH905 FSTCI 36772 Jan 24 15:19 c2ph
-rwxrwxr-x 1 TECH905 FSTCI 6223 Jan 24 15:19 c_rehash
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 24 15:20 captoinfo -> tic
-rwxrwxr-x 2 TECH905 FSTCI 905216 May 6 2020 clear
-rwxrwxr-x 2 TECH905 FSTCI 585728 Nov 22 2019 cmp
-rwxrwxr-x 1 TECH905 FSTCI 12856 Jan 24 15:19 corelist
-rwxrwxr-x 1 TECH905 FSTCI 7491 Jan 24 15:19 cpan
-rwxrwxr-x 2 TECH905 FSTCI 181 Apr 14 2020 cppstdin
-rwxrwxr-x 2 TECH905 FSTCI 47497216 Dec 8 2020 curl
-rwxrwxr-x 1 TECH905 FSTCI 6664 Jan 24 15:20 curl-config
-rwxrwxr-x 2 TECH905 FSTCI 1634304 Nov 22 2019 diff
-rwxrwxr-x 2 TECH905 FSTCI 671744 Nov 22 2019 diff3
-rwxrwxr-x 1 TECH905 FSTCI 41130 Jan 24 15:19 enc2xs
-rwxrwxr-x 1 TECH905 FSTCI 3092 Jan 24 15:19 encguess
-rwxrwxr-x 2 TECH905 FSTCI 778240 Apr 3 2020 envsubst
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 27 11:26 ex -> vim
-rwxrwxr-x 2 TECH905 FSTCI 172032 Mar 5 2020 ffi_util
-rwxrwxr-x 2 TECH905 FSTCI 884736 Jan 15 2021 funzip
-rwxrwxr-x 2 TECH905 FSTCI 782336 Apr 3 2020 gettext
-rwxrwxr-x 2 TECH905 FSTCI 4629 Apr 3 2020 gettext.sh
-rwxrwxr-x 1 TECH905 FSTCI 43766 Jan 24 15:19 gettextize
-rwxrwxr-x 2 TECH905 FSTCI 2349 Apr 6 2020 gunzip
-rwxrwxr-x 2 TECH905 FSTCI 6379 Apr 6 2020 gzexe
-rwxrwxr-x 2 TECH905 FSTCI 1667072 Apr 6 2020 gzip
-rwxrwxr-x 1 TECH905 FSTCI 29227 Jan 24 15:19 h2ph
-rwxrwxr-x 1 TECH905 FSTCI 60840 Jan 24 15:19 h2xs
lrwxrwxrwx 1 TECH905 FSTCI 7 Jan 24 15:21 idle3 -> idle3.7
-rwxrwxr-x 1 TECH905 FSTCI 106 Jan 24 15:20 idle3.7
-rwxrwxr-x 2 TECH905 FSTCI 1466368 May 6 2020 infocmp
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 24 15:20 infotocap -> tic
-rwxrwxr-x 1 TECH905 FSTCI 4313 Jan 24 15:19 instmodsh
-rwxrwxr-x 1 TECH905 FSTCI 3982 Jan 24 15:19 json_pp
-rwxrwxr-x 1 TECH905 FSTCI 15783 Jan 24 15:19 libnetcfg
lrwxrwxrwx 1 TECH905 FSTCI 2 Jan 24 15:21 lzcat -> xz
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzcmp -> xzdiff
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzdiff -> xzdiff
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzegrep -> xzgrep
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzfgrep -> xzgrep
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzgrep -> xzgrep
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzless -> xzless
lrwxrwxrwx 1 TECH905 FSTCI 2 Jan 24 15:21 lzma -> xz
-rwxrwxr-x 2 TECH905 FSTCI 180224 Dec 24 2019 lzmadec
-rwxrwxr-x 2 TECH905 FSTCI 180224 Dec 24 2019 lzmainfo
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 lzmore -> xzmore
-rwxrwxr-x 2 TECH905 FSTCI 6914048 Apr 3 2020 msgattrib
-rwxrwxr-x 2 TECH905 FSTCI 7024640 Apr 3 2020 msgcat
-rwxrwxr-x 2 TECH905 FSTCI 1757184 Apr 3 2020 msgcmp
-rwxrwxr-x 2 TECH905 FSTCI 7008256 Apr 3 2020 msgcomm
-rwxrwxr-x 2 TECH905 FSTCI 6901760 Apr 3 2020 msgconv
-rwxrwxr-x 2 TECH905 FSTCI 6930432 Apr 3 2020 msgen
-rwxrwxr-x 2 TECH905 FSTCI 1998848 Apr 3 2020 msgexec
-rwxrwxr-x 2 TECH905 FSTCI 7294976 Apr 3 2020 msgfilter
-rwxrwxr-x 2 TECH905 FSTCI 6533120 Apr 3 2020 msgfmt
-rwxrwxr-x 2 TECH905 FSTCI 7241728 Apr 3 2020 msggrep
-rwxrwxr-x 2 TECH905 FSTCI 7397376 Apr 3 2020 msginit
-rwxrwxr-x 2 TECH905 FSTCI 7868416 Apr 3 2020 msgmerge
-rwxrwxr-x 2 TECH905 FSTCI 7409664 Apr 3 2020 msgunfmt
-rwxrwxr-x 2 TECH905 FSTCI 6971392 Apr 3 2020 msguniq
-rwxrwxr-x 1 TECH905 FSTCI 6157 Jan 24 15:18 ncurses6-config
-rwxrwxr-x 2 TECH905 FSTCI 790528 Apr 3 2020 ngettext
-rwxrwxr-x 1 TECH905 FSTCI 27381760 Jan 24 15:19 openssl
-rwxrwxr-x 2 TECH905 FSTCI 122880 Apr 14 2020 perl
-rwxrwxr-x 2 TECH905 FSTCI 122880 Apr 14 2020 perl5.24.4
-rwxrwxr-x 1 TECH905 FSTCI 45419 Jan 24 15:19 perlbug
-rwxrwxr-x 1 TECH905 FSTCI 288 Jan 24 15:19 perldoc
-rwxrwxr-x 1 TECH905 FSTCI 10844 Jan 24 15:19 perlivp
-rwxrwxr-x 1 TECH905 FSTCI 45419 Jan 24 15:19 perlthanks
-rwxrwxr-x 2 TECH905 FSTCI 28426240 Jul 9 2018 php
-rwxrwxr-x 2 TECH905 FSTCI 28237824 Jul 9 2018 php-cgi
-rwxrwxr-x 2 TECH905 FSTCI 3964 Oct 13 2017 php-config
-rwxrwxr-x 2 TECH905 FSTCI 28794880 Jul 9 2018 phpdbg
-rwxrwxr-x 2 TECH905 FSTCI 4544 Jun 21 2017 phpize
-rwxrwxr-x 1 TECH905 FSTCI 8383 Jan 24 15:19 piconv
-rwxrwxr-x 1 TECH905 FSTCI 4557 Jan 24 15:19 pl2pm
-rwxrwxr-x 1 TECH905 FSTCI 4160 Jan 24 15:19 pod2html
-rwxrwxr-x 1 TECH905 FSTCI 14195 Jan 24 15:19 pod2man
-rwxrwxr-x 1 TECH905 FSTCI 11005 Jan 24 15:19 pod2text
-rwxrwxr-x 1 TECH905 FSTCI 3961 Jan 24 15:19 pod2usage
-rwxrwxr-x 1 TECH905 FSTCI 3712 Jan 24 15:19 podchecker
-rwxrwxr-x 1 TECH905 FSTCI 2540 Jan 24 15:19 podselect
-rwxrwxr-x 1 TECH905 FSTCI 13614 Jan 24 15:19 prove
-rwxrwxr-x 1 TECH905 FSTCI 36772 Jan 24 15:19 pstruct
-rwxrwxr-x 1 TECH905 FSTCI 3588 Jan 24 15:19 ptar
-rwxrwxr-x 1 TECH905 FSTCI 2654 Jan 24 15:19 ptardiff
-rwxrwxr-x 1 TECH905 FSTCI 4418 Jan 24 15:19 ptargrep
lrwxrwxrwx 1 TECH905 FSTCI 8 Jan 24 15:21 pydoc -> pydoc3.7
lrwxrwxrwx 1 TECH905 FSTCI 8 Jan 24 15:21 pydoc3 -> pydoc3.7
-rwxrwxr-x 1 TECH905 FSTCI 91 Jan 24 15:20 pydoc3.7
lrwxrwxrwx 1 TECH905 FSTCI 9 Jan 24 15:21 python -> python3.7
lrwxrwxrwx 1 TECH905 FSTCI 9 Jan 24 15:21 python3 -> python3.7
lrwxrwxrwx 1 TECH905 FSTCI 17 Jan 24 15:21 python3-config -> python3.7m-config
-rwxrwxr-x 1 TECH905 FSTCI 155648 Dec 22 2020 python3.7
lrwxrwxrwx 1 TECH905 FSTCI 17 Jan 24 15:21 python3.7-config -> python3.7m-config
-rwxrwxr-x 2 TECH905 FSTCI 155648 Dec 22 2020 python3.7m
-rwxrwxr-x 1 TECH905 FSTCI 3202 Jan 24 15:20 python3.7m-config
lrwxrwxrwx 1 TECH905 FSTCI 10 Jan 24 15:21 pyvenv -> pyvenv-3.7
-rwxrwxr-x 1 TECH905 FSTCI 448 Jan 24 15:20 pyvenv-3.7
-rwxrwxr-x 2 TECH905 FSTCI 794624 Apr 3 2020 recode-sr-latin
lrwxrwxrwx 1 TECH905 FSTCI 4 Jan 24 15:20 reset -> tset
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 27 11:26 rview -> vim
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 27 11:26 rvim -> vim
-rwxrwxr-x 2 TECH905 FSTCI 589824 Nov 22 2019 sdiff
-rwxrwxr-x 1 TECH905 FSTCI 1011712 Jan 27 11:26 sed
-rwxrwxr-x 1 TECH905 FSTCI 9396 Jan 24 15:19 shasum
-rwxrwxr-x 1 TECH905 FSTCI 18834 Jan 24 15:19 splain
-rwxrwxr-x 2 TECH905 FSTCI 5193728 Jun 1 2018 sqlite3
-rwxrwxr-x 1 BPXROOT FSTCI 12103680 Jan 27 11:26 sudo
lrwxrwxrwx 1 TECH905 FSTCI 4 Jan 27 11:26 sudoedit -> sudo
-rwxrwxr-x 1 TECH905 FSTCI 991232 Jan 27 11:26 sudoreplay
-rwxrwxr-x 2 TECH905 FSTCI 933888 May 6 2020 tabs
-rwxrwxr-x 2 TECH905 FSTCI 1622016 May 6 2020 tic
-rwxrwxr-x 2 TECH905 FSTCI 1187840 May 6 2020 toe
-rwxrwxr-x 2 TECH905 FSTCI 1028096 May 6 2020 tput
-rwxrwxr-x 2 TECH905 FSTCI 995328 May 6 2020 tset
lrwxrwxrwx 1 TECH905 FSTCI 2 Jan 24 15:21 unlzma -> xz
lrwxrwxrwx 1 TECH905 FSTCI 2 Jan 24 15:21 unxz -> xz
-rwxrwxr-x 2 TECH905 FSTCI 2260992 Jan 15 2021 unzip
-rwxrwxr-x 2 TECH905 FSTCI 1867776 Jan 15 2021 unzipsfx
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 27 11:26 view -> vim
-rwxrwxr-x 1 TECH905 FSTCI 11534336 Jan 27 11:26 vim
lrwxrwxrwx 1 TECH905 FSTCI 3 Jan 27 11:26 vimdiff -> vim
-rwxrwxr-x 2 TECH905 FSTCI 2099 Mar 18 2020 vimtutor
-rwxrwxr-x 2 TECH905 FSTCI 10072064 Apr 3 2020 xgettext
-rwxrwxr-x 1 TECH905 FSTCI 5190 Jan 24 15:19 xsubpp
-rwxrwxr-x 2 TECH905 FSTCI 135168 Mar 18 2020 xxd
-rwxrwxr-x 2 TECH905 FSTCI 712704 Dec 24 2019 xz
lrwxrwxrwx 1 TECH905 FSTCI 2 Jan 24 15:21 xzcat -> xz
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 xzcmp -> xzdiff
-rwxrwxr-x 2 TECH905 FSTCI 180224 Dec 24 2019 xzdec
-rwxrwxr-x 2 TECH905 FSTCI 6653 Dec 24 2019 xzdiff
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 xzegrep -> xzgrep
lrwxrwxrwx 1 TECH905 FSTCI 6 Jan 24 15:21 xzfgrep -> xzgrep
-rwxrwxr-x 2 TECH905 FSTCI 5649 Dec 24 2019 xzgrep
-rwxrwxr-x 2 TECH905 FSTCI 1823 Dec 24 2019 xzless
-rwxrwxr-x 2 TECH905 FSTCI 2182 Dec 24 2019 xzmore
-rwxrwxr-x 2 TECH905 FSTCI 1987 Apr 6 2020 zcat
-rwxrwxr-x 2 TECH905 FSTCI 1681 Apr 6 2020 zcmp
-rwxrwxr-x 2 TECH905 FSTCI 5883 Apr 6 2020 zdiff
-rwxrwxr-x 2 TECH905 FSTCI 29 Apr 6 2020 zegrep
-rwxrwxr-x 2 TECH905 FSTCI 29 Apr 6 2020 zfgrep
-rwxrwxr-x 2 TECH905 FSTCI 2084 Apr 6 2020 zforce
-rwxrwxr-x 2 TECH905 FSTCI 7586 Apr 6 2020 zgrep
-rwxrwxr-x 2 TECH905 FSTCI 1523712 Dec 30 2020 zip
-rwxrwxr-x 2 TECH905 FSTCI 1024000 Dec 30 2020 zipcloak
-rwxrwxr-x 1 TECH905 FSTCI 48523 Jan 24 15:19 zipdetails
-rwxrwxr-x 2 TECH905 FSTCI 2953 Jan 15 2021 zipgrep
-rwxrwxr-x 2 TECH905 FSTCI 2260992 Jan 15 2021 zipinfo
-rwxrwxr-x 2 TECH905 FSTCI 1007616 Dec 30 2020 zipnote
-rwxrwxr-x 2 TECH905 FSTCI 1011712 Dec 30 2020 zipsplit
-rwxrwxr-x 2 TECH905 FSTCI 2209 Apr 6 2020 zless
-rwxrwxr-x 2 TECH905 FSTCI 1845 Apr 6 2020 zmore
-rwxrwxr-x 2 TECH905 FSTCI 4556 Apr 6 2020 znew
TECH905@jismvs_test-> find / -name cp -exec ls -l {} ";"
-rwxr-xr-x 2 BPXROOT FSTCI 380928 Dec 30 2020 /bin/cp
total 16
drwx------ 3 WEBSRV1 FSTCI 8192 Jul 30 2016 RkvVL__uIOTsSiVasG1w.header.vary
TECH905@jismvs_test->
I can work on getting the conda list for you.
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
Hi Tom,
I am a software developer who works on open-source tools here at Rocket.
Your problem is concerning to me because, from what you've described, it seems that you've installed a package that includes `cp` as a binary. We only have one package that fits that description and it is meant only for internal use here at Rocket. We use it to test software that expects GNU coreutils like behavior from cp (not z/OS /bin/cp behavior). Let's first check that this is the problem and then determine how to proceed.
First, you can check which cp binary is being called by `which cp`. If you try that with a $PATH beginning/ending with ~/bin that will tell you if you are calling a different cp binary in each case.
Second, could you activate your conda environment and post the result of `conda list`? This will show all the packages you have installed and I can check if the package with GNU cp is included in the installed list.
Lastly, if you list the contents of `~/bin` you may see a binary named `cp`. Let me know either way. But if you do see such a binary that will be the problem.
Thanks for reaching out,
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
I am a software developer who works on open-source tools here at Rocket.
Your problem is concerning to me because, from what you've described, it seems that you've installed a package that includes `cp` as a binary. We only have one package that fits that description and it is meant only for internal use here at Rocket. We use it to test software that expects GNU coreutils like behavior from cp (not z/OS /bin/cp behavior). Let's first check that this is the problem and then determine how to proceed.
First, you can check which cp binary is being called by `which cp`. If you try that with a $PATH beginning/ending with ~/bin that will tell you if you are calling a different cp binary in each case.
Second, could you activate your conda environment and post the result of `conda list`? This will show all the packages you have installed and I can check if the package with GNU cp is included in the installed list.
Lastly, if you list the contents of `~/bin` you may see a binary named `cp`. Let me know either way. But if you do see such a binary that will be the problem.
Thanks for reaching out,
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
Here is a conda info
TECH905@jismvs_test-> conda info
active environment : None
shell level : 0
user config file : /u/tech905/.condarc
populated config files : /usr/local/Rocket/miniconda/.condarc
conda version : 4.5.8
conda-build version : conda-build-3.12.0-py37_2+3.g8ab3902b
python version : 3.7.0.final.0
base environment : /usr/local/Rocket/miniconda (writable)
channel URLs : https://repo.anaconda.com/pkgs/main/zos-z
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/free/zos-z
https://repo.anaconda.com/pkgs/free/noarch
https://repo.anaconda.com/pkgs/r/zos-z
https://repo.anaconda.com/pkgs/r/noarch
https://repo.anaconda.com/pkgs/pro/zos-z
https://repo.anaconda.com/pkgs/pro/noarch
package cache : /usr/local/Rocket/miniconda/pkgs
/u/tech905/.conda/pkgs
envs directories : /usr/local/Rocket/miniconda/envs
/u/tech905/.conda/envs
platform : zos-z
user-agent : conda/4.5.8 requests/2.19.1 CPython/3.7.0 z/OS/2.4 z/OS/0
UID:GID : 905:1
netrc file : None
offline mode : False
TECH905@jismvs_test->
Here is the conda list (it is lengthy and I did not see cp or coreutils
One thing I did notice is a package called autotag. Since my problem has a conversion element to it, this package is high on my suspect list.
TECH905@jismvs_test-> conda list
# packages in environment at /usr/local/Rocket/miniconda:
#
# Name Version Build Channel
anaconda-client 1.7.2 py37_2 https://condaserver.rocketsoftware.com/api/repo/defaults
asn1crypto 0.24.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
autotag 0.5 10 https://condaserver.rocketsoftware.com/api/repo/defaults
bash 4.3.48 2 https://condaserver.rocketsoftware.com/api/repo/defaults
beautifulsoup4 4.6.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
bzip2 1.0.6 6 https://condaserver.rocketsoftware.com/api/repo/defaults
certifi 2018.4.16 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
cffi 1.11.5 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
chardet 3.0.4 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
click 6.7 py37_1 https://condaserver.rocketsoftware.com/api/repo/defaults
clyent 1.2.1 py37_1 https://condaserver.rocketsoftware.com/api/repo/defaults
conda 4.5.8 py37_11 https://condaserver.rocketsoftware.com/api/repo/defaults
conda-build 3.12.0 py37_5 https://condaserver.rocketsoftware.com/api/repo/defaults
conda-repo-cli 1.0.1+2.g39f4600 py_0
conda-verify 3.0.2 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
cryptography 2.3 py37_3 https://condaserver.rocketsoftware.com/api/repo/defaults
decorator 4.3.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
filelock 3.0.4 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
future 0.16.0 py37_1 https://condaserver.rocketsoftware.com/api/repo/defaults
gettext 0.19.8.1 1 https://condaserver.rocketsoftware.com/api/repo/defaults
glob2 0.6 py37_2 https://condaserver.rocketsoftware.com/api/repo/defaults
idna 2.7 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
ipython_genutils 0.2.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
jinja2 2.10 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
jsonschema 2.6.0 py37_1 https://condaserver.rocketsoftware.com/api/repo/defaults
jupyter_core 4.4.0 py37_2 https://condaserver.rocketsoftware.com/api/repo/defaults
libffi 3.2.1 6 https://condaserver.rocketsoftware.com/api/repo/defaults
markupsafe 1.0 py37_5 https://condaserver.rocketsoftware.com/api/repo/defaults
nbformat 4.4.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
ncurses 6.1 10 https://condaserver.rocketsoftware.com/api/repo/defaults
openssl 1.0.2k 5 https://condaserver.rocketsoftware.com/api/repo/defaults
pkginfo 1.4.2 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pyasn1 0.4.3 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pycosat 0.6.3 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pycparser 2.18 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pyopenssl 18.0.0 py37_2 https://condaserver.rocketsoftware.com/api/repo/defaults
python 3.7.0 30 https://condaserver.rocketsoftware.com/api/repo/defaults
python-dateutil 2.7.3 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pytz 2018.5 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
pyyaml 3.13 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
readline 7.0 3 https://condaserver.rocketsoftware.com/api/repo/defaults
requests 2.19.1 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
ruamel_yaml 0.15.43 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
setuptools 40.0.0 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
six 1.14.0 py37_2 https://condaserver.rocketsoftware.com/api/repo/defaults
sqlite 3.23.1 0 https://condaserver.rocketsoftware.com/api/repo/defaults
traitlets 4.3.2 py37_1 https://condaserver.rocketsoftware.com/api/repo/defaults
urllib3 1.23 py37_0 https://condaserver.rocketsoftware.com/api/repo/defaults
xz 5.2.3 2 https://condaserver.rocketsoftware.com/api/repo/defaults
yaml 0.1.6 1 https://condaserver.rocketsoftware.com/api/repo/defaults
zlib 1.2.11 4 https://condaserver.rocketsoftware.com/api/repo/defaults
TECH905@jismvs_test->
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
Here is a new puzzler.
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
After my initial headaches using miniconda (see other threads here), I finally had a set of installed languages and tools in a ~/bin directory. This bin was placed in my PATH.
I then moved on to my next project of adding CO:Z tools from Rocket Software. The process has worked reliably for many years without flaws.
This time, it failed because when the script used the cp command to copy from an untagged binary unpaxed unix file to a member in a PDS dataset, the binary EBCDIC source was being converted again and the <<newline>> sequence was not causing records level breaks in the data. This caused the entire source file to become one big logical line. The target PDS could not put all that data in a logical record and the cp command failed.
As part of the debugging I confirmed that all AUTOCVT values were disabled (file level tags, file system mount commands, CEE environment vars, BPXK vars, etc).
All attempts to get a clean script run failed.
A solution was found by using the rule of 'What changed?' --- This led me back to where I placed the Rocket bin file in my PATH. In the past, it was at the end of the PATH variable. This time I installed it at the front so the new versions would be selected before any previously installed versions. By moving back to the end of the PATH search, cp worked as it always had and the Rocket install script finished without problems.
What in the Rocket installed languages and Tools could override the basic operating system functions of cp?
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
PMFJI here. I've been in contact with the Dovetailed guys WRT this issue and my diagnosis is that this is a problem with sed and not cp. When you have installed Rocket ported tools your PATH includes Rockets sed which requires Enhanced ASCII. The Dovetailed installation coz/sampjcl files are not tagged so Rockets sed is assuming the files are encoded in ASCII. To circumvent this I issued the following.
chtag -Rtc 1047 ~/coz/sampjcl
~/coz/install/install-sampjcl.sh ~/coz $USER.coz.sampjcl $USER.coz.loadlibAlternatively, you can rename sed in your Ported Tools ported/bin directory so z/OS /bin/sed will be invoked which will work without file tagging. A valid argument could be made that Rocket sed should default to 1047 if the file is not tagged, which is the behavior of z/OS sed.
------------------------------
David Crayford
Software Engineer
Rocket Internal - All Brands
------------------------------
PMFJI here. I've been in contact with the Dovetailed guys WRT this issue and my diagnosis is that this is a problem with sed and not cp. When you have installed Rocket ported tools your PATH includes Rockets sed which requires Enhanced ASCII. The Dovetailed installation coz/sampjcl files are not tagged so Rockets sed is assuming the files are encoded in ASCII. To circumvent this I issued the following.
chtag -Rtc 1047 ~/coz/sampjcl
~/coz/install/install-sampjcl.sh ~/coz $USER.coz.sampjcl $USER.coz.loadlibAlternatively, you can rename sed in your Ported Tools ported/bin directory so z/OS /bin/sed will be invoked which will work without file tagging. A valid argument could be made that Rocket sed should default to 1047 if the file is not tagged, which is the behavior of z/OS sed.
------------------------------
David Crayford
Software Engineer
Rocket Internal - All Brands
------------------------------
After running into several problems from several software providers related to mixed charater sets being supported on the same server, my only suggestion is to "know your audience" and find easier ways to support the EBCDIC world when delivering to s390x systems. This is a recommendation to all open source providers. You are performing a port of code to a different platform without handling the differences on that specific platform.
I am not trying to start a flame war, just expressing one mans opinion :)
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
Thanks for the definitive answer on the problem.
After running into several problems from several software providers related to mixed charater sets being supported on the same server, my only suggestion is to "know your audience" and find easier ways to support the EBCDIC world when delivering to s390x systems. This is a recommendation to all open source providers. You are performing a port of code to a different platform without handling the differences on that specific platform.
I am not trying to start a flame war, just expressing one mans opinion :)
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
After running into several problems from several software providers related to mixed charater sets being supported on the same server, my only suggestion is to "know your audience" and find easier ways to support the EBCDIC world when delivering to s390x systems. This is a recommendation to all open source providers. You are performing a port of code to a different platform without handling the differences on that specific platform.
I am not trying to start a flame war, just expressing one mans opinion :)
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
FWIW, I don't work on Ported Tools. The Dovetailed guys reached out to me personally as we have known each other for many years. I can appreciate their frustration that their installation script failed as it has been working for years.
@Harrison Kaiser IMO, Rockets sed port should work in the same way as z/OS POSIX sed and treat untagged files as encoded in 1047. Is this possible?
------------------------------
David Crayford
Software Engineer
Rocket Internal - All Brands
------------------------------
PMFJI here. I've been in contact with the Dovetailed guys WRT this issue and my diagnosis is that this is a problem with sed and not cp. When you have installed Rocket ported tools your PATH includes Rockets sed which requires Enhanced ASCII. The Dovetailed installation coz/sampjcl files are not tagged so Rockets sed is assuming the files are encoded in ASCII. To circumvent this I issued the following.
chtag -Rtc 1047 ~/coz/sampjcl
~/coz/install/install-sampjcl.sh ~/coz $USER.coz.sampjcl $USER.coz.loadlibAlternatively, you can rename sed in your Ported Tools ported/bin directory so z/OS /bin/sed will be invoked which will work without file tagging. A valid argument could be made that Rocket sed should default to 1047 if the file is not tagged, which is the behavior of z/OS sed.
------------------------------
David Crayford
Software Engineer
Rocket Internal - All Brands
------------------------------
That link went to the Rocket bin sed entry. Needless to say, I have deleted that link.
With the Rocket bin at the end of my PATH (more or less as a backstop) the only sed a default user sees is the IBM POSIX sed.
All is well!
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
FWIW, I don't work on Ported Tools. The Dovetailed guys reached out to me personally as we have known each other for many years. I can appreciate their frustration that their installation script failed as it has been working for years.
@Harrison Kaiser IMO, Rockets sed port should work in the same way as z/OS POSIX sed and treat untagged files as encoded in 1047. Is this possible?
------------------------------
David Crayford
Software Engineer
Rocket Internal - All Brands
------------------------------
I'm the install architect for WebSphere Application Server on z/OS, and we recently had an install failure caused by the customer's having "their own version of sed" in the USS path; we corrected it by explicitly invoking /bin/sed from our scripts. It sounds like we just hit the same issue - an install script that ran for years until hitting this change.
------------------------------
Jeff Mierzejewski
System Test Lead, WebSphere Application Server
Endicott NY US
------------------------------
I had created a symbolic link in a local /usr/bin file in my PATH.
That link went to the Rocket bin sed entry. Needless to say, I have deleted that link.
With the Rocket bin at the end of my PATH (more or less as a backstop) the only sed a default user sees is the IBM POSIX sed.
All is well!
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
That link went to the Rocket bin sed entry. Needless to say, I have deleted that link.
With the Rocket bin at the end of my PATH (more or less as a backstop) the only sed a default user sees is the IBM POSIX sed.
All is well!
------------------------------
Tom Longfellow
Senior Systems Programmer
Maryland Judicial Information Systems (JIS)
Annapolis MD US
------------------------------
Glad you found the issue. Monday was the first time I posted to the forum and I had a few issues posting.
Thanks for taking the time to write on our forum.
Harrison Kaiser.
------------------------------
Harrison Kaiser
Software Engineer I
Rocket Internal - All Brands
------------------------------
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
