Endevor

I was asked a question today that gave me pause for thought: What do I think (believe) are the top 10 Endevor features or functions?

I thought I'd ask the ENDEVOR community that question.... I appreciate it's somewhat subjective and a case of personal opinion, but I'd be curious all the same.

I'll start with one John, I'll add more.

The versioning of source code in all the Endevor environments. We kind of forget about this, because Endevor does an awesome job with it.  Developers, managers, auditors and other authorized people can view/retrieve the current or prior versions of source code as required.

'Endevor Processors' - Having the 'build' processes built into your SCM toolset.

Add on to this footprinting and component monitoring.

Packages, a simple yet potentially complex area, built into one of our instances so the magic of packages for production releases is hidden from the "application team", automatic create/cast/execute and ship. You have continuous Delivery and Deployment with this one feature.

With Edwards Processor and Phils SCM comments, you have Continuous Integration, 20 years before DevOps was a buzzword.

Some bits of packages are great like component validation, some bits I feel are a now little dated (like ship). 

Ship is very under developed, meaning that it has not evolved much. There is far too much jumping from batch job to batch job, to do one simple element distribution.

Versioning especially within Quickedit, this is a major like from our customers being able to use like TSO.

The monitoring of components is for sure high up on the list.  Being able to "BX" an element and find all the includes, copybooks, macros, dclgens, subroutines, etc. that were used at compile and link time is a great product feature.

I would rate top 10 features of the product as

1] Delta formats and Maintaining different versions of code.

2] Footprint information

3] BX for troubleshooting purpose, Very Useful.

4] Longnames Panel & QE functionality

5] Interface with other tools like C:D and inbuilt tools

6] Processors & Packaging

7] Shipment

8] Backup mechanism

9] ACMQ & Reports[For investigation]

10] Last but not least adaptability to new API's and technologies.

This a vote for the processors, the ACM input/output component tracking (CONRELE utility and WHERE USED query), and the global type sequencing. These enable us to verify that dependencies between different types of program elements are met prior to deploying programs to production.

For example, we utilize BMC Integrated Operations Architecture (IOA) INCONTROL Products, including Control-M, and AutoEdit facility terms (variables, conditionals, functions) are coded in JCL. The AutoEdit variables coded in the JCL need to be properly defined to that JCL, otherwise the JCL will fail to execute. Some of the AutoEdit variables may be defined in the Control-M schedule for that JCL. We want to resolve all of the AutoEdit variables in te JCL prior to executing CA JCLCHECK. We do not want to wait until production to discover that an AutoEdit variable was not properly defined, or that the JCL has a syntax error. To avoid that we do the following:

An IOA KeyStroke Language (KSL) program step is executed in a processor for the Control-M tables that identifies which JCL are executed by the schedules in that Control-M table (disregarding dummy schedules). This information is passed to a CONRELE step to save a list of those JCL as input components. IOA has an AutoEdit simulation utility that resolves the AutoEdit variables in JCL. This utility can be executed in schedule mode to retrieve the AutoEdit definitions found in the JCL's schedule, provided that schedule table and its library are identified to the utility. Our JCL processor executes a WHERE USED query to identify the name of the JCL's schedule table and its library. If the query finds a schedule table then another step reads the results of the WHERE USED query and passes this information to the IOA AutoEdit simulation utility to ensure that all of the AutoEdit variables, including those defined in the schedule for that JCL, are resolved.

Just from the top of my head and without weighting:

 
    Feature/Functionality    /* some explanatory Endevor-Terms */
1.    Implementation of a time-related, functional and technical structure in the software-elements    /* Element-Key */
2.    Implementation of a software-life-cycle from development to production    /* Map, Signout */
3.    Enforced consistency between source and from the source derived components    /* Processors, Security, Audit */
4.    Automated creation and maintaining of software-derived components     /* Processors */
5.    Source-levels for history of all element-contents in the time-line of each element.    /* Element-Version and -Level, Browse History */
6.    Relationship between software-elements (maintaining, analyzing)    /* Monitor=Components, ACM-Query */
7.    Grouping of software-element(action)s to represent software-releases
    /* Endevor-Package, CCID, */
8.    Approvement (“***-eyes-principle”) of software-changes in (near-)production environments    /* Inventory-Area, Endevor-Packages */
9.    Consolidated reporting und audit about software-changes in production  /*   (SMF-)Reports */
10.    Imbedding into global change procedures      /* Endevor-Webservices, Quickedit */

Hi John. In order of importance from my view. You will notice that I may have things that just never get stated as key important items. Since they have been there for so long, we tend to over look them. Plus I believe in controlling the inventory and being able to state "I know where everything is and where is came from, etc. That this is available to anyone."

1) FOOTPRINT. Which will always take you back 'home' to Endevor. Where the source is. No matter where the member is located. Whether a load, jcl, etc. Extremely key to audits. Which when running reports, you can see if there are exceptions, etc.

2) SMF recording. Which in combo of all the recording done in Endevor itself, pretty much covers the statement "No one can do anything in Endevor without an administrator knowing about it".

3) ACMQ and just component information in general. Plays a key role in many things. Package validation etc. But I think its best usage is for the developers to know what was brought together and from where when they compile their programs.

4) LISTINGS the LL option which would seem a standard thing by now. Where capturing the listing of a compile and/or link is noted in the component info and allows the LL option to work. A fantastic feature for the users and administrators when one has to review things. Instead of looking at the users job output or some other location. One doesn't miss it until its not available. Unfortunately my shop doesn't do this. Noticed it on day one when I came on board. Tried to have it addressed, but failed.  Instead they had us put them into DDIO files. Ugh. Why not both? Who knows.

5) PDM. Even though this is a companion tool, its very important and useful. Again, don't have it you miss it. As far as I know, its the only tool that works with Endevor. Three way compare, inside Endevor, outside libs or a combo. Then use the info to create a new combined body of code. My shop never turned it on, which I keep telling them they should.

6) CONTROL for consistence. Meaning the inventory structure and especially the processors. Ensuring what was used last month is the same now.

NOTE a drawback related to this. For administrators. Processors of course are versioned. But the inventory structure, especially processor group definitions, symbolic overrides, etc are NOT versioned. An issue we have mentioned over the years to be addressed.  We all have to use some sort of work around.

7) QUICKEDIT. Its name says it all.

8) SDLC via multi Endevor environments, stages via mapping etc. Allows for parallel development etc. If one has an administrator that 'thinks' out of the box. Endevor can be flexible in its configuration. This would include the 'sandbox' approach.

9) PACKAGE which of course allows for different methods of promoting changes through the SDLC.

10) ESI. Not normally mentioned, again you don't miss it unless not used. My shop uses a home grown thing. But really, ESI is much more flexible and maintainable.

Good luck.

Processors, versioning, monitoring, acmq.

It was tough to choose just ten, so here's my top 15

Top Ten

ESI

Versioning

Display Element w/Build Using Map

Environment Mapping

Extended Processors

Build SCL

ACMQ & Input Component Monitoring

Package Processing including Ship & Back Out

The CSV Utility

Unload / Reload

Top Fifteen includes:

Quick Edit - TSO / ISPF Edit capability

PDM

ALTER Base Comment / Module Description

Build Alias Load Module

CA Communities Support

I know it's been awhile since this was replied to but I was going through old emails and cleaning out my Ideation Folder when I realized I never replied to this. All of the input is really great and I agree with all listed. However one entry caught my eye which was about Code Deployment being underdeveloped. Since QE and ACM are in this list I have decided to chime in about two area of these tools that are underdeveloped.

QE - I know companies that will not implement QE because unlike Batch Add/Update QE does not invoke Exit 4. Some companies use Exit 4 to invoke JCLPREP or JOBSCAN or JCLNEAT to ensure standards are adhered to before allowing the JCL/PROCs to be added to Endevor. QE should invoke Exit 4. To me this is a flaw in the feature.

ACM - We are in the process of moving our Endevor code from our Production LPAR's to two Development Only LPAR's. During that process the naming convention for our Copybook, LOADLIBs and Listing Libs are changing. Therefore ACM does not work because the lib names in the ACM data does not match the new names and because of volume of modules we are not recompiling out 100k plus source modules. While the ALTER action changes metadata it only changes information in the MCF not the ACM files. I am sure we are not the only ones to experience this. ACM could stand some changes as well.