A Day in the Life of an Agile Mainframe Developer: A Naturally Agile Approach to App Dev
0 likes740 views
The document outlines a typical day in the life of an agile mainframe developer, highlighting an agile approach to application development. It emphasizes the importance of moving quickly through the DevOps lifecycle and supporting mobile generation. Key takeaways and insights are also presented.
A Day in the Life of an Agile Mainframe Developer: A Naturally Agile Approach to App Dev
- 1. 1 A Day in the Life of an Agile Mainframe Developer A Naturally Agile Approach to App Dev Mark Schettenhelm, Product Manager Paul Allard, Product Owner IBM Systems Magazine February 28, 2017
- 2. 2 Mark Schettenhelm Product Manager Paul Allard Product Owner
- 3. 3
- 4. 44
- 5. 5 A Typical Day in the Life of an Agile Mainframe Developer
- 6. 6 DEMO
- 7. 7
- 8. 8
- 9. 9
- 10. 10
- 11. 11
- 12. 12
- 13. 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. 18
- 19. 19
- 20. 20
- 21. 21
- 22. 22
- 23. 23
- 24. 24
- 25. 25
- 26. 26
- 27. 27
- 28. 28
- 29. 29
- 30. 30
- 32. 32
- 33. 33
- 34. 34
- 36. 36
- 37. 37 Move Quickly Through the DevOps Lifecycle
- 38. 38 Key Takeaways
- 39. 39 © 2017 Compuware Corporation. All rights reserved.
Editor's Notes
- #4: Development practices have matured over the past decade or so to be very aggressive, fast-paced and built on Agile and DevOps methodologies. These changes provide the collaborative environment needed to produce quality output that delivers great customer experiences. However, mainframe development processes and tools haven’t evolved similarly and are preventing IT from integrating their mainframe into these broader DevOps efforts. With exponentially increasing demands on your backend systems from mobile, cloud and web apps, along with a high number of mainframe experts retiring, this is a problem that must be addressed. Compuware can help by enabling a blended ecosystem where both mainframe and non-mainframe developers can use the same Agile processes. Our products and integrations with popular mainstream products like SonarSource and Jenkins, provide a naturally agile approach to app dev. We are changing the way developers develop by helping experienced staff and new hires perform mainframe-related tasks with agility, efficiency and precision.
- #6: These are the things you do every day Same things you do, but they will look different We’re not adding steps, but we’re making the steps you do easier and faster. Everything we’re going to show you today is in Topaz Workbench Make it easier to test Make testing more organized and have more automated test creation Proof of test Keep code and test cases together Compuware tools can help you navigate through your daily tasks Why do things in an Agile way with intuitive, modern tools? Efficiency Improve productivity Make your job easier More reliable code Fulfill business requirements in a much easier, faster way
- #12: We want to pull down the TTT_CWXTSUBC folder from ISPW and create a new test case that is added to this folder.
- #13: Then we open an Xpediter Debug Session to collect the data for the Total Test case.
- #14: After letting it run, we can open the Debug Configuration options.
- #15: The debug configuration tells Xpediter which program to debug.
- #16: The Xpediter debug session begins at the start of the procedure division of the main program.
- #17: We then want to set a breakpoint in the main program to find the call to CWXTSUBC.
- #18: Step into the CWXTSUBC program. Xpediter stops at the procedure division of the sub program. At this point, we change the value of the sales amount from 55,000 to 85,000 so I can hit the new code that Mark added. As you can see, the input value has changed from 55,000 to 85,000.
- #19: We want to right click on the highlighted procedure division to tell Xpediter to capture the data. This will sets up the unit test case.
- #20: In the dialogue box that appears, we select the project location where the new test case will be stored or we could also create a new project, if desired.
- #21: We continue to step through the code, ensuring that we hit the new code that Mark put in. As you can see, we hit the condition. Then continue to let the program execute until it finishes.
- #22: Once the program has finished executing, we get a message in the console window indicating a new test case has been created
- #23: Now we flip over to the project explorer view.
- #24: As you can see, a new test case was added to the scenario folder.
- #25: Note that the test case shows the value of 85,000 that we added in the Xpediter session. This tab shows the input parameters being passed into the sub program.
- #26: The check conditions tab shows the expected value after the test case has ran. In this case, we expect the sales commission to be 8,500 based on the predetermined calculations.
- #27: Once we hit the green “go” button, a dialogue box will appears indicating which JCL we want to run.
- #28: Once we hit the OK button, Topaz for Total Test will send the stubbed data to the mainframe. The testrunner program, which resides on the mainframe, will execute the program and use the test case as the stub for the SubC program.
- #29: Once the job finishes, we can view a test suite summary. This page indicates that the test case ran successfully.
- #30: In the details tab of the test results, we see the input, output and expected value.
- #31: We have now created a new unit test case for the changes Mark put into the SubC program. We can save this test case to the project folder and upload it to ISPW.