Les files d’attente de données à  l’oeuvre

est subordonné au
programme serveur DTAQSR. Ils communiquent par l’intermédiaire de deux files
d’attente de données : DTAQFIFO et DTAQKEYED. Le programme serveur DTAQSR est
soumis et attend jusqu’à  ce qu’il reçoive un message via la file d’attente de
données DTAQFIFO. Dès réception d’un message, le serveur envoie une réponse
au client via la file d’attente de données DTAQKEYED.

La file d’attente de données DTAQFIFO est classée en ordre FIFO
(premier entré/premier sorti), fournit des informations sur l’émetteur et est
définie par la commande suivante :

CRTDTAQ DTAQ(DTAQFIFO)
+

MAXLEN(40) SENDERID(*YES)



La file d’attente de données DTAQKEYED utilise l’ordre à  clés (keyed)
sans informations sur l’émetteur et est définie par la commande suivante :



CRTDTAQ DTAQ(DTAQKEYED) +

MAXLEN(40) SEQ(*KEYED) +

KEYLEN(6) SENDERID(*NO)

Figure 2, le membre source DTAQPROTO contient des prototypes pour appeler toutes les API de file d’attente de données. Une définition de prototype pour envoyer des données à  une file d’attente de données (QSNDDTAQ) apparaît en A et une autre pour recevoir des données en provenance d’une file d’attente de données (QRCVDTAQ) apparaît en B. En C, les prototypes restants pour les API QCLRDTAQ, QMHQRDQD et QMHRDQM sont définis, bien qu’on ne les utilise pas dans les exemples de programmes, figures 3 et 4. Le mot clé OPTIONS(*VARSIZE) désigne une longueur de zone maximale comme valeur par défaut. Le mot clé OPTIONS(*NOPASS) indique des paramètres optionnels qui ne sont pas obligatoires quand on utilise la commande d’appel de prototype, même si les API demandent que tous les paramètres provenant d’un groupe optionnel soient définis (ou non) ensemble.
Figure 3, le programme client DTAQCL envoie un message à  la file d’attente DTAQFIFO (qui fournit des informations sur l’émetteur) et attend une réponse sur la file d’attente de données DTAQKEYED. Pour accéder à  la réponse correspondante, le programme DTAQCL utilise son propre numéro de job comme clé. En A, les définitions de prototype de copie provenant du membre DTAQPROTO apparaissent avec quelques variables locales. En B, le programme extrait le numéro de job de la SDS (status data structure) du programme. En C, le programme appelle QSNDDTAQ pour envoyer le message trouvé dans DataSnd à  DTAQFIFO, où le serveur en prendra possession. Les paramètres attendus par l’API sont définis dans le membre copie prototype. Sur cet appel, les paramètres optionnels associés à  Dtaq à  clés ne sont pas utilisés en raison du mot clé OPTIONS(*NOPASS) sur la définition de prototype. En D, le programme appelle QRCVDTAQ pour recevoir les données envoyées par le serveur à  DTAQKEYED et les affiche à  l’attention de l’utilisateur.
Figure 4, le paramètre WaitTime définit une valeur négative, indiquant une attente illimitée. La longueur de clé est initialisée à  0 parce que la clé n’est pas utilisée. En A, le programme serveur DTAQSR reçoit le message de DTAQFIFO, avec la variable Sender (Emetteur) contenant le numéro de travail du client. En B, le numéro de travail est extrait de la variable Sender et placé dans la variable Data. Le numéro de travail est également utilisé comme clé. Ensuite, DTAQSR appelle QSNDDTAQ pour placer les données pour DTAQCL sur DTAQKEYED. Le programme DTAQCL utilise son propre numéro de travail comme clé pour déterminer quels messages provenant de DTAQKEYED lui sont destinés.