I found this answer on IBM's website, and it may have some bearing on your problem. It would be worth looking into.How do we end the QZDASOINIT job that is started once we connect to the AS/400, when our application happens to end abnormally?
There are several choices to resolve the problem. If you write your applications so that they only do record locks for update, the records should be locked only for a short period of time. Since the records are locked for a short period of time, the probability of a failure during this time should be low, thus there should be few incidences of QZDASOINIT being left with record locks.
The first thing that should be done is to have an error handler in your application that would shut down ODBC when your application and or PC fails. Error handlers are documented in the AS/400e series client access for Windows 95/NT API and technical reference version 3, document number SC41-3513-03, for when ODBC fails, but this concept should be adapted for your application and/or PCs failure.
Another choice is to change the TCP/IP keepalive value to a smaller value than the default 120 minutes. If the value was reduced to one minute, the ZDASOINT job would end after approximately four minutes as there are an extra three minutes that are added to the keepalive value. This can be done by using the command CHGTCPA and the parameter TCPKEEPALV.
QZDASOINT provides the TCP/IP database access to the AS/400 from a PC and therefore provides ODBC, file transfer, and other database accesses. If you are not accessing the AS/400 from any PC, it would be safe to use the API QUSLJOB to get a list of the QZDASOINT jobs, then do an ENDJOB on each of them as the only QZDASOINT jobs that should be left are the ones that are not in use. Since these are prestart jobs they will create new ones which can be used by the next user.
This was first published in February 2006