C1I0007E REQUIRED USER PARAMETER IS MISSING FROM THE JOBCARD

Products

• Endevor

Issue/Introduction

Endevor initialization will fail with message C1I0007E REQUIRED USER PARAMETER IS MISSING FROM THE JOBCARD if:

• Running with BATCHID=1 in C1DEFLTS which, by the way, is the only value allowed starting at release 19.0, -AND-
• The job does NOT have an userid assigned

Cause

During initialization, if BATCHID is set to 1 in C1DEFLTS, Endevor uses the value from field ASXBUSER in the ASXB control block (which is the extension of ASCB, Address Space Control Block) to determine the 'endevor userid' to be used in the run. This userid is used, for example, for package approval processing. Endevor may not run if this userid cannot be determined.

Normally, MVS jobs have an userid assigned (and ASXBUSER field populated) at the start of the job. However, it might happen that some other program mistakenly clears the value before Endevor initializes. In this case, initialization would fail with message C1I0007E

Resolution

Ensure that the job is assigned an userid so that Endevor may be run.

If the job is assigned to an userid, but the message arises during Endevor initialization, then the following technique may be used to catch the program that clears the ASXBUSER field.

First, add a first step to the job with EXEC PGM=IEFBR14. This program is used as it is known to have its entry point at offset 0 which is used in the next step, but any program (even the current first step of the job) may be used as far as the offset of the main entry point in the program is known.

Then set two dependent PER slip traps via console commands

/SLIP SET,IF,ID=TRP1,J=jobname,PVTMOD=(IEFBR14,0),MODE=HOME,TARGETID=TRP2,A=TARGETID,END

/SLIP SET,SA,DISABLE,ID=TRP2,J=jobname,ASIDSA='jobname',RANGE=224?+6C?+C0,A=SYNCSVCD,END

In the first command, PVTMOD=(IEFBR14,0) may be adjusted if needed to specify the name of the first program executed by the job and the offset of its main entry point

These command define two PER SLIP traps. First one (TRP1) is enabled and the other (TRP2) is initially disabled

When job 'jobname' runs, trap TRP1 (of type 'instruction fetch) should match when the first instruction of IEFBR14 is executed. Then, by A=TARGETID, the SLIP trap processor will disable TRP1 and enable TRP2

Trap TRP2 is of type 'storage allocation' and sets monitoring into the address of ASXBUSER field for the address space where 'jobname' runs (identified by the ASIDSA parameter) by the time trap TRP1 matches. The address of ASXBUSER is dynamically specified in the RANGE parameter, where:

• 224 is the hex offset of field PSAAOLD in the PSA (which resides at address 0). This points to the ASCB for the address space
• Suffix '?' means 31-bit address, so '224?' means the 31-bit address pointed to by storage at absolute address X'224'
• ASCB+6C is field ASCBASXB, which points to the ASXB associated with the ASCB
• ASXB+C0 is field ASXBUSER, the storage to be monitored

By A=SYNCSVCD, the SLIP processor will capture an SVC dump while keeping the processing of the job stopped so the dump will contain an exact picture of the storage when field ASXBUSER is altered.

The captured SVC dump may then be examined with IPCS to determine who altered the storage and consequently report the issue to the programmer or to the involved vendor.

While examining the dump, the following may be used:

• IP STATUS CPU REGS will show the contents of the PSW and registers when the instruction that altered the storage was executed
• The system trace (IP SYSTRACE) will show a SPER entry reflecting the spot when the storage was altered. The PSW shows in fields Unique-4 and Unique-5 of the SPER entry
• Given the NSI (next sequential instruction) address in the PSW, command WHERE <address> (or IP WHERE <address>) gives the name and offset of the module to which the address belongs