Champs RcdLen et DataLen

Après tout, comme l’API connaît la taille des champs RcdLen et KeyNbr, il serait facile de les soustraire de la longueur d’enregistrement pour obtenir la longueur de données, ou inversement.

C’est en effet une bonne question. En fait, c’est principalement une question de limites. Les entiers binaires de quatre octets sont mieux manipulés s’ils se trouvent tous dans une limite de quatre octets. Ainsi, si l’on a des données de 14 octets (comme une liste de noms d’unités ou de bibliothèques avec un seul élément), et si l’on y ajoute les trois entiers, la longueur d’enregistrements est alors de 26 octets, ce qui placerait le prochain enregistrement au milieu d’une limite de quatre octets (figure 7).

À l’adresse x’0021′ du dump vous pouvez voir que x’1A’, qui est la fin de l’entier, se trouve au milieu de la première colonne. Il en est ainsi parce qu’il démarre à l’adresse x’001E’.

Pour maintenir une limite de quatre octets plus efficace, vous pourriez augmenter la longueur d’enregistrement à 28 octets tandis que la longueur des données resterait, bien entendu, à 14 octets (figure 8). Les deux octets qui restent inutilisés importent peu. À présent, dans le dump, ce même entier démarre à x’0020′ et finit à x’0023′, ce qui convient parfaitement.

Pour plus d’efficacité encore, j’ai aussi créé une fonction interne appelée SetIntBoundary() (figure 9). Si la longueur n’est pas exactement divisible par quatre, elle renverra une longueur augmentée. Si elle est exactement divisible, elle renverra la longueur originale.

À présent, le calcul de la longueur dans la figure 3 peut-être modifié pour inclure cette nouvelle fonction (A en figure 10).