Condividi tramite


MC_TEST_RTS_AND_POST

Il verbo MC_TEST_RTS_AND_POST consente a un'applicazione, in genere un emulatore da 5250, di richiedere una notifica asincrona quando un programma di transazione partner (TP) richiede la direzione di invio.

La struttura seguente descrive il blocco di controllo verbo (VCB) usato dal verbo MC_TEST_RTS_AND_POST verbo.

Sintassi

  
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;  
};  

Members

Opcode
Parametro fornito. Specifica il codice dell'operazione verbo, AP_M_TEST_RTS_AND_POST.

opext
Parametro fornito. Specifica l'estensione dell'operazione verbo, AP_MAPPED_CONVERSATION.

reserv2
Campo riservato.

Primary_rc
Parametro restituito. Specifica il codice restituito primario impostato da APPC al completamento del verbo. I codici restituiti validi variano a seconda del verbo APPC rilasciato. Per questo verbo, vedere Codici restituiti per i codici di errore validi.

Secondary_rc
Parametro restituito. Specifica il codice restituito secondario impostato da APPC al completamento del verbo. I codici restituiti validi variano a seconda del verbo APPC rilasciato. Per questo verbo, vedere Codici restituiti per i codici di errore validi.

Tp_id
Parametro fornito. Identifica il TP locale. Il valore di questo parametro è stato restituito da TP_STARTED nella chiamata TP o da RECEIVE_ALLOCATE nel TP richiamato.

Conv_id
Parametro fornito. Fornisce l'identificatore della conversazione. Il valore di questo parametro è stato restituito da MC_ALLOCATE nella chiamata TP o da RECEIVE_ALLOCATE nel TP richiamato.

reserv3
Campo riservato.

Gestire
Parametro fornito. In Microsoft Windows questo campo fornisce l'handle eventi da impostare.

Codici restituiti dal verbo iniziale

AP_OK
Codice restituito primario; il verbo eseguito correttamente. Si noti in particolare che un codice restituito di AP_OK dal verbo iniziale non indica che MC_REQUEST_TO_SEND verbo ricevuto dal partner TP. Indica semplicemente che la struttura per ricevere una notifica asincrona è stata registrata.

AP_UNSUCCESSFUL
Codice restituito primario; la notifica request-to-send non è stata ricevuta.

AP_PARAMETER_CHECK
Codice restituito primario; il verbo non è stato eseguito a causa di un errore di parametro.

AP_BAD_CONV_ID

Codice restituito secondario; il valore di conv_id non corrisponde a un identificatore di conversazione assegnato da APPC.

AP_BAD_TP_ID

Codice restituito secondario; il valore di tp_id non corrisponde a un identificatore TP assegnato da APPC.

AP_COMM_SUBSYSTEM_ABENDED
Codice restituito primario; indica una delle condizioni seguenti:

  • Il nodo usato da questa conversazione ha rilevato un ABEND.

  • La connessione tra il tp e il nodo pu 2.1 è stata interrotta (errore LAN).

  • SnaBase nel computer TP ha rilevato un ABEND.

    L'amministratore di sistema deve esaminare il log degli errori per determinare il motivo di ABEND.

    AP_COMM_SUBSYSTEM_NOT_LOADED
    Codice restituito primario; Impossibile caricare o terminare un componente obbligatorio durante l'elaborazione del verbo. Pertanto, la comunicazione non poteva essere eseguita. Contattare l'amministratore di sistema per un'azione correttiva.

    Quando questo codice restituito viene usato con MC_ALLOCATE, può indicare che non è possibile trovare alcun sistema di comunicazione per supportare l'unità logica locale (LU). Ad esempio, l'alias LU locale specificato con TP_STARTED non è corretto o non è stato configurato. Si noti che se lu_alias o mode_name è inferiore a otto caratteri, è necessario assicurarsi che questi campi siano riempiti con spazi a destra. Questo errore viene restituito se questi parametri non vengono riempiti con spazi, poiché non è disponibile alcun nodo che può soddisfare la richiesta di MC_ALLOCATE .

    Quando MC_ALLOCATE produce questo codice restituito per un sistema client host integration server configurato con più nodi, sono disponibili due codici restituiti secondari come indicato di seguito:

    0xF0000001

    Codice restituito secondario; non sono stati avviati nodi.

    0xF0000002

    Codice restituito secondario; almeno un nodo è stato avviato, ma l'lu locale (quando viene rilasciato TP_STARTED ) non è configurato in alcun nodo attivo. Il problema potrebbe essere uno dei seguenti:

  • Il nodo con l'lu locale non viene avviato.

  • L'lu locale non è configurato.

    AP_CONVERSATION_TYPE_MIXED
    Codice restituito primario; il TP ha rilasciato verbi di conversazione di base e mappati. È possibile rilasciare un solo tipo in una singola conversazione.

    AP_INVALID_VERB_SEGMENT
    Codice restituito primario; VCB esteso oltre la fine del segmento di dati.

    AP_STACK_TOO_SMALL
    Codice restituito primario; le dimensioni dello stack dell'applicazione sono troppo piccole per eseguire il verbo. Aumentare le dimensioni dello stack dell'applicazione.

    AP_CONV_BUSY
    Codice restituito primario; c'è solo un verbo di conversazione in sospeso alla volta su qualsiasi conversazione. Ciò può verificarsi se il TP locale ha più thread e più thread eseguono chiamate APPC usando la stessa conv_id.

    AP_THREAD_BLOCKING
    Codice restituito primario; il thread chiamante è già in una chiamata di blocco.

    AP_UNEXPECTED_DOS_ERROR
    Codice restituito primario; il sistema operativo ha restituito un errore all'APPC durante l'elaborazione di una chiamata APPC dal TP locale. Il codice restituito dal sistema operativo viene restituito tramite il secondary_rc. Viene visualizzato nell'ordine di scambio di byte Intel. Se il problema persiste, consultare l'amministratore di sistema.

Codici restituiti dal completamento asincrono

AP_OK
Codice restituito primario; la notifica di richiesta da inviare è stata ricevuta dal PARTNER TP.

AP_CANCELLED
Il verbo TEST_RTS_AND_POST in sospeso è stato terminato. Ciò si verifica se la conversazione sottostante è stata deallocata o è stata rilasciata una AP_TP_ENDED. Si noti che come con RECEIVE_AND_POST, il TP è ancora responsabile della corretta terminazione della conversazione e possibilmente terminando il TP. L'emissione di un altro verbo, ad esempio RECEIVE_IMMEDIATE, in questo punto indicherà il motivo dell'errore della conversazione.

Commenti

La conversazione può essere in qualsiasi stato tranne RESET quando il TP genera questo verbo. Non esiste alcuna modifica dello stato.

Una funzionalità comune di molte applicazioni APPC, ad esempio 5250 emulatori, è un requisito per rilevare la richiesta di invio di un partner. Attualmente, questa operazione può essere eseguita eseguendo il polling dell'interfaccia APPC per rilevare la richiesta del partner. Ad esempio, un'applicazione può occasionalmente emettere uno dei verbi seguenti:

  • MC_TEST_RTS

  • MC_RECEIVE_IMMEDIATE e controllare il campo rts_rcvd

  • MC_SEND_DATA di zero byte, verificando nuovamente il campo rts_rcvd .

    Alcuni dei problemi associati a questo approccio di polling sono:

  • L'applicazione deve interrompere continuamente il lavoro principale per eseguire il polling di APPC.

  • La richiesta del partner non viene rilevata non appena diventa disponibile.

  • Questi approcci sono a elevato utilizzo del processore.

    Il verbo MC_TEST_RTS_AND_POST consente a un'applicazione in esecuzione in Windows, in genere un emulatore 5250, di richiedere una notifica asincrona quando il partner TP richiede la direzione di invio.

    Un'applicazione APPC genera in genere il verbo MC_TEST_RTS_AND_POST mentre è in stato SEND e quindi continua con l'elaborazione principale. Una richiesta di trasmissione dal tp del partner viene indicata in modo asincrono all'applicazione. Dopo aver gestito la richiesta del partner, l'applicazione torna in genere allo stato SEND, ristampa MC_TEST_RTS_AND_POST e continua.

    Il verbo MC_TEST_RTS_AND_POST viene completato in modo sincrono e il codice restituito AP_OK indica che è stata registrata una richiesta di notifica asincrona. È importante sottolineare che ciò non indica che la richiesta all'invio è stata ricevuta dal tp del partner.

    Quando viene ricevuta la richiesta di invio del partner, si verifica il completamento dell'evento asincrono. È importante notare che questo può essere prima del completamento del verbo MC_TEST_RTS_AND_POST originale del tp locale. Questo sarà il caso se la richiesta del partner di inviare è stata ricevuta prima dell'emissione del verbo MC_TEST_RTS_AND_POST tp locale o mentre il verbo MC_TEST_RTS_AND_POST tp locale è stato elaborato.