SETOBJACC

[Fuerchau]

Nun, viele IO's auf einer Datei deuten gerade nicht auf sequentielles lesen sonder auf viele (wiederholte) Chains hin. Somit prophitiert man nicht von sequentiellen Optimierungen.
Wie von mir schon beschrieben konnte ich mit eigenem Cache (Tabelle mit %lookup)
a) die Anzahl der Lesevorgänge von über 100.000 auf unter 100 bringen
b) die Gesamtlaufzeit um den Faktor 15 verringern
Da man nun mal nicht alleine auf dem System ist kann ich auch nicht beurteilen ob und wann tatsächlich gelesen oder nur vom Systemcache geladen ist.

Und ob sequentielle Optimierung tatsächlich etwas bringen wenn eine Tabelle per REUSEDLT(*YES) total gestreut verteilt liegt wage ichauch zu bezweifeln.
Hier ist ggf. ein RGZPFM nach LF-Sortierung vielleicht sogar effektiver.

[woodstock99]

irgendwie funktioniert das nicht so .

ich ändere den pool mit CHGSBSD auf meine gewünschte grösse .

wenn ich mit wrkshrpool mir das ansehe ändert sich kein wert des Pools. Wenn ich mir es aber mit WRKSYSSTS F11 ansehe dann ändert sich hier der wert des pool .

nun setze ich ein CHGSHRPOOL ab um die Paging option *calc zu setzen .


schau ich mir jetzt die werte mit wrkshrpool an . steht hier bei paging option der wert *calc aber die grösse despool ist immer noch unverändert .


sehe ich mit wiederrum des wert mit wrksyssts f11 an steht hier noch *Fixed .


????????????????

einmal ändert er es hier und einmal da ?? sollten die anzeigen nicht die gleichen werte anzeigen ?

[woodstock99]

hat jemand ein kleines beispiel wie ich das ganze mit usrdfn usw hinbekomme ?

[BenderD]

... ist denn der Job überhaupt I/O bound? Wie lange läuft denn der Job insgesamt und wieviel CPU verbraucht er dabei? Bei einem Batchjob ist das leicht zu ermitteln aus der Jobstart und der completion message in der History (DSPLOG MSGID(CPF1100) für den Zeitraum), oder im Joblog.

D*B

[hel400]

Hallo Woodstock,

ich denke, dass Du hier 2 Dinge verwechselst bzw. vermischst.
Einerseits SETOBJACC mit Userpools und andererseits den Expert Cache.

Beides gleichzeitig solltest Du nicht ausprobieren, sondern Schritt für Schritt. Nur so kannst Du dann ermitteln, was Dir eine Verbesserung bringt (und ob das ÜBERHAUPT etwas nützt ...).

Hier also in Kurzform:

Expert Cache:
WRKSYSSTS ASTLVL(*ADVANCED)
--> F11 einschalten mit "*CALC", ausschalten mit "*FIXED" (und vergiss USRDFN!)


SETOBJACC:
zunächst das Subsystem mit den Pooldefinitionen definieren:
CRT-/CHGSBSD subsystemname POOLS((1 *BASE) (2 10000 20))
In diesem Beispiel definierst Du also einen Userpool mit 10MB und ActivityLvl 20 (alles nur Beispiele). Warum als erster der "*BASE" steht --> siehe weiter unten!
Wichtig: Der Pool Nummer "2" ist also Dein Userpool, in den Du mit SETOBJCC Deine Objekte reinstellen musst. Dieser Pool wird durch den PerformenceAdjuster (Systemwert QPFRADJ) NICHT verändert, da es kein Sharedpool ist!
Dann die Objekte laden:
SETOBJACC OBJ(xxx) POOL(subsystemname 2)
Dabei gibt's dann im Joblog bei jedem Objekt eine Meldung, wieviel Speicher in diesem Pool zur Verfügung stand und wieviel vom Objekt verwendet wurde.

Zur Erklärung, warum als erstes der *BASE-Pool angegeben werden sollte:
Der Job, den Du in diesem Subsystem dann ausführst, wird ja wohl auch Objekte aufrufen, die Du NICHT mit SETOBJACC vorgeladen hast (andere Programme, Dateien etc,..)
Diese werden dann automatisch in den *BASE-Pool geladen. Wäre dieser nicht angegeben, so könnten diese Objekte Deinen Userpool ("2") zum "Übergehen" bringen.

Alles klaro?

[Fuerchau]

Ich sehe nicht, dass der Job im selben Subsystem laufen muss wie der Pool der geladenen Objekte.
Dann würde ich ja nichts gewinnen.
Außerdem ist nicht beschrieben, ob der SETOBJACC das Paging für die Daten dieser Objekt aushebelt.
Ich stimmer da Dieter eher zu dass die CPU-Zeit des Jobs wahrscheinlich ungleich höher ist als die IO's.

[hel400]

Ich sehe nicht, dass der Job im selben Subsystem laufen muss wie der Pool der geladenen Objekte.

Stimme ich gerne zu - in meinem Beispiel ist beides in einem Pool, ist aber absolut kein Muss.
(wenn mich nicht alles täuscht, wird von IBM die Trennung Daten/Job sogar empfohlen, möchte ich jetzt aber nicht schwören).
Die Definition von "*BASE" würde ich aber auf alle Fälle so machen, dann kann "nichts passieren".

Außerdem ist nicht beschrieben, ob der SETOBJACC das Paging für die Daten dieser Objekt aushebelt.

Wo ist das nicht beschrieben?
In meinem Beispiel? (will ja auch nicht das Manual neu schreiben).
Oder in den IBM-Publikationen dazu? (da steht's nämlich schon).

Ich stimmer da Dieter eher zu dass die CPU-Zeit des Jobs wahrscheinlich ungleich höher ist als die IO's.

Habe ich auch nie bestritten.
Der Fragesteller wollte aber (u.A.) wissen, wie er SETOBJACC anwenden kann, und das habe ich beschrieben ...

[woodstock99]

Danke @hel400 und natürlich auch an die anderen ..