Estandar de estructura de un programa cobol

27/9/2018 Estandar de Estructura de Un Programa Cobol
http://coboleross.foroactivo.com/t21-estandar-de-estructura-de-un-programa-cobol 1/18
Estandar de Estructura de Un Programa Cobolpor Coboler@ el Miér Feb 16, 2011 9:47 pm
DESCRIPCIÓN
Este documento define los estándares Cobol, a considerar en la
instalación, para codificar en base a unos fundamentos básicos
de programación en Cobol para una estructuración básica de un
programa.
1. IDENTIFICATION DIVISIÓN
1. Los programas deberán llevar un bloque de comentarios con la
siguiente información :
Un resumen de la función del programa (siempre que se
pueda, evitar que la descripción exceda de 12 líneas).
Cuadro para registro de modificaciones, con las siguientes
columnas:
1. Fecha de la modificación.
2. Autor de la modificación / Marca de identificación.
3. Descripción de la modificación.
2. ENVIRONMENT DIVISION
1. SPECIAL-NAMES. Se pondrá siempre la sentencia:
DECIMAL-POINT IS COMMA.
2. La organización y el tipo de acceso sólo se especificará en el
caso de tratar fichero VSAM.
3. El nombre externo de los ficheros en la sentencia SELECT será
el nombre de la DDNAME del fichero, este nombre seguirá las
reglas de nomenclatura definidas en la instalación de Mutua
Madrileña Automovilista, el nombre interno del fichero es libre y
debe decir algo sobre los datos que contiene.
4. La descripción del registro se codificará en la cláusula DATA
RECORD de la FD.
3. DATA DIVISION

1. No se utilizará cláusula SD (sort interno) por razones de
eficiencia.
2. Es obligatorio incluir las cláusulas BLOCK CONTAINS 0
RECORDS y RECORD CONTAINS, en la descripción de los
ficheros.
3. Las descripciones de ficheros se deben escribir en el mismo
orden que están en las SELECT.
WORKING STORAGE SECTION.
1. Los campos de fechas se definirán con 4 dígitos para el año
(evita problemas de cambio de siglo).
2. Los campos de importe deben tener espacio suficiente para
contener todas las unidades monetarias que recoge el proyecto y
deben incluir, además, como mínimo dos decimales.
3. Los nombres de los campos pertenecientes a un fichero
deberán llevar un prefijo que los identifique con él.
4. Las descripciones de los registros, se realizarán en miembros
independientes al programa, a los que se hará referencia
mediante COPY, salvo en el caso de que esa estructura solo se
use en un programa.
5. Los grupos de campos deben estar alineados de forma que los
que pertenezcan al mismo nivel comiencen en la misma
columna.
6. Los números de nivel de datos se numerarán de 5 en 5 (01,
05, 10, 15,...), realizando un sangrado en cada nivel de 4
columnas a la derecha. Entre el número de nivel y el nombre de
grupo o de variable se dejarán dos espacios de separación, de
forma que aparezcan situados en columnas comunes números de
nivel y nombres de datos.
7. Los registros correspondientes a un mismo fichero se definirán
uno a continuación de otro.
8. Los campos idénticos de diferentes ficheros deberán tener el
mismo nombre, distinguiéndose entre ellos por el prefijo del
fichero al que pertenecen.
9. En caso de que el programa tenga DB2, los cursores

obligatoriamente deben estar declarados en esta sección, nunca
en PROCEDURE o LINKAGE, se recomienda que todas las
declaraciones DB2 estén localizadas juntas y al final de la
WORKING, siempre que no haya tablas de trabajo internas, que
serán las últimas en definirse.
CAMPOS Y ESTRUCTURAS
Los campos se agruparán en bloques en función de su naturaleza
(Contadores, acumuladores, indicadores, índices,
literales, tablas, mensajes de error ,etc.), y deberán comenzar
con unos caracteres específicos que se utilizarán en todas las
variables que pertenezcan a dicho bloque lógico. Los caracteres a
usar serán los siguientes:
Mensajes de Error ME-
Mensajes de Aviso MA-
Registros en FD FD- / RG-
Auxiliares WS-
Indicadores (Switches) SW-
Acumuladores AC-
Contadores CN-
Índices IN-
Constantes CT-
File status FS-
Las líneas de cabecera de los informes se incluirán como COPYS
en los programas, siempre y cuando estas cabeceras sean
estándar.
El nombre de cada campo debe ser siempre significativo, prefijo
excluido. Se deben evitar los nombres poco claros.
En cuanto a las constantes, se deben evitar los nombres
idénticos al valor que contengan, nombrándolos según el
significado de dicho valor. Se definirán tantas constantes como
significados distintos tenga el valor correspondiente.
Se evitarán, por ejemplo:
10 CT-F PIC X VALUE ‘F’.

10 CT-20 PIC 99 VALUE 20.
Y se sustituirán por:
10 CT-FIJO PIC X VALUE ‘F’.
10 CT-FINAL PIC X VALUE ‘F’.
10 CT-MAX-LINEAS PIC 99 VALUE 20.
COPYS
Se usarán obligatoriamente para la descripción de estructuras de
datos, que se usen en más de un programa.
Es necesario que todas las COPYS estén definidas a un nivel
inferior al 01 y que todas empiecen por el mismo nivel, puesto
que hay procesos que concatenan COPYS para una misma
estructura de datos. Se acuerda definir las COPYS con 02 como
primer nivel y el resto como la norma de definición de datos en
WORKING.
Ejemplo:
02 Estructura-copy.
05 Campo1.
05 Campo2.
10 Campo21.......
LITERALES
Está prohibido utilizar literales en la PROCEDURE DIVISION.
Cuando se necesite una constante se define en la WORKING-
STORAGE con su valor, no estando su nombre relacionado con el
valor, sino con el significado de la constante.
Correcto:
05 CT-IVA-APLICABLE PIC S9V99 VALUE +0,15.
05 CT-CONTINUA PIC X VALUE ‘C’.
Incorrecto:

05 CT-0-15 PIC S9V99 VALUE +0,15.
05 CT-C PIC X VALUE ‘C’.
Se deben usar siempre las "constantes figurativas" en lugar de
los literales correspondientes, tanto en VALUE’s como en MOVE’s.
Correcto:
SPACES, ZEROS
Incorrecto:
0, 000, " ".
NIVELES 66
1. La utilización de los niveles 66 en la WORKING-STORAGE
SECTION está prohibido.
NIVELES 77
1. La utilización de los niveles 77 en la WORKING-STORAGE
SECTION está prohibido.
NIVELES 88
1. Se utilizarán siempre "nombres de condición" (nivel 88) para
definir los posibles valores de indicadores, códigos identificativos
o valores de campos que se usen para tomar alguna decisión en
el programa. No utilizar el nivel 01, en comparaciones, implica
un mayor coste de máquina.
01 SW-FIN-CURSOR PIC X VALUE 'N'.
88 FIN-CURSOR VALUE 'S'.
88 NO-FIN-CURSOR VALUE 'N'. '

TABLAS
1. Se utilizarán como norma general subíndices asociados a
TABLA en lugar de números enteros usados como subíndices.
Una opción es utilizar INDEXED BY, pero si no se van a efectuar
búsquedas en la TABLA no es necesario ni recomendable.
2. Se debe definir un nivel por encima del que contiene la
cláusula OCCURS para poder referirse a la TABLA como un todo.
3. Si se define más de una tabla en un programa estas deben ser
independientes, cada una debe tener su nivel 01.
Ejemplo :
01 TABLA-tttt.
05 TB-EL-tttt OCCURS n
INDEXED BY IN-tttt.
DEPENDING ON SIZE
10 TB-tttt-xxxx PIC ...
10 TB-tttt-xxxx PIC ...
....
4. Se recomienda que las cláusulas OCCURS e INDEXED BY estén
situadas en la columna 44 o en 36 de la línea siguiente.
5. En tablas sobre las que se van a efectuar búsquedas, definir
las tablas con DEPENDING ON para que esta se realice sólo sobre
los elementos de la tabla que tengan contenido.
6. Índices para control de bucles: definirlos en binario (COMP)
para evitar conversiones.
7. No sobredimensionar las tablas, ajustar el tamaño.
8. Programar la búsqueda lógica de la tabla de tal manera que se
pare en el último dato de la tabla (fila con contenido lógico) en
lugar de en la última fila definida. Controlar siempre la condición
de salida de fin de tabla rellena (opción AT END).
9. Antes de introducir un elemento nuevo, hay que comprobar
que cabe físicamente en la tabla; en caso contrario, emitir un

mensaje de error.
10. Controlar desbordamiento desde programa.
11. Declarar todas las tablas siempre al final de la WORKING por
posibles desbordamientos.
12. Usar búsquedas dicotómicas si se puede porque son más
eficientes (SEARCH ALL); a partir de 50 ocurrencias
aproximadamente.
13. Cuando la tabla está ordenada utilizar la búsqueda indexada
en lugar de la secuencial. Si no está ordenada meter en los
primeros valores de la tabla los más referenciados.
14. Los datos de la tabla que vayan a ser muy utilizados es
conveniente moverlos a campos de trabajo y referenciarlos
desde allí.
15. Estudiar la conveniencia, dependiendo del tamaño de la tabla
y de la probabilidad, de comprobar antes de realizar la búsqueda
en la tabla, sí nos encontramos en el elemento buscado.
16. No utilizar tablas estáticas dentro de los programas (valores
fijos no cargados desde fuera) cuando exista o pueda existir una
réplica en el exterior. De utilizarlos, asignar los valores más
frecuentes en los primeros elementos de la tabla.
17. Si se van a utilizar tablas WORKING comunes al programa
principal y a rutinas, se recuerda la posibilidad de definirlas como
EXTERNAL.
VALUE
1. Las variables que se inicien sólo una vez durante el programa,
se deben definir en la WORKING-STORAGE SECTION utilizando la
cláusula VALUE, en vez de utilizar sentencias MOVE en la
PROCEDURE DIVISION.
2. La cláusula VALUE se recomienda que comience en la columna
56 o en la 36 de la línea siguiente.
VARIABLES
Es conveniente que todas las variables que se utilicen en
operaciones aritméticas se definan como decimal empaquetado.
Las variables así definidas tendrán un número impar de dígitos.

Para cálculos intensos el formato COMP es el más rápido ya que
almacena los datos en binario.
4. PROCEDURE DIVISION
1. Se codificará un único nombre de párrafo principal desde el
cual se invocarán todos los demás.
2. Se escribirá siempre una instrucción por línea.
3. Prohibido utilizar las sentencias COBOL: INCLUDE y COPY en
la PROCEDURE, a excepción de las COPYS de módulos en los
programas on-line.
4. Cada aplicación tendrá codificados los mensajes funcionales
en una COPY.
5. No se utilizarán literales, para ello se utilizarán campos
declarados en WORKING.
6. Sólo se admite un GOBACK o STOP RUN en el programa.
7. Utilizar la sentencia INITIALIZE al comienzo de esta sección,
para iniciar los campos de trabajo, evitando posibles
cancelaciones por contadores y switches sin valor numérico. En
rutinas debe hacerse siempre.
8. Las llamadas a rutinas se podrán llamar con LINK o CALL. La
documentación disponible sobre las rutinas o módulos deberá
especificar el modo de conectarse con ellas.
9. Las llamadas vía CALL están prohibidas hacerlas de forma
estática, no se admitirá el nombre de la rutina entrecomillado.
10. En los MOVE’s y en los ADD’s consecutivos se codificarán de
forma que la palabra clave TO aparezca en la misma columna en
cada sentencia, aunque no necesariamente en una columna
concreta.
11. Se deben agrupar en bloques aquellas sentencias que están
relacionadas entre sí, y se separan con líneas en blanco de otras
sentencias o bloques de sentencias.
12. Se recomienda diseñar los programas de la manera más
sencilla, para que éstos sean accesibles fácilmente por cualquier

otro programador.
13. Los programas deben estar documentados con comentarios
siempre en Castellano. El nº de líneas de documentación no será
menor al 15 % del total.
14. Hacer todas las validaciones para ver si los datos son válidos
antes de tratarlos.
15. Prohibido utilizar ALTER (va en contra de la estructuración
del programa, propio de la programación invertida).
16. Cuando el proceso lo requiera, en los errores controlados por
programa que impliquen su finalización, prever la necesidad de
usar ROLLBACK.
17. Todos los programas que compilen con código distinto de 00
llevarán documentado el motivo.
18. INDICES:
Los campos con índices que se referencien frecuentemente
deben moverse a un área de trabajo para efectuar cálculos,
devolviendo el resultado al campo original.
Se deben emplear campos del tipo S9(4) COMP-3 como índices
para mejorar el rendimiento de los programas.
19. FICHEROS:
Se utilizará una sola sentencia OPEN de ficheros en el
programa, así como una cláusula de cada tipo INPUT, OUTPUT o
I-O. Los nombres de los ficheros deben situarse en una misma
columna.
Debe preverse que un fichero de entrada pueda estar vacío.
Se utilizará una sola sentencia CLOSE de ficheros en el
programa. Los nombres de los ficheros deben situarse en una
misma columna.
En caso de error controlado por programa es obligatorio cerrar
todos los ficheros que estuvieran abiertos antes de finalizar el
proceso.
Cada operación distinta de entrada/salida de ficheros (READ,
WRITE, REWRITE, DELETE) tendrá una única sentencia en el
programa que constituirá el párrafo (PERFORM) de I/O
correspondiente.
Todos los ficheros de entrada deben leerse desde el área de

entrada a la WORKING-STORAGE SECTION. Esto implica el
empleo de la sentencia READ - INTO.
Utilizar READ con END-READ.
Los ficheros de salida deben grabarse desde el área de salida
de la WORKING-STORAGE SECTION. Esto implica el empleo de la
cláusula WRITE - FROM.
Utilizar SEARCH con END-SEARCH.
Todos los ficheros de salida deben tener la cláusula BLOCK
CONTAINS 0 RECORDS: de ésta forma se traslada la
optimización del bloqueo al JCL, facilitando la posterior
explotación del programa.
Para ficheros con registros de longitud variable especificar
RECORDING MODE IS V.
Se recomienda controlar el acceso a ficheros VSAM mediante
FILE-STATUS.
En el tratamiento de ficheros, usar la técnica de lectura
adelantada: en un procedimiento se abrirá un fichero y se leerá
su primer registro, y en otro, se realizará el tratamiento del
registro para finalizar con la lectura del siguiente, y así
sucesivamente, hasta el final del fichero.
Cuando, por el propio proceso del programa, un listado/fichero
no tenga línea alguna, se editará un mensaje estándar que
recoja el nombre de la aplicación, la fecha de operación y el
nombre del programa junto al mensaje indicativo de que no
existen datos para este listado/fichero. De esta manera, puede
controlarse que el impreso realmente ha sido procesado, no
quedando la duda de si se ha perdido en distribución.
No generar ficheros de salida que sean un JCL, salvo los
programas estándares de la instalación.
Para salidas de programa por error controlado, cerrar los
ficheros y cursores que pudieran estar abiertos, antes de finalizar
el programa.
20. LISTADOS INTERNOS.

En programas que generen listados, se incluirán en los
registros el carácter ASA.
En caso de tener que utilizar las cláusulas AFTER ni BEFORE no
mezclar dichas opciones con las de control de carro 0, 1, +, -, '
'.
En impresión, no escribir líneas en blanco, que requieren una
instrucción MOVE por delante, utilizar en su caso el carácter
ASA.
No es necesario completar las líneas de listado hasta las 132
posiciones con la sentencia FILLER PIC X(??) VALUE SPACES,
puesto que al hacer el WRITE se realiza el rellenado automático
de espacios.
21. PARRAFOS (PERFORMS).
Cada párrafo empezará con una serie de comentarios donde se
definirá el nombre del mismo, y una sucinta descripción de las
funciones que realiza.
Primero se debe codificar el núcleo principal. Al núcleo
principal le seguirán los párrafos de inicio, proceso y fin, y , a
continuación el resto de párrafos desde el nivel más general
hasta el de mayor detalle.
PROCEDURE DIVISION.
PARRAFO-PRINCIPAL.
PERFORM 1000-INICIO
PERFORM 2000-PROCESO
PERFORM 3000-FINAL .
En la línea de párrafo sólo deberá aparecer su nombre.
Todos los párrafos deben tener un nombre descriptivo y un
número secuencial como prefijo. Este número debe estar
ordenado en el programa, es decir, no debe ponerse nunca el

párrafo 2300- antes del 2100-, por ejemplo.
Se utilizará siempre la instrucción
PERFORM nnnn-PARRAFO
Todos las llamadas a párrafos llevarán una línea en blanco por
delante y otra por detrás.
Utilizar el ‘.’ sólo al final del párrafo ya que mejora el
rendimiento de máquina.
Dejar una línea en blanco entre los diferentes párrafos que
componen el programa, para claridad en lectura.
Es aconsejable que ningún párrafo sobrepase las 60 líneas de
código (excepto para sentencias DB2 en las que intervengan
gran número de campos, validaciones de campos...), debiéndose
fraccionar éstos mediante llamadas a otros párrafos.
Evitar existencia de párrafos duplicados.
COLAPSADO DE PÁRRAFOS:
Para la ejecución en un bucle de un párrafo mediante
PERFORM se utilizará la cláusula UNTIL , evitando el uso de la
cláusula N TIMES.
Se evitará en lo posible que un párrafo llame a otro con un
prefijo numérico menor que el suyo. Para ello los párrafos
comunes deben comenzar por un 9. No se tendrá en cuenta este
punto, si se va a producir una acumulación excesiva de párrafos
comunes al final del programa, lo que llevaría a una gran
confusión en el seguimiento del mismo
22. SENTENCIAS CONDICIONALES:
SENTENCIA IF
Utilizar IF con END-IF
Están prohibidos más de tres IF encadenados.
Cuando haya más de tres niveles de anidamiento de IF sobre
la misma variable, se usará la sentencia EVALUATE.
No se debe usar las condiciones IF ALPHABETIC, ya que utiliza
la instrucción de máquina TRT que es muy costosa.
Las sentencias condicionales complicadas deben tratar de

desdoblarse en sentencias simples.
Deben evitarse las condiciones NOT, especialmente si van
combinadas con OR, dado que tienden a complicar la lógica del
programa.
Se procurará no utilizar conjuntamente condiciones AND y OR,
ya que conducen a malentendidos.
Limitar en lo posible el uso de switches
De utilizarlos, se indicarán los posibles valores o rangos a
través de niveles 88.
Deberán usar los valores S y N para SI y NO respectivamente.
Se debe utilizar el nombre de la condición siempre que esté
asociada a un nivel 88 para facilitar la comprensión del
programa.
No utilizar el nivel 01 cuando hay niveles 88 ya que es más
costoso para la máquina.
En las sentencias condicionales conectadas por la cláusula AND
debe revisarse primero la condición más restrictiva, mientras
que, en las sentencias conectadas por la cláusula OR debe
revisarse primero la condición más probable.
Las condiciones aritméticas deben ejecutarse fuera de la
condición de las sentencias condicionales, pues las operaciones
aritméticas dentro de una condición se ejecutan con una
precisión máxima de 6 dígitos.
Se utilizará siempre la cláusula END-IF para marcar el final de
una sentencia IF; de este modo se consigue que el programa
quede perfectamente estructurado y se facilita la comprensión y
el mantenimiento del mismo.
Cuando se utilice un ELSE en una sentencia IF, debe alinearse
en la misma columna del IF. De manera idéntica se considerará
el uso del END-IF.
No se debe usar NEXT SENTENCE, utilizar CONTINUE. Una
sentencia IF que contenga las cláusulas NEXT SENTENCE o ELSE,
puede ser más eficiente si la ordenamos de forma que no se
necesiten.
Por ejemplo :

En lugar de :
Debe poner:
IF A NOT EQUAL B
CONTINUE
ELSE
PERFORM C
END-IF. IF A EQUAL B
PERFORM C
END-IF.
Todas las instrucciones asociadas debido a un IF se
recomienda que comience 4 columnas a la derecha de la cláusula
IF.
Todos los IF anidados se irán sangrando de 4 en 4 columnas.
En el caso de codificar una sentencia CASE (IF-ELSE) se dejará
una línea en blanco antes de la instrucción ELSE. No se pondrá
ninguna instrucción en la misma línea del ELSE.
No se deben utilizar los símbolos de condición, ya que algunos
dispositivos de salida (impresora) no los soportan; utilizar LESS,
GREATER, EQUAL, ..., en lugar de, <, >, =, ....
No es recomendable la utilización de IF anidados cuando las
condiciones se han de verificar sobre distintas variables. En caso
de ser imprescindible la utilización de IF anidados sobre distintas
variables, se deberán utilizar sentencias PERFORM, de forma que
no se utilicen más de 3 niveles de anidamientos en los IF.
SENTENCIA EVALUATE
Utilizar EVALUATE con END-EVALUATE.
Se utilizará siempre que se precise verificar condiciones sobre
la misma variable.
La cláusula WHEN se sangrará 4 posiciones sobre la sentencia
EVALUATE, y las sentencias asociadas a cada WHEN se sangrarán
4 posiciones sobre éste.
Siempre existirá la opción WHEN OTHER.

23. COMPUTE:
En las expresiones aritméticas complejas se debe utilizar la
sentencia COMPUTE, que genera automáticamente todas las
variables intermedias con la longitud apropiada. Se debe evitar
para operaciones simples, en cuyo caso se utilizarán las
expresiones aritméticas apropiadas (Multiply, Divide,...).
Está prohibido multiplicar por 0 y dividir por 1, ya que el
resultado es conocido.
24. ACCEPT/DISPLAY:
Prohibido utilizar UPON CONSOLE.
Prohibido utilizar ACCEPT FROM DATE.
DISPLAY: Debe restringirse a la emisión de mensajes
informativos en caso de incidencia, y a estadísticas de programa
Batch.
ACCEPT: Su uso debe restringirse a recibir datos por SYSIN o
PARM, de forma excepcional.
25. NORMAS PROGRAMACION BATCH:
Cada programa Batch deberá implantar una sola función de
aplicación. Puede descomponerse en los pasos necesarios y usar
las Utilidades requeridas.
Reposicionamiento en programas Batch con DB2. (Ver
estándares SQL).
Para evitar bloqueos y problemas de recuperaciones la
aplicación debe estar preparada para realizar commits cada
cierto número de actualizaciones. Esto deberá estar sincronizado
con el tratamiento de ficheros de entrada y salida.
No usar datos constantes tales como centros, importes ...,
para las excepciones se estudiara la posibilidad de ingresarlas
por SYSIN.
La fecha del día para procesos BATCH se recupera con la

siguiente instrucción cobol, que habrá que ponerse al inicio de la
PROCEDURE
MOVE FUNCTION CURRENT-DATE TO CAMPO-AUXILIAR
donde campo-auxiliar puede ser definido como una PICTURE de
14 caracteres, ya que la recupera como AAAAMMDDHHMMSS.
Los programas no deben exceder de 5000 líneas, incluyendo
las de comentarios y excluyendo las debidas a COPYs. El nº de
líneas de comentarios no debe ser inferior al 15%, siendo este
dato una llamada al sentido común, no incluyendo comentarios
que no sean necesarios o redundantes.
El parámetro de la rutina debe ser inicializado antes de realizar
los MOVE’s a los distintos campos. De esta forma si se modifica
el parámetro de llamada a la rutina se puede definir la
inicialización como valor por defecto y no resulta necesario
modificar el programa y la rutina a la vez.
En los comentarios de programas o en los displays no debe
aparecer la palabra "CALL".
Si se produce un error tras la llamada a una rutina, se
utilizarán los mismos comentarios que se definieron en el
apartado de Documentos vacíos.
Ejemplo :
DISPLAY ‘*** ERROR EN CALL A SYSBLP ***’ Inválido
DISPLAY ‘*** ERROR EN LLAMADA A SYSBLP ***’ Válido
26. LLAMADAS A MODULOS BATCH:
Se trata de módulos a los que se puede llamar tanto desde un
programa BATCH como desde uno CICS, ya que no contienen
sentencias CICS y además no llaman a ningún otro que las
contenga.
En compilación deberán no llevarán precompilación de CICS.
Generan dos cargas, uno para CICS y otro para BATCH.
Se invocarán siempre de forma dinámica vía CALL, estando
contenido el nombre del programa en una variable de WORKING,
con PIC X(8), inicializada en la propia WORKING y con nombre
relacionado con el propio nombre del módulo, a ser posible el

mismo.
Ejemplo:
Si se quiere llamar al módulo de nombre SUBPROG1, la llamada
deberá hacerse de la forma
WORKING-STORAGE SECTION............... ...............
01 CT- SUBPROG1 PIC X(8) VALUE ‘SUBPROG1’. ....... ...............
PROCEDURE DIVISION................ ...............
CALL CT- SUBPROG1 USING.........
27. NORMAS PROGRAMACION CICS:
Las sentencias CICS deben comenzar a partir de la columna
11.
28. LLAMADAS A MODULOS CICS:
Se trata de módulos a los que solo se puede invocar desde
otro programa CICS.
En compilación deberán seleccionarse como CICS, no siendo
relevante el que se definan como programa o modulo, ya que en
ambos casos el procedimiento de compilación es el mismo.
El procedimiento de compilación incluye precompilación de
CICS con lo que ello implica de generación de dos áreas de
LINKAGE, DFHEIBLK y DFHCOMMAREA, que deberán ser tenidas
en cuenta en la llamada realizada vía CALL, como se describe
posteriormente
Se pueden invocar vía CALL o vía LINK como se indica a
continuación
• Llamada vía CALL :
Seguirá el mismo esquema de los módulos BATCH, aunque en la

sentencia de llamada deberá tenerse en cuenta las dos áreas que
introduce la precompilación CICS de un módulo, con lo que el
programa quedaría como sigue:
WORKING-STORAGE SECTION............ ......................
01 CT-SUBPROG1 PIC X(8) VALUE ‘SUBPROG1’.
01 VAR-LLAMADA PIC X VALUE SPACES. ........
PROCEDURE DIVISION. ..........
CALL CT-SUBPROG1 USING DFHEIBLK
VAR-LLAMADA
ARG1
........
• Llamada vía LINK
Deberá utilizarse lo menos posible, no existiendo ninguna
recomendación especial para su codificación.
• Diferencias entre invocación vía CALL y vía EXEC CICS LINK.
Una situación que podría presentarse, a la vista de las
recomendaciones contenidas en el apartado 2, sería el modificar
las llamadas vía LINK por llamadas vía CALL dinámico. En este
caso deberá tenerse en cuenta que:
El comportamiento de un módulo invocado vía CALL varía
ligeramente respecto al invocado vía EXEC CICS LINK, ya que en
el primer caso se inicializan las variables de WORKING solamente
la primera vez que se invoca el módulo a lo largo de la ejecución
del programa, mientras que en el segundo, se inicializan cada
vez. Ello puede conducir a comportamientos inesperados sobre
todo cuando el módulo se invocaba vía EXEC CICS LINK y pasa a
invocarse vía CALL.
Solamente puede pasarse un argumento, equivalente a la
DFHCOMMAREA, el cual sustituiría al VAR-LLAMADA mencionado
en el segundo ejemplo anterior.

Estandar de estructura de un programa cobol

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (10)

Similar a Estandar de estructura de un programa cobol

Similar a Estandar de estructura de un programa cobol (20)

Último

Último (6)

Estandar de estructura de un programa cobol