Mainframe Deployment Process with HCL Launch

HCL Launch is an enterprise-wide deployment tool that can deploy to all your platforms from Mainframe to Mobile. Whether you are deploying your RPG programs in IBM I or COBOL in your IBM Z or Java to your distributed systems, all of them can be done via HCL Launch.

We understand that z/OS deployment needs some specific customization. HCL Launch supports incremental versions that is very common in z/OS. We support merging versions, doing delta deploy of artifacts that saves the deployment time. We support searching of artifacts to find the version where/when it was deployed in an environment.

HCL Launch helps you with packaging of the artifacts. z/OS build systems don’t do packaging. HCL Launch has a utility called buzztool to package zOS artifacts.

This blog will talk about a simple mainframe deployment process design. A simple component process design for Mainframe deployment will have the following steps:

1. Download Artifacts for z/OS.
2. Deploy Datasets
3. Generate Artifact Info
4. Bind DB2 DBRMs
5. Newcopy CICS resources
6. Replace Tokens

Download Artifacts for z/OS:

This step is used to download the version artifacts to be deployed from Launch’s in-built artifact repository – Codestation to the target Mainframe LPAR. If you are storing your artifacts in an external artifact repository like Artifactory or Nexus, you can use this plugin to do the download to the target Mainframe LPAR.

Typically, this step needs no specific inputs to be configured.

Deploy Datasets:

This step deploys to the USS folders / PDS members in the target Mainframe LPAR. It uses the artifacts that were downloaded from the previous step and the Dataset mapping provided in the step properties to map them to the target dataset.

Typically, Dataset mapping (and many other properties in a deployment process) is configured as an environment property. This way, when a new target environment is created, these environment specific properties can be defined at the environment level.

Sample dataset mapping is provided below. It is of the format source_pds , target_pds. Source_pds is the PDS name that was used in the shiplist during version creation using buztool. These are the pds names of the dev environment. These are the names that you see when you see the version in HCL Launch UI. (Components -> YourComponentName -> Versions -> YourVersionName). Target_pds are the pds names of this environment where the deployment needs to happen.

Deploy datasets has a flag for “Backup for Rollback”. If checked, this step would backup the current PDS members that are going to be replaced before deployment. This in-built backup/rollback feature is unique to HCL Launch Mainframe plugin. Backups are stored in USS in the target LPAR and will be used by “Rollback Dataset” step, if needed.

You can configure to allow dataset creation that enables the plugin to create the datasets, if they are not already present in the target LPAR.

Generate Artifact Information:

After deployment to PDS is done, typically there are post deployment steps like Binds , Newcopies that needs to be done. This step helps to identify the artifacts that needs to go through a post-deployment process (for example, Bind) and also generate commands (for example, a bind card) for each of them from a template. There is a new plugin now that can generate multiple commands for different sets of artifacts

This step helps to filter the artifacts using source PDS name (Container name), Target PDS name, Deploy type or even using your own custom properties.

Then you provide a JSON template like shown below that can generate different output properties using different templates. These output properties can be referred in subsequent steps for post-deployment. Any number of output properties can be generated from one single step.

Bind job:

DB2 binds are done by submitting a job using the “Submit Job” plugin step and using the bind parameters generated on the previous step.

CICS Newcopy:

CICS newcopy is done using CICS TS plugin and the list of CICS programs generated above.

Replace Tokens:

Typically, there are instances in mainframe deployment where a ${HLQ} needs to be replaced with the high level qualifier for that environment. For example, in JCLs. A templated version of the JCL (or any other artifact like a DB2 DML statement) can be stored in the SCM. And each environment can be configured with HLQ/DB2 Schema name in the application environment properties.

This step can replace all the tokens in the target environment after the deployment with the values specific to that environment. This makes it easy to store the templated version in a SCM and have the deployment tool substitute the environment specific values.

Switch steps:

You might have noticed switch steps in the process design above. These steps help to decide whether which path to take based on a property value. In this case, we have used the switch step to bypass a post-deployment step like Bind, if there is nothing to bind.

Generate Artifact step generates a count variable for every output property. If the count is non-zero for bindCard, then the bind step gets executed, else it is skipped. This is an excellent way to skip a lot of post deployment steps, if not needed.

Need help setting up plugins with HCL Launch? Reach out to our support team here.