CHKDLO versus WRKLNK / DSPLNK

[E305GL]

Wenn du wohl CLP/CLLE meinst, sind das CHKOUT und CHKIN, wobei allerdings zusätzlich auch die Sperre gesetzt wird.
Wenn also CHKOUT klappt, sollte CHKIN nicht vergessen werden.

https://www.ibm.com/docs/en/i/7.4.0?...cl/chkout.html

Anhand von MONMSG kannst du den Fehler ja prüfen, z.B. CPFA0A9 = nicht vorhanden.
Was nicht heißt, dass du auch berechtigt CPFA09C bist;-).

---------------------------------------------------------------------------------------------
Danke für den Tipp.
Eine Sperre, nur um eine Existenzprüfung vorzunehmen, könnte ein Problem darstellen da meherer 100 User permanent produktiv zugreifen.
Wie effizient war/ist doch das QDLS...!!!
Vielleich hat jemand einen heißen Draht nach Rochester und die könnten "behirnen" dass z.B.
ein WRKLNK-Parameter DSPOPT(*NONE) oder ein DSPLNK-Parameter *OUTPUT(*NONE) auch eine OS400-native Lösung sein könnte.
LG

[Fuerchau]

Dann nimm SQL, so wie Birgitta vorgeschlagen hat. Da allerdings intern wieder API's verwendet werden ist die Funktion langsamer als der CHKOUT.
Die Wartezeit für die Sperre beträgt default 60 Sekunden.
Ein CHKOUT/CHKIN-Paar liegt weit unter 1 Sekunde, sollte also kein Problem darstellen.

[E305GL]

[QUOTE=Fuerchau;125852]Dann nimm SQL, so wie Birgitta vorgeschlagen hat. Da allerdings intern wieder API's verwendet werden ist die Funktion langsamer als der CHKOUT.
Die Wartezeit für die Sperre beträgt default 60 Sekunden.
Ein CHKOUT/CHKIN-Paar liegt weit unter 1 Sekunde, sollte also kein Problem darstellen.[/
QUOTE]

Dank für Dein Bemühen, werdens mit CHKOUT/CHKIN versuchen.
Andere SW-Krücken sind uns zu aufwendig, sind vergleichbar mit Assembler anno 1970.

[E305GL]

[QUOTE=E305GL;125855]

Dann nimm SQL, so wie Birgitta vorgeschlagen hat. Da allerdings intern wieder API's verwendet werden ist die Funktion langsamer als der CHKOUT.
Die Wartezeit für die Sperre beträgt default 60 Sekunden.
Ein CHKOUT/CHKIN-Paar liegt weit unter 1 Sekunde, sollte also kein Problem darstellen.[/
QUOTE]

Dank für Dein Bemühen, werdens mit CHKOUT/CHKIN versuchen.
Andere SW-Krücken sind uns zu aufwendig, sind vergleichbar mit Assembler anno 1970.

----------------------------------------------------------------------------------------------------
CHKOUT/CHKIN ist einfach und funktioniert, wenngleich mit einem Sperren-Restrisiko.
Habens jetzt mit DSPLNK in eine temoräre outqueue sperrenfrei gelöst.
Nochmals danke.

[BenderD]

Dann nimm SQL, so wie Birgitta vorgeschlagen hat. Da allerdings intern wieder API's verwendet werden ist die Funktion langsamer als der CHKOUT.
Die Wartezeit für die Sperre beträgt default 60 Sekunden.
Ein CHKOUT/CHKIN-Paar liegt weit unter 1 Sekunde, sollte also kein Problem darstellen.

... warum sollte sich jemand diesen Krampf antun, wenn eine subprocedure access(path: 0) gibt, die einem 0 zurückgibt, wenn das Objekt existiert?
Die grandiosen SQL_Services sind lediglich wrapper für (andere APIs), die ganze Listen erzeugen und nur über die weitere Schicht SQL bedienbar sind. OK, ich vergaß, man kann sich die Hosen gemäß eines Sprichworts auch mit der Kneifzange anziehen.
Was Assembler angeht, wer das (access(...)) für Assembler hält, der hat weder Ahnung von Assembler, noch von ILE RPG.

D*B

[Fuerchau]

Stimmt, accsess() kommt eigentlich aus der C-Welt, die quasi den Assembler abgelöst hat.
Da kommt man aber mit E305GL nicht direkt drauf, man braucht also einen doppelten Wrapper:
E305GL => ILERPG => C-API;-).

CHECKOUT hätte noch, mit der Sperre, den Vorteil, dass das Objekt zwischen Prüfung und Verwendung nicht verschwinden kann, CHECKOUT => Tuwas() => CHECKIN.
Wer garantiert einem, dass nach access() das Objekt noch immer da ist?
Schließlich erinnere ich mich, dass auf der IBM i durchaus mehrere Jobs am werkeln sind, incl. ggf. Netzwerkfreigaben und die Cients dazu.