Journalreceiver Abhängedatum im CL auslesen

[becama]

Hi *all,

wie kommt man am besten das Abhängedatum eines Receivers? Ich möchte es im CL auslesen und dann evtl. den/die uralten Receiver löschen.

Danke

[KingofKning]

Was hälst Du denn von DSPJRNRCVA?

In Spool-Datei und dann Datei im CL auslesen

GG 4488

[becama]

Den holprigen Umweg über ne Spoolfile wollte ich nicht gehen. Evtl. gibt es ja die Infos in irgendwelchen Systemtabellen, die ich anzapfen kann.

[Fuerchau]

Journalreceiver sind keine Table-Objekte. Vor allem wenn sie abgehängt sind haben sie ja nochnicht mal einen Journalbezug.

[becama]

Schade, aber irgendwo muss die Kiste das doch ablegen. Aber nur wo? Und vor allem, wie kommt man dran? Über ne API?

[Christian Bartels]

API QjoRtvJrnReceiverInformation hilft, aber dazu muss das CL-Programm als ILE-Programm erstellt werden (Befehl: CRTBNDCL).

Der Beispielcode könnte so aussehen:

DCL VAR(&RECEIVER) TYPE(*CHAR) LEN(20)
DCL VAR(&BUFFER) TYPE(*CHAR) LEN(512)
DCL VAR(&BUFLEN) TYPE(*INT)
DCL VAR(&DETDATE) TYPE(*CHAR) LEN(13)
...
CHGVAR VAR(&RECEIVER) VALUE('RECEIVER LIBRARY ')
CHGVAR VAR(&BUFLEN) VALUE(512)
CALLPRC PRC('QjoRtvJrnReceiverInformation') +
PARM((&BUFFER *BYREF) (&BUFLEN *BYREF) +
(&RECEIVER *BYREF) ('RRCV0100' *BYREF))
CHGVAR VAR(&DETDATE) VALUE(%SST(&BUFFER 109 13))

...

Mit freundlichen Grüßen,
Christian Bartels.

[BenderD]

Hi *all,

wie kommt man am besten das Abhängedatum eines Receivers? Ich möchte es im CL auslesen und dann evtl. den/die uralten Receiver löschen.

Danke

... Abhängezeitpunkt und create Zeitpunkt des Folgereceivers sind identisch - denk mal drüber nach. DSPOBJD und RTVOBJD kennst Du ja hoffentlich...

D*B

[becama]

DANKE den Vorschlag mit dem API probiere ich mal aus.

Der Vorschlag mit DSPOBJD ist auch geil, man muss nur das Erstellungsdatum in ODCDAT und die Zeit ODCTIM nehmen und der lfd. Nr. des Journalrcv 1 subtrahieren.

Schon hat man den Namen des Receivers den man löschen kann, sofern er in das Zeitfenster passt, das man löschen will. Bingo

DANKE Guru Bender und schönes Wochenende

[B.Hauser]

Bevor Du Dir allerdings mit dem API die Fingerchen brichst, oder zunächst mit einem CL-Befehl eine Tabelle/Datei generierst und dann darauf zugreifst, prüfe ob die die UDTF Object_Statistics in der Bibliothek QSYS2 nicht die gewünschten Informationen liefert.

Beispiel: Anzeige aller Journal Receiver auf dem System:

Select x.* from Table(Object_Statistics('*ALL', '*JRNRCV')) x
Order By ObjLib, ObjName;

Birgitta

[becama]

WOW so etwas hatte ich mir erhofft. Danke Birgitta!!

Allerdings greift bei mir der select ins Leere. Und die Spalte ObjLib gibt's nicht. Ich mach das im grünen SQL unter 6.1.

[BenderD]

Bevor Du Dir allerdings mit dem API die Fingerchen brichst, oder zunächst mit einem CL-Befehl eine Tabelle/Datei generierst und dann darauf zugreifst, prüfe ob die die UDTF Object_Statistics in der Bibliothek QSYS2 nicht die gewünschten Informationen liefert.

Beispiel: Anzeige aller Journal Receiver auf dem System:

Select x.* from Table(Object_Statistics('*ALL', '*JRNRCV')) x
Order By ObjLib, ObjName;

Birgitta

... was soll da der Vorteil sein? Das sind doch unausgegorene Beta Gimmicks - ohne praktischen Wert. Zur Illustration was ich da meine ein Auszug aus offiziellen Unterlagen:
"In IBM® i 7.3, many new result columns were added to the QSYS2.OBJECT_STATISTICS() UDTF. By adding columns to this UDTF, any customer views which reference the UDTF are left in an unusable state."
Quelle: https://www.ibm.com/support/knowledg...sDBObjStat.htm

Am Rande sei vermerkt, dass dieser Kram nur ein mit heißer Nadel gestrickter SQL Wrapper für DSPOBJD output(*outfile) ist, der schlechter zu bedienen ist als das Original.

D*B