API program abended on S0C1 after changes

Products

• Endevor

Issue/Introduction

A user written API program that calls endevor API started abending with S0C1 and the PSW pointing to low core (address X'00000002') after upgrading to a new endevor release and recompiling the program as recommended.

Environment

Release : all

Component : Endevor Software Change Manager

Cause

The S0C1 abend is caused by a wild branch to address zero. In this case it's happening when the API program is trying to call endevor API stub (subroutine ENA$NDVR) which, in this case, needs to be statically linked into the API program.  The subroutine is missing from the module which results in the wild branch.  

This is a sample of the API code(Assembler) that asks for a Static call: (Note the program can be Dynamically called or Statically called)

L   R15,=V(ENA$NDVR)
BALR R14,R15                     CALL SERVER THRU ENA$NDVR 

The API program was recompiled (as we recommend) but the binder could not find ENA$NDVR stub when building the load module. This resulted in an unresolved external reference (and a nonzero RC from the binder) which caused the S0C1 at runtime.

Resolution

Recompile and Link the API program. Ensure the Link(Binder) step has the Endevor distributed CSIQAUTH and CSIQLOAD in the SYSLIB DD and that option CALL is specified to the binder (or that option NCAL is NOT specified). This will allow the link to include the statically called program. In this case ENA$NDVR.

Another option is to change the API program so that it dynamically loads and calls ENA$NDVR from STEPLIB DD, which uses to be the default behavior in high-level languages like COBOL.

Additional Information

Adding option XREF to the JCL parm produces a cross-reference report. Symbol ENA$NDVR must NOT show up as UNRESOLVED in that report.

It is strongly recommended that the compile and link(Binder) listings be checked. Even without option XREF, the unresolved external reference raises a warning message in the binder report.