Change 2 Copy books with impact and promotion
Contents
- Getting Started with SCM – BMC AMI DevX Code Pipeline
- Code Changes
- Code Pipeline Impact Analysis
- Generate (AKA Compile)
- Promotion
Getting Started with SCM – BMC AMI DevX Code Pipeline
The goal of this Test Drive is to use BMC AMI DevX Code Pipeline Impact Analysis to identify components impacted by a change to 2 copybooks and add them to your assignment. Use BMC AMI DevX Workbench for Eclipse to make changes and then generate, use promotion analysis, and promote to Production. Code Pipeline enables developers to quickly and safely build, and test their mainframe code.
This Test Drive will take you through the following activities:
- Code changes
- Impact analysis
- Compiling
- Promotion into test and production environments
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.
Code Changes
Your development task in this Test Drive is to change 2 copybooks using the DevX Workbench editor, then use Code Pipeline Impact Analysis to identify and collect the impacted components. You will then promote both the copybooks and impacted components through the Application Life-Cycle to production.
First, you will find and add the 2 copybooks 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 Application
- Set the Level to "PRD" and ensure the Level option is set to "Selected level only" or "All found in level and above." Either setting will return the same results since there is no level above PRD.
- Filter the view even further by setting the Type to copy, this will allow you to focus only on the Cobol copybook components available in your stream | application at the PRD level. Click Apply (just below the Type).
The Repository View lists all the components of type COPY for your application.
Right-Click on "COPY TCPYA01 PRD" and click Add to Assignment with Checkout.
In the Add Task dialog, click New to the right of Assignment (highlighted). This will allow you to create a new assignment container for your copybook.
The Stream is CWEZ, and the Application is your assigned application. These values came from the repository explorer. The Default path is DEV1.
The Owner is your assigned ID, and the Assignment prefix is the same as the Application.
Type a description and Click OK.
A message will be displayed providing you with your new Assignment name.
Click OK.
Your new Assignment has been created and is ready to have Tasks added to it. An Assignment Container is the only Container Type in Code Pipeline that Tasks can be added to. The Assignment Container is where a developer will spend much of their time.
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.
Click OK.
Right-click on COPY TCPYB01 PRD. and click Add to Assignment with Checkout.
Click OK.
A message will be displayed to inform you that the task has been added to your assignment. A new version of the source has been copied, in this case from the PRD level, to the DEV1 level dataset.
If it is not selected, click on the Tasks View. It will show the 2 tasks that were added.
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.
Note that the COPY tasks in the assignment are 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. The Life Cycle Diagram shows the path structure that was constructed for the application.
Click on one of the tasks, then click on the View Life Cycle button (circled).
A picture of the Life Cycle is presented. 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 each copybook the next step would be to make changes to one of them. To do this:
Either right-click on TCPYA01 and click Edit or simply double-click on it. The version's source will be presented in the DevX Workbench Cobol editor.
Change the source but ensure you do not "break" the copybook (perhaps change/add a comment).
Once you have made a change, close the edit view and click Yes to save the changes.
Note the Name, Operation, User ID, and Date/Time fields have been updated to reflect the change in the task status.
Code Pipeline Impact Analysis
Now that changes have been made to both copybooks it is time to find out what components are affected by these changes.
Right-click on TCPYA01, mouse over View and then click on Impacts.
The Impacts view is opened showing the components impacted by the change to the COPY TCPYA01 component. Information is provided showing the level at which these components exist in the current Path to production as well as the type of relationship – static or dynamic.
In the Impacts view, click on the filter button.
Type 5 in the "Level of indirection…" field, then click OK.
Expand the impacts level of indirection as indicated below.
Understanding the impacts:
- The list above shows the component for which the impact option was requested, as well as those components related to and thus potentially impacted by a change to this component.
- The "Level of Indirection" column contains numbers and indentations to indicate the relationships of the changed component to the other components listed. Coloring is also used to indicate the calling level.
- The value of 0 indicates the component for which this impacts list was built (the changed component).
- Code Pipeline will display one level downward with a value of -1. Downward means these -1 components are called/used by the changed component.
- Code Pipeline will also display up to 32 calling levels upward - that is, component "A" calls component "B" calls component "C" and so on, up to the call of the changed module.
- The positive 1 indicates components which directly call/use the changed component.
- The positive 2 indicates components which call/use the positive 1 above them.
In the example above:
- TCPYA01 is the changed module and it has a "Level of Indirection" value of 0.
- COBOL program TPROG01 is at "Level of Indirection" value of 1 which means it calls/uses COPY TCPYA01 directly.
- JOB SJOB01 and JOB TJOB01 are at "Level of Indirection" value of 2 which means that each calls/uses the component above it at value 1.
- So, jobs SJOB01 and TJOB01 call/use COB TPROG01 which in turn calls/uses COPY TCPYA01.
To add the impacted component TPROG01 to your assignment, select it, then right-click and click Add to Assignment with Check Out.
Note that since the JOB components, SJOB01 and TJOB01, are known to not require a change because of the copybook change, they do not need to be added to the assignment.
The add task to assignment dialog will appear.
A message is presented to indicate that the task is checked out.
Close the Impacts view to see the Tasks view.
You now have 3 tasks in your assignment. The original 2 COPY tasks are in the assignment (and have been edited) and now there is a new task with type COB (COBOL program). The new task is also at DEV1 and has been checked out but nothing else has been done.
Right click on TCPYB01, mouse over View then click Impacts.
Expand all levels as shown.
The Impacts view is opened showing the components impacted by the change to the COPY TCPYB01 component.
In the example above:
- TCPYB01 is the changed module and it has a "Level of Indirection" value of 0.
- COB TPROG01 is at "Level of Indirection" value of 1 which means it calls/uses COPY TCPYB01 directly.
- JOB SJOB01 and JOB TJOB01 are at "Level of Indirection" value of 2 which means they call/use the component above them at value 1, being TPROG01.
- So, SJOB01 and TJOB01 call/use COB TPROG01 which in turn calls/uses COPY TCPYB01.
- Also, TSUBR01 is at "Level of Indirection" 1 which means it also directly calls/uses COPY TCPYB01.
- COB TPROG01 is at "Level of Indirection" 2 under TSUBR01 which shows TSUBR01 is called/used by TPROG01.
- And then JOB SJOB01 and JOB TJOB01 are at "Level of Indirection" value of 3 under TPROG01 so SJOB01 and TJOB01 call/use TPROG01.
- Thus, SJOB01 and TJOB01 call/use COB TPROG01 which calls/uses COB TSUBR01 which calls/uses COPY TCPYB01.
Under the Level column, you can see that TSUBR01 only exists at the PRD level. Since the copybook changes have impacted this subroutine, we want to recompile this program and thus we must add it to the assignment as well.
To add the impacted program (TSUBR01) to your assignment, select it, right-click and click Add to Assignment with Check Out.
The Add Task dialog is displayed.
A confirmation prompt is displayed when the task has been added.
TSUBR01 has been added to your assignment and the level is DEV1.
Generate (AKA Compile)
Now it is time to compile/generate the Cobol subroutine, so we can do our testing.
Right-click on TSUBR01 and click Generate.
When the generate is done, the task will be updated with the date and time of the generate, the user who performed the generate, and the operation will reflect that a generate has occurred, as highlighted below.
You can browse the listing from the generate at any time.
Right-click on the task and click View Generate Listing.
The listing is displayed in an Editor window.
Scroll up and down, notice that everything is available that you normally see in a listing. Close the listing display when you are finished.
You can also view the output of the job that did the generate.
Right-click on the task and click View Generate Job Output.
Close the listing when you are done viewing it.
As part of the generate, Code Pipeline collects each of the parts created as part of the generate (load, listing, DBRM, etc.) and registers them against the source.
To view the generated parts, right-click on the task, mouse over View and then click Parts.
The generate of this subroutine created a Listing, an Object, and a DDIO member (part DMEM). The types of parts created can be unique by application and type of component as well as the values of the generate parms.
Before promoting your changes to the next level in the Life Cycle, you will want to perform Promotion Analysis against the tasks in your assignment. This ensures that all tasks are ready to be promoted and warns you of potential overlay situations at other levels.
Click on the Assignment view to select it, then click on the Promotion Analysis button (circled).
The Promotion Analysis has identified that you will still need to generate one of the tasks.
Now that the statically linked subroutine has been generated, the mainline which calls it needs to be generated.
To do this right-click on the TPROG01 task and click Generate.
The COBOL program will be generated, and your assignment task list will be updated to reflect the new status.
- The Operation will be Generate
- The User ID and Date/Time will be updated
- The message will be updated to reflect the successful completion of the generate
Now that the mainline COBOL program has been generated, you can perform Promotion Analysis against the tasks in your assignment again. This will ensure the readiness of all tasks to be promoted.
In the Assignment view, select all tasks in the assignment (click on the first one, then hold down your Shift key and click on the last one), then right-click on the grouping and click Promotion Analysis or use icon as shown.
The Promotion Analysis now indicates that all tasks are ready for promotion.
Close the Promotion Analysis view and return to the Assignment view.
Promotion
At this point you have:
- Edited 2 copybooks
- Determined the impacted modules and collected them all in your assignment container
- Generated the programs in the correct order
Now you are ready to promote your changes to the QA1 level.
Select all the tasks by clicking on the top task in your assignment then holding the shift key down, clicking on the bottom task. To promote all the tasks to the QA1 level, right-click on the tasks and click Promote.
This action will create a set container. Sets are a special category of containers within Code Pipeline 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 tasks are placed in a set container for the promotion. The Code Pipeline set processor will:
- Perform the promotions of all the source to QA1
- Cleanup the DEV1 level (source and parts if applicable)
- Perform generates, in order, of all the tasks in the set which require a generation
- Deploy to runtime environments (if required)
In the screenshot below, you can see the promotion has progressed – the 4 tasks have been promoted to QA1 (see the Level value in the task list as well as the highlighted level in the picture). The subroutine generate is started before the mainline generate. The mainline generate will wait until the subroutine generate has completed successfully. Code Pipeline's set processor performs generates of the tasks that are contained in one set in the correct order automatically. This helps ensure even inexperienced developers are productive and everyone stays within site standards.
The screenshot above shows that:
- The promotion has completed
- All the tasks have successfully been promoted to QA1
- All the generates have completed successfully
Note the Status column of the 2 programs shows Generate Successful. The set processor performed a promotion and then a generate as Code Pipeline recognized it was required for COB types at the QA1 level based on the configuration of this application.
Let us assume all the testing at the QA1 level has been successfully completed and you are ready to promote to the STG level.
Select all the tasks as before, right-click and click Promote.
In the screenshot below a final refresh has been done showing that:
- The promotion has completed
- All the tasks have successfully been promoted to STG
Assuming all the testing at the STG level has been successfully completed, you are now ready to promote the tasks to the PRD level.
Select all the tasks as before, right-click and click Promote.
The selected tasks are being placed in a set container for the promotion. The Code Pipeline set processor will:
- Perform the promotions of all the source and parts to the PRD level
- Cleanup 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.
While a developer defined to this application can perhaps request the promote operation when promoting to the STG1 and QA levels, perhaps a change coordinator role is responsible for requesting the promotion to PRD. One or more approvals can be put in place for each application/level promotion, including but not limited to application manager, QA manager, impact, DBA, job scheduling, peer, or VP roles.
The Approval can be performed from:
- DevX Workbench/Code Pipeline
- TSO/Code Pipeline
- Web browser
- Mobile browser
For this Test Drive you will do the approval from DevX Workbench/Code Pipeline.
Right-click on the STG box in the Life Cycle diagram.
Click Approve to approve the set promotion.
Code Pipeline will now start a set processor to perform the promotion of the tasks collected in the set to the PRD level.
Click the refresh button.
You can see in the updated screen above that:
- SET processing has completed
- The tasks are being processed for a promotion to the PRD level
Promotion to the PRD level has completed. The subroutine and the program executables have been implemented/deployed. This means in addition to being promoted they were also copied to other libraries. This is the Deploy function of Code Pipeline and will be demonstrated in a later Test Drive. The source and parts for all the tasks were moved to the PRD level life cycle libraries and the STG level libraries were cleaned up as appropriate.
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 Code Pipeline Container List View.
To Close the Assignment, click on the Containers View and right-click on your assignment and click Close.
The Modify Assignment dialog 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 2 COBOL copybooks, use Impact Analysis to collect impacted components, and promote 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
- Added and checked out the two copybooks
- Changed them using the DevX Workbench editor
- Ran an impact analysis to determine the components impacted by your change
- Added and checked out the impacted components
- Generated (compiled) the program components
- Viewed your generated output
- Viewed the listings from the generate
- Viewed the parts created as part of the generate
- Performed promotion analysis to ensure that all tasks were ready to be promoted
- Promoted all tasks from DEV1 to QA1 with generates of the programs performed by Code Pipeline in the correct order
- Promoted all tasks from QA1 to STG, then to PRD
- Approved your promotion to PRD
- Closed your assignment to complete the change cycle
Congratulations! This completes the Code Pipeline tutorial for BMC Test Drive.