Emergency Change with Retrofit
Contents
- Getting Started with SCM – BMC AMI DevX Code Pipeline
- Code Changes
- Generate (AKA Compile)
- Promotion
- Retrofit
versionto
Getting Started with SCM – BMC AMI DevX Code Pipeline
The goal of this Test Drive is to make a emergency change to a Cobol program using BMC AMI DevX Workbench for Eclipse and promote it to Production using BMC AMI DevX Code Pipeline. You will then retrofit the code to another program. 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
- Changing code to fix a Production problem
- Using the compare and merge tool to retrofit code changes
- Generating/compiling
- Promoting and overlaying QA and observing the messaging
- Promoting to Production
Instructions:
- This guide contains many screenshots to provide a visual reference
- 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.
Code Changes
Your development task in this Test Drive is to change a COBOL program using the DevX Workbench Editor in the emergency stage, then generate and promote it through the Application Life-Cycle to Production. A second program will then need to be retrofitted with the code that was promoted to Production.
First, you will find and add a COBOL program into an Code Pipeline Assignment from which you can perform all this work.
- Change the Stream to CWEZ.
- Change the Application to your assigned application value (Txxx, where xxx is your unique number).
- Note: The SubAppl field will automatically populate with Assignment
- Set the Level to "PRD" and ensure the Level option is set to "Selected level only" or "All found in level and above" both settings will return the same results since there is nothing above PRD.
- Filter the view even further by setting the Type to COB, this will allow you to focus only on the COBOL program components available in your stream | application at the PRD level. Click Apply (circled).
The Repository View lists the COBOL Components for your application.
Scroll through the list and find COB TPROG09 PRD. Right-click on it and click Add to Assignment with Checkout, or click on the add to Assignment with Check Out button (circled).
From the Add Task to Assignment dialog box, you will notice 2 versions of the program: one at PRD and one at QA1.
First, select Path FIX. Leave PRD selected as the Base component version level.
Next, click New to the right of Assignment. This will allow you to create a new Assignment Container to put your Cobol program into.
Someone else is changing the same program and their version is at the QA1 level.
For Stream, use CWEZ. For Application and Assignment prefix, use your assigned values (see Substitute your values in the screenshots). Provide a description for your Assignment. Click OK.
You will see a message that the Assignment was successfully created (screenshot not shown). Click OK.
Your new Assignment number will appear in the Assignment field.
A message will be displayed to inform you that the task has been added to your Assignment.
Your Assignment has been created and you should now have a COBOL program in it.
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 FIX level. The Checkout Date/Time and User ID is reflected in the Task information. At checkout, a destination level for the checkout was chosen – FIX.
To see the Code Pipeline Life-Cycle path structure that was constructed for the Application, click once on the Task and then click on the View Life-Cycle icon.
A picture of the Life-Cycle is presented.
By choosing the FIX Level, you have defined the Path to Production ==> FIX-EMR-PRD. Other versions of these Components may also exist at other levels and may be passing through the other three paths – DEV1, 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.
In the Task View right-click on TPROG09, mouse over View, then click Component Versions.
When you first open the Component Versions view you will see the three versions of TPROG09.
If you select one of the versions it will bring up the version information in the Life Cycle view.
Notice that the information in the Life Cycle view has changed and version information has been added. This information can be very useful.
Now that you have a Version of a COBOL program the next step would be to make changes to it.
The version's source will be presented in the DevX Workbench Editor for editing.
If you see the Copybook Download message shown, click Yes, either with or without checking the box.
This will download the contents of the copybooks, so they can be used by the DevX Workbench Editor for various activities.
Change the source using the DevX Workbench Editor (don't break the program). You can type something in the comment area or add another comment line.
Once you have made your changes, close the DevX Workbench Editor view.
Click Yes to save the changes (screenshot not shown).
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.
To do this, right-click on TPROG09 and click Generate.
The status column will display a message indicating that the Task is being generated. 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.
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 EMR level.
To promote the Task to the EMR level, click on the Task view and right-click on the Task and click Promote.
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 EMR (see the Level value and the Operation in the Task List as well).
Note 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 EMR level based on the configuration of this application. This can be configured by the Code Pipeline administrator.
You can monitor the progress by clicking the refresh button. 
Assuming all the testing at the EMR level has been successfully completed, you are now ready to promote the Tasks to the PRD level.
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 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. Approvals are configured based upon customer needs and requirements.
Click once on TPROG09, then right-click on the EMR box and click Approve.
The program is promoted to PRD. The Operation status is Implement. This means the program was promoted and deployed to the runtime environment.
Retrofit
You have completed your emergency change. The current development version is still at QA1, but now you need to fit your emergency change into it. You will do this by checking out the QA1 version into the same path. You will merge the Production-fix changes into the version that is now in DEV1, and you will promote the new combined code and overlay the old version at QA1.
First, let's check the component versions again.
Right-click on TPROG09, mouse over View, then click Component Versions.
Your screen should look like this:
Notice, it shows the component at both QA1 and PRD.
Next, you're going to open the assignment that contains the version at QA1.
Verify that you opened the correct assignment. The Level column should show QA1. If not, click on the Component Versions view and be sure to click on the assignment that contains the component at QA1 (not PRD).
Notice the status, "Check versions," and the red double-arrow on the left.
This is a warning to the developer that another version of this component has passed their version in a different path. You can get more detail by viewing the messages.
Right-click on the program, and click View Messages.
You will see the following messages relating to the other version. The first message tells us that a version was checked out to FIX and the second that the version was promoted to PRD. At this point you can add a note, acknowledge the message, modify the message, delete, or close the message. This will give you information as to the status of the other developers who have your module checked out.
Click Close.
Right Click on the TPROG09 program and click "Add to Assignment with Check Out".
Click on the Filter button (blue)
Clear all filters except the Assignment, change this to be the assignment that contains the QA1 version (Note: this may be different than the one in the example)
Valiidate the Path to be DEV1, and make sure the QA1 version is selected (high-lite). Click OK.
A message that the task was checked out will appear (screenshot not shown).
TPROG09 is now checked out to the DEV1 level in the QA1 container.
Click once on your task in DEV1.
You need to incorporate the FIX changes into the QA1 version before it can promote forward to the next levels so that no code regression takes place.
First, we need to compare our DEV1 version with the version in Production (PRD) to retrofit our changes into the version at QA1.
Right-click on TPROG09 and click Compare/Merge.
Click the version in PRD.
Click OK.
The compare and merge view will appear. The first change that is seen is the change to the comment in TPROG09 from the FIX path change that you promoted to Production.
Click the Next Difference button.
You will see the first difference in TPROG09 version at DEV1 compared to the latest production version. Before reworking you would have analyzed the production fix made and determined what and how to incorporate this into the QA1 version
Using the Next Difference button as an easy way of cycling thru the differences, you can then copy the differences that are relevant to the DEV1 version in a controlled way. Do not! use "Copy All Non-Conflicting Changes" for that may deleted 'new code' that was added in the QA1 version.
Click the 'Copy Current Change from Right to Left' to incorporate the PRD change into the DEV1 program. (If the positions of the PRD and DEV1 versions are reversed for you you can use the swap left/right view button little to the left)
Your change has been copied to the DEV1 version of TPROG09.
You have now incorporated the QA1 changes into the program that had the Emergency fixes added.
Now, it's just a matter of promoting our newly merged code to Production.
Select the Tasks view.
Generate your program that is in DEV1 before you promote it. Ensure that the generate was successful by viewing the generate listing if necessary. View generate listing is found by right clicking the task.
You can monitor the progress by clicking the refresh button.
(Screenshots not shown.)
Next, promote the DEV1 version, overlaying the version at QA1. The version at DEV1 now has all the changes.
Right click on the TPROG09 at DEV1 and select Promote.
You can monitor the progress by clicking the refresh button.
You should see the following message. Since you have incorporated the QA1 changes into the DEV1 version of TPROG09 it is OK for you to overlay the version of TPROG09 in the QA1 level.
Click Yes.
The DEV1 version has replaced the version in QA1. The old QA1 version has been moved to the QA1 warehouse. It is still available if needed.
Select TPROG09 in QA1 and right-click on it, mouse over View, then click Component Versions.
This will bring up all the active versions of TPROG09.
Click the Show Inactive Versions button.
This also shows any versions that have been moved to the warehouse and are currently inactive.
This view shows when we promoted the DEV1 version that was based on Version 3 of TPROG09 to QA1. This caused Version 2 of TPROG09 to be moved into the warehouse making it inactive. The DEV1 version became Version 4 on the promotion and is now the active version at QA1. Components that are moved to the warehouse become inactive but are still available for use if needed. The fallback command can be used at the intermediate levels like QA1 to recover the warehoused versions. Your screen may look slightly different.
Close the Component Versions window.
Right-click on TPROG09 in STG and select Promote to promote TPROG09 to PRD.
There will be a warning to alert us that the promote of our current version is not based on the latest version in PRD. This is because we have reworked the production fix changes in a prior production version that already had code changes for a planned change.
You can select Yes here!
Approvals are required to promote to Production. Click once on TPROG09 and in STG right-click box and select Approve.
This will complete the promotion to PRD.
TPROG09 has been successfully promoted to PRD.
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.
To Close your Assignment, click on the Containers View and right-click on your Assignment and click "Close."
A Close confirmation panel is presented.
Click OK to complete the Close.
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 Emergency path to Production. As a part of this exercise, you have been able to use DevX Workbench and Code Pipeline to execute a workflow:
- Created an Assignment
- Made Emergency code changes to fix a Production problem
- Used the compare and merge tool to retrofit code changes
- Generated/compiled
- Promoted and overlaid QA1 and observed the messaging
- Promoted to Production
Congratulations! This completes the Code Pipeline tutorial for BMC Test Drive.