Troubleshooting issues with ALLOC=LMAP/PMAP in Endevor

Products

• Endevor

Issue/Introduction

This article provides guidelines to troubleshoot unexpected behavior of ALLOC=LMAP or ALLOC=PMAP in an endevor processor

Cause

Resolution

ALLOC=LMAP and ALLOC=PMAP are processed at runtime during preparation of the processor to be executed. When a particular DD specifies this option, Endevor checks the inventory map and creates additional DD statement blocks, one for each stage to be added to the allocation. These additional DD's are dynamically allocated while preparing the execution of the processor step

The Endevor dynamic allocation trace shows whether a particular allocation is being done under the control of ALLOC=LMAP. It is triggered by adding ddname EN$TRALC:

• In batch, add //EN$TRALC DD SYSOUT=* to the JCL step (the one that runs NDVRC1, not the processor step)
• In foreground, issue command TSO ALLOC FI(EN$TRALC) SYSOUT(X) before starting the Endevor dialog

EN$TRALC trace adds messages to C1MSGS1 DD which allows to identify the processor step to which each allocation belongs.

For example, you may have the following entries in the trace:

C1T0001I  DYNAMIC ALLOCATION TRACE - REQUEST = ALLOCATION       (LMAP 01)  : C1GPALLO C1GPALLO +0692            
C1T0002I      0001 0001  0008 ENXINC01                                                                          
C1T0002I      0002 0001  001F ENDV.DEV.GRPFACTS.CICS66.MAPLIB 
....
C1T0001I  DYNAMIC ALLOCATION TRACE - REQUEST = ALLOCATION       (LMAP 02)  : C1GPALLO C1GPALLO +0692            
C1T0002I      0002 0001  0020 ENDV.TEST.GRPFACTS.CICS66.MAPLIB                                                  
.....

The caption LMAP XX shows that ALLOC=LMAP is taking place and also the DSN's show how the datasets are resolved for each stage

The IMR trace (Inventory Management Routines) may be used to 'see' how Endevor search for each additional stage during LMAP processing. It is triggered by adding ddname EN$TRIMR and prints to ddname BSTERR, if it is alliocated. If BSTERR is not allocated, it prints to JESMSGLG

The entries in the IMR trace showing ALLOC=LMAP processing are similar to:

 08:45:27.8952 $IMR  C1GPPMRG MAPRUTN +003F9A  $IMR QUERY  MAP          DEV      1   
     0000.0000 $IMR  RC=0000 RSN=0000          $IMR QUERY  MAP          DEV      1    

What is meaningful is the caption C1GPPMRG MAPRUTN. This is the routine that scans the environment looking for new stages. In the above example, it has found stage 1 in environment DEV. These entries show that, at least, Endevor is trying to resolve ALLOC=LMAP and that you should see entries with caption LMAP NN in the EN$TRALC trace

If Endevor is not even trying, then you need to examine the processor assembly listing to see how ALLOC=LMAP resolves

Given a DD like this one:

           08:07:49  C1X0240I     21  //ENXINC01 DD DSN=&#C01&C1SY,DISP=SHR,   
           08:07:49  C1X0240I         //                     MONITOR=COMPONENTS,ALLOC=LMAP     

The assembly listing should contain

-                                   5288          $PRDDA DDNAME=ENXINC01
-                                   5325          $PRDDB DSNAME=&&#C01&&C1SY,                                   *  
                                                        DISP1=SHR,                                              *   
                                                        CONFIG=COMPONENTS,                                      *  
                                                        ALLOC1=LMAP                                                   

And, most importantly, it must assemble correctly without errors.

If the above $PRDDB macro fails with an error like

 ** ASMA017W UNDEFINED KEYWORD PARAMETER; DEFAULT TO POSITIONAL, INCLUDING KEYWORD - $PRDD/ALLOC1 
 ** ASMA435I RECORD 199 IN SYS4.TST1.ENDVR18.CSIQOPTN($PRDDB) ON VOLUME: MVT5AA      

Then the error is probably caused by parameter MACDSN= in C1DEFLTS TYPE=MAIN pointing to an outdated CSIQOPTN library. This library is allocated to SYSLIB DD during processor assembly and, if it is outdated, the invoked macros may not support the parameters generated during the translate processing

What is problematic is that the assembly error is a warning and does not cause the generation of the processor to fail. The error might not be noticed and, because of that, all the $PRDDB macros will lose the specification of ALLOC1 and none of the ALLOC=LMAP specifications in the processor will work.