Original Message:
Sent: 05-12-2024 19:37
From: Gary Freestone
Subject: Unable to perform a "git add" on z/OS 3.1 system
Thought I'd give you an update on my continued investigation of this issue.
First let me say that I don't believe it's a Git issue but z/OS 3.1 is acting differently on USS files than it did in previous releases. It relates to how files are tagged. Let me explain.
For starters, there is some confusion about the tagging of USS files. Does tagging files mean assigning a CCSID, such as IBM-1047/ISO8859-1/UTF-8 ? Does tagging mean turning on the eligible flag for auto-conversion ? or is it both ? Looking at the Rocket's installation information for 2.26.2 (the one I have installed) it seems to mean both.
In this example the -t option turns on the auto-conversion flag and the -c option assigns the CCSID.
In z/OS 3.1 the auto-conversion flag seems to be used by more utilities than prior releases and this ultimately is causing my problem. Let me explain why:
We have a default set of git attributes kept, where we keep most source, in a PDS. This member is transferred to USS, when required, via the following TSO commands in a batch job.
OCOPY INDD(INPUT1) OUTDD(OUTPUT1) TEXT CONVERT((BPXFX311)) FROM1047
OSHELL chtag -tc ISO8859-1 &PLMNT/.zGIT-templates/info/attributes
Where INPUT1 and OUTPUT1 are:
//INPUT1 DD DSN=SYS1.ZGIT.PARMLIB(GITATTR),DISP=SHR
//OUTPUT1 DD PATH='&PLMNT/.zGIT-templates/info/attributes',
// PATHOPTS=(OWRONLY,OCREAT),
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH),
// FILEDATA=TEXT
Where &PLMNT is a symbol that defines the Git template path in USS. The symbol is defined in the job's JCL.
The OCOPY command copies the GITATTR member from the PDS to the USS file converting it from IBM1047 (EBCDIC) to ISO8859-1 (ASCII), as required by Git.
The chtag command assigns the correct tagging, with ISO8859-1 as the CCSID and turning on the auto-conversion, as indicated by Rocket.
Before running a "git init" command, environment variable GIT_TEMPLATE_DIR is created and given the value of &PLMNT/.zGIT-templates. When the "git init" command is run, Git copies &PLMNT/.zGIT-templates/info/attributes into the .git/info/attributes file, as expected, and the "git init" finishes without an issue.
If however, our default attributes, stored in the PDS, are updated then we just re-run the batch job to execute the OCOPY/CHATG command again to update the USS files.
This worked fine on z/OS systems prior to 3.1 but it does not work on 3.1 (sometimes).
It does work if the &PLMNT/.zGIT-templates/info/attributes file does not exist when the OCOPY is executed.
It does not work if the &PLMNT/.zGIT-templates/info/attributes already exists, or more correctly the PDS member is copied OK but the USS file is "corrupted".
I believe that in z/OS 3.1, the system recognizes that the file already exists, its been encoded as ISO8859-1 (ASCII), and it has the auto-conversion flag on. This is causing the system to automatically convert incoming data from IBM-1047 (EBCDIC) to ISO8859-1.
The problem is that my OCOPY command is performing the EBCDIC to ASCII conversion. The result being I end up with a file that has been converted twice. EBCDIC => ASCII => ASCII making the file unusable by Git (or anything else).
The "git init" still works and git does copy the "corrupted" file from &PLMNT/.zGIT-templates/info/attributes to .git/info/attributes successfully. But when a "git add ." command is executed, and I try and add some files to my repo that have been tagged at IBM-1047, git cannot find a valid attribute statements in the corrupt file resulting in the message I reported in my initial forum entry, namely
fatal: can't add "zGIT-DS-Attributes": file is tagged, set corresponding zos-working-tree-encoding attribute or reset file tag
As I said this does not happen on USS files prior to z/OS 3.1.
Of course now I know what is going on, I will fix my copy job by removing the -t option from the chtag command. So z/OS will not automatically do a second conversion.
If you want another example of z/OS 3.1 acting different, try issuing a "B" (browse) line command in ISPF option 3.17 on a file that has been tagged with "chtag -t -c ISO8859-1". Totally different results for z/OS 3.1 vs the prior releases.
------------------------------
Gary Freestone
Systems Programmer
Kyndryl Inc
Mt Helen VIC AU
Original Message:
Sent: 05-01-2024 23:05
From: Benjamin Maloy
Subject: Unable to perform a "git add" on z/OS 3.1 system
Hey Gary,
Thanks for letting us know you have a problem with git on zOS 3.1. We will investigate the issue. In the meantime, you could try using the most up to date version of git that we have available, git 2.44.
Also, do you have a repository level .gitattributes? You can also check if your XDG_CONFIG_HOME environment variable is set and the same on both systems.
Best,
Ben
------------------------------
Benjamin Maloy
Software Engineer I
Rocket Internal - All Brands
Medford MA US
Original Message:
Sent: 04-30-2024 22:02
From: Gary Freestone
Subject: Unable to perform a "git add" on z/OS 3.1 system
I assume Git has been tested on a z/OS 3.1 system but I am having an issue with performing "git add ." and the only difference I can find is that I'm attempting to do it on a z/OS 3.1 system.
This is what I get when issuing git add .
fatal: can't add "zGIT-DS-Attributes": file is tagged, set corresponding zos-working-tree-encoding attribute or reset file tag
This is correct, the file is tagged IBM-1047 as seen here:
$ ls -lT
total 2
drwxr-xr-x 2 AUZZ04S #KYNDRYL 0 Apr 30 00:00 Z-GIT
t IBM-1047 T=on -rw------- 1 AUZZ04S #KYNDRYL 23 Apr 30 00:00 zGIT-DS-Attributes
The repository does have a attributes defined as follows:
$ cat .git/info/attributes | iconv -f ISO8859-1 -t IBM-1047
#
# Default zGit .gitattributes file specifying the attributes of some
# known file names
#
#
# This file is copied to .git/info/attributes when a zGit repo is created
#
#
* zos-working-tree-encoding=ibm-1047
### Animations
*.mpg binary
*.mov binary
*.mp3 binary
*.mp4 binary
*.wav binary
*.whl binary
If I perform a "git check-attr -a zGIT-DS-Attributes" the command doesn't return any output if I change it to "git check-attr zos-working-tree-encoding zGIT-DS-Attributes" it does return something but its incorrect. As seen below:
$ git check-attr -a zGIT-DS-Attributes
$ git check-attr zos-working-tree-encoding zGIT-DS-Attributes
zGIT-DS-Attributes: zos-working-tree-encoding: unspecified
For some reason git is not picking up the attributes defined in .git/info/attributes.
I the gitattributes are not defined I can understand why i'm getting the "fatal: can't add zGit-DS-Attributes" message.
If I issue the same check-attr command with the same .git/info/attributes file on a z/OS 2.4 system I get the following:
$ check-attr -a zGIT-DS-Attributes
zGIT-DS-Attributes: zos-working-tree-encoding: ibm-1047
$ git check-attr zos-working-tree-encoding zGIT-DS-Attributes
zGIT-DS-Attributes: zos-working-tree-encoding: ibm-1047
The versions of git on both systems is identical 2.26.2-84
So far this has been the only problem I've found
------------------------------
Gary Freestone
Systems Programmer
Kyndryl Inc
Mt Helen VIC AU
------------------------------