RECEIVE_AND_POST

Le verbe RECEIVE_AND_POST reçoit les données d’application et les informations d’état de façon asynchrone. Cela permet au programme de transaction local (TP) de poursuivre le traitement pendant que les données arrivent toujours à l’unité logique locale (LU).

Bien qu’une RECEIVE_AND_POST asynchrone soit en attente, les verbes suivants peuvent être émis sur la même conversation :

  • DEALLOCATION (AP_ABEND_PROG, AP_ABEND_SVC ou AP_ABEND_TIMER)

  • GET_ATTRIBUTES

  • GET_TYPE

  • REQUEST_TO_SEND

  • SEND_ERROR

  • TEST_RTS

  • TP_ENDED

    Cela permet à une application d’utiliser un RECEIVE_AND_POST asynchrone pour recevoir des données. Bien que le RECEIVE_AND_POST soit en attente, il peut toujours utiliser SEND_ERROR et REQUEST_TO_SEND. Il est recommandé d’utiliser cette fonctionnalité pour une prise en charge asynchrone complète. Pour plus d’informations sur la façon dont un TP reçoit des données et comment utiliser ce verbe, consultez Remarques dans cette rubrique.

    La structure suivante décrit le bloc de contrôle de verbe (VCB) utilisé par le verbe RECEIVE_AND_POST .

Syntaxe

  
struct receive_and_post {  
    unsigned short      opcode;  
    unsigned char       opext;  
    unsigned char       reserv2;  
    unsigned short      primary_rc;  
    unsigned long       secondary_rc;  
    unsigned char       tp_id[8];  
    unsigned long       conv_id;  
    unsigned short      what_rcvd;  
    unsigned char       rtn_status;  
    unsigned char       fill;  
    unsigned char       rts_rcvd;  
    unsigned char       reserv4;  
    unsigned short      max_len;  
    unsigned short      dlen;  
    unsigned char FAR * dptr;  
    unsigned char FAR * sema;  
    unsigned char       reserv5;  
};   

Membres

opcode
Paramètre fourni. Spécifie le code d’opération de verbe, AP_B_RECEIVE_AND_POST.

opext
Paramètre fourni. Spécifie l’extension d’opération de verbe, AP_BASIC_CONVERSATION.

reserv2
Champ réservé.

primary_rc
Paramètre retourné. Spécifie le code de retour principal défini par APPC à l’achèvement du verbe. Les codes de retour valides dépendent du verbe APPC émis. Pour connaître les codes d’erreur valides de ce verbe, consultez Codes de retour.

secondary_rc
Paramètre retourné. Spécifie le code de retour secondaire défini par APPC à l’achèvement du verbe. Les codes de retour valides dépendent du verbe APPC émis. Pour connaître les codes d’erreur valides de ce verbe, consultez Codes de retour.

tp_id
Paramètre fourni. Identifie le TP local. La valeur de ce paramètre est retournée par TP_STARTED dans l’appel du TP ou par RECEIVE_ALLOCATE dans le TP appelé.

conv_id
Paramètre fourni. Fournit l’identificateur de conversation. La valeur de ce paramètre est retournée par ALLOCATEin l’appel du TP ou par RECEIVE_ALLOCATE dans le TP appelé.

what_rcvd
Paramètre retourné. Indique si l’état des données ou de la conversation a été reçu. Les valeurs possibles sont répertoriées en suivant la section Membres

rtn_status
Paramètre fourni. Indique si les indicateurs d’état des données et de conversation doivent être retournés dans un appel d’API.

  • AP_NO spécifie que les indicateurs doivent être retournés individuellement sur des appels distincts du verbe.

  • AP_YES spécifie que les indicateurs doivent être retournés ensemble, à condition que les deux soient disponibles. Les deux peuvent être retournés lorsque :

    La mémoire tampon de réception est suffisamment grande pour contenir toutes les données qui précèdent l’indicateur d’état.

    Le paramètre de remplissage spécifie BUFFER ou LL, et les données sont le dernier enregistrement logique avant l’indicateur d’état.

    fill
    Paramètre fourni. Spécifie la façon dont le TP local reçoit des données.

    Utilisez AP_BUFFER pour indiquer que le TP local reçoit des données jusqu’à ce que le nombre d’octets spécifiés par max_len soit atteint ou jusqu’à la fin des données. Les données sont reçues sans tenir compte du format d’enregistrement logique.

    Utilisez AP_LL pour indiquer que les données sont reçues au format d’enregistrement logique. Les données reçues peuvent être les suivantes :

  • Enregistrement logique complet.

  • Partie d’octets max_len d’un enregistrement logique.

  • Fin d’un enregistrement logique.

    rts_rcvd
    Paramètre retourné. Indique si le tp partenaire a émis REQUEST_TO_SEND. Les valeurs possibles sont les suivantes :

  • AP_YES indique que le tp partenaire a émis REQUEST_TO_SEND, ce qui demande que le TP local modifie la conversation en état RECEIVE.

  • AP_NO indique que le TP partenaire n’a pas émis REQUEST_TO_SEND.

    max_len
    Paramètre fourni. Spécifie le nombre maximal d’octets de données que le TP local peut recevoir. La plage est comprise entre 0 et 65535.

    La valeur ne doit pas dépasser la longueur de la mémoire tampon pour contenir les données reçues. Le décalage de dptr plus la valeur de max_len ne doit pas dépasser la taille du segment de données.

    Dlen
    Paramètre retourné. Spécifie le nombre d’octets de données reçus. Les données sont stockées dans la mémoire tampon spécifiée par dptr. Une longueur de zéro indique qu’aucune donnée n’a été reçue.

    Dpt
    Paramètre fourni. Fournit l’adresse de la mémoire tampon pour contenir les données reçues par la lu locale.

    Pour Microsoft® Windows ®, la mémoire tampon de données peut résider dans une zone de données statique ou dans une zone allouée globalement. La mémoire tampon de données doit s’adapter entièrement à cette zone.

    Sema
    Paramètre fourni. Fournit l’adresse du sémaphore que l’APPC consiste à effacer lorsque l’opération de réception asynchrone est terminée. Le paramètre sema est un handle d’événement obtenu en appelant la fonction CreateEvent ou OpenEvent Win32.

    Valeurs retournées par le paramètre what_rcvd

  • AP_CONFIRM_DEALLOCATE indique que le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_SYNC_LEVEL . Le niveau de synchronisation de la conversation, établi par ALLOCATE, est AP_CONFIRM_SYNC_LEVEL. Lors de la réception de cette valeur, le TP local émet normalement des problèmes CONFIRMÉs.

  • AP_CONFIRM_SEND indique que le tp partenaire a émis PREPARE_TO_RECEIVE avec ptr_type défini sur AP_SYNC_LEVEL . Le niveau de synchronisation de la conversation, établi par ALLOCATE, est AP_CONFIRM_SYNC_LEVEL. Lors de la réception de cette valeur, le TP local émet normalement CONFIRMÉ et commence à envoyer des données.

  • AP_CONFIRM_WHAT_RECEIVED indique que le tp partenaire a émis CONFIRM. Lors de la réception de cette valeur, le TP local émet normalement CONFIRMÉ.

  • AP_DATA indique que cette valeur peut être retournée par RECEIVE_AND_POST si le remplissage est défini sur AP_BUFFER. Le tp local a reçu des données jusqu’à max_len ou la fin des données a été atteinte. Pour plus d’informations, consultez notes dans cette rubrique.

  • AP_DATA_COMPLETE indique, pour RECEIVE_AND_POST, que le tp local a reçu un enregistrement de données complet ou la dernière partie d’un enregistrement de données.

    Pour RECEIVE_AND_POST avec remplissage défini sur AP_LL, cette valeur indique que le tp local a reçu un enregistrement logique complet ou la fin d’un enregistrement logique.

    Lors de la réception de cette valeur, le TP local réédite normalement RECEIVE_AND_POST ou émet un autre verbe de réception. Si le tp partenaire a envoyé plus de données, le TP local commence à recevoir une nouvelle unité de données.

    Sinon, le tp local examine les informations d’état.

    Si primary_rc contient des AP_OK et what_rcvd contient AP_SEND, AP_CONFIRM_SEND, AP_CONFIRM_DEALLOCATE ou AP_CONFIRM_WHAT_RECEIVED, consultez la description de la valeur (dans cette section) pour l’action suivante que le TP local prend normalement.

    Si primary_rc contient AP_DEALLOC_NORMAL, la conversation a été libérée en réponse à l’instruction DEALLOCATE émise par le tp partenaire.

  • AP_DATA_INCOMPLETE indique, pour RECEIVE_AND_POST, que le TP local a reçu un enregistrement de données incomplet. Le paramètre max_len a spécifié une valeur inférieure à la longueur de l’enregistrement de données (ou inférieur au reste de l’enregistrement de données s’il ne s’agit pas du premier verbe de réception pour lire l’enregistrement).

    Pour RECEIVE_AND_POST avec remplissage défini sur AP_LL, cette valeur indique que le tp local a reçu un enregistrement logique incomplet.

    Lors de la réception de cette valeur, le TP local réédite normalement RECEIVE_AND_POST (ou émet un autre verbe de réception) pour recevoir la partie suivante de l’enregistrement.

  • AP_NONE indique que le tp n’a pas reçu de données ni d’indicateurs d’état de conversation.

  • AP_SEND indique, pour le tp partenaire, que la conversation a entré l’état RECEIVE. Pour le tp local, la conversation est désormais dans l’état SEND. Lors de la réception de cette valeur, le tp local utilise normalement SEND_DATA pour commencer à envoyer des données.

Codes de retour

AP_OK
Code de retour principal ; indique que le verbe s’est exécuté correctement.

Lorsque rtn_status est AP_YES , le code de retour précédent ou l’un des codes de retour suivants peut être retourné.

AP_DATA_COMPLETE_SEND
Code de retour principal ; il s’agit d’une combinaison de AP_DATA_COMPLETE et de AP_SEND.

AP_DATA_COMPLETE_CONFIRM_SEND
Code de retour principal ; il s’agit d’une combinaison de AP_DATA_COMPLETE et de AP_CONFIRM_SEND.

AP_DATA_COMPLETE_CONFIRM
Code de retour principal ; il s’agit d’une combinaison de AP_DATA_COMPLETE et de AP_CONFIRM_WHAT_RECEIVED.

AP_DATA_COMPLETE_CONFIRM_DEALL
Code de retour principal ; il s’agit d’une combinaison de AP_DATA_COMPLETE et de AP_CONFIRM_DEALLOCATE.

AP_DATA_SEND
Code de retour principal ; il s’agit d’une combinaison de AP_DATA et de AP_SEND.

AP_DATA_CONFIRM_SEND
Code de retour principal ; il s’agit d’une combinaison de AP_DATA et de AP_CONFIRM_SEND.

AP_DATA_CONFIRM
Code de retour principal ; il s’agit d’une combinaison de AP_DATA et de AP_CONFIRM.

AP_DATA_CONFIRM_DEALLOCATE
Code de retour principal ; il s’agit d’une combinaison de AP_DATA et de AP_CONFIRM_DEALLOCATE.

AP_DEALLOC_NORMAL
Code de retour principal ; le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_FLUSH ou AP_SYNC_LEVEL avec le niveau de synchronisation de la conversation spécifié en tant que AP_NONE.

Si rtn_status est AP_YES, examinez what_rcvd également.

AP_PARAMETER_CHECK
Code de retour principal ; le verbe n’a pas été exécuté en raison d’une erreur de paramètre.

AP_BAD_CONV_ID

Code de retour secondaire ; la valeur de conv_id ne correspond pas à un identificateur de conversation affecté par APPC.

AP_BAD_TP_ID

Code de retour secondaire ; la valeur de tp_id ne correspond pas à un identificateur TP attribué par APPC.

AP_BAD_RETURN_STATUS_WITH_DATA

Code de retour secondaire ; la valeur de rtn_status spécifiée n’a pas été reconnue par APPC.

AP_INVALID_DATA_SEGMENT

Code de retour secondaire ; la longueur spécifiée pour la mémoire tampon de données était plus longue que le segment alloué pour contenir la mémoire tampon.

AP_INVALID_SEMAPHORE_HANDLE

Code de retour secondaire ; l’adresse du sémaphore RAM ou du handle de sémaphore système n’était pas valide.

APPC ne peut pas intercepter tous les handles de sémaphore non valides. Si le programme transactionnel transmet un descripteur de sémaphore RAM incorrect, une violation de protection se produit.

AP_RCV_AND_POST_BAD_FILL

Code de retour secondaire ; le paramètre de remplissage a été défini sur une valeur non valide.

AP_STATE_CHECK
Code de retour principal ; le verbe n’a pas été exécuté, car il a été émis dans un état non valide.

AP_RCV_AND_POST_BAD_STATE

Code de retour secondaire ; la conversation n’était pas dans l’état RECEIVE ou SEND lorsque le TP a émis ce verbe.

AP_RCV_AND_POST_NOT_LL_BDY

Code de retour secondaire ; la conversation était dans l’état SEND ; le TP a commencé mais n’a pas fini d’envoyer un enregistrement logique.

AP_CANCELED
Code de retour principal ; le tp local a émis l’un des verbes suivants, qui ont annulé RECEIVE_AND_POST :

DEALLOCATE avec dealloc_type défini sur AP_ABEND_PROG, AP_ABEND_SVC ou AP_ABEND_TIMER

SEND_ERROR

TP_ENDED

L’émission de l’un de ces verbes entraîne l’effacement du sémaphore.

AP_ALLOCATION_ERROR
Code de retour principal ; APPC n’a pas pu allouer une conversation. L’état de la conversation est défini sur RESET.

Ce code peut être retourné par le biais d’un verbe émis après ALLOCATE.

AP_ALLOCATION_FAILURE_NO_RETRY

Code de retour secondaire ; la conversation ne peut pas être allouée en raison d’une condition permanente, telle qu’une erreur de configuration ou une erreur de protocole de session. Pour déterminer l’erreur, l’administrateur système doit examiner le fichier journal des erreurs. Ne réessayez pas l’allocation tant que l’erreur n’a pas été corrigée.

AP_ALLOCATION_FAILURE_RETRY

Code de retour secondaire ; la conversation n’a pas pu être allouée en raison d’une condition temporaire, telle qu’une défaillance de lien. La raison de l’échec est consignée dans le journal des erreurs système. Réessayez l’allocation.

AP_CONVERSATION_TYPE_MISMATCH

Code de retour secondaire ; l’unité logique partenaire ou tp ne prend pas en charge le type de conversation (de base ou mappé) spécifié dans la demande d’allocation.

AP_PIP_NOT_ALLOWED

Code de retour secondaire ; les données PIP spécifiées par la demande d’allocation, mais le tp partenaire ne nécessite pas ces données, ou l’unité logique partenaire ne la prend pas en charge.

AP_PIP_NOT_SPECIFIED_CORRECTLY

Code de retour secondaire ; le tp partenaire nécessite des données PIP, mais la demande d’allocation spécifiée n’a pas de données PIP ou un nombre incorrect de paramètres.

AP_SECURITY_NOT_VALID

Code de retour secondaire ; l’identificateur d’utilisateur ou le mot de passe spécifié dans la demande d’allocation n’a pas été accepté par l’unité logique partenaire.

AP_SYNC_LEVEL_NOT_SUPPORTED

Code de retour secondaire ; le tp partenaire ne prend pas en charge le sync_level (AP_NONE ou AP_CONFIRM_SYNC_LEVEL) spécifié dans la demande d’allocation, ou le sync_level n’a pas été reconnu.

AP_TP_NAME_NOT_RECOGNIZED

Code de retour secondaire ; l’unité logique partenaire ne reconnaît pas le nom tp spécifié dans la demande d’allocation.

AP_TRANS_PGM_NOT_AVAIL_NO_RETRY

Code de retour secondaire ; l’unité logique distante a rejeté la demande d’allocation, car elle n’a pas pu démarrer le tp du partenaire demandé. La condition est permanente. La raison de l’erreur peut être consignée sur le nœud distant. Ne réessayez pas l’allocation tant que l’erreur n’a pas été corrigée.

AP_TRANS_PGM_NOT_AVAIL_RETRY

Code de retour secondaire ; la lu distante a rejeté la demande d’allocation, car elle n’a pas pu démarrer le TP du partenaire demandé. La situation peut être temporaire, par exemple un délai d’attente. La raison de l’erreur peut être consignée sur le nœud distant. Réessayez l’allocation.

AP_COMM_SUBSYSTEM_ABENDED
Code de retour principal ; indique l’une des situations suivantes :

  • Le nœud utilisé par cette conversation a rencontré un abandon (ABEND).

  • La connexion a été interrompue entre le programme transactionnel et le nœud PU 2.1 (erreur LAN).

  • Le processus SnaBase qui se déroule sur l’ordinateur du programme transactionnel a rencontré un abandon (ABEND).

    L’administrateur système doit examiner le journal des erreurs pour déterminer la raison de l’abandon.

    AP_COMM_SUBSYSTEM_NOT_LOADED
    Code de retour principal ; indique qu’il n’a pas été possible de charger un composant requis ou d’y mettre fin lors du traitement du verbe. Par conséquent, la communication n’a pas pu être établie. Contactez l’administrateur système pour mettre en place une action corrective.

    Lorsque ce code de retour est utilisé avec ALLOCATE, il peut indiquer qu’aucun système de communication n’est trouvé pour prendre en charge la lu locale. (Par exemple, l’alias lu local spécifié avec TP_STARTED est incorrect ou n’a pas été configuré.) Notez que si lu_alias ou mode_name est inférieur à huit caractères, vous devez vous assurer que ces champs sont remplis d’espaces à droite. Cette erreur est retournée si ces paramètres ne sont pas remplis d’espaces, car il n’existe aucun nœud disponible qui peut satisfaire la requête ALLOCATE .

    Lorsque ALLOCATE produit ce code de retour pour un système client Host Integration Server configuré avec plusieurs nœuds, il existe deux codes de retour secondaires comme suit :

    0xF0000001

    Code de retour secondaire ; aucun nœud n’a été démarré.

    0xF0000002

    Code de retour secondaire ; au moins un nœud a été démarré, mais la lu locale (quand TP_STARTED est émise) n’est pas configurée sur les nœuds actifs. Le problème peut être l’un des éléments suivants :

  • Le nœud avec la lu locale n’est pas démarré.

  • La lu locale n’est pas configurée.

    AP_CONV_FAILURE_NO_RETRY
    Code de retour principal ; la conversation a été arrêtée en raison d’une condition permanente, telle qu’une erreur de protocole de session. L’administrateur système doit examiner le journal des erreurs système pour déterminer la cause de l’erreur. Ne réessayez pas la conversation tant que l’erreur n’a pas été corrigée.

    AP_CONV_FAILURE_RETRY
    Code de retour principal ; la conversation a été arrêtée en raison d’une erreur temporaire. Redémarrez le TP pour voir si le problème se produit à nouveau. S’il le fait, l’administrateur système doit examiner le journal des erreurs pour déterminer la cause de l’erreur.

    AP_CONVERSATION_TYPE_MIXED
    Code de retour principal ; le TP a émis des verbes de conversation de base et mappés. Un seul type peut être émis dans une seule conversation.

    AP_INVALID_VERB_SEGMENT
    Code de retour principal ; indique que le bloc de contrôle de verbe s’étend au-delà de la fin du segment de données.

    AP_PROG_ERROR_NO_TRUNC
    Code de retour principal ; le tp partenaire a émis SEND_ERROR avec err_type défini sur AP_PROG pendant que la conversation était en état SEND. Les données n’ont pas été tronquées.

    AP_PROG_ERROR_PURGING
    Code de retour principal ; en ATTENTE, en attente, PENDING_POST, CONFIRM, CONFIRM_SEND ou CONFIRM_DEALLOCATE état, le tp partenaire a émis SEND_ERROR avec err_type définie sur AP_PROG . Les données envoyées, mais non encore reçues, sont vidées.

    AP_PROG_ERROR_TRUNC
    Code de retour principal ; dans l’état SEND, après avoir envoyé un enregistrement logique incomplet, le tp partenaire a émis SEND_ERROR avec err_type défini sur AP_PROG . Le TP local peut avoir reçu la première partie de l’enregistrement logique par le biais d’un verbe de réception.

    AP_STACK_TOO_SMALL
    Code de retour principal ; indique que la taille de la pile de l’application est trop petite pour exécuter le verbe. Augmentez la taille de pile de votre application.

    AP_CONV_BUSY
    Code de retour principal ; il ne peut y avoir qu’un verbe de conversation exceptionnel à la fois sur n’importe quelle conversation. Cela peut se produire si le TP local a plusieurs threads et que plusieurs threads émettent des appels APPC à l’aide du même conv_id.

    AP_UNEXPECTED_DOS_ERROR
    Code de retour principal ; indique que le système d’exploitation a retourné une erreur à APPC lors du traitement d’un appel APPC à partir du programme transactionnel local. Le code de retour du système d’exploitation a été retourné via secondary_rc. Il apparaît dans l’ordre Intel avec permutation d’octets. Si le problème persiste, consultez l’administrateur système.

    AP_DEALLOC_ABEND_PROG
    Code de retour principal ; la conversation a été libérée pour l’une des raisons suivantes :

  • Le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_ABEND_PROG .

  • Le partenaire TP a rencontré un ABEND, ce qui a provoqué l’envoi d’une demande DEALLOCATE .

    AP_DEALLOC_ABEND_SVC
    Code de retour principal ; la conversation a été désaffectée, car le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_ABEND_SVC .

    AP_DEALLOC_ABEND_TIMER
    Code de retour principal ; la conversation a été désaffectée, car le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_ABEND_TIMER .

    AP_SVC_ERROR_NO_TRUNC
    Code de retour principal ; dans l’état SEND, le partenaire TP (ou lu partenaire) a émis SEND_ERROR avec err_type défini sur AP_SVC . Les données n’ont pas été tronquées.

    AP_SVC_ERROR_PURGING
    Code de retour principal ; le partenaire TP (ou lu partenaire) a émis SEND_ERROR avec err_type défini sur AP_SVC pendant réception, PENDING_POST, CONFIRM, CONFIRM_SEND ou CONFIRM_DEALLOCATE état. Les données envoyées au programme transactionnel de partenaire ont peut-être été vidées.

    AP_SVC_ERROR_TRUNC
    Code de retour principal ; dans l’état SEND, après avoir envoyé un enregistrement logique incomplet, le partenaire TP (ou lu partenaire) a émis SEND_ERROR. Le TP local peut avoir reçu la première partie de l’enregistrement logique.

Remarques

Le TP local reçoit des données par le biais du processus suivant :

  1. Le TP local émet un verbe de réception jusqu’à ce qu’il termine la réception d’une unité complète de données. Les données reçues peuvent être les suivantes :

    • Un enregistrement logique.

    • Mémoire tampon des données reçues indépendamment de son format d’enregistrement logique.

      Le TP local peut avoir besoin de émettre plusieurs fois le verbe de réception pour recevoir une unité complète de données. Une fois qu’une unité complète de données a été reçue, le TP local peut le manipuler. Les verbes de réception sont RECEIVE_AND_POST, RECEIVE_AND_WAIT et RECEIVE_IMMEDIATE.

  2. Le TP local émet à nouveau le verbe de réception. Cela a l’un des effets suivants :

    • Si le tp partenaire a envoyé plus de données, le TP local commence à recevoir une nouvelle unité de données.

    • Si le TP partenaire a terminé d’envoyer des données ou attend la confirmation, les informations d’état (disponibles via what_rcvd) indiquent l’action suivante que le TP local prend normalement.

    La procédure suivante montre les tâches effectuées par le TP local à l’aide de RECEIVE_AND_POST.

Pour utiliser RECEIVE_AND_POST

  1. Pour le système d’exploitation Microsoft Windows ®, le TP récupère le numéro de message WinAsyncAPPC en appelant l’API RegisterWindowMessage ou en allouant un sémaphore. Le champ sema doit être défini sur NULL si l’application s’attend à être avertie par le biais du mécanisme de message Windows.

    APPC envoie le message Windows ou efface le sémaphore lorsque le TP local termine la réception des données.

    Le sémaphore reste défini pendant que le TP local reçoit les données de façon asynchrone. APPC efface le sémaphore lorsque le TP local termine la réception des données.

  2. Le TP émet RECEIVE_AND_POST.

  3. Le TP vérifie la valeur de primary_rc.

    Si primary_rc est AP_OK , la mémoire tampon de réception (pointée par dptr) reçoit de façon asynchrone les données du tp partenaire. Lors de la réception de données de manière asynchrone, le TP local peut :

    • Effectuez des tâches non liées à cette conversation.

    • Problème REQUEST_TO_SEND.

    • Recueillez des informations sur cette conversation en émettant GET_TYPE, GET_ATTRIBUTES ou TEST_RTS.

    • Annulez prématurément RECEIVE_AND_POST en émettant DEALLOCATE avec dealloc_type défini sur AP_ABEND_PROG , AP_ABEND_SVC ou AP_ABEND_TIMER; SEND_ERROR;ou TP_ENDED.

      Si, toutefois, primary_rc n’est pas AP_OK, RECEIVE_AND_POST a échoué. Dans ce cas, le TP local n’effectue pas les deux tâches suivantes.

  4. Pour le système d’exploitation Windows, lorsque le TP termine la réception des données de façon asynchrone, APPC émet le message winAsyncAPPC Windows ou efface le sémaphore.

  5. Le TP vérifie la nouvelle valeur de primary_rc.

    Si primary_rc est AP_OK , le TP local peut examiner les autres paramètres retournés et manipuler les données reçues de façon asynchrone.

    Si primary_rc n’est pas AP_OK, seuls les secondary_rc et les rts_rcvd (demandes à envoyer reçues) sont significatifs.

    Effets de l’état de la conversation

    La conversation doit être dans l’état RECEIVE ou SEND lorsque le TP émet ce verbe.

    L’émission de RECEIVE_AND_POST pendant que la conversation est dans l’état SEND a les effets suivants :

  • La lu locale envoie les informations dans sa mémoire tampon d’envoi et un indicateur SEND au tp partenaire.

  • La conversation passe à l’état PENDING_POST; le TP local est prêt à recevoir des informations du tp partenaire de manière asynchrone.

    La conversation change deux fois les états :

  • Lors du retour initial du verbe, si primary_rc contient AP_OK , la conversation passe à l’état PENDING_POST.

  • Une fois le verbe terminé, l’état change en fonction de la valeur des éléments suivants :

    Paramètre primary_rc

    Paramètre what_rcvd si primary_rc est AP_OK

    Le tableau suivant montre le nouvel état associé à chaque valeur de what_rcvd lorsque primary_rc est AP_OK .

what_rcvd Nouvel état
AP_CONFIRM_DEALLOCATE CONFIRM_DEALLOCATE
AP_DATA_COMPLETE_CONFIRM_DEALL CONFIRM_DEALLOCATE
AP_DATA_CONFIRM_DEALLOCATE CONFIRM_DEALLOCATE
AP_CONFIRM_SEND CONFIRM_SEND
AP_DATA_COMPLETE_CONFIRM_SEND CONFIRM_SEND
AP_DATA_CONFIRM_SEND CONFIRM_SEND
AP_CONFIRM_WHAT_RECEIVED CONFIRMER
AP_DATA_COMPLETE_CONFIRM CONFIRMER
AP_DATA_CONFIRM CONFIRMER
AP_DATA RECEIVE
AP_DATA_COMPLETE RECEIVE
AP_DATA_INCOMPLETE RECEIVE
AP_SEND SEND
AP_DATA_COMPLETE_SEND SEND_PENDING

Le tableau suivant montre le nouvel état associé à chaque valeur de primary_rc autre que AP_OK.

primary_rc Nouvel état
AP_CANCELED Aucun changement
AP_CONV_FAILURE_RETRY RESET
AP_CONV_FAILURE_NO_RETRY RESET
AP_DEALLOC_ABEND RESET
AP_DEALLOC_ABEND_PROG RESET
AP_DEALLOC_ABEND_SVC RESET
AP_DEALLOC_ABEND_TIMER RESET
AP_DEALLOC_NORMAL RESET
AP_PROG_ERROR_PURGING RECEIVE
AP_PROG_ERROR_NO_TRUNC RECEIVE
AP_SVC_ERROR_PURGING RECEIVE
AP_SVC_ERROR_NO_TRUNC RECEIVE
AP_PROG_ERROR_TRUNC RECEIVE
AP_SVC_ERROR_TRUNC RECEIVE

Fin des données pour une conversation de base

Si le TP local émet RECEIVE_AND_POST et définit le remplissage sur AP_BUFFER, la réception des données se termine lorsque max_len ou la fin des données est atteinte. La fin des données est indiquée par primary_rc avec une valeur autre que AP_OK (par exemple, AP_DEALLOC_NORMAL), ou par what_rcvd avec l’une des valeurs suivantes :

AP_SEND

AP_CONFIRM_SEND

AP_CONFIRM_DEALLOCATE

AP_CONFIRM_WHAT_RECEIVED

AP_DATA_CONFIRM_SEND

AP_DATA_CONFIRM_DEALLOCATE

AP_DATA_CONFIRM

Pour déterminer si la fin des données a été atteinte, le TP local réécute RECEIVE_AND_POST. Si le nouveau primary_rc contient AP_OK et what_rcvd contient AP_DATA, la fin des données n’a pas été atteinte. Si, toutefois, la fin des données a été atteinte, primary_rc ou what_rcvd indique la cause de la fin des données.

Dépannage

Le TP local peut attendre indéfiniment si l’une des situations suivantes se produit :

  • Pour le système d’exploitation Windows, le TP local émet une requête RECEIVE_AND_POST, mais le tp partenaire n’a pas envoyé de données ou le primary_rc initial n’est pas AP_OK.

  • Pour le système d’exploitation OS/2, le TP local émet un appel de fonction DosSemWait , mais le tp partenaire n’a pas envoyé de données ou le primary_rc initial n’est pas AP_OK.

    Cela est dû au fait que APPC ne émet pas le message Windows ou efface le sémaphore.

    Lorsqu’une condition résultant de l’un des paramètres primary_rc suivants se produit, APPC ne efface pas le sémaphore :

    AP_INVALID_SEMAPHORE_HANDLE

    AP_INVALID_VERB_SEGMENT

    AP_STACK_TOO_SMALL

    Pour tester what_rcvd, émettez RECEIVE_AND_POST avec max_len défini sur zéro, afin que le TP local puisse déterminer si le TP partenaire a des données à envoyer, rechercher une confirmation ou a modifié l’état de conversation.