SETOBJACC

[woodstock99]

auf 3 .. Automatic adjustment
heisst dalso das System regelt sich selber .
@Pikachu . Wie setzt man das dann richtig um ?

[Fuerchau]

An diesen Schrauben zu drehen macht nun wirklch kaum noch Sinn da die Speicherverwaltung (Paging) doch schon ganz effektiv geworden ist.
Man sollte dann doch schon lieber in die Anwendung schauen, prüfen was die da so treibt und dann dort Verbesserungen durchführen.
Wenn ich mir so per WRKACTJOB die Belastungen ansehe, so frage ich mich bei manchen Programmen wirklich:
CPU 4,4 AuxIO 1592
CPU 32,1 AuxIO 556
CPU 30,3 AuxIO 295

D.h., auch bei viel IO kann das Programm (4,4 Sek) immer noch schnell sein.
Ich hatte mal ein Problem bei einer SQL-Function die ein OPM-Programm aufruft.
Per ODBC kamen so ca. 10 Sätze/Sekunde dann auf den PC.
Nach einer Optimierung (eigenes Caching von Dateizugriffen, Konvertieren in ILE) der z.T. von dem OPM-Programm aufgerufenen Unterprogramme (z.T. Filehandler) kam ich dann auf ca. 150 Sätze/Sekunde. Das ist zwar immer noch nicht schnell aber ist nun mal der Anwendung geschuldet die in dieser SQL-Funktion nun wirklich viel rechnen muss.
Man kann also durchaus die "alten" Anwendungen noch beschleunigen wenn man sie denn analysiert.

[hel400]

.. und ganz grundsätzlich zu *FIXED, QPFRADJ und SHRPOOL:

Steht der Systemwert QPFRADJ auf >0, so werden alle SHARED Pools automatisch angepasst, also auch der hier verwendete "*SHRPOOL1".
Möchte man einen Pool definieren, der NICHT vom OS verändert wird, so muss man den selbst definieren (aber NICHt als SHR- sondern als Userpool, also beim CHGSBSD einen tatsächlichen Wert bei "Speichergröße" angeben!).

Nun zum "*FIXED": Das wird oft falsch interpretiert, hat nichts mit fixer Größe oder sonstetwas zu tun.
Anzeigen u. verändern geht in WRKSYSSTS (ASTLVL(*ADVANCED)), dann mit F11 die Anzeige umschalten.
Rechts wird dann der aktuelle Wert angezeigt - und kann auch verändert werden.
Damit kann man nun den "Expert Cache" ein- u. ausschalten.
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.
Hat aber - wie gesagt - absolut NICHTS mit Größenangaben zu tun.

Fazit:
In einen SHARED-Pool mit SETOBJACC etwas hineinzustellen, macht nicht viel Sinn, weil da sofort der PfrAdjuster (QPFRADJ) wieder hineingreift!

[Fuerchau]

Und wenn sowieso genügend Speicher für sowas zur Verfügung steht dann wird der Standardcache des OS sicherlich schon ausreichen.
Ich hatte das früher mal (V2R2) verwendet als die Platten noch sehr langsam waren und konnte damit Performance gewinnen. Allerdings hatten wir das ausschließlich auf die Indizes beschränkt.

[BenderD]

... nur so am Rande vermerkt; bei sequentieller Verarbeitung wird alles nur einmal gelesen, da bringt ein cache nix...

[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