We have also been looking at a similar issue here at Macro 4 but with a slightly different approach for our mainframe development. We now use Subversion as our source repository, Eclipse as our IDE and we utilise Apache Ant and Jenkins for our development and production builds. However we do not use USS, we use z/OS for our compiles and assemblies – and this works for all of our languages; Assembler, Cobol, PL/1, C, REXX, Java, etc. We have the advantage that some of our products already have a z/OS STC as part of their installation and this STC has APIs allowing us to move the source from our workstations to z/OS, submit the JCL for the compiles, assemblies, etc. and capture and return any output and listings etc. By using z/OS it meant we could reuse all of the build JCL that we already had in place which was a big help with the transition. We have also created a task that scans all the source and produces a list of dependencies, such as Macro and Copybook usage. Then when a developer updates say a Macro he does not have to remember or scan for all the source that is affected by the update as the build system will automatically compile all the components affected. They can of course optionally rebuild the whole application if they want with a click of a button! The advantages are that we utilise Open Source, and admittedly some in-house code, rather than potentially costly mainframe based source management systems, and we utilise Eclipse as the IDE which helps with recruitment of new talent, cross training and up training to the mainframe. As I expect others have found our developers have to use multiple languages and get involved in cross platform solutions, especially with digital transformation and modernization projects, so using Subversion as the source repository and the Eclipse IDE for editing gives us a single way of working across the teams. There is also another benefit in using Eclipse in that like Macro 4 other vendors have produced Eclipse interfaces to their products meaning that your technical teams can stay in a single environment for all their tasks, again assisting with recruitment and training. Most of the University graduates CVs that we see have Eclipse experience and they expect a modern interface as their working environment, and although us die-hards like 3270 and ISPF we have to be realistic and accept that the younger generation do not want to be trained in ISPF, regardless of whether we think it is a much better interface or not. This approach works well for us and it didn’t take long for us to convert from our old mainframe based processes to this modern agile environment. Even turned an old timer who was a naysayer into “I wish we had done this 10 years ago”! We even trained up an Open Source developer with mainframe knowledge by just using the Eclipse interfaces and now he is a contributor to our mainframe development – and he does not have a TSO logon! Of course it will also work with other Open Source tools, such as GIT, so you are not tied in to one product, the choice is yours. Drop me an email if you want to know more – [email protected].
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
