Foro de Cobol
Registrate en el Foro de Cobol y Aporta tus experiencias y conocimientos sobre este lenguaje de programacion, con tu ayuda el foro crecera y todos nos podremos beneficiar de los conocimientos de los demas.

Gracias por entrar a COBOLEROS.ES
Síguenos en Twitter

Estandar de Estructura de Un Programa Cobol

Ver el tema anterior Ver el tema siguiente Ir abajo

Estandar de Estructura de Un Programa Cobol

Mensaje por 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.
avatar
Coboler@
Admin

Mensajes : 215
Reputación : 19
Fecha de inscripción : 02/02/2011
Edad : 37
Localización : Madrid

Ver perfil de usuario http://www.coboleros.es

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.