For many years it has been possible to execute SQL statements using the DB2 utility program DSNUTILB, which you use when you execute the JCL procedure DSNUPROC. I have touched upon this option indirectly when I described DB2 cross load, which at the core is all about executing a SELECT statement using DSNUTILB. However you can also execute all other kinds of SQL statements than SELECT (and WITH).

It is extremely easy to execute anything else than SELECT. Here is a simple example:

EXEC SQL
SET CURRENT SQLID = USER
ENDEXEC

Just like in COBOL and PLI (and other compiling programming languages) you start by writing EXEC SQL. On the other had the termination of the statement is a little different (almost like in COBOL) as you have to write ENDEXEC. The statement you put in between EXEC SQL and ENDEXEC is totally up to your needs or imagination. An example is to insert a row into a table so you know that the utility statement executed before the insert went OK. There are many other good use cases and now you know you can do it.

There is one special detail about excuting SQL statements using DSNUTILB. Each statement is always followed by an implicit COMMIT. In fact DSNUTILB establishes a new thread for each EXEC SQL. This means that it is a very bad idea to execute many SQL statements using DSNUTILB as it will take considerably longer time compared with tools like SPUFI, DSNTEP2, DSNTIAUL and DSNTIAD.

An annoying detail about DSNUTILB is that it fails when the input file is empty, which is quite frustrating if you generate the input and there is nothing to process. In such a situation you can insert the above example instead of having empty input. The example changes nothing, but will make DSNUTILB end with a return code of 0.