1.

DIRECTRICES Y RECOMENDACIONES........................................................................4
OBJETIVO DE ESTE APARTADO...........................................................................................................4
MANDATOS Y RESTRICCIONES..........................................................................................................5

2.

DIRECTRICES Y RECOMENDACIONES......................................................................13
INTRODUCCIN...............................................................................................................................14
GUA DE DISEO.............................................................................................................................14

Optimizacin del acceso a DB2...............................................................14

Aumento del paralelismo.........................................................................16
Descargas a ficheros secuenciales............................................................19
Gestin de Checkpoint/Restart.................................................................22
Aumento de la eficacia operativa.............................................................23
Administracin de la base de datos..........................................................23
Consideraciones del diseo fsico del modelo de datos...........................24
Monitorizacin constante del rendimiento...............................................25
NORMAS Y RECOMENDACIONES DE PROGRAMACIN.....................................................................26

Diseo Procesos Batch.............................................................................26

Accesos a DB2.........................................................................................26
Variables HOST.......................................................................................33
Programacin COBOL.............................................................................33
Errores comunes.......................................................................................35

____________________________________________________________________________________
Pg. 1 de 32

1. Directrices y Recomendaciones
Objetivo de este apartado.
Las recomendaciones corresponden a consejos tomados de la literatura
experta, que marcan una buena alternativa de cmo enfrentar una situacin. El
seguir las recomendaciones tendr como resultado necesario una mayor
posibilidad de construir un software de calidad, lo que en otras palabras se
transforma en un activo de mayor valor.
Es posible que este documento no de cuenta de todos los problemas en Diseo
y Construccin sin embargo es una gua bastante completa. De descubrir
problemas no tratados en esta edicin este documento puede ser actualizado
con la publicidad oportuna que se requiere para no entorpecer el avance del
proyecto.
Mandatos y Restricciones
1) Siempre habr solvencia tcnica detrs de un programa. En repetidas
oportunidades hemos constatado que detrs de un programa si bien ha
existido una detallada especificacin funcional, el como construirlo se
ha dejado al libre albedro del programador sin asegurarse que este
tiene dominio sobre los recursos tcnicos que ha de manejar. Ejemplos
recurrentes de estos son :
En transacciones CICS, en el manejo de las reas de comunicaciones
(COMMAREA) se han observado instancias de desconocimiento
absoluto del protocolo que regula su definicin, direccionamiento y
reglas de manejo de longitudes. Estos errores muchas veces son
difciles de detectar en un entorno distinto al de Produccin y una
vez detectada la existencia de un problema de este tipo, no siempre
es fcil de diagnosticar.
En programas DB2 en general , se ha observado sentencias SELECT
calificadas con complicada lgica booleana donde ninguno de los
discriminantes de la clusula WHERE tiene respaldo en la estructura
de la tabla.
Programas batch-DB2 que realizan grandes procesos secuenciales
por un orden distinto al de su cluster-key, sin haber razn para ello.
____________________________________________________________________________________
Pg. 2 de 32

Tal vez sea esta primera obligacin, la sntesis del resto de las
obligaciones y recomendaciones que componen el documento, esta es la
razn por la que nos hemos extendido en este punto y por lo que
consideramos esencial la intervencin de conocedores del tema
tecnolgico como respaldo para cada aplicacin. El conocimiento
tcnico aqu requerido puede ser entregado por un diseador fsico con
dominio del tema, mediante especificaciones detalladas de cmo
construir la aplicacin, otra alternativa es que el constructor sea el
experimentado en el tema y si ninguna de los dos fuera posible se debe
solicitar soporte al equipo de Infraestructura y Ambientes TI, quien
intentar proporcionar este con recursos propios o apoyado en los socios
tecnolgicos a su alcance.
Ser responsabilidad del Jefe de Equipo que este mandato se
cumpla sin excepcin.
2) No utilizar el verbo CANCEL de COBOL. Cientos de horas
productivas se han perdido debido al overhead de I/O, a veces superior
al 60% del tiempo total de ejecucin de un programa, medido en
decenas de horas, producto de la mala utilizacin de sta. Otras tantas
se han incurrido en la deteccin y reparacin de este problema.
3) No realizar SORT sobre el mismo archivo de entrada
4) No realizar un REPAIR despus de un LOAD, en su lugar debe
usarse un IMAGE COPY
5) Se especifica que no debe usarse la clusula VOL=SER en tarjetas
DD de JCLs ya que la instalacin posee SMS (que es quien decide el
Vol en que alocar el fichero)
6) NO USAR la instruccin SQL : SELECT * INTO :dclgen FROM
table-name .Cuando se requiera consultar una tabla DB2 es
conveniente seleccionar cada una de las columnas de la tabla, ya que
si la estructura de la tabla cambiase dicho cambio no afectar la
ejecucin del programa.
7) NO USAR operaciones aritmticas en la clusula WHERE . Como
ejemplo
SELECT col1, col2, col3 FROM table-name
WHERE col4 = :ws-var4 + 5 ;
El uso de una operacin aritmtica en la clusula WHERE inhibe
el uso de ndices que puedan resolver apropiadamente el SQL.
____________________________________________________________________________________
Pg. 3 de 32

8) Utilizacin de la secuencia dada por la CLUSTER-KEY en procesos

batch masivos cada vez que esto mejore el rendimiento.Cuando se
realicen procesos masivos sobre una tabla DB2, lo primero que se
debe analizar es la posibilidad de orientar la ejecucin del proceso a
que los datos se manipulen de acuerdo a su orden CLUSTER
secuencia fsica - , ya que esto activar los mecanismos de
Sequential Prefetch y Sequential Detection en el DB2. Estos
mecanismos reducen el I/O Wait de un proceso, ya que bsicamente
llevan las pginas de datos a memoria antes que el proceso las
requiera. La posibilidad de que esta oportunidad exista depende de la
calidad del modelo fsico de datos. Hay experiencia en CTC de
programas que han reducido su elapsed time desde mas de 13 hrs.
a 45 minutos al introducir la mejora aqu planteada.
9) Se debe usar la rutina de checkpoint/restart de ASSCC en todos los
procesos de actualizacin superiores en elapsed time a 1 hora. En
todos los procesos de actualizacin de datos en tablas DB2, es
altamente conveniente hacer uso de la instruccin SQL COMMIT,
proporcionada en este caso por la rutina mencionada, la que dar
puntos de estabilidad intermedios al proceso. El uso de esta
instruccin permitir una mayor concurrencia sobre los datos y
reducir el tiempo de un reproceso ante eventuales cadas.
10) Estudiar el path de acceso elegido por DB2. Al momento de
programar es conveniente realizar una lectura sobre la tabla
PLAN_TABLE, la que indica el camino elegido por el DB2 para
resolver las instrucciones SQLs. El uso de esta facilidad permitir
depurar las instrucciones SQLs y asegurarse de un correcto uso de
ndices para accesar los datos.
11) No usar SQL Dinmico. Esto significa, que cada instruccin SQL
resuelva su camino a travs del BIND de un package posterior a la
compilacin y NO en tiempo de ejecucin.
12) Evitar cada vez que sea posible, fundamentalmente en programas
batch, el uso de la clusula ORDER BY. Con esto se evitar un
SORT implcito de DB2, el que utiliza entre otros recurso tablas de
trabajo de DB2 las cuales estn orientadas a clasificar un pequeo
nmero de filas, fundamentalmente a los programas on-line. Siempre
estudie, para los programas batch, la posibilidad de utilizar el
____________________________________________________________________________________
Pg. 4 de 32

producto DFSORT, invocado como utilitario o desde la aplicacin.

DFSORT es uno de los productos mas eficientes que se conoce.
13) Toda vez que sea posible se debe hacer uso de la clusula
OPTIMIZE FOR n ROWS ( no debe estar presente en la instruccin
la clusula ORDER BY ). DB2 dispone de esta clusula para forzar
un path de acceso que minimice el tiempo de respuesta para
recuperar las primeras filas. Esta opcin se usa tpicamente en
consultas on-line paginadas.
14) Hacer uso de clusula FOR READ ONLY en los cursores cuando
sea posible. Esto ayudar a un mejor manejo de locks sobre los datos
por parte del DB2 minimizando la contencin.
15) Evitar, en lo posible, excesiva complejidad en una clusula
WHERE. El filtrado de filas muchas veces ser mas eficiente si se
hace dentro del programa COBOL (clusula IF..). Recuerde una
mxima en programacin keep it simple.
16) Evitar, cuando sea posible, comparaciones de columnas de una
misma tabla en la clusula WHERE.
17)

No utilizar el operador LIKE en la clusula WHERE.1

18)

No utilizar el uso de negaciones en la clusula WHERE.

Directrices para los procesos batch

Rendimiento: Las aplicaciones se disearn y construirn de acuerdo a
los requisitos de uso de CPU, espacio en disco, flujo de E/S y tiempo
asociado a su ventana batch que se determinen como necesarios para su
usabilidad
Concurrencia: Las aplicaciones se deben disear de forma que sea
aceptable ejecutarlas concurrentemente con el sistema online o con
otras aplicaciones batch que necesiten acceder a los mismos datos. En
estos casos se debe prever la liberacin de bloqueos en el menor tiempo
posible. As mismo hay que buscar la cantidad de datos sobre la que se
impone el bloqueo para que sea la menor posible. Como consecuencia,
es necesario el uso de COMMIT, mediante el gestor de checkpoint, para
1

En caso excepcionales podr usarse LIKE ABCD..% pero NUNCA %ABCD..

____________________________________________________________________________________
Pg. 5 de 32

liberar los bloqueos tomados. Un anlisis del tipo de accesos que se

realizarn, unido a una estimacin de tiempos, indicar la frecuencia
con que deben producirse estos COMMIT. Si se quiere disminuir el
tiempo de bloqueo, la frecuencia deber ser mayor. Ante cualquier duda
a la hora de determinar la frecuencia de COMMIT de un proceso se
deber poner en contacto con el departamento especializado de bases
de datos. Ser necesario encontrar un punto intermedio para conseguir
el rendimiento y el nivel de concurrencia ptimo.
Propiedad de los Datos. Una BD pertenece a una sola aplicacin o
anagrama, proporcionando esta aplicacin los servicios de
actualizacin y consulta de datos. Otras aplicaciones usan estos
servicios (o los servicios de negocio que los incluyen) en vez de realizar
acceso directo a estos datos. La excepcin a esta regla son las
extracciones debidamente justificadas para consultas on-line en otras
plataformas o procesos batch sin actualizacin por motivos de
rendimiento
Batchs Rearrancables desde ultimo punto de control mediante el
uso de un gestor de checkpoint / restart. Los programas deben tener:
o Puntos de checkpoint (de frecuencia parametrizable).
o Lgica de rearranque que permita arrancar el proceso desde el
ltimo check point en caso de fallo.
Desacoplamiento de interfaces batch mediante el uso de ficheros
intermedios, no permitindose procesos que acceden en lectura y
escritura a BBDD de Aplicaciones distintas
Gestin de errores: las aplicaciones deben realizar una gestin de
errores rigurosa (separacin de errores tcnicos de errores aplicativos)
que permita fcilmente detectar el problema y diagnosticar su origen.
La arquitectura ASC proporciona los servicios necesarios para ello
(rutina de errores)
Como norma general, los batch masivos deben disearse de modo que no haya
tiempos de espera por acceso a datos y procurando que la utilizacin del
procesador sea lo ms eficiente posible. Esto se consigue fragmentando el
proceso en pasos que realizan exclusivamente acceso secuencial a los datos
(ej. Sequential prefetch del DB2), estos pasos van intercalados con pasos de
clasificacin (sort) intermedios

____________________________________________________________________________________
Pg. 6 de 32

Directrices referentes a SADs

Construir los SAD a partir de la plantilla proporcionada por la
arquitectura ASC
Mantener la lgica del SAD simple; lgicas ms complejas deben
trasladarse al SN (servicio de negocio)
Uso de protocolo de comunicaciones ASC:
o Las llamadas locales (el SAD llamado se ejecuta en el mismo
CICS que el programa llamador) deben realizarse mediante
CALL. Dichas llamadas deben realizarse empleando una
constante definida en la working storage section (WS) (p.ej:
CALL WCA-ASCK01CB); cada programa invocado tendr su
propia constante definida en la WS y llamada WCA-nombre
programa
o Las llamadas remotas (el SAD llamado se ejecuta en un CICS
diferente que el programa llamador) deben realizarse mediante
LINK (SIN SYSID NI TRANSID). Se prohbe realizar LINK con
SYNCONRETURN
IV.- Directrices para codificacin de JCLs
Consolidando la prctica adoptada en el desarrollo de FA LATAM, se exige
que los JCLs sean parametrizables en los siguientes elementos
JOBNAME (se incluir dentro del nombre una variable Ctrl-M para
indicar la sigla representativa del entorno, para desarrollo es D)
DB2OWNER (calificador o propietario de la DB)
DD: debe parametrizarse los dos primeros calificadores del archivo
fsico correspondiente al DD (uno de ellos INDICAR UN PREFIJO
GENERICO PARA TODOS LOS FICHEROS DE UN CIERTO
AMBIENTE). El detalle de este punto se ver en el documento de
Nomenclatura
PLAN DB2.
DB2 SUBSYSTEM
PARMETROS FTP
NOMBRES DE PDS de PARMLIB, INCLIB, LIBSYM
Para realizar la parametrizacin debe tenerse en cuenta:
____________________________________________________________________________________
Pg. 7 de 32

1. Se utilizar la sentencia
%%INCLIB <lib vars estticas> %%INCMEM <miembro con
variables>
para definir la librera y miembro donde se encuentran las variables de tipo
esttico (con valor ya determinado) contenidas en la seccin de job que sigue.
2. Para las variables de tipo dinmico, esto es, definidas en algn
momento por el usuario u otro proceso se utilizar:
%LIBSYM <lib vars dinmicas> %%MEMSYM <miembro con
variables>
Esta parametrizacin persigue :
Simplificar la explotacin del sistema
Facilitar la migracin del SW de un entorno a otro
Posibilitar la ejecucin paralela de varias instancias del mismo JCL
sobre el mismo LPAR, gestor Ctrl.-M y DB2 (esta es la casustica de
nuestros proyecto)
Sentencias prohibidas
Las sentencias siguientes no pueden usarse:
//<comando>
//CNTL
//ENDCNTL
//JOBLIB DD
//JOBCAT DD
//STEPCAT DD
/*$<comando>
/*NOTIFY
/*OUTPUT
/*PRIORITY
/*SIGNOFF
/*SIGNON
/*XEQ
Los siguiente parmetros por nombre son innecesarios y pueden no usarse.
BURST
CHARS
CKPTLINE
CKPTPAGE
CKPTSEC
____________________________________________________________________________________
Pg. 8 de 32

COMPACT
CONTROL
FLASH
FORMDEF
GROUPID
INDEX
LINDEX
LINECT
MODIFY
PAGEDEF
PIMSG
PRTY
PRMODE
THRESHLD
TRC
UCS

____________________________________________________________________________________
Pg. 9 de 32

2. Directrices y Recomendaciones
A continuacin se incluyen una serie de recomendaciones dirigidas a asegurar
el rendimiento de las aplicaciones.

____________________________________________________________________________________
Pg. 10 de 32

Introduccin
Los objetivos de este apartado son:

Proporcionar una serie de pautas de diseo del modelo fsico de datos y

de los procesos batch de facturacin para optimizar su rendimiento
Establecer normas y recomendaciones de programacin que apliquen
las pautas de diseo establecidas.

Gua de Diseo
Optimizacin del acceso a DB2
Las medidas que pueden tomarse para optimizar el acceso a DB2 son las
siguientes:

Es obligado disear el acceso a los datos de forma que se permita el uso

de los mecanismos de DB2 sequential prefetch, list prefetch, y
sequential detection (procesos mediante los cuales el DB2 anticipa las
solicitudes de pginas de datos y ejecuta el I/O para cargar la pgina de
datos antes de ser requerida por la aplicacin) para reducir el elapsed
time. Con esto se pretende minimizar el I/O que es quin consume el
grueso del tiempo empleado en la ejecucin de los procesos batch,
(entre un 60% y un 70% de promedio)
o Sequential Prefecth: DB2 selecciona en tiempo de BIND este tipo
de prefetch cuando se solicita un acceso a pginas de datos
(tanto de tablas como de ndices) de forma secuencial (salvo que
la invocacin sea por medio de mltiples SELECTs que
recuperan UNA sola fila). Este mecanismo exige que la tasa de
clustering del ndice empleado sea superior al 80%. Por esta
razn (adems de por los otros beneficios que reporta) es
importante que las estadsticas de DB2 estn actualizadas.
o List Prefetch: DB2 selecciona en tiempo de BIND este tipo de
prefetch cuando se solicita un acceso a un conjunto de pginas
de datos (tanto de tablas como de ndices), tanto si son contiguas
como si no, por medio de un ndice cuya tasa de clustering es

____________________________________________________________________________________
Pg. 11 de 32

inferior al 80%, por mltiples ndices o para el acceso de datos en

la tabla inner de un join. Por esta razn (adems de por los
otros beneficios que reporta) es importante que las estadsticas de
DB2 estn actualizadas.
o Sequential detection: DB2 puede seleccionar este tipo de acceso
en tiempo de ejecucin, en caso de que no se haya activado el
sequential prefetch en tiempo de BIND (por ejemplo, si las
estadsticas no estaban actualizadas), y se compruebe un acceso
secuencial de la informacin desde el programa. Es importante
indicar que si la sentencia SQL condicionada a la integridad
referencial, este mecanismo de prefecth no se activar.

Emplear en las sentencias SQL predicados que sean de tipo stage 12,
evitando en la medida de lo posible predicados de tipo stage 2, ya que
el coste de procesamiento de los predicados stage 1 para el
optimizador del DB2 es significativamente menor que para los
predicados stage 2.
Acceso exclusivo por ndice (en el EXPLAIN esto se ve como
AACESSTYPE=I MATCHING COLUMNS >0). En las sentencias
SQL tener en cuenta que cuando toda la informacin que se precisa est
contenida en el ndice, el DB2 no precisa leer pginas de datos, y que
por lo tanto el tiempo de acceso y uso de I/O se disminuye.
Cuando se precise realizar un scan de una tabla, utilizar su ndice
cluster, ya que se disminuye la I/O requerida para recuperar la
informacin (la probabilidad de encontrar toda la informacin buscada
en la misma pgina, o en nmero menor de pginas aumenta cuando la
bsqueda es por ndice cluster).
Cuando se trate de tablas pequeas (tablas con menos de 1000 pginas
de datos), es recomendable emplear tablespaces segmentados. De esta
forma el scan de tabla se efecta nicamente sobre las filas
correspondientes a la tabla seleccionada y no para todas las tablas
almacenadas en el tablespace.
Cuando se utilicen sentencias SQL con joins anidadas (por cada
ejecucin de la tabla exterior del join se ejecuta una consulta sobre la
tabla interior), emplear como predicado en la clusula del join aquel que
proporcione el acceso ms eficaz para la tabla anidada.

El los manuales de DB2 de IBM puede hallarse una definicin de que predicados SQL son stage1; grosso
modo, un predicado stage1 es aquel que puede resolverse mediante ndices existentes en la DB.
____________________________________________________________________________________
Pg. 12 de 32

Aumento del paralelismo

Uno de los recursos que mejores resultados ofrecen para disminuir el
tiempo de ejecucin de la ventana batch (reduccin del elapsed time), es
aumentar el grado de paralelismo de los jobs en ejecucin, tanto si se trata
de jobs que ejecutan funciones distintas, como si se trata de jobs que
abordan la misma funcionalidad en paralelo.
El aumento del paralelismo en el sistema pasa por la resolucin en el
diseo de los siguientes problemas:

Disminucin de las dependencias funcionales que imponen una

ejecucin en serie de los procesos.
Identificar aquellas fuentes de datos que deben estar disponibles
antes de la ejecucin de un determinado proceso, y disear el sistema
para que estas fuentes de datos estn disponibles lo antes posible.
Para que la ejecucin en paralelo de procesos sea factible es preciso
dotar a los procesos de capacidad de recuperacin ante fallos, evitando
as que el fallo en un determinado job que se ejecuta en paralelo con
otros pueda implicar la necesidad de deshacer el trabajo realizado por el
resto de jobs en paralelo, o introducir inconsistencias en los datos.
Reducir la probabilidad de contencin en el acceso a recursos,
especialmente en el uso de DASD y CPU. Una forma de reducir la
contencin en el acceso a DASD, especialmente cuando se trate de un
acceso a tablas grandes, es mediante el particionado3 de la tabla. Hay
que tener en consideracin que al particionar una tabla no ser posible
actualizar el ndice asociado a la particin (como regla general se
recomienda particionar las tablas que empleen ms de 100.000 pginas
de datos).
Los procesos que actualizan e insertan informacin en tablas DB2
pueden ser diseados atendiendo a las siguientes modalidades:
procesamiento en serie con inserciones y actualizaciones aleatorias,
procesamiento en serie con inserciones y actualizaciones secuenciales, y
procesamiento paralelo con inserciones y actualizaciones.

A continuacin se indican las situaciones en las que cada una de estas

tcnicas pueden dar mejores resultados.

Una tabla particionada es aquella que se almacena en varios storage groups (esto se puede definir el crear la
tabla)
____________________________________________________________________________________
Pg. 13 de 32

Procesamiento en serie con inserciones y actualizaciones

aleatorias

El nmero de pginas de datos que son actualizadas o

modificadas es bajo.

El acceso a las tablas debe proporcionarse online.

Las tablas son de un volumen medio bajo.

No se trata de un proceso en el camino crtico de la

ventana batch.

Procesamiento en serie con inserciones y actualizaciones

secuenciales

El nmero de pginas de datos que son actualizadas o

modificadas es medio.

El acceso a las tablas debe proporcionarse online.

Las tablas son de un volumen medio bajo.

No se trata de un proceso en el camino crtico de la

ventana batch.

Procesamiento paralelo con inserciones y actualizaciones

(figura 1):

El tamao de las tablas es grande

El proceso se encuentra dentro del camino crtico de la

ventana batch

El acceso a las tablas debe proporcionarse online

El nmero de pginas de datos que son actualizadas o

modificadas es medio

____________________________________________________________________________________
Pg. 14 de 32

Inserts,
Upates

Split input into 4

batches

Sort into processing

sequence

Sort into processing

sequence

Sort into processing

sequence

Sort into processing

sequence

Sorted
inserts,
updates

Sorted
inserts,
updates

Sorted
inserts,
updates

Sorted
inserts,
updates

Cobol Insert/ update

Processing
Detect duplicates, do
duplicate processing on
inputs

Cobol Insert/ update

Processing
Detect duplicates, do
duplicate processing on
inputs

Cobol Insert/ update

Processing
Detect duplicates, do
duplicate processing on
inputs

Cobol Insert/ update

Processing
Detect duplicates, do
duplicate processing on
inputs

Database

Figura 1. Ejemplo de procesamiento en paralelo para inserciones y actualizaciones

____________________________________________________________________________________
Pg. 15 de 32

Descargas a ficheros secuenciales

El costo de acceso a ficheros secuenciales, en trminos de CPU, es menor
que para el acceso a DB2 (el consumo de CPU del acceso a fichero
secuencial y DB2 mantiene una relacin de 1:8).
Este ahorro de CPU en el acceso a la informacin puede compensar el
costo de descarga en situaciones en las que se traten datos temporales o de
paso, y en los que el nmero de inserts, updates y deletes sobre los datos
sea elevado (de esta forma se evita la actualizacin de la pgina de ndices,
y se disminuye de forma considerable el I/O requerido). A continuacin se
mencionan algunas recomendaciones para el diseo de este tipo de
procesos:

En caso de realizar el volcado al fichero secuencial por proceso (en

lugar de emplear un utilitario de DB2), el proceso debe ser diseado
siguiendo las siguientes reglas:
o

Escribir un registro actualizado para reflejar la nueva imagen

de la fila en vez de hacer un UPDATE.

Omitir los registros que van a ser borrados en vez de hacer

DELETE.

Escribir un nuevo registro en vez de hacer INSERT.

Escribir un registro para cada fila existente que no ha

cambiado.

Cuando se empleen utilitarios para la descarga de la tabla, considerar

el uso del High Performance Unload (disponible en DB2 v7)
Los registros deben ser insertados en el fichero secuencial en el
mismo orden empleado por el ndice cluster de la tabla principal del
proceso que va a procesar el fichero (ver apartado de optimizacin del
acceso a DB2).
En caso de que se emplee el utilitario de carga de IBM, se debe
ordenar previamente el fichero en el orden del ndice cluster de la tabla
destino (en caso de que difiera del orden del fichero secuencial), y una
vez ejecutado el procedimiento de carga se debe hacer una image
copy de la informacin y ejecutar RUNSTATS para actualizar las
estadsticas empleadas por el optimizador del DB2 para el acceso a la
tabla.

____________________________________________________________________________________
Pg. 16 de 32

Los beneficios de procesar la informacin intermedia o temporal por

medio de ficheros secuenciales son, adems de obtener una velocidad
de acceso mayor al recurso, eliminar la necesidad de generar logs en
DB2 por cada modificacin (ahorro de I/O y DASD), evitar la
necesidad de commit, obtener una tabla organizada sin precisar ejecutar
el job de re-organizacin, y, en caso de que se particione el tablespace,
permitir que el proceso sea realizado en paralelo (ver apartado anterior).
En cualquier caso, e independientemente de las reglas generales
indicadas en los puntos anteriores, es necesario para garantizar una
respuesta ptima del proceso, realizar un anlisis emprico del mismo, y
en su defecto emplear herramientas de estimacin de respuesta como
por ejemplo Explain.

____________________________________________________________________________________
Pg. 17 de 32

Inserts,
Upates

Database

Sort into processing

sequence

Sort into processing

sequence

Sorted
inserts,
updates

Cobol Merge Process

Detect duplicates, do
duplicate processing

Sorted Table
records

Sort into clustering key

sequence

Load into table using Load

utility

Figure 2. Ejemplo de descarga de informacin a ficheros secuenciales.

____________________________________________________________________________________
Pg. 18 de 32

Gestin de Checkpoint/Restart
El uso de checkpoint restart (realizado mediante el uso de la ASSCC) es
recomendado en las siguientes situaciones:

Cuando hay varios jobs actualizado o leyendo tablas, debe incluirse

un checkpoint tras procesar un determinado nmero de registros (que
depender del tamao de cada registro).
Emplear checkpoint restart cuando el uso de locks sea intensivo
(los locks son un recurso finito para el gestor de DB2).
Para evitar perder el trabajo realizado en aquellos jobs de larga
duracin (cuando un job falla, el coste en que se incurre se desglosa en
el coste de rollback y el de repeticin de la ejecucin del job desde el
principio).
Los intervalos de checkpoint se fijarn dependiendo de cada
situacin. Cuando haya carga de trabajo online o procesamiento en
paralelo, los intervalos de checkpoint deben ser ms frecuentes. Si se
trata de procesos batch que se ejecutan de forma independiente, sin
coexistir con cargas de trabajo online, los intervalos de chekpoint
pueden ampliarse. La mejor forma de determinar el intervalo de
checkpoint es por medio de pruebas empricas en cada instalacin.
Debe tenerse en cuenta que el uso de checkpoint consume recursos,
razn por la cual su uso excesivo debe ser evitado.

____________________________________________________________________________________
Pg. 19 de 32

Aumento de la eficacia operativa

Con frecuencia hay retrasos en la ejecucin de la ventana batch,
especialmente cuando los procesos no estn completamente automatizados.
Los retrasos que se pueden evitar por medio de la automatizacin de los
procesos son los siguientes:

Retrasos introducidos entre la finalizacin de un job y el inicio de

otro job dependiente, debidos a la necesidad de comprobar la correcta
finalizacin del primero, y la consiguiente lanzamiento manual del
mismo.
Retrasos debidos a la necesidad de configurar manualmente un JCL
antes de su lanzamiento.
Retrasos en el lanzamiento manual de JCL cuando el nmero de JCL
que debe lanzarse es alto.
Retrasos en la deteccin de jobs con problemas, y que tienen
establecida una dependencia con otros jobs.

Las ventajas derivadas de aumentar el grado de automatizacin en la

ejecucin de procesos batch se multiplica cuando el nmero de jobs y los
volmenes de datos que se procesan aumentan.
Administracin de la base de datos
Es preciso definir las estrategias de administracin del modelo de datos que
faciliten un rendimiento ptimo de los procesos que hagan uso de l. Las
actividades que deben incluirse dentro de la estrategia de administracin
son las siguientes:

Actualizacin de catlogo del DB2. Definir un procedimiento para la

actualizacin regular de los catlogos DB2, de tal forma que el
optimizador del DB2 disponga siempre de la mejor informacin para
determinar la mejor ruta de acceso a los datos. Este comportamiento del
optimizador del DB2 debe ser tenido en cuenta a la hora de proyectar
los resultados esperados para el sistema en produccin, a partir de los
resultados obtenidos en un ambiente de test (el optimizador puede
aplicar rutas de acceso distintas en uno y otro entorno, y por lo tanto
ofrecer tiempos de respuesta distintos).

____________________________________________________________________________________
Pg. 20 de 32

Consideraciones del diseo fsico del modelo de datos

A la hora de transformar el modelo lgico de datos en un modelo fsico de
datos se deben tener en cuenta las siguientes consideraciones:

Para optimizar los recursos de DASD es preciso tener en consideracin

que el tamao de cada una de las pginas puede ser definido bien de
4KB o de 32KB, y que el mximo nmero de filas por cada tabla es de
255 (valor por defecto). Por ejemplo, en caso de que se utilicen pginas
de 4KB, y que el mximo de filas por pgina se fije en 127, cualquier
fila con un tamao inferior a 24 bytes desperdiciar 4 bytes por fila (4 *
127 bytes por pgina).
Aquellas tablas que sufran actualizaciones e inserciones frecuentes se
beneficiarn del espacio libre que pudiera existir en la tabla
(disminucin en bloqueos para ndices de tipo 1, disminucin del split
de pgina). Este beneficio debe ser contrastado con el aumento en I/O
que se va a precisar para la lectura de informacin (se leern ms
pginas) y con el desperdicio de espacio en DASD.
Evitar el uso de columnas de tamao variable (VARCHAR, etc). Los
algoritmos de acceso de DB2 optimizan el acceso empleando columnas
de tamao fijo. Este tipo de columnas podrn ser empleadas nicamente
si los ahorros de espacio en disco son significativos.
Situar las columnas de tamao variable y las que se actualicen al final de
la tabla. De esta forma se minimiza el tamao del log de modificaciones
del DB2.
Des-normalizacin del modelo lgico de datos. Es posible disminuir
significativamente el nmero de accesos a DB2 y, por lo tanto los
tiempos de I/O consumidos, por medio de la des-normalizacin del
modelo de datos. El coste que introduce la des-normalizacin es el de
aumentar la dificultad para mantener la integridad referencial del
modelo, razn por la cual debe acotarse la prctica de des-normalizar a
aquellas situaciones en las que suponga la disminucin del nmero de
accesos al DB2 (que puede medirse por la disminucin del nmero de
joins utilizados).
Incentivar el uso de tablas grandes en lugar de otras alternativas como el
split horizontal para la gestin de grandes volmenes de informacin
(hasta 1 TB). El uso de este tipo de tablas simplifica las instrucciones
SQL, al tiempo que facilita (cuando las tablas son particionadas; hasta

____________________________________________________________________________________
Pg. 21 de 32

254 particiones en una tabla) la parelizacin de los procesos batch que

acten sobre ellas.

Particionar tablas grandes, para reducir el impacto en la ejecucin de

utilitarios (de esta forma es posible la ejecucin del utilitario particin
por particin).
Para reducir el espacio de requerido de DASD (o en aquellos casos en
los que se est cerca del lmite de 1 TB de capacidad mxima de una
tabla) puede emplearse la opcin de comprimir los datos. Esta opcin
implica el empleo de 8 bytes ms por cada fila, pero pueden alcanzarse
compresiones de entre 1:2 y 1:8. El empleo de este overhead no hace
considerable esta opcin, desde un punto de vista del ahorro de espacio
en DASD, cuando los tamaos de las filas sean pequeos. En trminos
de rendimiento, la compresin de datos implica una disminucin en el
I/O (se precisa la carga de menos pginas de datos para acceder a la
misma cantidad de informacin), pero acarrea un coste adicional en uso
de CPU (proceso de compresin y descompresin). Por otro lado, la
mencionada disminucin en I/O solo se hace palpable en accesos
secuenciales a la informacin.

Monitorizacin constante del rendimiento

Durante todas las fases del diseo (DTOC y DTD) y construccin es
preciso tener una medida del rendimiento de los procesos que se diseen e
iniciar las actividades de Capacity Planning siguiendo la metodologa
correspondiente.

Normas y Recomendaciones de programacin

En este apartado se recogen las normas y recomendaciones de diseo de
procesos batch con el fin de evitar los errores ms comunes de diseo y
construccin, en particular enfocados al desarrollo de procesos batch masivos.
Diseo Procesos Batch

Ordenacin de ficheros de entrada al proceso en funcin del ndice

cluster de la tabla principal a la que se accede, de forma que se utilice el
sequential PREFETCH de DB2 y se optimice el rendimiento.
En aquellos casos en los que el acceso a una de las Bases de Datos
sea muy costoso: acceder de forma repetitiva a varias tablas para

____________________________________________________________________________________
Pg. 22 de 32

obtener datos relacionados (p.e. acceso a cliente-cuenta-producto

comercial-productos servicios por cada CDR), se analizar la
posibilidad de hacer una rplica de la Base de Datos, con la informacin
desnormalizada, tal y como se requiere por el mdulo solicitante.

Para inserciones masivas de registros en tablas DB2 generar archivos

planos y cargas la tabla con utilidades LOAD
Utilizar el mnimo nmero de cursores, aprovechando descargas
existentes de las bases de datos.
Aprovechar la informacin que se haya recogido en procesos o
programas que se hayan ejecutado con anterioridad. Se puede
almacenar la informacin en archivos temporales. Los archivos
temporales se debern borrar una vez haya finalizado su uso.
Para accesos repetitivos a tablas con pocas ocurrencias (algunas
tablas de parametrizacin de Catlogos, etc) se estudiar la posibilidad
de realizar una carga de la tabla en tablas internas de trabajo.
Cuando definamos copys de archivo, debemos dejar un FILLER que
permita cambios a futuro (a modo general, este puede ser de 50
posiciones)

Accesos a DB2.

Cuando se realice joins entre tablas, especificar la condicin en

primer trmino usando solo columnas de la tablas. Sean la tablas:
Table1 C1, C2, Gender,BeginDate, EndDate (C1 es primary key)
Table2 C1, C2, FKC1 (C1 es primary key, FKC1 es foreign key contra
Table1)
1. Correcto:
SELECT A.C1, B.C2
FROM Table1 A, Table2 B
WHERE A.C1 = B.FKC1
AND A.C1 = :DG998-C1
2. Incorrecto:
SELECT A.C1, B.C2
FROM Table1 A, Table2 B
WHERE A.C1 = :HostVar -C1 (No hay condiciones de join, solo
variables host)
AND B.FKC1 = : HostVar -C1

____________________________________________________________________________________
Pg. 23 de 32

Si existen variables host adicionales que deben matchear columnas

primary key, estas deben especificarse a continuacin . Posteriormente
deben especificarse los predicados en orden de mxima discriminacin
(i.e: especificar criterios de seleccin que retornan el mnimo de filas) .
P.ej: si debemos codificar dos predicados adicionales, Gender y
Birthday, especificaramos Birthdate

Si podemos limitar las columnas recuperadas en el SELECT a

aquellas pertenecientes a un ndice se consigue ptimo rendimiento ya
que no se leen pginas de datos (i.e: solo se leen pginas del ndice)
En la medida de lo posible usar columnas de una sola tabla en los
ORDER BY
Siempre codificar la lista de columnas en los INSERT
Los cursores debe definirse con WITH HOLD ya que los procesos
deben poseer gestin de COMMIT (gestor de checkpoint/restart)
En las sentencias SQL, usar las columnas en el mismo orden en que
se encuentran definidas en la tabla (ya sea para SELECT, INSERT u
UPDATE).
No seleccionar columnas que no se usen en el programa.
Utilizar columnas ndice en el WHERE y ORDER BY (si aplica) en
el mismo orden que estn definidas en el ndice, sin dejar de utilizar
columnas intermedias de ste.
Si el programa tiene sentencias DB2 y contiene UPDATE, DELETE
o INSERT el programa debe realizar COMMIT (o bien utilizar rutinas
que lo realicen). Tendremos en cuenta el tamao de la tabla para que lo
anterior sea o no error. Ser necesario el COMMIT en tablas de gran
tamao. Como dato orientativo consideraremos que una tabla es grande
cuando tenga ms de 5000 filas y el programa sea de tipo on-line o
batch unitario, o cuando tenga ms de 10000 filas y el programa sea de
tipo batch masivo.
Las sentencias FETCH de un cursor deben contemplar las mismas
columnas que se estn recuperando en la SELECT del DECLARE
CURSOR y en el mismo orden.
Los cursores deben cerrarse de forma explcita al finalizar el
programa.

____________________________________________________________________________________
Pg. 24 de 32

La clusula FOR UPDATE OF de un cursor no debe contener ms

columnas de las que actualiza durante el proceso la sentencia
UPDATE...WHERE CURRENT OF.
Las sentencias SELECT y FETCH no deben recuperar columnas de
las que ya conocemos su valor por estar condicionadas por igual en la
clusula WHERE. Slo se podrn recuperar cuando la sintaxis de SQL
lo requiera, es decir en el caso de realizar ORDER BY por ellas o para
verificar existencia.
En las actualizaciones mediante DELETE FROM...WHERE
CURRENT OF slo es necesario declarar una columna, que no sea
ndice, en la clusula FOR UPDATE del DECLARE CURSOR.
Las sentencias INCLUDES de tablas que no se utilicen en el
programa deben eliminarse.
Se debern evitar las sentencias SELECTO COUNT(), MAX(),
MIN(), etc. En caso que fueran necesarias, las sentencias SQL SELECT
MAX()/MIN()/AVG()/SUM() deben codificarse contemplando el
indicador de nulos. Es necesario analizar el campo indicador de nulos
cuando SQLCODE es igual a cero, ya que valores negativos del mismo
indican que ninguna ocurrencia cumple la condicin.
Es aconsejable eliminar todas las sentencias SQL que no se usen en
el programa (aquellas que estn comentadas).
Segn las sentencia SQL que se utilice es necesario controlar el
SQLCODE del siguiente modo:
SELECT-FETCH-UPDATE-DELETE
OPEN-CLOSE
INSERT
UPDATE/DELETE WHERE CURRENT OFF
SELECT AVG/MAX/MIN
SELECT que pueda recuperar
ms de una fila

0
0
0
0
0

+100

-811

-803

100

SQLCODES :
100
0

Ninguna ocurrencia cumple la condicin

Una nica ocurrencia cumple la condicin

____________________________________________________________________________________
Pg. 25 de 32

-811

Varias ocurrencias cumplen la condicin

-803

Insercin o actualizacin con clave nica duplicada

Las sentencias SQL que tengan una codificacin idntica deben ser
codificadas en un prrafo aparte en una sola.
Las sentencias UPDATE que actualicen columnas de una entidad
que no han sido modificadas en el proceso (i.e. dejan esa columna con
el valor inicial) del programa deben ser eliminadas. Si la actualizacin
se lleva a cabo a travs de un cursor y no existe ninguna otra
actualizacin mediante este, debe ser eliminada la clusula FOR
UPDATE del mismo.
Las actualizaciones de las columnas de un ndice cluster deben
realizarse mediante DELETE-INSERT y no UPDATE. De esta manera
nos aseguramos que estamos actuando sobre una fila cada vez.

Se recomienda no utilizar SELECT *

No usar LIKE.

No seleccionar columnas de valor constante que sean parte del

criterio de seleccin.
El acceso a la entidad si bien se hace mediante un ndice, usa una
parte del mismo con lo que se discriminan pocos valores y dicho acceso
es costoso. Podemos observar este error fijndonos en las columnas
MATCHCOL y COLCOUNT del EXPLAIN de la sentencia.
Cuando una rutina DB2 detecta un SQLCODE de error, ha de
devolver inmediatamente el control al programa principal, informando
del suceso correctamente.
Todos los atributos de una entidad que se necesiten a lo largo de un
programa deben ser obtenidos mediante un nico acceso. Para ello
evitaremos SELECT repetidas pero con distintas columnas recuperadas
y las mismas columnas en el WHERE.
Las actualizaciones de entidades que pertenecen a otras aplicaciones
deben realizarse mediante un programa o rutina proporcionado por la
aplicacin propietaria de la entidad. Para ello nos aseguraremos que el
cdigo de aplicacin del programa y de las tablas con las que trabaja es
el mismo.

____________________________________________________________________________________
Pg. 26 de 32

Se obtiene mejor rendimiento de los procesos BATCH si se

utilizan dos o mas programas y se ordenan los ficheros de entrada
por los campos del ndice cluster de las entidades a las que se
acceden, antes de ejecutar dichos programas.
El SQLCODE debe controlarse inmediatamente detrs de cada
instruccin SQL.
No es aconsejable utilizar sentencias DB2 anidadas
(SUBSELECT...).
Se recomienda revisar el acceso a las entidades referenciadas cuando
se obligue al DB2 a realizar un SORT.
Se recomienda sustituir el CURSOR por una SELECT ya que solo se
recupera una fila.
La actualizacin mediante la sentencia DELETE o UPDATE sobre la
entidad referenciada puede estar actuando sobre ms de una fila.
Se recomienda estudiar la posibilidad de incluir las primeras
columnas del ndice en la clusula where para optimizar el acceso.
Se recomienda sustituir las condiciones en sentencias SQL del tipo
A>B OR A=B por A>=B del mismo modo con el caso de <.
El orden de preferencia en operadores de comparacin es:
a) Igualdades.
b) Rangos ( >,>=,>,<=, BETWEEN) y NOT NULL
c) El resto.

No utilizar = ni <> en el WHERE de la sentencia.

Utilizar primero las sentencias AND y al final OR e IN.

No deben utilizarse expresiones aritmticas ni en la clusula

SELECT, ni en la WHERE de sentencias SQL.
La seleccin de filas recuperadas por un cursor debe realizarse
siempre que sea posible en la clusula WHERE del DECLARE
CURSOR y no durante el proceso del programa.
Se recomienda eliminar la clusula FOR UPDATE del DECLARE
CURSOR ya que no existe ninguna sentencia UPDATE... WHERE
CURRENT OF.
Para verificar la existencia de una fila mediante SELECT, slo deben
seleccionarse columnas del ndice por el que se est accediendo.

____________________________________________________________________________________
Pg. 27 de 32

Las sentencias SELECT/FETCH utilizadas para verificar la

existencia o no de una fila para su posterior actualizacin
UPDATE/DELETE/INSERT deben ser eliminadas del cdigo del
programa.
Los valores incluidos en la lista de la clusula IN deben ir separados
entre si por al menos una coma y un blanco.
Todas las actualizaciones o modificaciones de una fila que requieran
lectura previa deben realizarse mediante un cursor FOR UPDATE y la
actualizacin con WHERE CURRENT OF.
Las sentencias SELECT/FETCH utilizadas para verificar la
existencia de filas que cumplan la condicin de bsqueda para su
posterior lectura, deben ser eliminadas y sustituidas por el primer
acceso para recuperar datos.
Los programas que no contengan accesos SQL no deben incluir la
SQLCA.
El acceso mediante CURSOR puede ser sustituido por una SELECT,
dado que se estn utilizando campos del ndice NICO condicionados
por igual y relacionados con el operador lgico AND. Se recuperar una
SOLA FILA funcin que realiza la sentencia SELECT, no siendo
necesaria la utilizacin de un cursor.
El acceso a la entidad referenciada lee todas las pginas de datos.
Este hecho se refleja en la columna ACTY = R del EXPLAIN.
Tendremos en cuenta el tamao de la tabla.
Todos los accesos a base de datos debern estar soportados por
acceso por ndice (bien cluster u otro).
El orden de las variables de las sentencias ORDER BY debe ser el
mismo que el orden de las variables de los ndices.
No se deber utilizar SQL Dinmico.
Todos los accesos de actualizacin a la base de datos de INSERT y
de UPDATE debern registrar el timestamp de modificacin y el
usuario que lo realizo. En el caso de procesos batch el usuario de
modificacin es el propio programa.
La gestin de cursores principales de los programas deber
implantarse a travs de esqueletos y nunca de forma independiente.

____________________________________________________________________________________
Pg. 28 de 32

No se controlar lgica de negocio a travs de errores SQL. Salvo

casos debidamente justificados por motivos de simplicidad o
rendimiento.
Los errores de SQL no provocarn anomalas. En su lugar generarn
informacin de salida en la salida estndar del programa.
Todas las sentencias SQL debern estar debidamente identificadas a
travs de una numeracin (u otro sistema) de forma que cuando
aparezca un error SQL pueda ser etiquetado adecuadamente e
identificada la sentencia que provoco el error.

Variables HOST
En cualquier sentencia SQL, las variables SQL utilizadas deben ser las
definidas en la DCLGEN , si no se puede, utilizar variables definidas en
working con el mismo formato que el generado para la columna afectada
en la DCLGEN. Esto se debe a que el DB2 trabaja de forma ms ptima
cuando las comparaciones las realiza sobre campos de igual definicin,
cuando esto no se cumple, el DB2 se ve forzado a realizar conversiones
constantemente y de forma innecesaria. Si, adems, la columna forma
parte de un ndice, puede que el DB2 no utilice dicho ndice en el acceso;
este es el caso de comparaciones numricas de distinta precisin, as como
alfanumricas donde la variable host es ms larga que el atributo a
comparar.
Programacin COBOL.

No utilizar las sentencias GOTO salvo las implementadas en

Bloques de programa estndar al sistema.

No dejar cdigo muerto.

Evitar el uso de DISPLAY al SPOOL.

Inicializar variables que tengan un dato constante durante todo el

proceso con VALUE desde su definicin.
En expresiones aritmticas poner las constantes primero o agruparlas
entre parntesis.
Correcta definicin de variables aritmticas:

USAGE BINARY. Para operaciones aritmticas con menos de

ocho dgitos, al declarar la variable ponerle signo y un mximo de 8
dgitos.

____________________________________________________________________________________
Pg. 29 de 32

COMP-3. Para clculos mayores a 8 dgitos, se debe declarar con

signo y en longitudes impares, es recomendable no exceder 15
dgitos de longitud total (enteros + decimales).

Evitar operaciones aritmticas con variables de diferente tipo.

Asegurarse de nunca dividir entre cero.

Validar y controlar cdigos de retorno al usar archivos (OPEN,

READ, WRITE, CLOSE).
Los nombres de las variables seguirn una determinada
nomenclatura. Se diferenciarn entre variables que referencien a
campos de la base de datos de variables de otro tipo. Debera quedar
claro solo con el nombre de la variable si se refiere a una columna de
una tabla y a que tabla y columna se refiere.
Todos los procesos se debern desarrollar tomando como punto de
partida alguno de los esqueletos estndar existentes.
No debern existir archivos de programa de mas de un nmero
determinado de lneas (a definir mas adelante). Cuando por la
complejidad de la lgica de negocio sean necesarios programas de mas
de este nmero de lneas se deber estructurar adecuadamente en rutinas
y copys.
No utilizar PERFORM que no regresen al control de origen.
Las llamadas a PERFORM debern seguir una nomenclatura
estndar.
El ciclo de COMMIT deber poder parametrizarse al arrancar el
proceso.
Debern evitarse ciclos de COMMIT demasiado largos que bloqueen
la concurrencia de otros procesos.
Las inserciones masivas en la base de datos debern realizarse a
travs de utilidades de carga en la base de datos.
Reglas de indentacin estndares a todos los programas (a
especificar mas adelante).
Estndares de documentacin del cdigo. Por ejemplo: Todo
PERFORM deber tener antes de su definicin un prrafo de
comentario que indique su objetivo.

____________________________________________________________________________________
Pg. 30 de 32

Todo programa deber tener en el primer nivel del cdigo tres

llamadas a los PERFORM de inicio, proceso y final. (siempre que se
usen esqueletos, esto ser as)
La inicializacin de variables se realizar ntegramente en el
PERFORM de inicio. Este prrafo no deber ser de nuevo invocado
desde los PERFORM de proceso y final.
El PERFORM de final deber controlar la finalizacin ordenada del
programa y deber poder ser llamado desde cualquier punto de la lgica
de programa provocando siempre un ROLLBACK de la lgica de
negocio pendiente de COMMIT y la salida del programa.
El PERFORM de proceso deber controlar la finalizacin de todas
las transacciones que dentro de el se abran (deber realizar el commit de
todas las transacciones de negocio).
Los programas que controlen transaccionalidad debern tener todos
una estrategia de rearranque. Esta estrategia podr tener varias
orientaciones, bien a travs de estados de los registros, bien a travs de
rutinas de control de rearranque para ficheros de texto, u otras que se
definan y que en cualquier caso debern estar estandarizadas.
La estrategia de rearranque deber estar documentada en un prrafo
de comentarios al inicio del programa.
Generar por Display o Archivo Plano estadsticas de control del
programa.
A la hora de realizar el diseo se deber contemplar la
posibilidad de gestionar parmetros de entrada al programa a
travs de CONTROLM.

Errores comunes
Adems de estas recomendaciones, se considerarn como errores los
siguientes supuestos:
1. Si aparecen 2 o ms sentencias de OPEN o CLOSE de ficheros
seguidos (podemos encontrar OPEN y CLOSE de ficheros y
cursores).
2. Si aparecen sentencias OPEN sin su correspondiente CLOSE.
3. Si aparecen sentencias READ no seguidas de INTO.
____________________________________________________________________________________
Pg. 31 de 32

4. Si aparecen sentencias WRITE no seguidas de FROM.

5. Despus de cada operacin sobre ficheros (OPEN, CLOSE,
WRITE, READ) se debe controlar el FILE STATUS.
6. En caso de que se utilice:
SELECT

Nombre_A ASSIGN TO Nombre_B

MOVE

Nombre_A TO ST-NOMBRE-FICHERO

7. No se considera error Nombre_A no ha sido asignado todava. La

manera correcta de realizar la operacin anterior sera:
SELECT

Nombre A ASSIGN TO Nombre_B

MOVE

Nombre_B TO ST-NOMBRE-FICHERO

8. El nmero de lneas de comentario que aparecen en los

programas han de ser al menos el 10% de las lneas de cdigo. De
esta manera el mantenimiento de los programas por otras
personas diferentes al autor ser ms sencillo.
9. Si el nmero de IF es diferente que el nmero de END-IF.
10.El programa no contempla la posibilidad de dividir por cero.
Debe comprobarse que el denominador no es cero mediante una
sentencia IF antes de realizar la divisin.
11.Debe controlarse la opcin AT END en la instruccin SEARCH.

____________________________________________________________________________________
Pg. 32 de 32