Endevor initialization might fail with message ENVIRONMENT PATH LOOP FOUND, CONTAINING ENVIRONMENT xxxxxxx
For example:
ENVIRONMENT PATH LOOP FOUND, CONTAINING ENVIRONMENT PROD
ENVIRONMENT PATH LOOP FOUND, CONTAINING ENVIRONMENT PROD
ENVIRONMENT PATH LOOP FOUND, CONTAINING ENVIRONMENT TSTK
BC1PINIT FAILURE, RC=0008.
BC1PSM10: F000 ABEND CODE=INIT NUMBER=0001
Component: ENDBAS
This message arises normally because of an incorrect setup of the C1DEFLTS TYPE=ENVRNMNT macros coded in the Endevor defaults table.
If the C1DEFLTS table defines a GCF dataset (Global Control File) to define dynamic environments, any environment definitions contained in that file may also be involved in the situation
In the table, each TYPE=ENVRNMNT entry defines an Endevor environment. For each of them, the NEXTENV= parameter sets the next environment in the map route. Likewise, each environment defined in the GCF file designates its next environment. Altogether, the environment names with their NEXTENV specifications define the Endevor map.
The problem in this case is that NEXTENV= parameter for the environment whose name is noted in the message points to an environment which is behind it in the path, creating a path that loops which is not allowed in Endevor.
For example, if C1DEFLTS defines environments, ENV1, ENV2 and ENV3, it's correct to define a map like
ENV1->ENV2->ENV3
However, a map like
ENV1->ENV2->ENV3->ENV2
would raise this error since the map forms a loop from ENV3 to ENV2 to ENV3 and so on
If the C1DEFLTS table does not define a GCF dataset via parameter GCFDSN= it may be enough to examine the C1DEFLTS source statements to determine how it defines the map. The parameters of interest in the C1DEFLTS TYPE=ENVRNMNT macros are:
If a GCF dataset is used, then it's imperative to take an Endevor options report as it contains the environments defined in C1DEFLTS as well as those defined in the GCF. It is recommended to take the options report in any case as it clears the possibility of looking at the wrong C1DEFLTS source. Note that the options report, if enabled, prints even in case the Endevor initialization fails so it may be used in this case.
In a batch run, the endevor options report is taken by adding //EN$TROPT DD SYSOUT=*,SPIN=NO to the JCL
In foreground, issue command TSO ALLOC FI(EN$TROPT) SYSOUT(X) SPIN(NO), get into Endevor (just to display the first menu), get out and go to SDSF or equivalent. The report should be in EN$TROPT DD among the outputs of your TSO session.
In the options report, The GCF dataset name, if used, prints in field "Global Control File" in section "Control Data Sets"
The section ENVIRONMENT DEFINITIONS starts with a summary of the environments/stages and how they map. For example:
Env ------- Stage 1 ------- ------- Stage 2 ------- ---- Next ----
Name ID Name Entry Stage ID Name Entry Stage Env Stage
RWRK 1 RWRK1 Y 2 RWRK2 N WRK 2
WRK 1 WRK1 Y 2 WRK N DEV 1
DEV 1 UNITTEST Y 2 UTC N QA 2
QA 1 QAINT Y 2 QATURN N PRD 2
PRD 1 PRDFIX Y 2 PRD N
This summary includes static environments (from C1DEFLTS) and dynamic ones (from the GCF). It's followed by a detail of each environment, which indicates all its attributes, including whether it is a dynamic one.
The summary should allow to determine where is the loop and guess what needs to be changed to fix it. There are two possibilities
In this case, it is enough to fix the environment definitions in C1DEFLTS table
This would be more problematic since updating the definitions requires to run the ENBE1000 utility to perform DEFINE ENVIRONMENT or DELETE ENVIRONMENT actions, but the utility cannot be executed as Endevor cannot initialize. What could be done in this situation is:
Special care needs to be taken when defining environments in the C1DEFLTS table. Any loops in the map or duplicate environment names are NOT detected at assembly time. These errors are only detected during initialization and make Endevor unusable.