MainframeKit

-927

SQLSTATE 51006NEGATIVE SQLCODE

The program called Db2 without a Db2 connection environment: in TSO it was not run under DSN, or it was linked with the wrong language interface module.

MOST LIKELY

A batch step runs the program with EXEC PGM=... instead of through IKJEFT01 with DSN and RUN.

FIRST CHECK

In TSO or batch, run the program with DSN SYSTEM(...) and RUN PROGRAM(...) PLAN(...) under IKJEFT01.

TRY IT ▸

MainframeKit assistant

What it means

Every Db2 program talks to Db2 through a language interface module that matches where it runs. If that environment is not set up, the first SQL call fails with -927 and SQLSTATE 51006, and the statement is not run.

In TSO or batch TSO this means the program was started directly instead of under the DSN command's RUN subcommand. In CICS, IMS, CAF or RRSAF it means the program has the wrong interface module: DSNELI is for TSO, DSNCLI for CICS, DFSLI000 for IMS, DSNALI for CAF and DSNRLI for RRSAF.

Typical causes

  • A batch step runs the program with EXEC PGM=... instead of through IKJEFT01 with DSN and RUN.
  • A TSO user calls the program directly rather than under DSN.
  • The load module was link-edited with the interface module for a different environment.
  • The DYNAM compile option loads a different interface module at run time than intended.

How to fix it

  1. In TSO or batch, run the program with DSN SYSTEM(...) and RUN PROGRAM(...) PLAN(...) under IKJEFT01.
  2. Check the link-edit map for which interface module (DSNELI, DSNCLI, DFSLI000, DSNALI, DSNRLI) was included.
  3. Relink with the module that matches where the program runs.
  4. If DYNAM is used, check which interface module is found first in the load library concatenation.

Example

Illustrative only; names and values are invented.

//STEP01  EXEC PGM=IKJEFT01
//SYSTSIN DD *
  DSN SYSTEM(DBT1)
  RUN PROGRAM(ORDR0200) PLAN(ORDPLAN) LIB('TEST.ORDERS.LOADLIB')
  END