Endevor- Processors

Processors are the build engines of Endevor: programs (usually written in JCL) that produce outputs from elements. When you GENERATE a COBOL program, a generate processor compiles it and link-edits the load module. When you MOVE it, a move processor may copy outputs forward. Processors are why every build in Endevor is identical and repeatable.

Processors themselves are stored as Endevor elements of type PROCESS, so they enjoy the same versioning and promotion control as your code. Changing a processor is a controlled change - as it should be, since it affects every program it builds.

Processor types

• Generate processor - builds outputs from source: compile, link-edit, bind. Runs on GENERATE and on ADD/UPDATE with GENERATE 'Y'.
• Move processor - runs when an element is moved into a stage; typically copies or regenerates outputs in the target stage.
• Delete processor - runs when an element is deleted; cleans up generated outputs so stale load modules are not left behind.
• A type can have all three, or just a generate processor. Non-buildable types like JCL often have no processor at all.

Processor groups - which processor builds what

• A processor group maps element types to processors for one environment and stage. Example: in DEMO stage D, type COBOL uses processor COBGEN; type COPY uses no processor.
• The same type can use different processors in different stages: DEV may compile with TEST options, PROD with OPT and no test hooks.
• When you GENERATE, Endevor looks up your element's type in the processor group for that stage and runs the mapped processor.
• Processor groups are defined by the Endevor administrator. If GENERATE says "no processor", the group mapping is missing - that is an admin fix.

A real generate processor fragment

Processors are JCL with Endevor symbolic variables (the &C1... names) that Endevor fills in at run time. Here is a simplified COBOL generate processor:

• Endevor substitutes the symbolics before submitting: source library, load library, element name, and stage-specific datasets.
• The real shop processor is longer (footprint step, listing capture, return-code checks) but follows this exact shape.
• Never copy a processor and hand-edit the datasets - a wrong library in a processor corrupts every build it runs.

Symbolic variables Endevor provides

• &C1ELEMENT - element name. &C1TYPE - element type. &C1STAGEID - stage ID.
• &C1SYSTEM / &C1SUBSYS - system and subsystem. &C1ENVIRON - environment name.
• &C1USER - the user running the action. &C1CCID - the CCID given on the action.
• &C1SRC / &C1LOAD / &C1SYSLIB - site-defined dataset symbolics for source, load, and library concatenations.
• Symbolics can also come from the processor group definition and from data tables the administrator maintains.

Footprints - proof of a clean build

• When a generate processor link-edits, Endevor stamps a footprint into the load module: element name, level, date, time, and generating system.
• The footprint is also recorded in the Master Control File, so Endevor can compare the load module against its records.
• A footprint mismatch means the load module was changed outside Endevor (hand link-edit, or built from different source) - Endevor will refuse to promote it until regenerated.
• Footprints are your tamper evidence: auditors check that production load modules carry valid Endevor footprints.
• You can display a load module's footprint with the Endevor footprint utility - ask your administrator for the job.

What happens during GENERATE - step by step

1. You issue GENERATE for element PAYROLL1, type COBOL, stage D.
2. Endevor finds the processor group for DEMO / stage D and maps type COBOL to processor COBGEN.
3. Symbolics are resolved: source dataset, copy libraries, load library, element name, CCID, user.
4. The processor JCL is submitted as a job (or runs inline). Compile step runs IGYCRCTL; a bad return code stops the build.
5. Link-edit runs, the footprint is stamped into the load module, and outputs land in the stage's load library.
6. Endevor records the generate in the element's history: date, time, processor used, return code.
7. On MOVE to the next stage, the move processor regenerates or copies the outputs there with that stage's options.