SETOBJACC

[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 ..