# SQLCODE -440: No routine with compatible arguments Source: https://wndsoftware.com/mainframe-errors/sqlcode-440 ### SQLCODE -440: No routine with compatible arguments SQLCODE -440 (SQLSTATE 42884) means Db2 couldn't find a function or stored procedure that has the name you used, accepts the arguments you passed, and that you are authorized to run. The routine may exist but in another schema, with different parameters, or without your authority. #### Other names for this code Also written as `SQL -440`, `SQLCODE=-440`, `SQLCODE = -440`, `db2 -440`, `sqlstate 42884`, `SQL0440N`, `db2 no function by the name`, `SQL0440`, `no authorized routine named`, `no authorized function by the name`. ### What it means When a statement calls a function or a procedure, Db2 has to pick the routine to run. For an unqualified name it searches the schemas in the SQL path, in order. For dynamic SQL that is the CURRENT PATH special register. For static SQL it is the PATH bind option. Within those schemas it looks for a routine with that name and the same number of parameters. For functions, each argument's type must also be promotable to the parameter's type. Promotion only goes one way. A SMALLINT argument can go to an INTEGER, BIGINT or DECIMAL parameter, and a CHAR argument to VARCHAR. Going the other way, from DECIMAL to INTEGER for example, doesn't count. If no routine passes all these checks, Db2 returns -440 with the routine type and name. The current message on Db2 for z/OS says no authorized routine was found. Authority is part of the search, so a routine you aren't allowed to run is treated as if it didn't match. Db2 for LUW's SQL0440N works the same way. ### Common causes - The wrong number of arguments was passed, often after someone added a parameter to a procedure. - An argument's type can't be promoted to the function parameter's type, for example a DECIMAL host variable for an INTEGER parameter. - The routine lives in a schema that isn't in the SQL path, and the name wasn't qualified. - The caller isn't authorized to execute the routine, so Db2 skips it during resolution. - The function name is misspelled, or it's a function from another database product, or from another Db2 platform, that your Db2 for z/OS doesn't have. - A CALL with a three-part name goes to a remote server, such as Db2 for LUW, and the procedure can't be found there under that name and signature. - The application or package runs at an application compatibility level that doesn't support a function or capability the statement uses. ### How to find the problem - Look the routine up with `SELECT SCHEMA, NAME, ROUTINETYPE, PARM_COUNT, SPECIFICNAME FROM SYSIBM.SYSROUTINES WHERE NAME = 'CALC_TAX'`. - Check each parameter's type in SYSIBM.SYSPARMS and compare it with the type of each argument you pass, including literals. A plain number like 5 is INTEGER, and 5.0 is DECIMAL. - For dynamic SQL, check the path with `SELECT CURRENT PATH FROM SYSIBM.SYSDUMMY1`. For static SQL, check the PATH bind option used for the package. - For a remote call, check the procedure's definition on the remote server. - Check that the caller has EXECUTE on the routine, for example in SYSIBM.SYSROUTINEAUTH, and check the package's APPLCOMPAT level if the function is new. ### How to fix it - Qualify the name with its schema, or add the schema to the path with `SET CURRENT PATH` or the PATH bind option. - Cast arguments to the parameter types, for example `CALC_TAX(CAST(:WS-AMT AS DECIMAL(11,2)))`. - Pass the right number of arguments, and update every caller when a routine's parameters change. - Replace functions that don't exist on your platform with ones that do. - Grant EXECUTE on the routine to the caller, or rebind with an APPLCOMPAT level that supports the function. ### IBM documentation [IBM documentation: -440](https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=codes-440). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). Technical reviewer: [Albert Joseph](https://wndsoftware.com/authors/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. ### Related codes [SQLCODE -204 Undefined object name Read →](https://wndsoftware.com/mainframe-errors/sqlcode-204) [SQLCODE -444 User program could not be found Read →](https://wndsoftware.com/mainframe-errors/sqlcode-444) [SQLCODE -471 Routine invocation failed Read →](https://wndsoftware.com/mainframe-errors/sqlcode-471) [SQLCODE -171 Invalid argument to a function Read →](https://wndsoftware.com/mainframe-errors/sqlcode-171) [SQLCODE -551 Not authorized for the operation Read →](https://wndsoftware.com/mainframe-errors/sqlcode-551) ### Questions #### The function exists. Why do I still get -440? It's in a schema outside your SQL path, its parameters don't match your arguments, or you aren't authorized to run it. Check the schema, the parameter count, each parameter type and EXECUTE authority. #### Will Db2 convert my DECIMAL argument to an INTEGER parameter? Not during routine resolution. Promotion goes from smaller types to larger ones. Cast the argument yourself. #### How does Db2 for LUW report this? As SQL0440N with SQLSTATE 42884. Its message also mentions authorized routines, as the z/OS message does. [Db2 SQLCODEs](https://wndsoftware.com/mainframe-errors/db2-sqlcodes) · [SQLCODE -433](https://wndsoftware.com/mainframe-errors/sqlcode-433) · [SQLCODE -444](https://wndsoftware.com/mainframe-errors/sqlcode-444) [← All error codes](https://wndsoftware.com/mainframe-errors/)