Change a Cobol PGM versioning fallback and deploy
Contents
Getting Started with SCM – BMC AMI DevX Code Pipeline
The goal of this Test Drive is to make a change to a Cobol program using BMC AMI DevX Workbench for Eclipse, generate, and promote it to Production using BMC AMI DevX Code Pipeline. Code Pipeline enables developers to quickly and safely build, and test their mainframe code.
This Test Drive will take you through the following activities:
- Creating an Assignment
- Code changes to a program
- Generating/compiling
- Promotion to Production
- View deployment of module
- Fallback a module
- View versions of module
Instructions:
- This guide contains many screenshots to provide a visual reference
- Specifies every action you must take
- Please note each place that you must enter your own specific ID or number
- You must complete each step before proceeding to the next to successfully follow the guide
If at any point during your experience the host connection times out, you may need to log back into the Test Drive host connection.
In this Test Drive the screen shots provided have used specific values that may differ from your assigned values. These were provided in your email notice. Substitute your values in the screenshots.
Code Changes
Your development task in this Test Drive is to change a COBOL program using DevX Workbench's Editor then generate and promote it through the Application Life-Cycle to Production.
First, you will find and add a COBOL program into an Code Pipeline Assignment from which you can perform all this work.
The Repository View lists the COBOL Components for your application.
Your Assignment has been created and you should now have a COBOL program in it. The Assignment view will open and the Task that was added will be listed.
Every operation that needs to be performed on this Task and other Components which are impacted by changing this Task (edit, impact analysis, compile, promote, deployment, etc.) can be performed from this Assignment or other Assignments. A developer will spend most of their time in an Assignment container. Note that the COBOL program in the Assignment is checked out and sitting in the DEV1 level. The Checkout Date/Time and User ID is reflected in the Task information. At checkout, a destination level for the checkout was chosen – DEV1.
A picture of the Life-Cycle is presented. You will notice the levels containing the Versions of the highlighted COBOL program are colored indicating the existence of a version of that Component at those levels. From this picture it is very easy to visually see where Versions exist. By choosing the DEV1 Level, you have defined the Path to Production→DEV1-QA1-STG-PRD. Other versions of these Components may also exist at other levels and may be passing through the other three paths – FIX, DEV2, or DEV3. Four paths were created for the application – one for emergencies starting at level FIX and three for development starting at DEV1, DEV2, and DEV3. The application level structure is customizable when defining the applications to Code Pipeline. Any number of paths can be defined with a minimum of three Levels.
Now that you have a Version of a COBOL program the next step would be to make changes to it.
Note the Operation, Date/Time, and User ID fields have been updated to reflect the change in the Task status.
Generate (AKA Compile)
The COBOL program will be generated/compiled, and your Assignment Task List will be updated to reflect the new status.
- The Operation will be Generate
- The User ID, Date/Time will be updated
- The Message will be updated to reflect the successful completion of the generate
Now it is time to compile/generate the program, so we can do our testing.
The Message will be updated to reflect the successful completion of the generate and the date and time will be updated. The screen will refresh automatically when the generate is done. At that time, the Task will be updated with the date and time of the generate, the user who performed the generate, and the operation will reflect a generate has occurred. Ensure that the generate worked and ended with a return code zero.
You can also view the output of the generate job.
This displays the output of the job that did the Generate.
Promotion
At this point you have:
- Edited a COBOL program
- Used the DevX Workbench Editor to help you make your changes
- Generated your program
Now you are ready to promote your changes to the QA1 level.
This action will create a Set Container. Sets are a special category of container that are used to conduct operations such as promotion and deploy. They are temporary and created by Code Pipeline as needed for the work. This allows you to promote subsets of Tasks within an Assignment container without the need to act on all the Tasks at once. Once you click Promote the selected Task(s) are placed in a SET container for the promotion. The Code Pipeline Set processor will:
- Perform the promotion of the source to QA1
- Cleanup the DEV1 level (source and parts if applicable)
- Perform generates, in order, of all the Task(s) in the SET which require a generation
A notification will appear in the lower right of the DevX Workbench indicating the Promotion has completed.
In the screenshot below, you can see the promote operation has completed – the Task has been promoted to QA1 (see the Level value and the Operation in the Task List as well). The Operation column shows Generate as the last operation. The SET processor performed a promotion and then a generation as Code Pipeline recognized a generate was required for COBOL types at the QA1 level based on the configuration of this application. This can be configured by the Code Pipeline administrator.
Let us assume all the testing at the QA1 level has been successfully completed and you are ready to promote to the STG level.
In the screenshot above, you can see the promote operation has completed – the Task has been promoted to STG (see the Level value and the Operation in the Task List as well as the highlighted Level in the picture). Note the Operation column shows Promote as the last operation. The SET processor performed a promotion. The Code Pipeline Set processor:
- Performed the promotions of all the parts to STG
- Cleaned up the QA1 level (source and parts if applicable)
The last Operation shows Promote and the STG box in the life cycle has been highlighted. The source and its parts have all been promoted to STG and no recompile was done.
Let's view the Parts that were promoted along with the source.
You can see the different parts that were promoted along with the Cobol source. There is an Object and Load module, a listing, and the Source Listing (part DMEM). When TPROG01 and its Parts reaches Production some of these Parts will be deployed to runtime libraries.
Assuming all the testing at the STG level has been successfully completed, you are now ready to promote the Tasks to the PRD level.
In this screenshot, as the Task(s) in the SET are being processed, you can see:
- The Task will be selected for a Promote
- Code Pipeline will start a SET processor for this SET
- The COBOL program, and its parts will be promoted
You can monitor the progress by clicking the refresh button.
A Set container will be created. The selected Task(s) are being placed in a SET container for the promotion. The Code Pipeline Set processor will:
- Perform the promotions of all the parts to the PRD Level
- Clean-up the STG level source and parts as applicable
A notification will appear in the lower right of the DevX Workbench indicating the application has been configured to require an approval for the promotion to PRD. The Tasks are locked in a SET for a Promote process, but the SET needs approval before the promote can proceed.
Below the STATUS shows the Tasks are locked in a SET for a Promote process but the SET needs approval before the promote can proceed.
The Approval can be performed from:
- DevX Workbench/Code Pipeline
- TSO/Code Pipeline in the ISPF interface
- Web interface (including mobile browser)
For this Test Drive you will do the approval from DevX Workbench/Code Pipeline.
You can see in the updated screen below that:
- SET processing has completed
- The COBOL program has been processed for a Promotion and is now at the PRD level
- A Deploy has taken place
The Promotion to the PRD level has completed. The source and parts for the COBOL program were moved to the PRD level Life-Cycle libraries and the STG level libraries were cleaned up as appropriate. Notice the Operation column shows Implement as the last operation. Code Pipeline performed any tasks that were configured for deploy and activation. An example of a Deploy Implementation activity is the copy of the executable load module into a CICS or IMS runtime library. Examples of an activation activity would be a DB2 Plan or Package Bind or a CICS New copy.
Now let's open the Deployment view.
You will see the set operations for TPROG01.
The Deployment view is opened and filtered on the set used for the deploy of TPROG01.
This shows the modules that were deployed and the datasets they were deployed to.
If you highlight the next program you will see the Source Shared Directory (SSD) where the Listing was stored. You can continue through all the programs if you wish. Notice the tasks were deployed to 2 different LPARs, CWC2, and CWCC. Click Cancel.
This View contains additional detailed information on the deploys. You will see all the information pertaining to the deploy request, dates, times, dataset names, etc.
The filter should be added pointing to the dataset.
Back in the Code Pipeline perspective Life Cycle view, we can see from the PRD level box that V15 is in PRD. Your version numbers may be different.
Once Fallback is selected you will receive the following message.
An approval is required to do the Fallback at the PRD level.
Your version numbers may be different.
You see the current PRD version. Make sure to select Show Inactive Versions. You will see all the inactive and the active PRD versions. Note that the last operation is Implement. This means that in addition to the Fallback in PRD, a deploy was done to restore the deploy datasets to the correct version of the code.
You have completed your Test Drive, now it is time to close the assignment. As a Developer you are now finished with your Assignment, so it can be closed. Assignments are closed manually and are usually closed to unclutter the Container List View.
A Close confirmation panel is presented.
For audit purposes, Closed Assignments, Sets, and Releases are never deleted from Code Pipeline. They are just filtered out of the standard day-to-day filtering. Once an Assignment, Set, or Release is closed it is removed from the standard filtered list, but it is still part of Code Pipeline history and can be viewed at any time.
You are done! Your job has been to change a Cobol program, and promote it through the Stream to PRD. Examine the deployed modules and perform a Fallback on the module in PRD. As a part of this exercise, you have used DevX Workbench and Code Pipeline to execute a workflow:
- Created an Assignment
- Checked out a Cobol program to the DEV1 level
- Changed it using the DevX Workbench Editor
- Compiled/Generated the program
- Promoted the Task from DEV1 to QA1
- Promoted the Task from QA1 to STG
- Promoted from STG to PRD a deploy was initiated automatically
- Viewed the Deployed Tasks
- Performed a Fallback
- Viewed the Version History of the Task
- Closed your Assignment to complete the change cycle
Congratulations! This completes the Code Pipeline tutorial for BMC Test Drive.