SETOBJACC

[BenderD]

Standard=*FIXED (also AUSgeschaltet). Stellt man auf "*CALC", so ist der Expert Cache eingeschaltet.
Damit versucht das OS, die Einlesevorgänge zu optimieren - kann besonders bei sequentieller Verarbeitung zu verbesserungen führen.

... auch die eigenen Beiträge sollte man genau lesen...
das ist halt schnöde falsch!!! bei sequentieller Verarbeitung bringt das wenig (max. 1 Prozent), die "impressive improvements" kann man nur bei Daten erwarten, die häufig gelesen werden.

In dem Sinne war auch der Denkansatz des OP falsch: wenn ich was mit SETOBJACC Speicher resident mache (das ist die Strategie von expert cache an den logischen Endpunkt gebracht!!!), dann nehme ich nicht die größte Datei und keine, die sequentilell verarbeitet wird, sondern suche die mit der höchsten Lesehäufigkeit!!!

D*B

[hel400]

.

Schon klar Hr. Bender, Sturheit kann man nicht kaufen, die hat man oder hat man nicht ...

Also, der Reihe nach:

... auch die eigenen Beiträge sollte man genau lesen...
das ist halt schnöde falsch!!! bei sequentieller Verarbeitung bringt das wenig (max. 1 Prozent), die "impressive improvements" kann man nur bei Daten erwarten, die häufig gelesen werden.

Erstens ist mir immer noch ein Rätsel, woher Sie diese ominösen "max. 1% Verbesserung" nehmen.

Weiters meinen Sie, dass das bei sequentiellem Lesen nicht viel bringt.

In dem von mir verlinkten Artikel (auf den Sie sich ja nun auch beziehen) steht allerdings klar u. deutlich:
Expert Cache provides the best results under the following conditions:
The data reference pattern of the job is sequential. Expert Cache can provide a significant benefit to jobs with a high percentage of DASD I/Os to sequential areas of data."

Soweit zum "sequentiell ist schnöde falsch" ...

Weiters steht ganz klar "Ausprobieren und messen"(!), ob das den gewünschten Erfolg bringt (Zitat "...measurement ...use of advanced tools which might require a great deal of time and Expertise..."). Sie schütteln die "max 1% Verbesserung" aber im Vorbeigehen aus dem Ärmel, auch nicht schlecht.

...
In dem Sinne war auch der Denkansatz des OP falsch: wenn ich was mit SETOBJACC Speicher resident mache (das ist die Strategie von expert cache an den logischen Endpunkt gebracht!!!), dann nehme ich nicht die größte Datei und keine, die sequentilell verarbeitet wird, sondern suche die mit der höchsten Lesehäufigkeit!!!
D*B

Haben Sie die ursprüngliche Frage des OPs eigentlich wirklich gelesen?
Diese lautete doch ganz klar:
"... da ein Job bei uns sehr viele I/Os erzeugt wollte ich
die Dateien mit den meisten I'Os in den Hauptspeicher laden um eine bessere Laufzeit zu erzielen".

Er schreibt überhaupt nicht von großer Datei, sondern "meiste I/Os", also hatte er genau den gleichen Denkansatz, den Sie selbst nun empfehlen ...

Und zum Abschluss ganz generell:
Ob diese Funktion nun bei
- Dateien, von denen eine große Anzahl an Sätzen gelesen wird
oder bei
- Dateien, deren Sätze oftmals eingelesen werden
mehr bringt, sei dahingestellt.
Expert Cache VERSUCHT das zu optimieren - allerdings sollte man das durch Messen/Beobachten verifizieren.
(und genau das empfiehlt auch die IBM, nicht mehr und nicht weniger!!).

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