Partager via

MC_TEST_RTS_AND_POST

Le verbe MC_TEST_RTS_AND_POST permet à une application, généralement un émulateur 5250, de demander une notification asynchrone lorsqu’un programme de transaction partenaire (TP) demande une direction d’envoi.

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

Syntaxe

  
struct mc_test_rts_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 char       reserv3;  
    unsigned long       handle;  
};

Membres

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

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

réserver2
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 varient en fonction du verbe APPC émis. Consultez les codes de retour pour obtenir des codes d’erreur valides pour ce verbe.

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 varient en fonction du verbe APPC émis. Consultez les codes de retour pour obtenir des codes d’erreur valides pour ce verbe.

tp_id
Paramètre fourni. Identifie le TP local. La valeur de ce paramètre a été 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 a été retournée par MC_ALLOCATE dans l’appel du TP ou par RECEIVE_ALLOCATE dans le TP appelé.

réserver3
Champ réservé.

poignée
Paramètre fourni. Sur Microsoft Windows, ce champ fournit le handle d’événement à définir.

Codes de retour à partir du verbe initial

AP_OK
Code de retour principal ; le verbe exécuté avec succès. Notez en particulier qu’un code de retour de AP_OK du verbe initial n’indique pas que MC_REQUEST_TO_SEND verbe reçu du TP partenaire. Il indique simplement que l’installation à recevoir une notification asynchrone a été inscrite.

AP_UNSUCCESSFUL
Code de retour principal ; La notification de demande à envoyer n’a pas été reçue.

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 affecté 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_COMM_SUBSYSTEM_ABENDED
Code de retour principal ; indique l’une des conditions suivantes :

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

  • La connexion entre le tp et le nœud PU 2.1 a été interrompue (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’ABEND.

    AP_COMM_SUBSYSTEM_NOT_LOADED
    Code de retour principal ; un composant requis n’a pas pu être chargé ou s’est arrêté lors du traitement du verbe. Ainsi, la communication n’a pas pu avoir lieu. Contactez l’administrateur système pour obtenir une action corrective.

    Lorsque ce code de retour est utilisé avec MC_ALLOCATE, il peut indiquer qu’aucun système de communication n’est trouvé pour prendre en charge l’unité logique locale (LU). (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 demande de MC_ALLOCATE .

    Lorsque MC_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 l’unité logique locale (lorsque TP_STARTED est émise) n’est pas configurée sur des 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é.

  • L’unité logique 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 seule conversation.

    AP_INVALID_VERB_SEGMENT
    Code de retour principal ; le VCB s’étend au-delà de la fin du segment de données.

    AP_STACK_TOO_SMALL
    Code de retour principal ; la taille de la pile de l’application est trop petite pour exécuter le verbe. Augmentez la taille de la 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 ; le thread appelant est déjà dans un appel bloquant.

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

Codes de retour à partir de l’achèvement asynchrone

AP_OK
Code de retour principal ; la notification de demande à envoyer a été reçue du tp partenaire.

AP_CANCELLED
Le verbe TEST_RTS_AND_POST en attente a été arrêté. Cela se produit si la conversation sous-jacente a été libérée ou si une AP_TP_ENDED a été émise. Notez que, comme avec RECEIVE_AND_POST, le TP est toujours responsable de la fin correcte de la conversation et éventuellement de la fin du TP. L’émission d’un autre verbe, tel que RECEIVE_IMMEDIATE, indique à ce stade la raison de l’échec de la conversation.

Remarques

La conversation peut être dans n’importe quel état, à l’exception de RESET lorsque le TP émet ce verbe. Il n’y a aucune modification d’état.

Une fonctionnalité courante de nombreuses applications APPC, telles que 5250 émulateurs, est nécessaire pour détecter la demande d’envoi d’un partenaire. Actuellement, cela peut être effectué en interrogeant l’interface APPC pour détecter la demande du partenaire. Par exemple, une application peut parfois émettre l’un des verbes suivants :

  • MC_TEST_RTS

  • MC_RECEIVE_IMMEDIATE et vérifiez le champ rts_rcvd

  • MC_SEND_DATA de zéro octets, vérifiez à nouveau le champ rts_rcvd .

    Voici quelques-uns des problèmes associés à cette approche d’interrogation :

  • L’application doit interrompre continuellement son travail principal pour interroger APPC.

  • La demande du partenaire n’est pas détectée dès qu’elle est disponible.

  • Ces approches sont gourmandes en processeurs.

    Le verbe MC_TEST_RTS_AND_POST permet à une application s’exécutant sur Windows, généralement un émulateur 5250, de demander une notification asynchrone lorsque le tp partenaire demande une direction d’envoi.

    Une application APPC émet généralement le verbe MC_TEST_RTS_AND_POST en état SEND, puis continue avec son traitement principal. Une demande d’envoi de direction à partir du TP partenaire est indiquée de manière asynchrone à l’application. Après avoir rempli la demande du partenaire, l’application retourne généralement à l’état SEND, réédite MC_TEST_RTS_AND_POST et continue.

    Le verbe MC_TEST_RTS_AND_POST se termine de manière synchrone et le code de retour AP_OK indique qu’une demande de notification asynchrone a été inscrite. Il est important de souligner que cela n’indique pas que la demande d’envoi a été reçue du tp partenaire.

    Lorsque la demande d’envoi du partenaire est reçue, l’achèvement de l’événement asynchrone se produit. Il est important de noter que cela peut être avant la fin du verbe MC_TEST_RTS_AND_POST d’origine du TP local. Il s’agit du cas où la demande d’envoi du partenaire a été reçue avant que le verbe MC_TEST_RTS_AND_POST du tp local ait été émis ou que le verbe MC_TEST_RTS_AND_POST local ait été traité.

  • Last updated on