Release Containers with Generate Impacts
Contents
- Getting Started with SCM – BMC AMI DevX Code Pipeline
- Release Management and Generate Impacts
- Assignment #1
- Assignment #2
- Assignment #3
- Assignment #4
Getting Started with SCM – BMC AMI DevX Code Pipeline
The goal of this Test Drive section is to provide you with experience using Agile Source Code Management, Deployment, and Release Automation on a mainframe platform. BMC AMI DevX Code Pipeline enables developers to quickly and safely build, test and deploy mainframe code.
This Test Drive will take you through the following activities:
- Creating Containers, both Assignments and a Release Container
- Checking out copy books
- Using a special LINK type
- Adding to Release Container
- Generating Impacts 2 different ways
- Promoting to Production
- Closing Containers
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 in to 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.
Release Management and Generate Impacts
Four developers are in 4 different assignments and are making changes for the Q4 Corporate Release. They check out various tasks into their individual assignments, and share them with the Release Container, they will use Generate Impacts to gather the impacted components and then the Release Coordinator will promote the entire Release to PRD.
- Change the Stream to your assigned stream value CWEZ.
- Change the Application to your assigned application value (Txxx, where xxx is your unique number).
- Note: The SubAppl field will be automatically populated with Application
- Set the Level to "PRD" and ensure the Level option is set to "All found in level and above".
- Filter the view even further by setting the Type to COPY, this will allow you to focus only on the Copy book components available in your stream | application at the PRD level. Click Apply (circled).
The Repository View lists the COPY Components for your application.
Assignment #1
Let's create a Release Container named TDRELnn, where nn is your assigned number.
Make sure you are on the containers view by clicking on the Containers tab. Click on the New Release button.
Fill in the Release ID, Description, Application, and Stream. The description is Corporate Q4 Release Test Drive XX. Click OK.
Your Release Container has been created. Click OK.
The Release Container should now appear in the Containers View. Note the Type is Release as opposed to Assignment. When you create your assignments, you should be able to use this Release name and also put the tasks into the Release container at the same time you add them to the Assignment container.
Now we want to change 2 copybooks and then find out what programs are using the copybooks, add these to the assignment, recompile, and promote them to Production with the copybooks.
First make sure your list of copy books is showing.
Highlight TCPYA04 and TCPYB04 in the list below (use CTRL Click to select TCPYB04).
Right-click the highlighted selection, then click on Add to Assignment with Check Out.
From the Add Task to Assignment dialog box, select Path DEV2 and the new Release you just created.
Click on New to the right of the Assignment field.
This will take you to the Add New Assignment dialog to create the assignment for your 2 Copybooks.
For Stream, use CWEZ. For Application and Assignment prefix, use your assigned values (see "Substitute your values in the screenshots").
Make sure the Default Path of DEV2 is selected and provide a description for your Assignment.
Click on the down arrow next to Release and select the Release you created - TDRELnn. Click OK.
A message will be displayed providing you with your new Assignment name. Make note of it for the Assignment #1.
Click OK.
Click OK to add the tasks to your assignment.
Two tasks were checked out to your Assignment.
Click OK.
You should end up in the Assignment View. If not,
Highlight Assignment #1 in the Container View and Double click to open. The Assignment view will appear.
Select both copy books and Right Click, select View, Generate Impacts.
We need to do this to make sure that all the programs that use these copy books have the new version of the copy books before they are promoted to Production. By selecting Generate Impacts, we will get the list of programs and the option to recompile them in the Assignment Container so that we pick up the new copy books.
The Generate Impacts view opens and you will see TPROG04 and TSUBR04. These 2 programs use the TCPYA04 and TCPYB04 copybooks, which means that they are impacted by the copybook changes.
Highlight at least one of the programs and select the Generate Impacts button.
The message below will appear asking if you want to process the remaining list of impacts in the Generate Impacts view. This will pick up the other program.
Click Yes.
You want to add these programs to your assignment and generate them. They will be recompiled using the Production source. No need to check out the source since nothing has changed in it. We are only regenerating to pick up the new copybooks.
The Enter Values to Add and/ or Generate window appears.
Select Generate and Click OK.
The Generate Impacts process is complete. The Generate is then attempted.
Click OK.
Click OK.
Return to Assignment #1 by clicking on the Tasks View.
You will see that the Program Tasks have been added to your Assignment and Generated. The Action shows as Compile only, which means that the program was generated using the next highest source found in the path.
Click on the Release View tab and you will see your Release Container and its tasks.
These are the same tasks that are in Assignment #1. This is because you selected TDRELnn for your release when creating Assignment #1 and this related the 2 containers together.
Return to Assignment #1 by clicking on the Tasks view.
To promote your tasks to the next level, select all tasks, right click and select Promote from within your assignment.
Your Code Pipeline Administrator has configured this promotion path to also allow for the deployment of the tasks to any or all of three different environments for QA testing. This is called Selective Deployment, and is covered in detail in another BMC Test Drive script.
You will not be deploying your tasks to any testing environments at this time.
Select the Do Not Deploy button and click OK.
You will see the promote completed message; four tasks have been promoted to QA2.
You may have to refresh your screen view to see the new information. Click on the refresh button 
.
Assignment #2
In this section we will show how Code Pipeline supports standard mainframe types like COB, JCL, etc., as well as 2 special types.
In Code Pipeline, the LKED type is used to supply the link-edit control cards to a generate process. The LKED task must have the same name as the program, and it must exist at the same level or a higher level (including Prod) to be useable by a generate of the program.
The LINK type also contains link-edit control cards, but it is not associated with a program. It is a stand-alone type which is generated. The control cards will name the load module. The generate process will not do any pre-compile or compile steps. The generate JCL will contain a LKED step only. This step will use the LINK type's control cards to build the load module and name it and the resulting load module will be a generate part associated with the LINK task, just like a load module is a part to a COB type.
In the Component Filter of the Repository Explorer view, enter LKED in the Type field and click Apply.
Let's browse this member.
Right-click and select Browse.
This member (MAINCOB) is used when linking program MAINCOB as part of the generate process. It includes 4 subroutines and, if you notice, it changes the name of the load module from MAINCOB to MAINLOAD. The LKED MAINCOB module exists in PRD and will be found during the generate as long as it is in the same path that you are currently working in.
Click the X to close MAINCOB.
In the Component Filter of the Repository Explorer view, enter LINK in the Type field and click Apply.
This brings up the SUPRLINK component.
Let's browse this member.
Right-click and select Browse.
This SUPRLINK component provides the include cards for building the load module and well as the load entry point and the name of the load module.
Click on the X to close the task.
Change the type to COPY and select TCPYAA and TCPYBA. Click on TCPYAA and hold the control button and click on TCPYBA to select both copy books.
Change Level to DEV1 and Level option to All found in level and above if you like.
Now right-click and add these two tasks to a new assignment with check out.
This will be Assignment 2.
Click New to create Assignment #2.
The Default Release is shown. You may either select it here or leave it as Default or select it on the next screen.
Your Path should be DEV2.
Make sure to select the correct Release Container (TDRELnn) and Path (DEV2) when creating this assignment.
Click OK.
You will see a message saying Assignment was successfully created (screenshot not shown).
Make sure the DEV2 path and the correct Release container are selected. Click OK.
You will see a message saying that 2 tasks were checked out to the assignment.
Click on the Container view. Right-click on Assignment #2 and select View Generate Impacts for the Assignment.
This will bring up a list of all programs that are calling these 2 copy books.
The Generate View will open. Here we see MAINCOB and SUPRLINK are using the 2 copybooks TCPYAA and TCPYBA.
Click on at least one of the tasks. Click on the Generate Impacts button.
Code Pipeline will ask you if you want to process the remaining list.
Click Yes to continue.
Check the generate box and click OK.
This will add your programs to your assignment to regenerate them.
You should receive messages like these.
Click OK.
Click OK.
You will see a list of your 2 source components (program and link control cards) and 2 copybooks. The programs have been generated with an Action of Compile only. This means they were compiled using the Production source in this case and this source was not checked out. The source had no changes and the compile was to pick up the new copybooks so no need to check out the source.
Select all the tasks and right click and select Promote.
Once again, you will not be deploying your tasks to any testing environments, so select the Do Not Deploy button and click OK (screenshot not shown).
This will promote everything to the QA2 level. Once the promotion is complete you will get a promotion completed message (screenshot not shown).
Return to the Release View. You will see the contents of both assignments in the view.
Assignment #3
Let's continue to Developer #3. We need to create an Assignment and Add with checkout the copybook TCPYSBA.
In the Repository Explorer view, highlight TCPYSBA, right-click and choose Add to Assignment with Check Out.
Click New to the right of Assignment on the Add Task to Assignment screen (screenshot not shown).
Type a description and make sure your Release and Default Path are selected and Click OK.
You should get a message saying your assignment was successfully created (screenshot not shown).
Make sure all your information is correct and click OK.
Task was checked out to assignment.
Click OK.
Click on the Assignment View. Right click on TCPYSBA and View Generate Impacts.
This will take you to the Generate Impacts (GI) View.
Select the GI button.
A message (not shown) will ask you if you want to process the remaining list of impacts. Click Yes.
Check the Generate box and click OK.
This will add and generate all these components into your Assignment.
The following message should appear.
Click OK.
A generate attempted message should also appear.
Click OK to continue.
Return to the Tasks View. You should see the programs have been generated with compile only.
We now need to promote these to the next level.
You can either select all the tasks or select the entire container. Since we are in the Tasks View, select all the Tasks, then right-click and select Promote.
You should receive the following warning message. We have already promoted MAINCOB and SUPRLINK to QA2 in another Assignment, but our warning is a good overlay – we are based on version 1, so we can replace version 1.
Click Yes on this message (and a similar one for SUPRLINK, screenshot not shown) to continue, or click Yes to All.
Once again, you will not be deploying your tasks to any testing environments, so select the Do Not Deploy button and click OK (screenshot not shown).
This will move the MAINCOB and SUPRLINK versions into the warehouse at the QA2 level. Our new versions will become the live versions at the QA2 level.
Once the promotion is complete you will get a promotion completed message (screenshot not shown). At this point you can also look inside the Release Container and see all the tasks from the 3 Assignment containers if you wish.
Assignment #4
Let's move on to the final Assignment container. Next, we will be looking for all the programs that call the program DATERTN, and then recompiling them to make sure they pick up the new version of DATERTN. First we check out DATERTN, and then we will perform a Generate Impacts to locate all of the calling programs.
Change your Component Type filter to COB and click Apply (screenshot not shown). This brings up the list of Cobol programs. Select DATERTN, right-click, and click Add to Assignment with Check Out.
Click on New (next to Assignment – screenshot not shown) to create a new assignment container.
Make sure to select your Release and the correct Path. Add a description of Assignment #4 and click OK.
You will get an Assignment Created message (screenshot not shown). Click OK.
Click OK on the Add Task to Assignment screen and then click OK on the Task was checked out message (screenshots not shown).
Click on the Tasks View and then double-click on DATERTN to open it up for editing (screenshots not shown). When you see this message, click Yes to download the copybook information.
Let's make a change but don't break the program.
Put your cursor at the end of a comment line and hit Enter. This will add a new line for you to type on.
Tab over and put an asterisk in column 7, then add a comment. Click on the X to save the change.
Click Yes.
We must now generate DATERTN.
Right-click on DATERTN and select Generate. If the operation is not successful, fix the error and generate again. When the generate succeeds, then continue.
Now we need to Generate Impacts; this will bring up a list of all the tasks that call DATERTN.
Right-click on DATERTN and select View, Generate Impacts.
This will take you to the Generate Impacts View. The view shows the programs that call DATERTN.
Click on the Generate Impacts button. You could click on Generate Impacts from the container view as an alternative. Either way, the generate impacts will be gathered. Click Yes on the Process the Remaining Impacts message (screenshot not shown).
Make sure the Generate check box is checked.
This will add the programs to your container and generate them using the Production source in this case. Click OK.
You should see the following 2 messages.
Click OK on both to continue.
Return to the Tasks view and make sure all the programs have completed generating (screenshot not shown). Then return to the Containers view. Select our current Assignment Container, right-click, and select Promote.
Once again, you will not be deploying your tasks to any testing environments, so select the Do Not Deploy button and click OK (screenshot not shown).
Once the promotion is complete you will get a promotion completed message (screenshot not shown).
Let's view our Release container.
Click on the Release hyperlink in the Container column and you should see the Tasks from all 4 Assignments. Double-click on the Release Tab to maximize that tab (shown). To see the assignments to which the tasks belong, right-click on any column header and select Assignment. You can select any of the other columns that you want to see. Every task should be at the QA2 level.
You now see which assignments are part of this Release container.
Double-click the Release Tab again to restore it to normal size.
Click on the Containers view. Now you will Promote the entire Release Container to the next level - STG. From the Containers View, right-click on your Release Container and select Promote.
Once the promotion is complete you will get a promotion completed message (screenshot not shown).
Click on the View Life Cycle button.
You should see everything is in STG except for the 2 programs that were overlaid and moved to the warehouse. These are the 2 tasks in your Assignment and Release which show as inactive at the QA2 level. The promotion to Production can be done individually and thus separately in each of the 4 Assignments or all together from the Release. In this case you want all these tasks to move together so you will choose the promotion from the Release Container.
Make sure you are in the Containers View; right-click on the Release container again and select Promote to perform the promotion to PRD.
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.
Right-click in the STG level box and select Approve.
This will approve the Release, and everything will promote to Production, as shown in the Life Cycle view below.
Double-click on the release and you will see that all the tasks have been promoted to PRD (screenshot not shown).
Now we will close the 4 Assignments and then the Release Container. What follows is the order in which they must be processed.
Make sure you are in the Containers View, then right-click on Assignment #1 and select Close.
Click OK to confirm 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 was to create 4 assignment containers, check out copy books into them, create a Release container, and perform Generate Impacts to pull in and recompile the associated programs. As a part of this exercise, you have been able to use BMC AMI DevX Workbench for Eclipse and Code Pipeline to execute a workflow:
- Created Containers, both Assignments and a Release Container
- Checked out copy books, and programs with a Release Container selected
- Used the special LKED and LINK types
- Generated Impacts 2 different ways – by task or by Assignment Container
- Handled overlay warnings due to concurrent development
- Promoted to Production from a Release Container instead of individual Assignment Containers
- Closed Assignment Container
- Closed Release Container
Congratulations! This completes the Code Pipeline tutorial for BMC Test Drive.