Manual de desarrollo en PLI

Objetivo del documento

El objetivo del presente documento es el enumerar una serie de factores a tener en cuenta a la hora de codificar un programa PL/I. Esta serie de factores han de influir en el grado de incidencia y mantenibilidad del programa, depurando el código y logrando una mayor comprensibilidad del objetivo del fuente.

El documento se divide en diversos apartados con la intención de abarcar toda posible tipología de programas y fases del desarrollo. Estos apartados son :

• PL/I : Consejos a nivel genérico.

• ON LINE :Aspectos destacables de la programación de transacciones ON LINE.

• BATCH : Puntualizaciones sobre programas BATCH.

• JCL's : Recomendaciones de carácter practico para la confección de JOBS.

• Análisis Orgánico : Puntos clave para la confección de análisis orgánicos.

PL/I

Declaraciones

• Utilización del tipo de variables mas adecuado según cada caso.

• Dec Fixed para contadores y operaciones

• PIC para edición

• No utilizar en lo posible las variables float.

• Las variables de tipo PIC solamente se han de utilizar para edición, nunca para operar con ellos.

• En caso de tener que inicializar muchas veces una misma estructura es mejor utilizar una estructura LIKE inicializada que inicializarla cada vez a "".

P ej : DCL 1 ESTRUCTURA,

3 DATOS....

3 DATOS...

3 DATOS....

DCL 1 ESTRUCTURA_INIT LIKE ESTRUCTURA;;

ESTRUCTURA_INIT = `'

Cada vez que queramos inicializar ESTRUCTURA le asignamos los datos de ESTRUCTURA_INIT.

• Declarar únicamente las variables que realmente se utilicen.

• El nombre de las variables ha de mantener cierta lógica con el uso que de ellas se hace.

P. ej : CONT_... Para contadores

TOTAL_.... o

SUMA_... Para contabilizar.

AUX_.... Para variables intermedias o de conversión.

• Las variables, en la medida de lo posible, deben declararse a nivel local. De esta manera tendremos control de su procedencia y uso.

Asignaciones

• Evitar operaciones de variables de diferente tipo. De esta forma se evitará hacer conversiones en tiempo de ejecución.

• En cuestión de rendimiento es aconsejable no utilizar la sentencia BY NAME

• Asignación campo a campo

• Basar una variable del tipo char sobre cada una de las estructuras que se quieren asignar y hacer la asignación Char a Char.

• En muchos de los casos donde se utiliza la función Builting SUBSTR se podría hacer basando una estructura sobre la variable que queremos tratar.

P. ej : En lugar de : AUX_LITERAL = SUBSTR(CAMPO,3,5);

Declarar : DCL 1 AUX_EST BASED(ADDR(CAMPO)),

2 FILL1 CHAR(2),

2 VALOR CHAR(5);

Entonces : AUX_LITERAL = AUX_EST.VALOR

• En ningún caso se puede asignar una variable del tipo CHAR a una variable numérica, aun sabiendo, por su lógica. que esa variable del tipo CHAR tenga un valor numérico.

Comparaciones

• Las SELECT 's siempre tienen que tener codificado su Other.

• Evitar los IF's anidados. Usar siempre que se pueda la sentencia SELECT

P. ej : Evitar : IF VAR1 > 1

THEN IF VAR2 > 1

THEN CASO 1

ELSE CASO 2

ELSE CASO 3

Utilizar : SELECT

WHEN (VAR1 > 1 & VAR2 > 1) CASO 1

WHEN (VAR1 > 1 & VAR2 <= 1) CASO 2

OTHER CASO 3

END

Operaciones

• Excepto en casos excepcionales los módulos tienen que inicializar sus propias áreas de salida y no el programa que los invoca.

• Utilizar las funciones MULTIPLY y DIVIDE para realizar operaciones. Ello nos evitara problemas de precisión y “overflows”.

P ej : No usar : TOTAL = SUMA1 / SUMA2

TOTAL = SUMA1 * SUMA2

Utilizar : TOTAL = DIVIDE(SUMA1,SUMA2,15,2)

TOTAL = MULTIPLY(SUMA1,SUMA2,15,2)

General

• Deben evitarse aquellos procedimientos excesivamente largos. Si preveemos que un procedimiento excederá una cantidad razonable de líneas de cogido se debe estudiar su procedimentación.

• Los programas, así como los procedimientos que lo componen, han de estar correctamente comentados. Un buen comentario puede evitar horas de búsqueda de la lógica del programa.

• Los nombres de los procedimientos deben ser claros y explicitos con la funcion que realizan.

• Los procedimientos deben tener funciones claras y especificas. Un proceso de calculo no deberia contener sentencias de lectura, o un procedimiento de impresión de un listado no debe contener actualizaciones a bases de datos, por ejemplo.

• Es conveniente utilizar niveles de indentación claros. Una buena técnica para ello es aprovechar los DO y END de las sentencias.

P. ej : DO WHILE (¬EOF)

| IF ..................

| THEN

| DO;

| | SELECT();

| | | WHEN(1)

| | | DO;

| | | | SENTENCIA

| | | END;

| | | OTHER

| | | DO

| | | END

| | END;

| END;

| ELSE

| DO;

| END;

END;

• El programa debe estructurarse y codificarse siguiendo un orden lógico.

PROCESO PRINCIPAL

LLAMADA PROC 1

LLAMADA PROC 2

LLAMADA PROC 3

FIN PROCESO PRINCIPAL

PROCESOS FINALES

PROC 1 :

FIN PROC 1

PROC 2:

LLAMADA PROC 4

LLAMADA PROC 5

FIN PROC 2

PROC 3:

FIN PROC 3

PROC 4:

FIN PROC 4

PROC 5:

FIN PROC 5

PROCESOS FINALES

FIN PROCESOS FINALES

Otra forma también valida seria :

PROCESO PRINCIPAL

LLAMADA PROC A

LLAMADA PROC B

LLAMADA PROC C

FIN PROCESO PRINCIPAL

PROCESOS FINALES

PROC A:

FIN PROC A

PROC B:

LLAMADA PROC D

LLAMADA PROC E

FIN PROC B

PROC D

FIN PROC D

PROC E

FIN PROC E

PROC C

FIN PROC C

PROCESOS FINALES

FIN PROCESOS FINALES

DB2

• Deben evitarse al maximo los accesos a DB2, ya que es la operación que mas recursos emplea. Es conveniente, por ejemplo, al acceder a una fila recuperar toda la información de ella para evitar mas accesos.

• Los accesos a DB2 deben realizarse siempre usando el índice (ya sea primario o secundario).

• Es conveniente, tanto para realizar consultas como a la hora de actualizar filas, el usar la estructura de la tabla para cargar la información de la fila y/o asignar los campos a actualizar.

ON LINE

• Esta prohibido el acceso a base de datos en los módulos de entrada y salida.

• Incluimos en el punto anterior la MSDB.

• Es de suma importancia intentar optimizar los componentes, sobre todo accesos DB2. Esto se consigue procedimentando al máximo los accesos a DB2, evitando en lo posible ORDER BY y GROUP BY y accediendo siempre por los índices de la tabla.

• No utilizar nunca la sentencia SIGNAL ERROR.

• La sentencia GOTO únicamente es valida en una situación : En módulos de entrada y salida después de haber dado una respuesta a terminal, mediante inserción de pantalla.

• Para añadir / modificar / eliminar operaciones del mensaje circulante hay que utilizar la macro correspondiente (STOW021 / STOW022) , nunca manipular la matriz de operaciones directamente.

• En los módulos de salida no debe utilizarse el MID (DCI) direccionado en la estructura AREAFE, ya que si hay cambio de IMS entre módulos de aplicación la información contenida en este campo se pierde. En su lugar es conveniente hacer “viajar” el MID como un área de datos de entrada. (Direccionada en el modulo de entrada y salida con la macro STDW004).

BATCH

• La llamada al procedimiento de Checkpoint debe realizarse SIEMPRE después de una actualización y antes de una lectura.

• El área de control del Checkpoint ha de contener TODA la información necesaria para el re-arranque. Debe tenerse en cuenta que si accedemos a tablas DB2 mediante cursor la posición de dicho cursor se pierde tras el Checkpoint, por lo que será necesario cerrarlo, abrirlo y posicionarse en la ultima fila leída después de cada Checkpoint.

• Utilización de las variables de entorno para controlar cuando se han de realizar los CHKP's. (SISPCB0.CALCHKP_SIS = '1')

• Procedimentar las rutinas de reposicionamiento.

• Para realizar las pruebas de Checkpoint es necesario forzar el ABEND del programa. Para ello se utiliza la sentencia SIGNAL ERROR, debiéndose esta codificar en los siguientes lugares del programa :

• En una primera prueba debe codificarse justo después del procedimiento de toma de checkpoint, con la condición de 100 registros leídos, por ejemplo.

• En otra prueba debe codificarse antes del checkpoint.

• En ambos casos, una vez abendado el programa, se procederá a quitar la sentencia de error y re-arrancar la cadena con Checkpoint = LAST. En ambos casos los resultados, de fichero de salida o actualizaciones de BB.DD. han de ser los mismos.

• En accesos a DLI utilizar las macros de declaración de SSA y lectura.

JCL's

• Para poder probar BMP's el ultimo carácter del nombre del JOB ha de ser @. De esta manera, al re-arrancar el programa, se localizara el identificador de Checkpoint.

• Los ficheros temporales del JOB deben seguir la siguiente nomenclatura :

Siglas-aplicacion.Nombre-cadena.Paso.Datapase

AAA.AAAXnnn.Pnnn.&DATAP

• Dichos ficheros temporales han de desaparecer al finalizar el procedimiento o cadena.

• Las fichas de control de SORT's deben tener la siguiente nomenclatura :

Siglas-aplicacion+ 0 + numero de cadena+numero secuencial

Tomando como ejemplo la cadena CPID0321. La primera ficha de control será :

CPI00321, la segunda CPI00322, la tercera CPI00323, etc...

• Para ejecutar un programa BMP este debe tener su propia PSB. NO deben aprovecharse PSB's de otros programas aunque tengan idénticos punteros de PCB's.

• Detrás de cada paso deben estar los pasos de control de la ejecución (IBMABEND y IBMMENSA) donde se catalogaran los ficheros creados en el paso o se borraran aquellos ficheros temporales que no hayan de utilizarse mas.

//ABEND010 EXEC PGM=IBMABEND,COND=(0,EQ,P010)

//*-------------------------------------------------------------

//P015 EXEC PGM=IBMMENSA

//DD1 DD DSN=CPI.CPID0401.&DATAP,

// DISP=(OLD,CATLG),UNIT=(,,DEFER)

Análisis Orgánico

• Las transacciones On-Line deben, en la medida de los posible, estar tratando una única pantalla. Esto simplifica las operaciones y su tratamiento, reduciendo el riesgo de errores.

• Cada DOC o cuaderno de carga debe ir acompañado del correspondiente diagrama de flujo, en el caso de transacciones On-Line, o del diagrama de la cadena en el caso de programas BATCH.

• Se debe incluir en cada caso los casos críticos a probar, es decir, aquellas pruebas mínimas que deben realizarse para considerar la pieza de software elaborada como operativa.

• Información que debe encontrarse en el documento :

• On-Line : Módulos de aplicación con su correspondiente código de operación, áreas de entrada y salida (estas ultimas deben incluir el código de formato), pantallas y sus correspondientes estructuras (DCI y DCO), flujos de la transacción.

• Batch : Estructuras de los ficheros de entrada y salida, formato de los listados (si corresponde), frecuencia de toma de Checkpoint (si corresponde), estadísticas a mostrar.

Control de ejecución correcta del paso P010

Catalogación de ficheros