Db2 SQLCODE

SQLCODE -927: Language interface called without a connection

SQLCODE -927 (SQLSTATE 51006) means a program issued SQL through Db2's TSO language interface without a Db2 connection. Usually the job ran the program with EXEC PGM= instead of under the DSN command.

Also written as SQL -927, SQLCODE=-927, SQLCODE = -927, db2 -927, sqlstate 51006, language interface was called, DSNELI -927.

What it means

A program with SQL doesn't talk to Db2 directly. The precompiler turns each statement into a call to a language interface module that is link-edited with the program. Each attachment facility has its own module. DSNELI is the TSO attach, used for batch jobs run under the DSN command. DSNALI is the call attachment facility (CAF), DSNRLI is RRSAF, DSNCLI is CICS and DFSLI000 is IMS. DSNULI, the universal language interface, works out the environment at run time.

DSNELI expects the DSN command to have connected to Db2 and opened the plan already. If the program was started some other way, there's no connection, and the first SQL call fails with -927.

The SQL never reaches Db2, so binding again or checking grants won't help. Look at the JCL and the link-edit instead.

Common causes

  • The JCL runs the program directly with EXEC PGM=PAYCALC instead of EXEC PGM=IKJEFT01 with a DSN RUN command.
  • JCL was copied or rewritten and the DSN step was lost, while the program itself didn't change.
  • The main program has no SQL, so nobody thought of Db2, but a subprogram it calls does.
  • The program is meant to manage its own connection through CAF or RRSAF, but it was link-edited with DSNELI instead of DSNALI, DSNRLI or DSNULI.
  • A program written for batch under DSN is called from another environment, such as a started task, where the DSN command never ran.

How to find the problem

  1. Look at the EXEC statement of the failing step. If it runs the application program directly, that's the cause.
  2. If it runs IKJEFT01 or IKJEFT1B, check the SYSTSIN input. You should see DSN SYSTEM(ssid), then RUN PROGRAM(...) PLAN(...) LIB(...), then END.
  3. Check the binder (link-edit) listing for the module to see which language interface it includes.
  4. If the program calls subprograms, check whether any of them contain SQL.

How to fix it

  • Run the program under the TSO terminal monitor program with the DSN command. Use EXEC PGM=IKJEFT01 and put DSN SYSTEM(DB2P), RUN PROGRAM(PAYCALC) PLAN(PAYPLAN) LIB('PROD.PAYROLL.LOADLIB') and END in SYSTSIN.
  • If the program must run with EXEC PGM=, link-edit it with DSNALI (CAF) or DSNRLI (RRSAF) and have it make its own connection. Both can also connect implicitly on the first SQL call. Then Db2 uses the default subsystem from DSNHDECP and a plan named after the program's DBRM, so most shops code the connect calls instead.
  • Keep Db2 batch steps in a cataloged procedure or JCL template, so new jobs start from a pattern that works.

What it looks like

PAYCALC  OPEN CSR-RATES FAILED  SQLCODE=-927  SQLSTATE=51006
IEF142I PAYRUN01 STEP030 - STEP WAS EXECUTED - COND CODE 0016

Questions

Why is there nothing about -927 in the Db2 logs?

Because the SQL never reached Db2. The language interface linked into the program found no connection and returned -927 by itself.

Does -927 need a BIND?

No. The plan and packages are fine. Only the way the program is started or linked needs to change.

Can one load module run both under DSN and with EXEC PGM=?

Not if it's linked with DSNELI. DSNULI decides the attachment at run time, so the same module can work with more than one attachment facility.