CONFIRMER

  • Article

Le verbe CONFIRM envoie le contenu de la mémoire tampon d’envoi de l’unité logique locale (LU) et une demande de confirmation au programme de transaction partenaire (TP).

La structure suivante décrit le bloc de contrôle de verbe utilisé par le verbe CONFIRM .

Syntaxe

  
struct confirm {  
    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 char   rts_rcvd;  
};

Notes

Members (Membres)

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

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 a été retournée par TP_STARTED.

conv_id
Paramètre retourné. Identifie la conversation établie entre les deux fournisseurs de services.

rts_rcvd
Paramètre retourné. Indique si le TP partenaire a émis REQUEST_TO_SEND, ce qui demande au TP local de modifier la conversation à l’état RECEIVE.

Pour passer à l’état RECEIVE fonctionnant sur Microsoft Windows, le TP local peut utiliser PREPARE_TO_RECEIVE, RECEIVE_AND_WAIT ou RECEIVE_AND_POST.

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 correspondait pas à un identificateur de conversation attribué par APPC.

AP_BAD_TP_ID

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

AP_CONFIRM_ON_SYNC_LEVEL_NONE

Code de retour secondaire ; le TP local a tenté d’utiliser CONFIRM dans une conversation avec un niveau de synchronisation de AP_NONE. Le niveau de synchronisation, établi par ALLOCATE, doit être AP_CONFIRM_SYNC_LEVEL.

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_CONFIRM_BAD_STATE

Code de retour secondaire ; la conversation n’était pas à l’état SEND.

AP_CONFIRM_NOT_LL_BDY

Code de retour secondaire ; la conversation pour le TP local était à l’état SEND, et le TP local n’a pas terminé l’envoi d’un enregistrement logique.

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’un échec de liaison. 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é lu ou tp partenaire 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 ; la demande d’allocation a spécifié des données PIP, mais soit le tp partenaire n’a pas besoin de ces données, soit l’unité lu partenaire ne les 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 n’a spécifié aucune donnée PIP ou un nombre incorrect de paramètres.

AP_SECURITY_NOT_VALID

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

AP_SYNC_LEVEL_NOT_SUPPORTED

Code de retour secondaire ; le TP partenaire ne prend pas en charge les sync_level (AP_NONE, AP_CONFIRM_SYNC_LEVEL ou AP_SYNCPT) spécifiés 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é lu 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é lu 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 ; l’unité 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 SnaBase sur l’ordinateur du TP a rencontré un ABEND.

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

    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. N’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. Si c’est le cas, 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 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_PROG_ERROR_PURGING
    Code de retour principal ; alors qu’à l’état RECEIVE, PENDING, PENDING_POST, CONFIRM, CONFIRM_SEND ou CONFIRM_DEALLOCATE, le partenaire TP a émis SEND_ERROR avec err_type défini sur AP_PROG. Les données envoyées mais pas encore reçues sont vidé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.

    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_typedéfini sur AP_ABEND_PROG.

  • Le TP partenaire a rencontré un ABEND, ce qui a entraîné l’envoi d’une requête DEALLOCATE par l’unité logique du partenaire.

    AP_DEALLOC_ABEND_SVC
    Code de retour principal ; la conversation a été libéré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é libérée, car le tp partenaire a émis DEALLOCATE avec dealloc_type défini sur AP_ABEND_TIMER.

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

    Remarques

    En réponse à CONFIRM, le tp partenaire émet normalement CONFIRMED pour confirmer qu’il a reçu les données sans erreur. (Si le tp partenaire rencontre une erreur, il émet des problèmes SEND_ERROR ou désalloue anormalement la conversation.)

    Le TP peut émettre CONFIRM uniquement si le niveau de synchronisation de la conversation, établi par ALLOCATE, est AP_CONFIRM_SYNC_LEVEL.

    La conversation doit être à l’état SEND lorsque le TP émet ce verbe. Les changements d’état, résumés dans le tableau suivant, sont basés sur la valeur du primary_rc.

primary_rc Nouvel état
AP_OK Aucun changement
AP_ALLOCATION_ERROR RESET
AP_COMM_SUBSYSTEM_ABENDED AP_COMM_SUBSYSTEM_NOT_LOADED RÉINITIALISER LA RÉINITIALISATION
AP_CONV_FAILURE_RETRY AP_CONV_FAILURE_NO_RETRY RÉINITIALISER LA RÉINITIALISATION
AP_DEALLOC_ABEND AP_DEALLOC_ABEND_PROG AP_DEALLOC_ABEND_SVC AP_DEALLOC_ABEND_TIMER RÉINITIALISER LA RÉINITIALISATION RÉINITIALISER LA RÉINITIALISATION
AP_PROG_ERROR_PURGING AP_SVC_ERROR_PURGING RECEVOIR UNE RÉCEPTION

CONFIRM attend une réponse du tp partenaire. Une réponse est générée par l’un des verbes suivants dans le tp partenaire :

  • CONFIRMÉ

  • SEND_ERROR

  • LIBÉREZ avec dealloc_type définie sur AP_ABEND_PROG, AP_ABEND_SVC ou AP_ABEND_TIMER

  • TP_ENDED

    En émettant CONFIRM afterALLOCATE, le TP appelant peut déterminer immédiatement si l’allocation a réussi (si le niveau de synchronisation est défini sur AP_CONFIRM_SYNC_LEVEL).

    Normalement, la valeur du paramètre mode_name du verbe ALLOCATE doit correspondre au nom d’un mode configuré pour le nœud du TP appelé et associé lors de la configuration à l’unité logique partenaire.

    Si l’un des modes associés à l’unité logique partenaire sur le nœud du TP appelé est un mode implicite, la session établie entre les deux unités logiques est du mode implicite quand aucun nom de mode associé à l’unité logique partenaire ne correspond à la valeur de mode_name. Pour plus d’informations, consultez l’aide de Host Integration Server.

    Plusieurs paramètres d’ALLOCATE sont des chaînes EBCDIC ou ASCII. Un TP peut utiliser le verbe de service commun (CSV) CONVERT pour traduire une chaîne d’un jeu de caractères à l’autre.

    Pour envoyer immédiatement la requête ALLOCATE , le TP appelant peut émettre flush ou CONFIRM immédiatement après ALLOCATE. Sinon, la requête ALLOCATE s’accumule avec d’autres données dans la mémoire tampon d’envoi de la lu locale jusqu’à ce que la mémoire tampon soit saturée.