Das Öffnen und Schließen ist gar nicht das Problem sondern die Sonderbehandlung der Commit-Steuerung (wusste ich bis Dieter mir das erklärte auch nicht):
Der Commit/Rollback wird nicht über SQL direkt verarbeitet und wird auch nicht in den Versionen CMD-Commit, native RPG Commit oder exec sql commit; unterschieden und geht an alle geöffneten Verbindungen gleichzeitig.
Nur wenn der Commit von allen DB's bestätigt ist, akzeptiert ihn das System.
Wenn eine RDB-Sitzung geschlossen werden soll (Disconnect) wird dies also bei fehlendem Commit ebenso abgelehnt.
Dies löst letztendlich auch dein Problem aus.

Die einzige Lösung in diesem Fall ist, deinem Triggerprogramm eine eigene benannte ACTGRP zu geben, da diese dann auch eine eigene Commit-Definition erhält.
Zusätzlich ist "exec sql set option commit= *chg;" erforderlich. Daran kann man auch sehen, dass dies nicht verbindungsspezifisch ist also auch für deine aktuelle Verbindung gilt.
Ein korrektes Schließen ist wirklich nur mit erfolgreichem Commit möglich.

Solltest du während der Bearbeitung durch den Trigger noch auf eigene nicht journalisierte Dateien zu greifen, so ergänze die SQL-Befehle alle mit " ... with NC" (mit ohne commit). Dann bekommst du keinen Fehler bei fehlendem Journal und ein Commit funktioniert dann.

Langfristiger würde ich das Triggerverfahren aber asynchronisieren, da der Connect/Update/Close durchaus mal länger dauern kann und auch bei Nichterreichbarkeit deine Dialogsitzung vollkommen ausbremst.
Dazu kann man ganz gut mit DTAQ's arbeiten, auf denen ein Batchprogramm horcht und die Aktionen ausführt. Dein Trigger schickt dann einfach nur eine Nachricht an die DTAQ (Datei + Key) und und protokolliert die Daten ggf. noch in einer weiteren kleinen Tabelle.
Der DTAQ-Watcher bekommt die Nachricht sofort aus allen Jobs, erledigt sein Werk und löscht den Satz aus der Protokolldatei.
Die Protokolldatei ist erforderlich, da DTAQ's auch schon mal kaputt gehen.
Dann kann man diese wiederherstellen und aus den nicht gelöschten Protokollsätzen die Aufträge wieder in die DTAQ schieben.

Per Prestart-Job kann man dann sogar mehrere Jobs parallel dranhängen, falls mal 1 nicht ausreichen sollte.