A standard development process on mainframe looks similar to the one below:
Requirements and Issue Tracking
Application requirements and issues are stored in Collabnet’s Teamforge, BMC’s Remedy or Atlassian’s JIRA.
Development
Mainframe developers use to work with 3270 screens and store their code in mainframe PDS's (Partitioned Data Sets) instead of in standard Windows directories. In a PDS you can’t version your files or members. That is why library management systems like Librarian or Panvalet, and later on more sophisticated systems with additional functionality like CA’s Endevor or Serena’s Change Man, were developed.
Nowadays, mainframes are often no longer seen as development environments, but mainly as machines able to cope with massive amounts of data and transactions. A major challenge is to make them part of today’s new ecosystem where distributed environments and mobile play an important role.
Another difficulty for the mainframe is to find young graduates that still want to code using a 3270 terminal. That is why companies like Compuware, IBM and others have refreshed the mainframe development IDE's and offer TOPAZ and RDZ respectively. Those IDE's are Eclipse-based environments with a lot of productivity enhancements for developers and which are attractive for young graduates.
Versioning
Once the development is done, developers “commit” their code (the same way as .NET or Java developers do), into a common version control repository like CVS, Subversion, GIT or Team Foundation Server (TFS). At this point, IKAN ALM takes over.
IKAN ALM has developed specific mainframe solution phases that will allow you to take the development of the mainframe and to steer the mainframe compile and deploy process from within IKAN ALM using non-mainframe technology, but serving the mainframe.
Automated build (compile!)
A sample compile process using the IKAN ALM build phases, runs like this:
- From your versioning system, you select the components you want to compile in a package.
- Based on the content of that package, a JCL (compile script for the mainframe) will be automatically generated. (Possible criteria can be: ASSEMBLE, COBOL, PL/1, SDF2, DB2, CICS, … using IBM or other compilers).
- That package (sources, copybooks,.. and JCL) is transmitted to the z/OS mainframe machine and the compile jobs are submitted. Once the compile jobs have been executed, the generated files are loaded and the results are brought back to IKAN ALM and you move to the next step.
Automated deployment to Test or Production environments
The next step is the deployment to a Test or Production environment. During the deployment you can, if required, recompile or apply the necessary rules, such as specifying the correct DB2 database or CICS system or Debugger, needed to run in your test or production environments.
The process is similar to the compile process:
- The package (the load modules and associated listings, dbrms and plans) is transmitted to the z/OS mainframe machine and the jobs are submitted for updating Binds, CICS Phasein or Debugger, or for managing other specific objects.
- Once the jobs have been executed, the results are brought back to IKAN ALM.
Enhanced communication between all stakeholders pre -or post-approvals can be set on Test and Production levels. Those approvals enable a verification moment before or after the execution of the Level Request to Test or Production. On top of that, notifications can be sent out to the people involved. This enhances the communication between the different stakeholders and improves traceability and quality control.
Continue reading in our next post: The benefits of DevOps for z/OS.
About the author
Hello, my name is René De Vleeschauwer.
Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.