Today, the main part of the top companies back office is managed by COBOL applications running on mainframe. Yes.
Most of those applications have a thing in common: they are developed with an old toolchain from the 80’s or 90’s.
This toolchain controls the build and deploy as a key features, and also the versioning but it is kind of primitive. Yes.
Furthermore, version management, when it exists, is used at the component level, not at application level. The development teams do not implement the branch management even if, in theory, this feature is available. Until today, the application versioning was not a concern and has not really be even considered.
By contrast, the « modern » apps (i.e. Java, .Net, etc.) are managed with tools providing full versioning like Git / SVN with branch management, automatic build, etc. The current weak point is the deployment which is the key for the DevOps world.
The mainframe world is quite different from what is encouraged today:
– On the mainframe, you do build and deploy individual components one after the other (update one by one, all the time – no parallel development, no software versioning).
– On the mainframe, sources are stored in bulk in libraries containing up to 40 000 sources. It is unthinkable to put all this stuff in a Git repository and to clone it on each developer desktop!
That said, what should I do to put my COBOL mainframe sources in Git ?
- First of all, split the waste bin that we use as a repository (I am kidding, of course) into well sized applications, identify common modules and treat them like applications too.
- Launch the mainframe compilation and transfer procedures (build and deploy) from external computers (Eclipse and Jenkins server).
- Manage the developers to use Git (Not a piece of cake!)
- Forget ISPF and work with Eclipse and Cobos!