Szenarien dieser Art sollte man vermeiden.

Zu 1 und 2:
Automatische Commits gibt es generell nicht. Wenn eine ACTGRP oder ein Job endet, wird ein offener Commit mit Rollback geschlossen.

Konsequenzen hängen vom Aufrufer ab.
Verwendet man dort ausschließlich RLA (also F-Bestimmungen) ohne Commit werden diese auch ohne Commit/Rollback-Möglichkeit verarbeitet.
Rufst du ein Programm mit Commit auf ist bei RLA ein manueller STRCMTCTL erforderlich sonst scheitert bereits der Open. Ist das Gerufene mit SQL wird intern STRCMTCTL automatisch gestartet und alles läuft unter Commit.
Macht der Service einen Return, bleibt die Transaktion offen bis zum Ende. Bei wiederholten Aufrufen ohne Commit erhöhen sich die Anzahl Sperren für den Rest der Welt, was dort zu Lock-Timeouts führen wird.
Die Dateien bleiben oberhalb weiter ohne Commit.

Ist der Aufrufer in SQL ohne Commit kann der Service scheitern, da ja die aktuelle Transaktion auf *NONE und nicht auf *CHG steht. Ich glaube nicht, das hier ein Automatismus besteht.
Eine Transaktion wird i.d.R. erst bei der Durchführung des 1. SQL's gestartet. Rufst du den Service zuerst auf kann es sein, dass der Rufer anschließend mit seinen SQL's entweder scheitert oder nun auch mit *CHG arbeitet.

Ausprobiert habe ich das noch nie, da solche Szenarien erst gar nicht angedacht werden sollten.

Wenn du das trennen willst, musst du in ACTGRP's denken.
Ein Service arbeitet i.d.R. mit *CALLER als ACTGRP. Musst du den Service nun nutzen benötigst du einen Wrapper mit eigener ACTGRP oder *NEW, der dann den Service aufruft. Der Wrapper muss dann auch einen Commit machen.