Applying DevOps to CICS cloud applications
This chapter demonstrates how the new DevOps tools can be used to deploy a CICS cloud application to multiple environments by using a repeatable and automatic process.
This chapter covers the following topics:
7.1 CICS and cloud applications
Introduced in CICS Transaction Server V5.1, CICS cloud applications provide a mechanism for encapsulating all of the resources that comprise a business application in one entity, which can be deployed, enabled, disabled, and removed as a unit. Certain resources can be tagged as entry points to the application so that you can analyze the resources that are used by the application and make activities such as chargebacks easier.
CICS Transaction Server V5.2 introduces CICS cloud application multi-versioning, in which you can have numerous versions of your application running concurrently, and bring a new version of an application into your production environment without service outages. You also can roll back versions of the application without major service interruptions. You can use multi-versioning to release new application functions to just a subset of your users and prepare and test the installation of the new application without deprovisioning the in-service application. You can also maintain support for particular versions of applications for migrating users.
For more information about CICS cloud applications, see Cloud Enabling IBM CICS, SG24-8114.
7.2 The scenario that is used in this chapter
The Policy Search GENAPP Extension with Cloud Enablement is used to illustrate the DevOps concepts that are described in this chapter. This scenario uses the following tools:
•CICS Explorer
•Rational Team Concert
•Apache Ant
•IBM CICS Transaction Server build toolkit (CICS build toolkit)
•DFHDPLOY
This GENAPP extension comes with two application bindings to demonstrate deploying the application to a single-region platform or a multi-region platform. When you use the single-region platform, the application binding installs all of the application into one region. When using the multi-region platform, the application binding installs each tier into a different region type. It also installs remote programs to allow program calls between regions.
You can download the GENAPP extension from this website and import it in CICS Explorer:
For this scenario, we primarily use the CICS Cloud perspective in CICS Explorer, which provides views to develop CICS cloud applications. You will see how variables can be extracted to make the application as portable to different environments as possible, and the code changes delivered to Rational Team Concert.
Rational Team Concert is used as a CI server and the Jazz Build Engine is used as a build engine. Apache Ant is the build utility, so you can start the CICS build toolkit for the build.
When deploying the application, JCL scripting provides the automation, which calls the CICS build toolkit to resolve the application's variables for the intended platform. Finally, the DFHDEPLOY utility is used to deploy the CICS cloud application to the target environment.
Figure 7-1 on page 157 shows the full CICS cloud application DevOps scenario for this chapter.
Figure 7-1 CICS cloud application DevOps scenario
We make several changes to the application that we are deploying to make it suitable for multiple environments:
•The CEDF transaction is a useful tool in development environments but is disruptive to testing and production environments. Use variable substitution to enable only CEDF for program definitions in the development environment and disable it in the testing environment.
•The name of the JVM server where OSGi bundles are installed might differ between environments. Use variable substitution to use different JVM server names in different environments.
It is also important to know which actions are performed by the individuals filling each role in the process:
•Application developer:
 – Use CICS Explorer wizards to change the CEDF and JVMSERVER program definition attributes to reference variables.
 – Set the variable default for development.
 – Check in changes to the source code management (SCM) system and request an automated build and deployment.
•Build engineer: Write build automation to run the CICS build toolkit that builds the application binding and related artifacts.
•Release engineer:
 – Create application bindings for the test environment and other environments
 – Write automation to run the CICS build toolkit that resolves the application by using properties for the test environment
 – Write automation to run the DFHDPLOY utility that undeploys the old version of the application and deploys the new, updated one
This scenario also demonstrates the architecture of the build and deployment processes.
The automated build process uses the SCM build engine and the CICS build toolkit's build command to build the application bundle directly in the location on zFS that is used as a build repository. The deployment process uses the CICS build toolkit's resolve command to resolve different variables in the resource definitions (for example, CEDF and JVM Server name attributes), and then uses the DFHDPLOY utility to deploy the application bundle to the target environment.
Figure 7-2 shows the scenario's build and deployment architecture.
Figure 7-2 Build and deployment architecture for CICS cloud application DevOps scenario
7.3 Using the Policy Search GENAPP Extension with Cloud Enablement
The Policy Search GENAPP Extension with Cloud Enablement demonstrates how the support for cloud applications in CICS allows the resources that compose an application to be deployed together, across a CICSPlex, and then managed as part of a combined lifecycle. Without changing the application, it can be bound to different topologies, which are known as platforms.
The application consists of three tiers. The first tier installs transaction SSC2, which is a 3270 terminal transaction that takes input and displays the associated policies. The middle tier installs a Java program that takes the input request in a COMMAREA and moves it into a container, and vice versa. The final tier installs a Java program that interacts with a DB2 database by using JDBC. When using the single-region platform, the application binding simply installs the entire application into one region. When using the multi-region platform, the application binding installs each tier into a different region type. It also installs remote programs to allow program calls between regions.
7.3.1 Importing the GENAPP extension projects into CICS Explorer
The GENAPP extension provides the application, application binding, platform, and CICS bundle projects. To start developing with these projects, download the extension from the location that is described in 7.2, “The scenario that is used in this chapter” on page 156. Then, in CICS Explorer, click File → Import and select Existing Projects into Workspace to import all the discovered projects (see Figure 7-3).
Figure 7-3 Projects that are imported from the GENAPP extension
To use the projects in an automated build and deployment pipeline, they must be shared to an SCM system. Right-click the projects and select Team → Share Project. Several different options are presented, depending on the source control plug-ins that are installed in CICS Explorer. For Rational Team Concert, select Jazz Source Control and choose a repository workspace and component to which to share (see Figure 7-4).
Figure 7-4 The projects that are shared to SCM - the repository icon decorator indicates that they are shared
With the projects shared to the SCM system, developers can now work on the application in their own workspaces.
During development, you can test the application by using tools in the CICS Cloud perspective of CICS Explorer. Right-click the listing for the application or application binding project and select Export Application/Application Binding Project to z/OS UNIX File System. Then, create the application definition and install the application.
7.3.2 Setting up the target platform for team development
The Java projects in the application are failing to compile because they have missing dependencies.
Developing OSGi-based applications in CICS Explorer (either for OSGi JVM servers or Liberty JVM servers with OSGi applications) involves the target platform. The target platform provides a set of OSGi bundles (and associated Java interfaces and classes) that are assumed to exist in a particular environment. By using the target platform, the applications can be compiled for each specific environment by using the APIs that the environment provides. It also provides many built-in target platform templates for each of the environments that CICS Transaction Server provides, including OSGi JVM servers and Liberty JVM servers, at each release of CICS Transaction Server.
Target platforms can consist of more than just the APIs for CICS Transaction Server, OSGi, and Liberty. When you use an OSGi JVM server, setting the environment variable OSGI_BUNDLES in the JVM profile allows additional OSGi bundles to be installed at the start of the JVM server, which means that applications can assume that they exist and use their APIs. Common OSGi bundles that are added to the OSGI_BUNDLES environment variable include the OSGi bundles for connecting to IBM DB2, such as db2jcc4.jar and db2jcc_license_cisuz.jar. The GENAPP extension needs the DB2 OSGi bundles to exist in the JVM server, so the target platform must be altered to include them for development purposes and to allow it to be built.
To store these external OSGi bundles, complete the following steps:
1. Create a project by clicking New → Project, click General → Project , and name the new project Target Platform.
2. Add a folder that is called bundles to the project and add the OSGi bundles to the folder.
With the dependencies available in the workspace, you can create and apply a target platform for CICS Transaction Server V5.3 and those dependencies. Complete the following steps:
1. Open the Preferences menu and click Plug-in Development → Target Platform.
2. Click Add to add a target definition and use the wizard to choose a platform template. The list includes CICS Transaction Server V5.3 and prior target platform definitions for OSGi JVM servers, and if the Eclipse Web Tools Platform is installed, it also shows the Liberty JVM server target definitions.
3. Click Next and CICS Explorer shows the content of the selected definition.
4. Rename the target platform to “CICS Transaction Server V5.3 with DB2”, as shown in Figure 7-5.
Figure 7-5 Rename a target definition that is produced from a template
5. The target definition also must refer to the DB2 bundles. Click Add to open a dialog box and select Directory (Figure 7-6) because the bundles are in a workspace directory.
Figure 7-6 Add directory content to the target definition
6. In this scenario, we want our target definition to be flexible so that developers can use it on different machines and with automation features, such as those provided with the CICS build toolkit. To achieve this flexibility, use a workspace variable to refer to the required bundles directory, either by entering the variable directly or clicking Variables and following the prompts. The resource_loc variable, which is predefined in Eclipse and can be used within both CICS Explorer and the CICS build toolkit, resolves the location of the argument workspace-relative path to an absolute file path (see Figure 7-7).
Figure 7-7 Specify the directory in an environment-neutral manner
7. With the workspace variable designated, click Next to see the OSGi bundles that are contained in the directory. In our example, there is just the com.ibm.db2.jcc bundle. Complete the steps in the Add Content window and then click the Content tab of the new target definition wizard (see Figure 7-8). Select the com.ibm.db2.jcc check box to ensure that the bundle is used by the target definition, and then click Finish.
Figure 7-8 Ensure that the DB2 bundle is selected in the target content
8. With the bundle selected, the new target platform appears in the list of all target platforms. Select the check box beside the new target platform and click Apply (see Figure 7-9). The workspace is rebuilt by using the new target platform.
Figure 7-9 The new target platform before it is shared into a project
9. The target platform is held locally by the workspace of CICS Explorer. It must be shared, by using source control, so that others can access it. To do this task, click Share to choose where to put it, and then select the Target Platform project.
10. Give the file a name, such as CICS Transaction Server V5.3 with DB2.target, and put it in the Target Platform project. A new target definition file is created in that project.
11. The Target Platform project and its content must now be checked in to the SCM system, Now, other developers can develop with a consistent target platform. They simply must check out the Target Platform project, open the target definition file, and click Set as Target Platform (see Figure 7-10 on page 167).
Figure 7-10 Set the target platform from the target definition file
Later in the development pipeline, when automating the build by using the CICS build toolkit, you load the Target Platform from the SCM system alongside the application, and pass the location of the target definition file to the CICS build toolkit by using the --target argument. In this way, both development and build use the same target platform, reducing errors caused by inconsistent platform definitions.
7.4 Making changes in development
To get started with changing the application, complete the following steps:
1. Open the CICS Explorer Cloud perspective, as shown in Figure 7-11, in which the GENAPP extension application bundles are displayed. Update both bundles by using variable substitution.
Figure 7-11 CICS Explorer Cloud perspective showing the GENAPP extension application bundles
2. Double-click the listing for IPDB.program and the program attributes are displayed, as shown in Figure 7-12 on page 169. CEDF is set to YES. Leave it as YES in the development environment, but set it to NO in the testing or production environments.
Figure 7-12 IPDB.program attributes
3. Right-click the CEDF attribute item and select Extract value to variable. The window that is shown in Figure 7-13 opens, where you can do variable substitution. Set CEDF(YES) for the single.binding test region and CEDF(NO) for the testing or production regions.
Figure 7-13 Extract a value to a variable
4. Select com.ibm.cics.geanapp51.single.binding (development) and com.ibm.cics.genapp51.binding (test or production) and set the CEDF values to NO and YES, respectively (see Figure 7-14). Click Finish. If you leave the single-binding option unchanged, it defaults to the db.bundle value of YES.
Figure 7-14 Extract value to variable changes
In Figure 7-15, a variable (${IPDB.Cedf}) takes the place of the CEDF attribute of the IPDB.program file.
Figure 7-15 CEDF attribute with substituted variable
5. Use the same steps and apply variable substitution to the JVM server name, specifically the db.bundle (see Figure 7-16). For our multi-environment, we select genapp51.binding, give it a value of JVM1, and click Finish. In this case, we do not change the development application binding, com.ibm.cics.genapp51.single.binding, which allows the bundle's value to be used.
Figure 7-16 Extract value to variable for JVM1
The IPDB.program attributes now show value substitutions for both CEDF and JVM Server (see Figure 7-17).
Figure 7-17 IPDB.program attributes with substituted variables
6. Change logic.bundle in the same way you did for the binding bundle. Figure 7-18 on page 173 shows the results. The value of the CEDF attribute is substituted with the variable ${IPPROG.Cedf}, and the value of the JVMSERVER attribute is substituted with the variable ${logic.jvm.server.name}. We set the value of the variable in the test application binding to JVM2 as a way to distinguish it from the other OSGi bundle, which used JVM1.
Figure 7-18 IPPROG.program attributes with substituted variables
With these changes made, you can now check them in and deliver them to SCM.
7.5 Creating an automated build definition by using Rational Team Concert and the CICS build toolkit
To provide continuous building of the application, create a Rational Team Concert build definition for it. When Rational Team Concert detects changes in the application source code, a new build is triggered.
There is no need to write new build scripts because the Ant build script that you created and used earlier in this book can also be reused to build the CICS cloud application. However, the parameters that you define on the build definition must be changed, as shown in Table 7-1. There are three changes:
•Change the bundle name to the name of the application binding.
•Change the Rational Team Concert source component to the component for this application.
•Change the target platform to use the target definition file that you created by using both CICS Transaction Server V5.3 and DB2 libraries.
Table 7-1 Build properties for the CICS cloud application
Name of property
Value
Uses
ant.work.dir
workdit
Working directory for the Ant script
build.output.dir
/var/cicsts/devops/builds/${bundle.name}
Output directory for the CICS build toolkit build command
bundle.name
com.ibm.cics.genapp51.single.binding
Bundle name to build
load.dir
${ant.work.dir}/${source.dir}
Load directory to use in the Rational Team Concert build definition
source.component
GENAPP Policy Search (Cloud)
Source component in Rational Team Concert
source.dir
source
The name of the source directory for the CICS build toolkit’s build command
target.platform
"${source.dir}/${source.component}/Target Platform/CICS Transaction Server V5.3 with DB2.target"
The name of the target platform for the CICS Build toolkit build command
In this process, you use a subset of the same zFS area that you used in Chapter 6, “Applying DevOps to Java applications” on page 129 because you use zFS as a common build repository between the bundles. Be sure to read the part about the disadvantages of zFS as a build repository compared to purpose-built alternatives.
7.6 Deploying the application with the CICS build toolkit and DFHDPLOY
With new versions of the application created and placed into zFS, you can now deploy the application. In this example, deployment consists of three steps:
1. Copying the application from its location in zFS.
2. Using the CICS build toolkit's resolve command to resolve variables by using the relevant application binding.
3. Using the DFHDPLOY utility to change the lifecycle of the application.
All of these deployment steps can be run by using JCL. In this example, we use a single job to perform the entire process. The JCL of the job is shown in Example 7-1.
Example 7-1 Application deployment JCL
//CLODDPLY JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID
//*
//EXPORT EXPORT SYMLIST=*
//*
// SET CPSMHLQ=CICSDPP.BETA14.CTS53BT.CPSM
// SET CICSHLQ=CICSDPP.BETA14.CTS53BT.CICS
// SET CICSPLEX=CICSPLEX
// SET JAVAHOME='/java/J8.0_64/'
// SET BUNWRKDR='/var/cicsts/devops/workdir'
// SET BUILDDIR='/var/cicsts/devops/builds'
// SET TARGETDR='/var/cicsts/devops/platform'
// SET CICSBTCM='/usr/lpp/cicsts/cicsbt/cicsbt/cicsbt_zos'
// SET BINDNAME='com.ibm.cics.genapp51.single.binding'
// SET PLATNAME='com.ibm.cics.genapp51.single.platform'
// SET PLATDEF='SINGPLAT'
// SET BINDVRNM='com.ibm.cics.genapp51.single.binding_1.0.0'
// SET APPLNAME='com.ibm.cics.genapp51.application_1.0.0'
//*
// SET CISCOPE=CICSDA01
//*
//* First step is to copy only the bundle you want to resolve
//*
//COPY EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDENV DD *,SYMBOLS=JCLONLY
JAVA_HOME=&JAVAHOME
/*
//STDPARM DD *,SYMBOLS=JCLONLY
SH
rm -r &BUNWRKDR/bundles/*;
cp -r
&BUILDDIR/&BINDNAME/*
&BUNWRKDR/bundles
//*
//* Second step is to resolve the bundle using cicsbt_zos
//*
//RESOLVE EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDENV DD *,SYMBOLS=JCLONLY
JAVA_HOME=&JAVAHOME
/*
//STDPARM DD *,SYMBOLS=JCLONLY
PGM
&CICSBTCM
--resolve &BUNWRKDR/bundles
--output &TARGETDR/
--properties &TARGETDR/bundles/variables.properties
--verbose
//*
//* Third step is DEPLOY and set available the new bundle
//*
//DEPLOY EXEC PGM=DFHDPLOY,REGION=100M
//*
//STEPLIB DD DISP=SHR,DSN=&CPSMHLQ..SEYUAUTH
// DD DISP=SHR,DSN=&CICSHLQ..SDFHLOAD
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSIN DD *,SYMBOLS=JCLONLY
SET CICSPLEX(&CICSPLEX);
*
* Define a CICS bundle resource and transition it towards an
* ENABLED state within the current CICSplex.
*
UNDEPLOY APPLICATION(GENASING)
VERSION(1.0.0)
SCOPE(&CISCOPE)
PLATFORM(&PLATDEF)
STATE(DISCARDED);
*
DEPLOY APPLICATION(GENASING)
APPLDIR(&TARGETDR/
&PLATNAME/
applications/
&APPLNAME/)
BINDDIR(&TARGETDR/
&PLATNAME/
bindings/
&BINDVRNM/)
STATE(AVAILABLE)
Each of the deployment tasks is a job step: COPY, RESOLVE, and DEPLOY. In both the COPY and RESOLVE steps, the BPXBATCH utility is used, allowing UNIX System Services commands to be run as specified in the STDPARM DD statement.
Throughout the job, we rely heavily on the use of symbols to avoid repetition of variables and to allow substitution, which includes using substitution within in-stream data sets, which is possible in z/OS V2.1 and later versions. Some of these variables are related to system setup (for example, the location of Java (JAVAHOME), the location of the CICS build toolkit (CICSBTCM), and the location of CICS data sets (CPSMHLQ and CICSHLQ)), and are likely to be shared across all installation scripts. However, other variables can change, such as those relating to the exact application, platform, and application binding that we are targeting. By passing different parameters to this script, different applications can be deployed.
The third step of this script, in which DFHDPLOY runs, undeploys the existing application before deploying the new application. Be careful because these steps can result in a small loss of service for the application. However, if application multi-versioning is used, both applications can coexist simultaneously, with the higher-versioned application taking the workload when it is available and the lower-versioned application being removed when appropriate, such as when another higher-versioned application is deployed or sufficient testing of the higher-versioned application is conducted. In this example, the application is not suitable for multi-versioning, thus leading to a loss of service.
When the job is run, the output looks like what is shown in Example 7-2.
Example 7-2 Output of the application deployment job
1 J E S 2 J O B L O G -- S Y S T E M M V H 1 -- N O D E W I N M V S H 0
0
16.14.08 JOB48117 ---- WEDNESDAY, 02 DEC 2015 ----
16.14.08 JOB48117 IRR010I USERID REDS01 IS ASSIGNED TO THIS JOB.
16.14.08 JOB48117 ICH70001I REDS01 LAST ACCESS AT 16:14:07 ON WEDNESDAY, DECEMBER 2, 2015
16.14.08 JOB48117 $HASP373 CLODDPLY STARTED - INIT 12 - CLASS A - SYS MVH1
16.14.08 JOB48117 IEF403I CLODDPLY - STARTED
16.14.11 JOB48117 - --TIMINGS (MINS.)-- ----PAGING COUNTS---
16.14.11 JOB48117 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE SWAP VIO SWAPS STEPNO
16.14.11 JOB48117 -CLODDPLY COPY 00 52 .00 .00 .05 315 0 0 0 0 0 1
16.14.25 JOB48117 -CLODDPLY RESOLVE 00 74 .00 .00 .22 366 0 0 0 0 0 2
16.14.43 JOB48117 -CLODDPLY DFHDPLOY 00 421 .00 .00 .30 3476 0 0 0 0 0 3
16.14.43 JOB48117 IEF404I CLODDPLY - ENDED
16.14.43 JOB48117 -CLODDPLY ENDED. NAME- TOTAL CPU TIME= .00 TOTAL ELAPSED TIME= .59
16.14.43 JOB48117 $HASP395 CLODDPLY ENDED
0------ JES2 JOB STATISTICS ------
- 02 DEC 2015 JOB EXECUTION DATE
- 85 CARDS READ
- 187 SYSOUT PRINT RECORDS
- 0 SYSOUT PUNCH RECORDS
- 11 SYSOUT SPOOL KBYTES
- 0.59 MINUTES EXECUTION TIME
 
!! END OF JESMSGLG SPOOL FILE !!
1 //CLODDPLY JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID JOB48117
//*
IEFC653I SUBSTITUTION JCL - CLASS=A,MSGCLASS=A,NOTIFY=REDS01
2 //EXPORT EXPORT SYMLIST=*
//*
3 // SET CPSMHLQ=CICSDPP.BETA14.CTS53BT.CPSM
4 //CPSMHLQ EXPORT EXPSET=CICSDPP.BETA14.CTS53BT.CPSM GENERATED STATEMENT
5 // SET CICSHLQ=CICSDPP.BETA14.CTS53BT.CICS
6 //CICSHLQ EXPORT EXPSET=CICSDPP.BETA14.CTS53BT.CICS GENERATED STATEMENT
7 // SET CICSPLEX=CICSPLEX
8 //CICSPLEX EXPORT EXPSET=CICSPLEX GENERATED STATEMENT
9 // SET JAVAHOME='/java/J8.0_64/'
10 //JAVAHOME EXPORT EXPSET=/java/J8.0_64/ GENERATED STATEMENT
11 // SET BUNWRKDR='/var/cicsts/devops/workdir'
12 //BUNWRKDR EXPORT EXPSET=/var/cicsts/devops/workdir GENERATED STATEMENT
13 // SET BUILDDIR='/var/cicsts/devops/builds'
14 //BUILDDIR EXPORT EXPSET=/var/cicsts/devops/builds GENERATED STATEMENT
15 // SET TARGETDR='/var/cicsts/devops/platform'
16 //TARGETDR EXPORT EXPSET=/var/cicsts/devops/platform GENERATED STATEMENT
17 // SET CICSBTCM='/usr/lpp/cicsts/cicsbt/cicsbt/cicsbt_zos'
18 //CICSBTCM EXPORT EXPSET=/usr/lpp/cicsts/cicsbt/c... GENERATED STATEMENT
19 // SET BINDNAME='com.ibm.cics.genapp51.single.binding'
20 //BINDNAME EXPORT EXPSET=com.ibm.cics.genapp51.si... GENERATED STATEMENT
21 // SET PLATNAME='com.ibm.cics.genapp51.single.platform'
22 //PLATNAME EXPORT EXPSET=com.ibm.cics.genapp51.si... GENERATED STATEMENT
23 // SET PLATDEF='SINGPLAT'
24 //PLATDEF EXPORT EXPSET=SINGPLAT GENERATED STATEMENT
25 // SET BINDVRNM='com.ibm.cics.genapp51.single.binding_1.0.0'
26 //BINDVRNM EXPORT EXPSET=com.ibm.cics.genapp51.si... GENERATED STATEMENT
27 // SET APPLNAME='com.ibm.cics.genapp51.application_1.0.0'
28 //APPLNAME EXPORT EXPSET=com.ibm.cics.genapp51.ap... GENERATED STATEMENT
//*
29 // SET CISCOPE=CICSDA01
30 //CISCOPE EXPORT EXPSET=CICSDA01 GENERATED STATEMENT
//*
//* First step is to copy only the bundle you want to resolve
//*
31 //COPY EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
32 //STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
33 //STDOUT DD SYSOUT=*
34 //STDERR DD SYSOUT=*
35 //STDENV DD *,SYMBOLS=JCLONLY
36 //STDPARM DD *,SYMBOLS=JCLONLY
//*
//* Second step is to resolve the bundle using cicsbt_zos
//*
37 //RESOLVE EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
38 //STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
39 //STDOUT DD SYSOUT=*
40 //STDERR DD SYSOUT=*
41 //STDENV DD *,SYMBOLS=JCLONLY
42 //STDPARM DD *,SYMBOLS=JCLONLY
//*
//* Third step is DEPLOY and set available the new bundle
//*
43 //DFHDPLOY EXEC PGM=DFHDPLOY,REGION=100M
//*
44 //STEPLIB DD DISP=SHR,DSN=&CPSMHLQ..SEYUAUTH
IEFC653I SUBSTITUTION JCL - DISP=SHR,DSN=CICSDPP.BETA14.CTS53BT.CPSM.SEYUAUTH
45 // DD DISP=SHR,DSN=&CICSHLQ..SDFHLOAD
//*
IEFC653I SUBSTITUTION JCL - DISP=SHR,DSN=CICSDPP.BETA14.CTS53BT.CICS.SDFHLOAD
46 //SYSTSPRT DD SYSOUT=*
//*
47 //SYSIN DD *,SYMBOLS=JCLONLY
 
!! END OF JESJCL SPOOL FILE !!
ICH70001I REDS01 LAST ACCESS AT 16:14:07 ON WEDNESDAY, DECEMBER 2, 2015
IEF236I ALLOC. FOR CLODDPLY COPY
IEF237I BC01 ALLOCATED TO STEPLIB
IEF237I JES2 ALLOCATED TO STDOUT
IEF237I JES2 ALLOCATED TO STDERR
IEF237I JES2 ALLOCATED TO STDENV
IEF237I JES2 ALLOCATED TO STDPARM
IEF142I CLODDPLY COPY - STEP WAS EXECUTED - COND CODE 0000
IEF285I CEE.SCEERUN KEPT
IEF285I VOL SER NOS= PHSY02.
IEF285I REDS01.CLODDPLY.JOB48117.D0000106.? SYSOUT
IEF285I REDS01.CLODDPLY.JOB48117.D0000107.? SYSOUT
IEF285I REDS01.CLODDPLY.JOB48117.D0000101.? SYSIN
IEF285I REDS01.CLODDPLY.JOB48117.D0000102.? SYSIN
IEF373I STEP/COPY /START 2015336.1614
IEF032I STEP/COPY /STOP 2015336.1614
CPU: 0 HR 00 MIN 00.01 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 164K SYS: 296K EXT: 132K SYS: 10540K
ATB- REAL: 16K SLOTS: 0K
VIRT- ALLOC: 2409M SHRD: 0M
IEF236I ALLOC. FOR CLODDPLY RESOLVE
IEF237I BC01 ALLOCATED TO STEPLIB
IEF237I JES2 ALLOCATED TO STDOUT
IEF237I JES2 ALLOCATED TO STDERR
IEF237I JES2 ALLOCATED TO STDENV
IEF237I JES2 ALLOCATED TO STDPARM
IEF142I CLODDPLY RESOLVE - STEP WAS EXECUTED - COND CODE 0000
IEF285I CEE.SCEERUN KEPT
IEF285I VOL SER NOS= PHSY02.
IEF285I REDS01.CLODDPLY.JOB48117.D0000108.? SYSOUT
IEF285I REDS01.CLODDPLY.JOB48117.D0000109.? SYSOUT
IEF285I REDS01.CLODDPLY.JOB48117.D0000103.? SYSIN
IEF285I REDS01.CLODDPLY.JOB48117.D0000104.? SYSIN
IEF373I STEP/RESOLVE /START 2015336.1614
IEF032I STEP/RESOLVE /STOP 2015336.1614
CPU: 0 HR 00 MIN 00.01 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 164K SYS: 304K EXT: 132K SYS: 10544K
ATB- REAL: 16K SLOTS: 0K
VIRT- ALLOC: 2409M SHRD: 0M
IEF236I ALLOC. FOR CLODDPLY DFHDPLOY
IGD103I SMS ALLOCATED TO DDNAME STEPLIB
IGD103I SMS ALLOCATED TO DDNAME
IEF237I JES2 ALLOCATED TO SYSTSPRT
IEF237I JES2 ALLOCATED TO SYSIN
IEF142I CLODDPLY DFHDPLOY - STEP WAS EXECUTED - COND CODE 0000
IGD104I CICSDPP.BETA14.CTS53BT.CPSM.SEYUAUTH RETAINED, DDNAME=STEPLIB
IGD104I CICSDPP.BETA14.CTS53BT.CICS.SDFHLOAD RETAINED, DDNAME=
IEF285I REDS01.CLODDPLY.JOB48117.D0000110.? SYSOUT
IEF285I REDS01.CLODDPLY.JOB48117.D0000105.? SYSIN
IEF373I STEP/DFHDPLOY/START 2015336.1614
IEF032I STEP/DFHDPLOY/STOP 2015336.1614
CPU: 0 HR 00 MIN 00.07 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 16K SYS: 300K EXT: 2384K SYS: 10544K
ATB- REAL: 28K SLOTS: 0K
VIRT- ALLOC: 2409M SHRD: 0M
IEF375I JOB/CLODDPLY/START 2015336.1614
IEF033I JOB/CLODDPLY/STOP 2015336.1614
CPU: 0 HR 00 MIN 00.09 SEC SRB: 0 HR 00 MIN 00.00 SEC
 
!! END OF JESYSMSG SPOOL FILE !!
 
IBM's internal systems must only be used for conducting IBM's business
or for purposes authorized by IBM management.
 
>> WINMVSH1 at z/OS 1.01.00
 
>> Wednesday 02 December 2015, JDay: 336
 
 
!! END OF STDOUT SPOOL FILE !!
Successfully resolved /var/cicsts/devops/workdir/bundles to /var/cicsts/devops/platform
 
!! END OF STDOUT SPOOL FILE !!
16:14:25.360784 : DFHDPLOY CICS TS APPLICATION DEPLOYMENT 2015/12/02 4:14pm
16:14:25.363714 : SET CICSPLEX(CICSPLEX);
16:14:25.368988 : DFHRL2013I Connection to CICSPLEX(CICSPLEX) successful.
16:14:26.389328 :
16:14:26.389382 : *
16:14:26.389396 : * Define a CICS bundle resource and transition it towards an
16:14:26.389404 : * ENABLED state within the current CICSplex.
16:14:26.389413 : *
16:14:26.389421 : UNDEPLOY APPLICATION(GENASING)
16:14:26.389431 : VERSION(1.0.0)
16:14:26.389440 : SCOPE(CICSDA01)
16:14:26.389448 : PLATFORM(SINGPLAT)
16:14:26.389458 : STATE(DISCARDED);
16:14:29.423585 : DFHRL2081I Application(GENASING) Version(1.0.0) in Platform(com.ibm.cics.genapp51.single.platform) does not exist.
16:14:29.434298 : DFHRL2056I CICS application definition for APPLICATION(GENASING) has been removed.
16:14:29.434357 : DFHRL2037I UNDEPLOY command successful.
16:14:29.452419 :
16:14:29.452461 : *
16:14:29.452473 : DEPLOY APPLICATION(GENASING)
16:14:29.452482 : APPLDIR(/var/cicsts/devops/platform/
16:14:29.452490 : com.ibm.cics.genapp51.single.platform/
16:14:29.452499 : applications/
16:14:29.452509 : com.ibm.cics.genapp51.application_1.0.0/)
16:14:29.452518 : BINDDIR(/var/cicsts/devops/platform/
16:14:29.452526 : com.ibm.cics.genapp51.single.platform/
16:14:29.452535 : bindings/
16:14:29.452544 : com.ibm.cics.genapp51.single.binding_1.0.0/)
16:14:29.452553 : STATE(AVAILABLE)
16:14:29.452561 :
16:14:30.510030 : DFHRL2044I CICS application definition(GENASING) created.
16:14:31.521346 : DFHRL2045I CICS application definition(GENASING) installed.
16:14:37.610669 : DFHRL2046I Setting application state to ENABLED.
16:14:40.660380 : DFHRL2046I Setting application state to AVAILABLE.
16:14:43.717402 : DFHRL2012I DEPLOY command completed successfully.
16:14:43.763215 :
16:14:43.763324 : DFHRL2007I Processing complete.
16:14:43.798314 : DFHRL2014I Disconnecting from CICSPLEX(CICSPLEX).
 
!! END OF SYSTSPRT SPOOL FILE !!
The output shows the three steps of the job running: COPY moves files into place, RESOLVE uses the CICS build toolkit to resolve the application binding, and DFHDPLOY deploys the application to CICS. In this case, the application does not exist, so the UNDEPLOY command to DFHDPLOY has no effect. However, if the application existed, it is removed and then the new application is installed.
The SYSTSPRT output of DFHDPLOY for this example is shown in Example 7-3.
Example 7-3 SYSTSPRT output of DFHDPLOY when the application exists
21:25:16.085229 : DFHDPLOY CICS TS APPLICATION DEPLOYMENT 2015/12/03 9:25pm
21:25:16.088220 : SET CICSPLEX(CICSPLEX);
21:25:16.104461 : DFHRL2013I Connection to CICSPLEX(CICSPLEX) successful.
21:25:17.130505 :
21:25:17.130563 : *
21:25:17.130575 : * Define a CICS bundle resource and transition it towards an
21:25:17.130584 : * ENABLED state within the current CICSplex.
21:25:17.130592 : *
21:25:17.130600 : UNDEPLOY APPLICATION(GENASING)
21:25:17.130610 : VERSION(1.0.0)
21:25:17.130620 : SCOPE(CICSDA01)
21:25:17.130628 : PLATFORM(SINGPLAT)
21:25:17.130638 : STATE(DISCARDED);
21:25:20.170062 : DFHRL2092I Application(com.ibm.cics.genapp51.application) Version(1.0.0) found on Platform(com.ibm.cics.genapp51.single.platform).
21:25:20.170217 : DFHRL2064I APPLICATION(GENASING) VERSION(1.0.0) state is ENABLED and availability is AVAILABLE.
21:25:20.170281 : DFHRL2046I Setting application state to UNAVAILABLE.
21:25:24.244958 : DFHRL2122I Quiescing tasks for application(GENASING) version(1.0.0).
21:25:26.271643 : DFHRL2091I No active tasks found for application(GENASING) version(1.0.0).
21:25:26.271756 : DFHRL2061I Quiesce of tasks for application(GENASING) version(1.0.0) completed successfully.
21:25:26.271821 : DFHRL2046I Setting application state to DISABLED.
21:25:30.346731 : DFHRL2042I Discarding APPLICATION(GENASING).
21:25:32.388240 : DFHRL2056I CICS application definition for APPLICATION(GENASING) has been removed.
21:25:32.388317 : DFHRL2037I UNDEPLOY command successful.
21:25:32.433415 :
21:25:32.433467 : *
21:25:32.433478 : DEPLOY APPLICATION(GENASING)
21:25:32.433488 : APPLDIR(/var/cicsts/devops/platform/
21:25:32.433497 : com.ibm.cics.genapp51.single.platform/
21:25:32.433505 : applications/
21:25:32.433514 : com.ibm.cics.genapp51.application_1.0.0/)
21:25:32.433523 : BINDDIR(/var/cicsts/devops/platform/
21:25:32.433532 : com.ibm.cics.genapp51.single.platform/
21:25:32.433540 : bindings/
21:25:32.433551 : com.ibm.cics.genapp51.single.binding_1.0.0/)
21:25:32.433560 : STATE(AVAILABLE)
21:25:32.433570 :
21:25:33.476387 : DFHRL2044I CICS application definition(GENASING) created.
21:25:34.487638 : DFHRL2045I CICS application definition(GENASING) installed.
21:25:40.572146 : DFHRL2046I Setting application state to ENABLED.
21:25:43.641345 : DFHRL2046I Setting application state to AVAILABLE.
21:25:46.683510 : DFHRL2012I DEPLOY command completed successfully.
21:25:46.740392 :
21:25:46.740493 : DFHRL2007I Processing complete.
21:25:46.810790 : DFHRL2014I Disconnecting from CICSPLEX(CICSPLEX).
With this kind of automation in place, CICS cloud applications can be built and deployed without human intervention.
For brevity, in this scenario we have not covered the automatic testing that should take place at each stage of the DevOps pipeline. With automated testing, approval for changes to proceed to the next stage can be automatically assigned, with full confidence that they passed the tests.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset