CL en version 2

En effet, CL en V2R1 ignorait totalement les données binaires et, quoique pas impossible, l’écriture de DSPSBSDFN aurait demandé beaucoup trop de temps. Appeler l’API et traiter les données de type caractère n’est pas trop difficile, en procédant comme dans la figure 6.

 (((IMG6708)))
Figure 6 : Appeler l’API QWDRSBSD et traiter les données caractères en utilisant les possibilités CL V2R1

Les seuls points un peu délicats sont l’initialisation de la variable CL &Len_SBSI (Length of the receiver variable &SBSI0100) en A de la figure 7 et de &EC_BytPrv (the API error code Bytes provided field) en B de la figure 7. Les deux variables sont définies comme des variables caractères de 4 octets (pour correspondre à la longueur des données Binary(4)) et  initialisées avec la notation hexadécimale. Dans le cas de &Len_SBSI, x’00000168’ correspond à la valeur décimale 360 (longueur déclarée de la variable &SBSI0100), et dans le cas de &EC_BytPrv, x’00000000’ correspond à la valeur décimale 0 (indiquant que les erreurs rencontrées par l’API devraient être exprimées en messages d’échappement). La valeur 360 pour la longueur de la variable réceptrice &SBSI0100 a été obtenue en ajoutant 80 (longueur combinée des champs fixes Bytes returned jusqu’à Number of storage pools de la figure 6, au produit de 10 (le nombre maximum de pools de stockage qui peuvent être définis pour un soussystème), et 28 (la longueur combinée des champs fixes Pool ID jusqu’à Pool activity level qui est renvoyée pour chaque pool de stockage). Cet article n’utilise que les 80 premiers octets de la variable réceptrice ; un prochain article utilisera l’information du pool de stockage.

Le reste du programme est simple (quoique pas vraiment auto-explicite). Le programme accède aux données caractères associées au sous-système en utilisant le built-in %substring (%sst), affiche les résultats en utilisant la commande SNDRCVF (Send/Receive File), puis, soit il rafraîchit l’affichage si la touche Entrée est actionnée, soit il quitte le programme si c’est la touche de commande 3. Jusqu’ici, tout va bien.

Les choses se compliquent un peu au moment de traiter les données basées sur binary(4) (&MaxActJob— Maximum number of active jobs, &CurActJob—Current number of active jobs, et &NbrPools—Number of storage pools) de format SBSI0100. La figure 7 montre le début d’une approche visant à afficher ces valeurs numériques.

(((IMG6713)))
 Figure 7 : Appeler l’API QWDRSBSD et traiter les données caractères et binaires en utilisant les possibilités CL V2R1

En B de la figure 8, le programme d’application est en train de déterminer la valeur à afficher pour le nombre maximum de jobs actifs que le sous-système supporte. Si le sous-système est défini avec MAXJOBS(*NOMAX), la constante *NOMAX doit être affichée en réglant l’indicateur 30 sur «on» (l’indicateur 30 conditionne cette valeur constante dans le fichier d’affichage DSPSBSDSPF de la figure 2, sinon la valeur numérique MAXJOBS de &MaxActJob doit être affichée (indicateur 30 sur «off»). La difficulté est que l’API renvoie le nombre maximum de jobs actifs sous la forme d’une valeur binaire et, comme on l’a mentionné lors de l’initialisation de &Len_SBSI et &EC_BytPrv, CL V2R1ne reconnaît pas les valeurs binaires, et donc des valeurs hexadécimales doivent être spécifiées lorsqu’on détermine la valeur renvoyée par l’API.

Comme l ’API QWDRSBSD indique qu’une valeur Maximum active jobs -1 est renvoyée si MAXJOBS(*NOMAX) est en vigueur, le premier test IF en B de la figure 8 sert à déterminer si -1 a été renvoyé. Il serait intéressant de pouvoir spécifier simplement ‘’If Cond(%sst(SBSI0100 69 4) *EQ x’FFFFFFFF’)», où x’FFFFFFFF’ est la valeur hexadécimale pour -1, mais si vous essayez cela vous constaterez rapidement que les littéraux hexadécimaux ne peuvent pas être spécifiés avec le mot-clé COND (il en résulte une erreur CPD0126— Operand not valid or operator missing in COND). Pour contourner cette limitation, le programme utilise la variable &Neg1, définie en A de la figure 8, où &Neg1 est réglé sur la valeur hexadécimale de 1 négatif binaire. Si le premier test IF en B de la figure 8 est vrai, l’indicateur 30 est réglé sur «on» et le programme commence alors à traiter la valeur renvoyée pour Current number of jobs (&CurActJob) (C dans la figure 8).

Si le premier test IF en B de la figure 8 est faux, l’indicateur 30 est réglé sur «off,» et le programme détermine la valeur spécifiée par l’utilisateur pour le nombre maximum de jobs. Cela se fait en testant le nombre maximum de jobs renvoyés aux variables CL &Pos1, &Pos2, &Pos3, etc. Ces variables CL sont définies en A de la figure 8, de la même manière que &Neg1 est défini et représentent les valeurs hexadécimales pour 1 positif binaire, 2 positif binaire, 3 positif binaire, etc. A noter dans le programme le commentaire «/* etc */» suivant le DCL de &Pos5 et le test IF pour &Pos3 (ainsi que dans quelques autres endroits du programme). Il en est ainsi parce que le nombre maximum qui pourrait être renvoyé est 1000 et que … je n’ai aucune envie de taper, et de publier, un millier de tests DCL et IF. C’est cette obligation de déclarer individuellement—et de tester—toutes les valeurs renvoyées possibles qui justifie ce que j’ai dit plus haut : «Si vous aviez entrepris d’écrire l’application DSPSBSDFN à l’aide des seules possibilités CL de la V2R1, vous n’y seriez probablement pas parvenu». Dans la pratique, on appellerait un programme écrit dans un langage tel que RPG pour convertir les valeurs binaires renvoyées par l’API en valeurs décimales packées que CL traiterait directement. Ou, plus probablement, on écrirait simplement tout le CPP avec un langage comme RPG ou COBOL.