manual-cobol

Computación

•

Engenharias

0

Iara Echegaray

1/11/2023

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Computación

8126 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

MANUAL DE SUPERVIVENCIA
Conceptos básicos para mis amigos Coboleros

Software Factory de Cáceres – CENIT
INSA
Rafael Campillo Lorenzo
CÁCERES – Año lectivo 2006 – 2007

"There is no way to happiness. Happiness is the way.
There is no way to peace. Peace is the way.
There is no way to enlightenment. Enlightenment is the way."

...Thich Nhat Hanh-Buddha

Software Factory Rafael Campillo Lorenzo.
Cáceres –

2

ÍNDICE

ÍNDICE DE FIGURAS. ............................................................................................... 4
1. MVS (Multiple Virtual Storage) .............................................................................. 6
2. ISPF (Interactive System Productivity Facility)........................................................ 7
3. CICS. (Customer Information Control System) ....................................................... 8
4. Características de los programas bajo CICS. BATCH vs ON LINE............................ 9
5. La Arquitectura de Desarrollo.............................................................................. 10
6. SQL. DB2. cursores. ........................................................................................... 12
6.1. Cursores....................................................................................................... 13
6.2. Documentación para las pruebas de las tablas DB2 utilizadas ....................... 14
7. PROGRAMAS DE REARRANQUE Y rEPOSICIONAMIENTO. ARQUITECTURA
BATCH. .................................................................................................................. 16
7.1. Funcionamiento del DB2............................................................................... 16
7.2. Rearranque de programas ............................................................................. 16
7.3. Ficheros dinámicos para salida ..................................................................... 16
7.4. Soporte Físico ............................................................................................... 17
7.5. Concatenación de Ficheros............................................................................ 17
7.6. Borrado de Ficheros de COMMIT. .................................................................. 17
7.7. Borrado Ficheros Ultimo Commit. ................................................................. 18
7.8. Ejemplos de JCL's......................................................................................... 18
7.9. Esqueletos .................................................................................................... 18
7.10. Tratamiento a seguir por los programas de aplicación en base a un ejemplo
real. Programa LQBBN01. .................................................................................... 19
8. JCL (JOB CONTROL LANGUAJE) ........................................................................ 44
8.1. Ficheros........................................................................................................ 44
8.2. VTOC. Tabla de contenido del volumen.......................................................... 44
8.3. Ficheros Particionados: PDS.......................................................................... 45
8.4. Formas de localizar un fichero. Catálogos ...................................................... 45
8.5. Lenguaje de Control de Trabajos. Sintaxis. .................................................... 45
8.6. Sentencia JOB .............................................................................................. 45
MSGLEVEL(A,B) ............................................................................................... 45
MSGCLASS ...................................................................................................... 46
CLASS.............................................................................................................. 46
NOTIFY ............................................................................................................ 46
TIME................................................................................................................ 46
TYPRUN ........................................................................................................... 46
RESTART ......................................................................................................... 46

Software Factory Rafael Campillo Lorenzo.
Cáceres –

3

REGION ........................................................................................................... 46
COND O IF/END/ELSE .................................................................................... 46
8.7. Sentencia DD................................................................................................ 46
DSN ................................................................................................................. 47
DISP................................................................................................................. 48
UNIT ................................................................................................................ 49
VOL.................................................................................................................. 49
DCB................................................................................................................. 49
SPACE ............................................................................................................. 49
DIR .................................................................................................................. 49
SYSOUT ........................................................................................................... 49
8.8. Sentencia EXEC............................................................................................ 49
Nombre del programa ....................................................................................... 49
NOMBRE DEL PROCEDIMIENTO...................................................................... 49
Acct.................................................................................................................. 50
Addrspc............................................................................................................ 50
Cond ................................................................................................................ 50
Dprty ............................................................................................................... 50
Dynamnbr........................................................................................................ 50
Parm ................................................................................................................ 50
Perform ............................................................................................................ 50
Rd.................................................................................................................... 50
Region.............................................................................................................. 50
time ................................................................................................................. 50
8.9. Utilidades de JCL.......................................................................................... 50
IEHLIST ........................................................................................................... 51
IEBGENER .......................................................................................................51
IEBCOPY.......................................................................................................... 52
IEBCOMPR....................................................................................................... 52
IEFBR14 .......................................................................................................... 52
DFSORT ........................................................................................................... 52
DFDSS ............................................................................................................. 53
8.10. Sentencias avanzadas JCL. CONCATENACIÓN DE FICHEROS..................... 53
REGLAS DE CONCATENACIÓN ........................................................................ 53
ANEXOS................................................................................................................. 55
ANEXO A: Notas y apuntes sobre COBOL y codificación. ...................................... 55
ANEXO 1: Listado de FILE – STATUS.................................................................... 57
ANEXO 2: Tutorial de los SQLCODES y sus causas .............................................. 62

Software Factory Rafael Campillo Lorenzo.
Cáceres –

4

ANEXO 2.B SQLCODES EN CASTELLANO. ......................................................... 82
ANEXO 3: ABEND CODES bajo TSO / ISPF.......................................................... 88
ANEXO 4: Utilidades y Objetos para el Reposicionamiento Batch. ......................... 92
ANEXO 4.1. DAREPOS..................................................................................... 92
ANEXO 4.2 DAPROCBATCH. ............................................................................ 93
ANEXO 4.3. INCLUDES y COPYS. ..................................................................... 94
URCOPYS......................................................................................................... 94
URMENSA........................................................................................................ 95
URSWITCH....................................................................................................... 95
URSQLCOD...................................................................................................... 96
URWORK.......................................................................................................... 96
URDCLGEN...................................................................................................... 97
URCURSOR...................................................................................................... 97
ANEXO 4.4 Funciones. XX_CANCELACION_PROCESOS_BATCH. ........................ 98
ANEXO 4.5. JCL REPOSICIONAMIENTO ........................................................... 99
ANEXO 5. Enfrentamiento de ficheros. ............................................................... 101
ANEXO-SORT .................................................................................................... 103
Ordenación básica .......................................................................................... 103
Ordenación parcial ......................................................................................... 104
Copia de un fichero......................................................................................... 105
Copia parcial de un fichero ............................................................................. 106
Ordenar y cambiar disposición de campos....................................................... 107
Eliminar repetidos .......................................................................................... 108
Acumular ....................................................................................................... 109
Operadores y tipos de datos ............................................................................ 109
ANEXO 6. just enough ispf................................................................................. 111
ANEXO 7- DESCRIPCION FILE STATUS EN ESPAÑOL........................................ 132
ANEXO 8 -PROGRAMACION UTILIZANDO HOST Y ARQUITECTURA ISBAN........ 135
ÍNDICE DE FIGURAS.

Figura 1 - Subsistemas del OS-390 ........................................................................... 8
Figura 2 - Arquitectura de desarrollo....................................................................... 10
Figura 3 - Herramientas de la arquitectura de desarrollo ......................................... 10
Figura 4 - Herramientas de desarrollo ON-LINE....................................................... 11
Figura 5 - Campos de la tabla DAREPOS................................................................. 92
Figura 6 - Campos de la tabla DAPROCBATCH........................................................ 93
Figura 7 - Parámetros de la función XX_CANCELACION_PROCESOS_BATCH........... 98
Figura 8 - SORT - Ordenacion básica .................................................................... 103
Figura 9 - SORT - Ordenacion parcial.................................................................... 104
Figura 10 - SORT - Copia de un fichero ................................................................. 105
Figura 11 - SORT - Copia parcial de un fichero...................................................... 106

Software Factory Rafael Campillo Lorenzo.
Cáceres –

5

Figura 12 - SORT - Ordena y cambia disposicion de campos.................................. 107
Figura 13 - SORT - Eliminar repetidos................................................................... 108
Figura 14 - SORT - Acumular................................................................................ 109

Software Factory Rafael Campillo Lorenzo.
Cáceres –

6

1. MVS (MULTIPLE VIRTUAL STORAGE)
MVS (Multiple Virtual Storage, Múltiple Almacén Virtual en inglés) fue el sistema
operativo más usado en los modelos de mainframes System/370 y System/390 de
IBM. No tiene ninguna relación con VM/CMS, otro sistema operativo de IBM.

El MVS fue lanzado al mercado por primera vez en 1974, y luego fue renombrado a
MVS/XA (por arquitectura extendida en inglés), más tarde a MVS/ESA (por
arquitectura de sistemas empresariales), luego se renombró como OS/390 cuando se
le añadió al sistema operativo los servicios de UNIX, y finalmente a z/OS cuando los
modelos zSeries fueron introducidos al mercado. Todos ellos, sin embargo, son
fundamentalmente el mismo sistema operativo. De hecho, los programas que hayan
sido diseñados para el sistema MVS pueden correr en z/OS sin modificación alguna.
MVS fue creado basado en SVS (Single Virtual Storage, Único Almacén Virtual), y éste
a su vez fue creado a partir de MVT, una de las variantes del sistema operativo
OS/360.

La variante original del OS/360 era PCP (Programa de Control Primario) no soportaba
la ejecución de tareas múltiples, y MVT (Multitareas con número de Tareas Variables)
era una mejora que era capaz de la ejecución de múltiples tareas. Sobre esta base, el
sistema SVS añadió el “almacén virtual”, mejor conocido como memoria virtual; el
espacio de direccionamiento de esta memoria era compartido por todas las
aplicaciones.

MVS, finalmente, añadió la capacidad de que cada programa tuviera su propio espacio
de direccionamiento de memoria, de allí su nombre.Este sistema se usa típicamente en aplicaciones comerciales y bancarias, y éstas son
normalmente escritas en COBOL. Normalmente estos programas escritos en COBOL
eran usados en sistemas transaccionales como IMS y CICS.

JCL (Job Control Language), la interfaz de proceso Batch.

TSO (Time Sharing Option), la interfaz interactiva de tiempo compartido.

ISPF Es una interfaz que permite al usuario lograr las mismas tareas que TSO pero
de una manera orientada a menús y formularios.

El sistema se usa normalmente en negocios y bancos, y las aplicaciones se suelen
escribir en COBOL. Los programas COBOL fueron tradicionalmente usados con
sistemas de procesamiento de transacciones como IMS YCICS. Para un programa
ejecutándose en CICS, se insertan las sentencias especiales EXEC CICS en el código
fuente COBOL. Un preprocesador replaza dichas sentencias EXEC CICS por el
apropiado código COBOL para llamar a CICS antes de que el programa se compile.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

7

2. ISPF (INTERACTIVE SYSTEM PRODUCTIVITY
FACILITY)
(Interfaz TSO/ISPF)

Es un conjunto herramienta para el sistema operativo IBM z/OS(MVS, OS/390) en los
ordenadores Mainframe.

Incluye un editor de pantalla, el interfaz de usuario fue comercializado a finales de los
años 80, incluyendo SPFPC.

Principalmente provee a la terminal IBM 3270 de un interfaz con menús y diálogos
para ejecutar herramientas de sistema bajo TSO. Frecuentemente es utilizado para
manipular archivos por medio de su PDF (Product Development Facility).
El ISPF es ampliable y muy a menudo es utilizado como interfaz para otros programas
de aplicación. Muchos productos vendidos para el sistema operativo MVS utilizan los
menús de ISPF para acceder a sus herramientas.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

8

3. CICS. (CUSTOMER INFORMATION CONTROL
SYSTEM)

Figura 1 - Subsistemas del OS-390

CICS es un gestor de transacciones. La ejecución de un programa es una transacción,
y cada transacción genera una Tarea. Una Transacción es cada una de las entradas
que se realiza desde el Terminal. Una Tarea es la unidad de trabajo de CPU creada por
una transacción. Cuando se invoca una transacción, un programa determinado se
carga en memoria y se inicia la Tarea. Así aunque varios usuarios invoquen la misma
transacción, cada uno tendrá una tarea distinta.
CICS es multitarea (concurrencia). Además varias tareas diferentes pueden compartir
el mismo programa si este es reentrante (no cambia en ningún momento). CICS
permite compartir la Procedure Division de un programa y sin embargo acceder a
Working Storage Sections diferentes.

El CICS es el monitor de teleproceso. Es un producto que permite el tratamiento de
procesos en tiempo real, una interfase software para soportar nuestros programas de
aplicación en tiempo real entre los programas de aplicación y el sistema operativo. Se
podría pensar que el CICS es un Sistema Operativo dentro de otro Sistema Operativo.
En estos términos, CICS es un SO especializado cuya finalidad es proveer un entorno
para la ejecución de programas de aplicación ON LINE, incluyendo interfases para
ficheros y productos de Bases de Datos. El sistema total es conocido normalmente
como un sistema DB/DC (Data Base/Data Control)

El esquema del proceso en tiempo real puede ser el siguiente: Un operador, desde una
oficina, introduce algún dato por el Terminal; la información viaja por la línea
telefónica hasta el ordenador central; éste procesa la solicitud (por ejemplo una
petición de saldo) y envía la respuesta al Terminal que efectuó la petición. Un Monitor
de Teleproceso (CICS) junto a un adecuado Método de Acceso a Telecomunicaciones
(VTAM), permiten que este trasiego de información se efectúe de forma muy rápida y
eficaz.

En un sistema BATCH los recursos utilizados (principalmente ficheros) sólo están
disponibles cuando el programa ha acabado de usarlos, llegando así a estar accesibles
para cualquier petición.
Hay varios CICS: Para Desarrollo, Explotación, Test, Correo Electrónico.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

9

4. CARACTERÍSTICAS DE LOS PROGRAMAS BAJO CICS.
BATCH VS ON LINE

Desde el punto de vista de la EJECUCIÓN:

• Un programa BATCH se lanza ejecutándose de principio a fin sin que ningún
usuario pueda interferir en el proceso durante la ejecución.

• Un programa ON-LINE permite interacciones con el usuario a través de un
Terminal. Además permite que un mismo programa sea ejecutado
simultáneamente por varios usuarios.

Desde el punto de vista de la utilización de MEMORIA:

• Un programa BATCH mantiene reservado para su uso exclusivo todo el espacio
físico de memoria requerido por el programa durante todo el tiempo de
ejecución.

• Sin embargo en un programa ON-LINE bajo CICS, es éste el que gestiona
dinámicamente la memoria, proporcionando áreas de memoria según las
necesidades del programa que en ese momento se están ejecutando.

Desde el punto de vista de utilización de FICHEROS,

• Un programa BATCH hace un uso exclusivo de la información de los ficheros
que requiere debiendo ser definidos expresamente en el programa

• Mientras que en un programa ON-LINE bajo CICS, se podrá acceder en todo
momento a la información de cualquier fichero que reconozca el CICS sin
requerir una definición expresa en el programa, pudiendo ser esto mismo
realizado por cualquier otro programa que también se esté ejecutando bajo
CICS.

Un programa BATCH envía sus instrucciones de E/S directamente al SO. Los
programas de aplicación del CICS envía tales instrucciones al CICS y éste maneja el
interfase con el Sistema Operativo.
Desarrollo de aplicaciones en HOST.
Teniendo la estación de trabajo conectada al HOST, bajo MVS y desarrollando las
aplicaciones bajo TSO

O bien funcionando de forma autónoma disponiendo de un CICS/OS2.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

10

5. LA ARQUITECTURA DE DESARROLLO

Figura 2 - Arquitectura de desarrollo

Es una estructura que pretende facilitar el desarrollo de aplicaciones que deben
ejecutarse bajo COBOL/II, CICS y DB2.
Se compone de una serie de productos, programas, enganches con otras aplicaciones,
etc...
Esta infraestructura proporciona una rápida puesta en marcha de aplicaciones y
ahorro de tiempo en el mantenimiento.
Se puede ver como un conjunto de herramientas que para su estudio las agruparemos
en herramientas de manejo de datos, para el desarrollo ON-LINE y el desarrollo
BATCH.
Herramientas de Manejo de Datos.

Figura 3 - Herramientas de la arquitectura de desarrollo

Software Factory Rafael Campillo Lorenzo.
Cáceres –

11

Diccionario de Datos: Se definen Entidades de las aplicaciones, así como los Atributos
que las componen, esto es, las tablas DB2 y sus campos. Permite relacionar atributos
de otras entidades y efectuar el mantenimiento de índices y vistas.

QMF: Es un producto mediante el cual se pueden emitir sentencias (en SQL) contra
Bases de Datos DB2 de forma interactiva.

SPUFI: También emite comandos SQL con la salvedadde que el proceso a realizar está
ya escrito en un fichero y permite usar sentencias de definición de datos

PROEDIT: Editor para tablas DB2 que permite procesar tablas DB2 fácil y
rápidamente pues es de apariencia similar al ISPF. Usando esta aplicación se pueden
modificar filas de las tablas sin conocimientos de SQL.

LIBRARIAN: Es un gestor de módulos fuentes, esto es, programas y copies que
mantiene hasta 10 versiones de un programa y 5 de una copy. Las copies del
programa deben ser pasadas a librarian antes que él para que la compilación de
cambio de entorno no falle.
Herramientas de desarrollo ON-LINE

Figura 4 - Herramientas de desarrollo ON-LINE

Software Factory Rafael Campillo Lorenzo.
Cáceres –

12

6. SQL. DB2. CURSORES.
DB2 es el sistema gestor de Bases de Datos de IBM. (Ha de permitir concurrencia,
seguridad (privilegios y prohibiciones) e integridad referencial, (coherencia dentro de la
BD)).

Clave Primaria (PRIMARY KEY): Si una columna está definida como clave primaria,
los datos de esa columna (campo) serán únicos. Es una columna o un conjunto de
columnas que identifican unívocamente a cada fila. Debe ser única, no nula y
obligatoria. Como máximo, podemos definir una clave primaria por tabla.
Esta clave se puede referenciar por una columna o columnas. Cuando se crea una
clave primaria, automáticamente se crea un índice que facilita el acceso a la tabla.

Clave Ajena, Externa (FOREING KEY): Esta formada por una o varias columnas que
están asociadas a una clave primaria de otra o de la misma tabla. Se pueden definir
tantas claves ajenas como se precise, y pueden estar o no en la misma tabla que la
clave primaria. El valor de la columna o columnas que son claves ajenas debe ser:
NULL o igual a un valor de la clave referenciada (regla de integridad referencial).

SQL: es un lenguaje declarativo. En cualquier BD trabajaremos con el lenguaje SQL.

DDL: Data Definition Language: CREATE, DROP, ALTER
DML: Data Manipulation Language: SELECT, INSERT, UPDATE, DELETE.
DCL: Data Control Language: …

CREATE DATABASE NombreDB

DROP DATABASE NombreDB

CREATE TABLE NombreTabla (Nom-campo TipoDato
RestriccionNulidad, Nom-campo2 TipoDato2 RestricciónNulidad
…)

RESTRICCIÓN NULIDAD:
NOT NULL: si a un campo le especificamos NOT NULL, obligamos a que en ese campo
se meta información, no se puede quedar vacío.

NOT NULL WITH DEFAULT: No permite nulos, pero si se deja en blanco rellena. Con
esta opción podríamos dejar campos sin rellenar en la tabla.

NULLABLE: que permite nulos ( en caso de no poner nada cogería esa opción por
defecto

DROP TABLE NombreTabla ( RESTRICT / CASCADE )

SELECT Campo1, ... ,CampoN
INTO :Var1, ... , :VarN
FROM Tabla
WHERE condiciones
GROUP BY Agrupaciones para sacar datos comunes

Software Factory Rafael Campillo Lorenzo.
Cáceres –

13

HAVING Filtro. Establece condiciones pero para grupos
ORDER BY Ordena

INSERT INTO Tabla
(Campo1, Campo2, … , CampoN)
VALUES
(Valor

UPDATE Tabla
SET
Campo1 = valor, … , CampoN = valor
WHERE …

DELETE FROM Tabla
WHERE …

Desde que nos conectamos hasta que ejecutemos ROLLBACK, El rollback recupera la
BD y la deja como estaba. Se usa en caso de error.

EXEC SQL
ROLLBACK
END-EXEC

El commit al contrario que Rollback, hace los cambios permanentes en las tablas.
Para evitar largos bloqueos de las tablas, las aplicaciones deben hacer confirmaciones
de los cambios realizados cada cierto número de registros (COMMIT), lo que liberará
los bloqueos existentes hasta ese momento.
Para ello, durante el proceso se harán confirmaciones periódicas de los datos
modificados (COMMIT), de forma que cuando el proceso falla en su ejecución, el DB2
se encarga de restablecer las tablas a su estado en la última confirmación,
deshaciendo todos los cambios no confirmados (ROLL BACK).

EXEC SQL
COMMIT
END-EXEC
6.1. Cursores
Hasta ahora solo se nos devolvía dentro de cobol una fila. Los cursores nos permitirán
trabajar con consultas de más de una fila. Declaración:

EXEC SQL
DECLARE Nombre-cursor CURSOR FOR
SELECT
WHERE Campo = var
END-EXEC

PROCEDURE DIVISION

Software Factory Rafael Campillo Lorenzo.
Cáceres –

14

MOVE VALOR TO VAR

EXEC SQL EXEC SQL
OPEN Nombre-cursor CLOSE Nombre-cursor
END-EXEC END-EXEC
Lectura:
EXEC SQL
FETCH Nombre-cursor
INTO :VAR
END-EXEC

Cambios dentro de las tablas:

WORKING STORAGE

EXEC SQL
DECLARE Nombre-cursor CURSOR FOR
SELECT …
FOR UPDATE OF Campo / s
END-EXEC

Si se hacen actualizaciones en la tabla, hay que indicárselo al cursor cuando se
declara.

PROCEDURE DIVISION

EXEC SQL
UPDATE Tabla
SET Campo = :valor
WHERE CURRENT OF Nombre-cursor
END-EXEC

Sólo se puede modificar la última lectura, aunque el puntero apunte a la siguiente
El cursor nos devuelve la tabla virtual, y podemos trabajar sobre ella, pero la tratamos
como un fichero secuencial
6.2. Documentación para las pruebas de las tablas DB2 utilizadas
Aparte del documento de ciclos y de los ficheros de E/S, hay que presentar el
contenido de las tablas DB2 con las que hemos probado el programa.
Si nuestro programa hace algún tipo de modificación (insert, update o delete) sobre
estas tablas, tendremos que presentar el contenido de las mismas antes de realizar la
modificación y después de hacerla.
Por cada tabla tendremos que presentar un (dos si sufre modificación) fichero con
formato EXCEL que construimos de la siguiente forma:
Vamos a la ventana de mandatos (MS-DOS)
Exportamos la tabla que queremos presentar. Para ello ejecutamos el siguiente
comando:

DB2 EXPORT TO Destino OF WSF SELECT * FROM xxxx

Software Factory Rafael Campillo Lorenzo.
Cáceres –

15

Donde: xxxx es el nombre de la tabla que queremos exportar. Y Destino es el lugar
donde vamos a dejar el fichero que contiene los datos de la tabla. El nombre que le
vamos a dar tendrá extensión wks.

Nos vamos a Excel y creamos un fichero nuevo. Abrimos desde Excel nuestro fichero
wks y seleccionamos todas las filas y las copiamos al fichero nuevo.

Ahora en ese fichero: FORMATO / COLUMNA / AUTOAJUSTAR SELECCIÓN

Software Factory Rafael Campillo Lorenzo.
Cáceres –

16

7. PROGRAMAS DE REARRANQUE Y
REPOSICIONAMIENTO. ARQUITECTURA BATCH.
Los grandes procesos Batch con gran número de actualizaciones DB2 plantean
problemas ya que mantienen durante largo tiempo bloqueos en las tablas modificadas,
impidiendo la concurrencia de otros procesos batch o del online. Por otra parte su
recuperación en caso de abend o de rearranque de todo el sistema es muy costosa ya
que el DB2 debe restaurar sus tablas a la situación inicial, bloqueando todas las
páginas que se hubieran utilizado.
Para evitar ambos problemas la aplicación debe estar preparada para efectuar
confirmaciones de los cambios (inserciones, borrado, modificaciones) cada cierto
número de actualizaciones (COMMIT).
De esta manera se liberaran los bloqueos adquiridoshasta ese momento y se
suavizará la recuperación del proceso.
Pero surge el problema del tratamiento de los objetos no DB2, tales como ficheros, ya
que el sistema no contempla de manera estándar su tratamiento.
Para esto se ha desarrollado una serie de utilidades que mediante la alocación
dinámica de ficheros sincroniza la actualización de ficheros secuenciales de salida con
la de objetos DB2.
7.1. Funcionamiento del DB2
El DB2 en caso de tener que hacer recuperación después de un error en ejecución de
programa, debe buscar en el Log propio del subsistema que contiene los datos de
cambios en Base de Datos y Puntos de Control del Sistema.
Para eliminar el problema de bloqueo, DB2 utiliza la sentencia COMMIT que libera
todos los recursos DB2 que el proceso estuviera utilizando (páginas, tablespaces,
índices, etc.). Por defecto cierra todos aquellos cursores que estuviesen abiertos y
considera definitivos todos los cambios realizados sobre las tablas.
Se llama unidad de recuperación (UR) a la secuencia de operaciones realizadas entre
dos puntos de COMMIT y hay que tener en cuenta que en caso de un ABEND el DB2
desharía todos los cambios realizados en la última UR, es decir, hasta el último
COMMIT.

El DB2 deshace los cambios no confirmados en caso de error (ROLL BACK), por ello,
para reposicionar los procesos que sólo actualizan datos en DB2, bastará con guardar
la última clave tratada y confirmada en los ficheros de entrada, para continuar desde
ella al rearrancar. Dicha clave se alamcena en una tabla de la arquitectura y se
recuperararía en un relanzamiento del programa para releer los ficheros de entrada o
las tablas hasta el último COMMIT realizado antes de que se interrumpiera la
ejecución.

Uno de los problemas es que no se contempla el reposicionamiento de objetos no DB2
tales como ficheros de salida; para ello la arquitectura ha generado herramientas para
su tratamiento.
7.2. Rearranque de programas
Se realizará rearranque cuando la ejecución se interrumpa de alguna manera (caída
de línea, de DB2, ABEND, etc.). Entonces el DB2 hará ROLLBACK (vuelta atrás
automática de los cambios realizados en las tablas en la última unidad de
recuperación, desde el último COMMIT).
7.3. Ficheros dinámicos para salida
Como se ha apuntado el DB2, automáticamente vuelve a la situación que existía en el
último punto de COMMIT, pero los objetos no DB2 no.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

17

Los ficheros de salida se han seguido generando y no podemos conocer cuales eran
sus datos antes. Por ello la arquitectura ha creado una serie de utilidades que
mediante la alocación dinámica de ficheros sincroniza la actualización de ficheros
secuenciales de salida con la de los objetos DB2.
El sistema, por cada uno de los ficheros de salida, que se han definido en una de las
tablas de trabajo, genera tantos ficheros dinámicos como procesos de COMMIT se
hayan realizado y posteriormente realizará una unión de todos ellos.
7.4. Soporte Físico
Como soporte a éste tratamiento y para hacerlo posible se utilizan dos tablas DB2,
varias rutinas para la alocación dinámica, diversos parámetros en el JCL de ejecución
de cada proceso y varios JCL's que enmarcan la ejecución de nuestros programas
batch.

En la arquitectura HOST de ISBAN Las aplicaciones guardarán toda la información
necesaria para reposicionar sus procesos Batch en caso de rearranque, en las tablas
DAREPOS y DAPROCBATCH pertenecientes a la arquitectura. (ver ANEXO3)

También se facilitan una serie de esqueletos de programas, así como copys con
campos estándar para la codificación de los mismos. (ver COPYS)
DCLGEN de las Tablas DB2.

D0204200 Dclgen de la tabla DAREPOS generada por Arquitectura.
D0204100 Dclgen de la tabla DAPROCBATCH generada por Arquitectura.
URDCLGEN Dclgen de la tabla DAREPOS que se usará en los programas.

INCLUDES a Utilizar en los Programas con Reposicionamiento.

URCOPYS Definición de las variables RURCOMM y RUROPER de comunicación
con la rutina UR0000.
URWORK Definición de las variables de trabajo para reposicionamiento.
URCURSOR Definición del cursor a utilizar en el programa con
reposicionamiento.

COPYS a Utilizar en los Programas con Reposicionamiento.

URSQLCOD Definición de la variable para controlar el SQLCODE de los
cursores de reposicionamiento.
MURSWITCH Definición de los SWITCHES utilizados por el programa con
Reposicionamiento.
URMENSA Definición de las variables de trabajo a utilizar para la cancelación.
7.5. Concatenación de Ficheros.

Se efectúa mediante el procedimiento URSORTX. Debe haber tantos JCL's de
concatenación como distintos ficheros de salida trate el proceso.

7.6. Borrado de Ficheros de COMMIT.

Una vez concatenados los ficheros y antes de volver a pasar el proceso se deben
borrar. Para ello existe un JCL que ejecuta una CLIST llamada URCLEAR, pasándole
como en el caso anterior, el nombre del plan, numero de registros por COMMIT,
proceso y prefijo de los ficheros.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

18

Esta CLIST ejecuta un plan que borra todos los ficheros y restaura el estado del
proceso a P sobre la tabla DAREPOS, estado que deja preparado el proceso para
ejecutarse.
Como en el caso anterior se crea y copia un fichero de PROFILE a fin de evitar
contenciones entre varios JCLs de éste tipo.

7.7. Borrado Ficheros Ultimo Commit.

En caso de tener que relanzar el proceso es necesario borrar los ficheros del COMMIT
que no llegó a efectuar. Para ello se ejecuta una CLIST llamada URCLEARU a la que
se le pasa como parámetros el nombre del plan, numero de registros del COMMIT,
proceso, prefijo de los ficheros y el subsistema DB2. Si no se ha alocado ningún
fichero la CLIST no hace nada, razón por la que se debe ejecutar siempre antes del
programa de reposicionamiento.
Si no se realiza éste paso la aplicación intentará alocar el fichero que ya existe, dando
un error
de catalogación NOT CATLG 2 y por consiguiente un ABEND del proceso.
Por otra parte si se varia alguna característica del fichero (como el tanto por ciento de
registros por COMMIT) al reutilizar el mismo fichero no se recogerá el cambio
efectuado con lo cual se repetirá el error anterior.

7.8. Ejemplos de JCL's.
Pueden consultarse en la libreria SIS.GRUR.REPOS. Hay distintos tipos según el
entorno de ejecución, ya que las CLIST y las librerías cambian.
En estos ejemplos aparecen con raya continua todas las variables que son propias del
proceso o del usuario que lo ejecuta. Muchos de estos parámetros están
interrelacionados.
Todos los JCL's deberán seguir las normas generales de la instalación, cómo por
ejemplo los nombres de los ficheros o los pasos a ejecutar.
(ver #JCLREPOS)
7.9. Esqueletos
Para facilitar la codificación de los programas se disponen de unos esqueletos en 5
modalidades distintas según utilicen ficheros secuenciales o tablas DB2, de entrada o
salida.
Dichos esqueletos son unas plantillas sobre las que se insertará la lógica de nuestro
programa. En ellos se controla todo el proceso de reposicionamiento y relanzamiento.

Se encuentran en la librería: SIS.GRUR.EJEMPLOS.

REPOSPS: Esqueleto de programa que efectúa reposicionamiento utilizando un fichero
secuencial de entrada y uno de salida. El plan debe llevar asociado la rutina
'UR0000'. REPOSPS.
En el programa no aparecerá la llamada a dicha rutina explícitamente ya que se
utilizará la variable RUR-CALL de la copy RUROPER para hacer llamadas dinámicas a
rutinas.

Entrada: Fichero secuencial.
Salida: Fichero secuencial.

Se emiten COMMIT's cada 10.000 registros tratados. Por cada COMMITse cierra el
fichero de salida actual y se abre otro nuevo. Si se produce el ABEND, el fichero de
salida queda incompleto y con un contenido impredecible. Antes de rearrancar el

Software Factory Rafael Campillo Lorenzo.
Cáceres –

19

proceso debe borrase el último fichero utilizado porque se intentará crear de nuevo,
obteniendo un error de catálogo puesto que ya existe.
Al rearrancar, se relee el fichero de entrada a partir de los apuntadores guardados en
DAREPOS al hacer el último COMMIT, y se continúa grabando en el fichero de salida
correspondiente.

@-------¬
| START |
$-------%
10k 20k 30k 40k 50k 60k
FIC [ - - - -_- - - - -_- - - - -_- - - - -_- - - - -_- - - - -_- - -
. . . .
. . . .
. . . .
. . . .
C C C A
S [--------_---------_---------_-----_
X1 Z1 Z2 Z3
X2 X3 X4----]

C = Punto de COMMIT
A = Punto de ABEND
X = Abre fichero de salida
Z = Cierra fichero de salida

@-------¬
|RESTART| Previo borrado del último fichero de COMMIT (4)
$-------%

10k 20k 30k 40k 50k 60k
FIC [ - - - - - - - - - - - - - ->- - - - -_- - - - -_- - - - -_- - -
. 10k 20k . 30k
. . . .
. . . .
. . . .
R C C F
S _---------_---------_----_
X4 Z4 Z5 Z6
X5 X6

R = Punto de RESTART
C = Punto de COMMIT
F = Punto de FINAL
X = Abre fichero de salida
Z = Cierra fichero de salida

7.10. Tratamiento a seguir por los programas de aplicación en base a
un ejemplo real. Programa LQBBN01.
Lo primero que se ha de hacer siempre que nos enfrentemos a la resolución de
programas de este tipo es identificar del tipo de programa: Se debe buscar el esqueleto
que más se ajuste al programa que se va a ejecutar.

A continuación se obtiene una copia del esqueleto pasando el esqueleto a nuestras
librerías, sin modificar lo directamente pues más adelante serán utilizados por otros
usuarios.

Durante la codificación hay que tener en cuenta que cada vez que se realiza un
COMMIT todos los cursores se cierran (aunque no se haya realizado CLOSE); por eso
si se ha abierto alguno que no pertenezca al reposicionamiento, hemos de recordar
abrirlo de nuevo.
Todos los switch que controlen el proceso deben guardarse (en la tabla DAREPOS)
porque si hay relanzamiento se debe saber qué parte del programa se debe ejecutar.
Si se utilizan tablas internas para validaciones, el primer paso al rearrancar, debe ser
cargarlas de nuevo. Se trata de reconstruir la situación al punto donde se quedó.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

20

Debe tenerse en cuenta que si se utilizan en el programa tablas internas en las que se
guarden acumuladores o datos intermedios, no se dispondrá de ellos en el momento
del relanzamiento. Entonces será necesario utilizar una tabla DB2 y trabajar con ella
de la misma forma que con los cursores de reposicionamiento. Podría ser utilizada la
tabla DAREPOS si el volumen de los datos lo permite.

¡¡Es importante decidir el criterio lógico de COMMIT, es decir, cada cuánto
tiempo se realiza un commit. Se puede establecer según el número de registros
leídos del fichero maestro, tratados o grabados en el fichero de salida, o según
el número de acceso a una tabla DB2, pero se ha de tener clara la lógica para
realizar el incremento del contador que nos dirá cuando efectuamos un
COMMIT..!! En el programa LQBBN01 se enfrentan dos ficheros de entrada, y
como lógica se ha decidido ir incrementando el contador en base alas lecturas
del fichero maestro.

Los programas Batch con reposicionamiento reciben como entrada los parámetros
necesarios para su control. No son parámetros de aplicación, si necesitase otros
parámetros para su proceso estos deberán pasarse al programa mediante ficheros de
entrada. Los parámetros para el control del reposicionamiento son:

PLAN Nombre del plan a ejecutar con reposicionamiento. Debería corresponder con el
propio.

NUMREG Número de registros que se van a procesar antes de cada confirmación.
Realmente no tiene porque indicar el número de registros de entrada: sólo es el tope
del contador del bucle de proceso de registros.

NUMPROC Número del proceso asociado a ese Job. Normalmente siempre es '1' salvo
el caso de programas que bifurcan y tratan tablas distintas según alguna entrada que
lean. En este caso se pueden lanzar dos o más Jobs en paralelo con el mismo
programa/plan pero distinto Número de Proceso para poder reposicionarse cada cual
correctamente e independientemente del otro Job.

PREFIX Prefijo de los ficheros de salida generados.

POOL Pool de discos. Este parámetro es opcional, si no se pone toma por defecto
SYSDA.

Ahora se han de preparar las tablas para la ejecución. Para ello se han de obtener y
modificar los JCL's correspondientes.

No debemos olvidar probar el proceso de relanzamiento una ver construído el
programa. Se deb cancelar una vez que se está ejecutando y volverlo a submitir.
(EJECUTAR).

****************************************************************************************
***
****************************************************************************************
***
* PROGRAMA: LQBBN01
*
* FECHA CREACION: 07-11-2006
*
* AUTOR: INSA
*
* INSTALACION: CLIENTE.ISBAN.
*
* DESCRIPCION: EL PROCESO DARÁ NUEVAS ALTAS EN LA TABLA DE SALDOS
* VALOR PARA LIQUIDACIÓN DE CONTRADOS DE PR�STAMOS.(SALDO_VALOR_

Software Factory Rafael Campillo Lorenzo.
Cáceres –

21

* _PTM).
* A PARTIR DEL FICHERO DE ALTAS DEL DÍA(ALTAS1),ORDENADO POR
* CONTRATO, Y DEL FICHERO DE CONTRATOS QUE LIQUIDAN POR EL NUEVO
* SISTEMA(CONTBA3) ORDENADO POR CONTRATO, SELECCIONAMOS LAS ALTAS
* ENFRENTANDO AMBOS FICHEROS. CON CADA ALTA VÁLIDA(ENCONTRADA EN
* EL FICHERO DE CONTRATOS) GENERAMOS UN REGISTRO EN LA TABLA
* SALDO_VALOR_PTM CON EL SALDO A 0 POR CADA POSICIÓN LEÍDA EN EL
* FICHERO CONTBA3. LA PREESISTENCIA DEL REGISTRO QUE SE VA A DAR
* DE ALTA EN SALDO_VALOR_PTM IMPLICA UN ERROR, POR LO QUE SE
* GRABA EN EL FICHERO DE SALIDA DE ERRORES (ERRALTA)
*
****************************************************************************************
***
*
* RUTINAS:
* RUTINA1: XX_CANCELACION_PROCESOS_BATCH:*
* CANCELAR LA EJECUCION DE UN PROGRAMA POR
* CUALQUIER TIPO DE ERROR
*
* RUTINA2: UR0000:
*
* MUEVE LOS PARÁMETROS JCL A LA RURCOMM, Y
* ACCEDE AL DB2
*
****************************************************************************************
**
*
* TABLAS:
* TABLA1: SALDO_VALOR_PTM
*
* SALDOS VALOR PARA LIQUIDACIÓN DE CONTRATOS
* DE PR�STAMOS
*
****************************************************************************************
***
****************************************************************************************
***
*
* MODIFICACIONES
* ----------------
*
* USUARIO FECHA DESCRIPCION
* ------- ----- -----------------------
* XXXXXXX DD-MM-AA XXXXXXXXXXXXXXXXXXXXXXX
*----------------------------------------------------------------
****************************************************************************************
***
****************************************************************************************
***

**************************
IDENTIFICATION DIVISION.
**************************
PROGRAM-ID. LQBBN01.
AUTHOR. RAFITASUPERSTAR.
DATE-WRITTEN. 10/11/2006.
DATE-COMPILED. 13/11/2006.

*################################################################*
*#
#*
*# ENVIRONMENT DIVISION
*#
#*
*################################################################*
**************************
ENVIRONMENT DIVISION.
**************************
CONFIGURATION SECTION.
SPECIAL-NAMES.
DECIMAL-POINT IS COMMA.
INPUT-OUTPUT SECTION.
FILE-CONTROL.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

22

* FICHERO DE CONTRATOS DE PRESTAMOS QUE LIQUIDAN POR EL NUEVO
* SISTEMA. FICHERO SECUENCIAL DE ENTRADA1
SELECT CONTBA3 ASSIGN TO CONTBA3
FILE STATUS IS FS-CONTBA3.

* FICHERO CON LAS ALTAS DEL DÍA.FICHERO SECUENCIAL DE ENTRADA2
SELECT ALTAS1 ASSIGN TO ALTAS1
FILE STATUS IS FS-ALTAS1.

* FICHERO DONDE SE GRABAN LAS ALTAS NO PRODUCIDAS POR CLAVE
* DUPLICADA.FICHERO SECUENCIAL DE SALIDA.
SELECT ERRALTA ASSIGN TO ERRALTA
FILE STATUS IS FS-ERRALTA.

*################################################################*
*#
#*
*# DATA DIVISION
#*
*#
#*
*################################################################*
***************************************************
DATA DIVISION.
***************************************************
FILE SECTION.

FD CONTBA3
LABEL RECORD ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORDING MODE IS F.
01 REGCONTBA3 PIC X(280).

FD ALTAS1
LABEL RECORD ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORDING MODE IS F.
01 REGALTAS1 PIC X(140).

FD ERRALTA
LABEL RECORD ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORDING MODE IS F.
01 REGERRALTA PIC X(147).

***************************************************
WORKING-STORAGE SECTION.
***************************************************

****************************************************************************************
**
*** COPY DE MENSAJES DE ERROR PARA PROGRAMAS BATCH QUE
*** USEN " REPOSICIONAMIENTO "
****************************************************************************************
**

COPY URMENSA.

****************************************************************************************
***
*** COPY QUE CONTIENE LOS " SWITCHES " UTILIZADOS
*** POR PROGRAMAS BATCH QUE UTILIZAN REPOSICIONAMIENTO.
****************************************************************************************
***COPY URSWITCH.

****************************************************************************************
***
*** COPY QUE CONTIENE LOS CAMPOS DE TRABAJO UTILIZADOS
*** EN PROGRAMAS BATCH QUE UTILIZAN REPOSICIONAMIENTO.
****************************************************************************************
***

Software Factory Rafael Campillo Lorenzo.
Cáceres –

23

EXEC SQL INCLUDE URWORK END-EXEC.

****************************************************************************************
***
*** CLAVES DE RELANZAMIENTO Y DE REPOSICIÓN PARA EL
*** FICHERO CONTBA3 Y ALTAS1

En caso de que un programa vea cancelada su ejecución y tengamos que relanzarlo, tenemos
que releer el fichero maestro hasta el punto guardado tras el último COMMIT efectuado antes de
su caída. La cave guardada en ese último COMMIT será CLAVE-ALTAS1, que es la clave de
reposicionamiento, y la clave temporal que ser irá comparando con ésta en la relectura del
maestro, será UR-CLAVE-RELANZAMIENTO.

01 UR-CLAVE-RELANZAMIENTO.
10 IDEMPR-RELANZAMIENTO PIC X(4).
10 IDCENT-RELANZAMIENTO PIC X(4).
10 IDPROD-RELANZAMIENTO PIC X(3).
10 IDCONTR-RELANZAMIENTO PIC X(7).

* LA CLAVE DE REPOSICIONAMIENTO ES LA DEL FICHERO MAESTRO ALTAS1

01 CLAVE-ALTAS1.
10 IDEMPR-ALTAS1 PIC X(4).
10 IDCENT-ALTAS1 PIC X(4).
10 IDPROD-ALTAS1 PIC X(3).
10 IDCONTR-ALTAS1 PIC X(7).

01 CLAVE-CONTBA3.
10 IDEMPR-CONTBA3 PIC X(4).
10 IDCENT-CONTBA3 PIC X(4).
10 IDPROD-CONTBA3 PIC X(3).
10 IDCONTR-CONTBA3 PIC X(7).

****************************************************************************************
***
*--- ESTRUCTURA DE LQCBN02-TAB-SALDOS-VALOR:

01 TAB-SALDOS-VALOR-TRA.
02 REG-SALDOS-VALOR-TRA OCCURS 2.
05 ELE-SALDOS-VALOR-TRA OCCURS 600.
10 FEC-VALOR-TRA PIC S9(8) COMP-3.
10 DIAS-AVX-TRA PIC S9(8) COMP-3.
10 DIAS-AVB-TRA PIC S9(3) COMP-3.
10 SALDO-VALOR-TRA PIC S9(13)V9(2) COMP-3.

****************************************************************************************
***
*** INTRODUCIR AQUI LA COPY QUE CONTIENE LOS CAMPOS
*** DE LOS FICHEROS DE ENTRADA Y SALIDA
****************************************************************************************
***

* COPY DEL FICHERO DE ENTRADA CONTBA3 DE CONTRATOS DE PRESTAMOS
COPY LQYCONTL.

* COPY DEL FICHERO ALTAS1 CON LAS ALTAS DEL DÍA
COPY BNYDE008.

* COPY DEL FICHERO ERRALTA
COPY JWYARC01.

Añadir en el programa las COPYS e INCLUDES necesarias para el reposicionamiento.

****************************************************************************************
***
*** INCLUDES DE LA COPY PARA DB2
****************************************************************************************
***

EXEC SQL INCLUDE SQLCA END-EXEC.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

24

****************************************************************************************
***
*** INCLUDE DE LAS COPYS PARA REPOSICIONAMIENTO
*** " RURCOMM " Y " RUROPER "
****************************************************************************************
***
*
EXEC SQL INCLUDE URCOPYS END-EXEC.

****************************************************************************************
***
*** INCLUDE DE LA COPY DE LA DCLGEN DE " DAREPOS ".
*** (TABLA UTILIZADA PARA EL REPOSICIONAMIENTO EN BATCH)
****************************************************************************************
***
*
EXEC SQL INCLUDE URDCLGEN END-EXEC.

****************************************************************************************
***
*** COPY QUE INCLUYE EL CURSOR FOR UPDATE DE DAREPOS.
*** TABLA UTILIZADA PARA EL REPOSICIONAMIENTO EN BATCH.
****************************************************************************************
***
*
EXEC SQL INCLUDE URCURSOR END-EXEC.

*------------------------------------------------------------
* TABLA DE ACTUALIZACIÓN SALDO_VALOR_PTM
*------------------------------------------------------------
EXEC SQL
INCLUDE D3445800
END-EXEC.

*------------------------------------------------------------
* SWITCHES
*------------------------------------------------------------
01 SW-SWITCHES.
05 SW-FIN-ALTAS1 PIC 9(1).
88 SW-SI-FIN-ALTAS1 VALUE 1.
88 SW-NO-FIN-ALTAS1 VALUE 0.

05 SW-FIN-CONTBA3 PIC 9(1).
88 SW-SI-FIN-CONTBA3 VALUE 1.88 SW-NO-FIN-CONTBA3 VALUE 0.

* PARA LOS CONTROLES DE DB2

05 SW-DB2-RETURN-CODE PIC S9(04)
COMP VALUE ZEROES.
88 DB2-OK VALUE 0.
88 DB2-CLV-NOT-FOUND VALUE +100.
88 DB2-CLV-DUPLI-INSERT VALUE -803.
88 DB2-CLV-DUPLI-SELECT VALUE -811.
88 DB2-RECURSO-NO-DISPONIBLE VALUE -911.
88 DB2-TABLA-BLOQUEADA VALUE -904.
05 SW-LEER-ALTAS1 PIC 9(1).
88 SW-SI-LEE-ALTAS1 VALUE 1.
88 SW-NO-LEE-ALTAS1 VALUE 0.
*----------------------------------------------------------------*
* CONSTANTES *
*----------------------------------------------------------------*
01 CT-CONSTANTES.
05 CA-LQBBN01 PIC X(7) VALUE 'LQBBN01'.
05 CA-PARRAFO-INICIO PIC X(14) VALUE 'PARRAFO-INI
- 'CIO'.
05 CA-PROGRAMA-LQBBN01 PIC X(30) VALUE ' PROGRAMA
- ' LQBBN01'.
05 CA-ASTERISCO PIC X(42) VALUE '***********
- '******************************'.
05 CA-RESPONSABLE PIC X(26) VALUE 'DESAROLLO-L
- 'IQUIDACIONES'.
05 CA-ALTAS1 PIC X(6) VALUE 'ALTAS1'.
05 CA-CONTBA3 PIC X(7) VALUE 'CONTBA3'.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

25

05 CA-ERRALTA PIC X(7) VALUE 'ERRALTA'.
05 CA-ERROR-APERTURA PIC X(26) VALUE 'ERROR AL AB
- 'RIR EL FICHERO'.
05 CA-ERROR-INSERT PIC X(26) VALUE 'ERROR AL HA
- 'CER EL INSERT'.
05 CA-ERROR-LECTURA PIC X(26) VALUE 'ERROR AL LE
- 'ER EL FICHERO'.
05 CA-ESCRIBIR-SALDO-PTM PIC X(28) VALUE 'ESCRIBIR SA
- 'LDO-VALOR-PTM'.
05 CA-SALDO-VALOR-PTM PIC X(21) VALUE 'SALDO-VALOR
- '-PTM'.
05 CA-LEER-ALTAS1 PIC X(21) VALUE 'LEER FICHER
- 'O ALTAS1'.
05 CA-LEER-CONTBA3 PIC X(22) VALUE 'LEER FICHER
- 'O CONTBA3'.
05 CN-CERO PIC 9(1) VALUE 0.
05 CN-UNO PIC 9(1) VALUE 1.
05 CN-OCHO PIC 9(1) VALUE 8.
05 CN-DIECISIETE PIC 9(2) VALUE 17.
05 CN-DIECIOCHO PIC 9(2) VALUE 18.
05 CN-OCHENTA PIC 9(2) VALUE 80.
05 CA-TIPO-ERROR-F PIC X(1) VALUE 'F'.
05 CA-ESTADO-C PIC X(1) VALUE 'I'.
05 CA-ESTADO-I PIC X(1) VALUE 'P'.
05 CA-ESTADO-P PIC X(1) VALUE 'C'.
05 CA-ESTADO-F PIC X(1) VALUE 'F'.
05 CA-TIPO-ERROR-D PIC X(1) VALUE 'D'.
05 CA-COD-RETORNO PIC X(4) VALUE '3333'.
05 CA-FICH-OK PIC X(2) VALUE '00'.
05 CA-FIN-FICH PIC X(2) VALUE '10'.
05 CA-CODERROA PIC X(4) VALUE 'GL01'.
05 CA-CODCESTX PIC X(3) VALUE 'PTM'.
05 CA-AORIGEN PIC X(3) VALUE 'CSV'.
*------------------------------------------------------------
* CAMPOS PARA LA FUNCIÓN DE ERRORES
*------------------------------------------------------------
01 WK-CANCELA.
05 WK-TIPO-ERROR PIC X(001).
05 WK-COD-RETORNO PIC X(004).
05 WK-DESCRIPCION PIC X(080).
05 WK-RESPONSABLE PIC X(030).
05 WK-PROGRAMA PIC X(008) VALUE 'LQBBN01'.
05 WK-PARRAFO PIC X(030).
05 WK-ERROR-DB2.
10 WK-SQLCA PIC X(148).
10 WK-TABLA-DB2 PIC X(015).
10 WK-DATOS-ACCESO PIC X(104).
05 WK-ERROR-RUTINA.
10 WK-RUTINA PIC X(008).
10 WK-PARAMETROS PIC X(114).
05 WK-ERROR-TABLA-MEMORIA.
10 WK-TABLA-MEM PIC X(030).
10 WK-INDICE PIC X(006).
10 WK-DATOS-TABMEM PIC X(086).
05 WK-ERROR-FICHERO.
10 WK-DDNAME PIC X(008).
10 WK-FILE-STATUS PIC X(002).
10 WK-DATOS-REGISTRO PIC X(112).
05 WK-EXISTENCIA-CONTRATO.
10 FILLER PIC X(57) VALUE 'YA EXISTE
- 'CONTRATO EN SALDO_VALOR_PTM PARA POSI
- 'CIÓN = '.
10 WK-TIPMVTO PIC X(3) VALUE SPACES.
05 WK-LECTURAS-CONTBA3.
10 FILLER PIC X(42) VALUE 'REGISTROS
- 'LEÍDOS EN EL FICHERO CONTBA3: '.
10 WK-CONT-CONTBA3 PIC 9(9) VALUE ZEROS.
05 WK-LECTURAS-ALTAS1.
10 FILLER PIC X(42) VALUE 'REGISTROS
- 'LEÍDOS EN EL FICHERO ALTAS1: '.
10 WK-CONT-ALTAS1 PIC 9(9) VALUE ZEROS.
05 WK-ESCRITURAS-ERRALTA.
10 FILLER PIC X(46) VALUE 'REGISTROS
- 'ESCRITOS EN EL FICHERO ERRALTA: '.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

26

10 WK-CONT-ERRALTA PIC 9(9) VALUE ZEROS.
05 WK-ESCRITURAS-SALDO-VALOR-PTM.
10 FILLER PIC X(57) VALUE 'REGISTROS
- 'ESCRITOS EN LA TABLA SALDO_VALOR_PTM'
.
10 WK-CONT-SALDO-VALOR-PTM PIC 9(9) VALUE ZEROS.
* PARÁMETROS PARA EL RESTO DE INCIDENCIAS SIN CATALOGAR(TIPO Q)
05 WK-ERROR-OTROS.
10 WK-RESTO-DATOS PIC X(122).
01 IND-I PIC 9(1).01 FECAPER-NUM PIC X(8).
01 FECAPER-COMP3 REDEFINES FECAPER-NUM.
05 FECAPER-FECHA PIC 9(8).

*------------------------------------------------------------
* DEFINICIÓN DE LOS CAMPOS DE LOS FICHEROS
*------------------------------------------------------------
01 CONT-CONTBA3 PIC 9(9) VALUE ZEROS.
01 CONT-ALTAS1 PIC 9(9) VALUE ZEROS.
01 CONT-SALDO-VALOR-PTM PIC 9(9) VALUE ZEROS.
01 CONT-ERRALTA PIC 9(9) VALUE ZEROS.

*--- FILE STATUS
01 FS-CONTBA3 PIC X(2) VALUE '00'.
01 FS-ALTAS1 PIC X(2) VALUE '00'.
01 FS-ERRALTA PIC X(2) VALUE '00'.

*------------------------------------------------------------
* TABLAS INTERNAS
*------------------------------------------------------------
01 W-POSICION-ALTA PIC X(03).
01 W-POSICIONES.
05 W-POSICION OCCURS 8 PIC X(03).

******************
LINKAGE SECTION.
******************
En esta variable de linkage se recibirán los datos pasados en PARÁMETROS en el JCL
a través de la copy RURCOMM.

01 PARMLIST.
05 PARM-LNG PIC XX.
05 PARAMETRO PIC X(200).

************************************
PROCEDURE DIVISION USING PARMLIST.
************************************
********************************************
* RUTINA-PRINCIPAL.
********************************************
Algo que llamará la atención pero que no ha de asustarnos es el hecho de que se usen
dos inicios y dos finales en la rutina principal del programa. Esto tiene su sentido
porque utilizamos un inicio y un final del esqueleto que en el que se controlan temas
relacionados con el reposicionamiento. Esto no implica que la lógica de nuestro
programa encaje exactamente con A100-INICIO-PROGRAMA, A400-PROCESO-
PROGRAMA Y S900-FIN, ya que iremos entremezclando nuestra lógica con la del
esqueleto con lo que es necesario conocer qué hace el esqueleto para encajar nuestro
programa.

PERFORM S100-INICIO
THRU S100-INICIO-EXIT.
*-----------
PERFORM A100-INICIO-PROGRAMA
THRU A100-INICIO-PROGRAMA-EXIT.

PERFORM A400-PROCESO-PROGRAMA
THRU A400-PROCESO-PROGRAMA-EXIT.

PERFORM A900-FIN-PROGRAMA
THRU A900-FIN-PROGRAMA-EXIT.

Software Factory Rafael Campillo Lorenzo.
Cáceres –

27

*-----------
PERFORM S900-FIN
THRU S900-FIN-EXIT.

STOP RUN.
****************************************************************************************
**
***
*** S100-INICIO
***
****************************************************************************************
**
S100-INICIO.

*---------------------------------------------------------------*
*--- INICIALIZAR VARIABLES DE PROCESO (COPY URSWITCH)
*---------------------------------------------------------------*
SET NO-HAY-ERROR-PROCESO TO TRUE.
SET NO-FIN-PROCESO TO TRUE.
SET NO-RELANZAMIENTO TO TRUE.
SET NO-FIN-DATOS TO TRUE.
SET NO-ERROR TO TRUE.
MOVE ZEROS TO CA-COMMIT.

*---------------------------------------------------------------*
*--- ACTUALIZACION DE DATOS DE RURCOMM CON LOS DATOS DE
*--- PARAMETRO Y DAPROCBATCH.
*----------------------------------------------------------------*

Estos parámetros son pasados al programa por el JCL y recibidos en LINKAGE
(PARMLIST). Para obtenerlos se invoca la rutina UR0000 con RUR-INIT, ésta deja los
parámetros desglosados en subniveles de la variable RURCOMM.
Esta llamada inicial a la rutina UR0000 se tiene que hacer siempre, aunque el proceso
no tenga ficheros de salida.
La variable RUR-CALL ya contiene el nombre 'UR0000' y pertenece a una de las
Copys. El formato de la llamada puede ser uno de los siguientes:

EXEC-FUN UR_PARM PARMS(PARAMETROS) END-FUN
o
CALL RUR-CALL USING RUR-INIT RURCOMM PARAMETROS

Las variables obtenidas son:
CA-PLANNAME Nombre del plan.
CA-PROCESO Número de proceso.
CA-NUMREG Número de registros tratados en cada confirmación (COMMIT).
CA-PREF Prefijo de los ficheros, dependerá del subsistema donde se esté
ejecutando (DES: desarrollo, SIS: sistemas, EXP: explotación).
Cuando el proceso tiene ficheros de salida, esta llamada a la rutina sirve también para
recuperar sus datos, que se almacenarán la variable CA-DDNAMES de la copy
RURCOMM.

CALL RUR-CALL USING RUR-INIT RURCOMM PARAMETRO

MOVE CA-PROCESO TO UR-PROCESO

Antes de comenzar el tratamiento de los datos de entrada, se consultará en qué
estado se encuentra el proceso, para saber si es necesario reposicionar o por el
contrario se comienza el proceso desde el principio. Para ello se accede a la tabla
DAREPOS utilizando el cursor “REP”, proporcionado en la INCLUDE URCURSOR. Se
abrirá el cursor para el plan y el número de proceso pasados en los parámetros de
reposicionamiento y se recuperará una única fila.