SETOBJACC

[hel400]

Da irren Sie sich, Hr. Bender!

Die Funktion "Expert Cache" funktioniert nämlich so:
Das OS "beobachtet", ob ein Job Daten aus einer Datei in sequentieller Reihenfolge liest.
Ist dies der Fall, dann liefert der Expert Cache den nächsten Datenpuffer von Platte in den Hauptspeicher, noch bevor(!!) der entsprechende READ vom jeweiligen Pgm kommt.
(daher sollte man den Expert Cache auch nur in den Pools einschalten, in denen vorwiegend Batchverarbeitung stattfindet, also *BASE).

Bei den heutigen Platten-Zugriffszeiten rückt dieser "Booster" natürlich immer weiter in den Hintergrund, kann in bestimmten Fällen aber immer noch Einiges bringen.

[BenderD]

... das ist prefetching, nicht caching und wann und wie das passiert, m.W. nicht wirklich dokumentiert. Davon ab bringt das wenig, da ja grundsätzlich Blöcke geholt werden und das dann maximal pro Block einen synchronous read zum asynchronous read macht. Caching kann erheblich was bringen für Daten, die mehrfach in kurzer Zeit gebraucht werden, für Indexe z.B. aber auch da ist die Wahrscheinlichkeit durch Eingriffe Verschlechterungen zu produzieren nicht aus dem Auge zu verlieren.

D*B

[Fuerchau]

Sobald ich Dateien als I-Dateien verarbeite und einen READ statt Chain verwende wird sowieso geblockt gelesen. Somit kann ich durchaus viele 1000 Sätze pro Sekunde verarbeiten.
Schau mal bei WRKACTJOB auf die CPU-Zeit im Verhhältnis zur Anzahl IO's.
Wenn es immer am IO läge müsste ich in 1 Sekunde schon mehrere 1000 IO's gemacht haben.
Meist (wie oben schon gesagt) wird eher lange rungerechnet als großartig IO durchgeführt oder es werden Daten gelesen die auf grund eines Filters nicht relevant sind.
Hier hilft dann eher eine LF mit dem passenden Schlüssel (von mir auch Select/Omit) um diese Sätze gar nicht erst zu lesen.
Manchmal könnte bei solchen Programmen tatsächlich SQL helfen.

[woodstock99]

@hel400

man sollte also ein subsystem anlegen mit wert Paging Option USRDFN und sollte dann z.b. im cl mit chgsbsd eine grösse die man benötigt anlegen . danach den pool clearen und das subsystem wieder beenden . habe ich das so halbwegs richtig zusammengefasst ?

wie gesagt evtl bringts was ?!??.

[woodstock99]

@fuerchau

ja man könnte sehr viel rausholen wenn man diesen Monsterjob redesignen würde . aber a habe ich die zeit nicht und b bekomme ich sie auch nicht dieses monster komplett neu zu programmieren . that's the big problem .. mit minimalsten aufwand versuchen irgendwas zu zaubern . ich habe nur mit einem sehr kleinen teil gestet (laufzeit 30 min) die komplette laufzeit und die anzahl reads willst du gar nicht wissen ). hab sowas noch nie gesehen ...

[hel400]

... das ist prefetching, nicht caching und wann und wie das passiert, m.W. nicht wirklich dokumentiert. Davon ab bringt das wenig, da ja grundsätzlich Blöcke geholt werden und das dann maximal pro Block einen synchronous read zum asynchronous read macht. Caching kann erheblich was bringen für Daten, die mehrfach in kurzer Zeit gebraucht werden, für Indexe z.B. aber auch da ist die Wahrscheinlichkeit durch Eingriffe Verschlechterungen zu produzieren nicht aus dem Auge zu verlieren.

D*B

Sobald ich Dateien als I-Dateien verarbeite und einen READ statt Chain verwende wird sowieso geblockt gelesen. Somit kann ich durchaus viele 1000 Sätze pro Sekunde verarbeiten.
Schau mal bei WRKACTJOB auf die CPU-Zeit im Verhhältnis zur Anzahl IO's.
Wenn es immer am IO läge müsste ich in 1 Sekunde schon mehrere 1000 IO's gemacht haben.
Meist (wie oben schon gesagt) wird eher lange rungerechnet als großartig IO durchgeführt oder es werden Daten gelesen die auf grund eines Filters nicht relevant sind.
Hier hilft dann eher eine LF mit dem passenden Schlüssel (von mir auch Select/Omit) um diese Sätze gar nicht erst zu lesen.
Manchmal könnte bei solchen Programmen tatsächlich SQL helfen.

Da irrt Ihr beide!
(oder anders gesagt "da unterschätzt Ihr beide diese Funktion"!)
Nochmals:
Der "Expert Cache" macht genau das, was ich oben beschrieb habe, nämlich die Analyse der Zugriffe im laufenden Betrieb und - wenn möglich - eine Optimierung der Plattenzugriffe.

Wer's nicht glauben mag, kann direkt beim Erfinder nachlesen:
http://www-01.ibm.com/support/docvie...d=nas8N1015953

@hel400

man sollte also ein subsystem anlegen mit wert Paging Option USRDFN und sollte dann z.b. im cl mit chgsbsd eine grösse die man benötigt anlegen . danach den pool clearen und das subsystem wieder beenden . habe ich das so halbwegs richtig zusammengefasst ?

wie gesagt evtl bringts was ?!??.

Ja, so in etwa. Also SBS nicht mit *SHRPOOLn sondern mit Größenangabe anlegen (oder mit CHGSBSD, genau), in diesen Pool kann man dann mit SETOBJACC die gewünwchten Objekte reinstellen.
Nach ENDSBS ist der Platz automatisch wieder freigegeben.

[BenderD]

... angegebene Quellen immer selber sorgfältig lesen!!! Der Haupteffekt von expert cache ist die dynamische Steuerung der Blockgrößen, sprich: wenn Ressourcen CPU und I/O frei sind, werden größeren Blöcke reingeholt, in der (vagen) Hoffnung, dass damit synchronous reads gespart werden.
Bei angenommenen Tausend Sätzen pro Block liegen die erreichbaren Verbesserungen bei sequentiellen Zugriffen unter 1%, wenn denn die Trefferrate optimal ist.
Die einfache Gegenstrategie, segmentieren und parallelisieren ist da ungleich effektiver (auf Mehrprozessor Maschinen allemal), erfordert allerdings software technische Eingriffe.

D*B

[hel400]

... angegebene Quellen immer selber sorgfältig lesen!!! Der Haupteffekt von expert cache ist die dynamische Steuerung der Blockgrößen, sprich: wenn Ressourcen CPU und I/O frei sind, werden größeren Blöcke reingeholt, in der (vagen) Hoffnung, dass damit synchronous reads gespart werden.
Bei angenommenen Tausend Sätzen pro Block liegen die erreichbaren Verbesserungen bei sequentiellen Zugriffen unter 1%, wenn denn die Trefferrate optimal ist.
Die einfache Gegenstrategie, segmentieren und parallelisieren ist da ungleich effektiver (auf Mehrprozessor Maschinen allemal), erfordert allerdings software technische Eingriffe.

D*B

Ach gottchen Hr. Bender, was soll denn das?

In meinem Beitrag #10 schreibe ich, dass der Expert Cache versucht, die Lesevorgänge zu optimieren.
Das hat Ihnen nicht gefallen (obwohl das zu 100% mit der IBM-Beschreibung übereinstimmt).

Daher habe ich das in meinem Beitrag #13 so präzisiert, dass "der nächste Datenpuffer gelesen wird, noch bevor er angefordert wird".
Sie zitieren nun die IBM-Beschreibung, dass (bei freien Ressourcen CPU u. IO) größere Blöcke reingeholt werden.
Das ist ja genau das, was ich (anders formuliert) geschrieben habe ...

Warum der OS-Entwickler die möglichen Performanceverbesserungen als "particularly impressive" bezeichnet und Sie diese aber nur mit "unter 1%" bewerten, möchte ich nicht diskutieren.
Weiters möchte ich darauf hinweisen, dass ich auch nicht behauptet habe, dass der Expert Cache das Allheilmittel ist sondern (ursprünglich) nur erklärt habe, was die Angaben *FIXED und *CALC bewirken, nämlich genau das von mir Beschriebene!!

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