This is actually an amalgamation of two related topics.
Another common implementation that I have seen is the over-utilization of the MONITOR=COMPONENTS ability in processors that create Load modules.
In a previous blog on “Composite Load Module Creation”, I have detailed at length the effect over-utilization of the facility can have on Endevor performance. This section has merely been inserted to draw attention to the issue once again; do not place MONITOR=COMPONENTS on every library being included in a linkedit. It is wisest to monitor only those libraries that are relevant to your actual applications. Unless it is relevant to have a detailed inventory of all the COBOL support routines that are included in your IBM compiles, I highly recommend NOT monitoring those libraries!
And believe it or not, Endevor can be very forgiving of coding errors in its processors. Consider the following processor…
//DLOAD01S PROC SYSA=DUMMY, // UNIT=VIO //S10 EXEC PGM=IEBGENER //SYSUT1 DD DSN=MY.LIB.LIB1, // DISP=SHR //SYSUT2 DD DSN=&&TEMP1, // DISP=(NEW,PASS) //SYSPRINT DD &SYSA //SYSIN DD DUMMY //* : :
In this example, my definition for the temporary dataset name &&TEMP1 is incomplete; I have not specified any other attributes of the file other than it is new and it should be passed. Endevor will execute this processor correctly; in other words, it will not abend. Instead, Endevor will make assumptions regarding the dataset and attempt to resolve the problems, usually quite correctly.
However, the problem you may run into is mysterious page-outs occurring on your Endevor jobs. Endevor batch jobs will page-out during execution and likely never page back in again. This typically results in your Operations area canceling your job (which is reflected in your JES log as an S522 abend).
This occurs because of the manner in which Endevor enqueues and dequeues datasets for read and write. Since the information supplied in the processor is incomplete, Endevor must make some assumptions based on a finite set of rules. If, for some reason, it must make those assumptions again for a related, or even unrelated circumstance, then it is possible it will put itself into a “deadly embrace”.
The fix to this problem is simple. Just remember to code your processors correctly with all values present.
//DLOAD01S PROC SYSA=DUMMY, // UNIT=VIO //S10 EXEC PGM=IEBGENER //SYSUT1 DD DSN=MY.LIB.LIB1, // DISP=SHR //SYSUT2 DD DSN=&&TEMP1, // DISP=(NEW,PASS), // UNIT=&UNIT, // SPACE=(TRK,(1,1),RLSE), // DCB=(LRECL=80,BLKSIZE=6160,RECFM=FB) //SYSPRINT DD &SYSA //SYSIN DD DUMMY //* : :