TEST_RTS_AND_POST

Article
10/14/2023

Le verbe 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 TEST_RTS_AND_POST .

Syntaxe

  
struct test_rts {  
    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_B_TEST_RTS_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 a été retournée par TP_STARTED dans le TP appelant 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 ALLOCATE dans le TP appelant ou par RECEIVE_ALLOCATE dans le TP appelé.

reserv3
Un 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 ; indique que le verbe s’est exécuté correctement. Notez en particulier qu’un code de retour de AP_OK du verbe initial n’indique pas que REQUEST_TO_SEND verbe reçu du TP partenaire. Il indique simplement que la possibilité de recevoir une notification asynchrone a été inscrite.

AP_UNSUCCESSFUL
Code de retour principal ; la notification de demande d’envoi 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 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_INVALID_SEMAPHORE_HANDLE

Code de retour secondaire, la valeur de handle n’était pas valide.

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 arrêté pendant le 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, cela 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 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 répondre à la demande ALLOCATE .

Lorsque ALLOCATE génère 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 émis) n’est configurée sur aucun nœud actif. Le problème peut être l’un des suivants :
Le nœud avec l’unité lu 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 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_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 à 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.

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

AP_OK
Code de retour principal ; la notification de demande d’envoi a été reçue du tp partenaire.

AP_CANCELLED
Le verbe TEST_RTS_AND_POST en suspens a été terminé. Cela se produit si la conversation sous-jacente a été libérée ou si un AP_TP_ENDED a été émis. Notez que, comme pour 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, à ce stade indique la raison de l’échec de la conversation.

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

Une fonctionnalité courante de nombreuses applications APPC, telles que les émulateurs 5250, est l’obligation de 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 :

TEST_RTS

Remarques

RECEIVE_IMMEDIATE et case activée le champ rts_rcvd
SEND_DATA de zéro octet, en vérifiant à nouveau le champ rts_rcvd .

Voici quelques-uns des problèmes associés à cette approche d’interrogation :
L’application doit interrompre continuellement son main travail pour interroger APPC.
La demande du partenaire n’est pas détectée dès qu’elle est disponible.
Ces approches sont gourmandes en processeur.

Le verbe 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 partenaire TP demande une direction d’envoi.

Une application APPC émet généralement le verbe TEST_RTS_AND_POST à l’état SEND, puis poursuit son traitement main. Une demande de direction d’envoi du tp partenaire est indiquée de manière asynchrone à l’application. Après traitement de la demande du partenaire, l’application retourne généralement à l’état SEND, réédite TEST_RTS_AND_POST et continue.

Le verbe 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 asynchrone de l’événement se produit. Il est important de noter que cela peut être avant l’achèvement du verbe TEST_RTS_AND_POST d’origine du TP local. Ce sera le cas si la demande d’envoi du partenaire a été reçue avant l’émission du verbe TEST_RTS_AND_POST du TP local, ou pendant le traitement du verbe TEST_RTS_AND_POST du TP local.

Partager via