Estandares de Codificacion v 4.1

© 2011 - everis of 50

Proyecto: COM Estándar de Programación en MAINFRAME

Resumen

Guía para codificar programas COBOL

Registro de modificaciones Versión Descripción [o descripción de

cambios] Autor Fecha

creación Aprobado por

Fecha aprobación

1.0 Versión Inicial COM 28/06/2007 2.0 Anexo 4, consideraciones de

estándares del cliente TDP. everis 25/04/2011

3.0 Adecuación y aclaración de los puntos:

Everis 09/06/11

4.0 Adicionar nuevas recomendaciones. Everis 08/09/2011

© 2011 - everis of 50

Contenido

1. Objetivo .................................................................................................................................... 3

2. Cobol Estructurado ................................................................................................................. 4

2.1 Estructuras de control ......................................................................................................... 4

3. Normas de programación Cobol ............................................................................................ 5

3.1 IDENTIFICATION DIVISION............................................................................................... 5

3.2 ENVIRONMENT DIVISION................................................................................................. 5

3.3 DATA DIVISION .................................................................................................................. 5

3.4 WORKING-STORAGE SECTION ...................................................................................... 6

3.5 LINKAGE............................................................................................................................. 8

3.6 PROCEDURE DIVISION .................................................................................................... 8

4. Estándares de Programación con SQL ............................................................................... 15

4.1 Elementos componentes de una sentencia SQL ............................................................. 15

4.2 Recomendaciones en sentencias SQL ............................................................................. 15

4.3 Consideraciones de uso de SQL ...................................................................................... 15

4.4 Consideraciones de rendimiento ...................................................................................... 18

4.5 SQL en programas de aplicación ..................................................................................... 19

4.5.1 Delimitación de las sentencias SQL ....................................................................... 20

4.5.2 Declaración del área de comunicación ................................................................... 20

4.5.3 Variables HOST ...................................................................................................... 20

4.5.4 Tareas previas a la codificación .............................................................................. 21

4.5.5 Declaración del cursor ............................................................................................ 21

4.5.6 Condiciones excepcionales..................................................................................... 23

4.5.7 Ejemplo de actualización ........................................................................................ 23

4.5.8 Ejemplo de borrado ................................................................................................. 24

5. Anexos .................................................................................................................................... 25

5.1 Anexo 1 – Conversion de datos numéricos ...................................................................... 25

5.2 Anexo 2 – Comparación de Datos Numéricos.................................................................. 26

5.3 Anexo 3 – Efecto en Operaciones aritméticas.................................................................. 27

5.4 Anexo 4 – Estándar del cliente Movistar .......................................................................... 28

5.4.1 Glosario ................................................................................................................... 28

5.4.2 Consideraciones Generales .................................................................................... 28

5.4.3 QA de programas. ................................................................................................... 29

5.4.4 QA de copys. ........................................................................................................... 39

5.4.5 QA de CTLs. ........................................................................................................... 41

5.4.6 QA de procedimientos. ............................................................................................ 42

5.4.7 QA de JCL. .............................................................................................................. 43

5.4.8 QA de cadenas. ...................................................................................................... 48

5.4.9 QA de ficheros o Archivos....................................................................................... 50

COM Estándar de Programación COBOL

Archivo: Estándares de Codificación v 4.0_porrevisar1.doc

© 2011 - everis Página 3 de 50

1. Objetivo El presente documento tiene por objeto la normalización de la codificación de los distintos módulos manejados en un programa Cobol, sobre la base de las premisas fundamentales:

• Denominaciones unívocas.

• Dotadas de la mayor semántica posible.

• Programas sin complejidad de mantenimiento.

• Utilización de la forma más óptima las sentencias e instrucciones.

• Evitar el uso de palabras reservadas “opcionales” (USAGE IS, THEN, etc..).




2. Cobol Estructurado Existen muchas razones para usar programación estructurada. Las ventajas son numerosas y pueden tener una importancia diferente. La siguiente lista contiene algunas de las más comúnmente aceptadas:

Los nuevos programadores pueden llegar a ser productivos en un período de tiempo más corto debido a las especificaciones definidas.

La productividad de los programadores es mejorada tanto en la codificación como en la depuración y prueba de los programas.

El control del esfuerzo de programación queda simplificado.

Las técnicas de documentación proporcionan una ayuda a los analistas para prevenir errores de diseño.

La cantidad de tiempo requerida para revisar el diseño lógico disminuye.

El mantenimiento y mejora de los sistemas en producción queda simplificado.

Disminuye el consumo de máquina para la recompilación de programas.

2.1 Estructuras de control

La noción de programación estructurada es una filosofía de escritura de programas de acuerdo con un conjunto de reglas para reducir los problemas en las pruebas, incrementar la productividad y la lectura del programa resultante.

La primera técnica de la programación estructurada es la restricción del uso de la sentencia GO TO y su sustitución por un número de otras sentencias de control mejor estructuradas.

Las reglas de programación estructurada son relativamente simples y para COBOL se mostrarán a continuación.

Todo el procesado en los programas debe consistir en sentencias de código sencillas o de estructuras de control.




3. Normas de programación Cobol

3.1 IDENTIFICATION DIVISION

ID001 El nombre del programa (externo) será el mismo que el codificado en la cláusula “PROGRAM-ID”.

ID002 Poner con comentarios, antes de dicha identificación, con un * (asterisco) en columna 7, una descripción resumida de las funciones del programa, haciendo especial mención a la parte de procedure o lógica del programa. La cabecera y descripción del programa puede variar según el cliente.

ID003 Cada vez que se modifique un programa, añadir al final de los comentarios tantas fichas como sean necesarias para explicar la causa de la modificación, a continuación del literal, la fecha de la modificación en formato DD-MM-AAAA y el autor de dicha modificación. Solo si el componente se encuentre en producción. Esta regla variará según las indicaciones del cliente donde se aplica el desarrollo.

ID004 Completar siempre el apartado de AUTHOR.

3.2 ENVIRONMENT DIVISION

ED001 SPECIAL-NAMES. Se pondrá siempre la sentencia: DECIMAL-POINT IS COMMA.

ED002 SOURCE-COMPUTE. OBJECT-COMPUTER. No son obligatorias. Pero conviene ponerlas.

ED003 Las instrucciones SELECT llevarán sus cláusulas sangradas respecto a SELECT, de forma que aparezcan cuatro columnas a la derecha. Ejemplo: SELECT PSPOCPMI ASSIGN TO PSPOCPMI ORGANIZATION IS SEQUENTIAL ACCESS MODE IS SEQUENTIAL FILE STATUS IS FS-PSPOCPMI.

ED004 El nombre de los ficheros en la sentencia SELECT será el nombre de la DDNAME del fichero, este nombre seguirá las reglas de nomenclatura definidas en la instalación del cliente, en caso de que existan.

ED005 La descripción del registro se codificará en una copy en la cláusula DATA RECORD de la FD.

3.3 DATA DIVISION

DD001 FILE SECTION. Utilizar BLOCK 0 para todo tipo de ficheros, para dejar al JCL la gestión del bloque optimo según tipo de dispositivo.

DD002 No realizar SORT interno por razones de eficiencia.




DD003 Tomar las definiciones de ficheros y registros, a través de la sentencia COPY.

Hay ocasiones en que se utiliza, en un mismo programa, varias veces el mismo tipo de fichero (matchings, reformateos, etc..). Para esos casos es necesario que las COPYs tengan un primer nivel mayor al 01. En caso contrario sería necesario bajar el nivel 01 de la COPY (usando REPLACING).

DD004 Las descripciones de ficheros se deben escribir en el mismo orden que están en la SELECT.

3.4 WORKING-STORAGE SECTION

WS001 Todos los campos de la Working se agruparan bajo un nivel 01 INICIO-WORKING-STORAGE.

WS002 Se definirán las siguientes áreas a nivel 05 en función de su naturaleza (estos bloques guardarán el mismo orden en todos los programas) :CONTROL DE FICHEROS, CAMPOS WORKING PARA ERRORES, AREA DE SWITCHES, AREA DE CONTADORES, AREA DE CONSTANTES, AREA DE LITERALES, AREA AUXILIAR, AREA DE COPYS Los campos agrupados en ellos deberán comenzar con unos caracteres específicos que se utilizarán en todas las variables que pertenezcan a dicho bloque lógico. Los caracteres a usar serán los siguientes:

Registros de FD FD / RG

Auxiliares WS

Indicadores(switches) SW

Acumuladores AC

Contadores CN

Índices IN

Tablas TB

Constantes CT

File status FS

WS003 La subordinación de niveles, será : 01..05..10.. con escritura escalonada, de tal manera que comiencen en la misma columna. Se realizara un sangrado de 4 columnas a la derecha. Entre el número de nivel y el nombre del grupo o de variable se dejarán dos espacios de separación, de forma que aparezcan situados en columnas comunes números de nivel y nombres de datos. La subordinación de niveles deberá ser múltiplo de 5 y no mayores de 45. Excepción hecha de los niveles “88”.




WS004 Tablas. • Poner las tablas juntas al final de la Working. • Como norma general se utilizarán subíndices asociados a la tabla en lugar de

números enteros usados como subíndices. Una opción es utilizar INDEXED BY, pero si no se van a efectuar búsquedas en la tabla no es necesario.

• Se debe definir un nivel por encima del que contiene la cláusula OCCURS para poder referenciar la tabla como un todo.

Ejemplo: 05 TABLAS. 10 TABLA-ttt. 15 TB-EL-ttt OCCURS n INDEXED BY IN-ttt 20 TB-ttt-xxxx PIC X.

• Las cláusulas OCCURS e INDEXED BY se posicionarán en la columna 44 o en 36 de la línea siguiente.

WS005 Los nombres de los campos pertenecientes a un fichero deberán llevar un prefijo que los identifique con él.

WS006 Los campos idénticos de diferentes ficheros deberán tener el mismo nombre, distinguiéndose entre ellos por el prefijo del fichero al que pertenecen.

WS007 Los descriptores de los registros, se realizan en miembros independientes al programa, a los que se hará referencia mediante COPY (los grupos de campos deben estar alineados de forma que los que pertenezcan al mismo nivel comiencen en la misma columna).

WS008 Los registros correspondientes al mismo fichero se definirán uno a continuación de otro.

WS009 Las líneas de cabecera y detalle de los informes se incluirán como copys en los programas

WS010 El nombre del campo debe ser siempre significativo (prefijo excluido). Se deben evitar los nombres poco claros.

WS011 Los campos que no se utilicen en el programa deben nombrarse como FILLER.

WS012 Las constantes deben evitar los nombres idénticos al valor que contengan, nombrándolas según el significado de dicho valor. Se definirán tantas constantes como significados distintos tenga el valor correspondiente. Por ejemplo: Se evitarán: 10 CT-F PIC X VALUE ‘F’. Se sustituirá por: 10 CT-FIJO PIC X VALUE ‘F’ 10 CT-FINAL PIC X VALUE ‘F’

WS013 Literales. • Evitar el uso de literales en el Procedure División. Si se usan literales y su valor

cambia, cada instrucción del programa debería ser revisada para asegurar la corrección del nuevo literal. Dondequiera que se necesite una constante definir una variable en la Working Storage con el valor adecuado.

• Evitar que los literales ocupen más de una línea, codificar la cláusula VALUE en otra línea si se necesitan literales más largos.

• Evitar el uso de literales en comparaciones con operandos COMP-3. Los literales provocan que las operaciones aritméticas sean realizadas en un área de trabajo, requiriendo más espacio e instrucciones.

WS014 Se deben usar siempre las constantes figurativas en lugar de los literales correspondientes, tanto en VALUE´s como en MOVE´s. INCORRECTO � “ “ o 0 CORRECTO � SPACES o ZEROS

WS015 Niveles 77. La utilización de niveles 77 en WORKING están prohibidos.




Para seguir el orden de programación como se ha indicado en el punto WS002

WS016 Niveles 88. Se utilizarán siempre “nombres de condición” (nivel 88) para definir los posibles valores de indicadores, códigos identificativos o valores de campos que se usen para tomar alguna decisión en el programa. Siempre que el número de niveles 88 sea superior a cinco niveles como máximo, se incluirán en una copy de working.

WS017 Picture. La cláusula PIC debe comenzar en la columna 44.

WS018 Value. • Las variables que se inicialicen sólo una vez durante el programa, se deben definir

en la WORKING utilizando la cláusula VALUE, en vez de utilizar sentencias MOVE en la PROCEDURE DIVISIÓN. Esto es debido a que la cláusula VALUE requiere sólo un paso de compilación. En cambio, la sentencia MOVE, además del tiempo de compilación, utilizan tiempo de ejecución para cada programa que se esté ejecutando.

• La cláusula VALUE se pondrá en la columna 56 o en la 36 de la línea siguiente.

WS019 Para variables tipo contadores binarios deben declararse con signo, para evitar conversiones y con una longitud impar, para aprovechar el espacio.

3.5 LINKAGE

LS001 En la LINKAGE SECTION deben declararse los campos a nivel 01 en la misma secuencia en que se pasan los parámetros en la lista USING en la CALL del programa invocador y de la PROCEDURE DIVISIÓN del módulo llamado.

LS002 La COMMAREA siempre irá definida en una copy.

3.6 PROCEDURE DIVISION

PD001 Se codificará un único nombre de párrafo principal desde el cual se invocarán todos los demás.

PD002 Cada párrafo empezará con una serie de comentarios donde se definirá el nombre del mismo, y una sucinta descripción de las funciones que realiza.

PD003 Primero se debe codificar el núcleo principal. Al núcleo principal le seguirán los párrafos de inicio, proceso y fin, y, a continuación el resto de párrafos desde el nivel más general hasta el de mayor detalle en el orden en que se van llamando.

PD004 Todos los párrafos deben tener un nombre descriptivo y un número secuencial como prefijo. Este número debe estar ordenado en el programa, es decir, no debe ponerse nunca el párrafo 2300- antes del 2100-, por ejemplo.

PD005 Dejar una línea en blanco, entre los diferentes párrafos que componen el programa, para claridad en lectura.

PD006 Se incluirán las sentencias comunes dentro de un párrafo.

PD007 Ningún párrafo debe sobrepasar 60 líneas de código (excepto para sentencias DB2 en las que intervengan gran número de campos o MOVEs masivos entre estructuras), debiéndose fraccionar éstos mediante llamadas a otros párrafos.




PD008 Se evitará en lo posible que un párrafo llame a otro con un prefijo numérico menor que el

suyo. Para ello los párrafos comunes deben comenzar por un 9. No se tendrá en cuenta este punto, si se va a producir una acumulación excesiva de párrafos comunes al final del programa, lo que llevaría a una gran confusión en el seguimiento del mismo.

PD009 Se escribirá siempre una instrucción por línea.

PD010 Inicializar las áreas de datos justo antes de ser utilizadas, en lugar de al comienzo del programa. Evitar limpiar largas tablas si es posible. (Utilizar el indicador número de elementos).

PD011 Al inicializar varias variables con un mismo valor, el valor asignado aparecerá una sola vez.

PD012 Eliminar cualquier registro o ítem independiente en la Working-Storage, siempre que no esté referenciado en la Procedure División.

PD013 Quitar los DISPLAY innecesarios del programa, deben eliminarse antes de proporcionar el programa al entorno de Control de Calidad.

PD014 No utilizar copys de procedure.

PD015 Acabar los programas BATCH con GOBACK.

PD016 Evitar acabar las sentencias con punto, ya que mejora el rendimiento de la compilación. Incluir un único punto al final de cada párrafo.

PD017 Utilizar la sentencia INITIALIZE para inicializar los campos de working, en especial los de nivel 01. Es necesario utilizarla cuando se inicializan campos de grupo y, en especial, si alguno de los campos de nivel inferior es numérico.

PD018 No se utilizará /EJECT para realizar saltos de página en el fuente del programa. La sentencia /EJECT, es solo para documentación.

PD019 Sentencia EVALUATE. • Utilizar la sentencia EVALUATE siempre que el sustituirla por IF anidados aumente

de forma considerable la complejidad del programa (cuando haya más de cinco niveles de anidamiento de IF sobre la misma variable). Debe terminarse en END-EVALUATE. Evitar las opciones EVALUATE WHEN TRUE, EVALUATE WHEN FALSE ya que en estos casos es más fácil el uso de IF.

• La cláusula WHEN se sangrará 4 posiciones sobre la sentencia EVALUATE, y las sentencias a cada WHEN se sangrarán 4 posiciones sobre éste.

• Siempre existirá la opción WHEN OTHER. • Hay que procurar colocar las opciones más probables en los WHENs más altos.

PD020 No utilizar la sentencia GO TO.

PD021 Se debe evitar siempre el uso de la instrucción CONTINUE.

PD022 No utilizar PERFORM … THRU … No utilizar PERFORM … VARYING … No utilizar PERFORM … TIMES …

PD023 Las sentencias INSPECT, STRING, UNSTRING, son sentencias bastante costosas, por lo que se recomienda utilizarlas sólo cuando sean necesarias. En el caso del STRING, considerar si se puede utilizar la instrucción MOVE VAR1(Posición:Desplazamiento) TO ...”, en cualquiera de sus modalidades.

PD024 En las sentencias STRING y UNSTRING, definir el carácter delimitador en Working o utilizar BY SIZE.




PD025 Sentencia ACCEPT. Si se accede a variables del sistema como DATE, DAY, TIME, CURRENT-DATE o TIME-OF-DAY, obtener el valor de la variable una sola vez en la rutina de inicialización, y ponerlo en un campo de la WORKING-STORAGE para posteriormente ser referenciado.

PD026 IF NUMERIC e IF ALPHABETIC, son muy costosos, por lo que debe restringirse su uso. PD027 Sentencia IF.

• Terminar los IF, con su correspondiente END-IF, de este modo se consigue que el programa quede perfectamente estructurado y se facilita la comprensión y el mantenimiento del mismo.

• Indentación de sentencias IF con 4 espacios, separando con una línea la sentencia ELSE y END-IF.

• Las sentencias condicionales complicadas o las sentencias IF anidadas deben tratar de desdoblarse en sentencias simples.

• En el caso de IF anidados, ponerlos en orden más probable, al menos probable. • Deben evitarse las condiciones NOT, especialmente si van combinadas con OR,

dado que tienden a complicar la lógica del programa. Por ejemplo: El siguiente código: If A Not Equal B Perform…. End-if. Debería ser codificado: If A Equal B Continue Else Perform.... End-if.

• Se procurará no utilizar conjuntamente condiciones AND y OR, ya que conducen a malentendidos.

• Se debe utilizar el nombre de la condición siempre que esté asociada a un nivel 88 para facilitar la comprensión del programa.

• En las sentencias condicionales conectadas por la cláusula AND debe chequearse primero la condición más restrictiva, mientras que, en las sentencias conectadas por la cláusula OR debe chequearse primero la condición más probable.

• Las condiciones aritméticas deben ejecutarse fuera de la condición de las sentencias condicionales, pues las operaciones aritméticas dentro de una condición se ejecutan con la precisión máxima de 6 dígitos.

• No utilizar la frase NEXT SENTENCE, cuando se utiliza dentro de un IF, y llega a ejecutarse, la siguiente instrucción que se ejecuta NO es la siguiente al END-IF correspondiente, sino la siguiente instrucción en secuencia detrás del punto siguiente más próximo.

• No es recomendable la utilización de IF anidados cuando las condiciones se han de verificar sobre distintas variables. En caso de ser imprescindible la utilización IF anidados sobre distintas variables, se deberán utilizar sentencias PERFORM, de forma que no se utilicen más de 3 niveles de anidamientos de los IF.

• Son preferibles estas sentencias IF WS-A <= SPACES, IF WS-A <= ZEROES a las siguientes: IF WS-A = SPACES, IF WS-A = ZEROES. Al contemplar, las primeras, los LOW-VALUEs o variables no inicializadas.




PD028 Tratamiento de Ficheros. • Utilizar una sola sentencia OPEN en lugar de varios, así como una cláusula de

cada tipo INPUT, OUTPUT o IO, al abrir los ficheros al mismo tiempo. Los nombres de los ficheros deben situarse en una misma columna.

• Debe preverse que un fichero de entrada este vacío. • Se utilizará una sola sentencia CLOSE de ficheros en el programa. Los nombres

de los ficheros deben situarse en una misma columna. • Cada operación distinta de entrada/salida (READ, WRITE, REWRITE, DELETE,

CURSORES) se codificarán siempre que sea posible, una sola vez en el programa, llamándolas con PERFORM cada vez que se utilicen.

• En sentencias de lectura (READ) y escritura (WRITE) de ficheros, se deben codificar llamando a variables definidas en WORKING, y no trabajar con los registros de la FD (esto implica el empleo de la cláusula READ-INTO y la cláusula WRITE-FROM).

• La sentencia READ debe terminar en END-READ. • Control de FILE-STATUS, para todas las operaciones. No debe utilizarse el control

INVALID KEY. Este control se puede “centralizar” en párrafos únicos donde, aparte, se acumulen contadores de lectura escritura.

• Si se generan varios informes por un único programa, es conveniente utilizar ficheros de impresión. Esto permite que los informes sean generados simultáneamente. Se ha de tener en cuenta que los formatos especiales serán alineados en la impresora como la primera línea de cada formato, no como la primera línea de impresión.

PD029 Índices.

• Los campos con índices que se referencien frecuentemente deben moverse a un área de trabajo para efectuar cálculos, devolviendo el resultado al campo original.

• Se deben emplear campos del tipo S9(4) COMP como índices para mejorar el rendimiento.

PD030 Informes.

• Cuando no existan datos en un informe, se imprimirá éste con su cabecera y la leyenda “NO EXISTEN DATOS PARA ESTE INFORME”.

• En PROCEDURE el WRITE, no lleva AFTER ADVANCING .. ni BEFORE ADVANCING...

PD031 Rutinas.

• Llamada a las rutinas de forma DINAMICA, para evitar volver a linkeditar el programa en caso de que se modifique la rutina: Llamada a la rutina sin comillas, definiendo una variable en working inicializada al nombre de la rutina. Realizar:

“CALL CT-NOMBREMODULO USING W-PARAMETROS”, siendo CT-NOMBREMODULO la variable definida en working. Se recomienda que los parámetros de llamadas estén definidos en un COPY. No se deben utilizar comas para separar parámetros.

• Una rutina nunca debe cancelar, hacer COMMITs o ROLLBACKs, debe devolver al programa invocante el error correspondiente.

• Se deberán inicializar los parámetros de llamada al comienzo del programa, ya que sino puede causar problemas si hay múltiples llamadas al subprograma. Esto es debido a que una copia del programa, incluyendo su Working Storage, es retenida en memoria. Se recomienda usar la sentencia CANCEL inmediatamente después de la sentencias CALL, con lo que el subprograma es siempre devuelto a su estado inicial.

• Debido a que las sentencias CALL podrían ser tratadas como las READ, usar siempre la sentencia ON EXCEPTION con los tratamientos de errores apropiados para cada sentencia CALL. Esta técnica no sólo formatea el mensaje de error sino que también lleva el Job actual a su estado final.




PD032 Tablas. • Usar SEARCH si la tabla tiene 99 elementos o menos. • Usar SEARCH ALL, si la tabla está clasificada y contiene más de 99 elementos. • Para cualquier tamaño de tabla poner los datos más frecuentes en los primeros

elementos de la tabla, si es posible. • Si un dato de una tabla es procesado muchas veces (esto es, varias referencias al

mismo dato en el mismo camino lógico o bucle), moverlo a un dato fijo declarado al principio de la WORKING-STORAGE, y tomar este mismo campo como referencia.

• En la sentencia SEARCH, debe controlarse la cláusula AT END, y debe terminar en END-SEARCH.

• Programar la búsqueda lógica de la tabla de manera que se pare en el último dato de la tabla, en lugar de en la última fila definida (muchas de las tablas sólo tiene contenido en los primeros elementos).

• Técnicas de búsqueda: No usar DEPENDING ON.

1. Usar búsqueda secuencial con índices literales para tablas de hasta 15 registros.

2. Utilizar búsqueda binaria para grandes tablas. La búsqueda binaria puede reducir drásticamente la cantidad de tiempo necesitado para realizarla. SEARCH ALL genera una búsqueda binaria si la tabla está ordenada (ascendente o descendentemente) y es unidimensional.

3. No usar nunca búsquedas secuenciales con índice variable. 4. Para realizar búsquedas binarias en una tabla parcialmente cargada, cargar el

resto de la tabla con HIGH-VALUE o LOW-VALUE, dependiendo de si la clave está en orden ascendente o descendente. Considerar que para vectores que contienen campos claves tipo binarios, se debe de completar con su valor más alto, ya que la constante HIGH-VALUE, cuando se almacena en dicho tipo de dato no tiene el valor esperado.

Por ejemplo, una tabla con 10,000 elementos requiere una media de 5,000 comparaciones por búsqueda con búsqueda secuencial, mientras que una búsqueda binaria requiere un máximo de 14 comparaciones. Manipular tablas con índice en lugar de subscripts siempre que sea posible.

• En las lecturas de datos para construir tablas internas: 1. Al informar la tabla hay que controlar que no se supere el máximo número de

elementos definidos en el OCCURS. Este dato se puede incluir en la definición de la propia tabla (a nivel 15).

2. Si se trata de una tabla interna de un módulo BATCH y (por cuestiones de rendimiento) es necesario conservarla entre llamadas hay que procurar no inicializarla al principio del programa.

PD033 Bucles.

• Reducir o minimizar el número de ejecuciones del bucle. • Mover todos los cálculos que sean posibles fuera del bucle.




PD034 Operaciones de Cálculo. • Para campos subscritos y en operaciones de cálculo, la mejor definición es S9(XX)

COMP, donde la longitud – XX – debe ser menor de 5 dígitos, si es posible, y evitar más de 9.

• Si no se utiliza COMP, utilizar COMP-3, en el formato S9(XX) COMP-3, creando los campos de 15 dígitos como máximo.

El número de dígitos (en usages COMP-3) debe ser impar con objeto de optimizar el espacio utilizado.

• Especificar el mismo USAGE para campos numéricos interrelacionados. • Para campos de ADD y SUBTRACT, especificar el mismo número de posiciones

decimales. • Ejecutar operaciones aritméticas con COMPUTE, exceptuando los contadores,

índices, que se realizarán con ADD (es decir no utilizar COMPUTE con operaciones simples). Se deberá utilizar con expresiones complicadas porque generalmente es más eficiente debido a que el compilador guarda áreas de trabajo internas y no tiene que almacenar los resultados de los cálculos intermedios. Es responsabilidad del programador asegurar que los datos han sido definidos con el adecuado número de dígitos significativos. Utilizar siempre a menos que se necesite el resto de una división.

• Para optimizar las operaciones aritméticas: si los datos no están en el formato ideal, es preferible moverlos antes a un campo de WORKING con el formato ideal, antes de realizar las operaciones.

• No utilizar la cláusula ON SIZE ERROR. • Utilizar la cláusula ROUNDED, lo menos posible. • Es preferible redefinir un campo en vez de multiplicar o dividir por 10 o potencia de

10. • Asegurarse, antes de ejecutar la instrucción DIVIDE, que el divisor sea distinto de

cero. • Es preciso tener especial precaución para evitar la pérdida de la precisión

necesaria dentro de las divisiones en las cláusulas COMPUTE. La precisión máxima se obtiene estructurando la expresión aritmética para forzar:

1. Multiplicaciones por número mayores que 1, y 2. Divisiones por número menores que 1 que ocurran antes que 3. Multiplicaciones por números menores que 1, y 4. Divisiones por números mayores que 1.

PD035 Se debe evitar el uso de MOVE CORRESPONDING al ocultar tratamientos individuales de

campos.

PD036 Se debe evitar el uso de WS-A(99:99) para cortar variables. Es mejor la utilización de REDEFINES.

PD037 Definir una COPY para informar y mostrar los diferentes tipos de errores. Esto permite detectar fácilmente la sentencia que ha producido el error.

PD038 No debe existir “código muerto”.

PD039 Eliminar todas las instrucciones usadas para depuración (EXHIBIT, DISPLAY, Instrucciones TRACE, RESET TRACE, etc) cuando el programa esté preparado para entrar en producción. La compilación de estas instrucciones genera una cantidad significativa de código (y tiempo de ejecución) que no será necesitado después de la fase de pruebas.




PD040 El uso de sentencias Perform dentro de la misma línea es mucho más eficiente y debería ser usado siempre que fuera posible. Ejemplo: Escribir esto Perform Until WS-FLAG = ‘Y’ Código a ser ejecutado End-Perform En vez de: Perform 3000-Find-Name Thru 3000-Exit Until WS-FLAG = ‘Y’ 3000-Find-Name. Código a ser ejecutado.

PD041 Cuando se realizan modificaciones en el código del programa se deberá marcar el comienzo y el fin del código modificado. Además, no se deberá eliminar líneas de código, sino que se comentarán las líneas no necesarias y se añadirá la modificación. Ejemplo: Move X to Y Se deberá reemplazar el move, ya que en lugar de X a Y, será de B a C. V00001* Move X to Y V00001Move B to C Nunca se debería hacer lo siguiente: V00001* Move B to C La documentación de los cambios depende del cliente, ya que puede tener un estándar para dicho proceso.




4. Estándares de Programación con SQL Este apartado tiene como finalidad reflejar la normativa básica de codificación y consideraciones de rendimientos SQL.

También recoge una serie de recomendaciones sobre el uso de SQL en programas de aplicación, así como unas normas de programación, que de algún modo proporcionan un uso eficiente del lenguaje.

4.1 Elementos componentes de una sentencia SQL

Palabras predefinidas: SELECT, INSERT, UPDATE...

Signos delimitadores. También llamados signos especiales. Se utilizarán para delimitar o separar las constantes dentro de una sentencia. Entre algunos de ellos se encuentran:

• El blanco ( ), se utilizará para separar las distintas palabras.

• Las comillas ( " ), se utilizarán para delimitar constantes alfanuméricas.

• Los operadores aritméticos ( +, -, *, / ), para formar expresiones con constantes, valores de columnas y funciones de valores de columnas.

• Los de comparación ( >, <, = ), se utilizarán en operaciones de comparación entre dos valores.

• La negación ( NOT).

• Los paréntesis ( ( ) ), se utilizarán para delimitar expresiones

4.2 Recomendaciones en sentencias SQL

En la codificación de una sentencia SQL:

• Se escribirán en Mayúsculas todas las palabras predefinidas para SQL y constantes (de carácter alfabético).

Las sentencias con más de una cláusula o palabra predefinida, deberán indentarse adecuadamente y colocar cada una de las palabras predefinidas en líneas diferentes para mejorar la claridad y legibilidad de las sentencias.

Por ejemplo:

UPDATE [ USER.] { TABLA | VISTA } [ ALIAS ]

SET COLUM=EXP, [ .... ]

[WHERE COND]

4.3 Consideraciones de uso de SQL 1. Actualización sin lectura previa.

Cuando se precise cambiar un dato, con independencia de su contenido, se deberá realizar su actualización directamente, sin lectura previa.

2. Actualización con lectura previa.

Habrá casos en que es preciso leer antes de actualizar una fila. En este caso, se debe utilizar la técnica siguiente si es posible:




DECLARE CURSOR

OPEN CURSOR

FETCH

UPDATE WHERE CURRENT OF

CLOSE CURSOR

Se deberá emplear esta técnica en lugar de SELECT y UPDATE sin cursor, ya que esto no garantiza la integridad. Cuando se hace SELECT, la fila recuperada no se bloquea y puede ser accedida por otros usuarios que la pueden modificar en el tiempo que va desde realizar el SELECT hasta el UPDATE. Por contra, una fila recuperada con FETCH, es bloqueada hasta el siguiente FETCH ó UPDATE WHERE CURRENT OF, y no puede ser modificada mientras tanto por otros programas. Así, es más seguro la actualización con cursor cuando es preciso leer previamente. Esta cláusula no puede utilizarse para la actualización de una columna perteneciente a la clave primaria.

El cursor debe definirse de tal forma que sólo seleccione los registros que se desean modificar y debe cerrarse en el momento en que ya no se necesite para evitar mantener bloqueos innecesarios.

3. Aprovechar la potencia de SQL.

Es más eficiente realizar una función con SQL que realizarla por aplicación. Se recomienda por tanto emplear inicialmente la potencia del lenguaje, no sólo desde la perspectiva de la productividad de desarrollo, sino también desde la eficiencia.

Por ejemplo:

SUM(<columna>)

AVG(<columna>)

MAX(<columna>)

4. Seleccionar con SQL.

Se recomienda filtrar las filas con SQL, utilizando los predicados de selección posibles (operadores relacionales, lógicos, sobre carácter, etc...). De este modo, no sólo la aplicación es más eficiente sino más fácil de construir y mantener.

5. Consideraciones en selecciones.

Sólo se deben recuperar las columnas que se precisen, pues es más económico que recuperar todas. Si se precisa conocer exclusivamente la existencia de una fila, se debe seleccionar exclusivamente por la clave primaria.

No utilizar SELECT *, para evitar que el programa de aplicación esté condicionado a la estructura física de las tablas y que se recuperen columnas innecesarias.

No se debe utilizar sentencias SELECT COUNT(*) si sólo se pretende verificar la existencia o no de filas.

6. Consideraciones en inserciones.

La sentencia SQL INSERT debe codificarse completa, es decir, debe especificar uno a uno los atributos a insertar así como las variables de las que toman el valor. Las variables deben estar en el mismo orden en que se han especificado los atributos. Esto no significa que se especifiquen todas las columnas de una tabla, sino aquellas que se necesiten, ya que el resto tomarán los valores por defecto.

7. Consideraciones en actualizaciones.




• No se pueden actualizar columnas pertenecientes al índice mediante una sentencia UPDATE, debe realizarse mediante DELETE e INSERT.

• Si es necesario conocer previamente el valor de la fila a modificar y/o borrar, utilizar actualizaciones con lectura previa mencionada anteriormente. (Cursores)

• Si no es necesario conocer el valor anterior, realizar una sentencia simple (DELETE/UPDATE).

• Cuando se actualicen o eliminen muchas filas en el mismo programa, liberar recursos regularmente mediante COMMIT.

8. Operaciones de comparación.

Con frecuencia la ejecución de una sentencia SQL implica la realización de una comparación entre dos valores. La comparación de dos valores se realiza de acuerdo con las siguientes reglas:

• Se debe evitar la comparación entre valores de distinto tipo, es decir, deben ser bien ambos numéricos, o bien ambos alfanuméricos.

• No se podrán comparar constantes o atributos numéricos con alfanuméricos, o viceversa.

• Todos los datos de tipo numérico podrán ser comparados los unos con los otros (por ejemplo, un decimal con un entero). Lo mismo ocurrirá con los alfanuméricos (por ejemplo, uno de longitud fija con otro de longitud variable).

• En comparaciones entre dos fechas se tendrá en cuenta el formato en el que se encuentran ambas fechas. Se podrán comparar dos campos de tipo fecha o uno de tipo fecha con otro de tipo alfanumérico.

9. Utilización de Vistas.

Podrán utilizarse para proporcionar un mecanismo que limite el acceso a los datos en las tablas. Proporcionan un camino alternativo en el bloqueo de los datos en una o más tablas.

Las vistas también podrán utilizarse para consultas en las cuales debido al criterio de selección, dichas consultas proporcionen un número elevado de filas, es decir, simplificar la formulación de consultas complejas o repetitivas.

10. Utilización de Índices.

Los índices proporcionan una ruta de acceso más rápido a los datos en la base de datos usando punteros. Los índices a definir en la base de datos deberán ser elegidos basándose en el tipo de consulta que se quiera realizar.

En general, las reglas a seguir para el mejor rendimiento en la definición de los índices son las siguientes:

• Las columnas que con más frecuencia sean utilizadas en la cláusula WHERE y usadas en un orden particular deberían ser elegidas como índices.

• Las columnas que sean utilizadas en ORDER BY y GROUP BY deberían ser elegidas como índices.

• Las columnas que son accedidas secuencialmente o por rangos en la cláusula WHERE deberían ser índices.

• Los índices definidos para múltiples columnas serán sólo utilizados si la primera columna en el índice es especificada en la cláusula WHERE.

11. Otras consideraciones.




• No se prefijará la tabla con el usuario propietario de la misma ya que la conexión se realizará con el mismo usuario.

• Los índices serán actualizados por cada ejecución de un INSERT, UPDATE o DELETE.

• Evitar la utilización de NOTs. Siempre que sea posible utilizar las condiciones en afirmativo.

• ORDER BYs deberán ser ejecutados sobre columnas indexadas únicamente.

• Evitar sentencia LIKE. Utilizar >= siempre que sea posible.

• No se permite el uso de Substrings aplicados a columnas de una tabla en sentencias SQL por cuestiones de rendimiento.

• No utilizar MAX y MIN en la misma sentencia SQL. Realizarlo en dos sentencias separadas. Asegurarse de utilizar un índice.

• No se deben utilizar JOIN de tablas. En caso de necesidad, utilizarlos, siempre y cuando, cumplan las condiciones reflejadas a continuación:

� Los JOIN´s permitidos serán aquellos referidos a funciones de validación y a servicios de lectura de descripción.

� JOIN por columnas indexadas únicamente (salvo que los tamaños de las tablas sean pequeños, con lo cual se podría hacer por columnas no indexadas).

� No especificar más de 3 tablas en un JOIN.

� Evitar hacer JOIN de una tabla sobre sí misma.

� Las columnas utilizadas en un JOIN deben ser del mismo tipo de dato y de la misma longitud.

� En JOIN´s especificar el nombre completo de la tabla antes de cada referencia a las columnas y no utilizar los alias de las tablas.

4.4 Consideraciones de rendimiento 1. Selecciones

Los argumentos de búsqueda en la cláusula WHERE dentro de las sentencias SELECT, DELETE y UPDATE pueden ser variables locales o funciones. El hecho de que se evalúen funciones con las columnas de la tabla como argumentos, tiene como consecuencia la utilización deficiente del índice que pudiera haber sobre esa columna o incluso la no utilización del mismo. De esta manera si tenemos un argumento WHERE debe ser definido de forma que la columna de la tabla aparezca sin ser afectada por ninguna función, esto es:

WHERE COLUMNA = :POR_CIENTO / 100

también hay una forma más eficiente que la anterior, en la que se han eliminado por completo las apariciones de funciones con columnas y/o variables, esto es posible por medio del uso de variables auxiliares:

DECLARE :POR_UNO DOUBLE (cursor)

SELECT :POR_UNO = :POR_CIENTO / 100.0

WHERE COLUMNA = :POR_UNO




• Se recomienda evitar las cláusulas OR en las consultas, sin embargo en algunas ocasiones es inevitable el uso de la misma por lo que es conveniente conocer el tratamiento que el SGBD hace de este tipo de condiciones.

El tratamiento es exactamente igual para las condiciones IN y OR, por lo que se recomienda el uso de la segunda por mayor claridad:

WHERE COLUMNA IN ("A","B")

Cuando sea posible, se deberá utilizar en su lugar la función BETWEEN para cálculo de intervalos, dado que esta no tiene necesidad de utilizar la estrategia OR y evalúa una consulta con el procedimiento estándar, con lo que habitualmente la mejora será substancial, siguiendo con el ejemplo anterior, la cláusula quedaría:

WHERE COLUMNA BETWEEN "A" AND "B"

• Las condiciones de tipo negativas o de negación de atributos tienen habitualmente como consecuencia la no utilización de los índices dado que hay que rastrear la tabla por completo, así se recomienda evitar operadores como <>,!=,NOT IN, etc., usar en su lugar, y en la medida de lo posible operadores IN o BETWEEN con el conjunto complementario.

• Cuando un conjunto de datos aparece en repetidas ocasiones en varias sentencias SQL, es útil y muy eficiente utilizar tablas temporales que contengan el citado conjunto de datos. El resultado es que la consulta se efectuará una única vez. Esta ventaja será aumentada si la tabla temporal se indexa de acuerdo con condicionantes de rendimiento y, especialmente, si todo esto se encierra en el interior de un proceso BATCH.

Es importante resaltar que esta técnica no resulta práctica si las filas involucradas en la consulta son muy pocas.

Se recomienda, en las sentencias INSERT o SELECT, especificar de forma explícita las columnas involucradas, con objeto de que continúen operativas en el caso de que las tablas involucradas sufran modificaciones en su estructura tales como añadir o suprimir columnas. En el caso de UPDATE, habrá que asignar valores por defecto a las nuevas columnas, o permitir valores nulos.

4.5 SQL en programas de aplicación

Al codificar SQL en un programa hay que desarrollar varias actividades:

• Delimitar las sentencias SQL.

• Declarar un área de comunicación con DB2.

• Declarar las tablas que se usen.

• Declarar las unidades de datos usados para pasar datos entre DB2 y COBOL.

• Codificar sentencias SQL para recuperar datos DB2 de una fila cada vez:

- Se puede usar SELECT si se está seguro de que sólo va a ser una la fila que será accedida.

- En caso contrario, es decir, no se sabe cuántas filas se van a recuperar, se deberá usar la sentencia DECLARE CURSOR y después usar una sentencia FETCH para poner los datos de una fila en las unidades de datos del programa.

• Codificar las sentencias SQL para actualizar, insertar y borrar datos en DB2.




• Manejar condiciones excepcionales, indicadas con códigos de retorno de DB2.

4.5.1 Delimitación de las sentencias SQL

Se usará “EXEC SQL” y “END-EXEC” para delimitar una sentencia SQL en un programa COBOL. En un programa se codificaría: EXEC SQL Sentencia SQL END-EXEC. Estas palabras indican al precompilador cuando empieza una sentencia y cuando acaba. Opcionalmente se puede codificar con un punto al final de la sentencia, pero si ésta va insertada dentro de una condición ‘IF’ deberá ser codificado sin punto. Las sentencias SQL deberán codificarse a partir de la columna 12.

4.5.2 Declaración del área de comunicación

Esta área también se conoce como SQLCA, debiendo ser incluida en el programa. Existen dos formas de definir el SQLCA dentro del programa de aplicación: declarando una estructura con el nombre y los campos adecuados o bien, se puede indicar al precompilador que ya existía codificado en la WORKING-STORAGE SECTION lo siguiente:

EXEC SQL

INCLUDE SQLCA

END-EXEC.

Uno de los parámetros más usuales de la SQLCA es el denominado SQLCODE. Es un conjunto de datos que almacenan un código de retorno de DB2 cada vez que se ejecuta una sentencia SQL. El programa puede examinar el SQLCODE como si fuera cualquier otra variable numérica COBOL.

4.5.3 Variables HOST

Una Variable Host es una variable definida en el programa fuente y que participa en alguna sentencia SQL del mismo. Estas variables pueden utilizarse para recibir datos resultantes de la ejecución de la sentencia, utilizar el contenido de las variables para insertar o actualizar datos en tablas, o usar su contenido para resolver las cláusulas WHERE o HAVING de la sentencia.

La variable Host debe declararse en el programa físicamente antes de su uso en cualquier sentencia SQL. El valor de la variable puede usarse para representar valores de datos, en ningún caso nombre de objetos DB2 (columnas, vistas, tablas).

Se recomienda que las Variables Host deben ir precedidas de dos puntos (:) cuando se utilicen dentro de la sentencia SQL (y sólo en este caso), con el fin de indicar que no se trata de un nombre de columna.

Los datos recuperados por el DB2 son almacenados en las variables HOST para usarlos en el programa. A su vez los datos que van a ser insertados o modificados también están referenciados en las variables.

Para recuperar datos a través de un programa se codificará la siguiente sentencia:

EXEC SQL

SELECT columna-1, columna-2, ...

INTO :variable-host-1, :variable-host-2, ...




FROM nombre-tabla

WHERE condición

WITH UR

END-EXEC.

Es necesario tener en cuenta dos cosas:

• La cláusula WHERE usa una variable HOST que debe ser compatible con el tipo de dato que contiene la columna implicada en la comparación.

• La cláusula INTO nombra las variables HOST del programa, usadas para recuperar los valores de las columnas seleccionadas por la sentencia SELECT.

4.5.4 Tareas previas a la codificación

Se deben generar unos miembros con la descripción de los campos de la tabla de la forma:

MIEMBRO TABLA0

01 TABLA0.

05 TB01-FLD1 PIC X(4).

05 TB01-FLD2 PIC S9(6).

05 TB01-FLD3 PIC S9(8).

Dentro del programa se deben incluir estas declaraciones previamente a la utilización de la tabla como sigue:

EXEC SQL

INCLUDE TABLA0

END-EXEC.

4.5.5 Declaración del cursor

Siempre que se ejecute una sentencia SELECT, ésta recuperará todas las filas que cumplan la condición especificada en la cláusula WHERE.

Sin embargo, habrá ocasiones en las que para una condición determinada se deseen recuperar esas filas una por una. La solución es la creación de un CURSOR o puntero en nuestro programa COBOL.

Cada cursor tiene validez dentro del programa en el que es definido. Esto significa que todas las sentencias que se refieran a un mismo cursor deben pertenecer al código generado en un mismo proceso de precompilación.

La sentencia DECLARE CURSOR es la que define el nombre lógico del cursor dentro del programa, el criterio de selección de filas y el tipo de proceso que se va a realizar sobre las filas leídas. Sólo hay que escribirla una vez dentro del programa.

Cuando se declare un cursor se debe utilizar la opción OPTIMIZE (para 50 filas) con el objeto de mejorar el rendimiento de la sentencia.

Un ejemplo de esta sentencia es el siguiente:




EXEC SQL DECLARE nombre-cursor CURSOR FOR SELECT columna1, columna2,.... FROM nombre-tabla WHERE condición WITH UR END-EXEC

No utilizar cursores con la opción FOR UPDATE OF a menos que realmente se vaya a hacer actualización de la tabla, y en ese caso incluir en la relación de columnas solamente aquellas que se vayan a actualizar.(Afecta considerablemente al rendimiento).

No utilizar en los cursores la sentencia FOR FETCH ONLY.

� Apertura del CURSOR mediante

EXEC SQL

OPEN nombre-cursor

END-EXEC.

Esta sentencia inicia el proceso de selección de filas que implica el cursor, en un área de trabajo del DB2.

� Las filas que cumplen las condiciones impuestas en la definición del cursor van a ser recuperadas una a una mediante la sentencia FETCH y almacenadas en Variables Host:

EXEC SQL

FETCH nombre-cursor

INTO :variable-host1, :variable-host2,....

END-EXEC.

Esta sentencia leerá la fila donde se encuentra posicionado el cursor, posicionándose después en la siguiente fila. Si después de leer la última fila, se detectará el fin de datos (SQLCODE=+100), lo sabríamos al realizar el siguiente FETCH sobre la tabla.

� Cierre del cursor mediante

EXEC SQL

CLOSE nombre-cursor

END-EXEC.

Esta sentencia cerrará el cursor creado y abierto anteriormente, como si se tratara de un fichero.

Es necesario tener en cuenta que desde el momento en que se abre el cursor, las variables HOST que estén inmersas en la cláusula WHERE tomarán el valor que tengan en ese instante. Esto es, si necesitamos recuperar más filas para la misma condición expresada en la cláusula DECLARE CURSOR, pero con valores de variables HOST diferentes debemos realizar la siguiente operación:

1. Cerraremos el cursor con la sentencia CLOSE.

2. Refrescaremos o actualizaremos las variables que deseemos modificar.




3. Volveremos a abrir el cursor, con lo cual el subfichero o la porción de la tabla que recuperaremos será distinta de la anterior, es decir, obtendremos OTRA TABLA RESULTADO.

4. A continuación ya estaremos en condiciones de volver a repetir el proceso de lectura, hasta que se acabe el cursor o nuestro programa decida acabar el proceso.

5. Por último cerraremos el cursor, o repetiremos este último proceso de refresco de variables.

4.5.6 Condiciones excepcionales

Una vez que la tabla haya sido leída en su totalidad, el programa encontrará el final de ésta, por lo que deberá hacer algo distinto. De igual manera, cuando un dato no se ha encontrado o se produzca algún error en la ejecución de una sentencia SQL, deberá ser detectado por el programa y desviar la ejecución en otro sentido.

Para detectar estos tres casos se deberá examinar el SQLCODE después de cada sentencia SQL.

Los códigos de retorno que devuelve el DB2 pueden ser principalmente los siguientes:

SQLCODE = 0 y

SQLWARN = SPACES

Cuando no se ha producido error

SQLCODE < 0 y

SQLWARN NOT = SPACES

Cuando se ha producido algún error

SQLCODE =100 y

SQLWARN NOT = SPACES

Cuando se ha encontrado final de tabla o no se ha encontrado el elemento buscado

Por tanto con esta información podremos chequear los códigos de retorno directamente, siempre después de cada sentencia SQL.

4.5.7 Ejemplo de actualización PROCEDURE DIVISION EXEC SQL DECLARE CURS2 CURSOR FOR SELECT TBLFLD1, TBLFLD2, TBLFLD3 FROM TABLA1 WHERE TBLFLD1 = :TB01-FLD1 AND TBLFLD2 = :TB01-FLD2 AND TBLFLD3 < :TB01-FLD3 ORDER BY TBLFLD3 WITH UR END-EXEC.

Sentencias para informar la variable HOST TB01-FLD1, TB01-FLD2, TB01-FLD3

EXEC SQL OPEN CURS2 END-EXEC EXEC SQL FETCH CURS2 INTO :WF-WRK1W, :WF-WRK2W, :WF-WRK3W END-EXEC. PERFORM UNTIL SQLCODE = 100 IF condición THEN EXEC SQL UPDATE TABLA1 SET TBLFLD1 = :TB01-FLD1,




TBLFLD2 = :TB01-FLD2 WHERE CURRENT OF CURS2 END-EXEC. EXEC SQL FETCH CURS2 INTO :WF-WRK1W, :WF-WRK2W, :WF-WRK3W END-EXEC. END-PERFORM EXEC SQL CLOSE CURS2 END-EXEC

4.5.8 Ejemplo de borrado PROCEDURE DIVISION EXEC SQL DECLARE CURS2 CURSOR FOR SELECT TBLFLD1, TBLFLD2, TBLFLD3 FROM TABLA1 WHERE TBLFLD1 = :TB01-FLD1 AND TBLFLD2 = :TB01-FLD2 AND TBLFLD3 < :TB01-FLD3 ORDER BY TBLFLD3 WITH UR END-EXEC.

Sentencias para informar la variable HOST TB01-FLD1, TB01-FLD2, TB01-FLD3

EXEC SQL OPEN CURS2 END-EXEC EXEC SQL FETCH CURS2 INTO :WF-WRK1W, :WF-WRK2W, :WF-WRK3W END-EXEC PERFORM UNTIL SQLCODE = 100 IF condición THEN EXEC SQL DELETE FROM EMPLEADOS WHERE CURRENT OF CURS2 END-EXEC. EXEC SQL FETCH CURS2 INTO :WF-WRK1W, :WF-WRK2W, :WF-WRK3W END-EXEC END-PERFORM EXEC SQL CLOSE CURS2 END-EXEC




5. Anexos

5.1 Anexo 1 – Conversion de datos numéricos

Efecto de la sentencia MOVE con datos numéricos de diversos formatos

DISPLAY numérico COMP COMP-3

DISPLAY numeric

Conversión puede o no puede ser necesaria, dependiendo de las PICTURES

Convierte el campo a COMP-3 y después a COMP

Convierte el campo a COMP-3

COMP Convierte el campo COMP a COMP-3 y entonces hace el DISPLAY

No hay conversión Convierte el campo a COMP-3 en un área temporal y después lo mueve

COMP-3 Convierte el campo COMP-3 a DISPLAY

Mueve COMP-3 al área temporal y entonces convierte a COMP

No hay conversión




5.2 Anexo 2 – Comparación de Datos Numéricos

Efecto de las comparaciones numéricas con diversos formatos


DISPLAY numeric

Convierte ambos campos a COMP-3

Convierte el campo DISPLAY a COMP-3 y luego a COMP o ambos a COMP-3


COMP Convierte el campo DISPLAY a COMP-3 y luego a COMP o ambos a COMP-3.

No hay conversión Convierte COMP a COMP-3 o viceversa dependiendo del tamaño de los campos

COMP-3 Convierte DISPLAY a COMP-3 Convierte COMP a COMP-3 o

viceversa dependiendo del tamaño de los campos

No hay conversión




5.3 Anexo 3 – Efecto en Operaciones aritméticas

Efecto de operaciones aritméticas con diversos formatos


DISPLAY numeric

Convierte el campo DISPLAY a COMP-3, pasa al área temporal

y luego a DISPLAY

Convierte el campo DISPLAY a COMP-3 y luego a COMP o ambos a COMP-3


COMP Convierte el campo DISPLAY a COMP-3 y luego a COMP o ambos a COMP-3.

No hay conversión Convierte COMP a COMP-3 o viceversa dependiendo del tamaño de los campos

COMP-3 Convierte el campo DISPLAY a COMP-3

Convierte COMP a COMP-3 o viceversa dependiendo del tamaño de los campos

No hay conversión




5.4 Anexo 4 – Estándar del cliente Movistar

5.4.1 Glosario

Término Descripción HDTC Herramienta de Diseño Técnico y Construcción ASSCC Arquitectura de Servicios Comunes

5.4.2 Consideraciones Generales

a) Las indicaciones dadas por cliente se complementan con los estándares de Everis, para lo cual se harán referencia al identificador de la regla.

b) Todo elemento deberá tener la cabecera estándar, además del historial de cambios, para identificar los cambios realizados. Inclusive la creación del elemento, para lo cual se debe hacer referencia a la OCTP o REMEDY, según sea el caso.

c) El desarrollador deberá indicar su autoría, tanto en la creación como en la modificación de un elemento. Colocando la letra inicial de su primer nombre y su primer apellido. Por ejemplo si el desarrollador de José Luis Pérez Peña, colocar en el autor: JPEREZ.

d) Todo nombre para un elemento nuevo deberá cumplir la nomenclatura según el tipo, esto se indicará en los siguientes puntos.

e) Actualmente EVERIS, realiza mantenimiento de componentes para los módulos AC (Atención del cliente) e IN (Infraestructura). Por lo tanto, los componentes a realizar mantenimiento no deben tener referencia en su nombre a los módulos de FA (Facturación) ni CO (Çobros).

f) Si se está analizando la creación de una tabla local, la cual guarda información transaccional o de movimientos, debe tener un proceso de depuración o pase a históricos, salvo sea una tabla de configuración.




5.4.3 QA de programas.

5.4.3.1 Alcances de los programas

a) Todo programa nuevo no debe contener ningún tipo marca (en las columnas 1 a la 6), ni sentencias comentadas. Las marcas se colocan solamente después que el programa ha pasado a producción. El identificador del cambio o marca debe ser único para una solicitud de modificación tanto como REMEDY o como OCTP.

b) Es necesario respetar la arquitectura online de invocación de elementos tipo programa.

Tipo Descripción

FIS Función de integración de Sistemas Es el elemento encarga de agrupar la lógica de negocio (SN), pero en algunos casos también agrupa FIS’s, tomando el nombre de FIS Agrupadora.

SN Servicio de Negocio Contiene la lógica de negocio, tales como validaciones, verificaciones. Los elementos de este tipo no deben solamente el paso de datos entre FIS y SAD. Dicho elemento puede invocar a múltiples SAD o Rutinas (elementos ATIS)

SNE Servicio de Negocio Externo Contiene la estructura de datos, a intercambiar con COLAS MQ, en dicha estructura, puedo colocar tanto la estructura de entrada como de salida. Actualmente hay SNE de ATIS, que son programas, tales como PEE0038, los cuales son una excepción a la regla.

SAD Servicio de Acceso a Datos Contiene las sentencias SQL. Se debe evitar tener lógica de negocio, para reutilizarlas en los futuros proyectos Se debe tener en cuenta que el acceso a las tabas locales, tablas Repositorio y a las tablas ATIS, no debe estar en un solo programas, ya que usan esquemas diferentes. Que son los siguientes: Las tablas ATIS, utilizan el esquema ATIS2X. Las tablas REPOSITORIO, utilizan el esquema REPO2X. Las tablas Locales, utilizan el esquema LOCA2X. Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress

Todos los elementos de este tipo deben manejar, las sentencias y condiciones para identificar si está realizando un TRACE.

Los programas de tipo FIS y SN no deben tener sentencias SQL

Los nombres y relación entre los elementos online, se debe gestionar con el Personal que administra la herramienta HDTC.

c) Para los elementos tipo SAD, es necesario que soporte muchas acciones, especialmente cuando se crean para tablas nuevas, para ello es necesario utilizar el elemento de información:

TIP-ACC-DAT-CD: TIPO DE ACCESO A UNA TABLA MEDIANTE UN SAD MULTIFUNCIONAL

El cual ocupa dos caracteres alfanuméricos, y se sugiere que para los próximos proyectos, evalúe los siguientes valores:

Tipo Acción

SF Selección del registro de la tabla




S1 Selección del registro por el primer índice

UP Actualizar el elemento por llave primaria

UL Baja lógica del registro

IN Insertar registro

DE Eliminar registro

Se puede indicar variaciones de acceso a la tabla cambiando la segunda letra del indicador, por ejemplo si quiero variar el estado de un registro, el tipo de acceso de datos sería: “US”.

También se puede aplicar el principio anterior, para la FIS y SN, utilizando los elementos de información:

IND-TIP-OPR-IN: Indicador de tipo de operación (1 carácter)

ACC-DAT-PRI-SN: Código de tipo de acceso a datos primero (2 caracteres)

d) Todos los párrafos deben tener un comentario inicial indicando la función a realizar.

e) Evitar el uso de párrafos que tenga como única sentencia EXIT.

f) Evitar colocar el punto por cada sentencia COBOL, sólo se debe colocar al final del párrafo. Ya que incrementa en tiempo de compilación.

g) Se sugiere evitar el uso de comentarios no útiles en la codificación, porque aumentan líneas de código y no ayudan a la documentación. Como se sabe todos los programas cobol, tienen 4 divisiones obligatorias, y su nombre no varía en el tiempo.

*===============================================================* *= =* *= I D E N T I F I C A T I O N D I V I S I O N =* *= =* *===============================================================*

h) Mantener el orden de la codificación. Todas las líneas deben estar correctamente IDENTADAS, es decir, guardar la correcta tabulación cuando se agrupan sentencias o segmentos de código, de acuerdo a una condición, iteración o párrafo.

i) Se han declarado solos los párrafos necesarios y todos éstos son invocados.

j) Las opciones de compilación a manejar son las siguientes:

Opción Descripción 1 Es para la compilación de programas CORE ATIS y programas DA que

actualizan tablas ATIS. La librería de los programas es: PPA.V14.X.SOURCE Siendo X, el ambiente: PROD: Producción D: Desarrollo G: Certificación S: Stress

2 Es para la compilación de programas relacionado Desarrollo Adicionales (DA), del tipo BATCH, los cuales pueden o no acceder a BD. La librería de los programas es: PPDX.V14. SOURCE Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress




3 Son para programas tipo SAD (que hacen solo consultas a tablas ATIS), relacionados a Desarrollo Adicionales (DA), La librería de los programas es: PPDX.V14. SOURCE Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress

4 Son para programa que acceden al esquema REPO2D. La librería de los programas es: PPDX.V14. SOURCE Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress

5 Son para elementos tipo FIS y SN de un Desarrollo Local. Son para elementos tipo SAD que acceden a tablas locales, tanto para consultas como modificación de datos. La librería de los programas es: PPDX.V14.LOCAL.SOURCE Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress

6 Son para programa BATCH, que acceden a tablas locales. No se debe compilar programas que acceden a ATIS, con la opción mencionada. La librería de los programas es: PPDX.V14.LOCAL.SOURCE Siendo X, el ambiente: Q: Producción D: Desarrollo G: Certificación S: Stress

5.4.3.2 Sección Inicial del programa

a) El nombre de programas ONLINE (FIS, SN, SAD, SNE), son proporcionados únicamente por la herramienta HDTC.

b) El nombre del programa BATCH debe cumplir con los estándares definidos, según el siguiente cuadro

Programa.- DASPLnnn

DA = Desarrollos Locales S = Sistema ATIS, donde:

• F = FA • C = CO • I = IN • A = AC

P = Tipo, donde: • B = BATCH • O = Online

L = Lenguaje, donde: • C = Cobol • D = DB2

nnn = Número secuencial correlativo de 001 a 999. En caso se acaben los números secuenciales utilizar caracteres válidos. EJEMPLOS: DAABC057, DACBD015




c) El programa debe tener al inicio, una cabecera con una descripción breve de su funcionalidad.

*===============================================================* * PROYECTO : * * * * OBJETIVO : * * * * PROGRAMA : * * * * TYPE : * * * * DESCRIPCION FICHEROS : * * * * DESCRIPCION COPYS : * *---------------------------------------------------------------* * FECHA AUTOR DESCRIPCION * *---------------------------------------------------------------*

Los formatos de los tres campos solicitados del historial de versiones, deben ser el siguiente:

Campo Formato Posición Inicial

Posición Final

Observación

Fecha DD/MM/YYY 9 18

Autor FLASTNAME 20 34 (Como máximo)

Debe respetar las consideraciones descritas en el punto 5.4.1 (Item C)

Descripción Libre 36 71 (Como máximo)

Debe respetar las consideraciones descritas los apartados c) y d). en el punto 5.4.1, Además la descripción debe tener más de una línea pero como máximo 4.

d) Cuando el programa sea modificado, existan “marcas” o identificadores. de estos cambios realizados, además de mostrarse también en la cabecera con su descripción de dicho cambio, en donde debe indicar la OCTP o Remedy correspondiente al problema en Producción.

Las marcas deben ubicarse en la parte A del programa (columna 1 a la 6), se deben tener el siguiente formato:

VNNNNN:

La letra V, indicará la versión que es una nueva versión del programa

NNNNN: Correlativo de la versión.

Las líneas a modificar deben ser comentadas, no se deben eliminar para tener evidencia de la versión original.

e) En la sección de la IDENTIFICATION DIVISION, debe contar con las siguientes líneas como mínimo.

IDENTIFICATION DIVISION. *======================== PROGRAM-ID. DVD0143. AUTHOR. ALONSO ELGUERA M. INSTALLATION. TELEFONICA.

5.4.3.3 Sección configuración y/o entorno del programa

a) Deberá seguir los puntos indicado en el apartado 3.2, según sea necesario.

b) Pero para el caso de programas que accedan a archivos es obligatorio el uso de las cláusulas (ASSIGN, ORGANIZATION, ACCESS MODE) indicadas en el punto ED003.




5.4.3.4 Sección declarativa del programa

a) Deberá seguir los puntos indicado en el apartado 3.3, según sea necesario.

b) Se deben seguir de manera obligatoria los puntos: WS001, WS002, WS003, WS004, WS005, WS006, WS007, WS008, WS009, WS010, WS011, WS012, WS013, WS014, WS015, WS016, WS017, WS018, WS019.

Además utilizar las reglas de LINKAGE (LS001 y LS002).

c) Usar datos de tipo binario (COMP) para el índice de los arreglos, en caso sea necesario declararlo, pero es mejor utilizar el índice declarado en el arreglo.

d) Usar datos de tipo binario (COMP) para contadores con una longitud máxima de 9.En el caso de gran cantidad de datos y se necesario manejar una longitud superior a 9 debe ser de tipo COMP-3.

e) Se recomienda utilizar variables tipo 88, para captar los casos más comunes, del FILE-STATUS de un archivo.

f) Sólo se debe declarar variables, a utilizar en los programas o subrutinas de los mismos.

g) Para los nombres de variables, tomar como referencia siempre los Elementos de Información, generados en la herramienta HDTC. Solo deberá variar el prefijo.

Un elemento de información, viene a ser el nombre único que identifica y relaciona al dato o datos que forman parte de los procesos, entre diferentes tablas, módulos y sistemas en una institución.

h) Verificar si es necesario los siguientes COPY’S ,ya que en la mayoría no se usan y se encuentran en los elementos de SAD, ocupando espacio de memoria innecesaria.

A continuación se indica el uso de cada copy:

N° COPY Descripción 1 ASEVGT99 Datos de entrada de la interfaz publica al gestor de tablas de

parámetros 2 ASSVGT99 Datos de salida de la interfaz publica al gestor de tablas de

parámetros 3 DPAC0001 Contiene errores tipo 08, los cuales son errores de aplicación

i) En el caso de los COPYS 1 y 2 de la tabla anterior, deberá incluirse en el programa, siempre y cuando se acceda a tablas paramétricas (Tabla ASTABLMD) usando el programa de ASSCC de ATIS (ASGT99CA)Sección operativa del programa

5.4.3.5 Sección de procedimientos del programa

a) Tener en cuentas todas las reglas indicadas en el punto 3.6.




b) Se deben indicar en la PROCEDURE DIVISION, el párrafo inicial 0000-PRINCIPAL, y dentro de éste, se debe invocar los siguientes párrafos principales, como se indica a continuación:

En un programa online En un programa Batch 0000-PRINCIPAL. PERFORM 1000-INICIO PERFORM 2000-PROCESO PERFORM 3000-FIN GOBACK.

0000-PRINCIPAL. PERFORM 1000-INICIO PERFORM 2000-PROCESO PERFORM 3000-FIN STOP RUN.

En el párrafo inicial, se debe realizar las inicializaciones de las variables (inclusive los arreglos) y verificar la traza inicial (en caso sea online), como funcionalidades mínimas.

En dicho párrafo se debe de invocar la apertura de archivos y la primera lectura de los archivos, así como la carga de los arreglos, según sea necesario.

En el párrafo proceso, se debe plasmar los objetivos del proceso.

En el párrafo fin, se verificar la traza final (en caso sea online), y finalizar el proceso.

c) La apertura y el cierre de los archivos, se debe de realizar para todos los archivos involucrados en el proceso.

d) Toda sentencia EVALUATE deberá tener una condición OTHER.

e) Todos los archivos declarados en el SELECT debe figurar en el proceso con una sentencia de lectura o escritura.

f) Uso de la sentencia DISPLAY.

� Los programas online, no deben contar con la sentencia DISPLAY.

� Validar que no existan DISPLAY’S innecesarios en los programas BATCH.

� Verificar que el programa BATCH debe de tener un estadístico del proceso (registros leídos, grabados, con error, etc.).




� En los programas tipo BATCH solo se debe mostrar los siguientes campos

� Nombre de archivo

� Operación

� Código error, el cual puede ser, el estado del Fichero (FILE STATUS) y Código SQL (SQLCODE).

Después detener el programa. Ya que se debe controlar el uso de display en el SPOOL.

Evitar lo siguiente

Se sugiere que los DISPLAYs vayan dentro del ELSE antes del STOP RUN, para evitar rechazos por Testing

g) Verificar mover datos de errores siempre cuando se verifique si hay error mediante una condición, tanto para los FILE STATUS y SQLCODE

Evitar lo siguiente:




Se sugiere

h) Usar SEARCH ALL en la búsqueda de datos en un arreglo para procesos que se ejecutan en paralelo u otro para archivos/tablas con más de 99 registros (ejemplo de buena práctica ver programa DIFBD001, el arreglo esta ordenado).

i) Utilizar las variables de la DCLGEN de la tabla no usar valores fijos o variables propias del programa salvo sea necesario.

j) Si se modifica variables externas (COPY con valores de constantes), debe constatarse que en los programas que las usan también hayan sido modificadas.

k) Utilizar siempre el archivo de errores en los programas BATCH, con la estructura DAICLGER o DAACLGER. Ubicados en la librerías_

PPDQ.V14.LOCAL.COPY(DAACLGER)

PPDQ.V14.COPY(DAICLGER)

No se debe utilizar el DAFCLGER y DACCLGER ya que son del bloque FA / CO

l) Utilizar las sentencias END-READ, END-WRITE, END-SEARCH y los demás terminadores de sentencias y no el punto.

m) Usar el estándar de MATCHING para evitar el alto consumo de MSU por hacer demás sentencia de comparación. IF FOVO-COD-FAC-CD < WS-COFA-CD (IND)

IF FOVO-COD-FAC-CD = WS-COFA-CD (IND) PERFORM 3440-GRABA-IGUALES PERFORM 3410-LEER-FOVO ELSE IF FOVO-COD-FAC-CD > WS-COFA-CD (IND) ADD 1 TO IND ELSE PERFORM 3410-LEER-FOVO END-IF END-IF.

También se sugiere utilizar la sentencia EVALUATE.

EVALUATE TRUE WHEN FOVO-COD-FAC-CD = WS-COFA-CD (IND) PERFORM 3440-GRABA-IGUALES PERFORM 3410-LEER-FOVO WHEN FOVO-COD-FAC-CD > WS-COFA-CD (IND) ADD 1 TO IND WHEN OTHER PERFORM 3410-LEER-FOVO END-EVALUATE.

La sentencia EVALUATE, tiene menor consumo frente al uso de IF

n) Se debe validar que no se presente desbordamiento del vector de datos (ARRAY), cuando se está moviendo valores. Y se debe comparar contra un campo del programa tipo constante y no con un valor fijo.




Para lo cual se sugiere lo siguiente para programas Online:

En el párrafo 3402-PROCESO-PEVAPEDV Se está controlando la longitud del vector de datos *----------------------------------------------------------------* * LISTA DE PVA PARA HOMOLOGACION. * *----------------------------------------------------------------* 3402-PROCESO-PEVAPEDV. INITIALIZE MSI-DPS0169I INITIALIZE ACS-MOD MOVE 'I2' TO MSI-TIP-ACC-DAT-CD OF MSI-DPS0169I MOVE 'PSEQUIPVA' TO MSI-COD-TIP-VLD-CD OF MSI-DPS0169I MOVE '0' TO MSI-IND-EST-ACV-IN OF MSI-DPS0169I PERFORM X010-LLAMA-DPS0169 SET WS-PSPVA TO 1 PERFORM VARYING WS-CNT2 FROM 1 BY 1 UNTIL WS-CNT2 > MSO-NUM-REG-RCU-NU OF MSO-DPS0169O OR WS-PSPVA > WCN-LIM-PVA MOVE MSO-COD-VAL-INI-CD OF MSO-DPS0169O (WS-CNT2) TO WCA-PVA-EQUIVALENTE OF ARR-D-PSPVA (WS-PSPVA) MOVE MSO-COD-VAL-RST-CD OF MSO-DPS0169O (WS-CNT2) TO WCA-PVA-ORIGINAL OF ARR-D-PSPVA (WS-PSPVA) SET WS-PSPVA UP BY 1 END-PERFORM IF WS-CNT2 <= MSO-NUM-REG-RCU-NU OF MSO-DPS0169O

AND WS-PSPVA > WCN-LIM-PVA

MOVE '3402-PROCESO-PEVAPEDV' TO WS-ACS-PARFERROR

MOVE 'TABLA PROVINCIA' TO ACS-VARMSG OF ACS-FIS (2)

PERFORM 8400-ERROR-VECTOR-DAT

END-IF

En caso se presente un desbordamiento se invocará al párrafo 8400-ERROR-VECTOR-DAT, el cual contiene la lógica para genera un mensaje de error a nivel de ventana, indicando la descripción del problema y la ubicación.

*----------------------------------------------------------------* * TRATAMIENTO DE ERRORES DE VECTOR DE DATOS *----------------------------------------------------------------* 8400-ERROR-VECTOR-DAT. MOVE 'ASC3ACST' TO ACS-COPY OF ACS-FIS MOVE 8 TO ACS-CR OF ACS-FIS MOVE 'A' TO ACS-TERROR OF ACS-FIS MOVE WS-ACS-PARFERROR TO ACS-PARFERROR OF ACS-FIS MOVE 'DPM0045A' TO ACS-CODMSG OF ACS-FIS (1) MOVE 'DPM0045A' TO ACS-CODMSG OF ACS-FIS (2) MOVE CT-ERR-DESBOR TO ACS-VARMSG OF ACS-FIS (1) MOVE 2 TO ACS-NUMMSGS OF ACS-FIS MOVE MODULO-ID(3:8) TO ACS-PROGERROR OF ACS-FIS. PERFORM 9999-SALIDA-ERROR.

En los programas BATCH, es necesario utilizar el archivo de errores.

5.4.3.6 Uso de Base de Datos

a) Tener en cuentas todas las reglas indicadas en el punto 4.

b) Las tablas que tienen datos de tipo catálogo las cuales están acotadas por ciertos campos, por ejemplo la tabla PSCYPSDV, que puede está acotada por familia y categoría, o la PEVAPEDV, que contiene validaciones de peticiones o procesos. Se debe recuperar los registros de manera ordenada (utilizar si es necesario el ORDER BY, en caso no se acceda por índice), y almacenarlo en un vector de datos para posteriormente realizar una búsqueda binaria. Lo cual optimizaría el acceso a datos.

c) El acceso a tablas debe ser únicamente por índice, y de tal manera para acotar la cantidad de registros.




d) Usar CHECKPOINT cuando se actualiza (UPDATE o INSERT) una tabla para controlar la frecuencia de COMMIT y re arranque (ejemplo de buena práctica ver programa DAABDA82).

La configuración de CHECK POINT, se debe de indicar en el SOFTWARE PRODUCIDO.

e) Usar lectura de catálogo por cursor y guardar en arreglo del programa que accede a la BD.

f) Evitar actualizar una tabla que usa cursor manteniendo el cursor abierto.

g) Usar WITH UR en lectura de tabla transaccional y/o catálogo en programas.

h) Utilizar el control de manejo de errores cuando se accede a la BD.

i) En la cláusula WHERE utilizar los campos claves o índices de la tabla a acceder.

j) Evitar el uso de la sentencia FOR FETCH ONLY y FECHT FIRST n ROWS ONLY.

k) Evitar la sentencia SELECT, accediendo a 3 tablas. Por performance, se sugiere acceder a 2 tablas y luego a una tercera.

l) La Nomenclatura de DCLGEN es DPXXXXDV. Debe de hacer referencia a la vista. En los casos de DCLGEN se deben generar no está permitido la modificación de estos componentes con P.3.2. De ser necesario, se debe permitir la modificación del DCLGEN, para retirar el ALIAS de la BD (ATIS2D) que se genera por defecto.




5.4.4 QA de copy’s.

a) Validar que el nombre de la copy cumpla con los estándares definidos.

COPY.- DASCxxxx


• F = FA • C = CO • I = IN • A = AC

C = Copy xxxx = Nombre del Copy EJEMPLO: DAFCEMPR

b) Validar que la copy tenga al inicio una cabecera con una descripción breve.

**************************************************************** * NOMBRE : * * PROYECTO : * * MODULO : * * DESCRIPCION : * * LRECL : * *==============================================================* * FECHA AUTOR DESCRIPCION * *--------------------------------------------------------------*

Para los componentes Regionales no aplica esta observación, puesto que son generados por una herramienta automatizada (HDTC o DIANA)

c) Validar que cuando existan cambios en la copy, existan “marcas” de estos cambios realizados, además de mostrarse también en la cabecera con una descripción breve.




5.4.5 QA de CTLs.

a) Validar que el nombre del Ctl cumpla con los estándares definidos.

CTL.- DASTnnnn


• F = FA • C = CO • I = IN • A = AC

T = CTL nnnn = Número secuencial correlativo de 0001 a 9999 EJEMPLO: DAIT5010

b) No se aceptan Jobs que en su contenido utilicen CTL a menos que sea un proceso dinámico el cual utiliza los CTL’s como plantilla.




5.4.6 QA de procedimientos.

a) Validar que el nombre del PROC cumpla con los estándares definidos.

PROC.- DASPnnnn


• F = FA • C = CO • I = IN • A = AC

P = Proc nnnn = Número secuencial correlativo de 0001 a 9999 EJEMPLO: DAFP5085

b) Los procedimientos solo se utilizan para procesos dinámicos. En este caso un PROC es también usado como plantilla.




5.4.7 QA de JCL.

a) Validar que el nombre del Job cumpla con los estándares definidos.

JCL.- DASJnnnn

DA= Desarrollos Locales S = Sistema ATIS, donde:

• F = FA • C = CO • I = IN • A = AC

J = Job de explotación de Datos W = Job de transmisión de CONNECT a HOST R = Job de transmisión de HOST a CONNECT nnnn = Número secuencial correlativo de 0001 a 9999 EJEMPLO: DAAJ0850

b) Validar que el Job tenga una cabecera con una descripción de su funcionalidad.

//********************************************************************* //* NOMBRE : * //* MODULO : * //* D.T. : * //* DESCRIPCION : * //*===================================================================* //* FECHA AUTOR DESCRIPCION * //*-------------------------------------------------------------------*

c) La librería que contiene las variables para identificar el ambiente de ejecución del ambiente, debe ser el PARAMDAS.

Evitar el uso de las siguientes librerías no usadas en Jobs.

//* %%INCLIB PPD%%AMB..%%V.DA.PROC %%INCMEM PARAMDAS //* %%INCLIB PPAA%%AMB..%%V.AC.PROC %%INCMEM MODIF //* %%INCLIB PPAA%%AMB..%%V.AC.PROC %%INCMEM NOMODIF //* %%INCLIB %%LIBCOP.PROC %%INCMEM COPARAM //* %%INCLIB %%LIBAC.JOB %%INCMEM ACVAR

d) Todos los pasos del Job, se debe indicar la funcionalidad que está destinada cada paso.

e) Para la creación de archivos en vacío, tanto para Jobs de Explotación de datos y de transmisión, utilizar el utilitario ICEGENER

//*-------------------------------------------------------------------* //* PASO0040 - ICEGENER - GENERA ARCHIVO VACIO //*-------------------------------------------------------------------* //PASO0040 EXEC PGM=ICEGENER //SYSPRINT DD SYSOUT=* //SYSUT0 DD DUMMY //SYSUT1 DD DSN=%%DSAC..%%V.DAAJA740.DAACER24.TOT.S, // DISP=(NEW,CATLG,DELETE),UNIT=SYSDA, // DCB=(RECFM=FB,LRECL=04,BLKSIZE=0), // SPACE=(%%SPACE_S,RLSE),%%VOL_S //SYSUT2 DD DUMMY




//SYSIN DD *

f) Todo Job (excepto los Jobs transmisores) deben de tener un paso de borrado al final del mismo. En este punto pueden existir excepciones pero que sean justificadas por el desarrollador.

g) Validar el nombre de los ficheros de salida en el Job.

El nombre de los ficheros de salida debe de hacer mención al nombre del Job que lo que crea.

Esto no aplica cuando existan casos en que el fichero de salida deba tener el nombre de un fichero de ATIS el cual será usado por un JOB ATIS.

Por ejemplo, en AC hay un JOB DAAJ0080 que genera un fichero de salida el cual será utilizado por el JOB de ATIS PEJ0005. En este caso si es válido que el nombre de fichero de salida difiera del nombre del JOB porque este será utilizado por ATIS-AC.




h) Si el JOB utiliza descargas con INZUTILB(HPU), debe de verificarse que la descarga muestre estadísticos. Para validar esto lo recomendable es ejecutar solo el paso de descarga.

Se muestra otro ejemplo con descarga usando INZUTILB y que no muestra estadístico lo cual será rechazado.




Cuando el JOB use descargas (cualquier descarga usada o no con INZUTILB) no debe de tener “WITH UR”.

i) Cuando se usa el SORT debe de considerarse que si es “SORT FIELDS=COPY”, en este caso no se usa DYNALLOC, caso contrario siempre debe de tener DYNALLOC.

j) Para los Jobs transmisores “R” (de 390 a CONNECT) y “W” (de CONNECT a 390) deben de tomarse en cuenta:

El paso o pasos de transmisión debe de contener estas líneas “NDM%%ENTORNO,PLIB=PPA.%%V.NDM.%%ENTORNO”, es decir debe de estar con los parámetros, para determinar el ambiente.

Cuando se copia el JOB trasmisor al ambiente de TESTING, debe de cambiarse el “v11” (ruta de Producción) por “v14” (ruta de pruebas) ya que se debe de probar que los Jobs transmisores se ejecuten correctamente. OJO aquí tener mucho cuidado con la ejecución del Job transmisor ya que se podría sobrescribir en el CONNECT ficheros de Producción (sobre todo los Jobs de tipo “R”), es por eso que es importante hacer este cambio.

k) Los Jobs transmisores “R” deben de tener siempre un paso de condición para UNIX. Esto es necesario porque en Producción los ficheros que son copiados al CONNECT, van a otro servidor y para ello el CONTROL-M del SUN requiere esta notificación.




l) El nombre del JOB trasmisor “R” debe estar de acuerdo al nombre del Job predecesor, por ejemplo: si se tiene el Job DAAJA341 cuyo fichero o ficheros serán transmitidos al CONNECT, el nombre del Job transmisor debe ser DAARA341. No sería correcto si este Job DAAJA341 tenga como Job transmisor un DAAR0540 (por ejemplo).

m) Evitar los procesos con alto tiempo de respuesta por inadecuado uso de los SQL, no se accede por la clave o índice secundario.

n) Inadecuado acceso a la BD por lectura cuando deberían de trabajar con archivos planos y usar el método MATCHING.

o) Los Jobs de transmisión (la quinta posición del nombre del Job con letra W) debe tener control de existencia de transmisión de archivo.

p) Verificar si es necesario la configuración de transmisión de archivo de intercambio del Mainframe y servidor CONNECT hacia el usuario final quedándose en el servidor CONNECT. En caso sea así, debe indicar el Excel de Software de Producido, e indicar los scripts necesarios.

q) Verificar el uso de utilitarios para descarga de tablas (HPU, DNSTIAUL). Se usa HPU cuando se descarga una sola tabla y DNSTIAUL cuando una tabla hace JOIN con otra. Verificar si el JOIN entre tablas por no usar los índices.

r) Usar archivo de errores como salida de un proceso BATCH para evidenciar la caída y motivo.

Para el archivo que guarda los errores de ejecución de un programa declararlo %%VOL_S,SPACE=(%%SPACE_S,RLSE),

s) Evitar la duplicidad de descarga de registros de las tablas (catálogos, transacciones) cuando otros lo realizan en la misma planificación. Se sugiere reutilizar descarga.

t) Evitar modificar o crear Jobs con un STEP que descargan catálogos y lo usan como archivo en el programa, este incrementa pasos en e l JOB.

u) Para la descarga de tablas de tamaño medio y grande se recomienda utilizar la utilidad HPU,




5.4.8 QA de cadenas.

a) Validar que el nombre de la cadena cumpla con los estándares definidos.

CADENA.- DSMOFnnn

D = Desarrollos Locales S = Sistema ATIS, donde:

• F = FA • C = CO • I = IN • A = AC

MO = Módulo. Ejemplo: • TR = Tráfico • RE = Rentas • C1 = Administrado de saldos • SI = Sincronismo • IB = Integración BATCH • MI = Migración • PE = Pedido • CC = Cliente / Cuenta • PQ = Parque

F = Frecuencia, donde: • I = Día cero • D = Diario • S = Semanal • Q = Quincenal • M = Mensual • T = Semestral • C = Cíclico • E = Eventual

nnn = Número secuencial correlativo de 001 a 999 EJEMPLO: DFPCD001

b) En el MEMLIB de la cadena de acuerdo al entorno, debe ir siempre lo siguiente:

c) En la parte que dice “GROUP” siempre debe ir el nombre de la cadena.

d) En la parte que dice “OVERLIB” debe estar “VACIO SIEMPRE”.




e) Validar que las condiciones predecesoras y sucesoras sean las correctas.

f) Cuando se modifica o crea una cadena se debe de entregar el flujo a nivel de Jobs en formato “visio” de la cadena. Este flujo debe de reflejar la misma secuencia de ejecución que se muestra en el CONTROL-M.

Estos flujos en formato visio son requeridos para el pase a comité de lo contrario es rechazado por Comité.

g) Considerar que se deben optimizar las cadenas, es decir no se deben generar varias cadenas por proyecto.

h) Para los Jobs de transmisión de datos (tipo J), deben tener activada la opción PREVENT-NCT2=Y

i) Para Job de transmisión tipo W (Connect a Host), debe tener la opción PREVENT-NCT2 = N.




5.4.9 QA de ficheros o Archivos.

a) Validar que el nombre del fichero cumpla con los estándares definidos.

PPDSA.Vnn.Nombre-Job.Nombre-Archivo.2do-Nombre-Archivo.Tipo-Archivo PP= Telefónica del Perú D = Desarrollos locales S = Sistema ATIS, donde:

• F = FA • C = CO • I = IN • A = AC

A = Ambiente. Ejemplo: Q, J, N, D, G, etc. Vnn = Versión. Ejemplo: V14 Nombre-Job = Nombre de Job que lo genera. Ejemplo: DAFJA020 Nombre-Archivo = Nombre de archivo: Ejemplo: FONOCARD o la COPY relacionada 2do-Nombre-Archivo = 2do.Nombre de Archivo. Ejemplo: F070108 Tipo-Archivo = Tipo de archivo. Ejemplo S (Secuencial) / K (VSAM KSDS) EJEMPLO: PPDFQ.V14. DAFJA020.FONOCARD.F070108.S

Estandares de Codificacion v 4.1

Documents

Transcript of Estandares de Codificacion v 4.1