Den QZDASOINIT gab es auch. Mit dem Abbruch wird er jedoch beendet. Erst nach meiner letzten Nachricht suchte ich nach dem Joblog. Es zeigt jedoch keinerlei Meldung zu Abbruch, Fehler oder Problemen. Aufgeführt sind meine 3 Tabellen mit den geschriebenen Sätzen:
Datei Bibliothek Einheit format art Anzahl Ausw Gem Anz Satz Bereich
SYSROUTINE QSYS2 SYSRO00001 PHY 0 I N. *ACTGRPDFN
QASQRESL QSYS2 QASQRESL LGL 0 I N. *ACTGRPDFN
FEKALES1 AM FEKALES1 FORMAT0001 PHY 29765 O N. 29766 *ACTGRPDFN
FEMEINS1 AM FEMEINS1 FORMAT0001 PHY 1 O N. 2 *ACTGRPDFN
FEDEKLS1 AM FEDEKLS1 FORMAT0001 PHY 2998 O N. 2999 *ACTGRPDFN
QPSRVDMP QSYS *SPOOL WMHYTITL PRT 2 O N. *ACTGRPDFN
QPDSPJOB QSYS *SPOOL DETAIL PRT 184 O JA 1 *ACTGRPDFN

Vor dem insert werden die Tabellen gecleart (CLRPFM über QCMDEXC aus C#). Es gibt weder ein Journaling noch einen Trigger. Mit DSPPFM kann ich das Schreiben in den 3 Tabellen nacheinander sehr schön mitverfolgen. Über Debug sehe ich auch, dass der MS-SQL-Reader korrekt befüllt ist. Beim Excecute.NonQuery tritt dann nahezu ohne Zeitverzögerung der Fehler auf. Die Verbindung steht also nachweislich. Durch den Debug verzögert handelt es sich auch definitiv nicht um ein Zeitproblem, da der Fehler immer reproduzierbar bei Datensatz 32768 auftritt.

PS: an Hr.Bender
Ich schrieb in meiner Problembeschreibung von einem C#-Programm. Sie brachten dann den Connectionpool ins Gespräch. Die static-Connection verwende ich um in verschiedenen Modulen die einmalig geöffnete Verbindung nutzen zu können.