C – Checkout/Copy

This section provides information about Checkout/Copy. 

C – Definition

Type C beside a module to invoke the ISPW checkout/copy routine. Note modules are never actually “checked out” of ISPW. The Checkout routine simply makes a copy of a module version to base further changes on.

Purpose

The C (Checkout) operation is used to make a copy of a module version to apply updates. Modules are first Added to a Task List, then C(hecked out) for update, then S(elected) to Edit.

Checkout for a New Component

When a component is new, and there are no other versions at Production or elsewhere in the change cycle, there is no source to copy. ISPW creates a blank/empty component.

Checkout Conflicts

Checkout is one of the more complex operations. If another version of the same name is anywhere in the change cycle, ISPW prompts with a list of the component versions to choose from. In many cases, the version in Production may not be the latest version of the module, so users should look at the version list carefully, before picking the version to base changes on.

Checkout Conflict Example

In the example shown in the following figure, other versions are already in the change cycle at the STG1 and QA levels. Depending on the Checkout Level, ISPW will suggest the best version (the one immediately above it in the Path) by showing an S beside it. For example, for DEV1, the version at STG1 is the best candidate. If it is to be based on a different version, the S can be changed to another version.

Checkout Conflicts

From this list, the user can:

• Browse the modules at any level with the B command
• Compare the versions at various levels using the CM command to see what has been changed.

Historical Versions

To check out from an Inactive version, use special Action Code H on the Task Add.

Historical Versions

Conflicts Can be Managed

Because the developer doing the Checkout can readily see the other version ahead in the change cycle, conflicts are visible and can be more easily managed.

Component Versions Can Exist at Every Level

Module versions may be Checked out multiple times, in as many update areas as are available. For example, if an Application has defined three change cycle paths—Development, Maintenance, and Fix—the same module could be checked out three times, in all three change paths, with changes for different reasons.

Check Versions Flag

In the examples shown in the following Check Versions Flag and Check Versions Message figures, a new version of the program is checked out to FIX, based on the version in Production.

Check Versions Flag

To warn users working with the other versions at STG1 and QA, the Check Versions message appears in the Status field beside those versions. It creates greater visibility and is an early notification of a potential version conflict requiring versions to be merged.

Check Versions Message

COBOL Program TSUBR03 is Now in FIX

There are now four versions of COBOL program TSUBR03 in the change cycle: one at Production, one at the QA level, one at STG1 level, and one at the FIX level. The first two versions exist in other assignments, whereas the latter two are in the assignment shown in the above example.

V List Shows Module at FIX

Use the V (Versions command) beside COBOL program TSUBR03 to see the version list again. For more information, see V – Version List.

The Component Version list now shows the version at the FIX level that has just been checked out.

V List

iVer, bVer, and rVer

As shown in the preceding figure (Component Version list), ISPW warns when there are possible conflicts—and even displays the Version number that changes were based on—to help resynchronize the versions.

• iVer is the ISPW internal version number. This number is 0 while the module is still at the lowest (update) level in the change cycle. This version at FIX will become version 14 when promoted to the next level.
• bVer is the base version this specific component version is based on. Note the version in FIX (bVer = 10) was copied from PRD (iVer = 10).
• rVer is the replace version this specific version may replace if it must be promoted over the top of another version.

Modules Already at Target Level

Occasionally, a module that must be checked out for update is already in that physical file, and therefore is in the way of the Checkout operation. In this situation, an example error message is displayed as shown in the following figure.

Checkout Error Message

At this point, there are two choices as to how to proceed:

• Check the module out to an alternate target library (that is, another leg), or
• RE(name) the module in the target level library to an alternate name to set it aside temporarily.

Email Interface

When checking out a new version while others already exist somewhere below Production in the change cycle, ISPW can send an email or other type of message to alert other users that a new version has been created. The userIDs of the owners of the other versions are already filled in on the Email Interface screen. Type S beside the Email/SMTP input field and press Enter, then press Enter again on the Confirmation screen.

Email Interface