Manchmal beginne ich hier zu verzweifeln:

Fakt 1:
Wenn die Where-Klauses die Einschränkung auf eine Join-Table macht, wird automatisch ein Inner Join draus!
Warum? Weil die Prüfung auf ein Left-Join-Feld die NULL-Werte ausschließt. Dies optimiert der Optimiser in der Regel ebenso automatisch zu einem Inner-Join.
Wenn du den Teil der Where-Klausel in die On-Klausel des Left-Jons packst, wirst du sehen, dass eben auch die Daten kommen, die nicht im Left join vorhanden sind und somit NULL-Werte liefern.
D.h., dass Birgittas Select ganz einfach mit einem "Select * from Test01" abgekürzt werden kann, da ja aus den Join-Tabellen gar keine Felder benötigt werden, die nur bei gefundener Bedingung Werte ungleich NULL aufweisen.

Fakt 2:
Ein Join, nun egal ob Left/Inner, kann neben einer 1:1 aber auch eine 1:N-Beziehung liefern.
Auf Grund des Ursprungselects, gehört ja der Join eigentlich als Inner Join kodiert, da die Ursprungs Whereklausel ja auf jeden Fall per "in" die Existenz geprüft hat.

Birgittas Select, geändert auf Inner Join, geht also von der Annahme aus, dass per Join die Laufnummer innerhalb der Zeit nur 1x vorkommt.
Da das ebenso auch für den 2. Join gilt, darf in dieser Konstellation die Laufnummer entweder nur im 1. Join oder nur im 2. Join vorkommen.
Ansonsten wird die Zeile aus TEST01 mindesten 2x geliefert.
Im Moment mag das vielleicht so sein, aber gilt dies generell für dieses Datenmodell?

Nun stellt sich mir die Frage, ob in den Daten tatsächlich nur eine 1:1-Konstallation vorliegt.
Wenn die Laufnummer aber eben mit verschiedenen Zeitmarken vorkommt, ist das eine 1:N-Beziehung und die Zeile aus Test01 wird mehrfach geliefert.
Ebenso gilt, dass ein "A->Join B and A->Join C" mindestens eine 1:2-Beziehung ist und zu einer Verdoppelung der Datenzeile TEST01 führen kann.

Fakt 3:
Eine Prüfung mittels "In" versus "Exists" in einer Where-Klausel kann nie einfach mit einem Join ersetzt werden. Insbesonders dann, wenn ich u.U. mehrere In/Exists, wie oben, benötige.

Und hier gilt eben wieder die Index-Prämisse:
Habe ich einen Index über das Feld der Beziehung und die Where-Klausel des Subselects, ist ein Exists immer schneller als ein "in", da nur 1x zugegriffen werden muss und hier noch ein Index-Only-Access erfolgen kann und wahrscheinlich wird.

Ein "in" baut im Gegensatz zu Exists je Ergebniszeile die Liste immer wieder neu auf um diese dann sequentiell zu durchsuchen. Dies ist u.U. auf der DB2/400 gar nicht zu merken, wenn die Ergebnisliste sehr kurz ist und auf Grund des DB-Caches keine Plattenzugriffe nötig sind.
Beim SQL-Server z.B. ist dies nicht der Fall. Hier geht dieser bei komplexeren Suchen per "in" durchaus in die Knie.

Ich persönlich verwende den "In" nur noch mit Konstanten ansonsten verwende ich nur den [not] Exists.