Wozu SHARE(*YES) bei PF

[ExAzubi]

Hallo zusmmen,

kann mir jemand genauso sagen, wozu das SHARE(*YES) gut ist?

Vermute das ich ein Problem habe mit den Zugriff auf einer Datei habe, da in einem SQLRPGLE Programm ein andrers RPG Programm aufgerufen wird.

Kann man das Problemlos auf *NO setzen, oder kann es dazu an anderer Stelle zu Abstürzen kommen?

Danke an alle Helfenden.

[Fuerchau]

Das liegt an der Anwendung.
Viele kommen noch aus Urzeiten, als der Open noch dauerte (Disketten).
SHARE(*YES) verhindert auch (ohne Commit) mehrfache Satzsperren.
Man findet dann mit unter auch mehrfach identische LF's, damit auf Grund Share der Satzzeiger nicht verbogen wird.

Ich kenne das von der Brain-Software und habe mir z.T. über ein Pre-CLP per OVRDBF den SHARE dann ausgeschaltet.

SQL interessiert das nicht, wenn nötig wird eine Table auch mehrfach geöffnet.

[ExAzubi]

Hallo Furchau,

erstmal Danke.

Wenn ich aus meinem Programm (SQLRPGLE) eines dieser "Uralten" Weiterverabeitungsprogramme (Wareneingnag) aufrufe, bekomme ich einen CPF5125 (nicht immer ?!?!?)

Bin der Meinung das das an dem SHARE liegt und ers zufällig einen SHARE nur mit INPUT erwischt.

Daher würde ich in einem CL vorher den SHARE auf *NO setzen, wobei ich nicht weiß wie die Auswirkunen sein könnten

[Fuerchau]

Das Problem mit dem Mischen SQL/Native besteht immer wieder, ins besonders wenn eine Anwendung share verwendet.
So lange die aufgerufenen Alt-Programme keine Datenveränderungen vornehmen sollen, kannst du share(*no) verwenden.

Bei Share(*no) kann es bei Mehrfachopen zu Deadlocks bei Read/Chain/Update kommen.

Share(*yes) wirkt nicht bei SQL, da sonst Optimierungen nicht möglich wären.

Du kannst dir nur mit eigener ACTGRP für dein SQLRPGLE behelfen (also nicht *CALLER).

[cbe]

schön, dass andere auch diese Probleme haben

Ich hatte mich damals auch nicht getraut, bei einer zentralen Datei den SHARE rauszunehmen.

Bei uns war die Auswirkung, dass wenn das erste Pgm die Datei mit ReadOnly öffnete, und dann ein Pgm ruft, das die Datei mit ReadWrite haben will - das bricht dann ab.


Letztlich habe ich mir so beholfen, dass ich eine neue LF mit gleichem Index (und natürlich SHARE NO) angelegt habe,
und diese im inneren Pgm verwende.

Gruß,
Christian

[Fuerchau]

Das kannst du bei Native-IO ja so machen, aber bei SQL geht das leider nicht.
Der SQL-Optimizer öffnet eine beliebige LF als Index immer Input, so dass aufgerufene Programme dann eben die Probleme bekommen.
Die PF wird ebenso Input geöffnet, nur bei FOR UPDATE dann eben IO um einen Lock zu platzieren.

Bei Brain/Infor gibt es auch einige CLP's die auf Grund SHARE(*YES) erst mal reihenweise OPNDBF .. OPTION(*ALL) machen, da die das Problem selber nicht in den Griff bekommen haben.