Debajo de la interfaz de SNA
Para diseñar procesos distribuidos de alto rendimiento, es necesario conocer los protocolos SNA y los correspondientes indicadores de control de flujo de datos (DFC) que CICS® utiliza para la autoedición, y cómo se relacionan los indicadores DFC con los comandos y opciones CICS. Además, necesita estos conocimientos para comprender la traza de CICS.
Excepto para algunos comandos que pueden causar transmisiones en contra del flujo
(como ISSUE SIGNAL), el flujo de conversación y el conjunto de indicadores son dictados por la transacción actualmente en estado de envío (estado 2).
Indicadores y registros del SCN
Los indicadores y registros SNA pueden generarse explícitamente como resultado de un comando CICS, o automáticamente cuando CICS detecta que son necesarios.
Los indicadores y registros más comunes del SCN:
- Paréntesis_inicial y paréntesis_fin_condicional
- Los indicadores begin_bracket (BB) y condition_end_bracket (CEB) de la cabecera de la petición (RH) denotan respectivamente el inicio y el final de una conversación entre dos transacciones. Como la BB se genera automáticamente al inicio de una conversación, sólo hay que tener en cuenta la CEB. El CEB es generado por un SEND con la opción LAST, un ISSUE ABEND, un comando FREE, o la terminación de una tarea antes de finalizar la conversación.
- Cabeceras de gestión de funciones
- Las cabeceras de gestión de funciones (FMH) son registros enviados en una conversación que contienen datos de control SNA. En el SCN se definen varios tipos de FMH, pero sólo dos FMH5 y FMH7 ) son relevantes para la APPC DTP.
El FMH5, también conocido como el FMH adjunto, se envía con BB y contiene la información necesaria para iniciar la transacción back-end.
El FMH7 es emitido por los comandos ISSUE ERROR, ISSUE ABEND y SYNCPOINT ROLLBACK. Además, si el sistema back-end rechaza el FMH5, se envía un FMH7 a la transacción front-end. El FMH7 contiene un código de 4 bytes, denominado código de sentido, que describe el error. Este código se establece en EIBERRCD (o CDBERRCD para conversaciones básicas). El FMH7 puede ir seguido de datos de registro. Estos datos de registro se incluyen en el mensaje DFHZN2701 en el sistema emisor y DFHZC3433 en el sistema receptor.
- Cambiar de dirección
- El indicador de cambio de dirección (CD), que se encuentra en el RH, cambia la transacción de emisión del estado de envío (estado 2) al estado de recepción (estado 5). CD se genera explícitamente mediante una de las siguientes acciones:
- Un comando SEND con la opción INVITE
- Un comando CONVERSE.
- Cabecera PS (tipo 10)
- Las cabeceras PS (tipo 10) son registros enviados en una conversación que contienen solicitudes de puntos de sincronización. Estas cabeceras contienen un código de solicitud de punto de sincronización de 2 bytes (por ejemplo, prepare, request commit, committed y forget ). Además, el registro inicial enviado contiene un modificador de 2 bytes que especifica el estado de la conversación tras un intercambio syncpoint satisfactorio.
Modo de solicitud y respuestas
Cuando se envían datos, normalmente no se espera una respuesta confirmando la recepción de los mismos, a menos que los datos se envíen con la opción CONFIRM. Normalmente, los datos se envían en modo RQE (request exception response), lo que significa que sólo se requiere una respuesta si es necesario transmitir una condición de error. Esta respuesta se denomina -RSP (respuesta negativa) y puede preceder a una FMH7. Sin embargo, si los datos se envían con la opción CONFIRM, los datos se envían en modo RQD (request definite response). Esto significa que la transacción de envío se suspenderá hasta que se reciba una DR (respuesta definitiva) o -RSP. La transacción asociada genera un DR con el comando ISSUE CONFIRMATION.
Cuando se transmiten indicadores SNA
Para optimizar el uso de las sesiones ISC, CICS aplaza el procesamiento de salida para los comandos SEND. La salida diferida permite a menudo a CICS añadir indicadores SNA a los datos en espera antes de transmitirlos. De este modo, se reduce el número de transmisiones en la sesión.
Para las sesiones APPC, esta reducción se consigue acumulando tantos datos como sea posible en un búfer CICS antes de transmitirlos a través del enlace. De este modo, los datos de una serie de comandos SEND sólo se transmiten cuando la memoria intermedia se llena o cuando debe forzarse la transmisión (por ejemplo, si se encuentra SEND WAIT).
La optimización de la transmisión ISC no afecta al número de flujos de datos que ve la interfaz de programación de aplicaciones.