REQUEST_TO_SEND

  • Article

Le verbe REQUEST_TO_SEND avertit le programme de transaction partenaire (TP) que le tp local souhaite envoyer des données.

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

Syntaxe

  
struct request_to_send {  
    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;  
};

Membres

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

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 le tp d’appel 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 ALLOCATE dans le tp d’appel ou par RECEIVE_ALLOCATE dans le tp appelé.

Codes de retour

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

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 attribué 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_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_R_T_S_BAD_STATE

Code de retour secondaire ; la conversation n’est pas dans un état autorisé lorsque le TP a émis ce verbe.

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 ; Un composant requis n’a pas pu être chargé ou s’est terminé 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’a pu être trouvé pour prendre en charge l’unité logique locale (LU). (Par exemple, l’alias de lu local spécifié avec TP_STARTED est incorrect ou n’a pas été configuré.) Notez que si lu_alias ou mode_name contient moins de 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 aucun nœud disponible ne peut satisfaire la requête ALLOCATE .

    Lorsque ALLOCATE produit ce code de retour pour un système client Microsoft 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 l’unité logique locale (lorsque TP_STARTED est émis) n’est pas configurée sur les nœuds actifs. Le problème peut être l’un des suivants :

  • Le nœud avec l’unité logique locale n’est pas démarré.

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

    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 même 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_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 seul verbe de conversation en suspens à 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_THREAD_BLOCKING
    Code de retour principal ; indique que le thread appelant se trouve déjà dans un appel de blocage.

    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.

Notes

La conversation peut se trouver dans l’un des états suivants lorsque le TP émet ce verbe :

CONFIRMER

PENDING_POST (OS/2)

RECEIVE

Il n’y a aucun changement d’état.

La notification de demande d’envoi est reçue par le programme partenaire via le paramètre rts_rcvd des verbes suivants :

  • CONFIRMER

  • RECEIVE_AND_POST

  • RECEIVE_AND_WAIT

  • RECEIVE_IMMEDIATE

  • SEND_DATA

  • SEND_ERROR

    Il est également indiqué par un primary_rc de AP_OK sur TEST_RTS.

    La notification de demande d’envoi est envoyée immédiatement au tp partenaire ; APPC n’attend pas que la mémoire tampon d’envoi soit remplie ou vidée. Par conséquent, la notification de demande d’envoi peut arriver hors séquence. Par exemple, si le TP local est à l’état SEND et que des problèmes PREPARE_TO_RECEIVE suivis de REQUEST_TO_SEND, le TP partenaire, à l’état RECEIVE, peut recevoir la notification de demande d’envoi avant de recevoir la notification d’envoi. Pour cette raison, la requête à envoyer peut être signalée à un TP par le biais d’un verbe de réception.

    En réponse à cette demande, le tp partenaire peut modifier la conversation en :

  • RECEVOIR l’état en émettant des PREPARE_TO_RECEIVE ou des RECEIVE_AND_WAIT.

  • PENDING_POST l’état en émettant des RECEIVE_AND_POST.

    Le TP partenaire peut également ignorer la demande d’envoi.

    L’état de la conversation devient SEND pour le TP local lorsque le TP local reçoit l’une des valeurs suivantes via le paramètre what_rcvd d’un verbe de réception suivant :

  • AP_CONFIRM_SEND et réponses avec CONFIRM

  • AP_DATA_COMPLETE_CONFIRM_SEND et réponses avec CONFIRM

  • AP_DATA_CONFIRM_SEND et réponses avec CONFIRM

  • AP_SEND

    Les verbes de réception sont RECEIVE_AND_POST, RECEIVE_IMMEDIATE et RECEIVE_AND_WAIT.