SQLCODE -301: Input host variable type can't be used

What it means

Every value a program passes to Db2 arrives with a data type. Db2 checks that the type can be used where the statement puts it, for example in a comparison, an assignment to a column, or as an argument of a CALL. If the type doesn't fit and Db2 can't convert it, the statement fails with -301. For INSERT, UPDATE, MERGE, DELETE, SELECT, VALUES INTO and SET, the position number counts the input variables from 1, left to right. For a CALL or a function, it is the argument number.

In practice most -301 errors come from dynamic SQL and from CALL statements. With static SQL, the precompiler and bind see the host variable declarations, so many type problems often show up at bind time instead. With parameter markers, Db2 only learns the type of each value when the program supplies it at OPEN or EXECUTE, so the check happens then.

Db2 for z/OS converts between many types on its own, including, in newer releases, between some string and numeric types. -301 is what's left when no such conversion applies.

Common causes

• A stored procedure called with a parameter whose type doesn't match the procedure's definition, for example a DECIMAL passed as an integer or as a character string.
• A parameter marker given a value of a type that can't be used in that place in the statement, through an SQLDA or a JDBC or ODBC call.
• An SQLDA built by hand with the wrong SQLTYPE code for one of the variables.
• A client tool or driver that describes a value with a different type from the column it's compared with or assigned to.

How to find the problem

1. Read the position number in the DSNT408I message or SQLERRMC. Count input variables or parameter markers from the left of the statement to find the one it means.
2. For a CALL, compare each parameter's type with the procedure definition in SYSIBM.SYSPARMS.
3. For dynamic SQL with an SQLDA, display SQLTYPE and SQLLEN for that entry before the OPEN or EXECUTE.
4. For Java or ODBC programs, check which setter or bind call supplies that parameter and what type it uses.

How to fix it

• Pass the value in the type the statement or procedure expects, for example a packed decimal field for a DECIMAL parameter.
• Use CAST on the parameter marker in the SQL, such as CAST(? AS DECIMAL(9,2)), so Db2 knows the type it should get.
• Correct the SQLTYPE and SQLLEN values in a hand-built SQLDA.
• If a tool or driver formats parameters wrongly, check for a fix from its supplier. IBM has fixed this kind of problem in its own tools with APARs.

What it looks like

DSNT408I SQLCODE = -301, ERROR:  THE VALUE OF INPUT VARIABLE OR ARGUMENT NUMBER 2 CANNOT BE
         USED AS SPECIFIED BECAUSE OF ITS DATA TYPE
DSNT418I SQLSTATE   = 42895 SQLSTATE RETURN CODE

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.