Db2 z DevOps and Cloud provisioning

1. 1

2. 2

3. 3

4. What is WWW?
On the one side we have the chaos that can be created in case developers just do
what they want. (This is how developers are sometimes perceived by the Sysprogs
and DBAs)
On the other a strictly controlled environment can lead to long wait times for the
developer (This is how the mainframe can be perceived by developers)
4

5. This is also reflected in this pyramid. Developers are driven by speed and reacting to
change, providing innovation and improving customer experience.
Sysprogs and DBAs on the other side have to keep the systems stable, secure,
reliable, available etc. In addition they are significantly less people compared to the
developers.
So how can we be more agile without jeopardizing the stability of the system?
5

6. This is our scenario: a German (health) insurance provider, that suddenly needs to
implement access to their backend systems to establish a digital health record for
every citizen
6

7. 7

8. Meet the team.
Pension Pete is our previous sysprog who had kept the systems up and running,
including provisioning.
Currently the position of Bluemix Bob is vacant, as our student moved on.
8

9. 9

10. This is the customer database interface of the General Insurance Application
10

11. This is the Policy part of the General Insurance Application, where for a specific
customer you can look up their policy record
11

12. The goal is a modern frontend that uses restful services to connect to the backend.
We used the following options for demonstration purposes:
• Java based restful services using the jax-rs framework in a Liberty server. This
server could run standalone or integrated in CICS.
• z/OS Connect as an alternative way of exposing mainframe assets as restful
services
• a Blockchain for the health record
12

13. We started with a simple CICS Region and a load library, containing the load modules.
One schema in Db2 was serving the dev environment.
In addition Pension Pete left us 2 provisioning jobs:
1. MEGABUILD to bump up environments from scratch. It was a huge and complex
job for all evenutalities.
2. MEGADELETE to get rid of everything again.
We tried twisting the jobs but were challenged with suddenly having to cater for
Liberty, z/OS Connect, new Schemas and much more.
13

14. The new environment takes advantage of the z/OSMF Cloud Provisioning, which
comes free as part of the operating system.
People mostly use z/OSMF today for sending incident logs to IBM or to define their IP
stack. There is much more available like WLM, Software Deployment, Tenant Groups
for Container based pricing, Workflows, etc
And a lot of stuff is restfully accessible. In addition there is a simple self-service portal
for demonstration purposes.
We now provision
• CICS
• Liberty Server (embedded in CICS, could be stand-alone)
• z/OS Connect (could run in standalone Liberty server, we run it in the embedded
Liberty)
• user load lib
• Db2 schema
14

15. We came from an environment of pets.
Every CICS region had a name and specifics (compare it to food allergies). For
example: CICST was the terminal owning region, CICSJ was for Java, CICSB was for a
beta version, but when the beta became a release, we just kept it and you could also
do Java there, also in CICS1, but not in CICS2, …
it was sooooo much work.
Now we have cattle. We treat them in the same way (compare to feeding) and if you
only need milk, you get a cow and return it afterwards. Actually, we destroy the cow,
this is where the analogy breaks. But deprovisioning is important as well to keep
control. We have one customer who got rid of 1000 test CICS regions, Now there are
only 9000 left…
15

16. 1. Sysprog loads a template into z/OSMF
2. Template consists of workflows for provision, deprovision, start, stop, checkStatus
3. workflow can run JCL, REXX scripts or issue rest calls, and it has variables to stay
flexible
4. the developer can use a self service portal to provision an instance (a container)
5. the developer can alternatively use a docker-like fashion with the free z/OS
Provisioning Toolkit
1. use zospt build (similar to docker build) to build an image. This image will
refer to a z/OSMF template. In addition you can specify a limited set of
additional parameters using a zosptfile as manifest.
2. issue the zospt run command (similar to docker run) that will issue a call
to the z/OSMF rest API to provision the instance (container)
16

17. There are provisioning workflows for Db2.
But we decided to share the Db2 sub system and only provision a schema (later).
You can register an existing Db2 system as instance (container) in z/OSMF using a
special registration template.
The developer then can refer to this registered instance using the --link option
(similar to the --link option in the docker run command). Under the cover this will
install a Db2 Connection into the newly provisionend CICS
17

18. live demo, slides are for reference and failover
18

19. live demo, slides are for reference and failover
19

20. live demo, slides are for reference and failover
20

21. Those are some of the templates the sysprog provided. You can
1. provision a CICS environment
2. register an existing MQ as instance
3. register an existing Db2 as instance
21

22. Now let’s deploy the application. Click on the video to start it or go to
http://www.gifbin.com/989010
We want to bring our application consisting of load modules, Java classes, z/OS
Connect APIs, DBRMs and more and simply throw everything into place.
22

23. But now we also have other stuff to deploy. The environment is empty, so bring your
CICS definitions (e.g. transactions), Db2 DDL, Liberty server.xml, Test data etc.
To the right you see how our application looks broken down into components in
UrbanCode Deploy
23

24. Now the developer will check in into Source Code Management.
In our case this is Rational Team Concert. The alternative is GIT because with
Dependency Based Build this is the only cross platform build tool that can also build
for the mainframe.
The deployable artefacts will be added to a Deployment Tool.
In our case this is UrbanCode Deploy. From there everything is deployed to where it
belongs.
24

25. 25

26. 26

27. 27

28. 28

29. 29

30. This is the deploy for the load modules and DBRMs.
the left leg will create a list of modules for CICS to newcoopy or phasein.
Le right leg will create a BIND PACKAGE statement for each member.
30

31. the list of BIND PACKAGE statements will then be fed into a job that also does the
bind plan.
31

32. our ddl deploy for the first time will check if a temporary schema had been creted.
If not, it will create it, execute the ddl and insert data into the database for testing.
In the future we will use the Db2 admin tool instead of executing the ddl directly.
Furthermore we want to look ad test data management instead of just copying the
data.
If we apply a changed ddl, this time the schema will be there, so we will create a
compare (z/OSMF) workflow for the Db2 Admin and Object Compare Tool.
We execute the complete workflow at once
32

33. at any time you can add approval steps to the flow.
In this case, a dba will get an email with the result of a process step. Once it was
reviewed and approved, the process will be continued.
33

34. This is how the Db2 lab imagines the compare process. The workflow will not be
executed at once, but step by step.
Before the changes are deployed, a DBA approval is required.
34

35. 35

36. 36

37. 37

38. 38

39. 39
39
This is how the lab imagines a Continuous Integration Scenario in the Future

40. 40
40
We have a gold master and several developer environments (sandboxes, temporary schemas)

41. 41
41
One Developer changes the database in his/her sandbox

42. 42
42
a temporary continuous integration schema will be created

43. 43
43
the change will be merged and validated against rules, tested, reviewed and approved.
If one of those failes, the whole build will fail.

44. This is an example screenshot from a merge request in GIT.
44

45. 45
45
once the change was accepted, the gold master will be updated and the change be pushed to the oth

46. 46

47. 47

48. 48