source code management, deployment, and release automation ... drive... · the mainframe software...

1

Compuware Test Drive

Source Code Management, Deployment, and release Automation - Change 2 Copy books with impact Revised: 7/20/2020

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. Compuware ISPW enables developers to quickly and safely build, test and deploy mainframe code.

The Mainframe Software Partner for the Next 50 Years

2

Contents

Getting Started with SCM - ISPW ................................................................................................. 3

Code Changes.............................................................................................................................. 8

ISPW Impact Analysis ................................................................................................................ 19

Generate (AKA Compile) ............................................................................................................ 30

Promotion ................................................................................................................................. 37

NEXT STEPS ............................................................................................................................... 51

https://compuware.sharepoint.com/sites/TestDriveScrum/Shared%20Documents/SCM/ISPW%20Part%204%20Test_Drive_ISPW%20Change%202%20Copy%20books%20with%20impact.docx#_Toc46159008







3

Getting Started with SCM - ISPW

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. Compuware ISPW enables developers to quickly and safely build, test and deploy 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

• Every action you must take is in orange

• 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

The Compuware Test Drive Experience requires that users complete the Building Your Environment exercise before starting any tutorial script.

Building Your Environment

If at any point during your experience, your host connection times out, you may need to log back in to the Test Drive host connection.

If you wish to do this script more than once, restart instructions are located at the end of the script.

http://resources.compuware.com/hubfs/Test%20Drive/Building_Environment_with_Host_and_JES_Explorers_TW_Test_Drive.pdf


4

To get started in the Topaz Workbench:

• Open the Host Explorer perspective

• Click on the arrow next to Hosts,

• Right-click on Test Drive and select Login

• Logon on with the user credentials that were provided to you for with the Test Drive and click OK

• Select ISPW from the Compuware menu


5

During this Test Drive you will encounter terms specific to ISPW. Here is a glossary for your convenience.

ISPW Terminology

Term Description

Application Business Area

Stream Development Life-Cycle used by one or more Applications

Life-Cycle Transitional Code States (DEV, QA, PROD) in the Development Life-Cycle

Level Instance of a Code State (DEV, QA, PROD)

Component SCM managed object such as a Cobol source member.

Component Version An immutable version of a Component.

Task An instance of a unit of work. For example, a change to a Component.

Part A generated object such as a load module, or a Listing or a DBRM

Warehouse Storage location for inactive historical or overlaid Component Versions (source and parts).

Assignment Container A package of one or more, usually related, Tasks. A development container that is used to organize and manage development work.


6

Terminology, continued

Term Description

Release Container A package of Tasks from one or more Assignment Containers. An operational container that is used to organize and manage operational releases.

Set Container A package of Tasks at an instance in time. A special ISPW container that is used internally to organize and manage work requests.

Add Task Make a statement of intent, often because of some impact analysis.

Checkout Task Copy source to development area

Edit Task Make a change to the source in the development area.

Generate Task Execute Compile and Link processes.

Promote Task Move Task forward to the next Level in the Life-Cycle.

Regress Task Move Task backwards to the previous Level in the Life-Cycle.

Delete Task Remove a Task from the development area

Fallback Task Restore previous version of Task.

Deploy Task Implement Task in one or more Run Time environments.


7

Substitute your values in the screenshots

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.

While taking the test drive, you must substitute your assigned values!

Variable Your Assigned Values

Application Txxx*

Assignment Prefix Txxx*

* For the value of xxx, substitute the last three digits of your test drive username.


8

Code Changes

Your development task in this Test Drive is to change 2 COBOL copybooks and promote them and any other impacted components through the application life cycle to production.

First, you will find and collect the two copybooks into an ISPW assignment from which you can perform all this work.

1. Change the Stream to CWEZ 2. Change the Application to your assigned application value (Txxx, where xxx is your

unique number) 3. 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 levels above PRD.

4. Filter the view even further by setting the Type to copy, this will allow you to focus only on the Cobol program components available in your stream | application at the PRD level. Click Apply (circled)


9

The ISPW Repository View lists all the components of type COPY for your application.

Right-Click on “TCPYA01 at level PRD” and click Add to Assignment with Checkout.


10

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.

Note: DEV1 is one of 4 paths defined to this application which the components can take to production. A picture of the life-cycle will be provided further along the test drive. Type a description and Click OK.


11

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 ISPW 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. Click OK.


12

A message will be displayed to inform you that the task has been added to your Assignment. Click OK.

Right-click on TCPYB01 at level PRD. and click Add to Assignment with Checkout.


13

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. Click OK.


14

The ISPW Tasks view 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.


15

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).


16

A picture of the Life Cycle is presented. You will notice the levels containing versions of the highlighted COPY task 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 thru 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 ISPW. Any number of paths can be defined with a minimum of three Levels.


17

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 Topaz 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.


18

Note the Name, Operation, User ID, and Date/Time fields have been updated to reflect the change in the task status. Now make a similar change to TCPYB01 and save it.


19

ISPW 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.


20

The ISPW 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 ISPW Impacts view, click on the filter button.

Type 5 in the “Level of indirection…” field, then click OK


21

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).

• ISPW will display one level downward with a value of -1. Downward means these -1 components are called/used by the changed component.

• ISPW 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.


22

In the example below:

• 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 TJOB01 is at “Level of Indirection” value of 2 which means it calls/uses the component above it at value 1.

• So, job TJOB01 calls/uses COB TPROG01 which in turn calls/uses COPY TCPYA01.


23

To add the impacted components (TPROG01 and TJOB01) to your assignment, select both (click on the first one and then hold down your Ctrl key and click on the second one), then right-click on the grouping and click Add to Assignment with Check Out.


24

The add task to assignment dialog will appear. Simply click OK to add the first task.

A message is presented to indicate that the first task is checked out. Click OK. A second Add Task to Assignment dialog is presented. Click OK. A message is presented to indicate that the second task is checked out. Click OK. (Screen shots not shown)


25

Close the ISPW Impacts view to see the ISPW Tasks view. You now have 4 tasks in your assignment. The original 2 COPY tasks are in the assignment (and have been edited) and now there are 2 new tasks – a COB type (COBOL program) and a JOB type (JCL). The 2 new tasks also are at DEV1 and have been checked out but nothing else has been done them.


26

Right click on TCPYB01, mouse over View then click Impacts.


27

Expand all levels as shown below. The ISPW 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.

• Cobol program TPROG01 is at “Level of Indirection” value of 1 which means it calls/uses COPY TCPYB01 directly.

• JOB TJOB01 is at “Level of Indirection” value of 2 which means it calls/uses the component above it at value 1, being TPROG01.

• So, Job TJOB01 calls/uses 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 TJOB01 is at “Level of Indirection” value of 3 under TPROG01 so TJOB01 calls/uses TPROG01.

• Thus, TJOB01 calls/uses COB TPROG01 which calls/uses COB TSUBR01 which calls/uses COPY TCPYB01.


28

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.

Note: ISPW also provides a Generate Impacts option that allows mass adding and generating of tasks to assignments based on the list of components in assignments or releases. So, for larger volumes of changes, it is not necessary to go through the impacts for each individual task.)


29

The Add Task dialog is displayed. Click OK to add this component as a task to your assignment with DEV1 as the chosen path.

A confirmation prompt is displayed when the task has been added. Click OK. (Screenshot not shown).

TSUBR01 has been added to your assignment and the level is DEV1.

Close the ISPW Impacts view. (Screenshot not shown).


30

Generate (AKA Compile) As indicated in the Status column, it needs to be compiled/generated. To do this, 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.


31

You can browse the listing from the generate at any time. Right-click on the task and click View Generate Listing.


32

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.


33

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.


34

As part of the generate, ISPW 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.


35

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. Close the ISPW Parts view.


36

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.

If you want to see the listing, Right-click on the program and click either View Generate Listing or View Generate Job Output (screen shots not shown).


37

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.


38

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 ISPW that are used to conduct operations such as promotion and deploy. They are temporary and created by ISPW 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 ISPW 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).


39

As the tasks in the set are being processed you can monitor the progress by clicking the refresh button (circled)


40

In the screenshot below, you can see the promotion has progressed – the 5 tasks have been promoted to QA1 (see the Level value and the Operation 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. ISPW’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.

When the confirmation dialog comes up that the 5 tasks have been promoted, click OK.


41

In the screenshot below a final refresh has been done showing that:

• The promotion has completed.

• All the tasks have successfully been promoted to QA1.

• All the generates have completed successfully.

Note the Operation column of the 2 programs shows Generate as the last operation. The set processor performed a promotion and then a generate as ISPW recognized it was required for COB types at the QA1 level based on the configuration of this application.


42

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.


43

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.


44

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.

Note: ISPW uses your installation’s security (RACF/Top-secret/ACF2) to manage process security (granular control of permissions by user and function). Process security defines who can perform which commands at which levels in the life cycle.

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.


45

The selected tasks are being placed in a set container for the promotion. The ISPW 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.

The application has been configured to require an approval for the promotion to PRD.

Normally, ISPW would be configured to prevent a user from approving their own change.

In the screenshot below, the Status Column 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:

• Topaz/ISPW

• TSO/ISPW

• Web browser

• Mobile browser For this Test Drive you will do the approval from Topaz/ISPW. Click OK.


46

Right-click on the STG box in the Life Cycle diagram.

Click Approve to approve the set promotion. ISPW will now start a set processor to perform the promotion of the tasks collected in the set to the PRD level.


47

Click the refresh button (as indicated in the screenshot).

You can see in the updated screen below that

• SET processing has completed

• The tasks are being processed for a promotion to the PRD level.


48

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 ISPW and will be demonstrated in a later Test Drive. The source and parts for all 5 tasks were moved to the PRD level life cycle libraries and the STG level libraries were cleaned up as appropriate.


49

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 ISPW Container List View. To Close the Assignment first close the ISPW Tasks View

To close your assignment, right-click on your assignment and click Close.


50

The Modify Assignment dialog is presented. Click OK to complete the close.

Closed assignments, sets and releases are never deleted from ISPW. 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 ISPW history and can be viewed at any time.


51

If you wish to repeat this script, start again from the beginning, except use TCPYA02 and TCPYB02 instead.

You are done – your job has been to change 2 COBOL copybooks. As a part of this exercise, you have been able to use Compuware ISPW within Topaz Workbench to execute a workflow:

• Created an Assignment

• Added and checked out the two copybooks.

• Changed them using SlickEdit.

• 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.

• Promoted 5 tasks from DEV1 to QA1 with generates of the programs performed by ISPW in the correct order.

• Promoted 5 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 ISPW tutorial for Compuware Test Drive.

NEXT STEPS

Click on the link below to return to the Compuware Test Drive main page and choose your next road trip!

COMPUWARE TEST DRIVE

https://compuware.com/test-drive/