Maigre et concentré

répercuté les changements sur le côté source.

Ces 46 premiers octets, comme les illustre la figure 4, contiennent une information descriptive qui identifie le programme, le job et l’utilisateur particulier qui a effectué le changement. A moins que votre logiciel de replay côté cible ait une dépendance véritable par rapport à la présence et au transport de la totalité des 46 octets dans de telles données (et très peu ont cette dépendance), vous constaterez peutêtre qu’il est judicieux d’éliminer un peu de gras en amaigrissant une bonne partie de l’information descriptive. (Pour plus d’informations sur la présentation d’une entrée de journal type, voir l’encadré « Une entrée de journal type ».)

Cette métadonnée descriptive se présente sous diverses formes et tailles. Par défaut, la plupart des journaux sont configurés de manière à capturer les trois principaux : job, profil utilisateur et nom de programme. Ensemble, ces trois gros consomment 46 octets de données descriptives supplémentaires (26 pour le programme, 10 pour le job et 10 pour le profil utilisateur) chaque fois que votre application change ou qu’elle ajoute une nouvelle ligne à une table.

Soit un job batch nocturne qui met à jour les soldes de 1 million de comptes, ajoute des enregistrements détail pour 300 000 de plus, et écrit des lignes d’historique pour 200 000. Au moment où ce job batch unique se termine, le journal a été visité 1,5 millions de fois. Et, chaque fois, il a transporté comme excédent de bagage, 46 octets supplémentaires nous disant et nous répétant que nous fonctionnons encore sous le même profil utilisateur, que nous exécutons encore le même programme, et que nous utilisons encore le même job batch.

En peu de temps, c’est beaucoup d’octets supplémentaires qui sont envoyés par le tuyau de communication. Votre côté cible a-t-il vraiment besoin qu’on lui rappelle 1,5 millions de fois la même réalité ? Si ce n’est pas le cas, c’est l’occasion d’éliminer quelques octets et de ne jamais les envoyer sur le fil.

Voulez-vous éliminer ce gras ? Vous le pouvez. Il suffit d’émettre une commande CHGJRN appropriée s’appliquant au journal local côté source, et de spécifier la technique à employer pour réduire l’en-tête ou chaque entrée du journal.

Il existe deux techniques principales pour réduire la taille de la portion non ESD de chaque entrée de journal. Premièrement, vous pouvez décider d’éliminer les 46 octets et de n’en garder aucun. C’est l’option minimize fixed-length header et vous pouvez le spécifier sur une commande change-journal, qui se présenterait ainsi :

    CHGJRN Jrn(mylib/myjrn)
    JrnRcv(*GEN)
    RcvSizOpt(*MINFIXLEN)

Ou bien, vous pouvez être sélectif et garder quelques informations d’en-tête non-ESD descriptives (celles que vous jugez les plus essentielles) et éliminer le reste. Il suffit de décider laquelle des trois principales vous voulez vraiment garder puis d’utiliser la puissance du paramètre FIXLENDTA sur la commande CHGJRN.
Si vous ne vouliez enregistrer que le profil utilisateur avec chaque entrée du journal, la commande ressemblerait à ceci :

    CHGJRN Jrn(mylib/myjrn)
    JrnRcv(*GEN) FixLenDta(*USR)

Si vous vouliez avoir une idée du nombre d’octets que vous pourriez éliminer dans votre propre site par l’une de ces techniques, l’approche est fort simple. Premièrement, utilisez la commande DSPJRN pour afficher un jeu de récepteurs de journaux contenant vos entrées de journal vers un fichier de sortie. Exécutez la requête suivante sur le fichier de sortie résultant :

Select count(*) * 46 as BytesReduced From yourlib/yourOutfile Where JOJOB != ‘*OMITTED’

La requête isole seulement les entrées du journal qui n’ont pas déjà eu les métadonnées dans leurs en-têtes omises. (Les entrées de journal induites par SMAPP sont normalement mélangées avec d’autres entrées de journal plus traditionnelles et auront des en-têtes rétrécis d’où les 46 octets ont déjà été éliminés ; par conséquent, nous ne voulons pas les compter deux fois). Elle compte ensuite combien d’entrées de journal ont des en-têtes complets et multiplie ce chiffre par 46 octets pour représenter le nombre d’octets maximum que nous pouvons espérer économiser.