Admin note: there was a thread here where a user was having an installer problem with CoZ. Due to my screw-up, it was accidentally deleted. Sorry!
The problem turns out to be this:
If you have installed Rocket Tools and you try to install Co:Z, you can run into a problem. The problem is that Rocket's version of the "sed" command is not compatible with IBM /bin/sed, since it will not work on untagged files. Since the Co:Z installer uses the sed command this causes problems if Rocket's tools are in the PATH environment before /bin.
Customers should run the installer without Rocket tools in PATH to avoid this issue.
For assistance with Rocket tools, please contact Rocket.
CO:Z Install problem 7.0.2.bin
Re: CO:Z Install problem 7.0.2.bin
Here is a log of this thread before it was accidentally deleted:
-- Posted by tlongfellow — Thu Feb 24, 2022 2:08 pm
For the first time in more years than I can count the coz install bin fails to complete correctly.
It fails copying the COZCFGD member into the sampjcl.
Code:
FSUM6260 write error on file "//'SYS3.COZ.SAMPJCL(COZCFGD)'": EDC5003I Truncation of a record occurred during an I/O operation.
I am reusing and overwriting the existing file. My cohort has tried going to new datasets with similar results.
We are: z/OS 2.3 AND z/OS 2.4 and trying an install of
> ./coz-7.0.2.bin
Any suggestions??
======================================================
-- Posted by tlongfellow — Thu Feb 24, 2022 4:25 pm
I know. I know. Replying to yourself is a sign of schizophrenia, but here goes.
I have compared old and new copies of the COZCNFG member in the PDS. Somewhere along the line a character set translation has happened. The raw zFS file is readable via ISPF --- The installed copy in the PDS is one truncated line that starts {{{{{{
I am convinced that some combination of file tagging and AUTOCVT environment variables will get me out of this I just need to know how to integrate it with the standard instill process
======================================================
-- Posted by dovetail — Fri Feb 25, 2022 11:15 am
Please verify the install file integrity:
> cksum coz-7.0.2.bin
3977495064 15017534 coz-7.0.2.bin
======================================================
-- Posted by tlongfellow — Fri Feb 25, 2022 11:52 am
The checksum was validated.
======================================================
-- Posted by dovetail — Wed Mar 02, 2022 10:36 am
> I am convinced that some combination of file tagging and AUTOCVT environment variables will get me out of this
First check to see that some combination of file tagging and AUTOCVT didn't get you *in* to this:
Rerun the install from scratch, but first:
1a) Is AUTOCVT(ON) set in your OMVS options?
or:
1b) before executing the installer, issues the "env" command and see if you have _BPXK_AUTOCVT=ON
2) Are you installing Co:Z (the target directory) into a zFS directory in a filesystem mounted with TAG() ?
3) Run the installer
4) After it fails:
cd <coz_inst>/sampjcl
chtag -p *
All of the files should be untagged.
If you have an environment where AUTOCVT is set on AND you are automatically tagging the files as then are unloaded to the zFS, then you have shot yourself in the foot.
======================================================
-- Posted by tlongfellow — Wed Mar 02, 2022 2:23 pm
No joy yet --- here is what we tried
1. reconfirmed the cksum as correct
2. removed any overrides to the _BPX_AUTOCVT var (confirmed in env display)
3. removed _CEE_RUNOPTS overrides for AUTOTAG and AUTOCVT (confirmed in env display)
4. Same error if run in either the 'bash' or 'sh' shells. The 'sh' user has never overridden the env variables.
5. The filesystems are mounted with override to the TAG() value --- we assume that the default of tag(notext,0) is in use.
6. We even did a fallback to install the backlevel 6.1.3 coz bin file --- same failure.
We still cannot complete a clean install. Any other ideas?
Here is the display from the command against the source
Code:
chtag -p *- untagged T=off @@README- untagged T=off COZCFGD- untagged T=off COZPROC- untagged T=off DTLSPAWN- untagged T=off GPGDSN- untagged T=off GREPDSN- untagged T=off OFFLDSMF- untagged T=off RACDCERT- untagged T=off RUNLNCH- untagged T=off RUNLNCHK- untagged T=off RUNLNCHP- untagged T=off RUNSFTP- untagged T=off RUNSFTPK- untagged T=off RUNSFTPS- untagged T=off RUNSHELL- untagged T=off SFTPIND- untagged T=off SFTPPROC- untagged T=off SFTPSAMP- untagged T=off SSHIND- untagged T=off SSHPROC- untagged T=off SSHSAMP- untagged T=off WGET2DSN
======================================================
-- Posted by dovetail — Thu Mar 03, 2022 11:19 am
It's hard to tell, but it seems like you have many things going on that might cause files to be automatically converted when they are either read or written from zFS. Of particular concern is that you would *ever* set _CEE_RUNOPTS to include AUTOTAG or AUTOCVT in a profile. This should only be done for a particular program that expects conversion (i.e. the program runs in ASCII).
I would suggest that you start over with:
- completely clean and minimal environment variables.
- a new filesystem without TAG,
- without any OMVS system options that enable conversion or tagging
- without an system LE options that enable conversion or tagging
- a userid with PGM(/bin/sh)
- since in theory it is even possible that your installer has been converted (but is converted back when you do a cksum), you should probably download that fresh.
What I can tell you is that in 15 years this is the only time that we have ever seen this.
======================================================
-- Posted by tlongfellow — Thu Mar 03, 2022 1:54 pm
I know. This is baffling me as well.
The reason those environment variables and the use of the bash shell was because the Rocket Software Open Source tools required it to run their anaconda (miniconda) installer.
To address your concerns:
- completely clean and minimal environment variables.
I changed all profiles in my id to no longer set those environment variables. This was confirmed with an 'env' command before calling the coz .bin file
- a new filesystem without TAG,
All of our file systems are mounted as TYPE(ZFS) with no TAG specification. I do not even know howto do that
- without any OMVS system options that enable conversion or tagging
SDSF File System Display shows AUTOCVT OFF
- without an system LE options that enable conversion or tagging
see above - all _CEE environment variables have been removed
- a userid with PGM(/bin/sh)
My cohort has used that shell by default and receives the same cp copy problem
- since in theory it is even possible that your installer has been converted (but is converted back when you do a cksum), you should probably download that fresh.
That's a stretch. any corruption should be found in the cksum (i have had this problem in the ancient past when a 'text' upload was performed to the mainframe. And this problem also occurs with coz 6.1 bin files as source. --- the 6.1 versions worked fine at that time
I can find nothing else to try at this point. Except looking for reports of 'cp' failures, which would be unlikely to be found in the wild without major impacts to lots of systems.
======================================================
-- Posted by dovetail — Fri Mar 04, 2022 12:28 pm
At this point we don't know how to help you. Since you can reproduce the problem with an old version of Co:Z (that worked before), then it is obviously something in your environment that we don't know about or understand that is causing files to be converted.
If you are able to figure it out, we would appreciate that you post information here on what it was.
-- Posted by tlongfellow — Thu Feb 24, 2022 2:08 pm
For the first time in more years than I can count the coz install bin fails to complete correctly.
It fails copying the COZCFGD member into the sampjcl.
Code:
FSUM6260 write error on file "//'SYS3.COZ.SAMPJCL(COZCFGD)'": EDC5003I Truncation of a record occurred during an I/O operation.
I am reusing and overwriting the existing file. My cohort has tried going to new datasets with similar results.
We are: z/OS 2.3 AND z/OS 2.4 and trying an install of
> ./coz-7.0.2.bin
Any suggestions??
======================================================
-- Posted by tlongfellow — Thu Feb 24, 2022 4:25 pm
I know. I know. Replying to yourself is a sign of schizophrenia, but here goes.
I have compared old and new copies of the COZCNFG member in the PDS. Somewhere along the line a character set translation has happened. The raw zFS file is readable via ISPF --- The installed copy in the PDS is one truncated line that starts {{{{{{
I am convinced that some combination of file tagging and AUTOCVT environment variables will get me out of this I just need to know how to integrate it with the standard instill process
======================================================
-- Posted by dovetail — Fri Feb 25, 2022 11:15 am
Please verify the install file integrity:
> cksum coz-7.0.2.bin
3977495064 15017534 coz-7.0.2.bin
======================================================
-- Posted by tlongfellow — Fri Feb 25, 2022 11:52 am
The checksum was validated.
======================================================
-- Posted by dovetail — Wed Mar 02, 2022 10:36 am
> I am convinced that some combination of file tagging and AUTOCVT environment variables will get me out of this
First check to see that some combination of file tagging and AUTOCVT didn't get you *in* to this:
Rerun the install from scratch, but first:
1a) Is AUTOCVT(ON) set in your OMVS options?
or:
1b) before executing the installer, issues the "env" command and see if you have _BPXK_AUTOCVT=ON
2) Are you installing Co:Z (the target directory) into a zFS directory in a filesystem mounted with TAG() ?
3) Run the installer
4) After it fails:
cd <coz_inst>/sampjcl
chtag -p *
All of the files should be untagged.
If you have an environment where AUTOCVT is set on AND you are automatically tagging the files as then are unloaded to the zFS, then you have shot yourself in the foot.
======================================================
-- Posted by tlongfellow — Wed Mar 02, 2022 2:23 pm
No joy yet --- here is what we tried
1. reconfirmed the cksum as correct
2. removed any overrides to the _BPX_AUTOCVT var (confirmed in env display)
3. removed _CEE_RUNOPTS overrides for AUTOTAG and AUTOCVT (confirmed in env display)
4. Same error if run in either the 'bash' or 'sh' shells. The 'sh' user has never overridden the env variables.
5. The filesystems are mounted with override to the TAG() value --- we assume that the default of tag(notext,0) is in use.
6. We even did a fallback to install the backlevel 6.1.3 coz bin file --- same failure.
We still cannot complete a clean install. Any other ideas?
Here is the display from the command against the source
Code:
chtag -p *- untagged T=off @@README- untagged T=off COZCFGD- untagged T=off COZPROC- untagged T=off DTLSPAWN- untagged T=off GPGDSN- untagged T=off GREPDSN- untagged T=off OFFLDSMF- untagged T=off RACDCERT- untagged T=off RUNLNCH- untagged T=off RUNLNCHK- untagged T=off RUNLNCHP- untagged T=off RUNSFTP- untagged T=off RUNSFTPK- untagged T=off RUNSFTPS- untagged T=off RUNSHELL- untagged T=off SFTPIND- untagged T=off SFTPPROC- untagged T=off SFTPSAMP- untagged T=off SSHIND- untagged T=off SSHPROC- untagged T=off SSHSAMP- untagged T=off WGET2DSN
======================================================
-- Posted by dovetail — Thu Mar 03, 2022 11:19 am
It's hard to tell, but it seems like you have many things going on that might cause files to be automatically converted when they are either read or written from zFS. Of particular concern is that you would *ever* set _CEE_RUNOPTS to include AUTOTAG or AUTOCVT in a profile. This should only be done for a particular program that expects conversion (i.e. the program runs in ASCII).
I would suggest that you start over with:
- completely clean and minimal environment variables.
- a new filesystem without TAG,
- without any OMVS system options that enable conversion or tagging
- without an system LE options that enable conversion or tagging
- a userid with PGM(/bin/sh)
- since in theory it is even possible that your installer has been converted (but is converted back when you do a cksum), you should probably download that fresh.
What I can tell you is that in 15 years this is the only time that we have ever seen this.
======================================================
-- Posted by tlongfellow — Thu Mar 03, 2022 1:54 pm
I know. This is baffling me as well.
The reason those environment variables and the use of the bash shell was because the Rocket Software Open Source tools required it to run their anaconda (miniconda) installer.
To address your concerns:
- completely clean and minimal environment variables.
I changed all profiles in my id to no longer set those environment variables. This was confirmed with an 'env' command before calling the coz .bin file
- a new filesystem without TAG,
All of our file systems are mounted as TYPE(ZFS) with no TAG specification. I do not even know howto do that
- without any OMVS system options that enable conversion or tagging
SDSF File System Display shows AUTOCVT OFF
- without an system LE options that enable conversion or tagging
see above - all _CEE environment variables have been removed
- a userid with PGM(/bin/sh)
My cohort has used that shell by default and receives the same cp copy problem
- since in theory it is even possible that your installer has been converted (but is converted back when you do a cksum), you should probably download that fresh.
That's a stretch. any corruption should be found in the cksum (i have had this problem in the ancient past when a 'text' upload was performed to the mainframe. And this problem also occurs with coz 6.1 bin files as source. --- the 6.1 versions worked fine at that time
I can find nothing else to try at this point. Except looking for reports of 'cp' failures, which would be unlikely to be found in the wild without major impacts to lots of systems.
======================================================
-- Posted by dovetail — Fri Mar 04, 2022 12:28 pm
At this point we don't know how to help you. Since you can reproduce the problem with an old version of Co:Z (that worked before), then it is obviously something in your environment that we don't know about or understand that is causing files to be converted.
If you are able to figure it out, we would appreciate that you post information here on what it was.