Ohne API (auch gekapselt) kann man nur mit DB's Sperrdatei sicher und auch vielfältiger arbeiten.
Man nehme eine neue Datei mit Unique-Key und z.B. JOB-Infofeldern.
Packe die Sperrfunktionen in ein Service-Programm mit eigener ACTGRP.
Nun kannst du lustig beliebige Exklusiv-Sperren setzen:

Z.B.
if Sperre(Key) = *on;
// tuwas
Entsperre(Key);
endif;

Das Serviceprogramm startet ggf. eine eigene Commit-Definition.

In der Funktion Sperre wird:
per Insert versucht den Satz zu schreiben (JobInfos ohne API aus INFDS)!

Schlägt der Insert fehl (duplicate Key ist schneller als jedes API) kann man per Select die Jobinfos auslesen und entsprechende Meldung ausgeben.
Hier kann ggf. auch noch der eigene Job drinstehen, dann gilt die Sperre ja auch noch.
Ist beim Select der Satz nicht mehr da, kann man den Insert wiederholen.
Dies passiert so lange (meist max. nur 2 Mal) bis der Insert oder Select OK ist.

Ist der Insert OK, ist die Sperre erhalten.

In der Funktion Entsperre() wird der Satz wieder gelöscht.

Da das Service-Programm keine Commit/Rollbacks ausführt, werden bei Jobende automatisch alle Sperren gelöscht (Auto-Rollback).

Dies hat den Vorteil, dass man
a) ggf. mehrere Sätze aus einer Datei sperren kann (ohne einen Update zumachen oder den Commit-Level höher zu setzen).
b) Sperren anfordern kann, die nichts mit Dateien zu tun haben (was gerne mit DTAARA's gelöst wird).

Zu b)
Dies ist ja häufiger bei Batchprozessen nötig die sich ggf. gegenseitig ausschließen.
Man kann auch dann mittels DLYJOB etwas länger auf die Sperren warten wenn es denn erforderlich ist.

Die Sperre/Entsperre-Funktion lässt sich auch als SQL-Procedure kapseln.
Die separate ACTGRP hilft auch im QZDASOINIT-Job.
Genauso gut lassen sich hier für CLP's auch CMD's wie LOCKKEY KEY(ABCD) und UNLOCKKEY KEY(ABCD) entwickeln.

So können nun SQL-Clients und CLP's ebenso diese Funktionen nutzen.

Natürlich kann man mit Native-SQL's sowieso an der Anwendung vorbei arbeiten, aber die API-Lösung verhindert das ja auch nicht.