Définitions de la mémoire centrale et du pool de sous-systèmes

selon le système.
Le pool de base est la mémoire
centrale qui reste une fois que vous
avez réservé le pool machine. Vous
pouvez concevoir *Base comme un
pool partagé qu’utiliseront tous les systèmes
pour effectuer le travail, ou bien
le diviser en pools plus petits de mémoire
centrale partagée et privée. Un
pool partagé est une allocation de mémoire
centrale dans laquelle de multiples
sous-systèmes peuvent traiter le
travail. *Machine et *Base sont tous
deux des exemples de pools partagés.
Parmi les autres pools de stockage partagés
que vous pouvez définir, citons
*Interact (pour des jobs interactifs),
*Spool (pour des imprimantes) et
*ShrPool1 à  ShrPool60 (pour des pools
que vous pouvez définir pour vos
propres besoins).
Vous pouvez contrôler les tailles
des pools partagés au moyen de la
commande ChgShrPool (Change
Shared Storage Pool) ou WrkShrPool
(Work with Shared Pools). Pour modifier
la taille du pool ou le niveau
d’activité, il suffit de changer les entrées de l’écran Work with Shared
Pool.
Le sous-système de contrôle par
défaut de l’iSeries, QBase, et le soussystème
de spooling par défaut, QSpl,
sont configurés pour tirer parti des
pools partagés. QBase utilise le pool
*Base et le pool *Interact, et QSpl utilise
*Base et *Spool.
Pour voir les pools qu’un sous-système
utilise, utilisez la commande Dsp
SbsD (Display Subsystem Description).
Par exemple, quand vous exécuterez
la commande

DspSbsD QBase Output(*Print)

vous trouverez les définitions de
pools suivantes pour QBase (si les valeurs
par défaut n’ont pas été changées)
:

QBase ((1 *BASE) (2 *INTERACT))

Les parenthèses délimitent deux
définitions, dont chacune peut contenir
deux parties distinctes (le numéro
et la taille du pool sous-système). Dans
cet exemple, le (1 *BASE) représente
le pool sous-système numéro 1 et une
taille de *Base, indiquant que le système
utilisera tout le pool *Base
comme un pool partagé. Une troisième
partie de la définition de pool, le
niveau d’activité, n’apparaît pas pour
*Base parce que la valeur système
QBasActLvl (Base pool activity level)
maintient le niveau d’activité.
La seconde définition de pool pour
QBase dans cet exemple est (2 *INTERACT).
Comme vous pouvez utiliser
la commande ChgShrPool ou Wrk
ShrPool pour changer le niveau d’activité
du pool partagé *Interact, le niveau
d’activité ne figure pas dans la
description du sous-système et il n’est
pas non plus spécifié quand vous utilisez
la commande Create Subsystem
Description (Crt SbsD) ou ChgSbsD.
Attention à  ne pas confondre la numérotation
des pools de sous-systèmes
avec la numérotation des pools
système. Les deux pools système prédéfinis
pour l’iSeries *Machine et
*Base sont définis comme pool système
1 et pool système 2, respectivement.
La numérotation des pools dans
un sous-système est unique à  celui-ci,
et seules les entrées de routage dans
ce sous-système l’utilisent pour déterminer
quel pool les jobs utiliseront, en
fonction des données de routage associées
à  chaque job. Au fur et mesure
que les sous-systèmes définissent de
nouveaux pools de stockage en plus
des deux pools système prédéfinis, le
système attribue le numéro de pool
système disponible suivant à  utiliser
comme référence sur l’écran Work
with System Status.
Par exemple, avec les pools évoqués
précédemment pour QBase et les
pools suivants pour QSpl

QSPL ((1 *BASE) (2 *SPOOL))

la numérotation des pools système
pourrait correspondre à  la numérotation
des pools de sous-systèmes de la
figure 2.
Un pool privé est une allocation
spécifique de mémoire centrale réservée
à  un sous-système. Généralement,
on utilise un pool privé quand le système
utilise le sous-système de
contrôle QCtl au lieu de QBase. Si vous
changez le sous-système de contrôle
en QCtl, à  IPL, le programme de démarrage
du système lance plusieurs
sous-systèmes (QInter, QBatch, QCmn
et QSpl) conçus pour supporter des
types spécifiques de travail. Bien que
l’utilisation de QBase comme sous-système
de contrôle permette de diviser
la mémoire centrale en pools séparés,
l’utilisation de QCtl est, par nature,
plus facile à  gérer et à  administrer
quant au contrôle du nombre de jobs
et au réglage des performances.
IBM offre les définitions de pool
suivantes pour l’approche sous-systèmes
multiples :

QCTL ((1 *BASE))br>
QINTER ((1 *BASE) (2 *INTERACT))
QBATCH ((1 *BASE))
QCMN ((1 *BASE))
QSPL ((1 *BASE) (2 *SPOOL))

On voit que la configuration initiale
de ces sous-systèmes est semblable à 
celle du sous-système QBase en ce que
les pools partagés réservent des zones
de mémoire centrale pour des types
spécifiques de job. Cependant le partage
des pools ne délivre pas de performances
optimales dans divers environnements
d’exploitation où divers
types de travail sont traités simultanément.
Dans de tels cas, il faudra peutêtre
recourir à  des sous-systèmes avec
des pools privés pour améliorer les
performances.
Dans les définitions de pools de la
figure 3, deux sous-systèmes interactifs
(QInter et QPgmr) fournissent des
pools privés pour les utilisateurs finaux
et les programmeurs. QInter et QPgmr
définissent tous deux des quantités
spécifiques de mémoire centrale à  allouer
au sous-système, plutôt que de
partager le pool *Interact. De plus, les
deux définitions de stockage demandent
un niveau d’activité spécifique,
tandis que les niveaux d’activité de
pools partagés sont maintenus dans le
cadre des définitions de pools partagés
(avec la commande ChgShrPool ou
WrkShrPool). La configuration de pool
privé dans cet exemple, avec des niveaux
de mémoire centrale et d’activité
privés, prévient la contention de
ressources indésirables entre les utilisateurs
finaux et les programmeurs.
La figure 3 montre également
comment on peut utiliser des soussystèmes
batch multiples. Trois sous-systèmes batch – QBatch, DayQ et QPgmrB – assurent,
respectivement, le traitement de jour et de nuit des jobs
batch soumis par opérateur, le traitement de jour par les utilisateurs
finaux de jobs courts, et les compilations de programmes.
Un sous-système de communications séparé,
QCmn, est configuré pour gérer les éventuelles requêtes de
communications, et QSpl se charge du spooling.
Le choix entre les pools partagés et les pools privés dépend
de la capacité de stockage du système. Comme les
pools partagés permettent une utilisation efficace de la mémoire
centrale en permettant à  plus d’un sous-système de
partager un pool de stockage, il est judicieux d’utiliser les
pools partagés dans le cas d’un système dont la mémoire
centrale est limitée. En revanche, les pools privés fournissent
un pool réservé de mémoire principale et des niveaux d’activité
qui sont constamment à  la disposition d’un sous-système
sans contention de la part de tout autre sous-système. Ils
sont faciles à  gérer dans un contexte de sous-systèmes multiples.
Par conséquent, les pools privés conviennent à  un
système doté d’une mémoire centrale abondante.