Fallos comunes del Sistema de control de información de clientes (Parte 1: Generalidades)

  En entradas anteriores se ha hablado del Sistema de control de información de clientes.
  Se trata de un gestor transaccional (componente que procesa información descomponiéndola de forma unitaria en operaciones indivisibles, llamadas transacciones), o monitor de teleproceso, que se ejecuta principalmente en ordenadores centrales IBM con los sistemas operativos OS/390, z/OS o VSE; aunque también existen versiones de SCIC para otros entornos, como OS/400, OS/2, etc. La versión para entornos Unix recibe el nombre de TX Series.
  Este programa está diseñado para procesar tanto transacciones en línea (instantáneas; suelen aparecer representados con un "1" en la 5ª posición del nombre de la operación de la aplicación del sistema asociada) como por lotes ("batch", en inglés).

 

FINAL ANORMAL

  En Informática, en general, la terminación inesperada, o final anormal, de un programa debido a un error o fallo se describe con un término comúnmente utilizado en la programación de ordenadores centrales denominado “ABEND”, por el término en inglés “abnormal end”, acuñado cuando los mensajes del operador debían ser lo más breves posible.
  Un final anormal es una terminación inesperada o anormal de una aplicación o sistema operativo que resulta de un problema con el soporte lógico. Ocurre cuando el sistema anfitrión no puede resolver una condición de error generada por el programa.
  Cuando un programa experimenta una terminación inesperada, el sistema emite un mensaje de error que, a menudo, incluye información para ayudar a resolver el problema. Una terminación anómala puede ocurrir por múltiples razones, pero, por lo general, es el resultado de un error de la aplicación o un problema relacionado con la memoria.
   Los finales anormales a veces se clasifican como suaves o duros. Un final inesperado se considera suave si el sistema puede recuperarse automáticamente del error. Si el sistema no puede recuperarse automáticamente, el final anormal se considera duro. Los sistemas operativos más actuales pueden manejar los finales anormales con más habilidad que en el pasado, limitando el problema a la aplicación en sí en lugar de hacer que se caiga todo el sistema.

 

FINAL ANORMAL EN SCIC

  En el Sistema de control de información de clientes, el final anormal se define como un error grave que hace que una transacción termine abrupta e inesperadamente, y se identifica mediante un código de 4 caracteres que indica la naturaleza y el origen del error.
  Para poder investigar más detalladamente un error de este tipo es posible emplear las transacciones DUMP y CEDF desde el propio CIC afectado.

 

Transacción DUMP 

  Aunque esta transacción se suele utilizar para solicitar un volcado de transacción, también sirve para mostrar el código abend y otra información de diagnóstico en un terminal desde el programa de aplicación.
  Su sintaxis para esta función sería:

EXEC CICS DUMP TRANSACTION

Transacción CEDF

  Como ya se ha dicho en una entrada anterior, esta transacción permite al usuario interceptar los programas de aplicación en la iniciación del programa, en cada comando SCIC y en la terminación del programa, ayudándole a aislar y centrarse en los problemas de los programas de aplicación, puesto que inicia la herramienta de depuración del Sistema de control de información de clientes {llamada Recurso de diagnóstico de ejecución [“Execution diagnostic facility” (“EDF”), en inglés]}. Por lo tanto, puede emplearse para depurar y rastrear la ejecución de una transacción e identificar el punto de error.
  Dentro de un terminal CIC, se ejecutará la transacción CEDF, con lo que se activará el EDF con un mensaje como:

    Tras esto, se escribirá el identificador de la transacción a tratar (tras borrar la línea anterior), lo que devolverá una primera pantalla con datos y un menú. 

   Acto seguido, se pulsa la tecla de entrada nuevamente y, si existe terminación anómala, se indicará en el “STATUS”, y aparecerá una nueva línea con el código de la misma.

  Si hay algún campo de bloque de interfaz EXEC [“EXEC interface block” (“EIB”), en inglés], cuyo valor sea distinto de “X’<los “0” que sean>’” (salvo en los campos cuyo valor no sea éste normalmente), es que el fallo está relacionado con éste [el más obvio para cerciorarse de que hay un error es el campo “EIBERR”, que indica que se ha recibido un error (X'FF') en una conversación APPC].

   

   Otro método es buscar el historial del CIC afectado en la herramienta de SCIC de Omegamon.

   Una vez seleccionado el CIC a investigar, se debe configurar su historial de transacciones escribiendo “H.B” en la línea que se encuentra al lado de la cabecera de la pantalla.

  A continuación, se cambia el valor del parámetro “ABENDS” a “YES” y se pulsa la tecla de entrada 2 veces.  

  Seguidamente, se escribirá “H.A” en la línea que se encuentra al lado de la cabecera de la pantalla para regresar al historial de transacciones con la nueva configuración.

  En esta pantalla hay que fijarse en la columna “Tran ID” y “Abend Code”. 

  Con esta información, se va al menú principal de z/OS y, desde ahí, se sigue la ruta “G > C” para ver los mensajes del registro del CIC cuya transacción ha terminado anormalmente. En la pantalla siguiente se escribe el comando “F <código del ABEND>” (“AISP”, en el ejemplo) para buscar más detalles sobre el error que lo provocó.

POSIBLES SOLUCIONES

  Como sucede con otros tipos de errores de las transacciones, es posible emplear la recuperación y el reinicio, procesos de restauración del sistema y la aplicación a un estado coherente después de un escenario de error o excepción, para solucionar una terminación anormal. De este modo, la recuperación implica deshacer o compensar cualquier cambio realizado por una transacción antes de que fallara; mientras que, por su parte, el reinicio implica reanudar o repetir la transacción desde un punto conocido. Existen funciones y herramientas de SCIC (diarios, registros, puntos de sincronización y puntos de control) que admiten la recuperación y el reinicio. Por otra parte, es posible emplear el comando EXEC CICS HANDLE ABEND para especificar una rutina de recuperación que pueda realizar acciones personalizadas, (registrar, informar, notificar…), antes de finalizar una transacción.
  Por otra parte, las técnicas de control de errores son métodos y prácticas esenciales que se pueden utilizar para prevenir, detectar y corregir errores y excepciones en las transacciones SCIC. Algunos pasos importantes consisten en   la validación de los datos y parámetros de entrada, utilizando los tipos de datos, formatos y longitudes correctos para variables y campos, así como los códigos de error, mensajes e indicadores apropiados. Asimismo, las técnicas de programación modular y estructurada pueden simplificar y organizar el código, mientras que los comentarios y la documentación pueden explicar la lógica y el propósito del mismo. También es básico probar y depurar el código a fondo antes de implementarlo, así como revisarlo y actualizarlo regularmente para corregir cualquier error o mejorar cualquier característica.

 

  Espero que la presente entrada haya sido interesante para el lector. Si es así, aguardo que éste  la comente y/o la comparta, por favor.