Command per Exit Point verändern

[dschroeder]

Ich habe auch schon die Idee überprüft, einen Trigger auf die QDDSSRC zu legen. Aber das ist etwas unschön, weil

• der Trigger beim Speichern eines DSPF bei jeder Zeile des Sourcecode anspringt
• man den Trigger auf jede Sourcefile (zumindest QDDSRSRC) legen muss, die man verwenden will
• es es sein kann, dass man eine Sourcefile nur speichert und nicht kompiliert. Der Informationsgehalt ist dann doch etwas anders als bei CRTDSPF einzugreifen.

[BenderD]

... der Aufwand erscheint mir mit der REGINF Variante überschaubar, die reicht den command String in CL Notation in das Exit Programm, da hat man auch die Wahl. ob das davor oder danach laufen soll. Kritisch wäre, was da passiert, wenn der compiile in den Ofen geht, da könnte man sich aber auch an die Message-Q andocken und die completion message auswerten.

Bei der VLDCKR Variante kann es Tage dauern die Parameterschnittstelle des commands zu anlysieren (es sei denn mein kleines Tool funzt noch).

Ich würde allerdings in erster Linie erwarten, dass profound da flexibler wäre.

D*B

[dschroeder]

Ich habe bei Profound schon nachgefragt. Die werden ihr Produkt in der Hinsicht wohl nicht ändern. Wahrscheinlich gibt es nicht viele User, die das Problem sehen.

Um ehrlich zu sein, sehe ich immer noch das Risiko, durch einen kleinen Fehler eine Situation auszulösen, in der kein Command mehr funktioniert. Oder denke ich da falsch?

[BenderD]

... no risc, no fun!
end of joke

Da müsste man sich schon sehr viel Mühe geben, oder unendlich dappig vorgehen.

D*B

PS: Beim VLDCKR kann das per Design nicht passieren.

[dschroeder]

Ich habe mir das VLDCKR mal angesehen. Ich glaube, ich verstehe, wie das funktionieren soll. Es ist insofern unkritisch, weil man es nur an ein spezielles Command hängt und alle anderen Commands davon nicht beeinflusst werden.
Allerdings bin ich unsicher, ob es meinen Einsatzweck erfüllt: Mein Checkprogramm würde ja aufgerufen, bevor das Command wirklich ausgeführt wird. Das wäre natürlich kein Problem, da ich ja in meinem Checkprogramm alles notwendige machen könnte. (Also selbst ein CRTDSPF aufrufen usw.). Aber ich müsste danach ja verhindern, dass das Command zu Ende läuft. (Da ich ja bereits alles notwendige selber gemacht habe). Wenn ich das zu Ende laufen per Escape Nachricht verhindere, würde ja sicherlich im Visual Designer von Profound eine Fehlermeldung auftauchen. Das wäre natürlich auch nicht schön.

Ich muss am Wochenende nochmal etwas über das ganze nachdenken.

Ich wünschen allen ein schönes Wochenende.

LG, Dieter

[dschroeder]

Hier doch noch eine Überlegung, bevor ich mich ins Wochenende begebe:

Kann es sein, dass ich die Exit Points, die ich oben genannt habe, falsch verstanden habe? Ich hatte gedacht, dass QIBM_QCA_CHG_COMMAND darauf reagiert, wenn ein Command ausgeführt wird. Inzwischen habe ich etwas gelesen, was darauf hindeutet, dass der Point ausgeführt wird, wenn das Command in QSYS verändert wird. Also per CHGCMD oder so.

Das würde mir dann ja nicht weiterhelfen, denke ich. Ich will ja eingreifen, wenn das Command ausgeführt wird, nicht wenn das Command-Objekt geändert wird.

[BenderD]

Hier doch noch eine Überlegung, bevor ich mich ins Wochenende begebe:

Kann es sein, dass ich die Exit Points, die ich oben genannt habe, falsch verstanden habe? Ich hatte gedacht, dass QIBM_QCA_CHG_COMMAND darauf reagiert, wenn ein Command ausgeführt wird. Inzwischen habe ich etwas gelesen, was darauf hindeutet, dass der Point ausgeführt wird, wenn das Command in QSYS verändert wird. Also per CHGCMD oder so.

Das würde mir dann ja nicht weiterhelfen, denke ich. Ich will ja eingreifen, wenn das Command ausgeführt wird, nicht wenn das Command-Objekt geändert wird.

... für die WRKREGINF Variante machst Du:
ADDEXITPGM EXITPOINT(QIBM_QCA_CHG_COMMAND) FORMAT(CHGC0100) PGMNR(1) PGM(Mylib/MyPgm) PGMDTA(*JOB 20 'CRTDSPF QSYS ')

damit wird beim Aufruf von CRTDSPF nachdem alles geprompted wurde, dein Programm aufgerufen. Das ist völlig identisch mit der VLDCKR Variante - nur dass keine command geändert wird und dass du im Programm den commanstring in cl notation bekommst und weiter Informationen in dem CHGC0100 Format.

Beim VLDCKR machst du ein crtdupobj von crtdspf in eine Bibliothek (ändere nie einen System command direkt, der könnte defekt werden), die vor der QSYS steht und hängst an diesen command den VLDCKR an. Das angehängte Programm kriegt die Parameter genau so, wie das CPP (Command processing programm), was bei Releasewechsel oder PTFs zu Problemen führen kann.

Mit beiden kannst Du den commandstring ändern oder abbrechen, bei der reginf Variante kannst du den Aufruf auch auf ein anderes Programm umbiegen.

Bei der VCP Variante musst Du die (undokumentierte) Parameter Schnittstelle des Commands kennen, damit könntest Du auch den Command auf ein Programm von Dir umbiegen.

Falls Profound die Wandlung mit einem eigenen command macht, der den CRTDSPF benutzt, dann würde ich den Profound command mit eine der obigen Techniken bearbeiten.


D*B

[dschroeder]

Vielen Dank für das konkrete Beispiel. Ich werde das mal ganz vorsichtig ausprobieren.

[BenderD]

Vielen Dank für das konkrete Beispiel. Ich werde das mal ganz vorsichtig ausprobieren.

... das Problem ist eher, da was nach dem CRTDSPF zu machen, ohne sich in Rekursion festzufahren.

D*B

[dschroeder]

Guter Hinweis,
vielen Dank.