Verwendung QUSLSPL

[Flappes]

Hallo

wir verwenden das API QUSLSPL (SPLF0200) für Spools zu suchen und zu verarbeiten.
Normal liest man eine feste OUTQ, so das nicht so die Masse an Spools erscheinen.
Nun habe ich das Problem das ich OUTQ-übergreifend lesen muss.
In der API kann man leider nicht den Spoolfile-Name mitgeben.
Genauso wenig funktioniert ein generisches Suchen über die Benutzdaten USRDTA.
Beim nativen WRKSPLF F4 kann man alle Angaben generisch suchen.

Hat jemand eine Idee

[Fuerchau]

Wenn Performance eher zweitrangig ist, wie wäre es damit:
https://www.ibm.com/docs/en/i/7.4?topic=services-spool

[Flappes]

Wenn ich deinen Link richtig lese, bekomme ich da aber keine Auflistung der Spools.
Ich müsste Sie halt am besten mit Spoolname und gnereisch aus den USRDATA auslesen.
Ansonsten über alle Spools des Systems zu lesen wäre nicht performant

[camouflage]

Hi,
Hast Du dir die SQL-Funktionen "SYSTOOLS.SPOOLED_FILE_DATA" auch angeschaut?

[Fuerchau]

Was ist ein einem "select * from qsys2.OUTPUT_QUEUE_ENTRIES where ...." auszusetzen?
Du kannst nach allen Feldern ja selektieren, USER_DATA ist da dann auch enthalten.

[Flappes]

Hierbei muss man leider expliziet die OUTQ angeben.

Ich muss eine gewisse Spool im gesamten Suchen.
Hab mein Programm umgestellt.
WRKSPLF *PRINT (inkl. der Angaben)
CPYSPLF *LAST in OUTFILE
per SQL auswerten.

Manchmal muss man wieder die klassischen Wege gehen

[Fuerchau]

Existiert die View OUTPUT_QUEUE_ENTRIES bei dir noch nicht?

select * from qsys2.OUTPUT_QUEUE_ENTRIES where USER_DATA = 'XXX'

[Flappes]

Ich hab mich von der Doku in die Irre führen lassen.
Da wird noch mit Parametern die OUTQ übergeben.

Der Select funktioniert jetzt, allerdings liegt die Antwortzeit bei ca. 25 Sekunden
Über den klassischen Weg dauert es 2 Sekunden

[Fuerchau]

Ist auch kein Wunder, da viele Informationen ebenso per API zusammengestellt werden.
Aber vielleicht ist ja die OUTPUT_QUEUE_ENTRIES_BASIC schneller da sie weniger Infos hat, aber zumindest die, die du brauchst.