This document discusses approaches to implementing DevOps practices on the mainframe. It addresses cultural, technical, and organizational considerations, including modernizing developer tools, integrating source control management, and using metrics to measure productivity. A case study describes installing ISPW source control to reduce compilation and enable automated deployments. The document advocates treating the mainframe like other platforms by integrating it into enterprise-wide deployments.

1. MAINFRAME
DAY
EDITION 2021
DARE TO UNLOCK
YOUR MAINFRAME!

2. 2
DevOps on mainframe
Modernize and integrate
Jérôme KLIMM Mainframe Consultant Trigone

3. 3
“DevOps is not a Goal, But a
never-ending process of
continuous improvement”
Jez Humble
INTRODUCTION

4. 4
“Devs are from Venus, Ops are
from Mars ”
Steven Haines
A CULTURAL
APPROACH

5. 5
A C u l t u r a l A p p r o a c h
Considering Developers Mindset
• DEVs have the culture of innovation and creating applicative value
• They are under pressure from the “Market”.
• DEVs needs modern tools and interfaces
• Mindset : OPS are a brake to innovation.

6. 6
A C u l t u r a l A p p r o a c h
Considering Operationals Mindset
• OPS have the culture of zero downtimes (most of the times !)
• They need stability, normalization and fixed rules to ensure SLA.
• Mindset : « A change is a managed risk ».

7. 7
A C u l t u r a l A p p r o a c h
The Z(Mainframe) Factor
• Mainframe is the most resilient and secure platform in the market.
• Supports most of trending technologies
• Can be virtualized*
• Z is Hybrid Cloud Ready

8. 8
A C u l t u r a l A p p r o a c h
« Z + DEV + OPS = ZDEVOPS »
• DEV+OPS means merging two culture together, with common values.
• Z + DEV + OPS is about merging two cultures by including a strong platform
with innovative solutions.
• Most important challenge is to Break down silos between Dev and Ops to reach
mutual comprehension and common mindset.

9. 9
“Everything that is done twice must
be automated”
Gatien Dupré
TECHNICAL
APPROACH

10. 10
A t e c h n i c a l a p p r o a c h
Normalize developers experience
• Use one solution that addresses multiple platforms to reduce toolchain complexity.
• Making the Mainframe a technology like any other.
• Support multiple language : Java Cobol Python PL/1 Assembler,...
• NO more 3270 screens.
Measure KPI
• Monitor bottlenecks and focus on improvements axes

11. 11
A t e c h n i c a l a p p r o a c h
Get the best from all matures Technologies
• Integrate opensource software.
• Striking example of a mature technology :
Expose Mainframe legacy applications via RESTful APIs (z/OS Connect,DB2Rest…).
Speed time to Market
• Reduce the learning curve for new developers.
• Automate test and delivery CT/CI/CD for delivering with quality.

12. 12
“Don’t oppose ITIL and AGILE”
ORGANIZATIONAL
APPROACH

13. 13
A O r g a n i z a t i o n a l A p p r o a c h
Co-build the Sofware Factory with Endusers and Ops
• Share ideas and use user feedbacks to enhance the product.
• Setup a cross-functional team (Pizza Team).
Create a community(And manage it)
• Use modern approach (social networks, serious gaming,…) to increase community and user contributions.
Simplify approbation Review Process (ITIL)
• Streamline committal and approval of changes.

14. 14
C o n c l u s i o n
Key Points for Success
• Co-construction is the key for rapid and massive adoption.
• Don’t oppose ITIL and AGILE, find accommodations.
• Build a cross-functional team (Pizza Team) that can setup innovative solution.
• Feel free to Experiment !
• Create an active community (Serious Games, Blogging, Rewards systems,…).
• Listen and apply Endusers feedbacks and suggestions.
• Deliver small but often (Sprint) .
• Get KPI (Key point Indicator) to monitoring and reporting.

15. 15
“Dare to commit…”
“To the z/DevOps path”

16. 16
DevOps on mainframe
Modernize and integrate
Benoit Ebner Mainframe Engineer NRB

17. 17
1. Modernize the user desktop
2. ISPW installation: a real case
3. zAdviser: the metrics you need to know
4. Integrate the mainframe in your enterprise deploy
SUMMARY

18. 18
Modernize the user desktop

19. 19
M o d e r n i z e t h e u s e r d e s k t o p
Why do you need it?
• Modernising the developer workspace is necessary for the DevOps transition.
• Modern tools (Git, ISPW, Java, ...) require more complex interfaces.
• Young developers are more used to Windows tools than to the TSO terminal.
• The use of tools such as Eclipse or Visual Studio Code allows more help in development.

20. 20
M o d e r n i z e t h e d e s k t o p u s e r
Th e edit or
Upscale the dev tooling
The use of Topaz Workbench as the main development tool has brought
new capabilities to the coding process.
• Copybook integration into the code

21. 21
M o d e r n i z e t h e d e s k t o p u s e r
Th e edit or
Upscale the dev tooling
The use of Topaz Workbench as the main development tool has brought
new capabilities to the coding process.
• Copybook integration into the code
• Coding help

22. 22
M o d e r n i z e t h e d e s k t o p u s e r
Th e edit or
Upscale the dev tooling
The use of Topaz Workbench as the main development tool has brought
new capabilities to the coding process.
• Copybook integration into the code
• Coding help
• Overview of the code

23. 23
M o d e r n i z e t h e d e s k t o p u s e r
Th e edit or
Upscale the dev tooling
The use of Topaz Workbench as the main development tool has brought
new capabilities to the coding process.
• Copybook integration into the code
• Coding help
• Overview of the code
• Syntax check

24. 24
M o d e r n i z e t h e d e s k t o p u s e r
Th e edit or
Upscale the dev tooling
The use of Topaz Workbench as the main development tool has brought
new capabilities to the coding process.
• Copybook integration into the code
• Coding help
• Overview of the code
• Syntax check
• Graphical Compare/merge

25. 25
ISPW Installation: a real case

26. 26
I S P W i n s t a l l a t i o n : a r e a l c a s e
Type of sou rces t o man age
Our client environment
We had to deal with the following types:
• PL/1 Sources
• MFS
• PSB (Batch and IMS)
• DB/2 copybook
• DL/1 copybook

27. 27
I S P W i n s t a l l a t i o n : a r e a l c a s e
Syst em complex it y
Our client environment
• 85 combinations of compilation options
• Up to 12 load generated per source file
• Mostly 1 or 2 load generated
• LLA Refresh needed on some LPAR
• Update of table in memory for some object
• Compilation on every LPAR
• We want to stop that! Compile less, but compile at the right time!

28. 28
I S P W i n s t a l l a t i o n : a r e a l c a s e
Wh at w e t ry before ISPW
Why using ISPW?
Other tools installed:
• 2008 - Serena
• 2011 - RTC
Why it failed:
• No implication of the development team in the choice
• Complexity of the client vs. rigidity of the tooling
• Try to do everything in one step (SCM installation, integration in the global release management…)

29. 29
I S P W i n s t a l l a t i o n : a r e a l c a s e
Wh at w e do for ISPW
Why using ISPW?
• Involvement of the development team in the choice of the product
• POC carried out jointly by the system team and the development team
• The choices made during the implementation were made in agreement with the development team
• Training and first line support by developers
• Step by step implementation

30. 30
I S P W i n s t a l l a t i o n : a r e a l c a s e
What is done?
• ISPW installation as a SCM
• Deploy managed by the tool from dev to prod
• Less compilation!
• Example: NO compilation for the PROD lpar

31. 31
I S P W i n s t a l l a t i o n : a r e a l c a s e
What we do now?
• Integration into the enterprise wide release management
• Deploy on the mainframe for:
• Java Jar files
• zOS Connect files
• SonarLint & SonarQube integration
• Implementation of a Test Data Management tool

32. 32
zAdviser: the metrics you need to know

33. 33
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
What is zAdviser
• BMC/Compuware product usage analysis tool
• Build on Elastic
• Used to get a statistical view of the source management
• Free of charge
• Focus on 3 panels:
• Development Productivity
• Refactoring Candidates
• Source Control Management

34. 34
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Development Productivity
• Provides insights into the productivity of development teams within the software development life cycle.
• How many software changes are being produced in a release or sprint?
• How long does it take to complete software changes?
• What is slowing development teams down?
• Three different parts:
• Life Cycle: begins on checkout and ends upon promotion to production.
• Testing Phase: begins upon promotion to the testing phase and ends upon promotion to production.
• Development Phase: begins when a component is checked out and ends upon promotion to the testing phase.

35. 35
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Development Productivity

36. 36
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Development Productivity

37. 37
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Refactoring Candidates
• Identifies programs that are those large monolithic programs which may be candidates for refactoring.
• Looking for programs that have the most checkouts, regressions and fallbacks.
• Programs with most checkouts may be candidates for refactoring by preventing more concurrent development.
• Breaking it down into smaller pieces
• allow faster development
• easier understand code
• Programs with most fallbacks and regressions lay be overly complicated and more difficult to understand and test.

38. 38
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Refactoring Candidates

39. 39
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Refactoring Candidates

40. 40
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Source Control Management
• Provides detailed information about the SCM KPIs.
• Useful to see
• The weekly trend of deployment
• The most changed application or source type

41. 41
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Source Control Management

42. 42
z A d v i s e r : t h e m e t r i c s y o u n e e d t o k n o w
Source Control Management

43. 43
Integrate the mainframe in your enterprise
deployment

44. 44
I n t e g r a t e t h e m a i n f r a m e i n y o u r e n t e r p r i s e d e p l o y
Purpose of the task
• Synchronize the automatic deployment through all the technology in the company
• Treat the mainframe in the same way as other systems
• The developer doesn’t need to know the deployment platform

45. 45
What we want to do
I n t e g r a t e t h e m a i n f r a m e i n y o u r e n t e r p r i s e d e p l o y
Source
Code
Management
Deploy
Target

46. 46
MAINFRAME
DAY
EDITION 2021
DARE TO UNLOCK
YOUR MAINFRAME!
www.nrb.be
www.trigone.fr