Manual de Recomendaciones - Desarrolladores Cobol DB2-CICS en Altamira

Desarrolladores

Cobol DB2-CICS

en Altamira

Manual de

Recomendaciones

Venezuela, Octubre 2020

Índice

Índice ....................................................................................................... 2

1. Aspectos generales de la arquitectura Altamira .................................... 4

1.1. Parametrizaciones Básicas de Arquitectura por la opción 2 del menú QM de

Arquitectura .................................................................................................. 4

Campo Tipo Altamira .................................................................................... 4

Campo Tipo de Transacción ................................................................................... 5

Campo Indicador de Tecleo .................................................................................... 6

1.2. Parametrizaciones Básicas de Arquitectura para el DESARROLLO DE

TRANSACCIONES BAJO PROTOCOLO PS9 (Especificidades de Función) ............. 7

Campo Indicador de Sesión ........................................................................... 7

Campo Indicador Asunto ............................................................................... 8

Campo Indicador Grabación de Trazas (Trace).................................................. 9

Campo Indicador Rollback ........................................................................... 10

Campo Indicadores Varios de Arquitectura (S/N) ............................................ 10

Especificación del Tipo de Formato ..............................................................

2. Consideraciones generales para desarrollo de transacciones bajo

protocolo Ps-9................................................................................... 22

3. Consideraciones básicas de CICS ....................................................... 26

Conceptos Generales .................................................................................. 26

Principales Comandos de CICS ..................................................................... 26

Relación entre las Parametrizaciones de Arquitectura y el CICS (New Copy) ........ 27

Principales Errores de CICS en la QMLO ......................................................... 27

Título del documento y versión 2

Principales Instrucciones del CICS ................................................................. 28

Debugging de Programa en CICS (CEDF y CEDX) ....................................... 28

4. Consideraciones generales de programación en lenguaje Cobol ......... 29


ASPECTOS GENERALES DE LA ARQUITECTURA ALTAMIRA

Parametrizaciones Básicas de Arquitectura por la opción 2 del menú QM de Arquitectura.

Esta interfaz consta de varios indicadores tal como se muestra en la figura, a continuación se

detallan los más importantes a considerar para las transacciones asociadas a un canal.

Campo Tipo Altamira:

Este indicador puede tomar los valores (N/E/M/A/C) estos indican:

• N: Transacción Altamira Extendida.

• E: Transacción Estándar con pantalla original Altamira.

• M: Transacción Estándar con cabecera y pie de pantalla de la Arquitectura Extendida.

• A: Transacción Altamira AST.

• C: Transacción Altamira Extendida para AST.

Todas las transacciones asociadas a un canal deben tener el indicador tipo Altamira igual a ‘C’ este

tiene la función de realizar validaciones en el mantenimiento de especificidades de función así

como también en el log de la AST, esto permite obtener un mejor control de los totales estadísticos

de ejecuciones por transacción así como también el seguimiento de la producción.


Las validaciones más importantes que se realizan en el gestor de canales AST son las siguientes:

1. Validación del límite para las transacciones financieras

2. Validación de asunto propio

3. Validación de firmas conjuntas

4. Validación de las modalidades de uso de sesión (Generación, Uso y Borrado de Sesiones).

Todas las transacciones que generan sesión deben ser tipo Altamira ‘A’, ejemplo la TX KVD1.

Campo Tipo de Transacción


Este campo indica la modalidad de uso de la transacción, cuyos valores pueden ser:

• Transaccionales: Son aquellas que manejan un hilo de comunicación único y finito, es decir,

obtienen el dato de entrada, recuperan los datos de salida y finaliza la comunicación.

• Conversacionales: Son aquellas que mantiene un hilo de conversación. Ejemplo:

transacciones tipo listado GTS.

Es un requisito fundamental que las transacciones asociadas a un canal desatendido deben ser tipo

‘T’, es decir, Transaccionales.

Campo Indicador de Tecleo

Este indicador permite los valores (S/N) y tiene la función de actualizar la tabla de tecleos

exclusivamente para las transacciones que se ejecutan desde las oficinas. Para las transacciones que

se ejecutan desde un canal desantendido (ejemplo: banca móvil, provinet personas), este indicador

debe estar con estatus ‘N’. Si el canal es atendido (ejemplo: Terminal Financiero) este indicador

debe estar con valor ‘S’.


Parametrizaciones Básicas de Arquitectura para el DESARROLLO DE TRANSACCIONES BAJO

PROTOCOLO PS9 (Especificidades de Función)

Esta interfaz consta de varios indicadores tal como se muestra en la figura.

A continuación se detallan los más importantes para las transacciones asociadas a un canal en el

menú de mantenimiento de especificadas de las transacciones.

Campo Indicador de Sesión


Este campo puede tomar los valores (G/U/N/B) donde:

• G= Genera sesión.

• U= Usa sesión

• N= No usa sesión

• B= Baja de sesión.

Para las transacciones asociadas a un canal debe existir una transacción inicial que genere la sesión

(Indicador Sesión con la letra ‘G’) la cual será usada por las transacciones que sean invocadas a

partir de ella, las cuales deben tener el Indicador de Sesión con la letra ‘U’ y para finalizar la sesión

debe existir una transacción que se encargue de dar de baja la misma, la cual se marca con la letra

‘B’ en el Indicador de Sesión.

Campo Indicador Asunto

Todas las transacciones financieras y de consultas de operaciones críticas deben tener activa la

validación de Asunto Propio en el mantenimiento de especificidades de función.

Este indicador sólo puede tomar los valores siguientes:

• 0 = La transacción no valida asunto propio.

• 1 = La transacción valida un asunto (contrato, cuenta, tarjeta).

• 2 = La transacción valida dos asuntos (contratos, cuentas, tarjetas).

Como complemento del indicador de asunto propio se debe especificar en el formato de entrada de

la transacción a cual campo se le efectuará la validación de asunto propio. Esto se marca a través de

la opción 3 del menú QM, navegando hasta la pantalla de Mantenimiento de Campos del Formato y

al identificar el campo, se debe actualizar el indicador Literal 4700 con el valor ”ASP”, de este

modo el gestor de canales realizará la validación de asunto propio antes de ejecutar una


operación.Cuando se requiera validar dos campos, al segundo se le debe actualizar el indicador

Literal 4700 con el valor “ASA”.

Nota: Las Transacciones de consulta no poseen este indicador.

Campo Indicador Grabación de Trazas (Trace)

Este indicador se usa para la generación de trazas del gestor de canales en la cola denominada

CNTRACE, por tal motivo es uno de los importantes y ninguna transacción asociada a un canal

debe tener este indicador con estatus activo, (Ind. Trace = A) ya que se pueden generar trazas

en el ambiente de producción y la cantidad máxima permitida de registros en una cola (temporage

storage) en el cics es de 32763. Copar ésta cantidad de registros genera un Sin Servicio en los

Canales Desatendidos por la región CICS donde reside la cola y más aún si la cola no es local y reside

en el CICS de gestión de colas remotas (QOR).


Campo Indicador Rollback:

Este indicador puede tomar los valores S/N. Para transacciones financieras debe estar con estatus

“S”, de modo de que si presenta alguna cancelación, incidencia o abend durante la operación, la

misma pueda ser reversada en línea de todas las tablas aplicativas y de arquitectura involucradas.

Campo Indicadores Varios de Arquitectura (S/N):

Estos indicadores (“QF”, “QA”, “QS”, “TCL” y “DIA”) permiten grabar en las tablas de arquitectura,

donde los primeros 4 indicadores deben permanecer con estatus ‘N’ para evitar grabar trazas y

registros en tablas de arquitectura. El último indicador debe permanecer con estatus ‘S’ para

indicar que las operaciones usan el flujo ligero de la arquitectura exclusivo para Canales

Desatendidos.


Existe una particularidad para las transacciones que entran en el modelo de funcionamiento de

Firmas Conjuntas. Sólo para éste caso se debe colocar el indicador “S” en el indicador “QF”. Ejemplo:

transacción de Transferencias a Otros Bancos.

Adicional a esto se debe realizar el borrado de la cola +DC para garantizar que no existan mezcla de

mapas en respuesta de transacción.

Se debe garantizar la inclusión de la siguiente sentencia en nuevos desarrollos de programas línea.

Ejemplo:


Dónde:

Los elementos que deben registrarse y asociarse en Arquitectura para la ejecución de transacciones

por PS9 son:

A. Transacción

B. Formatos de entrada y salida

C. Si es transacción Transaccional definir Preformato

D. Canal

E. Especificidades de la transacción

F. Terminales Lógicas y Terminal Contable

A continuación se comentan algunos aspectos relevantes acerca de cada uno de ellos.

A) Transacción:


En la definición de la transacción toma relevancia el campo Tipo Altamira, ya que en base a

este será el flujo que siga la ejecución de la transacción por PS9. (Al final se muestra

diagrama).

- TIPO ALTAMIRA: Indicador del tipo de transacción (N/E/M/A/C). Es modificable el campo.

Los valores indican:

* N: Transacción Altamira Extendida.

* E: Transacción Estándar con pantalla original Altamira.

* M: Transacción Estándar con cabecera y pie de pantalla de la Arquitectura

Extendida.

* A: Transacción Altamira AST.

* C: Transacción Altamira Extendida para AST.

B) Formatos de Entrada y Salida.

Lista de Formatos de una Transacción

Se accede a este panel desde el mantenimiento de transacciones con la tecla de función PF5.

Para cada línea del listado, existen dos campos:

• El campo de la selección. Se permite utilizar sólo uno de ellos cada vez, usando los caracteres

'X' o ‘S’.


• El campo de contenido de las líneas. No es modificable por pantalla. Informa acerca de las

características principales de cada registro de la tabla de Formatos.- Relación de la

transacción con el formato de salida.

Para que en esta pantalla se muestre el Formato de Salida, es necesario relacionarlo a la transacción

mediante la opción en QM de Formatos de salida de una TX (opción 11) , se muestra un ejemplo a

continuación.

Especificación del Tipo de Formato


- TIPO: Tipo del formato: define si es correspondiente a un mensaje de entrada BMS (E), a uno de

salida BMS (S), o a uno de entrada y salida BMS(A), o bien entrada no BMS (F) o salida no BMS

(X). Es modificable.

• Si la transacción es nueva o es Transaccional se recomienda tener un formato de entrada (F) y

uno de salida (X) que no sea BMS para no reservar espacio que realmente no se ocupa, debido a que

los formatos BMS reservan 3 bytes en cada campo correspondientes a sus atributos y esto se usa en

transacciones Conversacionales.

• Los Formatos pueden tener como máximo 69 campos y la longitud de cada campo y del formato

depende del tipo:

• Formatos F o X: longitud máxima de cada campo 143 bytes longitud máxima del

formato 9867 bytes.

• Formatos E, S o A: longitud máxima de cada campo 120 bytes longitud máxima del

formato 2000 bytes.

C) Si la transacción es Transaccional, definir un Pre-formato:

El preformato a utilizar en la salida es transparente a las aplicaciones, sabiendo la arquitectura en

cada momento con qué terminal está hablando, y en consecuencia, qué preformato de pantalla debe

utilizar en la salida. Los programas de aplicación solamente tendrán que dar a la arquitectura el

contenido de los campos variables del formato en la correspondiente copy.


- PREFORMATO DE SALIDA ESTÁNDAR: Preformato estándar (24x80) asociado al formato

correspondiente a la salida a pantalla. Puede ir informado en formatos de entrada/salida o de

salida (A/S). Es modificable. Si se informa, debe estar antes dado de alta en la tabla de

preformatos. Se utiliza cuando la salida es a pantalla.

D) Definición del Canal.

Son el conjunto de características establecidas para identificar una entidad externa en Arquitectura.

El campo de mayor relevancia en esta definición es el indicador de AST, como se informa en el

diagrama de modos de procesamiento (que se incluye al final), este indicador influye en

cómo debe parametrizarse o definirse la transacción. Si la operación requiere el uso de

colectores AST, este indicador debe establecerse como “S”.

Se puede acceder al panel de Mantenimiento de Canales:

• Desde el menú principal de mantenimiento de tablas de la arquitectura (QM) tecleando la

OPCION 12 y una clave del canal completa, en caso de no teclear ninguna clave a

continuación se mostrará un listado de los canales.

•

Este panel consta de los siguientes campos:

- CODIGO CANAL: Código del canal ASTA en 2 caracteres. Es modificable.

- DESCRIPCIÓN: Descripción del canal en 25 caracteres. Es modificable.


- NEW COPY: Indicador de si se desea que se refresque la copia en memoria del registro del canal

cuando se realiza una modificación. La selección puede hacerse con el carácter ‘X’. Si no se

realiza esta selección, solamente se actualizarán los valores modificados en la tabla DB2. Es

modificable.

- IND. AUTORIZACION CANAL (S/N): Valores ‘N’ o ‘S’. Con valor a ‘S’ no permite su ejecución

durante el proceso de cambio de sesión. Es modificable.

- LIT. ERROR PROPIOS: Indicador del manejo de mensajes de Error y Aviso propios de cada canal,

si se define como N, tomará los mensajes generales. Es modificable.

- IND. CANAL REQUIERE AST (S/N): Indicador si el canal requiere AST o no. Es modificable.

- ALTA-DISPONIBILIDAD ( /C/S): Alta Disponibilidad y Standing. No modificable en este panel.

- CODIGO CANAL AST: Código del canal AST. Es modificable.

- CODIGO CANAL ASTA: Código de canal ASTA. No modificable.

- CODIGO SUBCANAL AST: Código de subcanal AST. Es modificable.

- INDICE SUBCANAL: Indice de subcanal AST. Es modificable.

- CODIGO CANAL AST MODELO: Código de canal AST modelo. Es modificable.

- ENVIO DE MENSAJES: Rutina para envío de otro tipo de mensajes por canal distinto al de

entrada. Es modificable.

- FORMATEO MSG ENTRADA: Es modificable.

- FORMATEO MSG SALIDA: Es modificable.

- TRATAMIENTO ABEND / PARAMETROS: Es modificable.

- INICIO FORMATO PS9 / PARAMETROS: Es modificable.

- INDICADOR TIPO HORARIO: Valores A (abierto) C (cerrado).

- ABIERTO INICIO DIA HABIL: Hora inicio en horario abierto día hábil

- FIN DIA HABIL: Hora fin en horario abierto día hábil.

- ABIERTO INICIO DIA NO HABIL: Hora inicio horario abierto segundo tramo.

- FIN DIA NO HABIL: Hora fin en horario abierto en día no hábil.

- CERRADO INICIO DIA HABIL: Hora inicio en horario cerrado día hábil

- FIN DIA HABIL: Hora fin en horario cerrado en día hábil.

- CERRADO INICIO DIA NO HABIL: Hora fin en horario cerrado día no hábil.

- FIN DIA NO HABIL: Hora fin en horario cerrado en día no hábil.

- STAMPS ULTIMA MODIFICACION: Los siguientes campos no son modificables por pantalla, e

indican:

- Usuario, Fecha, hora y terminal que realizó la última modificación.


- Usuario, Fecha, hora y terminal que realizó el alta del registro.

Las teclas de función de este panel son:

- IN: Tecla de consulta. Al modificar el campo Código Canal y presionar la tecla “IN” se efectúa

una consulta de los datos para el canal introducido.

- PF2: Tecla de modificación de algún dato.

- PF3: Tecla de alta de un nuevo registro. Se valida que no exista en la tabla.

- PF4: Limpiar. Se borra toda la información que hubiera en la pantalla.

- PF5: Listado. Ir a la pantalla de Especificidades de función por canal.

- PF6: Tecla para dar de baja un registro previa confirmación con PF7. La baja que se realiza es

una baja física (se realiza un Delete del registro en la tabla).

- PF9: Ir al menú de mantenimiento.

E) Especificidades de la transacción

Parámetros que permiten establecer valores condicionantes del procesamiento para las

funciones ejecutadas en dentro del canal.

Listado de especificidades por función

Se accede a este panel desde el mantenimiento de canales con la tecla de función PF5, o desde el

mantenimiento de transacciones con la tecla de función PF16.


Para cada línea del listado, existen dos campos:

• El campo de la selección. Se permite utilizar sólo uno de ellos cada vez, usando los

caracteres ‘X’ ó ‘S’. Es modificable.

• El campo de contenido de las líneas. No es modificable por pantalla. Informa acerca de las

características principales de cada registro de la tabla de especificidades por función-

Parametrización de la transacción para el canal:

Se accede a este panel desde el listado de canales por función

• Seleccionando un registro del listado de la tabla de especificidades por función y pulsando

la tecla PF2, o no realizando ninguna selección y pulsando la tecla PF3 (alta).

Los campos que contiene este panel son:

- FUNCION: Indicador de Función, asociado a este campo se encuentra su descripción.

- CODIGO CANAL El Código de canal, este código no tiene un estándar a seguir, es una

convención entre las áreas involucradas en el proyecto y Arquitectura del país.

- IND. ACTIVO/DESACTIVO: Indicador Activo Desactivo.

- INDICADOR SESION: Indicador Sesión AST (Genera/Usa/No usa)

- INDICADOR ASUNTO: Número de asuntos (0, 1, 2), es el número de cuentas que validará

AST, como complemento de este campo, en la definición del formato de la transacción se

debe indicar cuál es el campo de la cuenta a validar, y si es asunto propio (ASP) o

asociado (ASA).


- INDICADOR IMPORTE: Indicador importe, indica si AST validará el importe de la

transacción, como complemento de este campo, en la definición del formato de la

transacción se debe indicar cuál es el campo de importe a validar, con el literal

IMP(Importe)

- INDICADOR ALTA AUTOMATICA: Indicador de alta automática para nuevos clientes en el canal.

- IND. CONTABILIZAR OPERACIONES: Indicador de Contabilización de operaciones.

- IND. CONTABILIZAR IMPORTES: Indicador de contabilización de importes.

- NIVEL DE SEGURIDAD: Indicador de nivel de seguridad

- MAXIMO NUMERO OPERACIONES/MES: Número máximo de operaciones por mes.

- IMPORTE MINIMO ESTANDAR: Importe mínimo estándar por operación.

- CANAL DESTINO: Indicador de trace.

- IND. TRACE: Indicador de trace.

- IND. REVERSO CONEXIÓN: Indicador de reverso de la operación

- IND. ROLLBACK: Indicador de rollback.

- IND. REGISTRO LOG: Indicador de Log.

- IND REGISTRO MONITOR: Indicador de monitor.

- IND. VALIDAR PASSWORD: Indicador de password

- IND. GENERAR FOLIO: Indicador de generar Folio.

- N. MAXIMO ASUNTOS: Máximo número de asuntos

- INDICADORES: QA, QS, TCL, DIA. Los siguientes indicadores se refieren a:

- QA: Indicador de grabar auditoria

- QS: Indicador de validar confidencialidad

- TCL : Indicador de grabar tecleo

- DIA : Indicador de grabar diario electrónico

- IND.TIPO DE HORARIO: Indicador tipo de horario (abierto/cerrado).

- ABIERTO HABIL: Rango horario abierto (hora inicio/hora fin).

- NO HABIL: Rango horario abierto no hábil (hora inicio/hora fin).

- CERRADO HABIL: Rango horario cerrado hábil (hora inicio/hora fin).

- NO HABIL: Rango horario cerrado no hábil (hora inicio/hora fin).

- STAMPS ÚLTIMA MODIFICACION: Los siguientes campos no son modificables por pantalla, e

indican:


- Usuario, Fecha, hora y terminal que realizó la última modificación.

- Usuario, Fecha, hora y terminal que realizó el alta del registro.

Las teclas de función de este panel son:

- IN: Tecla de consulta. Al modificar el campo Código Canal y presionar la tecla “IN” se efectúa

una consulta de los datos para el canal introducido.

-PF2: Tecla de modificación de algún dato.

-PF3: Tecla de alta de un nuevo registro. Se valida que no exista en la tabla.

-PF4: Limpiar. Se borra toda la información que hubiera en la pantalla.

-PF6: Tecla para dar de baja un registro previa confirmación con PF7. La baja que se realiza es

una baja física (se realiza un Delete del registro en la tabla).

- CL: Ir al panel anterior.

- Indicador de validación de los campos del formato de entrada de la transacción, con estos

indicadores se informan los asuntos e importes a validar en AST:

Si el canal va a entrar por AST y se van a validar los importes es necesario indicar la Literal

de cada campo asociado a éste.


CONSIDERACIONES GENERALES PARA DESARROLLO DE TRANSACCIONES BAJO

PROTOCOLO PS-9.

CAMBIOS DE LA COMMAREA. CONSIDERACIONES GENERALES.

1) La transacción QG30 de Altamira (SIGNON) funcionará bajo DPL pero sin ejecutar la

instrucción Signon prohibida en DPL. Esta transacción la podrá usar el terminal financiero

para leer información del terminal (usuario) que se ha conectado y de incidencias. Que no se

haga Signon no tiene consecuencias si la seguridad es externa y ya se propaga el SIGNON.

2) El SYNCPOINT o SYNCPOINT ROLLBACK deberá estar condicionado al nuevo indicador de

Syncpoint, que vendrán informado en un campo del CAA-STARTCODE en el Área de

comunicaciones de la Arquitectura (QGECCAA). Mientras existan transacciones donde se

requiere un ROLLBACK de parte de la operación y COMMIT del resto dentro de la misma

unidad de ejecución (LWU), se requiere que el Middleware que invoque Altamira vía DPL use

el parámetro SYNCONRETURN al ejecutar el LINK. La ejecución del comando SYNCPOINT

cuando CAA-STARTCODE indique que el SYNCPOINT No se recomienda el uso (‘D’) provocará

un ABEND de la tarea.

3) En caso de invocación DPL (CAA-88-DPL), se prohíbe el uso de los siguientes comandos CICS:

• Comandos de control de terminales referidos a su Principal Facility.

• Comandos que establezcan o pregunten por atributos del terminal.

• Comandos BMS.

• Comandos SIGNON y SIGNOFF.

• Comandos de intercambio de datos con el Batch.

• Comandos que direccionen la TCTUA.

• El uso del comando SYNCPOINT está limitado a la opción SYNCONRETURN establecida

por el LINK a la Arquitectura.

• No hacer uso del EIBTRMID para sufijar colas TS o cualquier tipo de recurso compartido

por transacciones. En su lugar usar CAA-TERMINAL.

CAMBIOS DE LA COMMAREA. CONSIDERACIONES PARA LAS APLICACIONES.

1) No hacer uso del EIBTRNID para identificar el código de la transacción en ejecución. En su

lugar usar CAA-CODTRAN.

2) No ejecutar la instrucción EXEC CICS ASSIGN USERID(). Para obtener la información del

usuario que ejecuta la transacción usar el campo CAA-USERID.


3) Usar los campos CAA-ENTIDAD, CAA-TERMINAL-CONT y CAA-NETNAME-CONT para efectos

de totalización y contables. Aunque tienen los mismos valores, es aconsejable usar el campo

CAA-TERMINAL-CONT para informar las áreas de Journal y totales (en lugar de CAA-

NETNAME-CONT).

4) No usar CAA-NETNAME como equivalente a CAA-TERMINAL. A efectos de auditoría

(grabación de stamps en tablas DB2) se aconseja usar el campo CAA-TERMINAL.

5) Las aplicaciones batch que exploten el Journal Contable, deberán tener en cuenta que se ha

añadido el campo JOU-CANAL en la zona de datos de aplicación. Existen dos alternativas

para manejar el problema: a) Utilizar una plantilla del campo en la que se incluya el canal en

los dos primeros bytes; o b) Mover/Tomar los datos variables a JOU-DATOS-APLIC-VAR (en

lugar de JOU-DATOS-APLIC-C), y tener en cuenta que la longitud del campo se incrementa en

dos debido a la existencia del campo JOU-CANAL.

6) Las aplicaciones no deberán utilizar las instrucciones CICS prohibidas en DPL. A

continuación se presenta una tabla con los comandos prohibidos. Excepto que se especifique

“all”, solo estarán prohibido usar el comando con las opciones de la columna derecha.

¦ Table 10. API commands prohibited in programs invoked by DPL ¦

+------------------------------------------------------------------------¦

¦ Command ¦ Options ¦

+----------------------+-------------------------------------------------¦

¦ ADDRESS ¦ ACEE TCTUA ¦

+----------------------+-------------------------------------------------¦

¦ ASSIGN ¦ ALTSCRNHT ALTSCRNWD APLKYBD APLTEXT BTRANS ¦

¦ ¦ COLOR DEFSCRNHT DEFSCRNWD DELIMITER DESTCOUNT ¦

¦ ¦ DESTID DESTIDLENG DS3270 DSSCS EWASUPP EXTDS ¦

¦ ¦ FACILITY FCI GCHARS GCODES GMMI HILIGHT INPARTN ¦

¦ ¦ KATAKANA LDCMNEM LDCNUM MAPCOLUMN MAPHEIGHT ¦

¦ ¦ MAPLINE MAPWIDTH MSRCONTROL NATLANGINUSE ¦

¦ ¦ NEXTTRANSID NUMTAB OPCLASS OPSECURITY OUTLINE ¦

¦ ¦ PAGENUM PARTNPAGE PARTNS PARTNSET PS QNAME ¦

¦ ¦ SCRNHT SCRNWD SIGDATA SOSI STATIONID TCTUALENG ¦

¦ ¦ TELLERID TERMCODE TERMPRIORITY TEXTKYBD ¦

¦ ¦ TEXTPRINT UNATTEND USERNAME USERPRIORITY ¦

¦ ¦ VALIDATION ¦

+----------------------+-------------------------------------------------¦

¦ CONNECT PROCESS ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ CONVERSE ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ EXTRACT ATTRIBUTES ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ EXTRACT PROCESS ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ FREE ¦ all ¦


+----------------------+-------------------------------------------------¦

¦ HANDLE AID ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ ISSUE ¦ ABEND CONFIRMATION ERROR PREPARE SIGNAL PRINT ¦

¦ ¦ ABORT ADD END ERASE NOTE QUERY RECEIVE REPLACE ¦

¦ ¦ SEND WAIT ¦

+----------------------+-------------------------------------------------¦

¦ LINK ¦ INPUTMSG INPUTMSGLEN ¦

+----------------------+-------------------------------------------------¦

¦ PURGE MESSAGE ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ RECEIVE ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ RETURN ¦ INPUTMSG INPUTMSGLEN ¦

+----------------------+-------------------------------------------------¦

¦ ROUTE ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ SEND ¦ CONTROL MAP PARTNSET TEXT TEXT(MAPPED) ¦

¦ ¦ TEXT(NOEDIT) PAGE ¦

+----------------------+-------------------------------------------------¦

¦ SIGNOFF ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ SIGNON ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ SYNCPOINT ¦ ¦

+------------------------------------------------------------------------¦

¦ Note: Can be issued in server region if SYNCONRETURN specified ¦

+------------------------------------------------------------------------¦

¦ WAIT TERMINAL ¦ all ¦

+----------------------+-------------------------------------------------¦

¦ XCTL ¦ INPUTMSG INPUTMSGLEN ¦

7) +--os programas de aplicación en on-line que no tengan acceso a la commarea de

Arquitectura (QGECCAA) y necesiten recuperar el terminal lógico, la entidad, el centro

contable, el terminal contable, el usuario que ejecuta la transacción, el STARTCODE, el

idioma del terminal o el canal de entrada, deberán llamar a la rutina QG6CTUT a través de la

commarea QGECTUT, estando permitida únicamente la lectura de los datos.

8) Para las aplicaciones que usen la versión de Arquitectura Estándar, la equivalencia de

campos con la commarea NBA es la siguiente:

• CAA-TERMINAL L10-TERMINAL

• CAA-NETNAME No existente

• CAA-TERMINAL-CONT L10-TERMINAL-CONT

• CAA-NETNAME-CONT No existente


• CAA-USERID L10-USUARIO-ID

• CAA-USERID-LOGON No existente

• CAA-CANAL L10-CANAL

9) En ocasiones las transacciones conversacionales ocupan copys independientes al formato

definido para la transacción, estos se almacenan en el puntero CAA-PTRDATA que es un área

auxiliar de memoria.

En el uso de transacciones conversacionales anidadas los datos almacenados en el puntero

CAA-PTRDATA se conservarán solamente durante la ejecución de la tarea activa no se

almacenarán en tareas posteriores (independientes).

PROPAGACIÓN DE CANAL. CONSIDERACIONES GENERALES.

1. Cada tipo de terminal está asociado a un único canal por defecto que se usará en todas las

operaciones, excepto que el protocolo sea capaz de asignar uno diferente o que el terminal

disponga de modelo.

2. El campo canal refleja el tipo de canal; oficina, cajeros, banca telefónica, etc.

PROPAGACIÓN DE CANAL. CONSIDERACIONES PARA LAS APLICACIONES.

1. Se añade un campo al área de comunicación de la Arquitectura con las aplicaciones (CAA):

CAA-CANAL que refleja el canal de operación del terminal

2. Si las aplicaciones necesitan más información sobre el canal, deberán acceder ellas a la Tabla

Corporativa General de Canales.

3. Los módulos de compatibilidad se encargaran de incluir en el área de comunicación especial

el código de canal. Este aparecerá en el campo L10-CANAL.

DEFINICIÓN DE TRANSACCIONES EN EL GESTOR TRANSACCIONAL CICS

Es Importante resaltar que al gestionar la definición de las transacciones con el equipo de soporte

Middleware Cics se debe indicar que debe estar asociada al programa maestro de arquitectura

denominado QG1CDIR0 y con instalación local en las regiones AOR Altamira correspondiente al

canal que le vaya a dar servicio. Existen regiones de CICS Aor diferentes para los canales más

importantes: Banca Móvil y Provinet Personas/Empresas.


CONSIDERACIONES BÁSICAS DE CICS

1.- Conceptos Generales

Siglas CICS: Customer Information Control System. Es el servidor de aplicaciones de la

plataforma Mainframe.

Tipos de Regiones CICS. Nomenclatura y Uso

TOR (Terminal Only Region): regiones utilizadas básicamente para el establecimiento de

conexiones con entes externos a través de recursos como sockets, urimaps, mq.

AOR (Application Only Region): son las regiones donde se ejecutan las transacciones

aplicativas de todos los modulos de Altamira.

FOR (File Only Region): son las regiones donde se instalan y tratan a nivel de lectura

y escritura los archivos VSAM, por ejemplo, el archivo vsam de tablas corporativas.

Ejemplo de Archivo.

Nombre corto: RCDF0000

Nombre largo: MBVD.RCFD.STDRVSAM.RCDF0000

QOR (Quee Only Region): son las regiones que se destinan para las definiciones y

tratamiento de las colas denominadas Temporage Storage que son muy usadas en los programas de

CICS para el tratamiento de datos técnicos y de negocio.

Ejemplo de Cola.

Modelo: QGSES

Cola: QGSES600000011

2.- Principales Comandos de CICS

COMANDO

CEMT I / S TRAN(QG30)

CEMT I TERM (CJCL)

CEMT I FILE (RCDF0000)

CEMT I TSQ (+PAR )

CEMT I TSM (QGSES)

CEMT I CONN(*)

CEMT I DB2T(*)

CEMT I DB2E(*)

CEMT I DB2E(*)

FUNCIÓN

Se emplea para consultar transacciones

Se emplea para consultar terminales

Se emplea para consultar archivos en CICS de

archivos

Se emplea para consultar nombres de colas

Se emplea para consultar los nombres de

modelos

Se emplea para consultar las Conexiones entre

los CICS.

Se emplea para consultar las conexiones con los

planes de DB2.

Se emplea para consultar y actualizar la

conexión con los planes de DB2.

Se emplea para consultar las tareas activas en

un CICS.


CEMT I TASK(*)

CECI SEND MAP (Nombre del Mapa

Se emplea para consultar las tareas activas en

el CICS.

Se emplea para visualizar el mapa de una

determinada transacción y poder revisar el

tamaño de los Campos.

3.- Relación entre las Parametrizaciones de Arquitectura y el CICS (New Copy)

New Copy de Colas (Refrescamiento de Datos) - Arquitectura: este refrescamiento es el que se

realiza sobre componentes de arquitectura (transacciones, formatos, preformatos, terminales,

teclas, especificidades de función) cuando se realizan modificaciones (incorporación, eliminación,

ampliación de campos) o cambios de parámetros en dichos componentes. El New Copy de

Arquitectura no es más que el borrado de la cola de CICS donde residen las características del

elemento de arquitectura. A continuación se describe los nombres de las colas de los principales

componente de arquitectura:

Cola de Transacciones: +CCRTRAN TRAN: nombre del terminal.

Cola de Aplicativo: +APRXX. XX: Nombre del Aplicativo.

Cola de Formato y Preformato: -R*

Cola del Terminal: Nombre del terminal

Cola de Teclas: +PFRTRAN. TRAN: nombre del terminal

New Copy de Objetos de Programas (Refrescamiento del Compilado) – CICS: este

refrescamiento es el que se hace directamente en las regiones (AOR o TORES) del entorno de CICS

para actualizar la versión de los ejecutables, ya que ha sufrido algún tipo de modificación en el

código del programa, lo cual afecta la longitud de los componentes en sus principales objetos (LOD,

DBR, BAT). Se realiza como un paso de reforzamiento del procedimiento de implantación que se

ejecuta a través de la herramienta CHANGE-MAN. En síntesis, el New Copy en CICS se usa para

refrescar objetos programáticos.

4.- Principales Errores de CICS en la QMLO.

Código de Error

EIBRESP 44 (QIDERR)

EIBRESP 53 (SYSIDERR)

EIBRESP 22 (LENGERR)

EIBRESP 26 (ITEMERR)

EIBRESP 27 (PGMIDERR

EIBRESP 28 (TRANSIDERR )

Significado

No existe el contenido en la cola.

No hay conexión entre los CICS.

Longitud del Registro Incorrecta.

Registro no existe en la cola.

Programa no existe en CICS.

Transacción no existe en CICS.


EIBRESP 81 (TERMIDERR)

ICH408I

DB2 -911

DB2 -501

DB2 -923

Terminal no responde o no existe.

Errores de RACF por falta de Autoridad

Time Out por recurso ocupado.

Cierre de Cursor que no está abierto.

Conexión No establecida contra el DB2.

5.- Principales Instrucciones del CICS

LINK

WRITEQ

ENQ

CANCEL

READQ

DELETEQ

DELAY

Enlazar o Invocar programas.

Realizar escritura de Colas

Aplicar retención de un recurso

Aplicar la liberación o cancelación de un

recurso ENQ o DELAY.

Realizar lectura de colas TS.

Realizar borrado de Colas TS.

Establecer un tiempo de espera en un

determinado recurso

6.- Debugging de Programa en CICS (CEDF y CEDX).

El comando CEDF/CEDX se utiliza para monitorear y depurar los programas asociados a

transacciones CICS.

El proceso de DEBUG puede ser iniciado desde el propio terminal o región de CICS donde se está

ejecutando la transacción (CEDF) o desde un terminal diferente donde el CICS intercepta la

transacción especificada a través del comando CEDX mas el nombre de la transacción específica,

donde se muestran el panel de diagnóstico que permite correr el programa interceptando los

comandos de CICS para efecto de seguimiento y determinación de errores. Las principales teclas

que se usan en el panel de Debug son las siguientes:

F9: Establece la instrucción CICS a Monitorear.

F4. Stop en cada ejecución de las Instrucción establecida.

F2: Cambiar entre Decimal e Hexadecimal.

F5: Visualizar datos de una posición de Memoria Específica.

ENTER: se para en cada instrucción CICS.


CONSIDERACIONES GENERALES DE PROGRAMACION EN LENGUAJE COBOL

A continuación se detalla un listado de recomendaciones técnicas que se deben considerar para lograr la

generación de un código en lenguaje cobol óptimo y de excelente calidad en términos de procesamiento y

eficiencia en consumo de recursos. Estas buenas prácticas se describen partiendo desde las más comunes o

básicas, hasta algunos casos de mayor complejidad e incluso de poca utilización en la plataforma.

Consideraciones Generales de Programación en Lenguaje Cobol

El máximo valor de un campo numérico es de 18 bytes, considerando los decimales se recomienda

usar la composición siguiente: 9(15)V(2), que indica 9 posiciones enteras con 2 decimales.

El máximo valor de un campo alfanumérico es de 65620 bytes

El máximo valor de un campo editado es de 255 bytes

El máximo valor posible de campo literal o constante es de 4096 bytes

EL nombre de una variable no debe superar los 40 caracteres

El campo AUTHOR debe ir informado. Siempre debe ir informado el campo ‘AUTHOR’ con el fin

de tener identificado al autor del programa.

El PROGRAM-ID es obligatorio y debe ser igual al miembro que lo almacena. Siempre debe ir

informado el campo ‘PROGRAM-ID’ con el nombre del programa que, a su vez, debe corresponder

con el nombre del miembro que lo almacena. La finalidad es tener identificado el nombre del

programa en el código fuente.

No se recomienda el uso de COMP-2.

Se recomienda no utilizar datos numéricos en formato COMP-2 por su elevado consumo. Se deben

utilizar formatos numéricos menos consumidores.

Se recomienda no usar FILLER a nivel 01.

No se asegura que el compilador lo sitúe en memoria en el mismo orden de aparición.

Las tablas deben definirse al final de la WORKING y antes de la declaración de cursores .

Las tablas WORKING deben declararse al final de la misma y antes de la declaración de cursores

con el fin de evitar que cualquier desbordamiento provoque errores en otras variables.

Los cursores deben definirse al final de la WORKING.

Los cursores tienen que declararse en WORKING STORAGE SECTION y nunca en PROCEDURE

DIVISION ya que es sentencia declarativa. Además, deberán declararse al final de dicha sección

para evitar posibles errores de desbordamiento.

Se recomiendan programas pequeños, con menos de 5000 líneas en fuente expandido.

Se recomienda no diseñar programas con un número elevado de líneas de código con el fin de

facilitar la depuración y el mantenimiento. Máximo recomendable 5.000 líneas en fuente

expandido.


Se deben poner comentarios al inicio de los párrafos.

Al comienzo de los párrafos se deben escribir comentarios aclaratorios de los mismos.

Existen párrafos no referenciados en el código.

Todos los párrafos, sentencias y variables no utilizados deben ser eliminadas de los programas

Se recomienda el uso de INITIALIZE para variables de nivel 01.

Las variables declaradas a nivel 01 con subniveles, son alfanuméricas (incluso si todos los campos

a los que agrupa son numéricos). Por tanto, la inicialización de este tipo de variables debe hacerse

con la sentencia INITIALIZE a nivel 01.

El índice de una tabla WORKING debe ser COMP.

En la definición de un campo de índice de una tabla, utilizar el formato COMP. Cualquier otro tipo

de formato implica conversión interna cuando el índice es referenciado.

No usar INITIALIZE para DCLGEN.

La sentencia INITIALIZE de una variable a nivel 01 puede ser muy costosa dependiendo del

número de subniveles y variables dependientes. Se debe utilizar sólo cuando sea necesario

inicializar todas las variables asociadas de los subniveles inferiores.

La utilización de la sentencia GO TO está prohibida.

La sentencia GO TO es incompatible con la programación estructurada, su uso está prohibido.

No se recomienda usarla cláusula ALTER.

La cláusula ALTER es incompatible con la programación estructurada, su uso está prohibido.

No se recomienda utilizar la cláusula CANCEL.

La cláusula CANCEL, no es necesaria con un correcto diseño de aplicaciones. Su utilización es

debida normalmente a la aparición de un número elevado de niveles de llamadas entre programas

como consecuencia de una excesiva modularización. La reducción del número de llamadas a

programas dentro de la ejecución de un programa elimina la necesidad de utilizar esta sentencia.

Es obligatorio el control de WHEN OTHER en la cláusula EVALUATE.

Siempre que se utilice la sentencia EVALUATE tiene que controlarse la opción WHEN OTHER para

completar todas las posibles condiciones.

El uso de PERFORM VARYING sólo es aceptado para tratar tablas WORKING.

El uso de PERFORM VARYING sólo se permite, por rendimiento, utilizarse para bucles que

procesan tablas de datos secuencialmente. La variable de control debe ser índice de la tabla

tratada.

El PERFORM THRU debe tener su correspondiente párrafo EXIT.

PERFORM ... THRU ... : La codificación de la etiqueta de la cláusula THRU sólo debe usarse para

garantizar la legibilidad del punto de finalización del PERFORM; por esa razón, esta sentencia

abarcará un máximo de dos párrafos o etiquetas (por ejemplo, PROCESO-XXX y PROCESO-XXX-

FIN), y el contenido del segundo párrafo será una única sentencia EXIT.


El uso de PERFORM N TIMES sólo es aceptado para tratar tablas WORKING.

PERFORM N TIMES sólo se permite, por rendimiento, utilizarse para bucles que procesan tablas de

datos secuencialmente. El valor de N debe ser menor o igual al tamaño de la tabla procesada.

Está prohibido el uso de SORT interno.

En caso de necesitar ordenar los datos de entrada y/o salida, utilizar SORT a través de JCL.

No se recomienda el uso de DISPLAY [variable/literal] UPON CONSOLE.

Está completamente prohibido enviar o recibir datos por la consola del sistema.

No se recomienda el uso de ACCEPT [variable/literal] FROM CONSOLE.

Está completamente prohibido enviar o recibir datos por la consola del sistema.

No se recomienda el uso de INCLUDE en la PROCEDURE DIVISION.

Está completamente prohibido el uso de INCLUDE en la PROCEDURE DIVISION.

No se recomienda el uso de COPY en PROCEDURE DIVISION.

Está completamente prohibido el uso de COPY en la PROCEDURE DIVISION.

Se debe finalizar un IF con su END-IF correspondiente.

Por claridad, es recomendable escribir la cláusula de fin de ámbito de un IF con su correspondiente

END-IF.

Se debe finalizar un READ con su END-READ correspondiente.

Por claridad, es recomendable escribir la cláusula de fin de ámbito de un READ con su

correspondiente END-READ.

Se debe finalizar un EVALUATE con su END-EVALUATE correspondiente.

Por claridad, es recomendable escribir la cláusula de fin de ámbito de un EVALUATE con su

correspondiente END-EVALUATE.

Se debe finalizar un SEARCH con su END-SEARCH correspondiente.

Por claridad, es recomendable escribir la cláusula de fin de ámbito de un SEARCH con su

correspondiente END-SEARCH.

Para búsquedas en tablas WORKING de menos de 50 elementos usar SEARCH .

Usar la instrucción SEARCH si la tabla tiene 50 elementos o menos.

Esta instrucción es más rápida que SEARCH ALL para tablas pequeñas.

El uso de DISPLAY sólo se permite por fin de programa o por ABEND.

No se puede utilizar la sentencia DISPLAY excepto en los casos en que informa de un ABEND

controlado (errores DB2 y errores del programa) o para sacar estadísticas al final de la ejecución

del programa. Durante la fase de construcción se puede utilizar la sentencia cuando sea necesario,

pero cuando el módulo se pasa al entorno de Producción deben desaparecer todas las sentencias

DISPLAY de pruebas de programas.

Se recomienda poner punto sólo al final de párrafo.

Evitar poner un punto al final de las sentencias excepto en: 1. Fin de párrafo 2.Sentencias IF que

incluyan la sentencia NEXT SENTENCE; éstas no sólo deberán ir cerradas con END-IF, sino que

además llevarán un punto detrás del END-IF. Esto es debido a que NEXT SENTENCE ignora el END-


IF. En el caso que se cumpla la condición asociada al NEXT SENTENCE, la siguiente instrucción que

se ejecutará será la que se encuentre inmediatamente después del punto más próximo. Por esta

razón, no es recomendable el uso de la sentencia NEXT SENTENCE.

Las rutinas con sentencias DB2 deben devolver el SQLCODE al programa principal.

Las rutinas con sentencias SQL deben programarse de forma que cuando se produce un error DB2,

la rutina debe devolver el control al programa principal informándole del SQLCODE producido.

Los campos que intervienen en operaciones aritméticas deben estar definidos como COMP o

COMP-3 y tener la misma longitud.

Cualquier otro formato implica conversión interna. No se admiten constantes numéricas.

Se deben evitar las divisiones entre 0.

Evitar multiplicar y dividir por 0, utilizando si fuese necesario una instrucción IF. Estas

operaciones consumen mucho tiempo de CPU, incluso cuando los resultados no son de interés.

En la instrucción IF no se permiten más de 10 niveles de anidación.

Por mantenibilidad y rendimiento, evitar anidar un número elevado de sentencias IF.

Para búsquedas en tablas WORKING de más de 50 elementos usar SEARCH ALL.

Si la tabla está clasificada y contiene más de 50 elementos, es más eficiente utilizar SEARCH ALL.

Se debe evitar el uso de IF NUMERIC e IF ALPHABETIC.X

Las condiciones IF NUMERIC, IF ALPHABETIC utilizan la instrucción máquina TRT.

Esta instrucción es muy potente y a la vez muy costosa, por lo que se recomienda que se utilice lo

menos posible. Para evitar la utilización de estas instrucciones hay que definir los datos de origen

en fase de diseño en el formato correcto.

No incluir SQLCA si no hay accesos DB2 en el programa.

Los programas que no contengan accesos SQL no deben incluir la SQLCA.

Se han detectado INCLUDE de tablas no utilizadas en el programa.

Las sentencias INCLUDE de tablas que no se utilicen en el programa deben eliminarse. Hacen el

DBRM más grande de lo necesario.

Es obligatorio controlar la variable de FILE STATUS después de cada sentencia de acceso a

ficheros.

No se recomienda utilizar ninguna línea de código entre la sentencia de acceso a fichero y el

control de su FILE-STATUS.

No se recomienda el uso de la variable RETURN-CODE.

Para condicionar ejecuciones posteriores se deben utilizar las condiciones de disparo del

planificador.

Se debe evitar el uso de LIKE '%' y LIKE '_'.

Evitar la utilización de operadores LIKE donde la expresión a evaluar no empiece por un valor

concreto, como por ejemplo: 1. LIKE ‘%dato’ 2. LIKE ‘_dato’.

Este tipo de predicado no es indexable y por tanto si se aplican a campos de índice, estos serán

ignorados por DB2 en el momento de decidir el camino de acceso.


No se recomienda la utilización del SUBSELECT.

No se debe utilizar SUBSELECT salvo en casos puntuales y estrictamente necesarios. Esta exigencia

debe preverse y evitarse durante la fase de diseño del modelo de datos.

No se recomienda la utilización de JOIN de dos tablas.

No se debe utilizar JOIN de tablas salvo en casos puntuales y estrictamente necesarios. Esta

exigencia debe preverse y evitarse durante la fase de diseño del modelo de datos.

Evitar el uso o la existencia de sentencias SQL que no se ejecutan.

No se pueden codificar sentencias SQL que no son ejecutadas durante el proceso. Esto hace que

tanto el DBRM como el PLAN sean más grandes de lo necesario, aumentando el tiempo de carga y

el espacio en el EDM POOL necesario para dicha carga. Si por modificación del módulo se quiere

dejar esa sentencia aunque ya no se utilice, debe dejarse como comentario.

En las sentencias FETCH o SELECT se están recuperando campos que no se utilizan

Los datos necesitados de una tabla deben obtenerse mediante un único acceso a ésta.

Evitar reiteradas consultas sobre una misma tabla para recuperar diferentes atributos de un

registro, los datos necesitados de una tabla y todos los atributos de una entidad que se necesiten a

lo largo de un programa, deben ser obtenidos mediante un único acceso.

Las tablas DB2 de bajo volumen y muy accedidas deben copiarse en WORKING al principio

de la ejecución del programa.

En procesos BATCH, es mejor desde el punto de vista de rendimiento acceder a este tipo de tablas

con sentencias de búsqueda COBOL que a través de sentencias SQL. Para el caso de online, sólo en

caso de necesitarse el 90% de las filas de la tabla en cada ejecución, en caso contrario, acceder sólo

a las filas necesarias. Para CCR y en caso de CICS, se podrá cargar la tabla en una Temporary

Storage si se comparte con más transacciones o ejecuciones de una misma transacción

En sentencias SQL se deben utilizar variables DCLGEN u otras definidas en WORKING con la

misma estructura.

En cualquier sentencia SQL, las variables SQL utilizadas deben ser las definidas en la DCLGEN o, si

no se puede, utilizar variables definidas en WORKING con el mismo formato que el generado para

la columna afectada en la DCLGEN. Cuando las variables utilizadas no tienen el mismo formato,

DB2 se ve forzado a realizar conversiones innecesarias. Si además la columna forma parte de un

índice, puede que DB2 no utilice dicho índice, por esta causa, en el acceso; este es el caso de

comparaciones numéricas de distinta precisión, así como alfanuméricas donde la variable HOST es

más larga que el atributo a comparar.

Detectado programa excesivamente grande, con más de 15.000 líneas expandidas.

Se recomienda no diseñar programas con un número elevado de líneas de código con el fin de

facilitar la depuración y el mantenimiento. Además la carga en máquina de este tipo de módulos es

costosa, condicionando el rendimiento del programa.

No debe usarse SQL dinámico.

No se recomienda la utilización de SQL dinámico en programación.

La sentencia FETCH debe incluir las mismas columnas y en el mismo orden que aparecen en

la declaración del cursor.

Para prevenir errores, la sentencia FETCH debe contemplar las mismas columnas y en el mismo


orden que el cursor del que se está leyendo.

Se han detectado cursores que no han sido cerrados durante la ejecución del programa.

Es obligatorio cerrar de forma explícita todos los cursores abiertos durante un proceso.

Sólo en caso de error serán cerrados por terminación anormal.

Las columnas actualizadas en UPDATE deben ser las mismas que las declaradas en la

cláusula FOR UPDATE.

Las columnas actualizadas mediante la sentencia UPDATE WHERE CURRENT OF CURSOR deben

ser todas las declaradas en la cláusula FOR UPDATE.

En cursores para borrar filas con DELETE WHERE CURRENT OF, en la cláusula FOR UPDATE

debe tener una sola columna.

Para los cursores declarados FOR UPDATE y en los que sólo se pretende borrar filas (no

actualizaciones) con la sentencia DELETE WHERE CURRENT OF CURSOR, en la cláusula FOR

UPDATE del DECLARE CURSOR sólo se debe declarar una columna.

Evitar el uso de un cursor FOR UPDATE que no informa en el SET del WHERE CURRENT OF

todas las columnas.

En la cláusula FOR UPDATE no se deben incluir columnas que no van a ser modificadas en el

proceso.

El cursor definido puede ser transformado en una SELECT.

Los cursores deben ser utilizados sólo cuando el WHERE de la sentencia devuelva más de una fila y

además todas las filas devueltas necesiten ser tratadas por el programa. En caso contrario, se

deben utilizar sentencias SELECT, controlando el SQLCODE –811 en caso de que la sentencia

devuelva más de una fila.

Evitar el uso de GROUP BY en un acceso SQL.

Por rendimiento, evitar el uso de la cláusulas GROUP BY en sentencias que provoquen SORT DB2

No se recomienda el uso de SELECT *.

Esto es debido a que su uso no independiza al módulo de posibles alteraciones de la tabla como

añadir columnas, etc.

No deben usarse constantes en sentencias SQL excepto cuando se usa IN / NOT IN.

Definir variables HOST para estas constantes y utilizar estas variables en la sentencia SQL.

Es conveniente utilizar las variables HOST definidas en la DCLGEN.

No se debe usar la sentencia SELECT COUNT(*) si sólo se pretende verificar la existencia o

no de filas.

Utilizar para ello una sentencia SELECT y controlar los valores de SQLCODE 0, -811 y 100 para

comprobar si existe o no la fila buscada. Si se precisase conocer el número de filas afectadas por un

UPDATE/DELETE/INSERT, puede obtenerse del campo SQLERRD(3) de la SQLCA una vez

ejecutada la instrucción.

La sentencia INSERT debe codificarse completa y con las variables HOST en el mismo orden

que los valores que toman.

Las variables HOST deben estar en el mismo orden en que se han especificado los atributos. Esto

no significa que se especifiquen todas las columnas de una tabla, sino aquéllas que se necesiten, ya


que el resto tomarán los valores por defecto:

1. Espacios para atributos alfanuméricos.

2. Ceros para atributos numéricos.

3. Fecha y/o Hora actual en campos de fecha y hora.

Se debe usar CURSOR FOR UPDATE en lugar de realizar SELECT y UPDATE/DELETE.

Si es necesario conocer previamente el valor de la fila a modificar ó borrar: utilizar un cursor

declarado FOR UPDATE en lugar de realizar primero una sentencia SELECT y luego la sentencia de

actualización. La razón es la forma de adquirir el bloqueo, ya que de la forma recomendada se

evitan posibles DEADLOCKS y TIMEOUTS.

No se recomienda realizar actualizaciones masivas mediante una sentencia SQL.

Dependiendo de la discriminación del WHERE pueden provocar un número elevado de bloqueos,

perjudicando la concurrencia de las aplicaciones.

Se debe controlar el WHEN OTHER/ELSE del SQL para que lleve a la cancelación controlada

del programa.

Los valores no estándar de SQLCODE que no se controlan explícitamente en el programa, deben

controlarse de forma genérica con una cláusula WHEN OTHER/ELSE y provocar la cancelación del

programa.

Evitar el uso de ROLLBACK.

La utilización de la sentencia ROLLBACK puede ser peligrosa.

Faltan por controlar valores necesarios del SQLCODE.

El control del SQLCODE tiene que realizarse inmediatamente después de realizar la sentencia SQL.

Además, es muy importante realizarlo de forma correcta. A continuación se detallan los códigos de

retorno de cada sentencia. Dichos códigos deben ser tratados siempre por programa.

En sentencias SELECT sobre tabla con índice único e informando todos los campos del índice por

igual, los códigos controlables son:

SQLCODE = +0 Registro Encontrado

SQLCODE = +100 Registro no Encontrado

En sentencias SELECT que puedan recuperar más de una fila, los códigos controlables son:

SQLCODE = +0 Registro Encontrado

SQLCODE = +100 Registro no Encontrado

SQLCODE = -811 Más de una fila cumple la condición de búsqueda

En sentencias INSERT sobre tablas con índice único, los códigos controlables son:

SQLCODE = +0 Acceso Correcto

SQLCODE = -803 Registro Duplicado

En sentencias INSERT sobre tablas que no tienen índice único, los códigos controlables son:

SQLCODE = +0 Acceso Correcto

En sentencias DELETE los códigos controlables son:


SQLCODE = +0 Borrado correcto de todas las filas que cumplen la condición

SQLCODE = +100 Ningún registro cumple la condición

En sentencias UPDATE los códigos controlables son:

SQLCODE = +0 Actualización correcta de todas las filas que cumplen la condición

SQLCODE = +100 Ningún registro cumple la condición

SQLCODE = -803 Registro duplicado (Índices únicos)

En sentencias OPEN y CLOSE los códigos controlables son:

SQLCODE = +0

Sentencia ejecutada correctamente

En sentencias FETCH los códigos controlables son:

SQLCODE = +0 Registro leído

SQLCODE = +100 No existen más registros que cumplen la condición

En sentencias DELETE y UPDATE WHERE CURRENT OF CURSOR los códigos controlables son:

SQLCODE = +0 Proceso correcto

Se debe evitar el uso del ACCEPT FROM DATE, TIME o DAY.

No se deben utilizar las sentencias ACCEPT DATE, TIME y DAY como fechas de proceso.

La fecha de proceso debería ser un atributo más del modelo de datos de la aplicación.

Si la fecha del sistema se utiliza como fecha de proceso, hay que tener en cuenta los problemas que

se podrían ocasionar si se tuviera que repetir un proceso con fecha del día anterior. Si el resultado

se utiliza para cabeceras de listado o similar, ejecutar cada sentencia una sola vez en el programa.

Se debe codificar OPEN, READ, WRITE una sola vez.

La apertura (OPEN) y cierre (CLOSE) de ficheros se codificarán, siempre que sea posible, una sola

vez en el programa, invocándolas vía PERFORM cada vez que se utilicen. Lo mismo con sentencias

READ y WRITE. Diferenciar el tipo de apertura de ficheros y codificar la sentencia OPEN como

INPUT, OUTPUT o INPUT/OUTPUT.

Se deben agrupar la apertura y cierra de todos los ficheros en un mismo OPEN y CLOSE.

Se deben agrupar tanto las instrucciones OPEN como las CLOSE en una sola instrucción.

No debe usarse en WRITE el registro 01 de la FD, ni una variable working de mayor longitud

que el tamaño del registro.

Las sentencias de escritura (WRITE) de ficheros, se deben codificar utilizando variables definidas

en la WORKING con idéntica longitud (se admite menor), y no trabajar nunca con las definiciones

de la FD de la FILE SECTION.

Se debe eliminar el uso de ON SIZE ERROR.

Eliminar la cláusula ON SIZE ERROR usando técnicas como comprobar que el denominador no está

a cero antes de ejecutar la instrucción. Esto es debido al elevado número de instrucciones máquina


para chequear que no se ha producido error después de ejecutar dicha instrucción.

No se permite la utilización de más de 10 ficheros en un programa.

Por mantenibilidad, se recomienda no diseñar programas que manejen un número elevado de

ficheros (máximo 10).

No debe usarse AFTER o BEFORE en WRITE.

En su lugar utilizar el carácter ASA escribiendo en ficheros definidos FBA.

El fichero referenciado no ha sido cerrado.

Como medida preventiva hacia la aparición de errores, se deben cerrar de forma explícita todos los

ficheros que sean abiertos a lo largo del programa.

Evitar el uso de ficheros VSAM.

La utilización de ficheros VSAM queda restringida a casos muy específicos. La necesidad de

utilización de este tipo de ficheros debe ser consultada con Calidad Técnica en fase de diseño.

Evitar la definición de una tabla WORKING con demasiados elementos (más de 5.000) ó un

tamaño total grande.

Por rendimiento del programa, se recomienda no utilizar en los programas tablas que tengan

definido un número elevado de ocurrencias. No se deben definir tablas que ocupen mucha zona de

memoria.

Los datos contenidos en estas tablas WORKING grandes deberían almacenarse en otro tipo de

dispositivos, como ficheros o tablas DB2, a los que se puede acceder de una forma más eficiente

cara al consumo de recursos.

Se han detectado más llamadas a rutinas de las permitidas (máximo: 10).

Se recomienda diseñar los procesos evitando la excesiva modularización de programas.

Este tipo de procesos implican un elevado consumo de recursos como consecuencia del coste

aplicado a la carga de módulos en máquina.

No se recomienda el uso de la sentencia LOCK TABLE.

No se puede utilizar la sentencia LOCK TABLE, ya que el nivel de bloqueo, en este caso, lo decide el

programa; es decir, el ámbito y duración del bloqueo quedan definidos por el propio programa,

pudiendo provocar con ello contenciones en datos. Además, existen otras maneras de bloquear los

datos de forma más ágil, eficiente e independiente del programa.

Se han detectado accesos SQL duplicados.

Las sentencias SQL idénticas deben codificarse en un párrafo aparte e invocarlas mediante

PERFORM, en lugar de escribirlas varias veces en el programa. Hacen el DBRM más grande de lo

necesario.

No se recomienda el uso de funciones sobre variables HOST en la cláusula WHERE de las

sentencias SQL.

Se recomienda no utilizar expresiones aritméticas en la parte derecha de la cláusula WHERE en

sentencias SQL; en su lugar, realizar la operación aritmética, mover el resultado a una variable

HOST y comparar con dicha variable. Esto se debe a que en dichos casos, si la columna a comparar

forma parte de un índice, el DB2 decide no acceder por el mismo, incrementando el coste de la


sentencia.

No se recomienda el uso de la DCLGEN a nivel 01.

En sentencias SQL está prohibido el uso de la DCLGEN a nivel 01, las columnas deben ser siempre

referenciadas una a una. La razón es la misma que en el caso de SELECT *.

Evitar el uso de un acceso a una tabla pequeña (nº páginas <= 7) en el que no se informan

los primeros campos de índice.

Siempre que las tablas DB2 tengan índices definidos, las sentencias SQL deben acceder por campos

que estén incluidos en estos índices. Además, se debe informar el mayor número posible de

campos del índice por el que se accede, informando siempre los primeros campos para evitar que

el acceso a DB2 sea costoso.

No se recomienda el uso de funciones sobre columnas en la cláusula WHERE de las

sentencias SQL.

Evitar la utilización de operaciones con columnas de la tabla en las cláusulas WHERE de las

sentencias., como por ejemplo : 1. WHERE COL1 + COL2 = :VAR-HOST 2. WHERE COL1 = COL1 +

:VAR-HOST 3. WHERE COL1 = COL2 + :VAR-HOST 4. WHERE SUBSTR(COL1,n,n) = :VAR-HOST 5.

WHERE UPPER(COL1) = :VAR-HOST .

Estos tipos de predicado no son indexables y por tanto si se aplican a campos de índice, estos

serán ignorados por DB2 en el momento de decidir el camino de acceso.

Evitar el uso de SORT DB2 en el acceso a la tabla.

Se debe tratar de evitar la realización de SORT por parte de DB2.

Si existe una necesidad funcional, deben buscarse soluciones de diseño identificando el origen de

la necesidad del SORT con el fin de evitarlo. Posibles soluciones al SORT DB2, dependiendo de cada

caso en particular y de la gravedad del SORT podrían ser :

- Pasos previos de SORT en JCL

- Cambios en el orden de tablas del modelo de datos

- Diseño de índices alternativos.

- Modificación de índices existentes.

- Etc, dependiendo del caso.

Se debe evitar el uso de sentencias SELECT función con baja discriminación en las

condiciones de la cláusula WHERE.

Es muy costoso utilizar sentencias SELECT <FUNCION> con cláusulas WHERE poco restrictivas que

seleccionen un elevado número de filas. Se debe evitar su uso.

Evitar la definición de una tabla en LINKAGE con demasiados elementos o un tamaño total

grande.



memoria.


Evitar el uso de COMMIT.

Se detecta la utilización de la sentencia COMMIT. La frecuencia de COMMIT en el programa

dependerá de factores como la hora de ejecución, el tipo de tablas a actualizar, la concurrencia con

otras aplicaciones, el tipo de proceso, el bloqueo de recursos etc. La sentencia COMMIT es costosa

por lo que la elección correcta de la frecuencia de COMMIT en el programa es importante.

Evitar el uso de una sentencia sobre una tabla pequeña (nº páginas <= 7), que usa más de

un índice para resolver el acceso.

No se deben construir sentencias SQL que accedan a las tablas utilizando más de un índice definido

sobre ellas. Posibles soluciones , dependiendo de cada caso en particular y de lo costoso del acceso,

podrían ser :

- Modificaciones funcionales que permitan cambiar el WHERE de la sentencia.

- Rediseño de los índices existentes.



Se debe definir correctamente el indicador de nulos (PIC S9(4) COMP).

La definición correcta es:

WORKING-STORAGE SECTION

----------

05 IND-NULL PIC S9(4) COMP.

No se debe utilizar el indicador de nulos en SELECT COUNT, utilizar SQLCODE.

En la sentencia SQL SELECT COUNT(*) no se debe contemplar indicador de nulos, solamente debe

controlarse el SQLCODE.

No mezclar SQLCODE con variables del programa en IF.

Es obligatorio controlar el SQLCODE inmediatamente después de la sentencia SQL.

No se recomienda utilizar ninguna línea de código entre la sentencia SQL y el control de su

SQLCODE. Además, la línea de control debe ser exclusiva para el SQLCODE, es decir, no se deben

mezclar la condiciones del control de SQLCODE con variables HOST del programa.

un control de valores de SQLCODE que no pueden darse.

Cualquier valor de SQLCODE diferente de los estándares son errores y deben tratarse como tal.

Evitar el uso de SELECT CURRENT TIMESTAMP.

Evitar la utilización de sentencias SELECT CURRENT TIMESTAMP, DATE o TIME. La fecha de

proceso debería ser un atributo más del modelo de datos de la aplicación. Si la fecha del sistema se

utiliza como fecha de proceso, hay que tener en cuenta los problemas que se podrían ocasionar si

se tuviera que repetir un proceso con fecha del día anterior. Si el resultado se utiliza para

cabeceras de listado o similar, ejecutar cada sentencia una sola vez en el programa.

Evitar el uso de la sentencia WHENEVER.

Es muy costoso el control del SQLCODE a través de la sentencia WHENEVER SQLERROR.

Se recomienda controlar el SQLCODE de forma explícita en el programa.


Evitar el uso de LIST PREFETCH en el acceso a DB2.

En ON-LINE, los cursores que tienen como finalidad construir listas, no deberían recuperar muchas

filas. Si debido a las condiciones de los WHERE los cursores recuperaran muchas filas, sería

necesario aplicar técnicas de lista-reposicionamiento para realizar recuperaciones parciales de

filas y optimizar los accesos.

La sentencia desencadena un proceso costoso de SORT por parte de DB2, debido al elevado

número de filas seleccionadas .

Si existe una necesidad funcional, deben buscarse soluciones de diseño identificando el origen de

la necesidad del SORT con el fin de evitarlo. Posibles soluciones al SORT DB2, dependiendo de cada

caso en particular y de la gravedad del SORT podrían ser :

- Pasos previos de SORT en JCL

- Cambios en el orden de tablas del modelo de datos


- Modificación de índices existentes.


Se están recuperando campos que se condicionan por igual en el WHERE.

No se deben recuperar campos que se condicionan por igual en el WHERE: el valor del campo es

conocido y por lo tanto no es necesario aumentar el bloque de E/S. Sólo en caso de comprobar la

existencia o no de un registro en una tabla, se justifica esta selección.

Evitar el uso de un acceso sobre una tabla mediana (7 < nº páginas < 10.000), en el que no

hay campos del índice informados en el WHERE.

Siempre que se pueda se deben utilizar los campos del índice para el acceso a datos. DB2, si puede

utilizar los índices, los utiliza facilitando así el camino de acceso a datos. Dependiendo del tamaño

de la tabla, del WHERE de la sentencia y de la frecuencia de ejecución del programa, podría ser

conveniente la creación de un índice sobre la tabla.

Se debe cambiar en la cláusula WHERE la condición C>DATO OR C=DATO por C>=DATO.

Aunque las dos sentencias siguientes recuperan los mismo datos, DB2 realiza un proceso de

búsqueda más sencillo en el segundo caso que en el primero:

1.WHERE (C1 > &gml.C1 OR C1 = &gml.C1)

2.WHERE (C1 >= &gml.C1)

No se permite el uso de la cláusula UNION.

Evitar la utilización de sentencias SELECT UNION y UNION ALL. Modificaciones en el modelo de

datos pueden evitar la utilización de estas sentencias.

No usar NOT> y NOT<, usar <= y >= respectivamente.

Evitar todos aquellos casos en los que DB2 no utiliza índices (predicados no indexables) como:

1. Predicados con '<>' o 'Not ='

2. Predicados con 'Not >' y 'Not <' que se pueden cambiar por '<=' y '>=' respectivamente

Si se necesita saber si existe o no una fila, buscarla seleccionando un solo campo y que sea

de índice.

Si es necesario verificar sólo la existencia o no de una fila y, no es necesario conocer ningún valor

de la misma, seleccionar sólo una columna del índice (aunque se condicione por igual). Esto

provoca que DB2 sólo acceda al fichero de índices no teniendo necesidad de acceder al fichero de


datos.

Evitar el uso de CURRENT DATE.

La fecha de proceso debería ser un atributo más del modelo de datos de la aplicación. Si la fecha del

sistema se utiliza como fecha de proceso, hay que tener en cuenta los problemas que se podrían

ocasionar si se tuviera que repetir un proceso con fecha del día anterior.

Evitar el uso de CURRENT TIME.

Si la hora del sistema se utiliza como hora de proceso puede ser peligroso por los posibles desfases.

El control del SQLCODE debe hacerse inmediatamente después de cada acceso SQL.

No se recomienda usar ninguna línea de código entre la sentencia SQL y el control de su SQLCODE.

Evitar el uso de un cursor declarado FOR UPDATE sin DELETE o UPDATE WHERE CURRENT

posterior.

Los cursores declarados con la cláusula FOR UPDATE deben tener una sentencia UPDATE/DELETE

WHERE CURRENT OF CURSOR asociada en el programa.

En UPDATE no se deben poner columnas cuyo valor no ha sido modificado.

No deben incluirse en la cláusula SET de un UPDATE columnas cuyo valor no hay sido modificado a

lo largo de la ejecución del programa.

No deben usarse SELECT/FETCH para verificar la existencia de una fila para su posterior

lectura o actualización.

Se deben controlar directamente los valores de retorno del SQLCODE en la sentencia de

actualización para comprobar si la fila existe.

Evitar el uso de HAVING.

Por rendimiento, no es recomendable la utilización de la cláusula de condición HAVING para

GROUP BY. Se deben realizar diseños de aplicación que eviten la utilización de este tipo de

cláusulas en fase de programación.

No se recomienda el uso de la cláusula CASE.

Por rendimiento no es recomendable la utilización de la cláusula CASE. Se deben realizar diseños

de aplicación que eviten la utilización de este tipo de cláusulas en fase de programación.

Evitar el uso de DISTINCT.

Por rendimiento no es recomendable la utilización de la cláusula DISTINCT. Se deben realizar

diseños de aplicación que eviten la utilización de este tipo de cláusulas en fase de programación.

Se recomienda el uso de INCLUDE de la DCLGEN de las tablas DB2 utilizadas.

Para todas las tablas utilizadas en el programa, se debe incluir la DCLGEN de cada una de ellas.

Evitar el uso de un cursor en PROCEDURE que no está declarado.

Los CURSORES referenciados a través de sentencias SQL OPEN, CLOSE y FETCH deben estar

declarados en el programa.

No están permitidas vistas que en su definición incluyan más de una tabla.


Por rendimiento, la utilización de este tipo de vistas es muy costosa.

Evitar el uso de la definición de una tabla en LINKAGE con demasiados elementos ó un

tamaño total muy grande.



memoria

En las sentencias FETCH o SELECT se están recuperando más de 10 campos que no se

utilizan

Las sentencias SQL no deben recuperar columnas que no se utilizan en el proceso.

Evitar el uso de la definición de una tabla WORKING con demasiados elementos (más de:

10.000) ó un tamaño total muy grande.



memoria.

Los datos contenidos en estas tablas WORKING grandes deberían almacenarse en otro tipo de

dispositivos, como ficheros o tablas DB2, a los que se puede acceder de una forma más eficiente

cara al consumo de recursos.

Evitar el uso de un acceso sobre una tabla grande (nº páginas >= 10.000), en el que no hay

campos del índice informados en el WHERE.





Evitar el uso de un acceso a una tabla mediana (7 < nº páginas < 10.000) en el que no se

informan los primeros campos de índice.





Evitar el uso de un acceso a una tabla grande (nº páginas >= 10.000) en el que no se






Evitar el uso de un acceso dentro de un bucle a una tabla (nº páginas >= 7) en el que no se







Evitar el uso de una sentencia sobre una tabla mediana (7 < nº páginas < 10.000), que usa

más de un índice para resolver el acceso.


sobre ellas. Posibles soluciones , dependiendo de cada caso en particular y de lo costoso del acceso,

podrían ser :





Evitar el uso de una sentencia sobre una tabla grande (nº páginas >= 10.000), que usa más

de un índice para resolver el acceso.


sobre ellas. Posibles soluciones, dependiendo de cada caso en particular y de lo costoso del acceso,

podrían ser :




- Etc, dependiendo del caso

Evitar el uso de un acceso en un bucle sobre una tabla (nº páginas >= 7), en el que no hay

campos del índice informados en el WHERE.





Evitar el uso de una sentencia dentro de un bucle sobre una tabla (nº páginas >= 7), que usa

más de un índice para resolver el acceso.


sobre ellas. Posibles soluciones, dependiendo de cada caso en particular y de lo costoso del acceso,

podrían ser :





No se recomienda la utilización de JOIN de más de dos tablas.

No se debe utilizar JOIN de tablas salvo en casos puntuales y estrictamente necesarios. Esta

exigencia debe preverse y evitarse durante la fase de diseño del modelo de datos.

No se recomienda la utilización de JOIN que contengan accesos costosos (R0, I0, MX).

No se debe utilizar JOIN de tablas que requieran accesos costosos a alguna de las tablas que

intervienen. Deben evitarse especialmente, accesos de tipo R0, I0 y MX. Esta exigencia debe

preverse y evitarse durante la fase de diseño del modelo de datos.


No se recomienda el uso de sentencias SQL que incluyan tablas temporales definidas

mediante la cláusula ‘AS’.

Se debe evitar el uso de sentencias que asignan mediante la cláusula “AS” un nombre de tabla

temporal a una subsentencia SQL incluida dentro de una sentencia SQL principal.

Evitar el uso de repetición de la operación Open / Close para un fichero a lo largo del

proceso.

Se ha de comprobar si el tratamiento verdaderamente requiere esta operatoria y tratar de evitarla

mediante el rediseño del modelo de procesos.

En sentencias que usen la opción MULTIROW, el tamaño del ROWSET nunca debe ser

superior a 200.

Por encima der de 200, la mejora en el rendimiento de las sentencias se ve considerablemente

mermado.

En sentencias que usen la opción MULTIROW, el valor del parámetro “N” de la opción FOR

“N” ROWS ha de ser <= al OCCURS de la tabla definida para recibir el ROWSET.

Se debe garantizar que todas las filas seleccionadas mediante la opción MULTIROW, tienen el

espacio necesario definido en la tabla que recibirá el ROWSET.

Si un cursor se define WHIT ROWSET POSITIONING, el FETCH correspondiente a ese cursor,

debe ser definido con la cláusula NETX ROWSET y viceversa.

La definición del cursor y el tratamiento de las filas seleccionadas por el mismo, ha de ser

concordante.

Si una sentencia está definida con la cláusula NEXT ROWSET, se debe realizar un control y

tratamiento adecuados del SQLCODE -100.

Se ha de comprobar si el ROWSET devuelto junto con el SQLCODE -100 ha devuelto alguna fila y

realizar el tratamiento adecuado para el conjunto de filas devuelto. El nº de filas realmente

devuelto, se obtiene examinado el contenido de SQLERR(3).

Todas las columnas declaradas en la SELECT de un cursor definido WITH ROWSET

POSITIONING deben ser utilizadas posteriormente en el programa.

Se debe garantizar que todas la filas seleccionadas son necesarias puesto que son usadas

posteriormente en el programa.

En sentencias INSERT definidas con opción MULTIROW, no se permite usar la cláusula NOT

ATOMIC CONTINUE ON SQLEXCEPCION.

Se debe garantizar que si el INSERT termina con error, no se ha insertado ninguna fila y todo el

ROWSET ha sido rechazado. No se permiten inserciones parciales por la dificultad de control.

En sentencias que usen la opción MULTIROW, la frecuencia del COMMIT, se debe definir en

función del número de filas afectado por cada sentencia, no del número de sentencias

ejecutado.

Cada sentencia afecta a un número de filas que viene determinado por el tamaño del ROWSET,

luego se tendrá en cuenta este dato para calcular la frecuencia del COMMIT, no solo el número de

sentencias ejecutado.


En sentencias UPDATE ö DELETE definidas con opción MULTIROW, No se recomienda usar

la cláusula FOR ROW “N” para actualizar ó borrar solo la N’ésima fila del ROWSET.

Se considera una práctica de riesgo y de difícil control realizar una sentencia que solo afecte a una

fila de un ROWSET que contiene varias.

En el tratamiento de OBJETOS SEQUENCE mediante cláusulas NEXT VALUE y PREVIOUS

VALUE, se debe controlar respectivamente, el SQLCODE -359 y -845.

El control adecuado de estos códigos, garantiza la fiabilidad del valor de la secuencia obtenida y

permite tomar las acciones oportunas cuando se producen.

El uso de cursores SCROLLABLES está estrictamente prohibido en la instalación.

Se considera una práctica de riesgo el uso de este tipo de cursores y no se permite su uso.

Es obligatorio definir mediante el uso de una COPY cualquier variable de uso EXTERNAL.

El control adecuado de este tipo de variables y su uso, requiere el uso de COPY para evitar

duplicidades y uso indebido de las mismas.

Es obligatorio sustituir los módulos obsoletos por el correspondiente módulo actualizado.

Los módulos de otras aplicaciones que sean llamados desde cualquier otra aplicación, deben ser

sustituidos por la nueva versión de los mismos cuando queden obsoletos. Se debe consultar a la

aplicación propietaria, los datos del nuevo módulo que sustituye al obsoleto.

El uso de la instrucción FUNCTION se considera que afecta negativamente al rendimiento.

Se recomienda buscar una alternativa al uso de la instrucción FUNCTION debido al coste de su uso.

No se recomienda el uso de REWRITE en ficheros secuenciales. No es óptimo utilizar la

sentencia REWRITE para reemplazar registros existentes en ficheros secuenciales. Este tipo de

mantenimiento se debe realizar a través de JCL.

Definición de fichero sin FILE STATUS o FILE STATUS mal definido

Es obligatorio controlar cualquier acceso a fichero mediante el FILE-STATUS. Debe ser declarado y

tratado en PROCEDURE DIVISION.

SELECT F-ENTRADA ASSIGN TO EJEMPLO

FILE STATUS IS FS-EJEMPLO.

Donde EJEMPLO es la DDNAME correspondiente al fichero elegido. El campo FS-EJEMPLO debe

estar definido posteriormente en WORKING como un campo alfanumérico de 2 posiciones.

01 DEF-FILE-STATUS.

05 FS-EJEMPLO PIC X(2) VALUE '00'.

El control correcto del FILE-STATUS tiene como objetivo el minimizar posibles ABENDS del

programa.

La cláusula BLOCK CONTAINS debe estar definida como BLOCK CONTAINS 0 RECORDS.

La cláusula BLOCK CONTAINS debe tener definido siempre 0 RECORDS para dejar al JCL la gestión

del bloque óptimo según el tipo de dispositivo.

No se permite la cláusula LINAGE.

No es óptimo utilizar la cláusula LINAGE en la definición de ficheros para especificar el tamaño de

una página lógica. El salto de página debe controlarse mediante caracteres ASA.


No permitida la cláusula OPTIONAL en la FILE CONTROL.

No se debe utilizar la cláusula OPTIONAL en la FD de definición de ficheros. Un fichero tratado por

un programa debe existir en el momento de la ejecución.

En la sentencia READ usa el registro 01 de la FD o una variable WORKING con distinta

longitud.

No se puede utilizar nunca la definición de registro REG-ENTRADA de la FILE SECTION para leer,

hay que utilizar un registro definido en WORKING con idéntica longitud (se admite mayor), y con la

definición de campos necesaria.

En SEARCH debe controlarse la cláusula AT END.

Siempre que se utilice la sentencia SEARCH tiene que controlarse la opción AT END de fin de

búsqueda.

No utilizar la cláusula NOREWIND en ficheros secuenciales.

Si un programa utiliza entrada mediante cinta, y ésta no puede ser cargada a disco previamente, no

se debe utilizar la opción NOREWIND.


Manual de Recomendaciones - Desarrolladores Cobol DB2-CICS en Altamira

Create successful ePaper yourself

Delete template?

Save as template?