Consideraciones sobre SNA en relación con LUA

En esta sección se explica la información de SNA que debe tener en cuenta al escribir aplicaciones de aplicación de unidad lógica (LUA).

Comprobación de BIND

Durante la inicialización de la sesión de LU, el host envía a la aplicación LUA un mensaje BIND que contiene información como tamaños de unidad de solicitud/respuesta (RU) para su uso por la sesión de LU. Microsoft® Host Integration Server devuelve este mensaje a la aplicación LUA en RUI_READ. La aplicación LUA debe comprobar que los parámetros especificados en BIND son adecuados. La aplicación tiene las siguientes opciones:

• Puede aceptar BIND tal como está, emitiendo RUI_WRITE que contiene una respuesta OK a BIND. No se pueden enviar datos BIND adicionales en la respuesta.

• Puede intentar negociar uno o varios parámetros BIND. (Esto solo se permite si bind es negociable). Para ello, la aplicación emite RUI_WRITE que contiene una respuesta OK, pero incluye bind modificado como datos.

• Puede rechazar el BIND emitiendo RUI_WRITE que contenga una respuesta negativa, utilizando un código de sentido SNA adecuado como datos.

  Validar los parámetros BIND y asegurarse de que todos los mensajes enviados sean coherentes con ellos es responsabilidad de la aplicación LUA. Sin embargo, se aplican las dos restricciones siguientes:

• Host Integration Server rechaza cualquier RUI_WRITE que especifique una longitud de RU mayor que el tamaño especificado en BIND.

• Host Integration Server requiere que la instrucción BIND especifique que la LU secundaria es la que gana la contención, y que la responsabilidad de la recuperación de errores recae en el perdedor de la contención.

  Nota:

  Para SLI, una aplicación debe especificar que usará SLI_BIND_ROUTINE en el SLI_OPEN si realizará alguna comprobación BIND.

Confirmaciones de cortesía

Host Integration Server mantiene un registro de las solicitudes recibidas del host para correlacionar cualquier respuesta enviada por la aplicación con la solicitud adecuada. Cuando la aplicación envía una respuesta, Host Integration Server correlaciona la respuesta con los datos de la solicitud original y, a continuación, puede liberar el almacenamiento asociado.

Si el host especifica solo la respuesta de excepción (se puede enviar una respuesta negativa, pero no se debe enviar una respuesta positiva), Host Integration Server debe mantener un registro de la solicitud en caso de que la aplicación envíe posteriormente una respuesta negativa. Si la aplicación no envía una respuesta, no se puede liberar el almacenamiento asociado a esta solicitud.

Por este motivo, Host Integration Server permite que la aplicación LUA emita una respuesta positiva a una solicitud del host que solo requiere respuesta de excepción. (Esto se conoce como confirmación de cortesía). La respuesta no se envía al host, pero la LUA la usa para borrar el almacenamiento asociado a la solicitud.

Distinguir códigos de sentido SNA de otros códigos de retorno secundarios

Un código de retorno secundario que no es un código de sentido siempre contiene un valor de cero en sus dos primeros bytes.

Un código de detección de SNA siempre contiene un valor distinto de cero en sus dos primeros bytes. El primer byte proporciona la categoría de código de sentido y el segundo identifica un código de sentido determinado dentro de esa categoría. (Los bytes tercero y cuarto pueden contener información adicional o pueden ser cero).

Información sobre los códigos de detección de SNA

Si necesita información sobre un código de sentido devuelto, consulte

• Mensaje de Error de Estado

• Códigos de error y de detección

Respuestas negativas y códigos de detección de SNA

Los códigos de sentido de SNA se pueden devolver a una aplicación LUA en los casos siguientes:

• Cuando el host envía una respuesta negativa a una solicitud de la aplicación LUA, incluye un código de sentido SNA que indica el motivo de la respuesta negativa. Esto se notifica a la aplicación en una RUI_READ posterior o SLI_RECEIVE con la siguiente información.

  Código de sentido	Descripción
  Código de retorno principal	LUA_OK.
  Indicador de solicitud/respuesta, indicador de tipo de respuesta y datos de detección incluidos	Todo establecido en 1, lo que indica una respuesta negativa que incluye datos de sensor.
  Datos devueltos	Código de sentido de SNA.

• Cuando Host Integration Server recibe datos no válidos del host, normalmente envía una respuesta negativa al host y no pasa los datos no válidos a la aplicación LUA. Esto se notifica a la aplicación en una RUI_READ posterior, SLI_RECEIVE, RUI_BID oSLI_BID con la siguiente información:

  Código de sentido	Descripción
  Código de retorno principal	LUA_NEGATIVE_RESPONSE.
  Código de retorno secundario	Código de detección de SNA enviado al host.

• En algunos casos, Host Integration Server detecta que los datos proporcionados por el host no son válidos, pero no pueden determinar el código de sentido correcto que se va a enviar. En este caso, pasa los datos no válidos en una solicitud de excepción (EXR) a la aplicación LUA en RUI_READ o SLI_RECEIVE con la siguiente información.

  Código de sentido	Descripción
  Indicador de solicitud/respuesta	Establézcalo en 0, que indica una solicitud.
  Indicador incluido de los datos de sensor	Se establece en 1, lo que indica que se incluyen los datos de sentido. (Este indicador se usa normalmente solo para una respuesta).
  Datos de mensajes	Código de detección de SNA sugerido.

  A continuación, la aplicación debe enviar una respuesta negativa al mensaje. Puede usar el código de sentido sugerido por Host Integration Server o puede modificar el código de sentido.

• Host Integration Server puede enviar un código de sentido a la aplicación para indicar que los datos proporcionados por la aplicación no eran válidos. Esto se notifica a la aplicación en RUI_WRITE o SLI_SEND con la siguiente información.

  Código de sentido	Descripción
  Código de retorno principal	Error: LUA_NO_EXITOSO.
  Código de retorno secundario	Código de detección de SNA.

  Los códigos de estado que se pueden devolver como códigos de retorno secundarios en verbos LUA se enumeran en el archivo de encabezado WINLUA.H. Para este archivo, consulte Host Integration Server o el SDK de SNA.

Sincronización

El ritmo se controla mediante la interfaz LUA. Una aplicación LUA no necesita controlar el ritmo y nunca debe establecer la marca del indicador de velocidad.

Si se usa el ritmo en los datos enviados desde la aplicación LUA al host (determinado por BIND), RUI_WRITE o SLI_SEND pueden tardar algún tiempo en completarse. Esto se debe a que LUA tiene que esperar una respuesta de velocidad del host antes de que pueda enviar más datos.

Si una aplicación LUA transfiere grandes cantidades de datos en una dirección, ya sea al host o desde el host (por ejemplo, una aplicación de transferencia de archivos), la configuración del host debe especificar que se use el ritmo en esa dirección. Esto garantiza que el nodo que recibe los datos no está inundado de datos y no se queda sin almacenamiento de datos.

Purga de datos al final de la cadena

Cuando el host envía una cadena de unidades de solicitud a una aplicación LUA, la aplicación puede esperar hasta que se reciba la última RU de la cadena antes de enviar una respuesta, o puede enviar una respuesta negativa a una RU que no sea la última de la cadena. Si se envía una respuesta negativa a mitad de la cadena, LUA purga todas las RU subsiguientes de esta cadena y no las envía a la aplicación.

Cuando LUA recibe la última RU de la cadena, indica esto a la aplicación estableciendo el código de retorno principal de RUI_READ o RUI_BID en LUA_NEGATIVE_RESPONSE con un código de retorno secundario cero.

El host puede finalizar la cadena enviando un mensaje como CANCEL mientras se encuentra en la cadena media. En este caso, el mensaje CANCEL se devuelve a la aplicación en RUI_READ. No se usa el código de retorno LUA_NEGATIVE_RESPONSE.

Segmentation

La segmentación de RU se controla mediante la interfaz LUA. LUA siempre pasa RU completas a la aplicación, y la aplicación debe pasar RU completas a LUA.