MC_TEST_RTS_AND_POST

Artículo
07/21/2023

El verbo MC_TEST_RTS_AND_POST permite a una aplicación, normalmente un emulador de 5250, solicitar una notificación asincrónica cuando un programa de transacciones de asociado (TP) solicita la dirección de envío.

En la estructura siguiente se describe el bloque de control de verbos (VCB) usado por el verbo MC_TEST_RTS_AND_POST .

Sintaxis

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

Miembros

opcode
Parámetro proporcionado. Especifica el código de operación de verbo, AP_M_TEST_RTS_AND_POST.

opext
Parámetro proporcionado. Especifica la extensión de operación de verbo, AP_MAPPED_CONVERSATION.

reserv2
Campo reservado.

primary_rc
Parámetro devuelto. Especifica el código de retorno principal que establece APPC al finalizar el verbo. Los códigos de retorno válidos varían en función del verbo APPC que se emita. Consulte la sección de códigos de retorno para obtener los códigos de error válidos para este verbo.

secondary_rc
Parámetro devuelto. Especifica el código de retorno secundario que establece APPC al finalizar el verbo. Los códigos de retorno válidos varían en función del verbo APPC que se emita. Consulte la sección de códigos de retorno para obtener los códigos de error válidos para este verbo.

tp_id
Parámetro proporcionado. Identifica el TP local. El valor de este parámetro lo devolvió TP_STARTED en el TP invocado o por RECEIVE_ALLOCATE en el TP invocado.

conv_id
Parámetro proporcionado. Proporciona el identificador de conversación. El valor de este parámetro lo devolvió MC_ALLOCATE en el TP invocado o por RECEIVE_ALLOCATE en el TP invocado.

reserv3
Campo reservado.

handle
Parámetro proporcionado. En Microsoft Windows, este campo proporciona el identificador de eventos que se va a establecer.

Códigos de retorno del verbo inicial

AP_OK
Código de retorno principal; el verbo se ha ejecutado correctamente. Tenga en cuenta especialmente que un código de retorno de AP_OK del verbo inicial no indica que MC_REQUEST_TO_SEND verbo recibido del TP del asociado. Simplemente indica que la instalación para recibir notificaciones asincrónicas se ha registrado.

AP_UNSUCCESSFUL
Código de retorno principal; no se ha recibido la notificación de solicitud a envío.

AP_PARAMETER_CHECK
Código de retorno principal; el verbo no se ha ejecutado debido a un error en un parámetro.

AP_BAD_CONV_ID

Código de retorno secundario; el valor de conv_id no coincide con un identificador de conversación asignado por APPC.

AP_BAD_TP_ID

Código de retorno secundario; el valor de tp_id no coincide con un identificador de TP asignado por APPC.

AP_COMM_SUBSYSTEM_ABENDED
Código de retorno principal; indica una de las condiciones siguientes:

El nodo utilizado por esta conversación encontró una anulación.
La conexión entre el TP y el nodo PU 2.1 se interrumpió (un error de LAN).
El proceso SnaBase que se ejecuta en el equipo del TP encontró una anulación.

El administrador del sistema debe examinar el registro de errores a fin de determinar el motivo de la anulación.

AP_COMM_SUBSYSTEM_NOT_LOADED
Código de retorno principal; no se pudo cargar un componente necesario o se ha terminado mientras se procesa el verbo. Por tanto, no se pudo establecer la comunicación. Consulte al administrador del sistema para aplicar una acción correctiva.

Cuando este código de retorno se usa con MC_ALLOCATE, puede indicar que no se puede encontrar ningún sistema de comunicaciones para admitir la unidad lógica local (LU). (Por ejemplo, el alias de LU local especificado con TP_STARTED es incorrecto o no se ha configurado). Tenga en cuenta que si lu_alias o mode_name tiene menos de ocho caracteres, debe asegurarse de que estos campos estén llenos de espacios a la derecha. Este error se devuelve si estos parámetros no se rellenan con espacios, ya que no hay ningún nodo disponible que pueda satisfacer la solicitud de MC_ALLOCATE .

Cuando MC_ALLOCATE genera este código de retorno para un sistema cliente de Host Integration Server configurado con varios nodos, hay dos códigos de retorno secundarios de la siguiente manera:

0xF0000001

Código de retorno secundario; no se ha iniciado ningún nodo.

0xF0000002

Código de retorno secundario; se ha iniciado al menos un nodo, pero la LU local (cuando se emite TP_STARTED ) no está configurada en ningún nodo activo. El problema podría ser cualquiera de los siguientes:
No se inicia el nodo con la LU local.
La LU local no está configurada.

AP_CONVERSATION_TYPE_MIXED
Código de retorno principal; el TP ha emitido verbos de conversación básicos y asignados. Solo se puede emitir un tipo en una sola conversación.

AP_INVALID_VERB_SEGMENT
Código de retorno principal; el bloque de control de verbo (VCB) se ha extendido más allá del final del segmento de datos.

AP_STACK_TOO_SMALL
Código de retorno principal; el tamaño de la pila de la aplicación es demasiado pequeño para ejecutar el verbo. Aumente el tamaño de pila de la aplicación.

AP_CONV_BUSY
Código de retorno principal; solo puede haber un verbo de conversación pendiente a la vez en cualquier conversación. Esto puede ocurrir si el TP local tiene varios subprocesos y más de un subproceso emite llamadas APPC con la misma conv_id.

AP_THREAD_BLOCKING
Código de retorno principal; el subproceso que llama ya está en una llamada de bloqueo.

AP_UNEXPECTED_DOS_ERROR
Código de retorno principal; el sistema operativo devolvió un error a APPC al procesar una llamada de APPC desde el TP local. El código de retorno del sistema operativo se devuelve a través de secondary_rc. Aparece en el orden de intercambio de bytes de Intel. Si el problema persiste, consulte con el administrador del sistema.

Códigos de retorno de la finalización asincrónica

AP_OK
Código de retorno principal; la notificación de solicitud a envío se ha recibido del TP del asociado.

AP_CANCELLED
Se ha terminado el verbo TEST_RTS_AND_POST pendiente. Esto se producirá si la conversación subyacente se ha desasignado o se ha emitido un AP_TP_ENDED. Tenga en cuenta que, al igual que con RECEIVE_AND_POST, el TP sigue siendo responsable de finalizar correctamente la conversación y posiblemente terminar el TP. La emisión de otro verbo, como RECEIVE_IMMEDIATE, en este momento indicará el motivo del error de conversación.

Comentarios

La conversación puede estar en cualquier estado excepto RESET cuando el TP emite este verbo. No hay ningún cambio de estado.

Una característica común de muchas aplicaciones APPC, como 5250 emuladores, es un requisito para detectar la solicitud de un asociado para enviar. Actualmente, esto se puede hacer sondeando la interfaz APPC para detectar la solicitud del asociado. Por ejemplo, una aplicación puede emitir ocasionalmente uno de los verbos siguientes:

MC_TEST_RTS
MC_RECEIVE_IMMEDIATE y compruebe el campo rts_rcvd
MC_SEND_DATA de cero bytes, de nuevo comprobando el campo rts_rcvd .

Algunos de los problemas asociados a este enfoque de sondeo son:
La aplicación debe interrumpir continuamente su trabajo principal para sondear APPC.
La solicitud del asociado no se detecta tan pronto como esté disponible.
Estos enfoques consumen muchos procesadores.

El verbo MC_TEST_RTS_AND_POST permite que una aplicación que se ejecute en Windows, normalmente un emulador de 5250, solicite una notificación asincrónica cuando el TP del asociado solicite la dirección de envío.

Normalmente, una aplicación APPC emite el verbo MC_TEST_RTS_AND_POST mientras está en estado SEND y, a continuación, continúa con su procesamiento principal. Una solicitud de dirección de envío del TP del asociado se indica de forma asincrónica a la aplicación. Después de tratar con la solicitud del asociado, la aplicación normalmente vuelve al estado SEND, vuelve a emitir MC_TEST_RTS_AND_POST y continúa.

El verbo MC_TEST_RTS_AND_POST se completa de forma sincrónica y el código de retorno AP_OK indica que se ha registrado una solicitud de notificación asincrónica. Es importante destacar que esto no indica que la solicitud de envío se recibió del TP del asociado.

Cuando se recibe la solicitud del asociado para enviar, se produce la finalización del evento asincrónico. Es importante tener en cuenta que esto puede ser antes de la finalización del verbo MC_TEST_RTS_AND_POST original del TP local. Este será el caso si la solicitud del asociado para enviar se recibió antes de que se emitiera el verbo de MC_TEST_RTS_AND_POST tp local, o mientras se procesaba el verbo de MC_TEST_RTS_AND_POST tp local.

Compartir a través de