View Full Version : CALL in CL ohne Interaktion
Hallo zusammen,
es wäre jetzt etwas kompliziert alle Hintergründe zu erklären und hoffe jemand kann mir auch ohne ausführliche Erläuterung weiter helfen?
Ich habe ein CL Programm und in diesem MUSS ich ein call auf ein Programm machen welches einen Bildschirm öffnet. Ich will aber sofort wieder aussteigen ohne etwas zu tun. meine Frage nun, ist so etwas möglich ohne dass ich F3 drücken muss? Sozusagen ein CALL mit sofortigem abbruch ...
ich kann nicht in das gerufene Programm eingreifen, sprich die Quelle ist nicht verfügbar.
Vielen dank im Voraus
es wäre jetzt etwas zu kompliziert alle Varianten zu erklären und ich hoffe du verstehst meine Antwort auch ohne ausführliche Erklärung:
ja, das geht, wie so vieles!
Hallo zusammen,
es wäre jetzt etwas kompliziert alle Hintergründe zu erklären und hoffe jemand kann mir auch ohne ausführliche Erläuterung weiter helfen?
Ich habe ein CL Programm und in diesem MUSS ich ein call auf ein Programm machen welches einen Bildschirm öffnet. Ich will aber sofort wieder aussteigen ohne etwas zu tun. meine Frage nun, ist so etwas möglich ohne dass ich F3 drücken muss? Sozusagen ein CALL mit sofortigem abbruch ...
ich kann nicht in das gerufene Programm eingreifen, sprich die Quelle ist nicht verfügbar.
Vielen dank im Voraus
Ich hoffe es gibt auch och normal Leute hier im Forum?
Für Spinnerantworten habe ich keine Zeit...
Tja, mir fällt dazu eigentlich nichts ein.
1.
Wenn du das Programm im Batch aufrufst, gibts beim Open der DSPF leider eine Abbruchmeldung.
2.
Wenn du das Programm im Dialog aufrufst, sitzt ein User davor, der dann F3 drücken kann (wenn er denn will).
Ansonsten wirds da wohl doch sehr kompliziert.
Im Prinzip musst du dir einen Serverjob schreiben, der ähnlich wie die TCP-5250-Job's ein Bildschirmdevice emuliert.
Per OVRDSPF kannst du dann die DSPF an dieses emulierte Device hängen.
Dann rufst du das Programm auf und dein Serverjob sendet die F3-Taste.
Andererseits frage ich mich wirklich, was denn ein Programmcall ohne dass das Programm was tun soll für einen Zweck hat.
Hallo Fuerchau,
das wär zumindest eine Möglichkeit.
Das Programm muss einmal aufgerufen werden, um spezielle Parameter zu aktivieren. Da dies aber im Batch läuft, wie Du bereits richtig vermutet hast, kann niemand F3 drücken.
da würde mir schon noch ein wenig mehr einfallen...
- break message Handler
- separater Prozess
- selbst das mit dem interaktiven Prozess, das ließe sich nocht tricksen
aber da der Frager ja keine Zeit für Spinnereien hat und klare Antworten nicht versteht...
Tja, mir fällt dazu eigentlich nichts ein.
1.
Wenn du das Programm im Batch aufrufst, gibts beim Open der DSPF leider eine Abbruchmeldung.
2.
Wenn du das Programm im Dialog aufrufst, sitzt ein User davor, der dann F3 drücken kann (wenn er denn will).
Ansonsten wirds da wohl doch sehr kompliziert.
Im Prinzip musst du dir einen Serverjob schreiben, der ähnlich wie die TCP-5250-Job's ein Bildschirmdevice emuliert.
Per OVRDSPF kannst du dann die DSPF an dieses emulierte Device hängen.
Dann rufst du das Programm auf und dein Serverjob sendet die F3-Taste.
Andererseits frage ich mich wirklich, was denn ein Programmcall ohne dass das Programm was tun soll für einen Zweck hat.
kuempi von stein
20-06-08, 15:46
hehe, der war gut.
Endlich konnte ich mal wieder lachen.
@shorty
auch wenn die Hintergründe zu erklären schwierig ist...
aber etwas mehr Info oder ein paar Code-Beispiele wären nett.
Benders Antwort war alles andere als Spinnerhaft...
it depends on...
k.
Ich habe ein CL Programm und in diesem MUSS ich ein call auf ein Programm machen welches einen Bildschirm öffnet. Ich will aber sofort wieder aussteigen ohne etwas zu tun. meine Frage nun, ist so etwas möglich ohne dass ich F3 drücken muss? Sozusagen ein CALL mit sofortigem abbruch ...
Was ähnliches habe ich mal alleine mit CL realisiert. Ich habe eine DSPF zuerst nur angezeigt (1. CLP), dann eine länger laufende Prozedur zur Initialisierung aufgerufen (RPG/COBOL) und dann ein 2.CLP oder RPG, und in diesem erst später die Eingaben des Bedieners eingelesen, welche dieser in der DSPF inzwischen erfaßt hatte. Der Trick bestand darin, beim Ende des 1.CLPs die DSPF nicht zu schließen, und beim 2. Programm vorauszusetzen, daß die DSPF bereits offen ist, und daß sie Daten enthält, die nur noch eingelesen werden müssen. Dafür habe ich nur wenige Attribute bzw. DDS-Befehle benötigt. Ich habe die DSPF also munter als Datenbereich benutzt, in dem quasi "Parameter" zwischen den Programmen übergeben wurden.
Auch das Öffnen von DSPFs durch Batchprogramme war auch kein Problem. Ich habe für sie, wenn ich mich recht erinnere, nur im 1. Schritt eine DEVD ALLOCATED. Diese darf natürlich nicht angemeldet sein; wenn sie abgemeldet und z.B. QINTER zugeordnet ist, kann man sie aber einfach allocaten, und dann öffnen.
Wenn Du die Aufgabe näher beschreibst, kann man vielleicht mehr dazu beitragen, und konkreter darauf eingehen.
Danke UFK,
das reicht mir schon als Antwort. Damit komme ich schon zurecht. Brauchte nur ein paar Denkanstöße.
Wenigstens zwei die konstruktive Beiträge leisten konnten, vielen Dank an UFK und Fuerchau.
Und der Rest: dumme Antworten bringen kann jeder. Aber von Laien erwatet man eben laienhaftes Verhalten.
Der Threat kann geschlossen werden. Ich brauch nicht mehr und werde auch nicht mehr darauf antworten.
Danke und tschüß