Generell gilt ja:
Alle Berechnungen in einer Where/Group-By-Klausel führen eher selten zu einer Indexverwendung.
Hierfür ist es besser, wenn die Anwendung es nicht selber bringt, einen fertigen Schlüssel zur Hand zu haben.
Ich habe mir hierfür, bereits vielfach diskutiert, eine PF mit den Schlüsseln JJ, MM, TT, JJJJ, JJJJMMTT, MMTT, JJJJ-MM-DD (*ISO-Datum) für 1900 - 2100 angelegt (du kannst natürlich auch mehr).
Somit kann ich die alten Dateien per "Inner Join" mittels JJJJ, MM, TT verbinden und das ISO-Datumfeld oder das DEC(8, 0)-Feld mit JJJJMMTT direkt abfragen.

Da der Optimizer ja nicht weiß was du willst, kann er auch nicht wirklich optimieren.

Als erstes musst du die unsäglichen Datumsberechnungen (JJJJ*10000+MM+100+TT) eliminieren und mit der neuen PF verbinden, dann helfen auch Keys.
Dein Having-Konstrukt ist dann einfacher zu verwenden.
Wobei das Having ggf. eher in die Where-Klausel zu stecken ist.

Ein
Select ... where xxx in (select distinct ...)
sollte auch in einen
Select ... where exists (select * from xfile where xxx = xfile.key and ...)
geändert werden können, da hierfür ein Index für xfile eindeutig festlegbar ist.