Guia Antipatrones General

GUA DE ANTIPATRONES
Y ALTERNATIVAS.
__________________________________________________________________________________________
Fecha edicin: 06/11/2012
1/125
GUIA ANTIPATRONES GENERAL (2).doc
Contenido
Control de versiones. .............................................................................................................................. 4
Introduccin. ........................................................................................................................................... 4
COBOL...................................................................................................................................................... 6
Tipos de datos. .................................................................................................................................... 6
Bsqueda en tablas WORKING............................................................................................................ 8
Uso de OCCURS DEPENDING ON......................................................................................................... 9
Ubicacin de las sentencias............................................................................................................... 10
Sentencias muy consumidoras.......................................................................................................... 11
READ/WRITE...................................................................................................................................... 16
Ficheros de longitud fija. ................................................................................................................... 17
Ficheros de longitud variable ............................................................................................................ 18
Enfrentamiento de ficheros .............................................................................................................. 19
Uso inadecuado de rutinas invocadas............................................................................................... 23
Rearranques. Uso inadecuado de COMMIT...................................................................................... 24
Parmetros de entorno de ejecucin................................................................................................ 25
SQL......................................................................................................................................................... 26
JCL.......................................................................................................................................................... 33
Nmero de pasos .............................................................................................................................. 33
Descarga de BBDD ............................................................................................................................. 33
Utilidades obsoletas .......................................................................................................................... 35
Dimensionamiento de ficheros. ........................................................................................................ 36
Ficheros temporales.......................................................................................................................... 37
__________________________________________________________________________________________
2/125
Ficheros externos. ............................................................................................................................. 38

Duplicidad de accesos en el JCL......................................................................................................... 42
SORT .................................................................................................................................................. 44
Identificacin y tratamiento en JCL................................................................................................... 47
Contenciones..................................................................................................................................... 48
Tratamiento de cancelaciones batch. ............................................................................................... 49
SERVICIOS .............................................................................................................................................. 51
MODELO DE DATOS............................................................................................................................... 54
NCAR ................................................................................................................................................... 75
BOINAS VERDES..................................................................................................................................... 93
Referencias.......................................................................................................................................... 125
__________________________________________________________________________________________
3/125
Control de versiones.
Versin
Autor
Fecha
DESCRIPCIN: del cambio
1.0
Arquitectura Calidad Sistemas
22.10.2012
Versin inicial
2.0
Arquitectura Calidad Sistemas
31.10.2012
Inclusin de tratamiento de
cancelaciones y rearranques.
Introduccin.
Este documento es una recopilacin de los errores ms comunes detectados en la
programacin, en el diseo de procesos y en el modelado de datos, junto con sus
alternativas orientadas a optimizar el consumo de recursos, la fiabilidad y la mantenibilidad
del software.
La razn de este documento es evitar en la fase temprana de diseo un conjunto de
prcticas que conducen a rendimientos deficientes del proceso, frecuentemente no
detectable en la fase de pruebas debido al inferior volumen de datos respecto a Produccin.
En el captulo Referencias se indican los documentos originales que amplan la informacin
aqu descrita.
La Gua de Antipatrones se presenta en formato de fichas:
CDIGO: XXXXXX
TIPO: XXXXXX
DESCRIPCIN:
NOMBRE: XXXXXXXXXXXXXXXXXXXXXXXXXXX
ALTERNATIVA:
CDIGO: Son nemotcnicos que identifican el antipatrn.

TIPO: Catalogacin del tipo de antipatrn:
__________________________________________________________________________________________
4/125
ERROR.- Antipatrn grave que debe corregirse obligatoriamente.

AVISO.- Antipatrn leve que debe corregirse obligatoriamente.
INFORMATIVO.- Antipatrn leve que conviene corregir. No es bloqueante.
NOMBRE: Breve descripcin del contenido de la ficha.

DESCRIPCIN: Detalle del antipatrn.
ALTERNATIVA: Mtodo/s para evitar el antipatrn.
__________________________________________________________________________________________
5/125
COBOL
Tipos de datos.
CDIGO: CBTD-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: NDICES NO COMP
El error consiste en buscar elementos en tablas WORKING usando como ndice un campo cuya
PICTURE no es COMP, p.e. PIC 9(4).
Todo campo con el que se hagan operaciones, como en ADD 1 TO INDICE, se convierte a
COMP en tiempo de ejecucin, por lo que si el campo se define directamente como COMP se
evita hacer la conversin cada vez que se ejecuta.
ALTERNATIVA:
Definir como COMP todos los ndices de tablas WORKING:
PIC S9(n) COMP, estando n en funcin del valor mximo que pueda adoptar el ndice:
Hasta un valor de 32.767: PIC S9(4) COMP. Este formato es el adecuado para la
mayora de tablas.
Para valores ms grandes: PIC S9(8) COMP.
__________________________________________________________________________________________
6/125
CDIGO: CBTD-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: CONTADORES NO COMP
El error consiste en usar como contadores campos cuya PICTURE no es COMP, p.e. PIC 9(6).
Todo campo con el que se hagan operaciones, como en ADD 1 TO CONT-LEIDOS, se convierte
a COMP en tiempo de ejecucin, por lo que si el campo se define directamente como COMP
se evita hacer la conversin cada vez que se ejecuta.
ALTERNATIVA:
Definir como COMP todos los contadores, y en general todo campo destinado a realizar
operaciones aritmticas:
PIC S9(n) COMP, estando n en funcin del valor mximo que pueda adoptar el campo:
Hasta un valor de 32.767: PIC S9(4) COMP.
Hasta un valor de 2.147.483.647: PIC S9(8) COMP.
Se recomienda no usar un tamao de PICTURE ms grande de lo necesario.
CDIGO: CBTD-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: HARD-CODE
El error consiste en incluir datos HARD-CODE en un programa.

Consultar el documento HARD-CODE, DIRECTRICES DE USO.
ALTERNATIVA:
Evitar el HARD-CODE, usando en su lugar datos externos al programa, de forma que puedan
modificarse sin necesidad de modificar el cdigo fuente.
__________________________________________________________________________________________
7/125
Bsqueda en tablas WORKING.

CDIGO: CBBW-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: BSQUEDAS EN WORKING
Pueden darse distintos errores:

1. Recorrer la tabla secuencialmente empleando como ndice un campo cuya PICTURE
no es COMP.
Consultar el apartado especfico sobre ndices de tablas WORKING.
2. Recorrer la tabla secuencialmente pudindolo hacer de forma binaria o dicotmica.

La bsqueda binaria o dicotmica es mucho ms rpida que la secuencial, y se
puede hacer siempre que la tabla est clasificada por algn campo.
3. Recorrer la tabla secuencialmente hasta la ltima ocurrencia, en lugar de hacerlo slo

hasta la ltima ocurrencia realmente cargada en la tabla.
Si la tabla est definida p.e. con OCCURS 1000, pero slo se han cargado 400
ocurrencias, no deben recorrerse las 1000, ya que se sabe que a partir de la
401 estn sin informar.
ALTERNATIVA:
Caso 1.- Consultar el apartado especfico sobre ndices de tablas WORKING.
Caso 2.- Si la tabla est ordenada por uno o ms campos, debe hacerse la bsqueda binaria
(SEARCH ALL):
01
TABLA.
10 ELEMENTO OCCURS 5000
ASCENDING KEY TAB-COD-BANCO, TAB-COD-OFICI
INDEXED
BY IND1.
15 E-BANCO PIC X(4).
15 E-OFICI PIC X(4).
SEARCH ALL ELEMENTO

AT END
SET NO-ENCONTRADO TO TRUE
WHEN E-BANCO (IND1) = WS-BANCO AND E-OFICI (IND1) = WS-OFICI
SET SI-ENCONTRADO TO TRUE
END-SEARCH
__________________________________________________________________________________________
8/125
Caso 3.a. Si el programa que recorre la tabla es el mismo que la ha cargado, el programa sabe
cuntas ocurrencias ha cargado (p.e. INDICE), por tanto el recorrido de la tabla debe
hacerse desde 1 hasta INDICE, no hasta el final de la misma.
b. Si la tabla la ha cargado un programa anterior al programa que la tiene que recorrer,
aqul debe informar a ste de cuntas ocurrencias ha cargado.
c. En cualquier caso, si la tabla se recorre para aadir un elemento, y no para buscarlo,
debe plantearse la necesidad de hacer dicho recorrido. P.e., un programa que realice
la carga de la tabla de forma ocasional, y no todo seguido, debe guardarse el nmero
de ocurrencia mayor en el que ha aadido un elemento (p.e. INDICE-ULTIMO), lo cual
permite en la siguiente ocasin aadir el elemento nuevo directamente en la
ocurrencia INDICE-ULTIMO + 1, sin tener que hacer recorrido hasta llegar a ella.
Uso de OCCURS DEPENDING ON

CDIGO: CBDP-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: OCCURS DEPENDING ON
Consiste en usar OCCURS DEPENDING ON en programas on-line.

Esta prctica implica que cada vez que se cargue una fila nueva en la tabla el programa
necesite buscar memoria para ella, con el consiguiente consumo de recursos.
ALTERNATIVA:
Evitar esta prctica en programas on-line.
__________________________________________________________________________________________
9/125
Ubicacin de las sentencias.

CDIGO: CBUS-01
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: UBICACIN DE LOS CLCULOS
El error consiste en colocar las sentencias en un lugar inadecuado, normalmente dentro de

bucles pudiendo estar fuera de ellos, con el consumo innecesario que ello ocasiona.
El bucle puede ser evidente o no evidente:
Bucle evidente:
MOVE 0 TO TOTAL.
PERFORM VARYING IND FROM 1 BY 1 UNTIL IND = 1000
COMPUTE TOTAL = TOTAL + (CAMPO(IND) * TIPO)
END-PERFORM.
En la ejecucin este bucle realiza:
1000 sumas (IND = IND +1).
1000 comparaciones (IF IND = 1000).
1000 multiplicaciones (CAMPO(IND) * TIPO).
1000 sumas (TOTAL = TOTAL + Resultado de la multiplicacin).
Las 1000 multiplicaciones pueden evitarse, obteniendo el mismo resultado en el campo
TOTAL.
Bucle no evidente:
Se trata p.e. de un programa batch de listado, donde las cabeceras fijas se obtienen N veces
en lugar de slo una en todo el programa (p.e. hace CALL a la rutina que le da la fecha para
imprimir la cabecera). Si esta fecha es fija para todo el listado, deber obtenerse al inicio del
programa, una sola vez, y no una por cada salto de pgina.
ALTERNATIVA:
Bucle evidente:
Reducir la codificacin de bucles al mnimo imprescindible:
MOVE 0 TO TOTAL.
PERFORM VARYING IND FROM 1 BY 1 UNTIL IND = 1000
COMPUTE TOTAL = TOTAL + (CAMPO(IND)
END-PERFORM.
COMPUTE TOTAL = TOTAL * TIPO.
Bucle no evidente:
__________________________________________________________________________________________
10/125
Codificar las instrucciones en el punto adecuado, teniendo en cuenta el momento exacto en

que deben ejecutarse.
CDIGO: CBUS-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: UBICACIN DE LAS LLAMADAS A RUTINAS DE

VALIDACIN
Es por ejemplo el caso de un programa batch que valida un fichero de tarjetas, y por cada
registro llama a una rutina que valida la Provincia donde se gener el movimiento, accediendo
entonces a la tabla de Provincias una vez por cada tarjeta, en lugar de una vez por cada
provincia.
ALTERNATIVA:
En tiempo de diseo, considerar la cardinalidad de la informacin procesada y actuar en
consecuencia.
En el ejemplo expuesto, si hay que validar la Provincia el fichero debera venir ordenado por
ese dato, y slo al producirse un cambio de Provincia llamara a la rutina de validacin.
En caso de que no fuera posible ordenar por Provincia, validar solo cuando sta sea distinta a
la ltima validada. De esta forma se puede evitar muchas validaciones.
Sentencias muy consumidoras.

Toda sentencia ocasiona un consumo en el momento de ejecutarse, sin embargo hay
sentencias que implican un alto consumo en comparacin con otras, para un mismo nmero
de ejecuciones.
CDIGO: CBMC-01
TIPO: AVISO
NOMBRE: INITIALIZE
DESCRIPCIN:
Esta sentencia sirve para inicializar un rea de trabajo. La definicin de inicializar es
establecer los valores iniciales para la ejecucin de un programa. El valor inicial depende de
la naturaleza (PICTURE) del campo; as, un campo numrico se inicializa a ceros; un campo
__________________________________________________________________________________________
11/125
alfanumrico se inicializa a espacios; etc.

En la ejecucin de un programa que emplea INITIALIZE, el sistema tiene que comprobar qu
PICTURE tiene cada campo para saber si debe moverle ZEROS o SPACES, y luego movrselo.
Esta comprobacin es la que se puede evitar empleando otras tcnicas.
El INITIALIZE de un rea es ms costoso:
Cuantas ms veces se ejecuta (como cualquier instruccin).
Cuantos ms campos contenga el rea.
Cuanta mayor sea la longitud total del rea. Cabe destacar que si el rea tiene
OCCURS la longitud total se multiplica, as como el nmero de campos.
En batch, el INITIALIZE de una tabla de WORKING slo tiene sentido si la tabla se carga de
forma aleatoria, de forma que al recorrerla tras la carga no se pudiera conocer qu filas van a
tener contenido. En cambio, si la carga se hace de forma secuencial, que es lo ms comn con
diferencia, siempre se sabe en qu ocurrencia se ha terminado de escribir, lo que hace que el
INITIALIZE previo sea innecesario.
ALTERNATIVA:
1. Para campos simples (campos que no estn incluidos en un rea), no usar INITIALIZE.
En su lugar, mover ZEROS o SPACES segn corresponda.
2. En general, para reas de datos (reas que incluyen varios campos individuales), usar
INITIALIZE slo si es necesario.
3. En lectura de ficheros (READ INTO), no inicializar (ni con INITIALIZE ni con MOVEs) el
rea antes de leer (ni evidentemente despus de leer) . El READ INTO va a reemplazar
el rea actual del registro de WORKING con el rea del registro ledo del fichero, con
lo que no es necesario el INITIALIZE previo.
4. En escritura de ficheros (WRITE FROM), no inicializar (ni con INITIALIZE ni con MOVEs)
el rea despus de escribir. Tampoco es necesario inicializar antes de escribir, si se
van a informar todos los campos del rea antes de la WRITE.
5. Si a pesar de todo se estima que un INITIALIZE es necesario:
a. Plantearse el lugar en donde se coloca la instruccin, y a ser posible colocarla
fuera de bucles.
b. Considerar la posibilidad de hacer el INITIALIZE de cada ocurrencia de una
tabla de WORKING justo antes de informar dicha ocurrencia, en lugar de
hacer uno general para toda la tabla. De esta forma slo se inicializarn las
ocurrencias realmente cargadas, y no la tabla completa.
6. En rutinas que cargan una tabla WORKING para devolvrsela al programa llamante, se
suele inicializar la tabla completa antes de hacer la carga (que puede ser parcial). En
estos casos se emplea INITIALIZE como medida de seguridad para que el programa
llamante, que recibe la tabla cargada, slo trate las ocurrencias informadas. Este
INITIALIZE se puede evitar por dos mtodos:
a. Un mtodo aplica a ambos programas (llamante y rutina); consiste en que la
rutina devuelva al llamante un contador con el nmero de ocurrencias
__________________________________________________________________________________________
12/125
cargadas en la tabla. Esto hace que el INITIALIZE sea innecesario, y que el

llamante tenga que comprobar dicho contador.
b. El otro mtodo aplica solamente a la rutina, siendo transparente para el
programa llamante; consiste en que la rutina haga INITIALIZE de la ocurrencia
siguiente a la que acaba de informar (contemplando que no exceda del
OCCURS). De esta forma la rutina slo ejecuta un INITIALIZE, y se obtiene la
misma seguridad que si hubiera inicializado toda la tabla, ya que el programa
llamante (en ausencia del contador) recorrer la tabla hasta encontrar una
ocurrencia inicializada (que ser la siguiente a la ltima cargada).
__________________________________________________________________________________________
13/125
CDIGO: CBMC-02
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: MOVE DE REAS GRANDES
El MOVE de un rea grande (miles de bytes) debe utilizarse con mesura. En este ejemplo, las
reas AREA1 y AREA2 tienen el mismo formato y longitud:
IF
ADD 1 TO CONTADOR
PERFORM
MOVE AREA1 TO AREA2
END-IF
MOVE AREA2 TO AREA1
El ltimo MOVE se est ejecutando sin necesidad cuando se ha ejecutado tambin el MOVE
anterior, ya que en este caso las dos reas ya son iguales antes de hacer el segundo MOVE (y
por tanto no hace falta hacerlo). Es decir:
Si entra en el IF, mover AREA1 a AREA2 y luego AREA2 a AREA1 (sin necesidad).
Si no entra en el IF, slo mover AREA2 a AREA1.
ALTERNATIVA:
Insertando un ELSE se pueden eliminar millones de instrucciones manteniendo la misma
funcionalidad, y de paso aportando claridad al programa:
IF
ADD 1 TO CONTADOR
PERFORM
MOVE AREA1 TO AREA2
ELSE
MOVE AREA2 TO AREA1
END-IF
Si entra en el IF, mover AREA1 a AREA2 (con lo cual ya son iguales).

Si no entra en el IF, slo mover AREA2 a AREA1.
__________________________________________________________________________________________
14/125
CDIGO: CBMC-03
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: IF NUMERIC
Esta instruccin es muy costosa, conviene evitar su utilizacin.

Esta instruccin suele emplearse para saber si un campo numrico y opcional viene
informado, p.e.:
01
IMPORTE-ALF.
03 IMPORTE-NUM
PIC 9(9).
IF IMPORTE-ALF IS NUMERIC
Tiene contenido numrico
ELSE
END-IF
Esta prctica es habitual cuando un campo numrico es opcional, de forma que:
Si viene informado, viene con nmeros de la forma habitual.

Si no viene informado, viene con SPACES o LOW-VALUES o similar.
ALTERNATIVA:
Para evitar esta prctica hay que definir los datos de origen en fase de diseo de forma que
esta instruccin no sea necesario hacerla, p.e. definiendo un indicador para saber si el campo
viene informado:
01
IMPORTE-ALF.
03 IMPORTE-INFORMADO
03 IMPORTE-NUM
PIC X.
PIC 9(9).
IF IMPORTE-INFORMADO = S
Tiene contenido numrico
ELSE
END-IF
__________________________________________________________________________________________
15/125
READ/WRITE
CDIGO: CBRW-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: READ/WRITE SIN INTO/FROM
El error consiste en hacer READ sin INTO o WRITE sin FROM. Este mtodo implica trabajar
directamente con el registro definido en la FD de la FILE SECTION, lo que puede suponer
prdida de informacin.
El INTO y el FROM no son obligatorios sintcticamente, pero s lo son en la instalacin.
ALTERNATIVA:
Hacer siempre READ con INTO y WRITE con FROM.
__________________________________________________________________________________________
16/125
Ficheros de longitud fija.

CDIGO: CBLF-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: INFORMAR UN FICHERO EN VARIOS PASOS
El error consiste en disear varios procesos batch para crear un determinado fichero y cada
proceso informa una parte del registro, teniendo ste una COPY nica en todos los procesos.
Esto supone un gran manejo de informacin en blanco durante toda la cadena, con la
consiguiente ocupacin en disco y tiempo de ejecucin innecesarios.
ALTERNATIVA:
Usar una COPY especfica para cada tipo de fichero, ajustando la longitud a la realmente
necesaria.
CDIGO: CBLF-02
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: FILLER DESPROPORCIONADO
El error consiste en disear COPYs para ficheros batch de longitud fija, contemplando una
cantidad de FILLER desproporcionada.
Esta prctica implica un desperdicio de espacio en disco y de tiempo de ejecucin, ms
grandes cuanto ms registros tenga el fichero y/o mayor sea el FILLER.
ALTERNATIVA:
No contemplar FILLER, o al menos reservar un espacio proporcionado a la longitud total del
fichero.
Usar ficheros de longitud variable; de esta forma slo se escribe en disco la informacin
realmente necesaria.
__________________________________________________________________________________________
17/125
CDIGO: CBLF-03
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: INFORMACIN REPETIDA EN FICHERO
Se trata de un error de diseo que consiste en disear programas batch que manejan ficheros
muy voluminosos, en los que hay una gran cantidad de registros con la misma informacin en
los mismos campos.
Un ejemplo puede ser el de un formato de registro compuesto por banco, oficina,
contrapartida y otros campos, y que tiene cientos o miles de registros con la misma
informacin en banco, oficina y contrapartida. Esto supone un gran volumen de informacin
repetida, que muy probablemente ser leda y grabada por SORTs, por programas COBOL, etc.
ALTERNATIVA:
Para estos casos, disear ficheros de longitud variable, incluyndole un tipo de registro y
haciendo que los registros sean realmente de longitud variable (no slo el atributo del
fichero). Esto slo es aplicable cuando el fichero no tiene que clasificarse una vez creado, ya
que la ausencia de algunos campos en los registros impide su clasificacin.
Ficheros de longitud variable

CDIGO: CBLV-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: APPLY-WRITE ONLY
El error consiste en no poner la clusula APPLY-WRITE ONLY en un programa que lee o crea
un fichero secuencial de longitud variable. El Compilador COBOL asume esta clusula por
defecto, sin embargo es conveniente ponerla en previsin de que se cambie la versin del
Compilador o se migre el programa a otro entorno donde no la tenga.
Esta clusula mejora el tiempo de proceso en el manejo de ficheros de longitud variable, y es
ms til cuanta ms variacin de longitudes tiene el fichero.
ALTERNATIVA:
Codificar la clusula APPLY-WRITE ONLY al manejar este tipo de ficheros.
__________________________________________________________________________________________
18/125
Enfrentamiento de ficheros
El objetivo principal de un enfrentamiento de dos ficheros suele ser buscar la interseccin para
llevarla a salida y/o buscar en uno de los ficheros las claves del otro para coger de aqul ciertos datos
y completar con ellos el registro de este ltimo.
La tcnica ms comn para enfrentar dos ficheros es la siguiente, aunque no siempre es la mejor:
Ejecutar un SORT para ordenar un fichero por la clave.

Ejecutar otro SORT para ordenar el otro fichero por la misma clave.
Ejecutar un programa que haga el enfrentamiento entre los dos ficheros clasificados.
CDIGO: CBEF-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: FICHERO GRANDE VS FICHERO PEQUEO
El error consiste en emplear la tcnica habitual y clasificar ambos ficheros para hacer
un enfrentamiento tpico.
ALTERNATIVA:
Para estos casos se recomienda seguir este procedimiento:

-
Clasificar mediante SORT el fichero pequeo.
Al inicio del programa, cargar en una tabla WORKING el fichero pequeo. Esta
tabla tendr un OCCURS suficiente para albergar el fichero completo, adems
de las clusulas ASCENDING KEY e INDEXED BY.
En el proceso del programa, cada vez que se lea un registro del fichero grande,
buscar su clave en la tabla de WORKING, empleando SEARCH ALL. Esta
instruccin hace una bsqueda binaria (no secuencial) en la tabla.
Obsrvese que NO ha sido necesario clasificar el fichero grande, con lo que hemos
evitado un paso de SORT que hubiera ledo, clasificado y grabado un fichero
voluminoso.
__________________________________________________________________________________________
19/125
CDIGO: CBEF-02
TIPO: ERROR
DESCRIPCIN:
NOMBRE: ENFRENTAMIENTO DE 2 FICHEROS MUY GRANDES
La tcnica ms comn para enfrentar dos ficheros es la siguiente, aunque no siempre

es la mejor:
Ejecutar un SORT para ordenar un fichero por la clave.
A continuacin, ejecutar otro SORT para ordenar el otro fichero por la misma
clave.
A continuacin, ejecutar un programa que haga el enfrentamiento entre los dos
ficheros clasificados.
El error consiste en emplear la tcnica habitual y clasificar ambos ficheros, uno detrs
de otro en el mismo JCL, para hacer un enfrentamiento tpico.
ALTERNATIVA:
Ejecutar ambos SORT en paralelo, uno en cada JOB, y ejecutar el programa de enfrentamiento
en un tercer JOB que dependa de aquellos dos. Al ejecutarse en paralelo, el tiempo dedicado
a la clasificacin de los ficheros se reduce a la duracin del SORT que ms tarde.
__________________________________________________________________________________________
20/125
CDIGO: CBEF-03
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: ENFRENTAMIENTO DE 3 FICHEROS MUY GRANDES
En la instalacin no abundan los programas que hacen enfrentamiento de tres

ficheros, aunque s son frecuentes los procesos funcionales que necesitan hacer este
enfrentamiento.
El error consiste en disear un programa que haga enfrentamiento a dos, y otro programa
que haga otro enfrentamiento a dos. Con este procedimiento, alguno de los ficheros se lee
dos veces.
ALTERNATIVA:
Disear un solo programa que haga el enfrentamiento de los tres ficheros a la vez.
P.e., si lo que interesa es la interseccin de los tres ficheros:
PERFORM INICIO
PERFORM PROCESO UNTIL FIN-FILEA OR FIN-FILEB OR FIN-FILEC
PERFORM FIN
PROCESO.
IF A < B
PERFORM LEERA
ELSE
IF A > B
PERFORM LEERB
ELSE (A=B)
IF A < C
PERFORM LEERA
ELSE
IF A > C
PERFORM LEERC
ELSE (A=B=C)
PERFORM TRATAR
END-IF
END-IF
END-IF
END-IF.
__________________________________________________________________________________________
21/125
CDIGO: CBEF-04
TIPO: ERROR
DESCRIPCIN:
NOMBRE: ENFRENTAMIENTO GENERAL DE 2 FICHEROS
En aquellos casos en que slo interesa la interseccin de ambos ficheros, es decir,

llevar a salida los registros que tienen correspondencia en los dos, el error consiste en
leerlos por completo:
PERFORM PROCESO UNTIL FIN-FILEA AND FIN-FILEB
No es necesario alcanzar el final de los dos ficheros en este caso.
ALTERNATIVA:
Detener el proceso en cuanto se alcance el final de uno de los dos ficheros:

PERFORM PROCESO UNTIL FIN-FILEA OR FIN-FILEB
CDIGO: CBEF-05
TIPO: ERROR
DESCRIPCIN:
NOMBRE: ENFRENTAMIENTO CONTRA UN CURSOR DE UNA

TABLA
Es el caso en que el programa hace un enfrentamiento del fichero de entrada contra una tabla
DB2 directamente, usando un cursor, y el criterio de clasificacin del fichero NO coincide con
el ndice cluster de la tabla.
P.e. el ndice de la tabla es contrapartida-folio-oficina-banco, y el enfrentamiento se hace por
banco-oficina-contrapartida-folio. Esto impide que el DB2 realice PREFETCH, con lo que el
proceso durar ms de lo necesario.
ALTERNATIVA:
Hacer el enfrentamiento utilizando el mismo criterio que el que tiene el ndice cluster.
__________________________________________________________________________________________
22/125
Uso inadecuado de rutinas invocadas

CDIGO: CBRU-01
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: INFRAUTILIZACIN DE LA RUTINA DE

CANCELACIN
El mdulo normalizado de gestin de errores batch COBOL, QPBTRXRR, es invocado cuando

se produce un error grave y hay que cancelar la ejecucin del JOB. Este mdulo emite
DISPLAYs antes de cancelar, mostrando los datos que le ha pasado el programa llamante
(cdigo de error, etc.).
Estos DISPLAYs estn destinados a la resolucin rpida del problema, con lo cual si el
programa llamante no le pasa todos los datos se est desaprovechando la funcionalidad del
mdulo.
ALTERNATIVA:
Informar todos los datos para el mdulo QPBTRXRR antes de llamarle.
CDIGO: CBRU-02
TIPO: ERROR
DESCRIPCIN:
NOMBRE: COPY DE ARQUITECTURA QPIPCCAB
Uso de copy distintas a la copy QPIPCCAB como interfaz general para la comunicacin
entre los mdulos y programas de las aplicaciones. El registro de la copy est
estructurado en agrupaciones funcionales, de acuerdo al contenido y uso de los datos
que comprende.
ALTERNATIVA:
Consultar el documento descripcin y normas de uso QPIPCCAB en Site Aquitectura
ejecucin HOST- Arquitectura Normativas.
__________________________________________________________________________________________
23/125
Rearranques. Uso inadecuado de COMMIT

CDIGO: CBCO-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: COMMIT
La gestin de los puntos de COMMIT ( CHKP si es bajo control del IMS) que se ejecutan en un
proceso batch, debe hacerse utilizando en la aplicacin el software especfico de Arquitectura,
y no un software propio de la aplicacin.
La frecuencia de COMMIT (cada cuntos registros lo hace) no debe estar escrita
explcitamente en el programa (lo que por otra parte sera un HARD-CODE), sino ser un
parmetro externo al mismo. Esto facilita la posible modificacin de la frecuencia, sin
necesidad de tocar cdigo.
La frecuencia de COMMIT depende de factores como p.e. el horario de ejecucin del
programa.
Un nmero alto de COMMITs aumenta la duracin del proceso, mientras que un nmero bajo
puede ocasionar bloqueo de recursos.
ALTERNATIVA:
Para aplicaciones PG, consultar los documentos de Arquitectura de Ejecucin en el

que se describe el procedimiento normalizado del uso del COMMIT:
Parametrizacin de la frecuencia de COMMIT (Rearranques-Manual Administracion

Rearranques PG.doc)
Uso de los servicios para gestin de COMMIT :
o QPBTRXEI. Inicio del programa.
o QPBTRXEC. Solicitud de COMMIT.
o QPBTRXEF. Cierre del programa.
Para aplicaciones de SSAA, consultar el documento Procesos BMP, en el que se describe

cmo codificar las sentencias para definir un programa COBOL como rearrancable bajo
control de IMS.
__________________________________________________________________________________________
24/125
Parmetros de entorno de ejecucin

CDIGO: CBPA-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Parmetros de ejecucin
En programas en los que requiere parmetros del entorno de ejecucin, suelen informarse a
fuego en los programas, como pas, entidad, jcl donde se procesa, etc.
ALTERNATIVA:
Llamada a rutina QPIPRX28 que obtiene datos tcnicos del contexto de ejecucin del
CPD donde se procesa el JCL.
En ningn caso los datos que se obtienen deben ser utilizados con fines funcionales
como: tratamiento de clientes segn pas, de contratos segn entidad, textos por
idioma, etc.
Consultar el documento QPIPRX28 en Site Aquitectura ejecucin HOST- Rutinas corporativas.
__________________________________________________________________________________________
25/125
SQL
CDIGO: SQL-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: INCLUDES QUE NO SE UTILIZAN
El error consiste en declarar la INCLUDE de una tabla sin que el programa acceda a la misma,
o bien codificar accesos DB2 (SELECT etc.) en prrafos que no se ejecutan nunca.
Esto hace que el DBRM sea ms grande de lo necesario.
ALTERNATIVA:
No declarar la INCLUDE si la tabla no es necesaria en el programa.
Eliminar el cdigo muerto en general, especialmente si son sentencias SQL.
CDIGO: SQL-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: CAMPOS RECUPERADOS EN SELECT/FETCH
El error consiste en recuperar campos que son conocidos, como en:

SELECT COD_ENTALFA, COD_PAISOALF FROM tabla WHERE COD_ENTALFA =
:variable-host1 AND IMP_MINCOM = :variable-host2
Dado que el campo COD_ENTALFA se iguala en el WHERE, no es necesario incluirlo en la

SELECT.
Hay una EXCEPCIN a esta regla: se puede recuperar un campo conocido cuando el acceso se
hace para comprobar existencia (no para leer), como en:
SELECT COD_ENTALFA FROM tabla WHERE COD_ENTALFA = :variable-host1
ALTERNATIVA:
No recuperar los campos que sean conocidos, salvo en la excepcin expuesta.
__________________________________________________________________________________________
26/125
CDIGO: SQL-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: SELECT COUNT
El error consiste en usar SELECT COUNT(*) para contar las filas que cumplen una
condicin en una tabla, sin ser necesario conocer dicho nmero de filas.
Normalmente se usa en programas on-line de paginacin (scroll), en los que se hace
SELECT COUNT(*) para conocer el nmero de filas y as calcular el nmero de pginas
para mostrar en ventana la paginacin (p.e. PAG. 1 de 52). En este caso puede estar
justificado su uso, no as en los casos en que lo nico que se necesita es saber si hay o
no filas que cumplen la condicin.
El SELECT COUNT(*) es muy costoso, ya que el DB2 tiene que contar todas las filas de la tabla.
ALTERNATIVA:
Cuando slo se necesite saber si hay o no filas que cumplen la condicin, sin necesidad de
saber su cuanta, hacer directamente un SELECT y tomando estas precauciones:
-
Recuperar slo el primer campo del ndice cluster de la tabla.

Contemplar el SQLCODE -811, pero slo si el ndice cluster tiene ms de un campo.
De este modo:
-
Si se contempla el SQLCODE -811:

o SQLCODE = 0 significa que slo hay 1 fila (y por tanto hay filas).
o SQLCODE = -811 significa que hay ms de 1 fila (y por tanto hay filas).
o SQLCODE = +100 significa que no hay filas.
Si no se contempla el SQLCODE -811:
o SQLCODE = 0 significa que slo hay 1 fila (y por tanto hay filas).
o SQLCODE = +100 significa que no hay filas.
Consultar la norma sobre paginacin.
__________________________________________________________________________________________
27/125
CDIGO: SQL-04
TIPO: ERROR
DESCRIPCIN:
NOMBRE: ROLLBACK
El error consiste en ejecutar ROLLBACK cuando en el programa (o en la unidad de trabajo) no

se ha hecho ninguna actualizacin (INSERT, UPDATE, DELETE).
ALTERNATIVA:
Si no se ha hecho ninguna actualizacin, no hacer ROLLBACK.
CDIGO: SQL-05
TIPO: ERROR
DESCRIPCIN:
NOMBRE: ROLLBACK
En transacciones PG, es la propia Arquitectura quien debe realiza el ROLLBACK, siempre que la
aplicacin lo solicite a travs de la informacin que se cumplimente en la copy QPEJCAQA.
ALTERNATIVA:
Existe un documento en Soporte a Desarrollo -Site Aquitectura ejecucin HOST- con el

tratamiento de errores en transacciones PG.
__________________________________________________________________________________________
28/125
CDIGO: SQL-06
TIPO: ERROR
DESCRIPCIN:
NOMBRE: CURSORES QUE SLO LEEN UNA FILA
El error consiste en usar un cursor para tratar nicamente una fila. Esta prctica se
puede detectar de dos formas:
-
En el programa fuente: El programa hace OPEN CURSOR, hace un slo FETCH y

hace CLOSE CURSOR:
o En este caso se observa que al programa slo le interesa la primera fila
recuperada del cursor.
En la definicin del ndice de la tabla: El programa hace OPEN CURSOR, luego

ejecuta un bucle de FETCH hasta que da SQLCODE +100, y luego hace CLOSE
CURSOR:
o Si en el WHERE del cursor se igualan todos los campos del ndice, y ste
es nico, slo podr haber una fila o ninguna. En este caso no es
necesario el cursor.
o Si en el WHERE del cursor se igualan todos los campos del ndice, y ste
no es nico, el cursor puede estar justificado.
o Si en el WHERE del cursor se igualan algunos campos del ndice, sea
ste nico o no, el cursor puede estar justificado.
ALTERNATIVA:
Hay varias alternativas en funcin de la necesidad del programa:

-
Si lo que se quiere es comprobar la existencia de fila/s, sustituir el cursor por

una SELECT directa. Consultar el apartado SELECT COUNT para ver los
SQLCODE posibles.
Si lo que se quiere es tratar slo una fila cualquiera, sustituir el cursor por una
SELECT directa. Consultar el apartado SELECT COUNT para ver los SQLCODE
posibles.
Si lo que se quiere es realmente tratar slo la primera fila, lo que slo tiene
sentido si el cursor emplea ORDER BY, aadir en la declaracin del cursor la
clusula FETCH FIRST 1 ROWS ONLY; esto le hace saber al DB2 que slo
leeremos una fila, lo cual acelera considerablemente la va de acceso a los
datos.
__________________________________________________________________________________________
29/125
CDIGO: SQL-07
TIPO: ERROR
DESCRIPCIN:
NOMBRE: CURSORES QUE NO LLEGAN AL FINAL
Se trata de abrir un cursor, iniciar un bucle de lecturas (FETCH), y detener el bucle al llegar a N
filas recuperadas (en lugar de esperar al SQLCODE +100).
Esta prctica puede observarse p.e. en aquellas rutinas que devuelven al programa llamante
un nmero determinado de filas cada vez que se las invoca (rutinas de paginacin, etc.).
El OPEN CURSOR tiene un alto consumo, por lo que no debe ejecutarse esta instruccin para
leer un nmero limitado (y conocido) de filas.
ALTERNATIVA:
Si el nmero de filas a leer es conocido, emplear en el DECLARE CURSOR la clusula

FETCH FIRST n ROWS ONLY, siendo n el nmero de filas que queremos recuperar. Este
mtodo reduce considerablemente el consumo del OPEN CURSOR.
Si se usa FETCH FIRST n ROWS ONLY, el nmero de filas que se pueden recuperar
queda limitado a n; de hecho, si se hicieran n+1 FETCHs, se obtendra un SQLCODE
+100, incluso aunque hubiera ms filas que cumplan la condicin del WHERE. Debido
a esto, si interesase saber si hay ms de n filas, p.e. para decrselo al programa
llamante, se recomienda usar un FETCH FIRST de una fila ms de las necesarias (n+1).
De este modo:
Si al leer la fila n+1 da SQLCODE +100, es que no hay ms de n.
Si al leer la fila n+1 da SQLCODE 0, es que hay ms de n.
En todo caso, los programas de paginacin deben posicionarse en el cursor por
mayor o igual a la ltima clave devuelta.
CDIGO: SQL-08
TIPO: AVISO
DESCRIPCIN:
NOMBRE: CODIFICACIN DEL WHERE
La forma de codificar el WHERE puede condicionar el uso del ndice y/o hacer que el
proceso interno de bsqueda sea ms o menos sencillo.
Esto es aplicable tanto a las SELECT directas como a los DECLARE CURSOR.
__________________________________________________________________________________________
30/125
Caso 1.- El WHERE utiliza OR con igualdad y mayor/menor: SELECT campos FROM
tabla WHERE campo1 = dato OR campo1 > dato.
Caso 2.- El WHERE utiliza OR con igualdad en dos datos: SELECT campos FROM tabla
WHERE campo1 = dato1 OR campo1 = dato2.
Caso 3.- El WHERE utiliza NOT: SELECT campos FROM tabla WHERE campo1 NOT >
dato.
ALTERNATIVA:
Caso 1.- Usar: SELECT campos FROM tabla WHERE campo1 >= dato.
Caso 2.- Usar: SELECT campos FROM tabla WHERE campo1 IN (dato1, dato2).
Caso 3.- Usar: SELECT campos FROM tabla WHERE campo1 <= dato.
CDIGO: SQL-09
TIPO: ERROR
DESCRIPCIN:
NOMBRE: UN OPEN CURSOR POR CADA REGISTRO (BATCH)
Consiste en un programa batch que trata un fichero de entrada, y por cada registro
hace un OPEN CURSOR en una tabla DB2 (directamente o mediante rutina) para
obtener datos de varias filas y llevar a salida tantos registros como filas encontradas
para el registro de entrada actual.
Esto ocasiona un consumo muy elevado si el fichero de entrada tiene muchos
registros, ya que el programa har un OPEN CURSOR por cada uno de ellos.
ALTERNATIVA:
Hay varias alternativas, dependiendo del volumen del fichero de entrada y de la tabla DB2 a
consultar:
CASO FICHERO
1
Pequeo
TABLA
Pequea
TIPO DE WHERE
Indiferente
Grande
Muy restrictivo
Pequeo
COMENTARIOS
Los OPEN CURSOR no deberan
suponer un consumo excesivo.
Aunque la tabla sea grande, como
el WHERE es muy restrictivo se
recuperarn pocas filas por cada
__________________________________________________________________________________________
31/125
Pequeo
Grande
Poco restrictivo
Grande
Pequea
Indiferente
Grande
Grande
Muy restrictivo
Grande
Grande
Poco restrictivo
registro del fichero.

Este cursor recuperar muchas filas
por cada registro del fichero.
El OPEN CURSOR no ser muy
costoso, sin embargo lo ejecutar
muchas veces.
El OPEN CURSOR no ser muy
costoso, sin embargo lo ejecutar
muchas veces.
ste es el peor de los casos.
Nota: La consideracin de pequeo/grande es subjetiva, pero se indica as en la tabla a modo

ilustrativo. No obstante, en este contexto se puede decir que se considera fichero grande
cuando tiene millones de registros y tabla grande cuando tiene miles de filas. El Analizador de
COBOL penaliza en la regla R058 la definicin de un OCCURS mayor de 5.000 ocurrencias, y en
la regla R073 el acceso repetitivo a tablas DB2 de bajo volumen. Por otra parte, el tamao de
una tabla no es exclusivamente el nmero de filas, sino lo largas que stas sean (nmero de
columnas y longitud de la fila).
CASO RECOMENDACIN
1
En funcin de los tamaos, puede mantenerse el cursor o aplicar la
recomendacin 4.
2
recomendacin 4.
3
Aplicar la recomendacin 6.
4
Cargar la tabla, ordenada, en Working, y hacer una bsqueda binaria (SEARCH
ALL). Poner atencin en el tamao de la tabla para optar por esta solucin.
5
recomendacin 6.
6
Hacer una descarga de la tabla y ejecutar un enfrentamiento. Nota: Este
mtodo obliga a que ambos ficheros estn clasificados.
__________________________________________________________________________________________
32/125
JCL
Nmero de pasos
CDIGO: JCNP-01
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: NMERO DE PASOS
El error consiste en disear JCLs con un excesivo nmero de pasos. Se recomienda que un JCL
no tenga ms de 10 pasos.
Un nmero excesivo de pasos:
-
Dificulta el mantenimiento futuro del JCL.

Reduce la posibilidad de reutilizar pasos en futuros procesos.
Puede camuflar la presencia de pasos que podran correr en paralelo.
ALTERNATIVA:
Disear JCLs con un nmero reducido de pasos.
Descarga de BBDD
CDIGO: JCDE-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: DESCARGA DE DATOS INNECESARIOS
El error consiste en descargar columnas o filas innecesarias, p.e.:

-
Se descargan los campos de auditora (usuario y fecha) y luego estos campos

se ignoran durante todo el proceso.
Se descargan filas de ms, empleando un WHERE poco restrictivo, y luego
estas filas de descartan mediante filtros, etc.
Esta prctica conlleva un consumo de tiempo y de espacio en disco innecesarios.

ALTERNATIVA:
Descargar nicamente las filas y las columnas que se necesitan para el proceso.
__________________________________________________________________________________________
33/125
CDIGO: JCDE-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: DESCARGA DE TABLAS COMPLETAS
La descarga completa de una tabla, no debe hacerse por programa sino por utilidad, a
menos que el proceso de descarga deba tener algn tipo de lgica o tratamiento.
Nota: Esto es aplicable tambin a BBDD IMS.
ALTERNATIVA:
Es ms eficiente p.e. utilizar ADUUMAIN o IKJEFT01 que un programa COBOL que se

lea la tabla por completo.
CDIGO: JCDE-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: DESCARGA CON SELECT *
No es recomendable realizar descargas usando SELECT *. Este mtodo conlleva el

riesgo de que, ante futuras modificaciones en la tabla, como aadir columnas, se
inutilice el proceso o se produzcan cancelaciones, ya que el SELECT * descargara las
columnas nuevas.
ALTERNATIVA:
Descargar exclusivamente las columnas necesarias para el proceso.
__________________________________________________________________________________________
34/125
CDIGO: JCDE04
TIPO: AVISO
DESCRIPCIN:
NOMBRE: DESCARGA SLO PARA ENFRENTAMIENTO
Consiste en ejecutar una descarga, total o parcial, y el fichero resultante se va a usar

exclusivamente para un enfrentamiento COBOL con un segundo fichero.
Las descargas son tiles sobretodo cuando el fichero resultante ser tratado por varios
procesos, o cuando la descarga genera ms de un fichero para as arrancar a continuacin
varios procesos en paralelo.
ALTERNATIVA:
Considerar la posibilidad de sustituir la descarga por un enfrentamiento directo con la tabla
empleando un CURSOR.
La decisin depende:
- Del tamao de la tabla. Si la tabla es muy grande, el uso del cursor evitara tener que
leer primero todas las filas en la descarga y despes todos los registros en el COBOL.
-
De la hora de ejecucin. Si se opta por el cursor y la tabla es muy grande, podra

producirse contencin con otros procesos.
etc.
Utilidades obsoletas
CDIGO: JCUT-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: UTILIDADES OBSOLETAS
Se debe evitar el uso de pasos que ejecuten utilidades de Recepcin de Aplicaciones que ya
no estn disponibles para procesos batch, tanto para aplicaciones de PG como para cualquier
aplicacin nueva, p.e:
IEBFILE, EXUTU011, EXTRU010, etc.
ALTERNATIVA:
__________________________________________________________________________________________
35/125
En su lugar deben emplearse utilidades estndar de IBM o procesos propios de Arquitectura,

p.e.:
-
IEBGENER en lugar de IEBFILE.
IDCAMS en lugar de EXUTU011.
QPIPB111 en lugar de EXTRU010.
Etc.
Para acceder al listado completo, consultar el documento UTILIDADES DE RECEPCIN DE

APLICACIONES NO DISPONIBLES PARA PROCESOS BATCH.
Dimensionamiento de ficheros.
CDIGO: JCDI-01
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: RESERVA DE ESPACIO INADECUADO
Consiste en codificar la clusula SPACE al crear un fichero nuevo de forma que el espacio
indicado es grande o pequeo respecto al que se necesitar realmente.
Con un SPACE demasiado pequeo el fichero se puede llenar, provocando una cancelacin.
Con un SPACE demasiado grande el sistema intentar obtener espacio sin necesidad, con el
consiguiente consumo de disco y de tiempo.
ALTERNATIVA:
Utilizar la CLIST TSO BLK para obtener el espacio idneo, en funcin de la longitud de registro
(LRECL), el nmero de registros estimados, y el tiipo de disco utilizado (3390 normalmente).
Ejemplo:
------------------- Espacios en Ficheros Secuenciales
LRECL =======> 250
REGISTROS ===> 1000000
(Compartido)
para 6233
BLK==> 6000
TRK==> 13889
CYL==> 463
-----------
(Discos 3350)
para 19069
(Discos 3380)
para 23476
(Discos 3390)
para 27998
BLK==> 19000
TRK==> 13158
CYL==> 439
BLK==> 23250
TRK==> 5377
CYL==> 359
BLK==> 27750
TRK==> 4505
CYL==> 301
__________________________________________________________________________________________
36/125
RXB==> 24
RXB==> 76
Cintas
para 13030
BLKSIZE ==>
A 1.600 ==>
A 6.250 ==>
* 3480 *==>
BYTES
==>
13000
9
2
2
250000000
RXB==> 93
Cintas 3480
para 24576
BLK====> 24500
RXB====> 98
RXB==> 111
Trk para workas
DK3330===> 23829
DK3350===> 14900
DK3380===> 6964
Ficheros temporales
CDIGO: JCFT-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: BORRADO DE FICHEROS TEMPORALES
No se debe codificar la sentencia DISP=(NEW,CATLG,DELETE) si no se tiene la seguridad de

que el fichero a crear no existe. Esta prctica puede producir cancelaciones.
Adems, no deben quedar definidos ficheros temporales una vez tratados. Esta prctica
conlleva una ocupacin innecesaria en disco.
ALTERNATIVA:
La nica forma de tener la seguridad de que los ficheros NEW no existen, es incluir un paso
previo en el que, mediante IDCAMS, se relaciones los ficheros NEW generados en el JOB y se
borren en caso de existir.
Deben borrarse los ficheros temporales una vez consumidos, al final del JCL, o bien en el JCL
de destino que lo consume.
__________________________________________________________________________________________
37/125
Ficheros externos.
NOMBRE: CREACIN DE FICHERO PARA OTRO JOB
CDIGO: JCFE-01
TIPO: AVISO
DESCRIPCIN:
Consiste en crear en el JOB1 un fichero para el JOB2, y ejecutar ms pasos a continuacin de

la creacin en el JOB1.
Al crear un fichero para otro JOB, conviene que este ltimo empiece a ejecutarse cuanto
antes. Sin embargo la existencia de pasos posteriores a la creacin del fichero en el JOB1 hace
que el JOB2 empiece ms tarde (no empezar, al menos, hasta que acabe por completo el
JOB1, debido a la dependencia JOB1JOB2).
Obsrvense en este ejemplo las horas de inicio y fin de cada proceso. Aunque el fichero F3
est disponible a las 11:00, no empieza a leerse hasta las 12:00, porque antes tiene que
finalizar el PASO1B. El error de diseo consiste en crear una dependencia tcnica (PASO1B
PASO2A) donde no hay dependencia funcional (PASO2A no depende de PASO1B).
JOB2 (12:00 a 14:00)
JOB1 (10:00 a 12:00)

F1
12:00
PASO2A
13:00
10:00
PASO1A
11:00
F5
F2
11:00
PASO1B
12:00
F3
13:00
PASO2B
14:00
F6
F4
TOTAL = 10:00 a 14:00 = 4 horas
__________________________________________________________________________________________
38/125
ALTERNATIVA:
Siempre que sea posible, disear los JCLs de modo que su proceso finalice en cuanto se
genere un fichero externo, para adelantar el inicio de los sucesores, creando para elo un JCL
adicional para los pasos restantes y definiendo (y/o eliminando) las dependencias
correspondientes.
En el ejemplo, extraer el PASO1B del JOB1 y llevarlo al nuevo JOB3.
JOB1 (10:00 a 11:00)
JOB2 (11:00 a 13:00)
F1
11:00
PASO2A
12:00
10:00
PASO1A
11:00
F5
F2
12:00
PASO2B
13:00
F3
F6
JOB3 (11:00 a 12:00)
11:00
PASO1B
12:00
F4
TOTAL = 10:00 a 13:00 = 3 horas
__________________________________________________________________________________________
39/125
NOMBRE: TRATAMIENTO DE FICHERO DE JOB PREVIO
CDIGO: JCFE-02
TIPO: AVISO
DESCRIPCIN:
Consiste en tratar un fichero de entrada que viene de un JOB previo, en un paso cuya
ejecucin podra adelantarse.
Esta prctica hace que se retrase la lectura del fichero externo.
Obsrvense en este ejemplo las horas de inicio y fin de cada proceso. Aunque a veces puede
estar justificado, el error de diseo consiste en crear una dependencia tcnica (PASO2A
PASO2B, ya que en el JOB los pasos van consecutivos) donde no hay dependencia funcional
(PASO2B no depende de PASO2A).
JOB2 (11:00 a 13:30)
F4
JOB1 (10:00 a 11:00)

F1
11:00
PASO2A
11:30
10:00
PASO1A
11:00
F2
F5
11:30
PASO2B
12:30
F3
F6
12:30
PASO2C
13:30
F7
TOTAL = 10:00 a 13:30 = 3,5 horas
__________________________________________________________________________________________
40/125
ALTERNATIVA:
Siempre que sea posible, disear los JCLs de modo que la lectura de ficheros externos
comience cuanto antes, creando un JCL adicional para los pasos restantes y definiendo (y/o
eliminando) las dependencias correspondientes.
En este caso, el PASO2B es un SORT que clasifica el fichero F3 para un enfrentamiento en
PASO2C. Debe extraerse el SORT y llevarlo al nuevo JOB3. El JOB2 ahora ya no depende del
JOB1, por lo que la dependencia JOB1JOB2 podra eliminarse; sin embargo, en este caso
concreto debe mantenerse, o bien hacer que el JOB2 se arranque por horario, etc. (de otro
modo, el JOB2 no se lanzara nunca). Todo ello har que JOB2 y JOB3 corran al mismo tiempo.
Nota: Esta solucin aplica al ejemplo concreto, ya que puede haber otros factores que
condicionaran la solucin adoptada (predecesores, sucesores, dependencias DB2, arranque
por horario, etc.).
JOB1 (10:00 a 11:00)
JOB2 (11:00 a 11:30)

F4
F1
10:00
PASO1A
11:00
F2
11:00
PASO2A
11:30
F5
F3
JOB4 (12:00 a 13:00)
JOB3 (11:00 a 12:00)
11:00
PASO2B
12:00
12:00
PASO2C
13:00
F7
F6
TOTAL = 10:00 a 13:00 = 3 horas
__________________________________________________________________________________________
41/125
Duplicidad de accesos en el JCL

CDIGO: JCDU-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: RUTINA INVOCADA EN VARIOS PASOS
Es el caso en que en unpaso de un JOB se ejecuta un programa que llama a una rutina, y unos
pasos despus se vuelve a invocar a la misma rutina.
F1
BD
PGM1
RUTINA
F2
PGM2
F3
ALTERNATIVA:
Segn el caso, este tipo de mtodos puede mejorarse si se arrastran mediante fichero los
datos obtenidos por la rutina en el primer paso, para poderlos coger en los pasos siguientes.
De esta forma se puede evitar un gran nmero de CALLs, lo que es especialmente importante
cuando la rutina es DB2 (directa o indirectamente).
F1
PGM1
BD
RUTINA
F2 + Datos rutina
PGM2
F3
__________________________________________________________________________________________
42/125
Tratamiento aparte merecen aquellas rutinas elementales, que nicamente ejecutan

ciertos algoritmos, como el clculo de intereses, operaciones con fechas, etc., porque
aunque sean invocadas varias veces puede justificarse porque trabajan cada vez con
datos distintos.
__________________________________________________________________________________________
43/125
SORT
CDIGO: JCSO-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: OUTFIL/INCLUDE
En el SORT no debe usarse la clusula OUTFIL cuando slo se genera un fichero de salida:
SORT FIELDS=(1,10,CH,A)
OUTFIL FNAMES=SALIDA,INCLUDE=(15,1,CH,EQ,C'1')
En este ejemplo el SORT clasifica todo el fichero por 1,10,CH,A, y despus aplica el filtro
indicado en el INCLUDE, llevando a SALIDA los registros que superen dicho filtro. De esta
forma, se han clasificado registros que no interesan.
ALTERNATIVA:
SORT FIELDS=(1,10,CH,A)
INCLUDE COND=(15,1,CH,EQ,C'1')
Con este mtodo, el SORT clasifica exclusivamente los registros que cumplen el filtro del
INCLUDE, y a continuacin los lleva a SALIDA. De esta forma se clasifican slo los registros que
interesan.
CDIGO: JCSO-02
TIPO: ERROR
DESCRIPCIN:
NOMBRE: DOS SORT: SUM FIELDS NONE + OUTREC
Es el caso en que:
Un primer SORT clasifica el fichero y elimina duplicados con SUM FIELDS NONE.
Un segundo SORT clasifica la salida del primero por los mismos campos y hace
OUTREC para cambiar el formato, dndonse la circunstancia que la salida del primer
SORT es slo de trabajo (no va a otros pasos).
De este modo un fichero de N registros se ha ledo dos veces, clasificado dos veces y grabado
dos veces.
ALTERNATIVA:
Hacerlo todo en un nico SORT.
La clusula OUTREC cambia el formato del registro justo antes de llevarlo a salida, y por tanto
lo hace una vez aplicado el SUM FIELDS NONE.
__________________________________________________________________________________________
44/125
CDIGO: JCSO-03
TIPO: AVISO
DESCRIPCIN:
NOMBRE: JUNTAR FICHEROS YA ORDENADOS
Es el caso en que:
Un primer SORT clasifica un fichero y genera la SALIDA1.
Un segundo SORT clasifica otro fichero y genera la SALIDA2, con el mismo formato
que SALIDA1.
Un tercer SORT clasifica otro fichero y genera la SALIDA3, con el mismo formato que
SALIDA1 y SALIDA2.
Etc.
Un ltimo SORT junta todas las salidas y los vuelve a clasificar, obteniendo la SALIDA
final.
Esta prctica se suele emplear para juntar ficheros (SALIDA1, SALIDA2, ) que vienen de
procesos previos y con el mismo formato.
ALTERNATIVA:
El ltimo SORT puede ser necesario para juntar los ficheros, pero lo que no hace falta es
clasificar (SORT FIELDS). Los ficheros llegan ya ordenados, aunque por separado, y un MERGE
FIELDS lo resuelve mejor que el SORT FIELDS, ya que el MERGE no clasifica. El MERGE hace un
enfrentamiento entre los ficheros y los lleva a salida en el orden que corresponda.
Ejemplo:
Codificar en el ltimo SORT:
MERGE FIELDS=(1,10,CH,A), en lugar de: SORT FIELDS=(1,10,CH,A).
Nota: Si se usa MERGE no son necesarias las fichas //SORTWKnn; el paso de SORT no necesita
espacio en disco para clasificar, ya que MERGE no clasifica.
CDIGO: JCSO-04
TIPO: ERROR
DESCRIPCIN:
NOMBRE: FILTROS CONSECUTIVOS EN VARIOS SORT
Es el caso en que un fichero se filtra en un SORT (INCLUDE/OMIT) y la salida se vueve a filtrar

en otro SORT (INCLUDE/OMIT).
Esta prctica hace que se duplique el proceso necesario para obtener el resultado final, ya
que el fichero se lee dos veces y se graba dos veces.
__________________________________________________________________________________________
45/125
ALTERNATIVA:
Unificar en el mismo paso de SORT el mximo de procesos.
CDIGO: JCSO-05
TIPO: ERROR
DESCRIPCIN:
NOMBRE: UNA CLASIFICACIN QUE ENGLOBA A OTRA
Es el caso en que:
1. El SORT1 clasifica el FICHERO1 por un cierto criterio, generando la SALIDA1, p.e.:
SORT FIELDS=(1,10,A,15,5,A,30,6,A),FORMAT=BI.
2. El SORT2 clasifica el FICHERO1 o la SALIDA1 por un criterio distinto, pero que engloba
al anterior, generando la SALIDA2:
SORT FIELDS=(1,10,A,15,5,A,30,6,A,50,2,A),FORMAT=BI.
ALTERNATIVA:
Aunque ambas salidas sean necesarias, el primer SORT puede suprimirse. El fichero SALIDA1
puede ser el mismo que el SALIDA2, ya que, aunque se clasifique por 50,2,A, esto no altera
la clasificacin del SORT1, es decir, el programa al cual va dirigido el fichero SALIDA1 le resulta
indiferente la clasificacin adicional de 50,2,A.
Nota: Deben considerarse otros factores no expuestos en el ejemplo, y que pueden alterar la
decisin adoptada, como p.e.:
El uso o no de la opcin EQUALS.
El uso o no de INCLUDE/OMIT/SUM.
etc.
CDIGO: JCSO-06
TIPO: AVISO
DESCRIPCIN:
NOMBRE: USAR SORT PARA CREAR GDG(+1)
Consiste en ejecutar un paso que crea un fichero, y a continuacin ejecutar un SORT que
copia ese fichero a un GDG(+1).
Esto supone un tratamiento doble del fichero (dos lecturas y dos grabaciones).
ALTERNATIVA:
__________________________________________________________________________________________
46/125
Generar directamente el GDG(+1) siempre que sea posible, evitando as el SORT posterior.
Identificacin y tratamiento en JCL

CDIGO: JCIT-01
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: IDENTIFICACIN Y OBJETIVO JCL
Los jcls generalmente no contienen el objetivo principal del mismo.

ALTERNATIVA:
Comentar a nivel de sentencia JOB la aplicacin de la que forma parte y el objetivo

general del trabajo, as como comentarios de las funciones de paso.
CDIGO: JCIT-02
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: HOMOGENEIDAD JCL
No se deben realizar montajes de procesos dispares en los JCLs.

ALTERNATIVA:
Disear el JCL como una unidad homognea y evitar concatenacin de tratamientos

dispares.
Disear JCLs para los diferentes tratamientos.
CDIGO: JCIT-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: MALLA DEL CAMINO CRTICO
El diseo de los JCLs en ocasiones mezclan procesos imprescindible con procesos

accesorios a la malla del camino crtico.
__________________________________________________________________________________________
47/125
ALTERNATIVA:
Disear JCLs de modo que los procesos accesorios en la medida de lo posible se ejecuten en
paralelo de los procesos accesorios.
Paralelizar los procesos susceptibles de ejecutarse en paralelo.
Contenciones
CDIGO: JCCO-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: CONTENCIONES
Un proceso de actualizacin o lectura puede producir el bloqueo de otro proceso de

actualizacin o lectura, p.e. el bloqueo o contencin puede darse cuando:
Un proceso IMS usa una PSB con PCB de actualizacin, cuando la PCB podra ser de
lectura.
Un proceso DB2 ejecuta un cursor costoso para actualizar.
Se ejecuta COMMIT con poca frecuencia.
Se accede a un recurso en modo actualizacin antes del momento preciso, con lo que
el recurso est bloqueado ms tiempo del necesario.
Se accede a una tabla DB2 que se est descargando mediante utilidad.
ALTERNATIVA:
En IMS usar la PCB de actualizacin slo donde sea necesario y en el momento de serlo.
En DB2 considerar que las tablas accedidas pueden estar siendo tambin accedidas por otros
procesos (online y/o batch), ajustando las dependencias necesarias.
__________________________________________________________________________________________
48/125
Tratamiento de cancelaciones batch.

CDIGO: JCCA-01
TIPO: AVISO
DESCRIPCIN:
NOMBRE: JOB CON PASOS NO DEPENDIENTES
El diseo de un JCL con muchos pasos, cuando algunos de ellos no dependen funcionalmente
de los anteriores, puede ocasionar que ante una cancelacin se retrase la finalizacin de los
posteriores, inncesariamente.
ALTERNATIVA:
Disear JCLs como una unidad funcional, de manera que, si cancelan, no retrasen el inicio de
JCLs que no tengan relacin con aqul.
Se trata de disear un JCL como una unidad de tratamiento homognea, evitando la
acumulacin de tratamientos dispares en un mismo JOB.
CDIGO: JCCA-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: RETRASO DE UNA CANCELACIN INEVITABLE
Es el caso en que un programa ya sabe que debe cancelar y sin embargo contina su proceso
antes de proceder a dicha cancelacin.
P.e. se trata de un programa que valida un fichero, generando una salida de registros
correctos y otra de errneos, y que ante un slo error debe cancelar, pero sin embargo
contina generando registros de correctos y errneos hasta el final del proceso. Slo en
ciertos casos se necesita llegar al final para proceder a la cancelacin.
ALTERNATIVA:
Si debe ejecutarse una cancelacin, hacerlo cuanto antes.
Consultar el documento Cancelaciones de trabajos batch.doc.
__________________________________________________________________________________________
49/125
CDIGO: JCCA-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: USO DE RUTINAS DE CANCELACIN NO

NORMALIZADAS.
Los programas COBOL usan rutinas distintas de la facilitada por Arquitectura, QPBTRXRR,
para cancelar un programa.

ALTERNATIVA:
Utilizar las rutinas normalizadas de cancelacin facilitadas por Arquitectura.
CDIGO: JCCA-04
TIPO: ERROR
DESCRIPCIN:
NOMBRE: CANCELACIONES EN TRATAMIENTOS MIXTOS DE

VALIDACIN Y ACTUALIZACIN.
Un programa realiza simultneamente validaciones y actualizaciones, cancelando al detectrse

una situacin anmala.
ALTERNATIVA:
1. Cuando no se requiera exclusividad sobre una entidad de datos, separar el proceso de
validacin del proceso de actualizacin.
2. Si fuera necesario mantener la exclusividad sobre una entidad de datos, disear el
proceso aplicando un tratamiento flexible de cancelaciones flexible que
permita descartar los registros de entrada errneos para su tratamiento

posterior, de manera que no afecte al proceso en curso.
__________________________________________________________________________________________
50/125
SERVICIOS
CDIGO: SERV-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: USO DE CAJAS NEGRAS
En fase de diseo se decide invocar va CALL a un mdulo para la obtencin de determinados

datos, obviando el hecho de que este mdulo a su vez invoca a una gran cantidad de rutinas.
De haber considerado ese hecho podra haberse escogido una rutina ms especfica que el
mdulo inicial.
Esta prctica ocasiona un alto consumo de recursos innecesariamente, tanto de ELAPSED
TIME como de CPU, lo que es especialmente importante en el online.
ALTERNATIVA:
Esta prctica se puede detectar si en tiempo de diseo se observan los campos que devuelve
el mdulo inicialmente escogido: un gran nmero de campos comparado con los que
realmente necesita el contexto, puede sugerir que el mdulo est invocando a rutinas que no
interesan.
Para evitarlo, debe elegirse como mdulo de obtencin de datos aqul que se ajuste ms a las
necesidades, no slo que las cubra. El stock de mdulos disponibles ser ms rico cuanto ms
se ajusten los accesos a las necesidades, lo cual debera contemplarse en tiempo de diseo
(de los mdulos, en este caso).
CDIGO: SERV-02
TIPO: AVISO
DESCRIPCIN:
NOMBRE: SERVICIO CON MUCHAS FUNCIONES EXCLUYENTES
Se trata de un servicio que contempla diferentes funciones, pero que en cada ejecucin slo
realiza una de ellas.
Este tipo de programas lleva asociado un mdulo demasiado grande para lo que hace cada
vez, adems de un DBRM tambin grande si es DB2. La consecuencia de estos tamaos es el
coste que supone cargar el mdulo en memoria.
ALTERNATIVA:
Se debe tender a disear servicios proporcionados a la funcin que realizan, sin llegar al
__________________________________________________________________________________________
51/125
extremo contrario (atomizacin).
CDIGO: SERV-03
TIPO: AVISO
DESCRIPCIN:
NOMBRE: ATOMIZACIN DE SERVICIOS
Consiste en disear servicios tan elementales, que algunas funciones necesitarn invocar a
una gran cantidad de ellos.
P.e., se disea una rutina que trata dos funciones alternativas, lo que en s mismo es correcto
porque no son demasiadas, sin embargo hay una funcin que requiere invocar a la rutina con
ambas funciones, primero con una y luego con otra. Si se sabe que una funcin debe cubrir las
dos necesidades, debera disearse un servicio que las cumpla.
ALTERNATIVA:
Disear mdulos espedficos para cada necesidad funcional (pero no elemental), a base de
unificar los accesos necesarios a BBDD en un mdulo.
En el ejemplo expuesto, habra una tercera funcin en la rutina que signifique hacer las otras
dos funciones, con lo cual con una llamada al servicio es suficiente.
CDIGO: SERV-04
TIPO: AVISO
DESCRIPCIN:
NOMBRE: RPLICA DE LA MISMA FUNCIN EN SERVICIOS

DIFERENTES
Un ejemplo sera:
El servicio A valida el cliente y una tarjeta del cliente.
El servicio B valida el cliente y un prstamo del cliente.
Si una transaccin incluyera estos dos productos, llamar a los dos servicios, con lo cual el
cliente habra sido validado dos veces.
ALTERNATIVA:
Disear los servicios conforme a requerimientos especficos, evitando accesos o validaciones
repetidas.
CDIGO: SERV-05
TIPO: AVISO
DESCRIPCIN:
NOMBRE: RUTINA QUE RECUPERA UNA FILA COMPLETA
__________________________________________________________________________________________
52/125
Es una prctica comn disear rutinas generales de acceso a tablas, contemplando las
funciones de leer/insertar/borrar/modificar.
Si la rutina recupera (SELECT) la fila completa, toda transaccin o proceso batch que requiera
alguna informacin de la tabla tendr que llamar a la rutina y sta devolver siempre la fila
completa, aunque en el contexto se necesite slo una pequea parte de las columnas.
ALTERNATIVA:
Disear la recuperacin de columnas en diferentes rutinas, por grupos homogneos de datos,
como p.e. datos personales, econmicos, de morosidad, etc.
Esto permite ajustar el consumo de las rutinas a la necesidad real que se tiene en cada caso.
CDIGO: SERV-06
TIPO: AVISO
DESCRIPCIN:
NOMBRE: USO DE RUTINAS ONLINE EN BATCH O VICEVERSA
Se trata de usar en programas batch rutinas que se disearon para su uso en online, o
viceversa.
Esta prctica tiene varios inconvenientes:
La rutina ejecuta de manera unitaria el mismo tratamiento para todos los registros,
aunque estos, por su agrupacin funcional, solo requieran un tratamiento distinto
cuando vara el criterio de agrupacin.
Si una rutina online es de paginacin y se usa en batch, puede estar devolviendo ms
filas de las necesarias.
Es posible que la rutina online ejecute un SELECT COUNT para contar el nmero de
filas como ayuda para la paginacin, lo que en batch no es necesario.
La rutina batch puede tener DISPLAYs, lo que en online supone un cosumo innecesario
(tambin lo es en batch bajo ciertas condiciones).
ALTERNATIVA:
Disear mdulos y rutinas adaptados al uso que se le va a dar. Slo cuando el entorno de
ejecucin es indiferente se pueden hacer rutinas comunes (p.e. rutinas de fechas, clculos,
formateos, ).
__________________________________________________________________________________________
53/125
MODELO DE DATOS
CDIGO:MD-001
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Utilizacin de atributos multipropsito
Dentro de los modelos de las aplicaciones corporativas se ha detectado que, con la intencin
de reutilizar estructuras de datos, se est dando a ciertas estructuras de informacin
(entidades y atributos) un uso distinto al uso para el que fueron creados. Incluso hay ocasiones
en las que desde el momento de su creacin, se preparan estas estructuras para almacenar
informacin de distinta naturaleza.
As por ejemplo, se pretende incluir en cdigo de persona diversos cdigos de distinta
naturaleza (cliente, no cliente, tercero, prospect). Otro ejemplo es un registro de movimientos
en el que se almacenan contadores que pueden ser a nivel de producto, tipo de evento, cliente
o contrato y se pretende almacenar estos cdigos en un nico atributo (unas veces cdigo de
producto, otras veces cdigo de contrato,).
Normalmente la intencin de crear este tipo de estructuras est fundamentada en la
reutilizacin de las estructuras existentes. Sin embargo, en la mayora de los casos estas
decisiones son errneas y llevan asociadas unas implicaciones (complicacin del
mantenimiento e ineficiencias de los procesos) que deben ser tenidas en cuenta.
Ejemplo de aplicacin del antipatrn:
En esta solucin se incluye el rol de persona con la intencin de codificar las personas tal y
como se estaban codificando terceros y clientes y as tratar de evitar una nueva codificacin.
Las desventajas de esta solucin son:
__________________________________________________________________________________________
54/125
Asignacin de formatos inadecuados (superiores a lo necesario) a los atributos clave.
Agravamiento del impacto por cambios en cualquiera de los conceptos enmascarados.
Complicaciones para localizar componentes en un anlisis de impacto.
No garantiza que se eviten procesos de recodificacin.
En esta solucin, se utiliza el atributo cdigo de persona para almacenar informacin de

distinta naturaleza: en unos casos se guarda el cdigo de cliente, con formato CHAR(10), en
otros casos los cdigos de personas con otro rol y formato muy inferior a CHAR(10) por las
ocurrencias que pueden llegar a tener estas entidades (por ejemplo cdigo de tercero
CHAR(5)). Tanto en un modelo lgico como en un modelo fsico es una solucin desaconsejada
para la codificacin de entidades (ver patrn 2).
Adems, pensemos en la posibilidad de realizar modificaciones a alguno de los cdigos
enmascarados bajo el cdigo de persona; por ejemplo, se incluyen los datos de una nueva
entidad bancaria y no es vlido el formato seleccionado para el cdigo de cliente:
En primer lugar debiera realizarse un anlisis de impacto detectando las tablas en las
que aparece el cdigo de cliente. Todas debieran ser modificadas.
A continuacin habra que contemplar el cdigo de persona que no aparecera de

manera directa en el anlisis de impacto, con el peligro aadido de no tener en cuenta
estos cdigos. No habramos conseguido aislar las personas de la problemtica de los
clientes. Todos los roles se veran impactados.
Si adems, para esta entidad bancaria la clave primaria de cliente se compone de

varios atributos, sera necesario enmascararlos bajo un cdigo. En el patrn 2 se
desaconseja este tipo de soluciones.
Tambin hay que tener en cuenta que es posible que llegasen a coincidir cdigos de distintos
conceptos por lo que no se ahorrara un proceso de recodificacin.
Incluso se ha llegado a plantear que aprovechando esta codificacin se podra llegar a
prescindir de las entidades especficas de cada rol. Es muy desaconsejable esta opcin ya que
procesos que slo traten personas de un rol determinado (por ejemplo un proceso que slo
gestione personas con el rol de tercero) se complicaran al tener que hacer un filtro de
personas por rol previo a cualquier operacin. Adems podran incrementarse los problemas
de bloqueos al acceder todos los procesos a una nica estructura de informacin.
ALTERNATIVA:
En el modelo lgico de datos, que nace desde los requisitos funcionales, no se debe incluir
__________________________________________________________________________________________
55/125
ningn atributo multipropsito. Cada concepto debe dar origen a una entidad y sus distintas
propiedades a distintos atributos. Distintos conceptos dan origen a distintas entidades y
distintas propiedades originan distintos atributos.
En el modelo fsico se contempla otro tipo de requisitos (tiempos de respuesta, seguridad,
informacin histrica) que pueden hacer variar la forma de implementacin. Incluso en estos
casos, es necesario tener en cuenta las implicaciones de este tipo de diseo para no tomar una
decisin inapropiada.
Adems, debe tenerse en cuenta para el modelo fsico que el Centro de Calidad y Certificacin
en una de sus recomendaciones expone que no se debera mezclar bajo un mismo
elemento/atributo cdigos de diferentes naturalezas (formato y longitud).
Ejemplos de aplicacin del patrn
Supongamos que en el modelo de datos se estn tratando personas que pueden ser de cuatro
tipos (roles): cliente, no cliente, tercero o prospect.
Para todas las personas se almacena una informacin comn independiente del rol que
desempea. Adems, dependiendo del rol que desempea en cada entidad se almacena cierta
informacin especfica (informacin especfica de cliente, informacin de tercero,).
patrn (solucin propuesta)
Adems de cumplir los requisitos descritos, en esta solucin se respeta la codificacin de

cliente y tercero existente en la plataforma actual (posiblemente no sera vlida al no
contemplar el requisito de multientidad que obligara a recodificar clientes y terceros). Se
selecciona un nuevo cdigo de persona (cumpliendo las premisas del patrn MD02) que
agrupa ocurrencias de los distintos roles que puede desempear una persona.
Los atributos y relaciones se ubicaran en el nivel que corresponda (persona/ persona entidad/
cliente/ no cliente/ prospect/ tercero). Cada proceso accedera al nivel que correspondiese
pudiendo especializarse (facilita su eficiencia y reutilizacin).
__________________________________________________________________________________________
56/125
__________________________________________________________________________________________
57/125
CDIGO:MD-002
TIPO: ERROR
NOMBRE: Diseo de PKs para cumplir el requisito

multientidad
DESCRIPCIN:
Las aplicaciones corporativas deben disear modelos de datos que soporten ser implantados
en distintas entidades (bancarias o no). Estos modelos deben tener capacidad de absorber
todas las ocurrencias generadas por cualquiera de las entidades y adems deben permitir la
convivencia de ocurrencias de distintas entidades en las mismas estructuras de datos.
Para cada entidad del modelo de datos se define una clave primaria que es el atributo o
conjunto de atributos que identifica de manera nica una ocurrencia de la entidad. Adems, la
clave primaria debe ser mnima (todos los atributos que la forman deben ser necesarios para
la identificacin).
Las claves primarias deben ser estables a lo largo del tiempo ya que estos atributos se
propagan por las distintas entidades y tablas de los modelos y su modificacin suele tener un
fuerte impacto.
La dificultad est en decidir cmo debe ser esta clave primaria para ser capaz de almacenar el
nmero de ocurrencias que deba identificar y cubrir el requisito de multientidad de
aplicaciones corporativas.
Condicionantes como la intencin de no recodificar los conceptos pueden llevar a tomar
decisiones errneas con mucho impacto a futuro y por ello es necesario hacer un anlisis
exhaustivo de cada caso para tomar la solucin ms acertada.
antipatrn (solucin desaconsejada):
Crear un atributo diseado que resulta de la unin de varios cdigos:
Si se enmascara en el cdigo de contrato cdigos de otros conceptos se complicara el proceso

de asignacin de cdigos (debe tener en cuenta banco y contrato para asignar el cdigo) y el
mantenimiento de este tipo de columnas ya que sera complicado hacerla visibles en un
anlisis de impacto ante un hipottico cambio en alguno de los subcdigos que la componen.
Tambin se complican los accesos a estas tablas ya que si se quisiera preguntar por alguno de
los conceptos que componen el cdigo (por ejemplo contratos de cierto banco) habra que
__________________________________________________________________________________________
58/125
tener claro qu posiciones identifican al concepto en el cdigo (en este caso el banco se
identifica con las 6 primeras posiciones) y realizar bsquedas por patrones (LIKE PPEEEE*) que
son ms costosas.
Si adems cada entidad estructura el cdigo de distinta manera, esta solucin obliga a disear
procesos especficos para cada una de las entidades (cada una utiliza el cdigo de distinta
manera) y obliga a mantener la misma informacin varias veces (cdigo de banco como parte
del identificador de contrato para una entidad o pas determinado y cdigo de banco como
atributo para ser utilizado por el resto entidades).
Adems, si se pretende incluir los contratos procedentes de distintas entidades en el mismo

cdigo, existe el riesgo de que coincidan los cdigos para distintos contratos de distintas
entidades. Esto podra solventarse con un proceso de recodificacin incluyendo la lgica en el
proceso de asignacin de cdigos (aade complicacin al proceso) o ampliando la clave
primaria con la inclusin del identificador de banco.
Para tomarse una decisin como la planteada en esta solucin debe tenerse muy claro cul
es el beneficio esperado.
ALTERNATIVA:
Por requerimiento de OCTA, una vez analizadas ventajas e inconvenientes, todo cdigo debe
tener formato alfanumrico, salvo los que utilizan el objeto sequence. Los formatos numricos
se reservan para atributos que sean usados para realizar operaciones aritmticas.
Adems la longitud del cdigo debe adecuarse al nmero de ocurrencias a codificar. As por
ejemplo, si una entidad bancaria no va a tener ms de 99 millones de clientes, no tendra
sentido utilizar un formato superior a CHAR(8) para codificar clientes.
Ejemplos de aplicacin del patrn
Supongamos que se quiere codificar contratos. La existencia del contrato siempre debe estar
condicionada por la existencia de una entidad. Cada entidad codifica sus contratos y no cabe
__________________________________________________________________________________________
59/125
la posibilidad de que un contrato se codifique de manera diferente para dos entidades.

Si una entidad estima que no conseguir superar los 1000 millones de contratos sera
suficiente con un CHAR(10) para codificar el contrato.
Se desaconseja la utilizacin de atributos diseados a partir de la unin de varios cdigos de
conceptos ya que el mantenimiento de este tipo de cdigos se complica.
__________________________________________________________________________________________
60/125
CDIGO:MD-003
TIPO: ERROR
NOMBRE: Implementacin del requisito multientidad en

modelos de datos
DESCRIPCIN:
Multientidad
Las aplicaciones corporativas deben disear modelos de datos que soporten ser implantados
en distintas entidades y pases. Una nica base de datos debiera soportar informacin de varias
entidades en uno o varios pases.
a)
Estructura de la entidad Entidad Bancaria
En Tablas Corporativas la relacin entre "pas" y "entidad bancaria" se realiza a travs de la

plaza bancaria (se corresponde con un tipo de agrupacin geogrfica), almacenndose en la
tabla de "entidad bancaria" el pas al que pertenece la plaza bancaria.
Al no ser dependiente la "entidad bancaria" del pas, simplifica la relacin con otras entidades
dependientes de la "entidad bancaria" que no debern incluir el pas entre sus atributos.
b)
Codificacin del resto de entidades del modelo
Slo se incluir la Entidad en las claves primarias de las entidades/tablas en las que sea
estrictamente necesario para el cumplimiento de un requisito. Nunca podr incluirse Pas y
Entidad en las claves Primarias para habilitar distintas codificaciones de un mismo concepto.
De este modo y como norma general, las entidades de tipificacin con estructura del tipo
cdigo + DESCRIPCIN: no necesitan incluir la entidad en su clave primaria.
__________________________________________________________________________________________
61/125
antipatrn (solucin desaconsejada)

La PK de la entidad de tipos de medio de comunicacin sera el "cdigo de tipo de medio de
comunicacin" junto con el cdigo de entidad.
Esta solucin abrira la posibilidad de asignar distintos cdigos a un mismo tipo de medio de
comunicacin (uno por entidad). Las desventajas de esta solucin son:
Replicacin de ocurrencias en la base de datos: un mismo concepto se almacena

tantas veces como entidades existan. Todas las relaciones que partan de la entidad
afectada tambin ven incrementado su nmero de ocurrencias. Posiblemente tambin
sea necesario generar tablas que mantengan las equivalencias entre los distintos
cdigos asignados a un mismo concepto (ms ocurrencias en la base de Datos).
Complicacin de los procesos: si algn proceso debe acceder a los datos de forma
cruzada, el proceso se vera obligado a pasar en un primer momento por las tablas de
equivalencia para obtener los distintos cdigos asignados al concepto. Por ejemplo, si
un mismo producto se codifica de formas distintas en cada entidad, para averiguar de
manera global cuntas veces se ha contratado el producto sera necesario primero
obtener todas las distintas codificaciones del producto (acceso a tabla de relacin entre
codificaciones) para despus ver cuntas veces se ha contratado.
Podra pensarse que la con esta solucin se hace ms flexible el sistema. Esto no es as porque
no evita la conversin de cdigos ya que para ser completamente flexible El nuevo cdigo
debiera contemplar todas las posibilidades de codificacin de las entidades involucradas
(CHAR(5)? CHAR(10)? CHAR(20?)?
__________________________________________________________________________________________
62/125
ALTERNATIVA:
Ejemplos de aplicacin del patrn de modelado del requisito "Multientidad"
Siempre debe evitarse la generacin de codificaciones dobles que obliguen a mantener tablas
de traduccin y compliquen procesos cruzados.
Por ejemplo:
Tipos de medios de comunicacin: Telfono, correo ordinario, correo electrnico, fax,
patrn (solucin recomendada) La PK de la entidad de tipos de medio de comunicacin sera el

"cdigo de tipo de medio de comunicacin".
En caso de existir la necesidad de restringir ocurrencias de una entidad por Pas y/o Entidad,
sera necesario crearse una entidad de relacin. As por ejemplo, si se quiere restringir que slo
ciertos tipos de medio de comunicacin sean vlidos para la entidad BBVA-Espaa, debiera
quedar de la siguiente forma:
En caso de necesitar varias codificaciones para un concepto tambin sera necesaria una
entidad que diera cabida a la codificacin mltiple. As por ejemplo, para reflejar distintas
codificaciones para una Entidad (cdigo CSB, cdigo IBAN, cdigo SWIFT, codificaciones
internas del pas,) quedara de esta forma:
__________________________________________________________________________________________
63/125
__________________________________________________________________________________________
64/125
CDIGO:MD-004
TIPO: AVISO
NOMBRE: Implementacin del requisito multicanal en

modelos de datos
DESCRIPCIN:
Va modelo de datos no se puede garantizar que una aplicacin cumpla el requisito
"multicanal". El dato del canal recogido en la transaccin no suele guardarse en Base de
Datos.
ALTERNATIVA:
nicamente sera necesario contemplar el canal en un modelo de datos cuando las
caractersticas de un concepto cambian por canal o el tratamiento vara por canal.
__________________________________________________________________________________________
65/125
CDIGO:MD-005
TIPO: ERROR
NOMBRE: Implementacin del requisito multidioma en

modelos de datos operacionales
DESCRIPCIN:
Las aplicaciones corporativas deben disear sus sistemas de forma que garanticen el
cumplimiento del requisito de multiidioma.
Desde el punto de vista del modelo de datos, implica considerar el requisito de multiidioma
respecto a la necesidad de por ejemplo, tener en cuenta que en un pas se hablen diferentes
idiomas en diferentes zonas geogrficas o se decida asociar un idioma al centro, diferente al
de la entidad, en funcin de su ubicacin geogrfica
Con objeto de estandarizar los diseos de los modelos de datos y dar una solucin adecuada
al problema, tambin desde el punto de vista de Optimizacin, se propone este patrn
para guiar a los equipos de desarrollo en el diseo de entidades de datos del tipo cdigodescripcin, en los que se garantice la adecuada traduccin de las mismas a los idiomas
aplicables en cada caso.
Antipatrn (solucin desaconsejada):
Incluir en cada tabla de definicin de un concepto las traducciones de sus literales replicando
las ocurrencias por cada idioma necesitado.
__________________________________________________________________________________________
66/125
ALTERNATIVA:
Implementacin en arquitectura:
La infraestructura necesaria para posibilitar esta casustica, es proporcionada por

Arquitectura, tratando que sea lo ms transparente posible a los aplicativos. Existe una tabla
de traduccin nica en la aplicacin QPIP de arquitectura (TQPIPLIT) a la que se recurrir para
obtener las descripciones traducidas de los conceptos contenidos en las tablas de cada
aplicacin.
Implementacin en cada aplicativo:
La solucin de traduccin se resuelve directamente en el modelo fsico de datos de

cada aplicacin, no reflejndose en el modelo lgico de datos.
No se incluir el idioma como parte de la clave primaria en las entidades que definen
de forma lgica los conceptos de cada aplicacin, para evitar la replicacin innecesaria de este
dato en todas las relaciones en las que participe la entidad.
En el modelo lgico de datos la entidad que define el concepto contendr un atributo

con la descripcin del mismo (que guardar la descripcin en el idioma por defecto de la
aplicacin,).
En el modelo fsico de datos la tabla que guarda este concepto contendr el campo
COD_IDIOMISO (que guardar el cdigo de idioma por defecto del aplicativo) y
COD_TRADUCC (para almacenar el cdigo de traduccin dado por arquitectura para cada
cdigo del concepto dado de alta). La relacin con el idioma por defecto en la que se define el
concepto no se explicitar ni en el modelo lgico ni en el fsico del concepto, con lo que los
modelos de aplicacin quedan aislados de esta problemtica.
Ejemplos de aplicacin del principio funcional en el modelo de datos
Si se desea mantener una tabla de tipos de bloqueo aplicables a una cuenta (Orden Judicial,
Libreta Extraviada, No permitir abonos, No permitir cargos, .) y mantener las descripciones
de estos tipos de bloqueos en los diferentes idiomas con los que trabaja el banco:
patrn (solucin recomendada) en el modelo lgico de datos:
Se crear una entidad (TKPSATBQ) que defina el concepto tipo de bloqueo con el cdigo de
tipo de bloqueo (COD_TIPBLQT), su descripcin (DES_TIPBLQT) y resto de atributos del tipo
de bloqueo.
__________________________________________________________________________________________
67/125
patrn (solucin recomendada) en el modelo fsico de datos:

En la tabla Tipos de Bloqueos aplicables a una cuenta (TKPSATBQ) se mantendrn los
cdigos de tipos de bloqueo(COD_TIPBLQT), la descripcin de estos tipos de bloqueo en el
idioma por defecto (DES_TIPBLQT), cdigo de idioma por defecto (COD_IDIOMISO) y el cdigo
de traduccin (COD_TRADUCC) correspondiente al tipo de bloqueo (por ejemplo: Libreta
Extraviada) en la tabla de traduccin. Si el proceso necesita la traduccin de este concepto en
otro idioma acceder con el cdigo de traduccin y el cdigo de idioma a la tabla
TRADUCCION para obtenerlo.
__________________________________________________________________________________________
68/125
CDIGO:MD-006
TIPO: ERROR
NOMBRE: Implementacin del requisito multidioma en

modelos de datos de aplicaciones Informacionales
DESCRIPCIN:
Las aplicaciones informacionales deben disear sus sistemas cumpliendo el requisito de
mulitidioma y respondiendo en rendimiento a la herramienta final de explotacin en BBVA,
Microstrategy.
Desde el punto de vista del modelo de datos, implica considerar el requisito de multidioma
respecto a la necesidad de tener en cuenta que los usuarios requieran la necesidad de diferentes
idiomas para un pas determinado.
Con objeto de estandarizar los diseos de los modelos de datos y dar una solucin adecuada al
problema, tambin desde el punto de vista de Optimizacin, se propone este patrn para guiar a
los equipos de desarrollo en el diseo de entidades de datos del tipo cdigo-descripcin, en los
que se garantice la adecuada traduccin de las mismas a los idiomas aplicables en cada caso.
ALTERNATIVA:
La implementacin de multidioma en cada aplicativo Informacional que se explote con
Microstrategy se resuelve directamente en el modelo fsico de datos, no reflejndose en el modelo
lgico de datos.
-
Para cada tabla de cdigo descripcin se definir una tabla de traduccin incluyendo el
idioma como parte de la clave primaria.
Por cada idioma se crear una vista para traducir el concepto. Est solucin es necesaria
para que la herramienta de explotacin Microstrategy pueda resolver el multidioma de
forma automtica.
Ejemplos de aplicacin del principio funcional en el modelo de datos

Si se desea mantener una tabla de cargos funcionales y mantener las descripciones de estos cargos
funcionales en los idiomas con los que trabaja el banco:
Solucin en el modelo lgico de datos:
Se crear una entidad que defina el concepto de cargo funcional, cdigo de cargo funcional y su
descripcin:
__________________________________________________________________________________________
69/125
CARGO FUNCIONAL
CODIGO_CARGO
<pi> COD_ALF_3
<M>
DES CORTA CARGO FUNCIONAL
DES_NOMBRE <M>
Solucin en el modelo fsico de datos:

La entidad de Cargos funcionales evolucionar al modelo fsico de la misma forma.
CARGO FUNCIONAL
CODIGO_CARGO
FECHA DE CIERRE
AUDITORIA USUARIO
AUDITORIA TIMESTAMP
VARCHAR2(3)
DATE
VARCHAR2(20)
VARCHAR2(8)
TIMESTAMP
Adems se crear una tabla aislada donde se incluya el idioma en la pk, de la siguiente forma :
CARGO FUNCIONAL IDIOMA
CODIGO_CARGO
FECHA DE CIERRE
CODIGO_IDIOMA_ISO
AUDITORIA USUARIO
AUDITORIA TIMESTAMP
...
VARCHAR2(3) <pk>
DATE
<pk>
VARCHAR2(2) <pk>
VARCHAR2(20)
VARCHAR2(8)
TIMESTAMP
Se crear tantas vistas como idiomas se necesite filtrando por idioma en cada vista.
CARGO FUNCIONAL_ES
CARGO FUNCIONAL_EN
CARGO FUNCIONAL_PT
CODIGO_CARGO
FECHA DE CIERRE
AUDITORIA USUARIO
AUDITORIA TIMESTAMP
CODIGO_CARGO
FECHA DE CIERRE
AUDITORIA USUARIO
AUDITORIA TIMESTAMP
CODIGO_CARGO
FECHA DE CIERRE
AUDITORIA USUARIO
AUDITORIA TIMESTAMP
KYRI.TKYRIFID
...
KYRI.TKYRIFID
...
KYRI.TKYRIFID
...
Internamente en Microstrategy se configurar para los Cargos funcionales Idioma la vista a la

cual recuperar la traduccin por idioma.
__________________________________________________________________________________________
70/125
CDIGO:MD-007
TIPO: ERROR
NOMBRE: Implementacin del requisito multipas en modelo

de datos
DESCRIPCIN:
Generalmente el requisito multipas est incluido en el requisito multientidad, al ser este
ltimo de un nivel inferior.
Si un modelo de datos cumple el requisito multientidad por defecto cumple el requisito
multipas.
Si se diera el caso de una aplicacin que necesitara ser multipas sin tener en cuenta la entidad
bancaria, en ese caso slo se incluir el Pas en las claves primarias de las entidades/tablas en
las que sea estrictamente necesario para el cumplimiento de un requisito. Nunca podr
incluirse Pas en las claves Primarias para habilitar distintas codificaciones de un mismo
concepto.
ALTERNATIVA:
De este modo y como norma general, las entidades que representen conceptos de tipificacin
con estructura del tipo cdigo + descripcin no necesitan incluir el pas en su clave primaria.
En caso de existir la necesidad de restringir ocurrencias de un concepto por Pas , sera
necesario crearse una entidad de relacin, donde se guarde la relacin de qu ocurrencias de
un concepto cualquiera son vlidos por cada pas
__________________________________________________________________________________________
71/125
CDIGO:MD-008
TIPO: INFORMATIVO
NOMBRE: Informacin necesaria en cada nivel de modelado

de datos (modelo lgico y fsico de datos)
DESCRIPCIN:
Frecuentemente se confunden los trminos de modelo lgico de datos y modelo de alto nivel
en el que slo sera necesario incluir macro entidades y los principales atributos.
Tambin, otro error frecuente es incluir informacin del modelo fsico de datos en el modelo
lgico de datos.
ALTERNATIVA:
En un modelo lgico de datos es necesario incluir toda aquella informacin que sea relevante
para el negocio, definicin de los conceptos de negocio y las relaciones existente entre ellos.
Adems hay que tener en cuenta que es independiente de la plataforma tecnolgica en que se
implemente.
Adems de la informacin de negocio, hay que dejar para el modelo fsico todos los
condicionantes y limitaciones derivadas de la plataforma tecnolgica elegida para la
implementacin de la aplicacin, que pueden incidir en el tiempo de respuesta o el espacio de
disco necesario (informacin histrica, informacin redundada, informacin calculada,
indicadores que eviten accesos,). Tambin, para tener mayor claridad en los diseos, se ha
decidido dejar para el modelo fsico de datos la informacin referente a auditora y todo
aquello que posibilite el tratamiento del requisito multiidioma.
__________________________________________________________________________________________
72/125
CDIGO:MD-009
TIPO: ERROR
NOMBRE: Utilizacin de Tablas SGAT en aplicaciones

operacionales
DESCRIPCIN:
Se ha detectado que las aplicaciones intentan hacer un uso indiscriminado de SGAT.
Para que una tabla pueda ser administrada por SGAT debe tener cumplir una serie de
caractersticas:
La tabla debe ser del tipo cdigo-descripcin.
Los datos deben ser estables, con poca volatilidad (nmero reducido de bajas y
modificaciones).
El total de filas que contenga no debe ser excesivo para evitar problemas de
rendimiento en las consultas on-line (entre 100 y 200 filas, aproximadamente).
No puede estar relacionada con ninguna otra entidad/tabla SGAT o NO SAGAT.
Las tablas SGAT presentan tambin una serie de restricciones a tener en cuenta para decidir
su utilizacin:
Slo el campo de descripcin tiene la capacidad multiidioma.
Adems de los campos de cdigo y descripciones se permiten otros atributos, hasta

un mximo de dos. Estos atributos no pueden contener texto susceptible de
tratamiento multiidioma.
La longitud del campo cdigo est establecida entre 1 y 10 caracteres.
La descripcin tiene una longitud mxima de 80 caracteres.
El mantenimiento slo se puede realizar a travs de la aplicacin proporcionada por

Arquitectura.
La extraccin o consulta de datos slo se puede realizar a travs de un mdulo de

Arquitectura.
antipatrn (solucin desaconsejada)

Surge la necesidad de crear una tabla para mantener un subconjunto de un concepto ya
existente (oficinas, productos, clientes, contratos, contrapartidas, ). Como SGAT no puede
mantener relaciones con otras tablas y no puede garantizar que los cdigos introducidos sean
__________________________________________________________________________________________
73/125
vlidos, No se debe crear en SGAT, se deber crear una tabla propia de la aplicacin
solicitante en el gestor utilizado.
Surge la necesidad de crear una tabla de subtipos. Como en SGAT no se puede mantener la
relacin con la entidad/tabla tipo, tampoco est permitida su creacin en SGAT, igualmente
se deber crear una tabla propia de la aplicacin solicitante en el gestor utilizado.
ALTERNATIVA:
Las entidades que Arquitectura de Datos acepta su implementacin como tabla SGAT se
distinguen en el Modelo Lgico de Datos porque se selecciona para ellas el Stereotype:
Entidad SGAT en la ventana en la que se documentan los datos de la entidad.
La tabla SGAT no aparecer en el Modelo Fsico de Datos de la aplicacin.
__________________________________________________________________________________________
74/125
NCAR
CDIGO: NACAR-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Flujos inconexos o con servicios sin salida
Antipatrn de tecnologa Ncar que detecta las situaciones en la que los flujos no finalizan, o
no lo hacen por un servicio nulo de fin de flujo arquitectura (ATAENLxxxxx).
ALTERNATIVA:
Revisar que todos los servicios dentro del flujo tengan transiciones de salida y las transiciones
de finalizacin lleguen a servicios nulos de arquitectura (ATAENLxxxxx).
__________________________________________________________________________________________
75/125
CDIGO: NACAR-02
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Control de retornos en flujos
Antipatrn de tecnologa Ncar que detecta las situaciones en las que los servicios de llamada
a un flujo no tienen en cuenta todas las posibles salidas que el flujo llamado tiene definidas.
ALTERNATIVA:
Verificar que el nmero de salidas controladas en las llamadas coincide con las que contiene
el flujo o servicio llamado. Si se controlan ms salidas que las definidas se marca como aviso,
pero si contiene menos salidas que las definidas se indica como error y puede producir
bloqueos de aplicacin.
__________________________________________________________________________________________
76/125
CDIGO: NACAR-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Flujos nulos
Antipatrn de tecnologa Ncar que detecta las llamadas a flujos nulos, entendiendo por nulo
aquel flujo que contiene una bola de inicio y una de fin (no procesa nada).
ALTERNATIVA:
No est permitido la utilizacin de flujos nulos dado que no procesan ninguna informacin. Se
deben eliminar y si su eliminacin origina otro antipatrn de otra tipologa se debe estudiar
una solucin en mayor profundidad (rediseo total o parcial del flujo, segn proceda).
__________________________________________________________________________________________
77/125
CDIGO: NACAR-04
TIPO: AVISO
DESCRIPCIN:
NOMBRE: Concatenacin de condiciones
Antipatrn de tecnologa Ncar que detecta las situaciones en las que se concatenan ms de
dos condiciones. Esta situacin puede producir una lentitud considerable en la ejecucin de
programas (segn numero de concatenaciones) o incluso bloquear la ejecucin.
ALTERNATIVA:
Se debe analizar la lgica de las condiciones para ver como solventarla.
-
Se pueden suprimir si no son necesarias.

Implementar un servicio de negocio que aglutine dicha lgica de las condiciones.
Llevar dicha lgica a capas inferiores de la aplicacin (Lgica de negocio).
__________________________________________________________________________________________
78/125
CDIGO: NACAR-05
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Condiciones o evaluadores incompletos
Antipatrn de tecnologa Ncar que detecta las situaciones en las que las condiciones o
evaluadores no presentan consistencia. Ej. Condiciones con una salida true o false,
Evaluadores cuyo nmero de PAR.CASOS no coincida con el numero de flechas que salen del
evaluador.
ALTERNATIVA:
Para el caso de las condiciones, aadir el caso que falte (true o false).
Para el caso de evaluadores, revisar que coinciden el numero de PAR.CASOS con las opciones
de salida del evaluador y tener en cuenta que se debe aadir la opcin default.
__________________________________________________________________________________________
79/125
CDIGO: NACAR-06
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Condiciones antes de fin de flujo
Antipatrn de tecnologa Ncar que detecta las condiciones que preceden a un estado de fin
de flujo (ATAENLxxxxx).
ALTERNATIVA:
La presencia de condiciones antes de fin de flujo puede producir bloqueos.
-

Sustituir por un evaluador que aglutine todas las opciones + default.
__________________________________________________________________________________________
80/125
CDIGO: NACAR-07
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Eventos de arquitectura en ventanas
Antipatrn de tecnologa Ncar que detecta las situaciones en las que se utilizan eventos de
arquitectura en los controles de las ventanas. Para no experimentar efectos indeseados, los
eventos de los controles de la ventana tiene que ser del tipo UUAAEVnnnnnnnnn.
ALTERNATIVA:
Sustituir los eventos de arquitectura por eventos de la aplicacin (UUAAEVnnnnnnnn).
__________________________________________________________________________________________
81/125
CDIGO: NACAR-08
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Control de retornos en SD y SG
Antipatrn de tecnologa Ncar que detecta las situaciones en la que no se controlan

adecuadamente los retornos de los servicios de datos y genricos.
ALTERNATIVA:
Completar las salidas que falten en los servicios para que el numero de retornos sea
coherente con el tipo de servicio.
__________________________________________________________________________________________
82/125
CDIGO: NACAR-09
TIPO: AVISO
DESCRIPCIN:
NOMBRE: Varias ventanas
Antipatrn de tecnologa Ncar que detecta las situaciones en las que un flujo contiene ms
de una ventana.
ALTERNATIVA:
Es conveniente redisear el flujo considerando que partes deben de modularizarse en flujos
nuevos.
__________________________________________________________________________________________
83/125
CDIGO: NACAR-10
TIPO: AVISO
DESCRIPCIN:
NOMBRE: Concatenacin evaluadores o condiciones (Aviso)
Antipatrn de tecnologa Ncar que detecta las situaciones en las que las condiciones o
evaluadores (o combinacin de ambos) que se encuentran concatenados. (Aviso).
ALTERNATIVA:
Se debe analizar la lgica de las condiciones para ver como solventarla.
-

__________________________________________________________________________________________
84/125
CDIGO: NACAR-11
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Varios eventos de inicio
Antipatrn de tecnologa Ncar que detecta los flujos que tienen ms de un evento de inicio.
ALTERNATIVA:
Se debe eliminar los eventos de inicio duplicados.
__________________________________________________________________________________________
85/125
CDIGO: NACAR-12
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Uso incorrecto de servicios genricos
Antipatrn de tecnologa Ncar que detecta el uso incorrecto de los servicios genricos
ATAESG00004 y ATAESG00048,
Ej. ATAESG00048.
Debe utilizarse para invocar a operaciones de otra UUAA.
Ej. ATAESG00004
Debe utilizarse para invocar flujos de forma dinmica.
Tened en cuenta el rendimiento en el uso masivo de servicios.
ALTERNATIVA:
El servicio ATAESG00048 no se debe utilizar para invocar flujos de la misma UUAA. Si se
necesita invocar un flujo de la misma UUAA se invocara llamando al UUAAFLxxxxx
correspondiente.
El servicio de llamada de flujos ligero ATAESG00004 se debe utilizar para invocar a flujos
dinmicamente, en ningn caso se debe utilizar llamando a un nico flujo (UUAAFLxxxxx).
__________________________________________________________________________________________
86/125
CDIGO: NACAR-13
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Uso incorrecto del fin de flujo ATAENL00002
Antipatrn de tecnologa Ncar que detecta el uso incorrecto del servicio ATAENL00002.
ALTERNATIVA:
No se debe utilizar en los flujos servicios finales ATAENL00002.
Se consideran de uso correcto los estados finales de flujo ATAENL00001, ATAENL00003 y
ATAENL00004.
__________________________________________________________________________________________
87/125
CDIGO: NACAR-14
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Eventos iguales
Antipatrn de tecnologa Ncar que detecta estados que tienen varias salidas con el mismo
cdigo de evento.
ALTERNATIVA:
Se deben modificar los eventos que tengan el mismo cdigo de evento por otros eventos. El
objetivo es no presentar ambigedad de caminos en la ejecucin del flujo (no sabe por donde
continuar).
__________________________________________________________________________________________
88/125
CDIGO: NACAR-15
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: Mapeos redundantes
Antipatrn de tecnologa Ncar que detecta mapeos en los que se hace un uso ineficiente del
contexto de flujo o del Servicio siguienteServicio evento.
ALTERNATIVA:
Si el dato mapeado se utiliza en un estado posterior al siguiente se debe hacer uso adecuado
de los contextos para almacenarlo.
__________________________________________________________________________________________
89/125
CDIGO: NACAR-16
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: Secuencias largas de SD o SG.
Antipatrn de tecnologa Ncar que detecta secuencias que contengan ms de tres servicios
de datos o genricos consecutivos. Estas secuencias pueden producir retrasos considerables
entre una ventana y otra (dependiendo de la naturaleza del servicio de datos). No est
recomendado tener ms de tres.
ALTERNATIVA:
Intentar, en la medida de lo posible no poner todos los servicios de datos juntos, sin tener
interaccin con el usuario.
__________________________________________________________________________________________
90/125
NOMBRE: Antipatrones no automatizables.

CDIGO: NACAR-17
TIPO: AVISO
DESCRIPCIN:
Se detalla una relacin de casos de antipatrones no automatizables mediante herramientas y
que el equipo de ACS revisa de forma manual.
Mapeos o Pasos de flujo inactivos (tipificacin Aviso)
No deben existir pasos de flujo ni mapeos inactivos en los flujos del DCD cuyo XML va a ser
implantado en produccin.
Correcta utilizacin de Servicios Genricos (tipificacin Aviso)
Se revisa la correcta utilizacin de Servicios Genricos. Hay servicios pensados para ser
utilizados de forma dinmica, nunca esttica (ATAESG00004, ATAESG00002, ATAESG00003,
).
Servicios de Negocio Nulos (tipificacin Error)
No deben utilizarse servicios de negocio nulos.
Flujos innecesarios (tipificacin Error)
No deben utilizarse flujos cuya existencia sea innecesaria. Algunos de estos flujos son de los
siguientes tipos:
Flujo que invoca nicamente a un flujo.
Flujo que invoca nicamente a una ventana.
Flujo que contiene nicamente condicionales o evaluadores.
Flujo con un nico servicio de datos (aunque contenga sus posibles mensajes).
Flujo con un nico servicio genrico (aunque contenga sus posibles mensajes).
Cualquiera de los casos anteriores junto con condiciones o evaluadores.
Flujo del tipo INICIO - paso de flujo FIN con uno o varios mapeos.
Concatenacin Condiciones/Evaluadores (tipificacin Aviso)
Existe un tipo de anidacin, concretamente la anidacin en rbol, que la herramienta no es
capaz de detectar pero se considera un antipatrn puesto que consta de ms de 2
condiciones/evaluadores/la suma de ambos anidados.
Un ejemplo sera una condicin que por el True va a un evaluador/condicin y por el False va
a otra condicin/evaluador.
Revisin de mapeos (tipificacin Aviso)
Se revisa si se han utilizado los valores Con Vuelta/Sin Vuelta y Por Valor/Por Referencia con
sentido o dejndolos por defecto.
ALTERNATIVA:
__________________________________________________________________________________________
91/125
Estos casos se estudian en detalle y su solucin puede variar (dependiendo del caso).
En la mayora de los casos las opciones son:
Eliminacin de pasos inactivos (en las versiones que van a produccin)
Estudiar si aplica o no aplica utilizar servicio genrico, sustitucin por otro servicio.
Eliminacin de servicios de negocio nulos, llevando rutinas si las hay hacia los mapeos.
Rediseo eliminando el flujo innecesario llevndose los componentes al flujo llamante.
Sustitucin de las condiciones por un servicio de negocio que aglutine toda la logica (o la
mayor parte) implementada en las condiciones.
Analizar cuando procede tipar el mapeo con vuelta o sin vuelta.
__________________________________________________________________________________________
92/125
BOINAS VERDES
CDIGO: BV-01
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de productos en la entrega a Boinas

Verdes
Dentro del circuito de construccin de aplicaciones Nacar, como paso previo a la entrega a
construccin a factora el equipo de Boinas Verdes realiza una revisin formal del diseo de
los componentes y emite un resultado sobre el mismo (F111).
El primer paso a comprobar por el equipo de Boinas Verdes es que se han entregado todos los
componentes que pertenecen a la entrega.
-
Modelos del proyecto y documentacin de diseo asociada. El diseo debe ser

entregado en la forma en la que se va a realizar la entrega a factora.Se contemplan
dos posibilidades:
1. Modelo (emx con el perfil de Arquitectura asociado) + publicacin html
o
2. Modelo (emx con el perfil de Arquitectura asociado o mdl) + Soda.
Entregables a Factora para poder revisar toda la documentacin que conforma la
entrega asociada al modelo (aspecto visual de presentacin , prototipo, copys de
transacciones , C204, ..)
F011. Tipificacin de los casos de uso.

Persona identificada para darnos soporte durante el tiempo que dure la revisin y un
telfono de contacto.
F203. Volumen de casos de uso y planificacin por cada uno de los proyectos.
Casos de Uso que interese (a los responsables de la aplicacin) que sean auditados
principalmente (opcional)
Plataforma y estndar de diseo Gua Bsica Diseo NACAR-RSA utilizada.
Documento F101 de estndares de diseo NACAR utilizados por el proyecto (si es el
caso).
Esqueletos .cmpt a entregar a factora.
ALTERNATIVA:
Completar todos los productos necesarios para que la entrega sea correcta.
__________________________________________________________________________________________
93/125
CDIGO: BV-02
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de puntos generales
Se revisan los aspectos generales sobre los productos, el componente se revisa siguiendo todos los
puntos y marcando si cumplen la norma o no. En el caso de incumplimiento se rellena en la casilla
descripcin el motivo por el que se incumple el punto. Los puntos que hacen referencia a la gua
de diseo, indican en la columna Referencia a norma el punto donde a aparecen en el
documento Norma de diseo de aplicaciones Nacar.
PUNTOS A
REVISAR
GENERALES
Estructura del
1. (paquete)
diseo ajustado a Unidad
norma
Funcional
1.1 (paquete)
Vista Caso de
Uso ( 1 nico
caso de uso)
1.1.1 (paquete)
Modelo
Procesos (MPxxx)
1.2 (paquete)
Vista Lgica
1.2.1 (paquete)
Modelo Lgico
(ML-xxx)
1.2.2 (paquete)
Modelo Fsico
(MF -xxx)
1.2.3 (paquete)
Objetos No
Propietarios
(opcional)
El modelo est
O bien con
apoyado en el
keywords
perfil NACAR
apoyados en
para estereotipos estereotipos y
y atributos
atributos de la
gua
Inconsistencias
entre diagramas
funcional y
tcnico
El diagrama
Existe una
tcnico es
correspondencia
coherente con la entre lo que se
definicin de
incluye en el
clases incluidas
diagrama tcnico
en el modelo
y lo que se
recoge en el
modelo lgico y
Cumple Comentario Tipo de error
Referencia
en Norma
INCOMPLETO
3,1,2 3.3.1
3.3.3
NORMA
3.7.2 - 3.7.3 3.7.4 - 3.8.2 3.8.4 - 3.9.1 y

3.11
INCONSISTENCIA
INCONSISTENCIA
__________________________________________________________________________________________
94/125
objetos no
propietarios
El estereotipo
multiidioma se
aplica y est
rellenado
adecuadamente
Revisin que el
caso de uso
dispone de
informacin de
versionado.
Si se trata de un
clon o
modificacin se
indica de forma
clara cul es el
origen del clon y
en qu consisten
las
modificaciones
Para flujos
nuevos, cada CU
existe un nico
estereotipo
VERSIONADO y
viene relleno
respecto a
Norma.
Estereotipos
Locale
INCOMPLETO
3.9.11
Para el caso de
flujos
modificados o
clonados
INCOMPLETO
3.4
Se debe indicar
en el estereotipo
versionado y
slo aplica para
casos de uso
bajo la norma
RSA, para
anteriores
normas (Por ej:
ROSE) NO
No se permite
crear un caso de
uso especfico
para incluir el
versionado en el
diagrama como
un componente
diferente
INCOMPLETO
3.4
INCOMPLETO
??
ALTERNATIVA:
El diseo debe ser corregido conforme a los incumplimientos indicados hasta que cumpla la
normativa vigente. Se efectan tantas revisiones (entregas y correcciones por parte de Boinas
Verdes) como sean necesarias hasta que el diseo este conforme a la norma.
__________________________________________________________________________________________
95/125
CDIGO: BV-03
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de documentacin del diseo
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes la
documentacin de diseo.
PUNTOS A
REVISAR
GENERALE
S
Cumpl Comentari
Tipo de error
e
o
Referenci
a en
Norma
DOCUMENTACION
G.D.
1
Generacin
Documentacin
de entrega del
modelo
(SODA/HTML)
SI
G.D.
2
Documentacin
adjunta
necesaria al
modelo incluido
en entrega
Aspecto visual SI
presentacin,
txt de copys
de
transacciones,
etc...
G.D.
3
Existe
documentacin
que
complementa al
modelos y
ofrece
informacin de
contexto
Si no existe
informacin
dentro del
modelo,
debera
completarse
con
documentaci
n adjunta que
aporte sta
SI
DOCUMENTACIO
N
INCOMPLETO
DOCUMENTACIO
N
__________________________________________________________________________________________
96/125
G.D.
4
El diseo
tcnico necesita
apoyarse en
documentacin
externa no
considerada en
norma
G.D.
5
Documentacin
adicional al
modelo incluido
en entrega es
coherente con
modelo
G.D.
6
Existencia de
los esqueletos
generados a
partir del
modelo UML
(ficheros .cmpt,
xmi)
G.D.
7
Coherencia de
los esqueletos
generados a
partir del
modelo UML
(ficheros .cmpt,
xmi) con el
diagrama
tcnico
entregado en el
modelo
SI
NORMA
Por ejemplo
prototipo ,
C204,
SI
INCONSISTENCIA
Existencia
ficheros .cmpt
generados a
partir de .xmi
SI
INCOMPLETO
SI
INCONSISTENCIA
ALTERNATIVA:
__________________________________________________________________________________________
97/125
CDIGO: BV-04
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de casos de uso
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes
al anlisis de casos de uso.
PUNTOS A
REVISAR
GENERALES
Cumple Comentario Tipo de error
Referencia
en Norma
ANLISIS
REVISIN DE CASO DE USO
A.1
Verificar la
existencia y revisar
Diagramas de Casos
de Uso
NORMA
3.5
A.2
Revisar el Diagrama
de Casos de Uso (si
est bien
estereotipado):
Definicin de
actores y procesos
NORMA
A.3
Revisar la
documentacin del
diagrama Caso de
Uso
DOCUMENTACION 3.3.1
A.4
Diagrama de Caso
de Uso general (que
aglutine varias UF o
casos de uso)
DOCUMENTACION 3.5.1
REVISIN DEL DIAGRAMA DE DEFINICIN DE LOS CASOS DE USO

A.F.1 Verificar la
INCOMPLETO
3.3.1.1
existencia del
Diagrama Definicin
de Casos de Uso
(Diagrama
Funcional) y
comprobar que
viene representado
como un diagrama
de actividad
__________________________________________________________________________________________
98/125
A.F.2 Revisar estereotipos
NORMA
3.6
en el Diagrama de
Definicin de Caso
de Uso o Diagrama
Funcional: Unidades
visuales, servicios
datos,
A.F.3 Revisar la
DOCUMENTACION 3.3.1
documentacin
diagrama de
Definicin de Casos
de Uso
A.F.4 Revisar que
NORMA
Diagrama Definicin
Caso de Uso existe
un Inicio y un Fin
A.F.5 Revisar que las
NORMA
actividades son
acciones y no clases
lgicas o fsicas
A.F.6 Existe
DOCUMENTACION 3.2.1
documentacin en
las actividades
A.F.7 Las actividades
INCONSISTENCIA 3.2.1
correspondientes
con ventanas/flujos
modales han de
reflejarse tanto en el
diagrama funcional
como en el diagrama
tcnico indicados
mediante una nota.
ALTERNATIVA:
__________________________________________________________________________________________
99/125
CDIGO: BV-05
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de diseo de diagramas tcnicos
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes al
diseo de diagrama tcnico.
PUNTOS A
REVISAR
GENERALES
Cumpl Comentari
e
o
Tipo de
error
Referenci
a en
Norma
DISEO
REVISIN DEL DIAGRAMA TCNICO (DIAGRAMA DE ACTIVIDAD)
D.1
Verificar
existencia del
diagrama
Tcnico.
Comprobar que
viene
representado
como un
diagrama de
actividad
D.2
Revisar que
existe un Inicio y
unos o varios
fines
D.3
Revisar que el
diagrama tcnico
representa el
flujo NACAR y
claramente los
servicios NACAR
y sus pasos de
flujo
INCOMPLETO
Tiene que existir

un nico inicio y
una nica bola
de fin. Adems
debe existir un
nico evento de
inicio
3.7
INCONSISTENCI 3.7.1
A
INCONSISTENCI 3.7.1
A
__________________________________________________________________________________________
100/125
D.4
Revisar que cada

servicio NACAR
est modelado
como una accin
y est
denominado con
el nombre del
componente
NACAR
(especfico o
servicio
genrico)
Cada accin se
debe denominar
con el nombre
de un
componente
NACAR
INCONSISTENCI
A
D.5
Todos los
elementos del
diagrama estn
estereotipados
en base a perfil
o norma
Las acciones,
transacciones y
decisor tienen
los estereotipos
correctos
ajustados al
perfil ARQ
NORMA BLOQ
3.7.2
D.6
El diagrama
tcnico est
estereotipado
como
Diagrama_Tcnic
o
Estereotipo
ofrecido por
ARQ.
Necesario para
la futura
conversin del
diagrama
tcnico a un
borrador de
flujo o
esqueleto
NORMA BLOQ
3.7.3
D.7
El diagrama
tcnico dispone
de un atributo
"Codigo_Flujo"
informado con el
cdigo del flujo
NACAR
Necesario para
la futura
conversin del
diagrama
tcnico a un
borrador de
flujo o
esqueleto
NORMA BLOQ
3.12
D.8
Servicios
genricos
modelados
segn norma
NORMA BLOQ
3.7.4
__________________________________________________________________________________________
101/125
D.9
Existen nodos o
actividades
inconexas, o
existe un camino
o trayectoria que
no finalicen en
un fin de flujo
D.1
0
D.1
1
D.1
2
Nodos
inconexos. Que
un nodo no
tenga
transacciones
de entrada o de
salida
NORMA BLOQ
Antipatrones
Nacar.
No se utilizan
flujos nulos.
NORMA BLOQ
Antipatrones
Nacar.
Controlar todo
los posibles
retornos de los
servicios (flujos,
servicios de
datos, servicios
genricos).
NORMA BLOQ
Antipatrones
Nacar.
No se incluyen
flujos con ms
de un servicio de
presentacin
NORMA BLOQ
Antipatrones
Nacar.
Transiciones
D.1
3
Las transiciones
modeladas entre
servicios
corresponden a
eventos lgicos
de servicios
NACAR
Las transiciones
son asociadas a
eventos
posibles. Por
ejemplo, un
servicio
transaccional
no puede
generar un
evento lgico de
aplicacin que
no sea FIN_OK,
AVISO o ERROR
D.1
4
Las transiciones
con mismo
nombre de
evento estn
claramente
identificadas.
No existen
servicios con
eventos
duplicados
Con un ordinal,
etc
NORMA
No pueden
existir dos
eventos iguales
con el mismo
origen.
NORMA BLOQ
D.1
5
INCONSISTENCI 3.7.1
A
3.7.1
Antipatrones
Nacar.
__________________________________________________________________________________________
102/125
D.1
6
En las
transiciones se
disponen los
mapeos en el
campo
"documentacin"
D.1
7
Revisar la
Ajustado a
notacin y
norma
formato seguido
en la
especificacin de
los mapeos
(mbitos,
frmula,
jerarqua, por
referencia)
D.1
8
Revisar que la
transicin
dispone de los
atributos
"convuelta ",
evento lgico" y
por referencia
informado.
Revisar que los
mapeos sean
coherentes
tcnicamente y
estn completos
D.1
9
INCONSISTENCI 3.7.1 y 3.7.2

A
Los elementos
de contexto
corresponden al
mbito de la
transicin, los
elementos del
mapeo estn
especificados
explcitamente,
NORMA BLOQ
3.7.2
NORMA
3.12
INCONSISTENCI
A
Multiidioma
D.2
0
Los valores
relativos a datos
de tipo fecha o
numricos se
mueven en los
pasos de flujo en
formato neutro,
excepto cuando
se van a
presentar
NORMA BLOQ
__________________________________________________________________________________________
103/125
D.2
1
Los valores
relativos a datos
de tipo fecha o
numricos se
convierten antes
de visualizarse
del formato
neutro al
adecuado en el
paso de flujo
antes de la
unidad visual y a
la inversa
cuando salen de
la ventana se
convierten en
formato neutro
D.2
2
No se observan
literales y
mensajes a fuego
en los servicios
de mensajes de
Arquitectura
sean genricos o
no
Se deben
aplicar rutinas
de Arquitectura
en los mapeos
de antes y
despus de la
ventana, para
convertir del
formato neutro
al formato del
idioma
adecuado. Se
debe tener en
cuenta si la
aplicacin Host
est adaptada al
multiidioma o
no.
NORMA BLOQ
NORMA BLOQ
Condiciones y evaluadores
D.2
3
Especificacin
clara de la
condicin o
evaluacin a
implementar
D.2
4
Condiciones
implementadas
como decisores
RSA.
Con condicin
en campo
"documentacin
" donde
especifique el
mbito de la
variable a
evaluar y salida
TRUE y FALSE
INCOMPLETO
3.7.1
NORMA BLOQ
3.7.1
__________________________________________________________________________________________
104/125
D.2
5
Condiciones con Fusionar +

varias entradas
accin decisor
modelados
segn norma
NORMA BLOQ
3.7.5
D.2
6
Expresiones
especificadas
como atributos
NORMA BLOQ
D.2
7
No existen dos
condiciones con
el mismo nombre
o identificador en
el modelo
(aunque s se
exprese la misma
condicin)
El problema
reside en la
generacin de
esqueletos, ya
que se generan
condiciones por
el nombre con
mltiples
salidas
NORMA BLOQ
D.2
8
No existen dos o
ms condiciones
o evaluadores
consecutivos.
Sustituir dos o
ms
condiciones por
un servicios de
negocio o
evaluadores,
segn el caso.
No se admite
tampoco la
combinacin de
dos condiciones
o evaluadores
con un servicio
nulo entre ellos.
NORMA BLOQ
Antipatrones
nacar
D.2
9
Todo evaluador
contempla
adems de las
salidas a evaluar
necesarias la
salida default.
En los
evaluadores
deben existir
tantas salidas
como casos de
PAR_VALOR +
el default
(obligatorio)
NORMA BLOQ
Antipatrones
nacar
__________________________________________________________________________________________
105/125
D.3
0
No se hace uso
de condiciones
antes del cierre
del flujo
No es
recomendable la
utilizacin de
condiciones
antes del cierre
de un flujo.
NORMA BLOQ
Antipatrones
nacar
NORMA BLOQ
Antipatrones
nacar
NORMA BLOQ
Antipatrones
nacar
Utilizacin Eventos de Arquitectura

D.3
1
No se hace uso
de Fin Ok / Fin
Aviso / Fin Error
de Arquitectura
para salir de una
ventana.
D.3
2
Para las salidas

de los servicios
de mensajera
(ME o
ATAESG00001)
no se puede usar
con Fin OK/Aviso
o Error.
Siempre deben
de salir por
eventos tipo
Aceptar/Aceptar
Dialogo,Si, No
ALTERNATIVA:
__________________________________________________________________________________________
106/125
CDIGO: BV-06
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de Modelo de clases lgico
modelo de clases lgico.
PUNTOS A
REVISAR
GENERALES
Cumpl Comentar
e
io
Tipo de
error
Referenc
ia en
Norma
DISEO
REVISIN DEL MODELO LGICO (DIAGRAMA DE CLASES)
ML.1
Revisin que todos

los servicios NACAR
propios del diagrama
tcnico estn
incluidos en el
paquete ML y Objetos
no propietarios
INCOMPLETO
3.8
ML.2
Revisar que todos los

componentes NACAR
asociados a los
servicios NACAR se
encuentran en el
paquete ML
INCOMPLETO
3.8.1
INCOMPLETO
3.8.1
NORMA BLOQ
3.8.1
ML.2. Modelado de los

contextos de flujos,
1
ventanas, servicios
de datos
ML.3
Existen diagrama/s
de clases lgicas
donde se muestran
las relaciones entre
servicios y
componentes NACAR
Se debe
incluir un
diagrama por
componente
tal cual se
especifica en
la gua
__________________________________________________________________________________________
107/125
ML.3. El Diagrama de
clases relaciona
1
NORMA BLOQ
correctamente los
servicios con sus
componentes
(contextos, recursos,
)
ML.4
Revisar que las

clases lgicas estn
estereotipadas segn
norma
ML.5
Revisar que los

atributos de los
servicios y
componentes estn
sujetos a norma
ML.6
Revisar la
documentacin de
las clases
Ventanas y
servicios de
negocio
NORMA BLOQ
3.8.2
NORMA
3.12
DOCUMENTACI 3.2.1
ON
Servicios de datos
ML.7
Revisar que el
recurso de
Transacciones
dispone de la
definicin de la E/S o
est incluida la copy
en el campo
documentacin
ML.8
Se ha definido
correctamente el
Recurso de
Transacciones
indicando el tipo y la
transaccin a lanzar
as como la copy. De
igual forma se ha
definido el parmetro
recurso de datos con
los atributos Formato
de entrada, Versin,
Identificador_de_acc
eso, Cabecera.
Se debe
incluir
obligatoriame
nte en la
documentaci
n.
INCOMPLETO
3.10.2
INCOMPLETO
__________________________________________________________________________________________
108/125
ML.9
Revisar que el
recurso de acceso a
BBDD y
procedimientos
almacenados
disponer de la
definicin E/S
INCOMPLETO
ML.1
0
Revisar que el
recurso Tabla cdigo
dispone de la
definicin E/S
INCOMPLETO
ML.1
1
Se ha definido
adecuadamente la
sentencia SQL para
los accesos a BB.DD
y Tabla Cdigo en el
recurso
INCOMPLETO
ML.1
2
Los atributos del

componente Query
vienen informados
INCOMPLETO
ML.1
3
Revisar que el
recurso <<Servicio
de Negocio>>
dispone de la
definicin E/S
INCOMPLETO
ML.1
4
Revisar que otros

servicios de datos
disponen de la
definicin E/S
INCOMPLETO
ALTERNATIVA:
__________________________________________________________________________________________
109/125
CDIGO: BV-07
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de Modelo de clases fsico
modelo de clases fsico.
PUNTOS A
REVISAR
GENERALE
S
Cumpl Comentari
Tipo de error
e
o
Referenci
a en
Norma
DISEO
REVISIN DEL MODELO FSICO (DIAGRAMA DE CLASES Y PSEUDOCDIGO ASOCIADO)
Revisin que
todos los
recursos fsicos
propios del
diagrama
tcnico estn
incluidos en el
paquete MF
Revisar que
existe
diagramas de
clases fsicas
que representan
las relaciones
entre clases
Revisar que las
clases fsicas
estn
estereotipadas
segn norma
INCOMPLETO
NORMA
3.8.4
MF.4
Documentacin
de la clase
DOCUMENTACI
ON
3.2.1
MF.5
No se incluye
cdigo
NORMA BLOQ
3.9.5
MF.1
MF.2
MF.3
3.8.3
NORMA
No se admite
cdigo java,
javascript, ajax
en la ventana,
servicios de
negocio..
Si est permitido
definir include y
tld.
Ventanas
__________________________________________________________________________________________
110/125
MF.6
Se encuentran
todos los
recursos fsicos
necesarios para
la ventana (js,
JSP, XSL,)
INCOMPLETO
3.9
MF.7
Se disponen de
esqueletos para
las ventanas
nuevas y
prototipo HTML
INCOMPLETO
3.9
MF.8
Los JSP
esqueletos son
coherentes con
el modelo RSA y
se
corresponden
con las
ventanas a
construir y
prototipo
incorporado en
entrega
Los prototipos
.jsp son
coherentes y
utilizan las
custom tags
adecuadas, y
estn
adecuadamente
definidos los
atributos
INCONSISTENCI
A
MF.9
MF.1
0
La funcionalidad
de la ventana
incluida en el
diseo permite
la construccin
de la misma sin
"interpretacione
s"
Se verifica que
no se utilizan los
custom-tags por
defecto, as
como los
atributos,
cuando en el
diseo se
contempla el
uso de customtags propias o
de Arquitectura
con atributos
distintos
INCONSISTENCI
A
INCOMPLETO
__________________________________________________________________________________________
111/125
MF.1
1
Funcionalidad
de la ventana
expresada en
"documentacin
" de la clase con
pseudocdigo
NORMA
3.9
MF.1
3
El diseo
dispone de una
definicin de los
controles de la
ventana y sus
propiedades
Controles de la
ventana
identificados
como atributos
de la clase fsica
INCOMPLETO
3.9
MF.1
5
Relacin del
aspecto visual
de la ventana
con los
controles de la
ventana en el
modelo. El
comportamiento
de la ventana se
corresponde
con el aspecto
visual de la
ventana.
INCONSISTENCI
A
MF.1
6
La entrega del
diseo dispone
de informacin
necesaria para
la
implementacin
de las libreras
javascript
propias.
La entrega del
diseo dispone
de informacin
necesaria para
la
implementacin
de las libreras
de presentacin
(custom tags )
propias.
INCOMPLETO
Modelado
javascript sujeto
a norma (No se
incluye cdigo)
NORMA BLOQ
MF.1
4
NORMA
3.9.1
3.9.3.1
Elementos de presentacin
MF.1
7
MF.1
8
INCOMPLETO
3.9.5
__________________________________________________________________________________________
112/125
MF.1
9
Modelado
CustomTag
sujeto a norma
NORMA
3.9.4
Servicios de negocio
MF.2
0
La entrega del
diseo dispone
de informacin
necesaria para
la
implementacin
de los servicios
de negocio
propios
(funciones , su
comportamiento
y E/S)
INCOMPLETO
MF.2
1
No se incluye
cdigo java
directamente en
el modelado del
servicio de
negocio
NORMA BLOQ
3.10.4
Multiidioma
MF.2
2
No se usan
literales a fuego
para efectuar las
siguientes
funciones:
- alerts o
ataaMensaje.
- Al invocar
ventanas
modales no se
pasa el ttulo o
el locale a fuego
- la definicin de
la columna libre
en la tabla
editable no usa
literales a fuego
Ver gua de
recomendacione
s. En la mayora
de los casos
sera
recomendable
usar ficheros .js
NORMA BLOQ
__________________________________________________________________________________________
113/125
MF.2
3
No deben
usarse controles
HTML puros, ya
que estos no
estn
soportados por
la herramienta
de traduccin de
ventanas
En algn caso
podra ser
adecuado usar
controles HTML,
si no se adaptan
las custom tags
definidas, como
tablas, frames.
Siempre que se
respeten las
condiciones
para ser
multiidioma.
NORMA
ALTERNATIVA:
__________________________________________________________________________________________
114/125
CDIGO: BV-08
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de reutilizacin de flujos y servicios

genricos
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes a la
reutilizacin de flujos y servicios genricos.
PUNTOS A
REVISAR
GENERALES
Cumple Comentario
Tipo de
error
Referencia
en Norma
REUTILIZACIN FLUJOS
REVISIN REUTILIZACIN FLUJOS
R.F.1 Flujo invocado
lanzado a travs
de las funciona
JS para ventanas
modales con
presentacin a
ventana
completa
R.F.2 Flujo invocado a

travs de una
ventana
emergente
invoca a otras
ventanas
modales o
emergentes
La
presentacin
modal a
pantalla
completa debe
implementarse
con el servicio
genrico 48
INCOMPLETO
Desde BBVV
se pedir una
aclaracin por
parte de la
aplicacin
para confirmar
que no se
realiza la
llamada de
una ventana
modal dentro
de otra
ventana modal
INCOMPLETO
SERVICIOS GENRICOS
REVISIN UTILIZACIN SERVICIOS GENRICOS
__________________________________________________________________________________________
115/125
S.G.1 Incorrecta
utilizacin de
servicios
genricos
Por ejemplo:
Slo se
debera utilizar
el SG48 para
llamar a flujos
de otra
aplicacin de
forma esttica
o dinmica.
Slo se
debera utilizar
el SG4 para
llamar de
forma
dinmica a
flujos de la
misma
aplicacin.
Slo se
debera utilizar
el SG3 para
llamar de
forma
dinmica a
servicios de
datos.
Slo se
debera utilizar
el SG2 para
llamar de
forma
dinmica a
servicios de
presentacin
(ventanas)
Etc
NORMA
BLOQ
Antipatrones
nacar
ALTERNATIVA:
__________________________________________________________________________________________
116/125
CDIGO: BV-09
TIPO: ERROR
DESCRIPCIN:
NOMBRE: Revisin de casos de prueba
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes a los
casos de prueba.
PUNTOS A
REVISAR
GENERALE
S
Cumpl
e
Comentari
o
Tipo de error
Referenci
a en
Norma
PRUEBAS
REVISIN CASOS DE USO DE PRUEBAS
CP.
1
El C204 de la
entrega dispone
casos de
pruebas para el
caso de uso
INCOMPLETO
CP.
2
El detalle de los
casos de
pruebas
asociados
incorpora
DESCRIPCIN:e
s y datos
suficientes para
poder realizar la
ejecucin del
caso
INCOMPLETO
CP.
3
Los casos de
prueba permiten
validar el
funcionamiento
de los
componentes
que conforman
el casos de uso
Los casos de
prueba
contemplan
todas los pasos
de flujo
modelados en el
caso de uso.
INCOMPLETO
CP.
4
Tratamiento
de errores
(fin_aviso,
fin_error,
fin_ok) de los
SD. Pruebas
de todos los
accionadores
DOCUMENTACIO
N
__________________________________________________________________________________________
117/125
CP.
5
Se entregan los
ficheros de
transacciones
dummys, ya que
no se van a
realizar las
pruebas de
integracin HostNacar por
factora
En el F011
vendr
indicado si el
caso de uso
tiene pruebas
de
integracin
Host-Nacar o
no. En caso
de que no se
realicen, el
proyecto
debe enviar
los ficheros
de las
transaccione
s dummy
INCOMPLETO
ALTERNATIVA:
__________________________________________________________________________________________
118/125
CDIGO: BV-010
TIPO: INFORMATIVO
DESCRIPCIN:
NOMBRE: Revisin de casos de prueba
Se mantiene el mismo protocolo de revisin, en este caso se revisan los aspectos referentes a
los casos de prueba.
PUNTOS A
REVISAR
GENERALES
Cumple Comentario
Tipo
Referencia
de
en Norma
error
CALIDAD DISEO TCNICO

CC.1
Minimizar o
evitar incluir
entre diferentes
interacciones del
usuario
secuencias muy
pesadas que
retrasen la
siguiente
interaccin
CC.2
Minimizar la
invocacin de
servicios que se
repiten en flujos
secundarios
CC.3
Controlar los
retornos de
cualquier
servicio de datos
o flujo con Fin
Ok, Fin Aviso y
Fin Error
Controlar que los
servicios de
mensajes tengan
sus retornos
correspondientes
(Aceptar Dilogo,
)
CC.4
Deben llevarse
al flujo
superior y
llevar los datos
al contexto,
para que lo
reutilicen el
resto de flujos
y servicios
Q.
Alta
5.1.1.1.
Q.
Alta
5.1.1.2.
Q.
5.1.1.3
Media
Q.
5.1.1.3
Media
__________________________________________________________________________________________
119/125
CC.5
Es recomendable
que todos los
Flujos finalicen
con
ATAENL00001,
ATAENL00003 y
ATAENL00004
para poder
controlar las
salidas con Fin
Ok, Fin Aviso y
Fin Error
Q.
5.1.1.4
Media
CC.6
Revisar que
nicamente
existe un evento
Inicio en el flujo
Q.
5.1.1.4
Media
CC.7
Controlar que las

variables no se
mueven de
servicio en
servicio, si no se
van a utilizar en
todos ellos (se
debe hacer uso
del flujo actual)
CC.8
Revisar que se
han creado todos
los contextos
(del flujo, de los
servicios de
datos, de las
ventanas)
correctamente y
no se utilizan
variables
dinmicas
CC.9
No se permite la
utilizacin de
flujos nulos
CC.10 Utilizar las

opciones de
"Con Vuelta" y
"Sin Vuelta"
correctamente
cuando sea
necesario para
evitar duplicar
mapeos en el
flujo
Q.
Alta
5.1.1.5
Q.
Relacionado
Media con 5.1.1.5
Q.
Alta
5.1.1.6
Q.
5.1.1.7
Media
__________________________________________________________________________________________
120/125
CC.11 CONDICIONES.
Q.
5.1.1.8
Media
Sustituir dos o
ms condiciones
por evaluadores
o servicios de
negocio
CC.12 Utilizar los

servicios de
Arquitectura para
servicios de
infraestructura
Especialmente
en servicios de
negocio, por
ejemplo se han
encontrado
trazas en
presentacin
implementadas
por aplicacin.
CC.13 Usar mapeos por
5.1.1.9
Q.
5.1.1.10
Media
referencia en la
medida de lo
posible (el
mapeo por valor
genera una copia
del origen).
CC.14 Garantizar la
Valorar y
salida, mediante consensuar
alguna condicin con el proyecto
o evento, cuando
se producen
ciclos o bucles
entre
componentes o
servicios dentro
de un flujo.
CC.15 Habilitar la cach Debe

de transacciones
en aquellas que
devuelvan datos
estticos y
compartidos para
los criterios de
cach.
Q.
Alta
especificarse
en la
documentacin
de la
transaccin
(atributo
cacheable del
estereotipo)
Q.
5.1.1.11
Media
Q.
5.1.1.12
Media
__________________________________________________________________________________________
121/125
CC.16 Identificar y
Q.
Alta
5.2.1.1
CC.17 Reducir la carga Si se especifica

del onload de la en el jsp se
podr
ventana
Q.
Alta
5.2.2.1
CC.18 La lgica pesada
Q.
Alta
5.2.2.2
Q.
Alta
5.1.3
encapsular
funciones
javascritp
comunes en
libreras
comunes en el
modelo fsico
de la ventana
recomendar al
proyecto que
elimine la
carga. Valorar
y consensuar
con el proyecto
que genera los

estados de la
presentacin
asociado a un
evento de
usuario se deben
condicionar a la
ejecucin de este
evento.
CC.19 Flujos
ejecutados en
ventanas
modales siguen
especificaciones
de diseo
Servicio de
presentacin
activo ,
operacin de la
misma
aplicacin y
paso de datos
__________________________________________________________________________________________
122/125
CC.20 El rendimiento se A travs de la

puede ver
afectado por el
diseo del flujo
CC.21 El prototipo JSP

se completa o
dispone de
propiedades en
los controles
ejecucin de
pasos de flujo
complejos con
enorme
cantidad de
mapeos,
servicios de
negocio
complejos,
procedimientos
almacenados
pesados,
secuencias de
transacciones
pesadas antes
de que
aparezca la
ventana
Los controles o
traduccin se
completa con
la edicin de
propiedades,
que finalmente
se traducen en
atributos de las
custom tags,
en vez de dejar
las
propiedades
por defecto
Q.
Alta
Q.
Baja
__________________________________________________________________________________________
123/125
CC.22 Se obtienen en
las transacciones
y accesos a
BB.DD. el
volumen de
campos
necesarios para
la ejecucin de
los clculos,
funcionalidades
y su
presentacin.
Si slo se
presentan o
utilizan un
volumen
inferior al 2030%, indica
que se extraen
campos
innecesarios, y
que se estn
ejecutando
transacciones
pesadas,
ocupando
ancho de
banda
innecesario.
Tambin puede
suponer una
mala
modularizacin
de
transacciones.
Q.
Alta
ALTERNATIVA:
__________________________________________________________________________________________
124/125
Referencias.
Los siguientes documentos amplan la informacin de las alternativas a cada antipatrn.
Puede localizarse en los sites de Arquitectura de Ejecucin, Soporte a Desarrollo
Arquitectura Calidad Sistemas.
COBOL
1. Hard-code. Directrices de uso
2. Anexo Conjunto de reglas verificadas por el analizador de la Gua de uso del
Analizador de cdigo COBOL/DB2.
JCL.
3. Utilidades de Recepcin de Aplicaciones no disponibles para procesos batch.
Rearranques:
4. Procesos BMP.
5. Rearranques-Manual Administracion Rearranques PG.doc
6. Gua Rpida Arquitectura Batch PG.
Paginacin.
7. Manual de Paginacin.
Gestin de errores.
8. Tratamiento de errores en transacciones PG.
9. Tratamiento aconsejado para cancelaciones batch.
__________________________________________________________________________________________
125/125

Guia Antipatrones General

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guia Antipatrones General

Transféré par

Droits d'auteur :

Formats disponibles

GUA DE ANTIPATRONES

Ficheros externos. ............................................................................................................................. 38

DESCRIPCIN: del cambio

Arquitectura Calidad Sistemas

Arquitectura Calidad Sistemas

CDIGO: Son nemotcnicos que identifican el antipatrn.

ERROR.- Antipatrn grave que debe corregirse obligatoriamente.

NOMBRE: Breve descripcin del contenido de la ficha.

NOMBRE: NDICES NO COMP

Para valores ms grandes: PIC S9(8) COMP.

NOMBRE: CONTADORES NO COMP

Hasta un valor de 32.767: PIC S9(4) COMP.

Hasta un valor de 2.147.483.647: PIC S9(8) COMP.

Se recomienda no usar un tamao de PICTURE ms grande de lo necesario.

El error consiste en incluir datos HARD-CODE en un programa.

Bsqueda en tablas WORKING.

NOMBRE: BSQUEDAS EN WORKING

Pueden darse distintos errores:

2. Recorrer la tabla secuencialmente pudindolo hacer de forma binaria o dicotmica.

3. Recorrer la tabla secuencialmente hasta la ltima ocurrencia, en lugar de hacerlo slo

SEARCH ALL ELEMENTO

Uso de OCCURS DEPENDING ON

NOMBRE: OCCURS DEPENDING ON

Consiste en usar OCCURS DEPENDING ON en programas on-line.

Ubicacin de las sentencias.

NOMBRE: UBICACIN DE LOS CLCULOS

El error consiste en colocar las sentencias en un lugar inadecuado, normalmente dentro de

Codificar las instrucciones en el punto adecuado, teniendo en cuenta el momento exacto en

NOMBRE: UBICACIN DE LAS LLAMADAS A RUTINAS DE

Sentencias muy consumidoras.

alfanumrico se inicializa a espacios; etc.

cargadas en la tabla. Esto hace que el INITIALIZE sea innecesario, y que el

NOMBRE: MOVE DE REAS GRANDES

Si entra en el IF, mover AREA1 a AREA2 (con lo cual ya son iguales).

Esta instruccin es muy costosa, conviene evitar su utilizacin.

Esta prctica es habitual cuando un campo numrico es opcional, de forma que:

Si viene informado, viene con nmeros de la forma habitual.

NOMBRE: READ/WRITE SIN INTO/FROM

Ficheros de longitud fija.

NOMBRE: INFORMAR UN FICHERO EN VARIOS PASOS

NOMBRE: FILLER DESPROPORCIONADO

NOMBRE: INFORMACIN REPETIDA EN FICHERO

Ficheros de longitud variable

NOMBRE: APPLY-WRITE ONLY

Ejecutar un SORT para ordenar un fichero por la clave.

NOMBRE: FICHERO GRANDE VS FICHERO PEQUEO

Para estos casos se recomienda seguir este procedimiento:

Clasificar mediante SORT el fichero pequeo.

NOMBRE: ENFRENTAMIENTO DE 2 FICHEROS MUY GRANDES

La tcnica ms comn para enfrentar dos ficheros es la siguiente, aunque no siempre

NOMBRE: ENFRENTAMIENTO DE 3 FICHEROS MUY GRANDES

En la instalacin no abundan los programas que hacen enfrentamiento de tres

NOMBRE: ENFRENTAMIENTO GENERAL DE 2 FICHEROS

En aquellos casos en que slo interesa la interseccin de ambos ficheros, es decir,

No es necesario alcanzar el final de los dos ficheros en este caso.

Detener el proceso en cuanto se alcance el final de uno de los dos ficheros:

NOMBRE: ENFRENTAMIENTO CONTRA UN CURSOR DE UNA

Uso inadecuado de rutinas invocadas

NOMBRE: INFRAUTILIZACIN DE LA RUTINA DE

El mdulo normalizado de gestin de errores batch COBOL, QPBTRXRR, es invocado cuando

NOMBRE: COPY DE ARQUITECTURA QPIPCCAB

Rearranques. Uso inadecuado de COMMIT

Para aplicaciones PG, consultar los documentos de Arquitectura de Ejecucin en el

Parametrizacin de la frecuencia de COMMIT (Rearranques-Manual Administracion