Eigene QTEMP für interaktives Programm?

[franknadolni]

Hallo, kennt jemand eine Möglichkeit in einem interaktiven Programmablauf ein weiteres PGM aufzurufen und diesem eine eigene QTEMP zuzuweisen. Normalerweise würde dieses Programm ja auf die QTEMP des übergeordneten Programms zugreifen. Da aber mit einzelnen Programmen immer die selben Temporären Dateien erzeugt werden kommt es hier zu Problemen.

[BenderD]

... zum Glück nicht, sonst würden die Künstler, die diesen Dummfug zusammengeklimpert habem, noch größeren Dummfug zusammenklimpern.
Works as designed, manchmal hat man eben Pech!

D*B

[franknadolni]

Ohne das entsprechende Hintergrundwissen warum das so ist sollte man nicht so urteilen. Die Programmierer haben sich dabei sehr wohl was gedacht.

[BenderD]

... das nennt man dann einen Fall von denkste! Sowas geht immer irgendwann schief - und dann werden die Anwender ausgeschimpft: "Sie wissen doch, dass Sie dieses Knöpfchen jetzt nicht drücken dürfen..."

D*B

[andreaspr@aon.at]

Hallo,
zum einen, ist die QTEMP überhauptkeinem Programm zugeordnet sondern nur den JOB.
Wenn die einzelnen Programme eine eigene Umgebung benötigen kannst du sie auch mit SBMJOB übergeben.
Es wäre nur zu beachten ob das in eurem Programmablauf überhaupt erlaubt ist.

[holgerscherer]

Es wäre nur zu beachten ob das in eurem Programmablauf überhaupt erlaubt ist.

Streiche "erlaubt", setze "sinnvoll" ;-)

-h

[andreaspr@aon.at]

Streiche "erlaubt", setze "sinnvoll" ;-)

Mit erlaubt hab ich eher gmeint ob die Programme überhaupt asynchron laufen darf. Stimmt aber, sinnvoll gehört auch dazu

[B.Hauser]

... um solchen Problemen vorzubeugen, sollte man auch in temporären Dateien/Tabellen in der QTEMP einen eindeutigen "Handle" einfügen in den Key mit aufnehmen.

Jede Aufgabe (Programm/Prozedur), die Daten in diesen Tabellen verwendet für den Zugriff diesen "Handle".

Vor dem Schreiben wird der nächte "Handle" ermittelt (Möglichkeiten hierzug gibt es diverse). Dieser Handle wird anschließend für den Zugriff auf die Daten als Schlüssel-Wert verwendet. Wird in mehreren Prozeduren aus der temporären Datei/Tabelle gelesen, muss der entsprechende "Handle" als Parameter übergeben werden.

Die temporären Tabellen sollten bei einer solchen Vorgehensweise jedoch nicht gecleart werden, sondern jeweils nur die Daten mit dem gewünschten "Handle" gelöscht werden.

Das Erstellen von "gleichen" Tabellen mit unterschiedlichen Namen und Overrides auf Aktivierungsgruppen-Ebene könnte auch funktionieren, vorausgesetzt, dass die unterschiedlichen Programme in unterschiedlichen Aktivierungsgruppen laufen. ... das Risiko, dass dabei wieder irgendwas schief geht ist extrem hoch.

Deshalb würde ich für die "Handle"-Methode plädieren, sofern eine Batch-Verarbeitung nicht möglich ist.

@Dieter
Manchmal können auch die Programmierer nichts für solche Situationen. Hab' ich alles schon erlebt!
In der ursprünglichen Version wurden bestimmte Programme im Batch ausgeführt und alles war OK. Doch dann kam ein DAU oder ein DAK, der nicht in der Lage war festzustellen, ob das Batch-Programm beendet ist und der darauf berharrte die Batch-Programme müssten interaktiv laufen. ... und schon wäre das Schlamassel perfekt gewesen, hätten wir nicht mit o.g. Handles gearbeitet.

Birgitta

Birgitta

[BenderD]

@Birgitta:

das sehe ich anders, sowohl das erste, wie das letzte. Benutzung temporärer Workfiles ist in > 95% ein ernsthafter Designfehler. Die Mächtigkeit von SQL z.B.: reicht bei weitem aus eben diese 95% aller Workfiles als View auf die aktiven Dateien darzustellen und das in einem Ratsch zu machen, was eine Stafette von 5 Programmen sich da zusammen wackelt, mit 1 Tag mehr an nachdenken, hätte man da überdies 5 Tage Programmierung eingespart und keinen Wackelhaufen produziert.

Dieter

[B.Hauser]

@Birgitta:

das sehe ich anders, sowohl das erste, wie das letzte. Benutzung temporärer Workfiles ist in > 95% ein ernsthafter Designfehler. Die Mächtigkeit von SQL z.B.: reicht bei weitem aus eben diese 95% aller Workfiles als View auf die aktiven Dateien darzustellen und das in einem Ratsch zu machen, was eine Stafette von 5 Programmen sich da zusammen wackelt, mit 1 Tag mehr an nachdenken, hätte man da überdies 5 Tage Programmierung eingespart und keinen Wackelhaufen produziert.

Dieter

Es gab nun mal Zeiten, in denen SQL noch nicht so mächtig war, bzw. nicht eingesetzt wurde und viele Andwendungen sind halt auch schon ein paar Jährchen alt.

... manchmal hat man auch keine andere Möglichkeit als auf einem "gewachsenen Wackelhaufen" aufzusetzen! ...
... auch wenn man genau weiß, dass "grobe Designfehler" vorliegen und man sich dadruch, das man das auch noch laut ausgesprochen hat gewaltig unbeliebt gemacht hat.
... Und ein oder mehrere Programme mit ein paar 10.000 undokumentierten Code-Zeilen in Uralt-RPGII oder RPGIII würde ich auch nicht so auf die Schnelle neu schreiben können/wollen! (Ich hab' schon Programme gesehen, die liefen und keiner wusste warum!)

Birgitta

[BenderD]

... auch wenn man genau weiß, dass "grobe Designfehler" vorliegen und man sich dadruch, das man das auch noch laut ausgesprochen hat gewaltig unbeliebt gemacht hat.

... genau deswegen halte ich es für wichtig, dass "außenstehende Experten" Murks auch eindeutig Murks nennen und nicht schönreden.

D*B,

der meint, dass man auch vor 20 Jahren schon auf gutes Design achten konnte.

[Pikachu]

... Und ein oder mehrere Programme mit ein paar 10.000 undokumentierten Code-Zeilen in Uralt-RPGII oder RPGIII würde ich auch nicht so auf die Schnelle neu schreiben können/wollen

In ein paar Jahren kommen auf anderen Systemen ein paar 10.000 undokumentierte Code-Zeilen in Uralt-C oder C++ oder Uralt-Java dazu. Und auch da gibt's massenweise "gewachsene Wackelhaufen".