DEALLOCATE

Le verbe DEALLOCATE désalloue une conversation entre deux programmes transactionnels (TPs).

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

Syntaxe

  
struct deallocate {  
    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        reserv3;  
    unsigned char        dealloc_type;  
    unsigned short       log_dlen;  
    unsigned char FAR *  log_dptr;  
    void                 (WINAPI *callback)();  
    void                 *correlator;  
    unsigned char        reserv6[4];  
};  

Membres

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

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

conv_id
Paramètre fourni. Identifie la conversation établie entre les deux TPs. La valeur de ce paramètre est retournée par ALLOCATE dans le tp d’appel ou par RECEIVE_ALLOCATE dans le tp appelé.

reserv3
Un champ réservé.

dealloc_type
Paramètre fourni. Spécifie comment effectuer la désallocation.

L’utilisation de l’une des valeurs suivantes libère la conversation anormalement :

• AP_ABEND_PROG

• AP_ABEND_SVC

• AP_ABEND_TIMER

  Si la conversation est à l’état SEND lorsque le TP local émet DEALLOCATE, APPC envoie le contenu de la mémoire tampon d’envoi de l’unité logique locale (LU) au tp partenaire avant de désallouer la conversation. Si la conversation est à l’état RECEIVE ou PENDING_POST, APPC vide toutes les données entrantes avant de la déallouer.

  Un TP d’application ou de service doit spécifier AP_ABEND_PROG lorsqu’il rencontre une erreur empêchant la réussite d’une transaction.

  Un TP de service doit spécifier AP_ABEND_SVC lorsqu’il rencontre une erreur provoquée par son tp de service partenaire (par exemple, une erreur de format dans les informations de contrôle envoyées par le service partenaire TP). Un tp de service doit spécifier AP_ABEND_TIMER lorsqu’il rencontre une erreur nécessitant une désallocation immédiate (par exemple, un opérateur mettant fin prématurément au programme).

  AP_FLUSH envoie le contenu de la mémoire tampon d’envoi de la lu locale au tp partenaire avant de désallouer la conversation. Cette valeur est autorisée uniquement si la conversation est à l’état SEND.

  AP_SYNC_LEVEL utilise le niveau de synchronisation de la conversation (établi par ALLOCATE) pour déterminer comment libérer la conversation. Cette valeur est autorisée uniquement si la conversation est à l’état SEND.

  Si le niveau de synchronisation de la conversation est AP_NONE, APPC envoie le contenu de la mémoire tampon d’envoi de la lu locale au tp partenaire avant de déallouer la conversation.

  Si le niveau de synchronisation est AP_CONFIRM_SYNC_LEVEL, APPC envoie le contenu de la mémoire tampon d’envoi de la lu locale et une demande de confirmation au tp partenaire. Après réception de la confirmation du tp partenaire, APPC libère la conversation. Si, toutefois, le tp partenaire signale une erreur, la conversation reste allouée.

  log_dlen
  Paramètre fourni. Spécifie le nombre d’octets de données à envoyer au fichier journal des erreurs. La plage est comprise entre 0 et 32767.

  Vous pouvez définir ce paramètre sur un nombre supérieur à zéro si dealloc_type a la valeur AP_ABEND_PGM, AP_ABEND_SVC ou AP_ABEND_TIMER. Sinon, ce paramètre doit être égal à zéro.

  log_dptr
  Paramètre fourni. Fournit l’adresse de la mémoire tampon de données contenant des informations d’erreur. Les données sont envoyées au journal des erreurs local et à l’unité logique partenaire.

  Ce paramètre est utilisé par DEALLOCATE si log_dlen est supérieur à zéro.

  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 tenir entièrement dans cette zone.

  Pour OS/2, la mémoire tampon de données de journal doit résider sur un segment partagé sans nom, qui est alloué par la fonction DosAllocSeg avec des indicateurs 1. La mémoire tampon des données de journal doit être entièrement adaptée au segment.

  Le TP doit mettre en forme les données d’erreur en tant que variable de journal des erreurs GDS. Pour plus d’informations, consultez votre ou vos manuels IBM SNA.

  Rappel
  Paramètre fourni. Présent uniquement si le bit AP_EXTD_VCB est défini dans le membre opext , ce qui indique la prise en charge du point de synchronisation. Ce paramètre est l’adresse d’une fonction de rappel fournie par l’utilisateur. Si ce champ a la valeur NULL, aucune notification n’est fournie.

  Le prototype de la routine de rappel est le suivant :

void WINAPI callback_proc(  
    struct appc_hdr *vcb,  
    unsigned char tp_id[8],  
    unsigned long conv_id,  
    unsigned short type,  
    void *correlator  
   );  

La procédure de rappel peut prendre n’importe quel nom, car l’adresse de la procédure est passée à la DLL APPC. Les paramètres passés à la fonction sont les suivants :

Vcb

Pointeur vers le bloc de contrôle de verbe DEALLOCATE qui a provoqué la désallocation de la conversation.

tp_id

Identificateur TP du TP qui possédait la conversation désallouée.

conv_id

Identificateur de conversation de la conversation désallouée.

type

Type du flux de message qui a provoqué l’appel du rappel. Les valeurs possibles sont les suivantes :

AP_DATA_FLOW

Flux de données normal sur la session.

AP_UNBIND

La session était indépendante normalement.

AP_FAILURE

La session s’est arrêtée en raison d’une panne.

Correlator

Cette valeur est le corrélateur spécifié sur le verbe DEALLOCATE .

Correlator
Paramètre fourni. Présent uniquement si le bit AP_EXTD_VCB est défini dans le membre opext , ce qui indique la prise en charge de l’API de point de synchronisation. Ce champ corrélateur permet au tp de spécifier une valeur qu’il peut utiliser pour mettre en corrélation un appel à la fonction de rappel avec, par exemple, ses propres structures de données internes. Cette valeur est retournée au tp en tant que l’un des paramètres de la routine de rappel lorsqu’elle est appelée.

reserv4
Un champ réservé.

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_DEALLOC_BAD_TYPE

Code de retour secondaire ; le paramètre dealloc_type n’a pas été défini sur une valeur valide.

AP_DEALLOC_LOG_LL_WRONG

Code de retour secondaire ; le champ LL de la variable de journal des erreurs GDS ne correspondait pas à la longueur réelle des données du journal.

AP_INVALID_DATA_SEGMENT

Code de retour secondaire ; les données d’erreur pour le fichier journal étaient plus longues que le segment alloué pour contenir les données d’erreur, ou l’adresse de la mémoire tampon de données d’erreur était incorrecte.

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_DEALLOC_CONFIRM_BAD_STATE

Code de retour secondaire ; la conversation n’était pas à l’état SEND, et le TP a tenté de vider la mémoire tampon d’envoi et d’envoyer une demande de confirmation. Cette tentative s’est produite parce que la valeur de dealloc_type a été AP_SYNC_LEVEL et que le niveau de synchronisation de la conversation a été AP_CONFIRM_SYNC_LEVEL.

AP_DEALLOC_FLUSH_BAD_STATE

Code de retour secondaire ; la conversation n’était pas à l’état SEND et le tp a tenté de vider la mémoire tampon d’envoi. En effet, la valeur de dealloc_type était AP_FLUSH, ou bien AP_SYNC_LEVEL avec le niveau de synchronisation de la conversation AP_NONE. Dans les deux cas, la conversation doit présenter l’état SEND.

AP_DEALLOC_NOT_LL_BDY

Code de retour secondaire ; la conversation était à l’état SEND et le TP n’a pas fini d’envoyer un enregistrement logique. Le paramètre dealloc_type était défini sur AP_SYNC_LEVEL ou AP_FLUSH.

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 ; la 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 ; les données PIP spécifiées par la demande d’allocation, mais soit le TP partenaire n’a pas besoin de ces données, soit l’unité logique du 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és 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 la sync_level (AP_NONE ou AP_CONFIRM_SYNC_LEVEL) spécifiée dans la demande d’allocation, ou le sync_level n’a pas été reconnu.

AP_TP_NAME_NOT_RECOGNIZED

Code de retour secondaire ; la 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 ; la lu distante a rejeté la demande d’allocation, car elle n’a pas pu démarrer le TP 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 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.

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

• Le TP partenaire a rencontré un ABEND, ce qui a entraîné l’unité lu partenaire à envoyer une demande DEALLOCATE .

  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

Selon la valeur du paramètre dealloc_type , la conversation peut se trouver dans l’un des états indiqués dans le tableau suivant lorsque le TP émet DEALLOCATE.

Les changements d’état, résumés dans le tableau suivant, sont basés sur la valeur de l’primary_rc.

Avant de déallouer la conversation, ce verbe effectue l’équivalent de l’un des éléments suivants :

• FLUSH, en envoyant le contenu de la mémoire tampon d’envoi de la lu locale à l’unité lu partenaire (et TP).

• CONFIRMez, en envoyant le contenu de la mémoire tampon d’envoi de la lu locale et une demande de confirmation au TP partenaire.

  Une fois ce verbe exécuté, l’identificateur de conversation n’est plus valide.

  Le point de synchronisation LU 6.2 peut utiliser une optimisation des flux de messages appelée oubli implicite. Lorsque le protocole spécifie qu’un en-tête FORGET PS est requis, le flux de données suivant sur la session implique qu’un forget a été reçu. Dans la situation normale, le TP est conscient du prochain flux de données lorsque des données sont reçues ou envoyées sur l’une de ses conversations de point de synchronisation.

  Toutefois, il est possible que le dernier message à circuler soit dû à la désaffectation de la conversation. Dans ce cas, le TP ignore quand le prochain flux de données sur la session se produit. Pour fournir au TP cette notification, le verbe DEALLOCATE est modifié pour permettre au TP d’inscrire une fonction de rappel qui sera appelée :

• Lors de la première transmission de flux normal (demande ou réponse) sur la session utilisée par la conversation.

• Si la session n’est pas lié avant tout autre flux de données.

• Si la session est interrompue anormalement en raison d’une panne de DLC.

  Le verbe DEALLOCATE contient également un membre de champ corrélateur qui est retourné en tant que l’un des paramètres lorsque la fonction de rappel est appelée. L’application peut utiliser ce paramètre de n’importe quelle manière (par exemple, comme pointeur vers un bloc de contrôle au sein de l’application).

  Le TP peut utiliser le paramètre de type passé à la fonction de rappel pour déterminer si le flux de message indique qu’un oubli implicite a été reçu.

  Notez que le verbe DEALLOCATE se terminera probablement avant l’appel de la routine de rappel. La conversation est considérée comme étant à l’état RESET et aucun autre verbe ne peut être émis à l’aide de l’identificateur de conversation. Si l’application émet un verbe TP_ENDED avant le prochain flux de données sur la session, la routine de rappel n’est pas appelée.

  Host Integration Server permet aux fournisseurs de services de libérer les conversations immédiatement après l’envoi de données en spécifiant le paramètre de type sur SEND_DATA comme AP_SEND_DATA_DEALLOC_*. Toutefois, les verbes SEND_DATA ne contiennent pas la fonction de rappel d’oubli implicite. Les fournisseurs de services qui souhaitent recevoir une notification d’oubli implicite doivent émettre EXPLICITEMENT DEALLOCATE .