The objects of this blog run only under IBM’s ISPF for Endevor and Quick-Edit. So, they do not apply to Endevor activity outside of ISPF, such as actions under zowe, VS Code, or Eclipse. For more information about ISPF, see What is ISPF?
According to Cornell University, the first television broadcast occurred in 1927. In the year 1908, Henry Ford made the first mass-produced automobile. IBM's ISPF (Interactive System Productivity Facility) was first introduced in 1974, making it much younger than other things that have surpassed the test of time.
This document presents these ISPF-dependent features:
-
Package Builder - a fast method for creating, Casting, and executing packages and enforcing your site standards for package names
-
Parallel Development Alert (PDA) - automated messaging that alerts developers when they enter into parallel development.
-
RETRO - an action a developer can use with a PDA message to merge another version of code for one element into their own
Because of the dependency on ISPF, these tools are prepared separately in the ISPF-tools-for-Quick-Edit-and-Endevor section of Broadcom’s GitHub repository.
Package Builder
Anyone who has ever created and Cast an Endevor package is likely to recognize these screen images:
The Package Builder offers an alternative to using these built-in Endevor and Quick-Edit panels to create, Cast, and optionally Execute a package in 2 screens, and provides these features:
-
You can accomplish the same results in a fraction of the time. The Creation, Cast, and optional Execution of a package can be completed from either Endevor or Quick-Edit)
-
The package name is automatically determined, using your pre-configured method for naming packages
-
The entering of redundant information is eliminated - reducing errors. The CCID and Comment values you already provided serve as the CCID and Comment and package Description values
-
Submits a package Cast in batch - avoiding the session-choking experience of foreground Casting.
-
Can piggyback a batch Execution of the package for packages that do not need approval.
-
It begins with the list of elements for which you are already working. Why throw away a perfect list of elements only to rebuild it again with the package panels?
-
Helps to establish package naming standards. After a look at the elements listed, it determines a new package name based on your pre-defined instructions.
-
Package prefixes can begin with values established at your site for standard names. For example, System, C1CCID, Environment or Stage, where the values come from the elements listed.
-
Leverages CCID and Comment fields from the previous ISPF panels into the CCID, Comment, and Description fields for the package and its SCL.
-
Makes intelligent decisions on the selection of PROMOTION package values
-
Can force packages to be “Sharable” and “Backout Enabled”
-
Easy to learn. Easy to use. Requires only an introduction in education materials for new Endevor users.
-
Adaptable - No dependencies on Endevor Release level.
-
REXX and ISPF panel-based. Easily tailorable for your site.
Package Builder starts from an element list presented by either Endevor or Quick-Edit.
Elements that are to be packaged together are typically found in the same development location - whether that be the same Environment and stage or a Subsystem (Sandbox). The elements listed above by Quick-Edit are within the same sandbox ACTP0003, where they have been modified and tested. The “TSO PACKAGE” command initiates the Package Builder.
All the elements listed are initially assumed to be placed into a package - whether the number of elements listed is 11, 111, or 11 thousand. The first Package Builder screen appears.
The panel manages your options for the package to be created. The Package Builder:
-
Shows a package name determined by standardizations (coded in the REXX) and classification information for the elements listed
-
Assumes a MOVE action is to be used for all selected Elements. However, you can change the Action value on the panel to do GENERATE or DELETE actions instead
-
Uses the CCID and COMMENT values from the previous screen for actions placed into the package and for the package Description.
-
Shows the number of elements to be packaged in the upper right-hand corner. However, if you want to select elements from those listed, a “Pick List” feature presents the listed elements again, allowing you to select the ones you want packaged.
-
Supports an Append option to allow the user to append to an existing package
-
Supports options for Concurrent Action processing, the Execution window, and notes
-
Supports your choices for Promotion Package, Cast Validation, and Execute (when no Approvals are required). Default values for these options can be established in the REXX code.
When you press Enter, the package is created, and the second Package Builder panel is displayed.
The second panel is Endevor’s standard Job confirmation panel. At this point, the package is created. The name of the package is shown in the message field at the top right corner of the panel.
Minimally the submitted job will CAST the package. Depending on values entered on the first panel, the job may also Execute the package if the CAST is successful, and if no Approvals are required.
In 2 panels, you have quickly accomplished what the many panels would have done.
Parallel Development Alert (PDA)
One of the challenges when supporting parallel development is developer awareness.
Developers need to know when other work is underway that might impact the work they are doing. When a developer brings an element down to a development location of Endevor, It is imperative to:
-
Avoid causing regression for another development effort on the same element
-
Merge my changes into the other version, or merge changes from the other version into mine.
-
Alert other developers of the changes I am making.
The Parallel Development Alert (PDA) is a tool that can be automatically invoked by Quick-Edit to alert a developer that their work on an element is in parallel with other work. PDA is invoked on an “Edit” request to Quick-Edit.
For each non-production location where the element is found, a text string is prepared by the PDA as NOTE or MSG lines and presented back to the developer.
This example shows the element in 3 non-production locations. Since one of the locations has another person’s userid (SPEEDY) on the element, it is highlighted by the use of a MSG line.
NOTE and MSG lines are temporarily used by ISPF for display only. If the element is “SAVED”, or if you enter “RESET”, NOTE and MSG lines disappear.
The purpose of the PDA notification is to alert developers about parallel development so that we can take the appropriate actions to avoid regression. When SPEEDY edits his version of the element, the two lines with my userid will be highlighted to him. SPEEDY and I will decide which of us must merge code, based on who is going to production first. The code merge itself can be done in several different ways, for example:
-
Parallel Development Manager - parallel-development-option
-
IBM’s SUPERC
-
IEH “eyeball” - a manual merge from visual observations
-
RETRO - the screen-assisted execution of PDM described in the next section
RETRO
RETRO is a merge tool, that executes the ENDEVOR’s pdm tool to merge parallel changes. RETRO is invoked while examining messages provided by the Parallel Development Alert.
You can Enter “RETRO” on the command line, and before pressing Enter move the cursor to a line that lists the element you want. Anywhere on a line is sufficient to select the listed element for a code merge.
Retro identifies inputs for a PDM execution and displays them on this panel.
You may press Enter to proceed, or End or PF3 to exit the code merge.
RETRO may determine that your version already contains the changes from the other version. This is what you will see.
On the other hand, RETRO will inform you that a code merge is recommended. RETRO called PDM once to create a Work-in-Process file. You are allowed to view the WIP file.
You are also allowed to view a temporarily merged file produced by a PDM execution by RETRO.
Finally, you are allowed to indicate your choice to update your version with the results of the PDM merge.
Again, you may opt out of the code merge, or continue.
If you continue with the code merge, RETRO updates your element.
A new change level is created, reflecting changes from the other version that have been merged into yours.
Summary
These three tools depend on ISPF and can be found on Endevor GitHub. Like the other items on GitHub, they are offered as “Open Source”, in the sense that anyone can use them. However, modifying them is restricted to Broadcom personnel, and due to their discretionary inclusion and required local tailoring they are offered outside of the Endevor product.
-
Package Builder - a fast method for creating, Casting, and executing packages and enforcing your site standards for package names
-
Parallel Development Alert (PDA) - automated messaging that alerts developers when they enter into parallel development.
-
RETRO - an action a developer can use with a PDA message to merge another version of code for one element into their own
If you would like to see more on these examples or want to chat about other uses of ISPF with Endevor, please let me know at joseph.walther@broadcom.com.