Lockwait auf DTAARA ?

[BikerKini]

Hallo Fachleute.

Seit unserem Releasewechsel von 5.3 auf 5.4 haben wir folgendes Phänomen.

Wir haben eine relativ alte Version von GFC-Fax im Einsatz. Wenn wir nun das Wartungsmenü für die Fax-Software aufrufen wollen haben wir plötzlich eine Wartezeit von 5 Minuten um in das Menü zu gelangen. Vorher ging das in 1 Sekunde. Als ich mir den Job mal genauer angesehen habe, musste ich feststellen daß dort ein Exklusiv-Zugriff auf eine DTAARA gemacht wird. (QGFCCOM/GFCCOM)
Gibt es eine Möglichkeit die Wartezeit für den LCKW runterzusetzen? Oder kann die DTAARA auf eine andere Zugriffsart als *EXCL gesetzt werden?
Die Hotline bei GFC konnte mir leider nicht weiterhelfen, das Phänomen ist dort unbekannt.

Weiß jemand von euch einen Rat?

Gruß vom BikerKini

[Fuerchau]

Wenn beim ALCOBJ keine Wartezeit angegeben wird, zieht die Standardwartezeit des Objekts.
Ist diese nicht definiert (bei Dateien kann man dies explizit mit der Dateiwartezeit), gilt die Standardwartezeit des Job's (Default eigentlich 30 Sekunden).

GFC sollte mal seine ALCOBJ's darauf prüfen.

[BikerKini]

Hallo Herr Fürchau.

Danke erstmal für die schnelle Rückantwort. Ich habe mal testweise den Job auf Jobwartezeit 1 Sek. gesetzt. Der Zugriff geht jetzt tatsächlich um einiges schneller. Wie kann man denn die Jobwartezeit dauerhaft auf 1 Sekunde setzten? Nach neuanmeldung ist der Wert doch wieder auf 30 Sekunden, oder?
In der JOBD, SBSD, USRPRF und DEVD hab ich nix gefunden.

Gibt's eigentlich einen Systemwert der die Dateiwartezeit bei Zugriff regelt?

Gruß vom BikerKini

[Pikachu]

Der Job holt seine Standardwartezeit wahrscheinlich aus der Klasse, die im entsprechenden Leitwegeintrag des Subsystems eingetragen ist, in dem er läuft. (DSPSBSD Subsystem, dann Auswahl 7 und dann "5=Details anzeigen" für den entsprechenden Leitwegeintrag. Die Klasse kannst du z.B. mit DSPCLS anzeigen.)

[Fuerchau]

Nein, den gibt es nicht.
Wie gesagt, die Dateiwartezeit kann man an der Datei selber einstellen.

Alle anderen Objekte werden über ihre Klasse gesteuert.
Anscheinend ist für DTAARA's jetzt der Default von 0 auch auf die Job-Standardwartezeit geändert worden.

Besser wäre, dass GFC seine ALCOBJ's entsprechend auf WAIT(0) anpasst als im System rumzustricken.

Die Standardwartezeit findest du über:

DSPSBSD
7 -> Leitwege
5 -> Anzeige Details

Hier sieht du die verwendete Klasse.
Mit CHGCLS kannst du die Wartezeit anpassen.

Allerdings hat dies auf das gesamte System Auswirkungen und kann sich ggf. nachteilig auswirken.

Besser wäre eine Anpassung der Anwendung.

[BenderD]

das sieht mir erst mal mehr nach einem OS/400 Bug aus. Die Wartezeit schlägt ja nur zu, wenn man das Objekt n i c h t zugeordnet bekommt. Sprich Verkürzung der Wartezeit beschleunigt den Abbruch einer Aktion, nicht die Durchführung!

D*B

Nein, den gibt es nicht.
Wie gesagt, die Dateiwartezeit kann man an der Datei selber einstellen.

Alle anderen Objekte werden über ihre Klasse gesteuert.
Anscheinend ist für DTAARA's jetzt der Default von 0 auch auf die Job-Standardwartezeit geändert worden.

Besser wäre, dass GFC seine ALCOBJ's entsprechend auf WAIT(0) anpasst als im System rumzustricken.

Die Standardwartezeit findest du über:

DSPSBSD
7 -> Leitwege
5 -> Anzeige Details

Hier sieht du die verwendete Klasse.
Mit CHGCLS kannst du die Wartezeit anpassen.

Allerdings hat dies auf das gesamte System Auswirkungen und kann sich ggf. nachteilig auswirken.

Besser wäre eine Anpassung der Anwendung.

[Fuerchau]

"Alte" Anwendungen prüfen gerne über ALCOBJ ob ein Batchjob aktiv ist oder nicht.
Wenn sich nun der Default bestimmter Objektarten ändert, ändert sich eben auch das Prüfverhalten.

Deshalb verwende ich auch bei Sperr-Prüfungen grundsätzlich WAIT(0), da ich per DLCOBJ die erhaltene Sperre eh sofort wieder freigebe.

[BenderD]

wenn das Objekt verfügbar ist, dann ist die Wartezeit schnurz, wenn das Objekt nicht verfügbar ist, dann bräuchtest du nicht zu prüfen, wenn du deine Aktion dann trotzdem durchführen willst???

"Alte" Anwendungen prüfen gerne über ALCOBJ ob ein Batchjob aktiv ist oder nicht.
Wenn sich nun der Default bestimmter Objektarten ändert, ändert sich eben auch das Prüfverhalten.

Deshalb verwende ich auch bei Sperr-Prüfungen grundsätzlich WAIT(0), da ich per DLCOBJ die erhaltene Sperre eh sofort wieder freigebe.

[Pikachu]

Sofort oder erst nach 30 Sekunden Wartezeit aufzugeben macht manchmal schon einen Unterschied.

[Fuerchau]

DANN habt ihr mich NICHT verstanden.

Ein bestimmter Batchjob lockt per ALCOBJ eine DTAARA, so dass man per ALCOBJ nur prüft, ober der Batchjob auch noch läuft.
Tatsächlich erhalten will ich die Sperre ja gar nicht (deshalb die sofortige Freigabe), sondern nur z.B. im Bildschirm anzeigen, dass der Batch bereits aktiv ist.
Kann ich die Sperre ohne CPF erhalten, weiß ich, dass der Batchjob eben nicht läuft.

Das Objekt selber, die DTAARA, dient hier nur als Anker (Semaphore) mangels anderer Möglichkeiten (insbesonders wenn man auf CLP beschränkt ist).