From library stages to Git: source management and code pages
Library managers such as Endevor and ChangeMan ZMF move source through stages like development, test, QA and production, with packages and approvals. Git expresses the same ideas with branches, pull requests, protection rules and tags, usually with a pipeline promoting one build through the environments. Source is kept in Git as UTF-8 and converted to EBCDIC on z/OS through .gitattributes.
How library managers organise change
Described at the level of their public documentation: in Endevor, a life cycle is made of environments, for example DEV, TEST and PROD, each with a Stage 1 and a Stage 2, and an environment map that says where an element moves next. In ChangeMan ZMF, a change is a package: components are checked out from baseline libraries into the package's staging libraries, built, audited, frozen, promoted through test levels, approved, installed, and then become the new baseline, with backout to restore the previous version.
The same ideas in Git
| Library manager idea | In a Git workflow |
|---|---|
| Element or component in a library | A file in the repository |
| Package of related changes | A branch and its pull request |
| Approval before promotion | Required reviews on a protected branch, plus change records |
| Freeze: install what was tested | A tag or commit id that the pipeline builds once and deploys |
| Promotion DEV → TEST → QA → PROD | A pipeline deploying the same build to each environment, or merges into environment branches |
| Baseline / production libraries | The release branch and its tags |
| Backout | Redeploy the previous tag, or a revert commit |
Two ways to model the stages
- Environment branches (dev, test, qa, prod), promoted by merging upward. Familiar to library-manager users, but branches drift apart and the same code is rebuilt at every stage.
- One main line, tags and a pipeline: changes merge into main through reviewed pull requests, a release is tagged, and the pipeline builds once and deploys that build to each environment with approvals in between. What reaches production is exactly what was tested.
- Some sites run both worlds for a while; Broadcom's Endevor Bridge for Git, for example, lets developers work in Git and synchronise with Endevor for build and life cycle.
EBCDIC, code pages and .gitattributes
z/OS data sets and many z/OS UNIX files are in EBCDIC, while Git and almost every desktop tool expect UTF-8. The usual rule is: store UTF-8 in the repository, convert on z/OS. Git's working-tree-encoding attribute does the conversion: when such a file is added, Git re-encodes it to UTF-8 for the repository, and re-encodes it back on checkout. Git on z/OS adds a platform-scoped form, zos-working-tree-encoding, that applies only on z/OS, so the same repository checks out as IBM-1047 on z/OS and stays UTF-8 on laptops.
# text, converted to EBCDIC IBM-1047 only when checked out on z/OS *.cbl text zos-working-tree-encoding=ibm-1047 *.cpy text zos-working-tree-encoding=ibm-1047 *.jcl text zos-working-tree-encoding=ibm-1047 # never converted, never diffed or merged as text *.bin binary
binaryis shorthand for-diff -merge -text: no conversion, no line-by-line diff and no automatic merge. Use it for anything that is not text.- On z/OS, Git uses file tags (CCSIDs, set with chtag) when files are added: the tag must match the encoding in .gitattributes, and Git on z/OS does not add untagged files.
- Every client that works on the repository must support the attribute: Git's manual warns that some other Git implementations and old Git versions do not.
- Different EBCDIC code pages place some characters differently, so the code page in .gitattributes must be the one your compilers and data expect.
Binary members and load modules
Load modules, object decks and other binaries are build outputs. Keep them out of the source repository (the pipeline rebuilds them and stores them as versioned artifacts) and, if a binary file must live in Git, mark it binary so nothing tries to convert or merge it.
Which .gitattributes attribute converts files to an EBCDIC code page only when they are checked out on z/OS?
Show a hint
The platform name in front of working-tree-encoding.
Show the solution
zos-working-tree-encoding, for example *.cbl text zos-working-tree-encoding=ibm-1047.
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
Diffs, reviews and every desktop tool break. Store UTF-8 and convert on z/OS with .gitattributes.
Environment branches drift. Prefer one main line, tags, and a pipeline that promotes one build.
They are build outputs: rebuild them in the pipeline and keep them as versioned artifacts, or mark them binary.
What you will see at work
- Migrations from a library manager to Git usually start with one application, run both in parallel for a while, and move the approval evidence to pull requests.
- Setting up .gitattributes is one of the first tasks in a new mainframe repository, and it is reviewed like code.
- Expect to explain the mapping to colleagues who know Endevor or ChangeMan well: their questions about approvals, freezes and backout all have Git answers.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.