SYSVAL AUTOVRT

[itec01]

Hallo Zusammen,
bei einem Kunden von uns liegt der SYSVAL von QAUTOVRT bei 10000.
Nun gab es Probleme, dass 5250 Handscanner sich nicht mehr anmelden konnten (monmsg CPF87D7). Habe dann den Wert erhöht, nur wie kann es sein, dass so viele Virtuelle Devices den Wert so hochschaukeln?
Habe hier https://www.mcpressonline.com/progra...irtual-devices gelesen, dass man den Wert eigentlich auf 0 haben sollte. Leider steht auch in dem Bericht, dass es wohl keine Möglichkeit gibt den Wert zu reorganisieren bzw. erkennt, wieso der Wert so hoch ist, sprich wer belegt diese hohe Anzahl .
Hat jemand dazu eine Idee, vielleicht?
Danke schon mal.

Gruß Klaus

[Fuerchau]

Einfach die Devices *DEVD mal per Status prüfen.
- Sind sie einem Subsystem überhaupt noch zugeordnet?
- Sind die Objekte noch i.O.?
Das ist halt der Nachteil, wenn man nicht mit fest benamten ID's (User, Gerät) arbeitet sondern mit QPADEV o.ä.
Hinzu kommen noch u.U. sog tote Jobs im System, die noch Spools haben und somit aus Sicherheitsgründen das Device noch nicht freigeben können.
Habe ich ein benanntes Device "BALDURS1", "BALDURS2" usw. wird es immer wieder vewendet und es entsteht kein Bedarf dauernd was neues zu generierern.
Auch das Wiederverbinden bei Sitzungsabbrüchen klappt dann, weil ein abgebrochener Job QPADEV* nicht wieder verbindbar ist.
Das reduziert dann die Anzahl der Geräte im Schnitt auf 2-3 Sitzungen (mehr braucht selten einer) je User.

[itec01]

Danke Dir.
SELECT OBJNAME,OBJCREATED,OBJATTRIBUTE,OBJDEFINER, LAST_USED_TIMESTA
MP FROM
TABLE(QSYS2.OBJECT_STATISTICS('*ALL','DEVD')) A
Damit habe ich die DEVD ermittelt, die ueralt sind. Werde diese dann löschen.

[K_Tippi]

Moin,
prüf mal ob JOBLOGS im Status Pendig stehen, die halten auch Sperren

Mit Jobprotokollen arbeiten (WRKJOBLOG)

Auswahl eingeben und Eingabetaste drücken.

Jobprotokollstatus . . . . . . . *PENDING *PENDING, *SPOOLED

Zeitraum:
Startzeit und Startdatum:
Startzeit . . . . . . . . . . *AVAIL Zeit, *AVAIL
Startdatum . . . . . . . . . . *CURRENT Datum, *CURRENT, *BEGIN
Endzeit und Enddatum:
Endzeit . . . . . . . . . . . *AVAIL Zeit, *AVAIL
Enddatum . . . . . . . . . . . *CURRENT Datum, *CURRENT, *END
Jobname . . . . . . . . . . . . *ALL Name, generisch*, *ALL
Benutzer . . . . . . . . . . . *ALL Name, generisch*, *ALL
Zahl . . . . . . . . . . . . . *ALL 000000-999999, *ALL

[itec01]

Moin,
Danke, das passt aktuell mit dem wrkjoblog.
Ich würde nun alle devices löchen, deren letzte Benutzung älter als 2 Jahre her ist bzw. das Datum letzte Benutzung NULL ist. Wisst Ihr wieso das Datum NULL ist? Nicht dass ich zu viel lösche.

SELECT OBJNAME,OBJCREATED,OBJATTRIBUTE,OBJDEFINER,
LAST_USED_TIMESTAMP FROM
TABLE(QSYS2.OBJECT_STATISTICS('*ALL','DEVD')) A WHERE
(last_used_timestamp < '2023-01-01' or last_used_timestamp is null)
and objattribute = 'DSPVRT'


Danke.

[KingofKning]

Warum löscht Du nicht alle? Die VRT werden doch in Sekundenbruchteilen bei Bedarf neu angelegt.

GG 2126

[itec01]

OK, wenn das kein Problem ist.
Danke.

[Pikachu]

Welche Sperren können beendete Jobs noch halten, die nicht automatisch aufgehoben werden?

Hinzu kommen noch u.U. sog tote Jobs im System, die noch Spools haben und somit aus Sicherheitsgründen das Device noch nicht freigeben können.

prüf mal ob JOBLOGS im Status Pendig stehen, die halten auch Sperren

[Fuerchau]

Sperren nicht unbedingt, da bei Jobende alle Datensperren zumindest freigegeben werden.
Hauptsächlich belegen tote Jobs Speicher:
- teilweise QTEMP-Objekte
- u.U. jede Menge Spools => Spoolspeicher
- Die internen Jobliste ist ein Array. Die Suche nach einer freien Jobnummer bei Überlauf kann schon mal länger dauern, d.h., der Start eines Jobs kann statt 10ms schon mal 1 Sekunde dauern. Ich habe da schon gesehen, dass pro Minute durchaus 100te Jobs submitted werden als stattdessen eine Prestart-Service zu erstellen.
- Verlangsamung des Work-Managements.

Es ist ja häufig kein Wunder, dass erst mit einer neuen Maschine alles schneller wird, obwohl die alte das auch gekonnt hätte. Man hätte nur wollen müssen;-).

Gerade heute wieder das Problem CLRPFM im laufenden Betrieb mit 1 Minute Wartezeit statt SQL-Delete, da REUSEDLT = *NO steht. Und man wundert sich, wieso die Berechnungen nicht stimmen.

[Pikachu]

Hm? Meine Jobs löschen noch schnell alle Objekte aus ihrer QTEMP bevor sie sich beenden!? Aber das mit den Spools ist ein Problem. Außer man trennt die Spools von den Jobs. Das geht ab irgendeinem V5Rx. Die nächste Jobnummer ist ja schnell ermittelt (vorherige +1 oder 1 bei Überlauf) aber es muß immer geprüft werden damit es keinen anderen Job mit genau gleichem Namen im System gibt. Da sind weniger Jobs besser und kleinere Jobtabellen schneller durchsucht.

[Fuerchau]

Also das mit dem Aufräumen ist schon eher verpönt.
Gerade in SQL vergisst man das "temporary table"-Objekt halt in der QTEMP sitzen.
Und da man auf den realen Close keinen EInfluss hat, kann da schon mal was liegenbleiben.
Um SPLF's aufzuheben fällt mir nur der SNDTCPSPLF ein, man kann den Spool dann an einen User auf dem eigenen System senden. Somit hängen dann alle Spools am Empfangenen Job.
Gut, dass die SPLFNR inzwischen 6-stellig ist.
Aber wirklich empfehlen kann man da nur ein Archivierungssystem.

Ja, und die Job-Tabelle wird im laufenden Betrieb ncht verkleinert sondern nur baim IPL neu aufgebaut.

[Pikachu]

Wie ist das bei anderen Systemen? Übersteht ein Job da auch einen Neustart oder ist da alles weg und muß wieder neu aufgebaut werden? Ist da alles nur temporär im Arbeitsspeicher?