In this second part of this blog series we will detail the mainframe features you can find in Clarive and how they are integrated into the system.

Clarive Mainframe Features

Clarive manages all aspects of the z/OS code lifecycle:

• Sending files to z/OS partitions
• Character translation maps and codepages
• Identify relationships – impact analysis
• JCL Template Management
• Submit JCL
• Nested JCL Management and synchronous – asynchronous queue control
• Retrieve Job Spool output and parse results

Integration rules

Clarive z/OS features 3 entirely different integration points with the mainframe. Each integration feature serves a specific purpose

• Job queue access – to ship files and submit jobs into the z/OS job queue in batch mode. Clarive will track all nested jobs and parse results into the job tree.

• ClaX Agent – for delivering files into Datasets and/or OMVS partitions and executing z/OS processes online. This is the preferred way of running REXX scripts sent from Clarive to the mainframe. Access z/OS facilities such as SDSF^®,ISPF^®, VSAM^® data records or RACF^®.

• Webservices Library – for writing code that initiates calls from the mainframe directly into Clarive using TCP/IP sockets and the RESTful webservices features of the Clarive rules.

Clarive to Mainframe Integration Point

Tool considerations

Clarive is a tool that allows enterprise companies to implement an end-to-end solution to control the software lifecycle providing countless out-of-the-box functionalities that help solving any complex situation (automation, integration with external tools, critical regions, manual steps through the process, collaboration, etc.)

CCMDB – Configuration Items

In Clarive any entity that is part of the physical infrastructure or the logical lifecycle is represented as a configuration item (CI). Servers, projects/applications, sources repositories, databases, users, lifecycle states, etc. are represented as CIs in Clarive under the name Resource.

Any resource can have multiple relationships with other resources (i.e. an application is installed in one server in production, a user is developer of an application, the Endevor “system x/subsystem y” combination is the source code repository related to an application, etc.)

The graph database made of this entities and relationships is Clarive’s Change oriented Configuration Management Database (CCMDB). The CCMBD is used to keep the whole system configuration as well as to do impact analysis, infrastructure requests management, etc.

CCMBD navigation

Natures / Technologies

Clarive natures are special CIs in Clarive that automate the identification of technologies to be deployed by a deployment job. A nature can be detected by
file path/name (i.e. Nature SQL: *.sql), by project variable values (i.e. ${weblogic}:Y) or by parsing the changed files code (i.e. COBOL/DB2: qr/EXEC SQL/)

Natures list

JES spool monitoring

Clarive will take care of downloading and parsing the spool output when submitting a JCL in z/OS to split the DDs available in the output and to identify and use the return codes of all steps executed in the JCL.

JES output viewer

Calendaring / Deployment scheduling – Calendar slots

Any deployment job in Clarive will be scheduled and Clarive will provide the available slots depending on the infrastructure affected by the deployment. Infrastructure administrators can define these slots related to any CCMDB level (environment, project, project groups, server, etc…)

Calendar slots definition

Rollback

Clarive rule will allow the administrator to define the way to rollback changes. In either Endevor and ChangeMan ZMF it will execute a Backout operation on each package included in the job.

Rollback control

Next Steps

Features are an important step when picking the right tool to bring DevOps to the mainframe.

In the next 2 installments of this series we will review how Clarive can deploy mainframe artifacts (or elements), either by driving popular z/OS SCM tool such as CA Endevor or Serena ChangeMan, or replacing them with Clarive’s own z/OS deployment agents.

Read the first post of this series and learn more on how to bring DevOps to the mainframe.