Command per Exit Point verändern

[dschroeder]

Hallo,
ich würde gerne ein Command "manipulieren". Ich habe gelesen, dass es sogenannte exit points gibt, an die man Exit Programme hängen kann. Ich habe das aber noch nie gemacht.

Bisher bin ich auf folgende Infos gestoßen:

1. Um ein Command während der Ausführung zu manipulieren, sollte man den Exit Point QIBM_QCA_CHG_COMMAND verwenden.
2. Es wird noch der Point QIBM_QCA_RTV_COMMAND in diesem Zusammenhang genannt. Ich weiß aber nicht, ob den zusätzlich benötige.
3. Mit WRKREGINF bzw. mit ADDEXITPGM bzw. RMVEXITPGM kann man den Exit-Points Programme hinzufügen.

Was ich erreichen möchte, ist folgendes:

Wenn das Command aufgerufen wird, möchte ich vor der Ausführung mein eigenes Programm aufrufen (im Prinzip so wie ein *before Trigger). Mein Programm soll prüfen, ob es eingreifen muss. Falls ja, soll es den Befehl "ins leere" laufen lassen und stattdessen selber die erforderlichen Dinge ausführen. Wenn mein Programm feststellt, dass es kein interessanter Fall ist, soll mein Programm den Befehl einfach weiterlaufen lassen.

Erste Frage: Ist das so möglich?

Nächste Überlegung: Da ich ja nur einen Exit Point angeben kann, wirkt der ja auf alle Commands. Ich muss natürlich sicherstellen, dass mein Programm nur bei einem ganz bestimmten Command anspringt.
Das Verfahren kommt mit sehr heikel vor. Ich will ja auf keinen Fall riskieren, dass kein Command auf der Anlage mehr läuft, weil mein eventuell fehlerhaftes Programm bei jedem Command anspringt.

Sind meine Überlegungen da richtig?
Hat schon jemand so etwas gebaut?
Gibt es vielleicht ein Beispiel dafür?
Ist das ganze ein Performanceproblem, wenn ab jetzt bei jeder Command-Ausführung ein Programm aufgerufen wird?

Vielleicht bin ich da aber auch voll auf dem Holzweg!

Dieter

[Fuerchau]

Das Problem ist tatsächlich, dass bei einem Fehler das System nicht mehr ausführbar werden kann.
"Command" heißt ja auch aus dem CL heraus ein "CALL...".
Testen kann man das auch eher nur auf einem Entwicklungsrechner, allerdings, wenn dann das Problem auftritt, wird man fast zu einer Neuinstallation gezwungen.

Möglich ist das sicherlich.
Performance, wenn das Programm gezielt auf ein CMD prüft, vernachlässigbar.
Das System merkt sich den Programmpointer, d.h. auch, dass du ggf. einen Neustart brauchst, wenn du das Programm ändern willst, da durch das Verschieben in QRPLOBJ bei der Erstellung, weiter mit der alten Version gearbeitet wird.

Wie Dieter schon sagen würde: Alles Huddel. Wenn man solche Überlegungen hat, sollte man sich fragen, was man genau eigentlich machen möchte.

Um welches CMD handelt es sich? Was soll verhindert werden? Gibts ggf. einfach nur ein Berechtigungsproblem?

[BenderD]

Wenn das Command aufgerufen wird, möchte ich vor der Ausführung mein eigenes Programm aufrufen (im Prinzip so wie ein *before Trigger). Mein Programm soll prüfen, ob es eingreifen muss. Falls ja, soll es den Befehl "ins leere" laufen lassen und stattdessen selber die erforderlichen Dinge ausführen. Wenn mein Programm feststellt, dass es kein interessanter Fall ist, soll mein Programm den Befehl einfach weiterlaufen lassen.

Erste Frage: Ist das so möglich?

Ausser dem angeführten command exit gibt es noch den validity checker (CHGCMD VLDCKR(...), oder einen davor gestellten command. Der command exit wurde eingeführt, weil die älteren Methoden bei Release Wechsel (oder auch bei PTFs) dasselbe Problem haben wie mit CHGCMDDFT geänderte commands - die Änderungen können bei diesen events verschwinden..

Nächste Überlegung: Da ich ja nur einen Exit Point angeben kann, wirkt der ja auf alle Commands. Ich muss natürlich sicherstellen, dass mein Programm nur bei einem ganz bestimmten Command anspringt.
Das Verfahren kommt mit sehr heikel vor. Ich will ja auf keinen Fall riskieren, dass kein Command auf der Anlage mehr läuft, weil mein eventuell fehlerhaftes Programm bei jedem Command anspringt.

Dieter

Für diese exit points können beliebig viele Einträge hinterlegt werden, die jeweils nur auf einen einzelnen command verweisen. Bei einem fehlerhaften Eintrag geht der dann nicht mehr. Da der command qualifiziert anggeben wird, kann das ohne Risiken getestet werden, bevor man das scharf schaltet. Was das an Strom kostet, hängt von Deinem Programm ab, den System seitigen Overhead kann man vernachlässigen. (Ich habe bereits vor Jahrzehnten mit validity checkern für CHGSPLFA gearbeitet und das war nicht spürbar langsamer als ohne.)
Kompliziert an der ganzen Sache sind die Parameter Schnittstellen, die undokumentiert sind und die man genau kennen muss. Zu einigen validity checkern gab es auch diverse Artikel von mir.

D*B

[dschroeder]

Vielen Dank für eure Antworten.
Ich muss mir dann schon genau überlegen, wie ich da weitermache und wie aufwendig das werden kann.

Konkret geht es in meinem Fall um den Befehl CRTDSPF. Eine Standardanwendung (der Profound Visual Designer) verwendet CRTDSPF, um eine DSPF zu erstellen. Ich würde gerne dazwischenkommen und weitere Aktionen auslösen (z.B. die Objektbibliothek ändern und das DSPF in unserem Repository und in unserer Versionskontrolle ablegen. Ich habe aber leider keine Möglichkeit, in die Profound-Software direkt einzugreifen.

[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.