Wartezeit in RPG-Programm einbauen

[Daniel Ritzmann]

Hallo *all

Ich möchte in einem RPG-Programm eine Wartezeit von z.B. 100 Millisekunden einbauen. Dies könnte mit einer Endlosschlaufe, bei welcher die Zeit immer wieder neu ermittelt wird, gelöst werden. Ich bin aber auf der Suche nach einer eleganteren Lösung, bei welcher der Job tatsächlich wartet (keine Systemleistung mehr benötigt!)

Wer hat einen Tip?
Vielen Dank

[mk]

Hallo,

ich meine das Du das nur mit einem DLYJOB
über QCMDEXEC erreichen kannst.

gruss Micahel

[fabax]

Hier ist ein Beispiel in MI (das habe ich irgendwann mal auf einer US-Seite gefunden) das kann man ganz leicht in RPG einbinden und funktioniert einwandfrei.

NbrSec gibt die Anzahl der Secunden an.

H DFTACTGRP(*NO)
DWait pr extproc('_WAITTIME')
D 16
DTemplate ds
D Interval 20u 0
D Options 8 inz(*loval)
DOneSecond s 20u 0 inz(4096000000)
C *entry plist
C parm NbrSecs 15 5
C eval Interval = NbrSecs * OneSecond
C callp Wait(Template)
C move '1' *inlr
C return

Zitat:

---

Original erstellt von Daniel Ritzmann:
Hallo *all

Ich möchte in einem RPG-Programm eine Wartezeit von z.B. 100 Millisekunden einbauen. Dies könnte mit einer Endlosschlaufe, bei welcher die Zeit immer wieder neu ermittelt wird, gelöst werden. Ich bin aber auf der Suche nach einer eleganteren Lösung, bei welcher der Job tatsächlich wartet (keine Systemleistung mehr benötigt!)

Wer hat einen Tip?
Vielen Dank[/quote]

[Dieser Beitrag wurde von fabax am 02. März 2003 editiert.]

[Dieser Beitrag wurde von fabax am 02. März 2003 editiert.]

[Ludger Muhmann]

Hallo Daniel,

eine Möglichkeit wäre es, ein CL mit "CALL" aufzurufen, in dem eine Wartezeit angegeben ist.
Die kleinste Einheit ist hier allerdings 1 Sekunde.

Das CL kann folgendermassen aussehen:
PGM
DLYJOB DLY(1)
ENDPGM

Eleganter wäre es noch, die Wartezeit als Parameter variabel zu übergeben.

Doch wie gesagt, Wartezeit mindestens 1 Sekunde.

mfg. Ludger

[Steven]

Hoi,

ich hab auch sowas ähnliches. Ich programmiere mit RPGLE.

Ich bau gerade als kleine Übung nen Chat. Das System ist einfach:

Eine Eingabe wird in eine Tabelle geschrieben, und dann in einem Subfile eingetragen. Ich hab jetzt aber das Problem das ich den BlockControllsatz mit einem EXFMT Anzeigen muss. Und dann steht das System bis zu einer Eingabe. Danach springt es wieder hoch und lädt das SF erneut. Eine neue Eingabe wird also nur nach dem drücken auf 'ENTER' angezeigt.

Ist es irgendwie möglich, das Subfile alle 3 Sekunden neu zu laden? Ich habs mit dem CL probiert, allerdings ist das Programm in der Wartezeit nicht bedienbar, also bringt es mir nix.

[Fuerchau]

Bei einer Displayfile must du eine DTAQ zuordnen. Dann kannst du ein QRCVDTAQ mit Timeout absetzen.
Wird eine Funktionstaste bzw. Enter gedrückt wird eine entsprechende Nachricht an die DTAQ gesendet, so dass ein nachfolgender READ die Daten dann tatsächlich abholt.

[Steven]

Hi Fuerchau,

genau das will ich ja nicht.
Ich will, das wenn ein neuer Satz in den Chat eingegeben wird, dieser sofort erscheint, und nicht erst nach einer aktualisierung. Praktisch müsste sich das Subfile alle paar Sekunden selbst neu laden, wobei das Programm aber trotzdem verwendbar sein muss, um z. B. etwas in die Eingabezeile einzugeben. P
raktisch eine Endlosschleife, die das SF anzeigt, unten wartet und dann wieder nach oben springt und das SF wieder neu anzeigt.

[Fuerchau]

Trotzdem ist dies die einzige Lösung allerdings mit der WAIT-Funktion von oben in Kombination.

1. DTAQ an die Displayfile anhängen
2. Subfile füllen
3. Schleife mit _WAIT und QRCVDTAQ allerdings mit 0 Sekunden !

Entweder hat der Benutzer was eingegeben dann gibts Daten und kein Timeout, oder es gibt Timeout und ich kann die andere Datenquelle prüfen.

[BenderD]

Hallo,

sowas geht ohne Einschränkungen nur mit Multithreading, sprich nicht in einem 5250 Job und nicht wirklich mit RPG. Du willst nämlich zwei Sachen gleichzeitig machen und dafür brauchst Du zwei Threads.

Dieter Bender

[B.Hauser]

Hallo an alle,

selbstaktualisierende Subfiles sind möglich! Allerdings muss man dabei etwas tricksen.
Kompliziert wird das Ganze, wenn man die Auswahlen sichern muss!

Das Füllen erfolgt im Batch über einen Dauerläufer-Job, der die Subfile-Sätze in eine DataQueue ausgibt.
Die DataQueue wird im Dialog-Programm ausgelesen und in die Subfile umgeladen.

In der Display-File muss das Schlüssel-Wort INVITE auf Dateiebene bedingt (mit Bezugszahl) angegeben werden.
Die DataQueue muss beim Umwandeln der Display-File im Parameter DTAQ hinterlegt werden.
Alternativ kann die Dataqueue auch über einen OVRDSPF gesetzt werden.
Erfolgt eine Eingabe über die Tastatur, wird ein DataQueue-Eintrag mit '*DSPF' auf Stelle 1-5 erzeugt.

Das Dialog-Programm erstellt die Dataqueue, submittet das Füll-Programm. Es muss eine Steuerung eingebaut werden, die den Dauerläuferjob bei Programm-Ende beendet.
Im Dialog-Programm darf für das Subfile-Kontroll-Format kein EXTFMT erfolgen!
Die Bezugszahl für INVITE muss vor dem WRITE des Subfile-Kontroll-Formats auf *ON gesetzt werden.
Die DataQueue steht auf permanentem Empfang (API QRCVDTAQ 5. Parameter Wartezeit = -1).
DataQueue-Einträge, die nicht mit *DSPF beginnen werden in die Subfile geschrieben.
Für DataQueue-Einträge, die mit *DSPF beginnen, wird der Subfile-Kontroll-Satz über READ eingelesen. Die Verarbeitung der Eingaben kann, wie in jedem anderen Dialog-Programm erfolgen.

Übrigens, nur so als kleine Anmerkung, das geht schon seit es die AS/400 gibt, nur kaum einer weiss es!

Birgitta

[BenderD]

Hallo,

soweit die Bemerkung: "e s g e h t" meinen Beitrag betrifft, dann beachte man den genauen Wortlaut:

sowas geht ohne Einschränkungen nur mit Multithreading, sprich nicht in einem 5250 Job und nicht wirklich mit RPG.

Ich will das an einem kleinen Beispiel deutlich machen:

In einem Java Programm (sprich Multithreaded) würde man bei Eingabe einer neuen Auftragsposition die Auftragssume auf einer anderen Anzeige in einem anderen Fenster problemlos automatisch aktualisieren können.
Mit dem von Birgitta erklärten Workaround (der mir sehr wohl bekannt ist) scheitert man real bereits, wenn man auf jeder Anzeige eine laufende Uhr haben wollte. Die Anwendung wird ausgebremst und beim zweiten Fenster auf dem Bildschirm ist eh Ende der Fahnenstange.

Es gibt übrigens eine weitere Einschränkung bei der ganzen Sache: man kann das ganze nicht synchronisieren, wenn mehrere Anforderungen gleichzeitig kommen, werden diese gepuffert, mit seltsamen Effekten für den Benutzer. Über die "Wartungsfreundlichkeit" dieser Lösung möchte ich garnicht erst nachdenken.

Dieter Bender

[KM]

Hallo Daniel,

für Dein Problem gibt es eine ganz einfache Lösung. Benutze doch die externe Prozedur sleep. Siehe Beispiel (Wartezeit 5 Sekunden) !

D SLEEP PR EXTPROC('sleep')
D SECONDS 10U 0 VALUE
*
C CALLP SLEEP(5)

Gruß,
KM