En el entorno CICS, la planificación de PSB se maneja de forma diferente que en los entornos no CICS. Las secciones que siguen describen la planificación de PSB, cómo utilizar un PSB alternativo durante la ejecución y cómo compartir un PSB con un programa llamado.
Al utilizar una sentencia CALL o DXFR para transferir el control del programa, el programa receptor no tiene que utilizar el mismo PSB utilizado por el programa transfiriente.
EGL utiliza el PSB indicado en la especificación de programa para crear llamadas DL/I para los segmentos definidos en el PSB y para validar los cambios realizados en las llamadas DL/I. En el entorno CICS, Enterprise Developer Server para z/OS también utiliza el nombre del PSB para la planificación de PSB en el momento de ejecutar el programa.
Sin embargo, a veces puede que desee utilizar un PSB alternativo con el mismo programa. El PSB alternativo describe bases de datos con la misma estructura exacta que el PSB del programa, pero las bases de datos en sí pueden ser diferentes. Por ejemplo, puede que tenga un conjunto de bases de datos de prueba para el desarrollo del programa y un conjunto correspondiente de bases de datos de producción que contengan los datos reales para la producción.
Si desea utilizar un PSB alternativo por alguna razón, el programa puede cambiar dinámicamente el PSB planificado colocando el PSB alternativo en DLIVar.dliPsbName antes de ejecutar la primera función DL/I. El PSB alternativo debe coincidir con el PSB del programa, excepto en que los nombres de las bases de datos pueden ser diferentes.
Los programas llamado y llamante no pueden ser ambos programas DL/I, a menos que compartan el mismo PSB de programa o que se realice una operación de compromiso para finalizar el PSB antes de cada llamada o retorno a un programa que utilice un PSB diferente. El PSB se comparte pasando la estructura DLILib.psbData o los registros PCB en la llamada tanto del programa llamado como del llamante.
Si los programas llamado y llamante son ambos programas EGL, y si el PSB estaba planificado antes de la llamada, EGL no vuelve a planificarlo en el programa llamado.
Puede compartir un PSB entre programas EGL y programas no EGL. Cuando la estructura de datos DLILib.psbData se pasa como parámetro, se pasa en realidad un área de 12 bytes. Los 8 primeros bytes contienen el nombre del PSB; los 4 bytes finales contienen la dirección del Bloque de interfaz de usuario (UIB) de CICS. Si el PSB no está planificado, la dirección UIB es 0. Al compartir un PSB entre programas EGL y no EGL, el programa llamado debe comprobar la dirección UIB antes de planificar. Si la dirección UIB no es 0, el PSB no de planificarse de nuevo. Si el programa llamado finaliza el PSB, debe establecer el campo de dirección UIB en 0. Si el PSB se planifica de nuevo, el campo de dirección UIB debe establecerse en la dirección UIB devuelta por CICS.
Si un programa necesita compartir un PSB planificado con un programa EGL llamado, debe pasar un área de 12 bytes al programa. De nuevo, los 8 primeros bytes deben contener el nombre del PSB y los últimos 4 bytes deben contener la dirección UIB. Si el PSB no está planificado, la dirección UIB debe ser 0. En el retorno, la dirección UIB refleja el estado de planificación actual del PSB.
Los registros actualizados no se escriben realmente en la base de datos hasta que el PSB ha finalizado. El programa obtiene el uso exclusivo de estos registros hasta la finalización del PSB, debido a que la sentencia de E/S EGL get...forUpdate impide que otros programas puedan cambiar de nuevo el registro hasta que éste se ha escrito realmente en la base de datos. Esto puede provocar una situación de punto muerto, en la que el programa tiene algún registro bloqueado y en ese momento desea cambiar registros bloqueados por otro programa que, a su vez, necesita los registros que usted ha bloqueado. Cuando CICS detecta una situación de punto muerto, finaliza de forma anómala uno de los programas, restituye los cambios que ha efectuado en la base de datos y escribe un mensaje de error en el terminal, que describe por qué ha finalizado el programa.
Si la finalización anómala de un programa es inaceptable para los usuarios del mismo, puede definir el programa como reiniciable en las tablas de CICS. Para obtener información acerca del reinicio de programas, consulte la sección "Reiniciar programas EGL después de un punto muerto DL/I", más adelante en este mismo tema.
Si el programa es reiniciable y CICS detecta una situación de punto muerto, CICS restituye los cambios que el programa ha realizado desde que se planificó el PSB y reinicia el programa desde el principio de la transacción.
Si el programa se ejecuta en modalidad segmentada (pseudoconversacional), se reinicia el segmento más reciente del programa y no es necesario ningún código especial de reinicio en el programa.
Si se reinicia un programa conversacional, éste se inicia de nuevo por el principio. Puede determinar que el programa se ha reiniciado haciendo que éste pruebe un valor 1 en el campo DLIVar.cicsRestart. Si DLIVar.cicsRestart es 1, puede escribir un mensaje al usuario del programa indicando que el programa se ha reiniciado debido a un punto muerto y, a continuación, visualizar de nuevo la correlación de programa inicial.
Cuando se utiliza el recurso de aislamiento de programas DL/I, pueden producirse puntos muertos entre dos transacciones que bloquean el mismo registro. Los programas intentan actualizar el mismo registro simultáneamente. Si ambas actualizaciones se aceptan, uno de los cambios se pierde. Si CICS detecta que se pierden datos, finaliza anormalmente la transacción con un código de finalización anómala ADLD.
De lo contrario, CICS escribe un mensaje indicando la razón de la finalización del programa. Un programa reiniciado es un programa que se inicia de nuevo desde el principio de la última transacción que se estaba ejecutando. Todos los cambios realizados en las bases de datos desde que el PSB del programa se planificó por última vez se retrotraen.
Los programas ejecutados en modalidad segmentada deben tener todos los recursos de CICS (que deben actualizarse) definidos como recuperables si se solicita el reinicio. Los nombres de las colas de almacenamiento temporal creadas por la función de segmentación de Enterprise Developer Server para z/OS son una combinación del identificador de terminal del usuario añadido a un prefijo de 4 caracteres. Los prefijos utilizados tienen el formato X‘EE‘ seguido de WRK o MSG.
No debe solicitar el reinicio de programas conversacionales, a menos que haya diseñado el programa para manejar el reinicio. Un programa puede comprobar el campo DLIVar.cicsRestart para ver si la transacción de programa actual se ha reiniciado. Una forma sencilla de diseñar un programa para el reinicio consiste en hacer que éste compruebe cicsRestart siempre que se inicia. Si el indicador de reinicio está activado, el usuario 1 debe visualizar una correlación o mensaje especial indicando que la transacción se ha reiniciado por el principio debido a que el usuario 2 estaba cambiando la base de datos simultáneamente. Los cambios del usuario 1 se han restituido, y el programa se ha reiniciado para evitar la pérdida de los datos.