Endevor User Guide

BARCLAYS BANK PLC RETAIL FINANCIAL SERVICES
RETAIL OPERATIONS MAINFRAME TOOLS SUPPORT
Endevor User Guide
Date Version Author
26 October 2012 1.0a (First Draft) Gary Haynes
Endevor User Guide
SUB-PROJECT DEVELOPMENT BUSINESS OWNER LAN FILE SOURCE
: N/A : N/A : N/A : k:\endevor information\user guide.doc
DOCUMENT CHANGE RECORD:
Date
Version
Updated by Gary Haynes
Change Details New Issue.
dd/mm/yy 1.0
Copyright Statement This document is confidential to Barclays Bank PLC who retain all title to the copyright. The document shall not be used by other than authorised Barclays employees nor shall it be used or disclosed outside of Barclays Bank PLC without the express written permission of the Director Retail Operations.
Page ii Barclays Bank PLC 1.0a (First Draft)
Endevor User Guide
DISTRIBUTION LIST: All Endevor users Barclays Bank
1.0a (First Draft)
Barclays Bank PLC
Page iii
Endevor User Guide
TABLE OF CONTENTS
1 INTRODUCTION ..................................................................................... 7
1.1 1.2 HOW TO USE THE GUIDE. ........................................................................ 7 WHERE TO GET HELP ................................................................................ 7
2 STANDARD LIFECYCLE .......................................................................9

2.1 2.2 2.3 ENVIRONMENTS ........................................................................................ 9 STAGES ......................................................................................................... 9 LIFECYCLE MAPPING ............................................................................. 10 2.3.1 2.3.2 2.3.3 STANDARD ENDEVOR LIFECYCLE ....................................... 10 EXTENDED ENDEVOR LIFECYCLE ........................................ 10 LIVE SYSTEMS AT BARCLAYS ............................................... 11
3 STORING CODE IN ENDEVOR ........................................................... 12

3.1 3.2 3.3 3.4 ENDEVOR CODE TYPES .......................................................................... 12 ENDEVOR SYSTEMS ................................................................................ 13 ENDEVOR SUBSYSTEMS ........................................................................ 13 IDENTIFYING ENDEVOR ELEMENTS .................................................. 14
4 MANAGING CODE IN ENDEVOR ...................................................... 15

4.1 4.2 4.3 4.4 COMMON ENDEVOR ACTIONS ............................................................. 15 CHANGE CONTROL IDENTIFIERS ........................................................ 17 FOOTPRINTS .............................................................................................. 17 ENDEVOR VERSIONING ......................................................................... 18
4.4.1 Source code out of sync ................................................................. 19 4.4.2 Source code requires a Jump .......................................................... 20 4.5 OTHER ENDEVOR ACTIONS .................................................................. 20
5 ENDEVOR PROCESSOR GROUPS...................................................... 21 6 ENDEVOR LIBRARIES ......................................................................... 23

6.1 6.2 6.3 INPUT LIBRARIES..................................................................................... 23 OUTPUT LIBRARIES................................................................................. 24 MASTER CONTROL FILES ...................................................................... 24
7 ENDEVOR SECURITY .......................................................................... 25

Page iv Barclays Bank PLC 1.0a (First Draft)
Endevor User Guide
7.1 7.2 7.3
ENDEVOR SYSTEMS & ENVIRONMENT ACCESS ............................. 25 ENDEVOR ACTION ACCESS................................................................... 25 ENDEVOR JOB FUNCTIONS ................................................................... 26
8 USING ENDEVOR ................................................................................. 28

8.1 USING ENDEVOR IN FOREGROUND .................................................... 28 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 STARTING ENDEVOR ................................................................ 28 SELECTING AN ENVIRONMENT ............................................. 28 SPECIFYING OPTIONS ............................................................... 28 ENDEVOR DEFAULTS ............................................................... 29 BASIC DISPLAY OPTIONS ........................................................ 30 (1) DISPLAYING ELEMENT INFORMATION ............................... 30 (2) DISPLAYING FOOTPRINT OR LISTING INFORMATION ..... 34 (3) DISPLAYING TYPES ................................................................... 35 (4) DISPLAY PROCESSOR GROUPS .............................................. 36 8.1.6 FOREGROUND OPTIONS........................................................... 37 (1) RETRIEVING ELEMENTS .......................................................... 38 (2) ADDING AND UPDATING ELEMENTS ................................... 38 (3) GENERATING ELEMENTS ........................................................ 40 (4) MOVING ELEMENTS.................................................................. 40 (5) DELETING ELEMENTS .............................................................. 41 (6) PRINTING ELEMENTS ............................................................... 42 (7) SIGNING-IN ELEMENTS ............................................................ 44 8.2 USING ENDEVOR IN BATCH .................................................................. 44 8.2.1 WHY USE BATCH? ..................................................................... 44 8.2.2 ACCESSING & INVOKING BATCH OPTIONS ........................ 45 8.2.3 INTERPRETING BATCH RESULTS .......................................... 47 8.2.4 BATCH PROCESSING SUMMARY ........................................... 49 8.3 ENDEVOR REPORTS ................................................................................ 49
9 SUMMARY ............................................................................................. 52
FIGURES
Figure 1: Standard Endevor Lifecycle ................................................................... 10 Figure 2: Extended Endevor Lifecycle .................................................................. 10 Figure 3: Common Program Change Route .......................................................... 16 Figure 4: Environment Selection Panel ................................................................. 28 Figure 5: Primary Options Menu ........................................................................... 29
1.0a (First Draft) Barclays Bank PLC Page v
Endevor User Guide
Figure 6: Endevor Defaults Panel .......................................................................... 29 Figure 7: Display Options Panel ............................................................................ 30 Figure 8: Display Elements Main Panel ................................................................ 31 Figure 9: Element Selection List Panel .................................................................. 31 Figure 10: Element Master Information (1) ........................................................... 32 Figure 11: Element Master Information (2) ........................................................... 32 Figure 12: Element Component List Panel ............................................................ 33 Figure 13: Footprint Display Panel ........................................................................ 34 Figure 14: Footprint/Load Module Display Panel ................................................. 35 Figure 15: Type Display Panel .............................................................................. 35 Figure 16: Type List Panel..................................................................................... 36 Figure 17: Processor Group Display Panel ............................................................ 36 Figure 18: Processor Group List Panel .................................................................. 37 Figure 19: Foreground Options Menu ................................................................... 37 Figure 20: Retrieve Elements Panel....................................................................... 38 Figure 21: Add/Update Elements Panel................................................................. 39 Figure 22: Generate Elements Panel ...................................................................... 40 Figure 23: Move Elements Panel ........................................................................... 41 Figure 24: Delete Elements Panel .......................................................................... 42 Figure 25: Print Elements Panel ............................................................................ 43 Figure 26: Print Request Panel .............................................................................. 43 Figure 27: Sign in Element Panel .......................................................................... 44 Figure 28: Batch Options Menu............................................................................. 45 Figure 29: SCL Generation Panel ......................................................................... 46 Figure 30: Retrieve Elements Panel...................................................................... 46 Figure 31: Reporting Interface Panel .................................................................... 49 Figure 32: Report Selection Panel ........................................................................ 50
Page vi
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
INTRODUCTION
Endevor-MVS is a Software Configuration Management (SCM) System that is used to control and monitor the application development process on the mainframe. The system allows you to: record all changes made to application elements and identify the person(s) responsible for the changes prevent conflicting changes to the same application element manage related elements as a release and action the group of elements together using single commands create an audit trail of changes, with up to 99 versions, and up to 100 levels of change per version retrieve a prior level of any element define and control development and operational handover procedures produce online and hardcopy of the system inventory. Endevor is installed at each of the Bank's computer centres and is run under MVS, using TSO ISPF. Endevor also has a batch interface for largescale actions, and its own 'programming interface' called Software Control Language (SCL) for manipulating elements. Endevor is currently the Bank standard product for configuration management on the mainframe.
1.1
HOW TO USE THE GUIDE. This guide consists of two parts: A description of the Endevor system, the Barclays Bank design of the system and the functionality provided, plus an overview of Endevor security; read this section first for an overview of what Endevor is and how people commonly use it A detailed description of the procedures required to manage elements within Endevor, and how to actually access and use the product.
1.2
WHERE TO GET HELP Endevor is administered and supported centrally by the Mainframe Tools Support team at Radbroke Hall. Currently the team personnel are: Gary Haynes, Team Leader, 7-2000-3011 Nick Clarke, Lead Endevor Administrator, 7-2000-4075 Jonathon Fell, Technical Support, 7-2000-2441.
1.0a (First Draft)
Barclays Bank PLC
Page 7
Endevor User Guide
The Endevor support team can be contacted on the above numbers or by calling the Development Support Help Desk (7-2000-2228) who will log an incident and hand you on. Whilst each project area may have its own primary Endevor contact on hand to answer 'how to' questions specific to that project, all Endevor users are welcome to contact the above team with any query they have. This may be a simple "How do I" question, or a requirement to understand a compile failure, or a request to change the Endevor architecture of the project (e.g. by adding a new part to the lifecycle). The Endevor support team is responsible for all Endevor administration, including all library administration (e.g. if datasets require compression). At the present time, the team is generally available from 9am to 5 pm Monday to Friday. There is no weekend or on-call support provided.
Page 8
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
STANDARD LIFECYCLE
The standard lifecycle supported by Endevor at each centre consists of a number of Endevor environments and stages.
2.1
ENVIRONMENTS An Environment is the highest level definition within Endevor. It allows organisational distinctions to be identified and controlled individually. An Endevor Environment will reflect the process involved in the lifecycle of a development project. The four environments standard throughout Barclays are, in 'descending' order:
LIVE ACCEPT SYSTEMS
an image or copy of the live system Note: copy, for more details see section 2.3.3 an environment for Acceptance testing an environment for Systems testing an environment for unit / link testing.
PROGRAM -
Some project areas may require more complex lifecycles, to allow for longer release cycles and/or multiple developments in parallel. For this reason, additional environments can be made available on request: PARALA to PARALL: for parallel developments; these are positioned alongside and completely independent from the standard PROGRAM environment, but like it feed directly into SYSTEMS; SERIALA: for extending the standard lifecycle before PROGRAM.
There are additional administration and training environments, but these are not generally available and are not mentioned elsewhere in this document. 2.2 STAGES Each Endevor environment consists of two stages. These are numbered 1 and 2, but may also be named according to the environment. For example, at Live, stage 1 is called EMER - Emergency Amendment, and stage 2 is called LIVE - Live System; whereas at Accept, stage 1 is FIX - Fix Acceptance Test, and stage 2 is ACCEPT - Acceptance Test. Referring to the stages consistently as stage 1 and 2 is the normal method. Two stages exist to facilitate testing of changes prior to release. For example, a problem in Live can be fixed and tested in the stage 1 (without impacting the live system or any other code) and then promoted into the stage 2 area for release. In normal operation, all code has to enter an environment via the stage 1 area and be moved into the stage 2 area.
1.0a (First Draft) Barclays Bank PLC Page 9
Endevor User Guide
2.3
LIFECYCLE MAPPING The Endevor lifecycle is formed by mapping stages and environments. All stage 1s map into the relevant stage 2, and stage 2s then map further up the lifecycle to the next environment. Programs enter (are ADDed to) the lifecycle at a stage 1 and MOVEd up to the next environment when ready. All Endevor libraries will concatenate in this manner. For example, if you are compiling in Systems stage 1, the compiler will automatically look for copybooks in the following order: Systems1, Systems2, Accept2, and Live2. The map specifically excludes stage1s higher up the lifecycle.
2.3.1 STANDARD ENDEVOR LIFECYCLE The standard lifecycle map is as follows:

Error! Not a valid link.Figure 1:
Standard Endevor Lifecycle
Each stage 1 maps to the appropriate stage 2. Each stage 2 maps up to the next stage 2, until Live2, which is deemed the 'end' of the lifecycle, i.e. the 'highest' environment in which an element can reside. For example, the lifecycle of a new program would be: Add into Program stage 1 for unit testing Move to Program stage 2 for link testing Move to Systems stage 2 for systems testing - With optional fixes at Systems testing performed in Systems stage 1 and moved back into Systems stage 2 Move to Accept stage 2 for acceptance testing - With optional fixes at Acceptance testing performed in Accept stage 1 and moved back into Accept stage 2 Move to Live stage 2 for Live running - With emergency live fixes performed in Live stage 1 and moved back into Live stage 2 when tested. All projects within Barclays have at least the above lifecycle definitions. 2.3.2 EXTENDED ENDEVOR LIFECYCLE For project areas requiring an extended lifecycle, the following can apply in part or in full.
Error! Not a valid link.Figure 2:
Extended Endevor Lifecycle
Page 10
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
In the extended lifecycle, each environment operates as standard with a Stage 1 and Stage 2. However, SERIAL2 maps into PROGRAM2, whereas each of the PARALlel environments is an independent programming level, each mapping to SYSTEMS2. In this way, multiple parallel developments can run without impacting one another. 2.3.3 LIVE SYSTEMS AT BARCLAYS A cautionary note Endevor contains facilities for securing the Live environment so that it is the actual Live application system - i.e. the load library associated with the Live environment at Stage 2 is from where the application actually runs. Endevor provides a facility called Package Shipment to distribute the Live code to a different mainframe, i.e. the live machine. In this way, Endevor is completely responsible for the integrity of the development & live code and the relationships between them. However, Barclays do not release live code in this manner. At Barclays, the Endevor LIVE environment is a copy of the code actually running live. The Customer Application Support team (CAS) take a release into Live from the Endevor ACCEPT environment (or a handover library populated by the project from the Endevor ACCEPT environment). Once this code has actually gone live, then the ACCEPT elements are promoted into Endevor LIVE. Clearly, there is scope, however small, for discrepancies to arise between what is deemed "live" in Endevor and what is actually running Live on the mainframe. Within the Barclays method there is no way to avoid this, as development users generally do not have access to the live mainframe and vice versa. However, it is important to realise that: Just because you move something up the lifecycle to LIVE in Endevor, that does not mean it has actually gone Live, and Just because the element at LIVE in Endevor is at, say, v. 1.15, that does not necessarily mean that the element actually running on the live machine is the same version. It should be, but it may not be.
To avoid any possible issues, full use should be made of Endevor's reporting, auditing & footprinting capabilities. Examine a live load module on the live machine, and its footprint will state exactly what elements have been used to construct it. These should mirror exactly what is in the Endevor LIVE environment.
1.0a (First Draft)
Barclays Bank PLC
Page 11
Endevor User Guide
STORING CODE IN ENDEVOR

Code in Endevor follows a migration path according to the lifecycle. However, within the lifecycle Endevor supports a wide variety of code types across multiple systems and subsystems.
3.1
ENDEVOR CODE TYPES When source is stored in Endevor, it is defined according to a set of predefined types. The type of a source code element defines what sort of code is being held and consequentially what processing makes sense for that element. For example, COBOL II source is stored as type COBOLII; JCL as type JCL; copybooks as type COPYBOOK and Link Cards as type LINK. Associated with each type is a set of pre-defined processor groups that define what happens for code of that type. For example, there is a processor group for type COBOLII that initiates a compile using the COBOL II compiler whenever the element is generated - this happens automatically for code of that type. Whereas the generate processor for type COBOL370 initiates the COBOL for OS/390 compiler instead. A generate of an ASM type initiates an assemble process. Not all project areas will require all types, and some will require a few non-standard types (particularly for storing and processing code received as part of a 3rd party application or package). By default, the following types are defined for all projects in Endevor as standard: COBOLVS (now de-installed, no longer supported) COBOLII (to be removed when IBM withdraw support in c. 2001) COBOL370 (now COBOL for OS/390) COPYBOOK for COBOL copybooks DCL for DB2 DCLGEN copybooks (optional) BINDPLAN for DB2 bind decks ASM for assembler code MACRO for assembler macros LINK for Link Edit decks MFS for IMS screen formats BMSMAP for CICS maps JCL for standard JCL decks TEXT for standard text / documentation LOADMOD for 'raw' load modules (e.g. delivered from 3rd party, or where no source is available).
Barclays Bank PLC 1.0a (First Draft)
Page 12
Endevor User Guide
In addition, other types may be of interest, for example REXX for storing mainframe ReXX execs, CLIST, PANEL, various Focus types, etc. It is important to remember that each type can have more than one processor group against it. For example, the COBOLII type has separate processor groups for batch, CICS, IMS & DB2 processing (and combinations thereof). The code type defines what sort of source the element is, not exactly how it will be generated. Therefore there is one COBOL II type which can be processed for Batch, CICS, DB2, IMS etc. as appropriate - not separate types for CICS COBOL, IMS COBOL, Batch COBOL and so on. You can change the processing stream for an element (e.g. if you move from VSAM to DB2) without changing the source type you simply change the related processor group for that element. It may go from VSAM to DB2, but it is still a COBOL II program. 3.2 ENDEVOR SYSTEMS Source code is grouped within a system. At Barclays, the system names are logically derived from the project / application code, with an additional description. For example, system WBY is Branch Accounting; DLY is Customer; BOY is Triumph, and so forth. There are multiple systems stored in each environment and stage. The system names, along with the environment and stage, are used to physically catalog the source code and resulting outputs. For example, the load library for project WBY at stage 2 of LIVE is WBY.LIVE2.LODLIB. 3.3 ENDEVOR SUBSYSTEMS Each system can be logically broken down into one or more subsystems. Subsystems may be useful for splitting out separate sub-application groups within Endevor, for reporting or lifecycle management. However, it is important to note that subsystems are not used to physically store the output from compiles of elements. For example, any code in subsystem A of WBY is stored in the same output file as code in subsystem B of WBY. Whilst Endevor can report on this separately, having any duplicate names across subsystems within the same system - whilst permitted - can lead to confusion. To illustrate this, consider fictional system AAY in environment Live. AAY has subsystems PAYROLL and REPORTS. We are permitted to store a COBOL program called AAAA1 in both subsystems of AAY and Endevor will store these as separate elements, each separately identifiable. They could even contain completely different code (e.g. different releases of a 3rd party package). However, since there is only a logical split for subsystems, and the physical split is at the system / stage / environment level, there is only one Load Library for system AAY at Live stage 2: AAY.LIVE2.LODLIB. If we generate and link program AAAA1 in subsystem PAYROLL, the lodlib will contain this version of AAAA1. But
Endevor User Guide
if we then generate and link program AAAA1 in subsystem REPORTS, this overwrites the load member in the output load library - even though Endevor will tell us that there are two different AAAA1 programs, one in each subsystem, and allow us to work on these separately. However, provided we keep member names unique, we can use the subsystem concept to promote the whole of the PAYROLL subsystem into LIVE while leaving the REPORTS subsystem in development. If you require more than one Endevor subsystem, ensure that everyone is aware of the way output libraries are managed. More detail is given on that in a later section. 3.4 IDENTIFYING ENDEVOR ELEMENTS An object stored under Endevor's control is known as an element. Each Endevor element is uniquely identifiable by a combination of its name, its type, its subsystem, system, environment and stage. For example, COBOL II source element FRED in Live stage 2 of system AAY subsystem PAYROLL is completely different from element FRED of type LINK in the same system, subsystem, environment and stage. If you ask Endevor to list all elements named FRED, it would show both the COBOL II source and the Link card as separate elements. Equally, FRED in AAY is completely separate from element FRED in system WBY at Program Stage 1. Elements can be logically grouped - either for reporting or acting on - by any combination of these factors. For example, the following are all valid logical concepts in Endevor: Promote all COBOL II code in System WBY from ACCEPT2 to LIVE2 Promote all code in system WBY from ACCEPT2 to LIVE2 Promote all code in system WBY subsystem BRANCHES from ACCEPT2 to LIVE2 Promote member FRED in system WBY subsystem BRANCHES of type ASM from ACCEPT2 to LIVE2 Promote all COPYBOOKs from WBY Systems stage 1 to Systems stage 2.
Furthermore, because all of the above take place under the control of Endevor, there is a complete audit trail of who did what, when, and where.
Page 14
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
MANAGING CODE IN ENDEVOR

Once code is stored in Endevor, the key activity is managing that code through the development lifecycle. In order to facilitate this, Endevor provides a number of actions and processor groups. An Endevor action defines what is to be done to an element, or set of elements. The processor groups define exactly how that will be carried out. For example, the Endevor action MOVE moves code from its current location up the lifecycle. The associated move processor defines exactly how that happens for the particular code being moved. e.g. a COBOL II move may promote the source element, its compiled Object member, its listing and possibly a related load module - whereas a move for a type of TEXT will only promote the element because there are no related outputs. Equally, a GENERATE on a COBOL II element will do many different things depending on what processor group is invoked for the action: a processor group requesting CICS compile and link will invoke tasks to pre-compile the element for CICS, compile it through the standard compiler, produce a load module, and write all that out to the output datasets (lodlib, listing dataset, etc.). A GENERATE on the same COBOL II element for batch without a link will do something completely different.
4.1
COMMON ENDEVOR ACTIONS The most common Endevor actions are as follows: DISPLAY: show the contents of an element, and/or the audit trail, history and changes associated with it PRINT: as above, but print to a dataset or printer rather than show on screen RETRIEVE: take an image of an element out of Endevor into an external library to work on. The element remains in Endevor, but is "signed out" to the individual who retrieved it. A record of the sign out is kept and an element can only be signed out to one user at a time. If a user wishes to take a copy of an element but not sign it out, e.g. for testing or compiling purposes in another environment, then the element can be retrieved 'without sign out' ADD: add a new piece of code from an external dataset (e.g. a user library where editing takes place) into Endevor. The object will be stored and audited in Endevor, with automatic versioning of changes. Where relevant, the Endevor processor will also produce output components (e.g. an object module, load module or listing). ADD is only relevant at Stage 1, you cannot ADD directly into Stage 2. If the element already exists in the stage 1, the ADD will fail UPDATE: update an element that already exists, with processing as for ADD. Again, UPDATE is only relevant at Stage 1.
Barclays Bank PLC Page 15
1.0a (First Draft)
Endevor User Guide
You can combine ADD and UPDATE by specifying ADD and turning on the option "Update if present" - this will attempt the ADD, and if the element already exists it will be updated. In normal circumstances, only the person who RETRIEVEd the code can then UPDATE the element back with the changes made externally, thus preventing someone from overwriting any changes. However, certain people will be granted the authority to 'override signout' in order to action emergency changes MOVE: move one or more elements through the lifecycle along the predefined map, e.g. from Stage 1 to 2 or into the next environment DELETE: delete element(s) no longer required in that system, stage, environment etc. SIGNIN: specifically sign in an element previously signed out - for example, if code was taken out for changes that have been cancelled, the elements can be signed in to allow other users update access GENERATE: generate the input element (i.e. the source) and produce the required output objects. The detailed processing here depends on the type of element and the processor group selected. An example of GENERATE action could be to re-compile a COBOL II program after changes have been made to one of the copybooks it uses. We do not have to RETRIEVE the COBOL II and ADD it back into Endevor to do this, because the COBOL itself has not changed; we just regenerate the COBOL element in situ LIST: produce a list of elements matching a certain criteria (e.g. in a particular system, environment & stage, or even list any elements containing a string in a certain column). Elements identified by the LIST action can then be actioned upon as a group. For example, we could LIST all elements that use the copybook FRED and request an action of GENERATE against them.
From the list above it can be seen that a common sequence of actions for a COBOL developer would be to: RETRIEVE some code to be worked on from an Endevor location (e.g. Live stage 2, to make an emergency fix) into a user library Change the code in the external library ADD the code back into the Stage 1 location for testing When testing is complete, MOVE the code into Stage 2.
No GENERATE is required here because ADD will issue an automatic generate anyway. The standard development route for program changes is illustrated in the following figure. Note that a development would normally consist of more than one program!
Error! Not a valid link.Figure 3: Page 16
Common Program Change Route

1.0a (First Draft)
Barclays Bank PLC
Endevor User Guide
All of these actions are audited in Endevor automatically and can be displayed or reported on. Furthermore, if the emergency fix proves to introduce more problems than it solves then the original release of the COBOL can be RETRIEVEd and reinstated in Endevor to back out the change. Full lifecycle management is possible using some combination of these basic Endevor actions. 4.2 CHANGE CONTROL IDENTIFIERS Whenever an Endevor action is performed, the user must specify a Change Control Identifier, or CCID. This is a tag applied to the audit record for reporting and grouping purposes. At the same time, the user can specify a textual description of the action taking place. The CCID is a mandatory, alphanumeric, user defined field, up to 12 characters long. It will be used to identify and group together elements as part of a change and/or for a specific handover to Operations/CAS. CCIDs give maximum benefit if they are applied when the members are first introduced into Endevor. CCIDs could represent: BBC2O number PAF number Infoman Change Management Number An ADE-generated reference
but can be anything of meaning or use to the project. The CCID is recorded against the element. As a result, a user could GENERATE all COBOL II elements for a particular release and give them the same CCID; and could later say MOVE all elements with that CCID. 4.3 FOOTPRINTS Endevor uses its footprinting mechanism to audit elements and ensure integrity. For example, the footprint can ensure that a load module in an output library was produced by Endevor using the appropriate levels of source code. The Endevor footprint is encrypted and contains details on the: Site each mainframe system currently has a unique site id e.g. Live e.g. 1 e.g. WBY
Environment Stage System -
1.0a (First Draft)
Barclays Bank PLC
Page 17
Endevor User Guide
Sub-system Element Name Element Type Version/Level Date/Time
e.g. BCHACC e.g. FRED e.g. COBOL II e.g. 1.14 14th February 1998 at 10:32.
This footprint is embedded within the element and can be reported on to ensure integrity between input (source) elements and output objects. 4.4 ENDEVOR VERSIONING Endevor maintains the history of element changes via use of 'base' and 'delta' images. Changes between versions of the element are stored as deltas. Endevor can support up to 99 versions of an element, each version with up to 100 'levels'. When an element is first added into Endevor, it is stored as Version 1 Level 0 - in 1.00 notation. When changes are made, the level number is incremented. For example, if the element at 1.00 is changed, it becomes 1.01. Because Endevor stores all the base and delta information, any old levels of the code can be retrieved and reinstated. Also, Endevor can show all the changes between one level and the next, or summaries of which lines were added / changed at each level since the base version. Most elements worked on in Endevor at Barclays already exist somewhere in the lifecycle, and are being changed. To track changes on the version retrieved for working on, Endevor uses the current version of the element up the lifecycle map as the base release for any changes, and deltas new changes accordingly. For example: assume element FRED is Live at v 1 level 5 - 1.05. Some new changes are required on FRED so it is retrieved from Live 2 and added into Program stage 1 - the base release when FRED is added to Program 1 is 1.05. Any changes made to FRED will increase the level number to 1.06. When FRED eventually returns to Live, the version / level number will go with it. If many changes are made at Program stage 1, the level number may increase quite rapidly - for example, you could end up with FRED 1.26 if you repeatedly change it. Most of this delta information at Program stage 1 is irrelevant when FRED is moved up the lifecycle; they were unit test changes and there is no need to record all the various errors. For this reason, Endevor allows the move up the lifecycle to consolidate the change history back to one level of delta: in this example, FRED would move to Program Stage 2 and become 1.06. This is called 'Move without history'. It is entirely your choice whether you preserve all the history or not. The Endevor default is to collapse deltas into one new change level on a move.
Page 18
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
Endevor will automatically consolidate levels according to pre-set threshold values that should not require changing (currently set to 75). Several versioning situations requiring attention may arise during the lifecycle of a program, particularly where an element is being worked on at multiple parts of the lifecycle. The two scenarios important to understand are 'out of sync' errors and 'jump' errors. 4.4.1 Source code out of sync Code in Endevor becomes out of sync if the base level of an element being moved does not match the version further up the lifecycle. This can happen where the element is worked on at multiple parts of the lifecycle and some changes are cancelled. For example, consider element FRED in Live stage 2 at version 1.05. A new release starts in program and eventually moves to Systems Stage 2 for Systems testing, where FRED has become 1.06. While this change is still in progress, another change begins, also impacting FRED. FRED is added into Program 1, and Endevor forms its base at Program from the element it finds up the lifecycle map: in this instance, FRED in Systems 2 at 1.06 first. So FRED becomes 1.06 in Program, with its base level the same as the element currently in Systems 2. Any changes to FRED at Program will in turn increase the level number to 1.07. If the release in Systems moves eventually to live then FRED 1.06 will go live. When the release in Program also moves up to Accept, Endevor is happy with the changes as the element in Live and Accept were the same when the base level was taken. It will make FRED 1.07 at Live: 1.05 being the original live release, 1.06 being the release from Systems, 1.07 including the new changes from the level in Program. However, if the release in Systems is cancelled, then FRED 1.06 is deleted from Endevor. When this happens, the base version used to track FRED in Program is lost (remember, FRED in Program was based upon FRED in Systems when it was created, not FRED in Live). As a consequence, when the Program version of FRED is moved up the lifecycle, Endevor cannot track the FRED 1.06 version originally used to form this element - the latest release was 1.05 in Live. Endevor considers the element FRED 1.07 to be 'out of sync' with the element 1.05 in Live, because an intervening version has gone missing. If this happens, Endevor can be forced to synchronise the elements when moved into Live 2. It will mark this as having taken place, and form a new delta at Live 2 of the changes between the release originally changed at Program and the old release in Live 2. 'Sync' is an option on the Move statement. This is not a show-stopping error, and does not occur often as most changes move up the lifecycle in good order. However, where a release or change is cancelled, Sync errors can arise.
1.0a (First Draft)
Barclays Bank PLC
Page 19
Endevor User Guide
4.4.2 Source code requires a Jump Move 'Jumps' are required whenever Endevor finds elements at a 'nonmapped' location in the lifecycle between the source and target locations on the Move. In simple terms, this most often happens when an element is being worked on in stage 1 area when another release wants to enter the stage 2 from the previous environment. For example: element FRED exists in Live stage 2. FRED is also part of a release that is now in Acceptance testing ready to go Live - i.e. to be moved from Accept 2 to Live 2. However, overnight FRED failed and was worked on in Live stage 1 to produce an emergency fix. As a consequence, FRED is in Accept 2, Live 1 and Live 2 at the same time. Any attempt to move FRED from Accept 2 to Live 2 will give rise to a Jump error effectively asking if you want the version from Accept 2 to "jump over" the emergency changes. This may be a valid thing to do. The Live 1 version may be a throw away version for a scenario that will never happen again; or the fix from Live 1 may already have been incorporated into the Accept 2 version. If so, the best thing to do is delete the version from the stage 1. The Move will then work without error, as there is no intermediate level to jump over. Again, jump errors are rare in normal circumstances. Forcing a jump will execute the Move anyway, if that is the appropriate thing to do. 4.5 OTHER ENDEVOR ACTIONS There are also a number of ancillary actions available within Endevor, generally for use by system administrators. These include the ability to ARCHIVE and RESTORE elements in bulk (e.g. to move them from one system to another, or to take a backup). However, their use is not discussed here.
Page 20
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
ENDEVOR PROCESSOR GROUPS

Each Endevor type has a number of processor groups associated with it. These define how that type of code will be processed when added into, updated, or generated in Endevor. Processor groups vary from project to project, and stage to stage. For example, there are processor groups available to automatically compile COBOL code for debugging with Xpediter in the stage 1 areas: but never in the stage 2s (because you should not be debugging in stage 2). You can therefore compile a COBOL program for mainframe debugging by specifying one of these Xpediter processor groups and re-generating. Refer to Endevor for the processor groups specific to your project and lifecycle. However, some generic processor groups are given below: For COBOL II code in a stage 2:
BATLRES BATNRES CICLRES CICNRES DBCLRES DBCNRES DBILRES DBINRES COBOLII BATCH COBOLII BATCH COBOLII CICS COBOLII CICS - WITH LINK - (RES=YES). - NO LINK - NO LINK - (RES=YES). - (RES=YES). - (RES=YES). - (RES=YES). - WITH LINK - (RES=YES).
COBOLII CICS/DB2 - WITH LINK - (RES=YES). COBOLII CICS/DB2 - NO LINK COBOLII IMS/DB2 COBOLII IMS/DB2 - NO LINK - WITH LINK - (RES=YES).
Note: the processor group defines how the element is compiled. Whether generated for CICS or batch, the source code is still COBOL II. Users of the old release of Endevor may be used to specifying the code type differently for CICS and Batch, but that no longer applies. From the above examples, you can see that if you want your COBOL II code to be generated for CICS with an automatic link, use CICLRES. However, if you want to run the link yourself via a separate link card, use CICNRES. For the stage 1 area, you may have a list like this:
BATLRES BATNRES CICLRES CICNRES DBCLRES DBCNRES DBILRES DBILXRES DBINRES 1.0a (First Draft) COBOLII BATCH COBOLII BATCH COBOLII CICS COBOLII CICS - WITH LINK - (RES=YES). - NO LINK - NO LINK - (RES=YES). - (RES=YES). - (RES=YES). - WITH LINK - (RES=YES).
COBOLII CICS/DB2 - WITH LINK - (RES=YES). COBOLII CICS/DB2 - NO LINK COBOLII IMS/DB2 COBOLII IMS/DB2 COBOLII IMS/DB2 - WITH LINK - (RES=YES). - WITH LINK (RES=YES,XPEDITER). - NO LINK - (RES=YES). Page 21
Barclays Bank PLC
Endevor User Guide
DBINXRES
COBOLII IMS/DB2
- NO LINK
(RES=YES,XPEDITER).
All of the stage 2 processor groups are there, plus the special Xpediter stage 1 only processor groups. Normally, processor groups are mirrored throughout all the environments and stages for a project, because processor group is an 'attribute' of an element and therefore must exist as the element is promoted. Where generation does not really have a meaning - e.g. for the type of MACRO - you will see the following processor group:
*NOPROC* DEFAULT PROCESSOR GROUP.
NOPROC essentially does nothing except a) tag the element as being successfully generated, and b) image the source to the output library if appropriate. In this example, adding & generating a MACRO with NOPROC will copy an image of the source to the output MACLIB. Once the processor group is set for an element when it is first added, you only need to specify it again if you ever want to change it - otherwise, Endevor will re-use the last processor group. To see what processor groups you have for your code in your project, use the DISPLAY .. PROCESSOR GROUP panel in on-line Endevor (see section 8.1.5(4)).
Page 22
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
ENDEVOR LIBRARIES
There are three types of Endevor libraries: Input libraries - where the elements are actually stored Output libraries - generated by Endevor from the input source Master Control Files (MCFs) - essentially the Endevor 'catalog', administered centrally by the Endevor support team at Radbroke Hall.
Only the Endevor support team and Endevor itself have alter access to any Endevor libraries. Any library maintenance required must therefore be performed by the support team at Radbroke Hall. Daily backups and 'tidy ups' of the libraries are performed by Storage Management Systems Group (SMSG) using the Hierarchical Storage Management (HSM) product. Backups are kept on and off site for a certain period of time, for further details please contact SMSG direct. 6.1 INPUT LIBRARIES The key input libraries are the Endevor BASE and DELTA files. These are compressed, encrypted source storage files using VSAM file formats for high performance. The BASE library stores the base source code image. The DELTA library stores the sequence of changes made to that BASE file member in reverse delta format. This means that Endevor keeps the current source file in the BASE and constructs previous versions by applying the deltas in reverse format. This is done for performance reasons; if forward delta-ing is used, every time any user accesses the current source all the deltas need to be applied in order to construct it. There is a BASE and DELTA file for each project, environment and stage combination. For example, for the project AAY the following BASE and DELTA files exist: AAY.PROGRAM1.BASE & AAY.PROGRAM1.DELTA for storing project source at Program Stage 1 AAY.PROGRAM2.BASE & AAY.PROGRAM2.DELTA for storing project source at Program Stage 2 AAY.LIVE2.BASE & AAY.LIVE2.DELTA for storing project source at Live Stage 2.
and similarly all the way up to
In the normal operation of Endevor, users do not even need to know that these files exist. But they are the critical datasets for each project. With the appropriate MCF files, all the output libraries can be lost and reconstructed from the contents of the BASE and DELTA libraries.
1.0a (First Draft)
Barclays Bank PLC
Page 23
Endevor User Guide
6.2
OUTPUT LIBRARIES The output libraries are defined as files where Endevor will put objects resulting from actions on input elements. Typical output libraries are: The LISTING dataset, to store compile / link listings: this is also an encrypted compressed Endevor VSAM file for performance reasons The CPYLIB dataset, a PDS containing an image of the copybooks for that project in that environment and stage The MACLIB dataset, a PDS containing an image of any assembler macros for that project in that environment and stage The BINDLIB dataset, another PDS for storing images of Bind Cards.
Like the BASE and DELTA, these are stored for each project, environment and stage combination, as in: AAY.LIVE1.LISTING AAY.LIVE2.LISTING AAY.LIVE1.CPYLIB AAY.LIVE2.CPYLIB
and so forth. Exactly which output libraries are defined will vary from project to project. All output libraries are sacrificial from the point of view of Endevor. The entire library can be lost, but provided the BASE and DELTA remains with the appropriate MCF, the output libraries can be re-constructed. They are given a universal access of READ, but only Endevor can write to them. Any PDS output libraries can be browsed using standard ISPF utilities. However, the encrypted Endevor listing file can only be accessed via Endevor, which provides an option especially for browsing listings. 6.3 MASTER CONTROL FILES The MCF datasets are hidden from the user. They represent the critical catalog information for Endevor, in the form of pointers from the catalogs and lists to the actual source and history information. The MCFs are the responsibility of the Endevor support team, who take care of their administration on a daily basis. There is one MCF file per environment and stage, for all projects. In other words, the LIVE1 MCF stores all the Endevor catalog information for all projects in LIVE Stage 1 at that centre. The integrity of the MCF is critical for successful Endevor operation, and recovery from any disaster or DASD loss.
Page 24
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
ENDEVOR SECURITY
Access to all Endevor systems, environments and actions is protected by standard RACF profiles, defined in a class specific to Endevor. Security administration on these profiles is performed by the Endevor support team at the request of nominated project contacts. There are essentially two levels of RACF access of interest: Access to systems, environments & options, and Access to Endevor actions.
7.1
ENDEVOR SYSTEMS & ENVIRONMENT ACCESS Each system, environment and Endevor menu option is protected by a RACF profile. For example, there is a profile protecting the PARALA environment (as not all systems have one). Normally, local project RACF groups will be connected into these access profiles, rather than individual userids. Therefore, local administration can be performed to permit a new user into an existing group without needing to contact the support team. For example, if project AAY requires a PARALA environment then the AAY local RACF administrator can create a RACF group for this purpose (e.g. AAYPARA). The Endevor support team can connect this group into the appropriate profile. Anyone in AAYPARA will then have access to AAY PARALA. In order to grant access to the parallel environment for a new user, there is no need to contact the Endevor support team; the local AAY RACF administrator can simply connect the new user into group AAYPARA and he/she will inherit the appropriate access. This use of groups allows security access to be granted at an easily maintained level, without saturating RACF with numerous individual userid connections requiring constant maintenance.
7.2
ENDEVOR ACTION ACCESS Endevor actions are also protected by RACF profiles (e.g. a profile to protect the ADD action), but actions are grouped together to form commonly used job functions. This is achieved by the connection of standard Endevor groups into the action profiles. There are 5 such groups for each system, named xxYNDV1-5 where xxY is the system name. For example, an AAY programmer will regularly need access to RETRIEVE code from anywhere (provided it is not signed out), and ADD / UPDATE / GENERATE and probably DELETE their own work in any of the stage 1s. Rather than connect the userid into each profile specifically (once for the ADD, once for the UPDATE, once for the RETRIEVE etc.), a special Endevor group is created to cover all these common accesses - in this case, a group called AAYNDV1.
1.0a (First Draft)
Barclays Bank PLC
Page 25
Endevor User Guide
Unfortunately, RACF does not permit the connection of groups to other groups. As a result, once the special Endevor groups are connected into the profiles, individual user connections must be made to the xxYNDVn groups. Because all the Endevor groups are administered by the Endevor support team, any user requiring specific access (e.g. programmer access) must contact the Endevor support team with their details via the nominated project RACF co-ordinator. 7.3 ENDEVOR JOB FUNCTIONS The 5 standard Endevor job functions and associated groups are independent from one another, and not cumulative. For example, someone in NDV5 does not inherit 1-4 as well. The groups are defined as follows: Programmer: xxYNDV1: access is granted to: RETRIEVE code from anywhere in the lifecycle provided it is not signed out ADD/UPDATE/GENERATE/DELETE in any Stage 1 where code is not signed out to someone else. Programming Team Leader: xxYNDV2: access is granted to: MOVE code to Parallel/Serial and/or Program Stage 2 OVERRIDE SIGNOUT in Parallel/Serial/Program/Systems stage 1s and Parallel/Serial and/or Program Stage 2 DELETE & GENERATE in Program Stage 2 On-Call Programmer: xxYNDV3: access is granted to: OVERRIDE SIGNOUT in Accept stages 1 and 2, and Live stage 1. This may be necessary where the code was being worked on (i.e. signed out to) someone else, but a fault was found requiring a fix. The on-call programmer can override signout on the affected element and provide a fix. Project Leader: xxYNDV4: access is granted to: MOVE from Parallel/Serial/Program stage 2 to Systems Stage 2 MOVE from Systems stage 1 to Systems stage 2 MOVE from Systems stage 2 to Accept stage 2 MOVE from Accept stage 1 to Accept stage 2 GENERATE & DELETE in Systems stage 2 and Accept stage 2 Project Manager: xxYNDV5: access is granted to: MOVE from Accept stage 2 to Live stage 2 MOVE from Live stage 1 to Live stage 2
Page 26 Barclays Bank PLC 1.0a (First Draft)
Endevor User Guide
All other actions in Live stage 2. The job titles are notional. For example, to allow an on-call programmer to produce live fixes overnight, he or she would need to be connected into NDV1 (to RETRIEVE code) and NDV3 (to OVERRIDE SIGNOUT if necessary). If that same programmer was also 'trusted' to actually make the fix live (i.e. did not need independent sanction to then move the fix into Live 2), he/she could also be connected into NDV5. It is at the discretion of the local RACF administrator which groups users are connected into, and all requests must come through the pre-agreed local Endevor RACF co-ordinator (preferably via Email).
1.0a (First Draft)
Barclays Bank PLC
Page 27
Endevor User Guide
USING ENDEVOR
Endevor can be used on-line (in foreground ISPF), or run as a batch job for better performance (for example, if many elements are to be acted upon).
8.1
USING ENDEVOR IN FOREGROUND
8.1.1 STARTING ENDEVOR Endevor is available from the ISPF primary option menu, via option ENV or ENDE. 8.1.2 SELECTING AN ENVIRONMENT The first screen presented is the Environment Selection Screen, which will look something like this:
--------------------- ENDEVOR/MVS Environment Selection ---- Row 1 to 17 of 17 Option ===> Scroll ===> CSR Select an environment to continue. Enter the END command to exit. -- ----------------------------------------------1 PARALA PARALLEL AMENDMENTS 1 2 PARALB PARALLEL AMENDMENTS 2 3 PARALC PARALLEL AMENDMENTS 3 4 PARALD PARALLEL AMENDMENTS 4 5 PARALE PARALLEL AMENDMENTS 5 6 PARALF PARALLEL AMENDMENTS 6 7 PARALG PARALLEL AMENDMENTS 7 8 PARALH PARALLEL AMENDMENTS 8 9 PARALI PARALLEL AMENDMENTS 9 10 PARALJ PARALLEL AMENDMENTS 10 11 PARALK PARALLEL AMENDMENTS 11 12 PARALL PARALLEL AMENDMENTS 12 13 SERIALA SERIAL DEVELOPMENT 1 14 PROGRAM PROGRAM TESTING 15 SYSTEMS SYSTEMS TESTING 16 ACCEPT ACCEPTANCE TESTING 17 LIVE LIVE SYSTEM COPY ******************************* Bottom of data ********************************
Figure 4: Environment Selection Panel The exact list of environments will depend on what access has been granted to your userid. To proceed from this panel, select the number of the environment you want to work in and hit ENTER. Note: this value is used to populate the environment field in ensuing screens, it does not fix you into staying within this environment for the entire Endevor session. You can simply overtype the environment field on any panel. 8.1.3 SPECIFYING OPTIONS After selecting an environment, you will be presented with the Endevor primary options menu:
Endevor User Guide
-------------------- ENDEVOR 3.7.2 Primary Options Menu ----------------------Option ===> 0 1 2 3 U T C X DEFAULTS DISPLAY FOREGROUND BATCH USER MENU TUTORIAL CHANGES EXIT Specify ENDEVOR ISPF default parameters Perform Display functions Execute Foreground Actions Perform Batch Action processing Display user option menu Display information about ENDEVOR Display summary of changes for this release of ENDEVOR Exit the ENDEVOR/MVS dialog Current environment: PROGRAM ENDEVOR/MVS support hotline - DSU at Radbroke Hall Ext.2228 (C) 1987,1995 Computer Associates International, Inc. Use the EXIT option to terminate ENDEVOR/MVS
Figure 5: Primary Options Menu The options are largely self-explanatory. Option U provides access to the Endevor reports facility (see 8.3) and the Parallel Development Manager. 8.1.4 ENDEVOR DEFAULTS If you are using Endevor for the first time, it is worth checking your default options by selecting option 0. Once completed, there should be no reason to re-visit the defaults screen:
UPDATE ----------------COMMAND ===> ENDEVOR USER DEFAULTS ------------------------------
WORK DATASET ALLOCATION INFORMATION: LIST DATASET ALLOCATION INFORMATION: PRIMARY QUANTITY ===> 1 PRIMARY QUANTITY ===> 15 SECONDARY QUANTITY ===> 1 SECONDARY QUANTITY ===> 15 SPACE UNITS ===> CYL (TRK/CYL/BLK) UNIT NAME ===> SYSDA VOLUME SERIAL ===> (BLANK FOR DEFAULT) PRINT OPTIONS: SYSOUT CLASS LINES PER PAGE ===> X ===> 66 FOREGROUND OPTIONS: DISPLAY MSGS WHEN RC GE INTERCEPT ISPF RETURN CMD ===> 8 ===> N
JOB STATEMENT INFORMATION: ===> //JOBNAME JOB (ACCOUNT) ===> //* ===> //* ===> //*
Figure 6: Endevor Defaults Panel Some first time users may find that the List Dataset allocation parameters are set to 1 cylinder. Whilst this may be fine for most elements, some very large programs will blow this limit when working in foreground, and it is worth increasing them to at least 5 cylinders. There are two options for foreground processing worthy of note:
1.0a (First Draft)
Barclays Bank PLC
Page 29
Endevor User Guide
"Display Msgs when RC GE .." specifies the level at which messages will be displayed when performing foreground actions, e.g. generates. If you set this to 0, you will receive numerous messages telling you things have worked OK, with all the job output displayed. If you set it to 4, only actions resulting in a warning (or worse) will be displayed. If you set it to 8, you will only get summary notification unless there are any errors, in which case messages will be displayed. 8 is the recommended option for faster foreground processing (as browsing the message output sometimes takes longer than performing the action!) "Intercept Return Command": if you set this to Y, Endevor will return to its primary option menu on a RETURN command, rather than the ISPF primary option menu. This is entirely your personal preference.
Any changes to the Endevor defaults will not be active until you then exit Endevor completely, and come back in. If you have changed any defaults, do that now. 8.1.5 BASIC DISPLAY OPTIONS Much Endevor work consists of browsing elements or element history, and this basic functionality can be reached via the DISPLAY menu (Option 1 on the Endevor Primary Option menu):
--------------------------OPTION ===> 1 2 3 4 5 6 7 8 9 A E ELEMENT FOOTPRINT SITE STAGE SYSTEM SUBSYSTEM TYPE PROCESSOR GROUP APPROVER GROUP RELATE GROUP ENVIRONMENT DISPLAY OPTIONS MENU ----------------------------
Display Display Display Display Display Display Display Display Display Display Display
element/component list information footprinted members and compressed listings site information stage information system definitions subsystem definitions type definitions processor group definitions approver groups inventory area/approver group relationships information about the current environment
Figure 7: Display Options Panel To display element contents, element information, element history or lists of elements, selection option 1. To display listings, select option 2 (Footprint). As detailed in section 6.2, the compressed listing dataset is only viewable via this option. The other options will display information about the Endevor environment internals where you are working, e.g. the name of the system, a list of types valid for your system or a list of processor groups. (1) DISPLAYING ELEMENT INFORMATION
Selecting option 1 will present the following screen:
Page 30
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
------------------OPTION ===>
Display Elements/Component Lists
------------------------
blank - Display selection list S - Display summary of levels M - Display element master info
B - Browse element current level C - Display changes current level H - Display history current level
Enter SX, BX, CX or HX to display component list information FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE ===> ===> ===> ===> ===> ===> PROGRAM NDY DSG 2 LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ DISPLAY SYS/SBS LIST BUILD USING MAP 1 - UNIT 2 - PROGRAM ===> Y ===> ===> ===> N ===> N (Y/N) (Y/N) (Y/N)
Figure 8: Display Elements Main Panel A combination of entry fields and the command on this panel will produce a wide variety of results and access to a lot of useful information. For example, to get a list of all elements in the system / environment / stage specified above (i.e. PROGRAM stage 2 for System NDY subsystem DSG), simply hit ENTER (command: "blank for selection list"). To get a list of all COBOLII elements in the same location, enter COBOLII in the panel field TYPE above and press ENTER. To get a list of elements with names beginning FRED, enter FRED* in the ELEMENT field above and press ENTER. To get a list of all the elements with the CCID of REL1234, enter REL1234 in the "WHERE CCID EQ" field above and press ENTER. Any such 'list' action will produce a screen similar to the following:
--------------------------COMMAND ===> ELEMENT SELECTION LIST --------- Row 1 to 4 of 4 SCROLL ===> CSR
---- DATES ---ELEMENT TYPE ENVIRON S SYSTEM SUBSYSTEM VV.LL CURRENT GENERATE BBANKTST COBOLII PROGRAM 2 NDY DSG 01.06 28APR99 28APR99 EMCLF00 COBOLII PROGRAM 2 NDY DSG 01.04 24JUN99 EMFLT00 COBOLII PROGRAM 2 NDY DSG 01.02 27MAY99 EMLAR00 COBOLII PROGRAM 2 NDY DSG 01.01 08APR99 ******************************* Bottom of data ********************************
Figure 9: Element Selection List Panel In this example, there are 4 elements in PROGRAM stage 2 for system NDY; they are all COBOLII elements, with various versions, and the dates of the current source level & last generate date are shown on the panel. From any such list, you can quickly view the following information by entering the appropriate line command against the element name: The contents of the element (via B for Browse) The history of the element (via H) The changes at the currently level (via C)
Barclays Bank PLC Page 31
1.0a (First Draft)
Endevor User Guide
MCF information (who added, last action performed, etc.) (via M) A summary of levels (via S) Component list information for any of the above (via attaching an X to the line command, e.g. BX to browse component information).
Examples of this information follow: On command M: two screens of information

------------------------------- ELEMENT MASTER -------------------------------COMMAND ===> (PANEL 1 OF 2) ELEMENT: BBANKTST ENV: PROGRAM SYS: NDY SUB: DSG TYPE: COBOLII PROC GRP: BATNRES STG: 2 VV.LL: 01.06 LAST ACTION: MOVE DESCRIPTION: TEST FOR BBANK. SIGNOUT ID: PKG ID (SOURCE): PKG ID (OUTPUT): --------------------------- LAST ELEMENT ACTION USERID: NDYNJC DATE/TIME: 28APR99 12:17 COMMENT: TEST NDVR RC: 0000 PROCESSOR: MOVEPROC (MOVE) ----------------------------CCID: NICK001 ACTION: MOVE PROC RC: 0000
------------------------------ CURRENT SOURCE ------------------------------USERID: NDYNJCD DATE/TIME: 28APR99 12:11 CCID: NICK001 COMMENT: TEST DELTA FMT: R ADD/UPDATE FROM DSN: NDYNJC.TEST.SOURCE(BBANKTST) --------------------------------- GENERATE ---------------------------------USERID: NDYNJCD DATE/TIME: 28APR99 12:11 CCID: NICK001 COMMENT: TEST COMPONENT LIST VV.LL: 01.00 DELTA FMT: R (Press ENTER for next panel)
Figure 10: Element Master Information (1) Screen 1: shows element name and details, last action, signout to (in this case blank), who created the source and when, who generated the source and when, and so forth.
-----------------------------COMMAND ===> ELEMENT: BBANKTST PROC GRP: BATNRES ELEMENT MASTER ------------------------------(PANEL 2 OF 2) SUB: DSG TYPE: COBOLII LAST ACTION: MOVE SIGNOUT ID:
ENV: PROGRAM SYS: NDY STG: 2 VV.LL: 01.06 RETRIEVE
--------------------------------USERID: DATE/TIME: COMMENT: RETRIEVE TO DSN:
---------------------------------CCID:
----------------------------------- BASE -----------------------------------USERID: NDYNJC DATE/TIME: 10MAR99 14:54 COMMENT: TEST FOR BBANK. --------------------------- FROM ENDEVOR LOCATION --------------------------USERID: NDYNJC DATE/TIME: 28APR99 12:17 ACTION: MOVE ELEMENT: BBANKTST ENV: PROGRAM SYS: NDY SUB: DSG TYPE: COBOLII STG: 1 VV.LL: 01.08 (Press ENTER for previous panel)
Figure 11: Element Master Information (2)
Page 32
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
Screen 2: shows who last retrieved the code (in this case blank), and the base information (i.e. when the element was created and where). On command BX (Browse Components), the following screens (joined and edited here for brevity):
********************************* Top of Data ********************************** ******************************************************************************* ******************************************************************************* ** ** ** COMPONENT LIST COPIED FROM STAGE 1 ** ** ** ** COMPONENT BROWSE 09DEC99 14:32 ** ** ** ** ENVIRONMENT: PROGRAM SYSTEM: NDY SUBSYSTEM: DSG ** ** ELEMENT: BBANKTST TYPE: COBOLII STAGE: PROGRAM ** ** ** ******************************************************************************* ******************************************************************************* ---------------------COMPONENT LEVEL INFORMATION ---------------------------
VV.LL SYNC USER DATE TIME STMTS CCID COMMENT ----- ---- -------- ------- ----- ----- ------------ -------------------------01.00 NDYNJCD 28APR99 12:11 39 NICK001 TEST
-------------------------+00
ELEMENT INFORMATION SUBSYS DSG
-----------------------------TYPE COBOLII GROUP BATNRES STG S 1
VV.LL DATE TIME SYSTEM 01.08 28APR99 12:11 NDY
ELEMENT BBANKTST
-----------------------+00
PROCESSOR INFORMATION
-----------------------------TYPE PROCESS GROUP STG S 1
VV.LL DATE TIME SYSTEM 01.09 16MAR98 14:03 NDY
SUBSYS ELEMENT STDPROCS GCOBBATN
--------------------------STEP: COMPILE +00 +00 DD=SYSLIB
INPUT COMPONENTS
------------------------------
VOL=WCTSAB DSN=NDY.LIVE2.CPYLIB SUBSYS DSG DSG ELEMENT CKZERRB CKZ0199Z TYPE STG COPYBOOK 2 COPYBOOK 2
MEMBER CKZERRB CKZ0199Z
VV.LL DATE TIME SYSTEM 01.00 16DEC98 14:47 NDY 01.00 16DEC98 14:47 NDY
STEP: COMPILE +00
DD=SYSLIB
VOL=WCTSHH DSN=NDY.SYSTEMS2.CPYLIB SUBSYS DSG ELEMENT CKZERRA TYPE STG COPYBOOK 2
MEMBER CKZERRA
VV.LL DATE TIME SYSTEM 01.03 10MAR99 15:48 NDY OUTPUT COMPONENTS
--------------------------STEP: COPYOBJ +00 DD=SYSUT2
-------------------------------
VOL=WCTSHP DSN=NDY.PROGRAM1.OBJLIB SUBSYS DSG ELEMENT BBANKTST TYPE COBOLII STG 1
MEMBER BBANKTST
VV.LL DATE TIME SYSTEM 01.08 28APR99 12:11 NDY
Figure 12: Element Component List Panel This panel shows basic information for the element (name, version etc.) and then:
Endevor User Guide
In Processor Information, what processor was used to generate it In Input Components, what files were used to compile it: in this case, two copybooks CZERRB and CKZ0199Z from Live stage 2 (hidden off screen, page right to see on-line), and one other copybook CKZERRA, from Systems stage 2. All three copybooks have been identified by Endevor up the standard lifecycle map In output components, what the processor produced, namely an object module into the dataset NDY.PROGRAM1.OBJLIB on 28th April 1999 at 12:11.
That is a very brief introduction to the wealth of information available from a single panel entry point. The best way to explore Endevor information is to access this information from the Display panel; you cannot do any harm while in Display mode, simply navigate the panels, try the commands and see what information is available. (2) DISPLAYING FOOTPRINT OR LISTING INFORMATION
If you do not want to browse the element source, but its footprint information or compile listing, selecting Option 2 from the Display Options menu. You will be presented with the following screen:
------------------------- ENDEVOR - FOOTPRINT DISPLAY ------------------------Option ===> blank - Member selection list I - Display load module CSECTS and ENDEVOR footprints L - Display the library member FROM ISPF LIBRARY: PROJECT ===> NDY LIBRARY ===> PROGRAM2 TYPE ===> LISTING MEMBER ===>
THRU MEMBER ===>
OTHER PARTITIONED DATA SET: DATA SET NAME ===>
Figure 13: Footprint Display Panel In the Member field, enter an element name, leave blank for all elements, or put in a name pattern (e.g. ABC*). To display the compile listing, put an L on the command line or against the member in the ensuing list panel. No listing is shown here as they tend to be very large. To display footprint information, use command I instead. Information similar to the following will be displayed:
Page 34
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
--------------------- ENDEVOR LOAD MODULE IDR DISPLAY -------- Row 1 to 5 of 5 Command ===> Scroll ===> CSR Library: WBY.LIVE2.LODLIB Options: B - Browse element H - Show change history C - Show changes only M - Show Master Record Member: KGPZZZ03 S - Show change summary
|--------------------- F O O T P R I N T ----------------------| CSECT SYSTEM SUBSYSTEM ELEMENT TYPE S VV.LL DATE TIME LD *LOADMOD WBY BCHACC KGPZZZ03 LINK 2 01.00 24JUN98 07:53 KGPZZZ03 WBY BCHACC KGPZZZ03 ASM 2 01.00 23JUN98 22:43 KGPZZZ06 WBY BCHACC KGPZZZ06 ASM 2 01.00 23JUN98 22:44 KGPTABRD WBY BCHACC KGPRTAB0 ASM 2 01.00 23JUN98 22:22 KGPTABRQ WBY BCHACC KGPRTAB0 ASM 2 01.00 23JUN98 22:22 ******************************* Bottom of data *******************************
Figure 14: Footprint/Load Module Display Panel (3) DISPLAYING TYPES
To display a list of types valid for your system, select option 7 from the Display Options menu. You will be presented with the following screen
----------------------------OPTION ===> TYPE DISPLAY ----------------------------------
blank - Display type definition ENVIRONMENT ===> PROGRAM SYSTEM TYPE STAGE ===> NDY ===> ===> 1 1 - UNIT 2 - PROGRAM
Figure 15: Type Display Panel Enter the Endevor environment, system name and stage and press ENTER for a list of valid types. You will get a screen similar to the following:
1.0a (First Draft)
Barclays Bank PLC
Page 35
Endevor User Guide
--------------------------COMMAND ===> CURRENT ENV: NEXT ENV: PROGRAM PROGRAM
TYPE SELECTION LIST 1 2 SYSTEM: SYSTEM:
---------- Row 1 to 26 of 26 SCROLL ===> CSR NDY NDY
STAGE ID: STAGE ID:
TYPE TYPE DESCRIPTION TEXT DOCUMENTATION TEXT. REXX ISPF REXX STATEMENTS. CLIST ISPF CLIST STATEMENTS. PANEL ISPF PANEL DEFINITIONS. TABLE ISPF TABLE DEFINITIONS. MESSAGE ISPF MESSAGE DEFINITIONS. SKELETON ISPF SKELETON DEFINITIONS. LOADMOD LOAD ONLY OBJECTS. COPYBOOK COBOL COPYBOOKS. DCL IMS/DB2 DCL COPYBOOKS. MFS MFS SCREEN DEFINITIONS. MACRO ASSEMBLER MACROS. BMSMAP BMS SOURCE CODE. GENLIB GENLIB PARMS. ASM ASSEMBLER SOURCE CODE. COBOLVS COBOL/VS SOURCE CODE. COBOLII COBOL/II SOURCE CODE. COBOL370 COBOL/370 AD-CYCLE SOURCE CODE. LINK LINKEDIT INCLUDE DECK. BINDPLAN DB2 BIND PLAN STATEMENTS. JCL JOB CONTROL LANGUAGE. FOCMAST FOCUS FILE DEFINITIONS. FOCSQL FOCUS DB2 ACCESS FILE DESCRIPTIONS. FOCPSB FOCUS IMS ACCESS FILE DESCRIPTIONS. FOCEXEC FOCUS INTERPRETED CODE. FOCCOMP FOCUS COMPILATION. ******************************* Bottom of data ********************************
Figure 16: Type List Panel Key S against any type for further information if required. (4) DISPLAY PROCESSOR GROUPS
To display a list of processor groups valid for your system at this stage and environment, select option 8 from the Display Options menu. You will be presented with the following screen:
----------------------OPTION ===> PROCESSOR GROUP DISPLAY -----------------------------
blank - Display processor group definition ENVIRONMENT ===> PROGRAM SYSTEM TYPE STAGE GROUP ===> NDY ===> COBOLII ===> 1 ===> 1 - UNIT 2 - PROGRAM
Figure 17: Processor Group Display Panel
Page 36
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
Enter the Endevor environment, system name and stage and press ENTER for a list of valid processor groups for that combination. You will get a screen similar to the following:
--------------------COMMAND ===> CURRENT ENV: NEXT ENV: PROGRAM PROGRAM PROCESSOR GROUP SELECTION LIST STAGE ID: STAGE ID: 1 2 SYSTEM: SYSTEM: NDY NDY ------- Row 1 to 8 of 8 SCROLL ===> CSR TYPE: TYPE: COBOLII COBOLII
PROCESSOR GROUP PROCESSOR GROUP DESCRIPTION BATLRES COBOLII BATCH - WITH LINK - (RES=YES). BATNRES COBOLII BATCH - NO LINK - (RES=YES). CICLRES COBOLII CICS - WITH LINK - (RES=YES). CICNRES COBOLII CICS - NO LINK - (RES=YES). DBCLRES COBOLII CICS/DB2 - WITH LINK - (RES=YES). DBCNRES COBOLII CICS/DB2 - NO LINK - (RES=YES). DBILRES COBOLII IMS/DB2 - WITH LINK - (RES=YES). DBINRES COBOLII IMS/DB2 - NO LINK - (RES=YES). ******************************* Bottom of data ********************************
Figure 18: Processor Group List Panel By keying S against one of these names, or by entering the name on the display panel above, you can see details about the processor group. 8.1.6 FOREGROUND OPTIONS Displaying information about elements already in Endevor is all well and good. But the foreground options menu provides access to the actions to populate the Endevor system with source code, and manage that code through the lifecycle. Note: for more than a few elements, foreground processing is slow and batch processing is preferable. The foreground options menu follows:
-------------------------- Foreground Options Menu ---------------------------Option ===> 1 2 3 4 5 6 7 8 DISPLAY ADD/UPDATE RETRIEVE GENERATE MOVE DELETE PRINT SIGNIN Display an element Add or update an element into stage 1 Retrieve or copy an element Execute the Generate Processor for this element Move an element to the next inventory location Delete an element Print elements, changes and detail change history Explicitly sign-in an element
Figure 19: Foreground Options Menu The Display option is replicated in the foreground option menu to avoid having to come out to the primary option menu to display the results of any actions. It functions exactly as Display from the primary option menu.
1.0a (First Draft)
Barclays Bank PLC
Page 37
Endevor User Guide
(1)
RETRIEVING ELEMENTS
Select Retrieve from the Foreground Options menu to take code out of Endevor into an external library, e.g. for editing. The screen follows:
------------------------------ RETRIEVE ELEMENTS -----------------------------OPTION ===> ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History R - Retrieve element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE COMMENT ===> ===> ===> ===> ===> ===> ===> PROGRAM NDY DSG 2 ACTION OPTIONS: CCID ===> EXPAND INCLUDES ===> SIGNOUT ELEMENT ===> OVERRIDE SIGNOUT ===> REPLACE MEMBER ===> 1 - UNIT 2 - PROGRAM
N Y N N
(Y/N) (Y/N) (Y/N) (Y/N)
TO ISPF LIBRARY: PROJECT ===> NDYGBH LIBRARY ===> COBOL TYPE ===> SOURCE MEMBER ===>
LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ BUILD USING MAP FIRST FOUND TO OTHER PARTITIONED OR SEQUENTIAL DATA SET: DATA SET NAME ===>
===> Y (Y/N) ===> ===> ===> N (Y/N) ===> Y (Y/N)
Figure 20: Retrieve Elements Panel You specify on the panel where the Endevor element to be retrieved is currently held (FROM ENDEVOR), and where you want the element to be stored (TO ISPF LIBRARY). The element display options are there to allow you to see the history / changes for an element, and if appropriate run the RETRIEVE against a previous level (i.e. not the current version). This is to enable backout of any changes. In the Action Options area, you can specify the CCID associated with the retrieve, and whether you want the element signed out to you, or just take a read-only copy. 'Replace Member' will overwrite a member of the same name in the target ISPF library if set to Y. In the List Options area, you can specify a list only where CCID or Processor Group equal a certain value (e.g. you want to retrieve an element you know is part of the release tagged DEV1234). Also, you can specify that Endevor builds the list using the lifecycle map (so it will start in the current environment and stage (Program 2 here) and list all elements up the lifecycle to Live 2). Most of the foreground action panels are similar to this one, and most of the fields are self-explanatory. If you require any help, just press F1. (2) ADDING AND UPDATING ELEMENTS
Select Add/Update from the Foreground Options menu to enable population of an Endevor environment / system / stage with code.
Endevor User Guide
The following screen is displayed:

---------------------------OPTION ===> blank - Member list TO ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE: COMMENT ===> SYSTEMS ===> NDY ===> DSG ===> ===> 1 ===> LIST OPTIONS: DISPLAY LIST THRU MEMBER ===> ===> Y (Y/N) ADD/UPDATE ELEMENTS A - Add an element ---------------------------U - Update an element ===> ===> ===> ===> ===> ===> ===>
ACTION OPTIONS: CCID GENERATE ELEMENT DELETE INPUT SOURCE NEW VERSION OVERRIDE SIGNOUT PROCESSOR GROUP UPDATE IF PRESENT
Y (Y/N) N (Y/N) N (Y/N) N (Y/N)
FROM ISPF LIBRARY: PROJECT ===> NDYGBH LIBRARY ===> COBOL TYPE ===> SOURCE MEMBER ===>
FROM OTHER PARTITIONED OR SEQUENTIAL DATA SET: DATA SET NAME ===>
Figure 21: Add/Update Elements Panel Panel entry fields allow specification of where in Endevor the element is to be added (TO ENDEVOR section), from where the source is to be taken (FROM ISPF LIBRARY section), and what options should be used on the add: e.g. what CCID to apply, whether to delete the source from the ISPF library to clean behind, what processor group to apply, and whether to update the element on the Add if it is already present. To execute an ADD, use option A; use option U to do an update (i.e. when you know the element already resides in the Endevor location). If you select DISPLAY LIST = 'Y' and leave the command line blank, a list of members in the ISPF library will be displayed and you can then use A or U as line commands from that list. If you Add and leave processor group blank, Endevor will use the default processor group for that type. If you Update and leave it blank, Endevor will re-use whatever processor group was last used for that element. If you specify a processor group, Endevor will use whatever you specify. Always specify a CCID and comment for this change. Once the element is added, you can view the Master Control File information for it from the Display option, via line command M. Endevor will check that if the element is signed out, it was signed out to you - you are of course allowed to add in or update a member you previously retrieved and signed out. If the signout id is not yours, the update / add will fail unless you specify (and have authority to request) override signout of the element currently in Endevor. Endevor will calculate the new version number automatically, unless you specify "New Version", in which case that will be allocated. For details on Endevor versioning, see section 4.4
Endevor User Guide
(3)
GENERATING ELEMENTS
To recompile a program, there is no need to retrieve it and add it back in. Simply re-generate the element in place. Use the generate action for this.
------------------------------ GENERATE ELEMENTS -----------------------------OPTION ===> ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History G - Generate element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE COMMENT ===> ===> ===> ===> ===> ===> ===> ===> Y (Y/N) ===> ===> ===> N (Y/N) PROGRAM NDY DSG 2 ACTION OPTIONS: CCID COPYBACK OVERRIDE SIGNOUT PROCESSOR GROUP 1 - UNIT ===> ===> N (Y/N) ===> N (Y/N) ===>
2 - PROGRAM
LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ BUILD USING MAP
Figure 22: Generate Elements Panel Simply specify which element to generate, and provide a CCID and comment. To change the processor group - e.g. to regenerate an element that previously was debugged with Xpediter to remove the Xpediter support - specify the new processor group. For elements signed out, you cannot generate them if they are not signed out to you, unless you have override signout authority. The 'Copyback' option in Generate is a specific feature to enable you to generate an element in the current environment from further up the lifecycle without having to go and retrieve that element and add it in - i.e. it is a shortcut. In conjunction with the list option and 'Build Using Map', generate with copyback will list all the elements up the lifecycle and allow you to generate back the one you want. It will take the element from the location you specify and place it into the current environment and stage, and generate it, signing it out to you. (4) MOVING ELEMENTS
When development work on elements in the current stage is complete, they can be moved up the lifecycle. Note that elements can not be moved out of stage 1 into stage 2 until they have been successfully generated - you cannot promote, for example, a COBOL II program that does not compile. The MOVE panel is fairly straightforward, and looks like this:
Page 40
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
-------------------------------- MOVE ELEMENTS -------------------------------OPTION ===> ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History O - Move element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE 1 COMMENT ===> ===> ===> ===> ===> ===> UNIT PROGRAM NDY DSG COBOLII 1 2 - PROGRAM ACTION OPTIONS: CCID SYNC WITH HISTORY RETAIN SIGNOUT SIGNOUT TO ACKNOWLEDGE ELM JUMP DELETE 'FROM' ELEMENT ===> ===> ===> ===> ===> ===> ===> TESTCBACK N (Y/N) N (Y/N) N (Y/N) N (Y/N) Y (Y/N)
===> TEST COPYBACK LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ BUILD USING MAP ===> Y (Y/N) ===> ===> ===> Y (Y/N)
Figure 23: Move Elements Panel You specify the location of the element to be moved, and the usual options such as CCID and comment. You can also opt to retain signout as you move up the lifecycle, or automatically sign out to someone else (if your handover procedures required). Note that there is only a FROM element area - you do not specify where the element is moved TO, because that is pre-defined by the lifecycle map: stage 1s move to stage 2, and stage 2s move up the lifecycle. Three options of interest are 'With History', 'Sync' and 'Acknowledge Element Jump'. The impact of these is specified in section 4.4. Most of the time, these will all be set to N. However, if you wish to move all the lengthy history with the element, or force a sync or a jump, specify Y. Moving a source element will also move all of the relevant output members. So if you move, say, a COBOL II program, the base & deltas will be moved, as will the output object member and/or load member, and last compile listing. Because of this, there is no need to regenerate everything after the move, because all of the outputs have moved too. (5) DELETING ELEMENTS
Changes or releases may be cancelled. Code can be rewritten and made obsolete. When that happens, Endevor should be tidied up so that the input & output libraries are not containing misleading or out of date information. Use the delete action to clear down Endevor systems. The delete action screen looks like this:
1.0a (First Draft)
Barclays Bank PLC
Page 41
Endevor User Guide
------------------------------- DELETE ELEMENTS ------------------------------OPTION ===> ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History # - Delete element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE COMMENT ===> ===> ===> ===> ===> ===> ===> PROGRAM RFY RISK * 1 ACTION OPTIONS: CCID ===> OVERRIDE SIGNOUT ===> N (Y/N) ONLY COMPONENT ===> N (Y/N) 1 - UNIT 2 - PROGRAM
LIST OPTIONS: DISPLAY LIST ===> Y (Y/N) WHERE CCID EQ ===> WHERE PROC GRP EQ ===>
Figure 24: Delete Elements Panel By now this panel should be self-explanatory! Enter the delete details, a CCID and comment, # to delete and hit ENTER. Elements signed out to other users will not be deleted - unless you specify Override signout = Y (but you need the appropriate authority to be able to do that). 'Only component' refers to deleting only the Endevor component list, not the element itself. This option should always be N. If you get a list of elements up, use # as the line command to delete only those you want to remove. (6) PRINTING ELEMENTS
Printing elements or history is not possible in foreground working in Endevor; instead, print requests are queued and submitted for processing when you exit Endevor. In this way, you can raise multiple print requests in an Endevor session, and then submit them all in one print job at the end. To issue print requests, use the following screen:
Page 42
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
-----------------------------OPTION ===>
PRINT ELEMENTS
------------------------------H - History
ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse P - Print element M - Master C - Changes PC - Print changes only PS - Print element summary PM - Print master information PH - Print change history FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE ===> LIVE ===> NDY ===> DSG ===> ===> ===>
1 - EMER
2 - LIVE
LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ BUILD USING MAP
===> Y (Y/N) ===> ===> ===> N (Y/N)
Figure 25: Print Elements Panel You have the option to print either the element contents, or the MCF information available from the display functions previously described. To do different options against different members, bring the list up (blank command on this panel) and then key P, PC, PS, PM or PH as appropriate against the members you choose. Print requests are written to a temporary dataset and actioned when you exit Endevor, via the following screen:
----------------OPTION ===> J ENDEVOR FOREGROUND PRINT REQUEST OPTIONS ------------------
J - Submit job to execute (and delete) foreground PRINT requests D - Delete PRINT requests (and do not perform PRINT actions) K - Keep PRINT requests
PRINT OPTION: SYSOUT CLASS
===> X
JOB STATEMENT INFORMATION: ===> //JOBNAME JOB (ACCOUNT) ===> //* ===> //* ===> //*
Figure 26: Print Request Panel You have the option to either submit the requests (ensure your jobcard information is correct!), or delete the requests without actioning, or keep them (in which case the temporary dataset will remain when you exit Endevor for you to process in your own time).
Endevor User Guide
(7)
SIGNING-IN ELEMENTS
If an element has been signed out to you, but you no longer require that signout, nobody else can obtain the element to work on it until you remove the sign out. If you do not need to change the element (i.e. there is no point adding it back in), then simply sign the element in to remove the sign out details. Use the following screen to achieve this:
------------------------------ SIGNIN ELEMENTS -------------------------------OPTION ===> ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History SI - Sign-in element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE ===> PROGRAM ===> NDY ===> DSG ===> ===> ===> ACTION OPTIONS: OVERRIDE SIGNOUT ===> N (Y/N) SIGNOUT TO ===>
1 - UNIT
2 - PROGRAM
LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ WHERE USER EQ BUILD USING MAP
===> Y (Y/N) ===> ===> ===> NDYGBH ===> N (Y/N)
Figure 27: Sign in Element Panel As for all the other foreground panels, enter the element details (or blanks or wildcards for a list), and use the SI command to sign the element in. If you have override signout authority, you can use this panel to sign in an element signed out to another user. This could be useful where, for example, that individual has left the Bank leaving active sign outs. 8.2 USING ENDEVOR IN BATCH
8.2.1 WHY USE BATCH? Processing a few elements in foreground is acceptable, but to process 10s or hundreds of elements it is advisable to use the batch Endevor interface. The batch interface is faster than working in foreground, and uses less storage - you may find that generating very large programs in foreground means your TSO region runs out of storage and you need to generate in batch, even for one element. Creating a batch job to process elements also allows that job to be submitted again and again without needing to re-specify panel information.
Page 44
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
8.2.2 ACCESSING & INVOKING BATCH OPTIONS To access the batch options, select option 3 from the Endevor Primary Options menu. You will be presented with the following screen:
BATCH ----------------------OPTION ===> 1 2 3 4 5 BUILD SCL EDIT SUBMIT VALIDATE BUILD JCL BATCH OPTIONS MENU ---------------------------
Build batch SCL actions Edit request data set Submit job for batch processing Check request data set for syntax errors Enter additional JCL to be included with the job APPEND ===> N (Y/N) INCLUDE JCL ===> N (Y/N) <<< THIS FIELD IS FOR SCL ONLY
REQUEST DATA SET: PROJECT ===> NDYGBH GROUP ===> MASTER TYPE ===> JCL MEMBER ===>
OTHER PARTITIONED OR SEQUENTIAL DATA SET: DSNAME ===> JOB STATEMENT INFORMATION: ===> //NDYGBHH JOB (0),'GARY HAYNES',CLASS=E, ===> // MSGCLASS=X,NOTIFY=NDYGBH,TIME=1440 ===> /*JOBPARM LINES=9999 ===> //*
Figure 28: Batch Options Menu The five options are to: Build SCL by using the online panels to generate SCL statements to the specified ISPF request dataset Edit SCL direct, or edit the results of option 1 to further specify SCL statements Submit the job using the jobcard information at the bottom of the screen and the SCL request dataset Before submission, on-line validate the SCL generated or entered to ensure it is valid SCL Build additional JCL into the job (e.g. for DD cards).
SCL can be coded outside Endevor, and when embedded within a job can be run (submitted) outside Endevor also. This batch option menu is provided as a 'quick start' to running batch Endevor jobs. To build batch SCL request, enter a member name in the request data set and select option 1. The following screen appears:
1.0a (First Draft)
Barclays Bank PLC
Page 45
Endevor User Guide
------------------------------OPTION ===> 1 2 3 4 5 6 7 8 9 10 11 12 13 DISPLAY ADD/UPDATE RETRIEVE GENERATE MOVE DELETE PRINT ELEMENT SIGNIN TRANSFER PRINT MEMBER LIST ELEMENT LIST MEMBER ARCHIVE -
SCL GENERATION
------------------------------
Display an element Add or update an element into stage 1 Retrieve or copy an element Execute the Generate Processor for this element Move an element to the next inventory location Delete an element Print elements, changes and detail change history Explicitly sign-in an element Transfer elements between two ENDEVOR locations Print a compressed listing or member Create List actions for ENDEVOR elements Create List actions for external members Archive elements
REQUEST DATA SET: NDYGBH.MASTER.JCL(USERGUID) APPEND: N
Figure 29: SCL Generation Panel This is similar to the foreground options menu, because it is granting access to the same sort of actions but in batch rather than foreground. Note that the name of the request dataset is given at the bottom of the screen; append is N because I opted on the previous screen not to append SCL requests to this member. If I selected Append = Y on the Batch Options panel, I can repeatedly write SCL requests to the same dataset. Select the action type you want to process. As an example, let us RETRIEVE an element to an external dataset using a batch request. So from this menu, we select option 3 (retrieve):
------------------------------ RETRIEVE ELEMENTS -----------------------------OPTION ===> r ELEMENT DISPLAY OPTIONS: blank - Element list S - Summary B - Browse H - History R - Retrieve element M - Master C - Changes FROM ENDEVOR: ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE COMMENT ===> ===> ===> ===> ===> ===> ===> ACTION OPTIONS: LIVE CCID ===> NDY EXPAND INCLUDES ===> DSG SIGNOUT ELEMENT ===> SYNCTEST OVERRIDE SIGNOUT ===> COBOLII REPLACE MEMBER ===> 2 1 - UNIT 2 - PROGRAM Test Batch retrieve for the user guide userguide N (Y/N) Y (Y/N) N (Y/N) N (Y/N)
TO ISPF LIBRARY: PROJECT ===> NDYGBH LIBRARY ===> COBOL TYPE ===> SOURCE MEMBER ===>
LIST OPTIONS: DISPLAY LIST WHERE CCID EQ WHERE PROC GRP EQ BUILD USING MAP FIRST FOUND TO OTHER PARTITIONED OR SEQUENTIAL DATA SET: DATA SET NAME ===>
===> Y (Y/N) ===> ===> ===> N (Y/N) ===> Y (Y/N)
Figure 30: Retrieve Elements Panel This panel is identical to the foreground retrieve panel!
Endevor User Guide
However, when building batch requests, information you enter here is used to write an SCL request, and not processed immediately. Only when you submit the batch job will the retrieve take place. In this example, I am asking to retrieve element SYNCTEST of type COBOL II to my COBOL.SOURCE dataset. If I specify no member name, it will be given the same name as the element. When I hit ENTER, Endevor tells me the SCL request has been generated. I then PF3 back to the Batch Options menu, and select 2 - Edit, to get the following SCL:
RETRIEVE ELEMENT 'SYNCTEST' VERSION 01 LEVEL 10 FROM ENVIRONMENT 'LIVE' SYSTEM 'NDY' SUBSYSTEM 'DSG' TYPE 'COBOLII' STAGE 2 TO DSNAME 'NDYGBH.COBOL.SOURCE' OPTIONS CCID 'USERGUIDE' COMMENTS "TEST BATCH RETRIEVE FOR THE USER GUIDE" NOSEARCH
. This is the batch SCL request. If I submit this via option 3, the job will run and RETRIEVE element SYNCTEST to the above library, signing it out to me with an appropriate CCID and comment. Because Batch processing is faster than foreground processing, I would probably use this to retrieve / add / delete / move a number of elements at a time. For example, if I wanted to retrieve all the COBOLII code in my project to my dataset, I would not do that in foreground. I would instead code a piece of SCL similar to:
RETRIEVE ELEMENT '*' FROM ENVIRONMENT 'LIVE' SYSTEM 'NDY' SUBSYSTEM 'DSG' TYPE 'COBOLII' STAGE 2 TO DSNAME 'NDYGBH.COBOL.SOURCE' OPTIONS CCID 'USERGUIDE' COMMENTS "TEST BATCH RETRIEVE FOR THE USER GUIDE" NOSEARCH
. In this example, I am retrieving all elements (ELEMENT '*') to my library. Any number of SCL requests can be placed in the request file, separated by a '.'. Endevor will process them in sequence and report on each command. 8.2.3 INTERPRETING BATCH RESULTS When the job has been submitted and has executed, you must check the results. Do this via the standard TSO SDSF utility. In the job output, two parts are of particular interest: C1MSGS1: this is the work area for Endevor, where each SCL action is parsed and executed, with all appropriate information produced C1MSGS2: this is a summary section added when the job completes, listing all the return codes.
For the above simple RETRIEVE action for one element, my job output (in SDSF) breaks down as follows:
1.0a (First Draft)
Barclays Bank PLC
Page 47
Endevor User Guide
DDNAME JESMSGLG JESJCL JESYSMSG C1MSGS1 C1MSGS2
STEPNAME PROCSTEP DSID OWNER JES2 2 NDYGBH JES2 3 NDYGBH JES2 4 NDYGBH NDVRBAT 103 NDYGBH NDVRBAT 104 NDYGBH
C X X X X X
DEST LOCAL LOCAL LOCAL LOCAL LOCAL
REC-CNT PAGE 14 41 90 39 8
C1MSGS1 contains the following information:

E N D E V O R S Y N T A X REQUESTED BY: NDYGBHH 14:19:38 C1Y0015I R E Q U E S T
STARTING PARSE OF REQUEST CARDS
STATEMENT #1 RETRIEVE ELEMENT 'SYNCTEST' VERSION 01 LEVEL 10 FROM ENVIRONMENT 'LIVE' SYSTEM 'NDY' SUBSYSTEM 'DSG' TYPE 'COBOLII' STAGE 2 TO DSNAME 'NDYGBH.COBOL.SOURCE' OPTIONS CCID 'USERGUIDE' COMMENTS "TEST BATCH RETRIEVE FOR THE USER GUIDE" NOSEARCH . STATEMENT #2 EOF STATEMENT GENERATED 14:19:38 C1Y0016I REQUEST CARDS SUCCESSFULLY PARSED
i.e. a repeat of the SCL request and a message saying it has been successfully parsed. The execution then follows immediately:
14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 14:19:40 ACTION #1 / STMT #1 RETRIEVE ELEMENT SYNCTEST VERSION 01 LEVEL 10 FROM ENVIRONMENT: LIVE SYSTEM: NDY SUBSYSTEM: TO DSNAME: NDYGBH.COBOL.SOURCE OPTIONS: NOSEARCH CCID: USERGUIDE COMMENT: TEST BATCH RETRIEVE FOR THE USER GUIDE NOT RETRIEVED - NO REPLACE SPECIFIED AND SYNCTEST WAS FOUND IN NDYGBH.COBOL.SOURCE C1G0277E RETRIEVE PROCESSING TERMINATED BECAUSE OF THE PREVIOUS ERROR C1G0200I REQUEST PROCESSING COMPLETED, HIGHEST RC WAS 0012 END OF JOB. HIGHEST ENDEVOR RC = 0012 C1G0202I C1G0203I C1G0211I C1G0204I C1G0205I C1G0232I C1G0232I C1G0232I C1G0126E
You can see that my request failed, because I did not specify REPLACE MEMBER on the retrieve panel and SYNCTEST already existed in my ISPF library. I got a return code of 0012. This is summarised in the C1MSGS2 as follows:
E N D E V O R A C T I O N REQUESTED BY: NDYGBHH S U M M A R Y
*FAILED*
ACTION RETRIEVE
ELEMENT SYNCTEST
PROC RC
NDVR RC 0012
+-------------- FROM ENVIRONMENT SYSTEM LIVE NDY
INFORMATION SUBSYSTEM DSG
Page 48
Barclays Bank PLC
1.0a (First Draft)
Endevor User Guide
This tells us in summary form that the request failed. If there are multiple SCL requests in the input dataset, there is a line in C1MSGS2 for each of the requests, listing what the request was and its associated return code. Any statements which fail are flagged with *FAILED* in column 1. 8.2.4 BATCH PROCESSING SUMMARY The Endevor batch interface is powerful and performs better than the foreground interface. However, specifying batch jobs and SCL can be daunting at first, whereas it is easier to get up and running using the foreground panels. There are many things that can only be done in batch. For example, you can list all elements
WHERE GENERATE FAILED
which will only show you any elements where the generate process did not complete successfully. This in conjunction with a COBOL II type will list all compile failures. You cannot do this easily in foreground. If you require any assistance in processing batch SCL requests, contact the Endevor support team. 8.3 ENDEVOR REPORTS Endevor provides a number of standard reports. These are accessible via the User option (U) on the Endevor Primary Option menu, followed by Option 1 - reports. The reporting interface works by generating a batch job for the request, then submitting this. Output can be checked as described in the section on using Endevor in batch. The following screen is presented:
------------------------- ENDEVOR REPORTING INTERFACE ------------------------OPTION ===> 1 2 3 4 5 6 7 E S MASTER SMF PACKAGE FOOTPRINT UNLOAD SHIPMENTS COLLECTIONS EDIT SUBMIT Build Build Build Build Build Build Build Master Control File report JCL SMF historical report JCL Package report JCL Footprint report JCL Unload/Reload report JCL Package Shipment report JCL Product Collection report JCL
- Edit Report JCL - Submit Report JCL for Batch execution
Job statement information: ===> ===> ===> ===> //NDYGBHI JOB (0),'GARY HAYNES',CLASS=E, // MSGCLASS=X,NOTIFY=NDYGBH,TIME=1440 /*JOBPARM LINES=9999 //*
Figure 31: Reporting Interface Panel
1.0a (First Draft)
Barclays Bank PLC
Page 49
Endevor User Guide
Only option 1 - Master is generally available. Selecting it gives the following reports:
SELECT _ 01 _ 02 _ 03 _ 04 _ 05 _ 06 REPORTS: System inventory profile System inventory summary Element catalog Element activity profile Element activity summary Element catalog by CCID FROM ENDEVOR/MVS ENVIRONMENT SYSTEM SUBSYSTEM ELEMENT TYPE STAGE DAYS SEARCH ENVIRONMENT MAP ===> ===> ===> ===> ===> ===> _ _ _ _ _ _ 07 08 09 10 11 12 System definition profile Element signed out profile - by system Element signed out profile - by user Approver group definition Approver group usage Element catalog by retrieve CCID
LIVE NDY DSG * COBOLII 2
===> 365 ===> N (Y/N)
Figure 32: Report Selection Panel Specify in the "From Endevor" fields which environment / system / subsystem / element / type / stage combination you wish to report on. The DAYS field is relevant only for some report types, it specifies how far back to look. The Search Map option is useful for reporting on element information up the lifecycle. The report types are outlined briefly as follows: System inventory profile: lists elements in a system, giving their name, current version and base / generate dates and userids, with the whole report broken down by type / stage / subsystem / system and environment. One line of detail per element, sorted by system, subsystem, type and stage System inventory summary: a summary of the above report, listing only how many elements per type combination, and the number of statements for that type, sorted by system, subsystem, type and stage Element catalog: gives element details, including their type, processor group, base, current version and generate dates and userids, sorted by element name, system, subsystem, type and stage Element activity profile: details the element actions within the period defined in the DAYS field. For each action, lists the element and gives the action details: what was done to what, when and by whom, and what the return code and CCID were; sorted by system, subsystem, type, stage and element Element Activity Summary: a summary of the above report, again summarising actions within the period defined by the DAYS field. The number of MOVES, RETRIEVEs. etc are summarised, sorted by system, subsystem, type & stage
Barclays Bank PLC 1.0a (First Draft)
Page 50
Endevor User Guide
Element catalog by CCID: gives standard element information (similar to the element catalog 03 report), but ordered & grouped by CCID (can be useful for seeing what elements are grouped under a tagged change identifier) System Definition Profile: detailed breakdown of the system configuration, types & processor groups supported. Of no real interest to Endevor end users Element Signed Out Profile - by system: lists element details for all elements currently signed out, including who signed them out and when and what CCID was associated with the sign out; the report is sorted by system, subsystem, type, stage and element name Element Signed Out Profile - by user: similar to the above report, but groups the results by userid Approver Group Definition / Usage: administrator interest only Element Catalog by Retrieve CCID: similar to element catalog by CCID, but only for RETRIEVEs to see who has retrieved code, from where, and when.
These are 'canned' reports, which means they can be run very easily and quickly without any special JCL - just a standard job card. View the output in SDSF as you would any other job.
1.0a (First Draft)
Barclays Bank PLC
Page 51
Endevor User Guide
SUMMARY
Endevor is a very powerful product that offers Barclays a consistency of control over application development with the security of in-depth auditability. Footprinting of all Endevor-produced outputs means that any live program can be tracked exactly back to the source used to produce it, thus enhancing live support. Its powerful SCL interface enables productive management of hundreds or thousands of source elements in a secure, controlled environment. Because there is such power available, however, some users may find the product initially daunting. The guide can be used to get a Quick Start on Endevor. For further assistance, please call the Endevor Support Team.
Page 52
Barclays Bank PLC
1.0a (First Draft)

Endevor User Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Endevor User Guide

Hochgeladen von

Copyright:

Verfügbare Formate

BARCLAYS BANK PLC RETAIL FINANCIAL SERVICES

RETAIL OPERATIONS MAINFRAME TOOLS SUPPORT