Git push failing with large COBOL copybooks

General DevOps for Mainframes Discussion, Vendor Specific Cloud Computing Tools for mainframes, DevOps Certifications, IDz, Topaz, IBM DBB, Jenkins
User avatar
Angel
Registered Member
Posts: 97
Joined: Sat Jun 08, 2013 8:13 pm

Git push failing with large COBOL copybooks

Post by Angel »

Hi,

Git push failing with large COBOL copybooks. We are using Rocket Git and it timeouts with big copybooks. What are the Workarounds? Could someone please guide. 
User avatar
zum13
Active Member
Posts: 135
Joined: Thu May 04, 2023 12:58 am

Re: Git push failing with large COBOL copybooks

Post by zum13 »

Hello.

I'm not familiar with Rocket Git, but, with my Sysprog's hat on, that sounds like the sort of thing that I would be calling Rocket Software about to get some support for.
User avatar
enrico-sorichetti
Global Moderator
Global Moderator
Posts: 855
Joined: Wed Sep 11, 2013 3:57 pm

Re: Git push failing with large COBOL copybooks

Post by enrico-sorichetti »

read the git docs about repository and file sizes 
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort 8-)
User avatar
Anuj Dhawan
Founder
Posts: 2838
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Contact:

Re: Git push failing with large COBOL copybooks

Post by Anuj Dhawan »

Angel wrote: Sun Sep 14, 2025 11:39 am Hi,

Git push failing with large COBOL copybooks. We are using Rocket Git and it timeouts with big copybooks. What are the Workarounds? Could someone please guide. 
This usually happens because very large COBOL copybooks (often flattened or vendor-supplied) make the Git pack huge, and git push times out on Rocket Git. A few workarounds:
 
  • Avoid committing flattened copybooks — DBB/zAppBuild can resolve nested COPYs via copybookSrcDirs, so keep only modular copybooks in Git. If flattening is needed, generate it in the build step, not in version control.
  • Use SSH instead of HTTPS to bypass proxy/LB timeouts.
  • Tweak Git client settings: lower compression (core.compression 1) , raise timeouts (http.lowSpeedTime 600), and repack before pushing.
  • Consider Git LFS (if supported) for large, rarely changed copybooks.
  • Infra fix: increase reverse-proxy/load balancer timeouts (NGINX/Apache/ALB).
In practice, the cleanest approach in DBB pipelines is to keep Git light (just source + modular copybooks) and fetch any large/vendor copybooks separately during the build.
Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
User avatar
Anuj Dhawan
Founder
Posts: 2838
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Contact:

Re: Git push failing with large COBOL copybooks

Post by Anuj Dhawan »

zum13 wrote: Mon Sep 15, 2025 5:43 am Hello.

I'm not familiar with Rocket Git...
 
 
Rocket Git for z/OS is Rocket Software’s port of the popular Git version control system to the IBM mainframe environment. It gives mainframe developers the same benefits that distributed developers enjoy with Git—tracking changes, managing versions, and collaborating on code—but tailored for z/OS. One of the standout features is its handling of character encoding: since mainframe code is usually in EBCDIC (like IBM-1047) while most modern tools use ASCII, Rocket Git automatically translates between the two via .gitattributes, making cross-platform work much smoother. It also integrates well into DevOps pipelines, enabling Git-based workflows and helping organizations modernize their mainframe development practices. Overall, it’s part of Rocket’s broader push to bring open-source tools to the mainframe world, lowering barriers and making the platform more accessible to a wider pool of developers. You can also check IBM’s official page here for more details: IBM Rocket Git for z/OS.
Hope this helps,
Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
Post Reply Previous topicNext topic

Create an account or sign in to join the discussion

You need to be a member in order to post a reply

Create an account

Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute

Register

Sign in

Return to “DevOps for Mainframes and related news”