R : Oui, il
existe un moyen de faire cela en RPG. Vous pouvez spécifier l’utilisation d’une variable pour le nom de zone de données en spécifiant la valeur spéciale *VAR sur le motclé DTAARA. RPG propose deux manières de lire une zone de données. Il y a l’ancienne manière par structure de données externe (USD) de lire une zone de données, et il y a l’utilisation des opcodes IN et OUT pour lire une zone de données.
Je tiens à clarifier cela parce que je rencontre souvent des gens qui confondent les deux méthodes. Ils pensent qu’il faut à la fois définir la structure de données avec UDS et utiliser les opcodes. Bien que le mélange des deux soit autorisé en RPG, cela ne marche pas dans ce cas parce que le nom de la zone de données doit être connu quand UDS le lit au début du programme, et cela signifie que vous ne pouvez pas calculer le nom dans vos C-specs.
Quand vous définissez une structure de données avec UDS, la zone de données doit être une zone de données caractères et elle est lue par le programme quand il démarre et écrite quand le programme se termine.
Par exemple :
D MyDtaAra UDS
D Lastdate 10A
Quand le programme qui contient ce code démarre, il lit une zone de données nommée MyDtaAra. Ce doit être une zone de données caractères de 10 octets de long.
Vous pouvez changer le champ Lastdate de telle sorte que, quand le programme se termine, ce champ soit mis à jour sur disque. Si vous voulez que la structure de données ait un nom différent dans votre programme que celui de la zone de données sur le disque, vous pouvez utiliser le mot-clé DTAARA que montre la figure 1. Cette méthode présente plusieurs inconvénients :
- La zone de données est lue automatiquement quand le programme démarre, donc le nom de la zone de données doit être connu à ce moment-là. Pour cette raison, vous ne pouvez pas calculer le nom dans vos C-specs.
- Les structures de données sont des champs caractères, et donc la zone de données doit être toujours de type caractère.
- Comme RPG ouvre la zone de données pour la mise à jour, placez un verrou dessus quand le programme démarre et ce verrou empêche les autres programmes d’y accéder.
Dans cet exemple, la zone de données OTHERNAME n’est pas lue automatiquement au démarrage parce que je n’ai pas codé un U en colonne 23 de la D-spec. Au lieu de cela, elle est lue quand j’exécute l’opcode IN et elle est écrite quand j’exécute l’opcode OUT. Si je ne veux pas verrouiller la zone de données quand je la lis, je peux enlever la valeur spéciale *LOCK de l’opcode IN, et aucun verrou ne sera alors demandé.
Ce genre de support permet aussi de lire des zones de données décimales (celles qui ont été créées avec TYPE(*DEC) sur la commande CTRDTAARA). Vous faites cela en spécifiant le mot-clé DTAARA sur un champ décimal packé dans mon programme (figure 3). Ce fragment de code démontre aussi comment vous pouvez spécifier le nom de la bibliothèque sur le mot-clé DTAARA. Maintenant, je réponds (enfin !) à votre question. A partir de la V5R2, vous pouvez spécifier une valeur spéciale de *VAR sur le mot-clé DTAARA.
L’option *VAR vous permet d’utiliser une variable pour le nom de la zone de données, comme le montre la figure 4. Ici, le nom de la zone de données est calculé d’après la date courante. Si nous sommes le 12 juillet 2007, il lit une zone de données nommée TOT070712 dans la bibliothèque RECVLIB. Il verrouille la zone de données quand il la lit. Il change ensuite la valeur de la zone de données et utilise l’opcode OUT pour sauvegarder ces changements sur disque. Scott Klement
