... also erst einmal sollte das delete statement nicht Tage dauern, eher Stunden. Standard isolation ind DB2/400 ist *CHG (uncommitted read), was hier erst mal bedeutet, dass alle bereits gelöschten Sätze eine update verhindernde Sperre haben. Alles was gelesen ist, hat keine Sperre, das subselect kann sich also während der delete Operation in alle Richtungen ändern, was dazu führen kann, dass Sätze nicht gelöscht werden oder Sätze zum löschen nicht mehr gefunden werden. Wenn man im Sperrlevel auf Cursor stability (nennt sich sinnigerweise *ALL) hochgeht muss man im konkurrierenden Betrieb mit reichlich Kollisionen rechnen, je nachdem woher der Subselect gezogen wird auch in einer nicht tangierten Tabelle. Im übrigen kann man davon ausgehen, dass eine Sicherungsoperation Probleme bekommt, wobei Save while active hier am schlechtesten wäre, der geht garnicht.
Je nach Anforderung wäre hier Segmentierung des subselects in jedem Fall anzuraten, oder man zieht ein Substract und arbeitet dieses per Programm in Einzeltransaktionen (lesen substract, löschen Satz, löschen Satz in Substract, commit oder rolback, je nachdem). Bei dieser Logik kann man das Programm bei richtiger Transaktionslogik (keine Sperreskalation auf das substract!) mehrfach parallel submitten - relativ einfach und schnell.

D*B