MAX1TB est le paramétrage par défaut pour les nouveaux fichiers logiques créés sur des systèmes RISC

la base de données.
(Le terme « feuille » (« leaf ») est utilisé par les spécialistes de la base de données
de Rochester ; c’est tout simplement un noeud de niveau inférieur de l’arborescence
de racine binaire.)

MAX1TB est le paramétrage par défaut pour les nouveaux fichiers logiques créés
sur des systèmes RISC. Les fichiers logiques que l’on a fait migrer des systèmes
CISC à  RISC ne sont pas automatiquement convertis en MAX1TB et seront des index
MAX4GB (trois octets), sauf conversion explicite.

Pour connaitre les fichiers logiques ayant des index à  trois octets, il faut exécuter
la commande DSPFD (Display File Description) sur chaque fichier logique de la
bibliothèque de la base de données. Si l’on a des fichiers physiques avec clés,
l’index de chacun d’eux peut avoir des index à  trois ou quatre octets. Pour trouver
les fichiers avec des index à  trois octets, il faut exécuter DSPFD sur les fichiers
physiques.

Pour convertir des fichiers logiques d’index à  trois octets en quatre octets,
utiliser CHGLF (ou CHGPF pour des fichiers physiques avec clés). Cette opération
peut durer entre 10 minutes et 12 heures, selon la capacité du système, les tailles
des fichiers, les configurations matérielles et logicielles, et l’utilisation
de SMP. L’utilisation de SMP peut réduire nettement le temps de conversion puisque
le travail de modification d’un fichier logique est réparti entre de multiples
tâches SLIC DBL3 et de multiples processeurs.

Durant le traitement de CHGLF, le fichier est verrouillé, et donc il faut convertir
des fichiers quand les autres jobs n’en ont pas besoin.

Diviser l’entrée en jobs multiples

La présence de plusieurs jobs simultanés exécutant chacun une partie du travail
d’une application peut permettre d’augmenter l’utilisation de la CPU et d’accroître
le débit de l’application. Après avoir déterminé le nombre de jobs à  exécuter,
il reste à  leur répartir les données en entrée et à  les lancer.

C’est peut-être plus facile à  dire qu’à  faire. La méthodologie choisie pour distribuer
l’entrée entre des jobs multiples peut, selon la structure de l’application, demander
un examen approfondi de cette dernière pour recenser les étapes nécessaires.

Si l’on n’a qu’un seul fichier en entrée de transactions à  appliquer à  la base
de données et si l’on a un job pour traiter les données, il faut démarrer plusieurs
instances du job (k instances) et répartir le traitement entre elles. Le premier
job traiterait de l’enregistrement 1 à  l’enregistrement (1 x nbr_enr)/k, le deuxième
job traiterait de l’enregistrement (((1 x nbr_enr)/k) + 1) à  (2 x nbr_enr)/k et
ainsi de suite, où nbr_enr est le nombre d’enregistrements actifs du fichier physique.
Dans un exemple comportant un fichier de 300 enregistrements et trois jobs (k
= 3), les enregistrements traités par chaque job seraient :

Job 1 : De l’enregistrement 1 à  l’enregistrement (1 x 300)/3
(De l’enregistrement 1 à  l’enregistrement 100)

Job 2 : De l’enregistrement (((1 x 300)/3) + 1) à  l’enregistrement (2 x 300)/3
(De l’enregistrement 101 à  l’enregistrement 200)

Job 3 : De l’enregistrement (((2 x 300)/3) + 1) à  l’enregistrement (3 x 300)/3
(De l’enregistrement (201 à  l’enregistrement 300)