Manual de supervivencia Cobol

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

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

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

Cáceres –
5
Figura 12 - SORT - Ordena y cambia disposicion de campos.................................. 107
Figura 13 - SORT - Eliminar repetidos................................................................... 108
Figura 14 - SORT - Acumular................................................................................ 109

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.

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.

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.

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.

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

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 salvedad de 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

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

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

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

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

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 adquiridos hasta 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.

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.

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 COMMIT se 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

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ó.

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 PRSTAMOS.(SALDO_VALOR_

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 PRSTAMOS
*
****************************************************************************************
***
****************************************************************************************
***
*
* 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.

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
01 REGALTAS1 PIC X(140).
FD ERRALTA
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.
****************************************************************************************
***

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.

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'.

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.
- 'LEÍDOS EN EL FICHERO ALTAS1: '.
10 WK-CONT-ALTAS1 PIC 9(9) VALUE ZEROS.
05 WK-ESCRITURAS-ERRALTA.
- 'ESCRITOS EN EL FICHERO ERRALTA: '.

Cáceres –
26
10 WK-CONT-ERRALTA PIC 9(9) VALUE ZEROS.
05 WK-ESCRITURAS-SALDO-VALOR-PTM.
- '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.

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.
EXEC SQL
OPEN REP

Cáceres –
28
END-EXEC.
MOVE SQLCODE TO SW-DB2-RETURN-CODE
EVALUATE TRUE
WHEN DB2-OK CONTINUE
WHEN OTHER
EXEC-FUN XX_CANCELACION_PROCESOS_BATCH
TIPO_ERROR('UR-MSG-TIPO-ERROR')
DESCRIPCION('UR-MSG-OPEN-REP')
PROGRAMA('CA-LQBBN01')
PARRAFO('UR-MSG-INICIO')
SQLCA('SQLCA')
END-FUN
END-EVALUATE.
EXEC SQL
FETCH REP INTO :RUR-PLANNAME,
:RUR-PROCES,
:RUR-ESTADO,
:RUR-NUMCOMM,
:RUR-PUNTEROS
END-EXEC.
*
EVALUATE TRUE
WHEN DB2-OK
*---------------------------------------------------------------*
*--- "I" : ESTADO DE EJECUCIóN MEDIANTE ARSB (VIA ONLINE)
*--- SE HA RESERVADO EL NUMERO DE PROCESO PARA LA
*--- EJECUCION.
*---------------------------------------------------------------*
IF RUR-ESTADO = CA-ESTADO-I
MOVE SPACES TO UR-VALOR-REGISTRO-TEXT
MOVE 254 TO UR-VALOR-REGISTRO-LEN
MOVE ZEROES TO UR-CEROS
*--- ACTUALIZAR A ESTADO "C" Y GUARDAR PUNTEROS.
EXEC SQL
UPDATE DAREPOS
SET RUR_ESTADO = :CA-ESTADO-C,
RUR_NUMCOMM = :UR-CEROS,
RUR_PUNTEROS = :UR-VALOR-REGISTRO
WHERE CURRENT OF REP
END-EXEC
EVALUATE TRUE
WHEN OTHER
DESCRIPCION('UR-MSG-UPDA-REP')
SQLCA('SQLCA')
END-FUN
END-EVALUATE
*--- REALIZAMOS COMMIT: Y ASÍ ACTUALIZAMOS LA TABLA DAREPOS.
*--- SE RECOMIENDA CONTROLAR EL CODIGO DE RETORNO DE LA SENTENCIA
*--- COMMIT Y ABENDAR EL PROGRAMA EN CASO DE SQLCODE DISTINTO DE
*--- CERO, YA QUE LOS DATOS PUEDEN QUEDAR INCONSISTENTES.
Antes de comenzar se debe hacer una primera confirmación (COMMIT) para liberar el
bloqueo sobre la tabla DAREPOS. Ésta no contabiliza en el proceso del número de

Cáceres –
29
confirmaciones, de hecho, si no hay reposicionamiento, se ha inicializado a cero en la
tabla DAREPOS.
EXEC SQL COMMIT END-EXEC
EVALUATE TRUE
WHEN OTHER
DESCRIPCION('UR-MSG-COMM-REP')
SQLCA('SQLCA')
END-FUN
END-EVALUATE
MOVE ZEROES TO RUR-NUMCOMM
ELSE
*---------------------------------------------------------------------------------------
*--- "P" : IMPLICA QUE LOS FICHEROS RESULTANTES DEL
*--- PROCESO HAN SIDO BORRADOS Y SE PUEDE EJECUTAR
*--- DE NUEVO EL PLAN.
*---------------------------------------------------------------------------------------
Estado Inicial (P).
Un proceso está en estado inicial P cuando su última ejecución se completó
correctamente, sin ningún error. Implica que el proceso se encuentra en condiciones
de ser relanzado, los ficheros resultantes del último proceso han sido borrados y se
puede ejecutar de nuevo el plan. Si el programa de reposicionamiento comprueba que
el proceso se encuentra en estado inicial NO REPOSICIONARÁ SU ENTRADA, puesto
que debe comenzar el proceso desde el principio.
Si la consulta a la tabla DAREPOS indica que el proceso se encuentra en estado inicial
(P), se modificará para inicializar el número de validaciones a cero. Además se pondrá
el switch de reposicionamiento a “N”, para que el proceso comience desde el principio.
(SW-RELANZAMIENTO _ NO-RELANZAMIENTO).
IF RUR-ESTADO = CA-ESTADO-P
MOVE ZEROES TO UR-CEROS
*--- ACTUALIZAR A ESTADO "C" Y GUARDAR PUNTEROS.
EXEC SQL
UPDATE DAREPOS
SET RUR_ESTADO = :CA-ESTADO-C,
RUR_NUMCOMM = :UR-CEROS,
WHERE CURRENT OF REP
END-EXEC
EVALUATE TRUE
WHEN OTHER
SQLCA('SQLCA')
END-FUN
END-EVALUATE
*--- REALIZAMOS COMMIT:

Cáceres –
30
EVALUATE TRUE
WHEN OTHER
SQLCA('SQLCA')
END-FUN
END-EVALUATE
ELSE
*---------------------------------------------------------------------------------------
*--- "C" : IMPLICA QUE SE ESTAN REALIZANDO COMMITS
* O QUE SE ES RELANZAMIENTO EN CASO DE NO SER LA PRIMERA VEZ
*---------------------------------------------------------------------------------------
Estado Intermedio (C).
Un proceso está en estado intermedio cuando durante su última ejecución acabó con un abend
o un error después de haber hecho una o varias confirmaciones (COMMIT).
Si el programa de reposicionamiento comprueba que el proceso se encuentra en estado
intermedio REPOSICIONARÁ SU ENTRADA, puesto que debe comenzar en el siguiente
registro de entrada al último confirmado.
Si la consulta a la tabla DAREPOS indica que el proceso se encuentra en estado
intermedio (C) será necesario reposicionarse antes de comenzar el tratamiento. Para
ello:
− Se mueve la información del puntero (RUR_PUNTEROS) a la variable utilizada para
el reposicionamiento: CLAVE-ALTAS1.
− Se recupera el número de validaciones realizadas (RUR_NUMCOMM).
− Se pone el switch de reposicionamiento a “S”, para que el proceso se reposicione
antes de comenzar el tratamiento. (SW-RELANZAMIENTO _ SI-RELANZAMIENTO).
IF RUR-ESTADO = CA-ESTADO-C
MOVE RUR-NUMCOMM TO CA-COMMIT
MOVE RUR-PUNTEROS-TEXT TO CLAVE-ALTAS1
SET SI-RELANZAMIENTO TO TRUE
EXEC SQL CLOSE REP END-EXEC
EVALUATE TRUE
WHEN OTHER
DESCRIPCION('UR-MSG-CLOSE-CUR')
SQLCA('SQLCA')
END-FUN
END-EVALUATE
ELSE
DESCRIPCION('UR-MSG-ESTADO-DAR')

Cáceres –
31
SQLCA('SQLCA')
END-FUN
END-IF
END-IF
END-IF
WHEN DB2-CLV-NOT-FOUND
*---------------------------------------------------------------*
*--- SI NO EXISTE EN DAREPOS SE CREA UNA ENTRADA
*--- CON ESTADO "C" GUARDANDO PUNTEROS.
*---------------------------------------------------------------*
EXEC SQL
INSERT INTO DAREPOS
(RUR_PLANNAME,
RUR_PROCES,
RUR_ESTADO,
RUR_NUMCOMM,
RUR_PUNTEROS)
VALUES (:CA-PLANNAME,
:UR-PROCESO,
:CA-ESTADO-C,
:UR-CEROS,
:UR-VALOR-REGISTRO)
END-EXEC
EVALUATE TRUE
WHEN OTHER
DESCRIPCION('UR-MSG-INSERT-REP')
SQLCA('SQLCA')
END-FUN
END-EVALUATE
EVALUATE TRUE
WHEN OTHER
SQLCA('SQLCA')
END-FUN
END-EVALUATE
WHEN OTHER
DESCRIPCION('UR-MSG-FETCH-REP')
SQLCA('SQLCA')

Cáceres –
32
END-FUN
END-EVALUATE.
S100-INICIO-EXIT.
EXIT.
****************************************************************************************
*********
*
* A100-INICIO-PROGRAMA.
*
* SE INICIALIZAN TODAS LAS VARIABLES PARA CAMPOS DE LA FUNCIÓN
* DE ERRORES Y LOS CAMPOS DE ESTADÍSTICAS. ADEMÁS SE ABREN LOS
* FICHEROS CONTBA3 Y ALTAS1 EN MODO ENTRADA Y EL FICHERO ERRALTA
* EN MODO DE SALIDA, Y SE LEE EL PRIMER REGISTRO DE CONTBA3 Y
* ALTAS1.
*
****************************************************************************************
*********
A100-INICIO-PROGRAMA.
*---------------------------------------------------------------*
*--- INICIALIZAR DCLGEN DE LAS TABLAS Y CAMPOS DE WORKING
*---------------------------------------------------------------*
INITIALIZE DCLSALDO-VALOR-PTM
WK-ERROR-DB2
WK-ERROR-RUTINA
WK-ERROR-TABLA-MEMORIA
WK-ERROR-FICHERO
WK-ERROR-OTROS
CONT-CONTBA3
CONT-ALTAS1
CONT-ERRALTA
CONT-SALDO-VALOR-PTM
Para el caso de programas que utilizan ficheros de entrada (en nuestro caso CONTBA3
y el maestro: ALTAS1) tienen que controlar mediante un switch (SI-RELANZAMIENTO)
si es la primera vez que entra al programa o es relanzamiento porque haya abendado
anteriormente el proceso. En éste caso deberá leerse el fichero desde el principio hasta
el registro grabado en DAREPOS correspondiente al último COMMIT.
*---------------------------------------------------------------*
*--- SE ABREN LOS FICHEROS
*---------------------------------------------------------------*
PERFORM A150-ABRIR-FICHEROS
THRU A150-ABRIR-FICHEROS-EXIT
*---------------------------------------------------------------*
*--- SI ENTRA AL PROGRAMA POR RELANZAMIENTO PORQUE HAYA
*--- CASCADO EL PROCESO, DEBE LEERSE EL FICHERO DE ENTRADA
*--- DESDE EL PRINCIPIO HASTA EL ULTIMO REGISTRO GRABADO
*--- EN EL ULTIMO COMMIT, GRABADO EN "DAREPOS".
*---------------------------------------------------------------*
IF SI-RELANZAMIENTO
PERFORM A110-RELEER-FICH-ENTRADA THRU
A110-RELEER-FICH-ENTRADA-EXIT
UNTIL FIN-DATOS
*---------------------------------------------------------------*
*--- ENTRA A LEER LOS FICHEROS DE ENTRADA POR PRIMERA VEZ
*---------------------------------------------------------------*
ELSE
MOVE LOW-VALUE TO CLAVE-ALTAS1
CLAVE-CONTBA3
PERFORM 9100-LEER-FICH-ALTAS1
THRU 9100-LEER-FICH-ALTAS1-EXIT
PERFORM 9200-LEER-FICH-CONTBA3
THRU 9200-LEER-FICH-CONTBA3-EXIT
END-IF.

Cáceres –
33
A100-INICIO-PROGRAMA-EXIT.
EXIT.
*************************************************************
***
*** A110-RELEER-FICH-ENTRADA
***
*************************************************************
A110-RELEER-FICH-ENTRADA.
IF NO-FIN-PROCESO AND NO-FIN-DATOS
READ ALTAS1 INTO BNYDE008
AT END
SET FIN-DATOS TO TRUE
SET SW-SI-FIN-CONTBA3 TO TRUE
SET FIN-PROCESO TO TRUE
MOVE HIGH-VALUES TO CLAVE-ALTAS1
NOT AT END
SET SW-NO-FIN-ALTAS1 TO TRUE
*--- MOVER LOS CAMPOS DEL REGISTRO AL CAMPO WORKING
*--- UR-CLAVE-RELANZAMIENTO.
MOVE BNYDE008-IDEMPR TO IDEMPR-RELANZAMIENTO
MOVE BNYDE008-IDCENT TO IDCENT-RELANZAMIENTO
MOVE BNYDE008-IDPROD TO IDPROD-RELANZAMIENTO
MOVE BNYDE008-IDCONTRN TO IDCONTR-RELANZAMIENTO
END-READ
IF FS-ALTAS1 NOT EQUAL CA-FICH-OK AND
NOT EQUAL CA-FIN-FICH
MOVE CA-PARRAFO-INICIO TO WK-PARRAFO
MOVE CA-ALTAS1 TO WK-DDNAME
MOVE FS-ALTAS1 TO WK-FILE-STATUS
MOVE CA-ERROR-APERTURA TO WK-DESCRIPCION
PERFORM 9300-ERROR-FICHERO
THRU 9300-ERROR-FICHERO-EXIT
END-IF
END-IF
*--- EL REGISTRO LEIDO ES MAYOR AL ULTIMO LEIDO ANTES DE
*--- CASCAR EL PROGRAMA, QUE ESTA GRABADO EN 'DAREPOS'.
IF UR-CLAVE-RELANZAMIENTO > CLAVE-ALTAS1
Hemos de tener en cuenta que hay que actualizar la clave de reposicionamiento
CLAVE-ALTAS1 a la siguiente, porque el registro almacenado en ella ya ha sido
procesado, y se ha de continuar por el siguiente.
MOVE UR-CLAVE-RELANZAMIENTO TO CLAVE-ALTAS1
SET FIN-DATOS TO TRUE
END-IF.
***
A110-RELEER-FICH-ENTRADA-EXIT.
EXIT.
**************************************************************************************
* A150-ABRIR-FICHEROS.
*
* SE ABREN LOS FICHEROS CONTBA3 Y ALTAS1 EN MODO ENTRADA Y EL
* FICHERO ERRALTA EN MODO DE SALIDA Y SE COMPRUEBA QUE SE HA
* REALIZADO LA OPERACIÓN CORRECTAMENTE. EN CASO CONTRARIO SE
* LLAMA AL PÁRRAFO 9300-ERROR-FICHERO
*
**************************************************************************************
A150-ABRIR-FICHEROS.
OPEN INPUT CONTBA3
ALTAS1
IF FS-CONTBA3 NOT EQUAL CA-FICH-OK
MOVE CA-CONTBA3 TO WK-DDNAME
MOVE FS-CONTBA3 TO WK-FILE-STATUS
END-IF

Cáceres –
34
IF FS-ALTAS1 NOT EQUAL CA-FICH-OK
END-IF.
A150-ABRIR-FICHEROS-EXIT.
EXIT.
****************************************************************************************
**
* A400-PROCESO-PROGRAMA.
*
* PROCESO PRINCIPAL DEL PROGRAMA. SE REALIZARÁ UN PROCESO CONTÍNUO
* EN EL QUE SÓLO SE SALDRÁ CUANDO SE LLEGUE AL FINAL DEL FICHERO
* DE ALTAS1 OR CONTBA3, O SE DETECTE ALGÚN ERROR MENCIONADO A
* CONTINUACIÓN QUE INDIQUE EL FINAL DEL PROGRAMA
*
**************************************************************************************
A400-PROCESO-PROGRAMA.
Se van alocando los ficheros de salida dinámicamente por cada commit que se realiza.
PERFORM S400-PROCESO-COMMIT
THRU S400-PROCESO-COMMIT-EXIT
UNTIL FIN-PROCESO OR SI-ERROR.
El programa contendrá, después de su inicio, un bucle externo y otro interno. El bucle
externo, se repetirá hasta que no haya más datos de entrada (SW-FIN-DATOS) o hasta
que ocurra un error.
A400-PROCESO-PROGRAMA-EXIT.
EXIT.
*********************************************************************
***
*** S400-PROCESO-COMMIT
***
*********************************************************************
S400-PROCESO-COMMIT.
En este bucle externo se incluirán las siguientes tareas, además de las propias de la
aplicación.
Ext. 1. Iniciación del contador de registros procesados a 1.
Ext. 2. Alocación de los ficheros de salida, si existen en el proceso.
Se hará una llamada a la rutina UR0000 con el parámetro RUR-NEW para alocar los
ficheros de salida. Formato:
CALL RUR-CALL USING RUR-NEW RURCOMM DCLDAREPOS
La rutina UR0000 llamada de ésta manera construirá el nombre del fichero
correspondiente para cada DDNAME y número de confirmación, alocando
dinámicamente cada uno de ellos. Si durante este proceso se produjese algún error
aparecerá reflejado en el fichero de mensajes (RURMSG) y el JOB se cancelará. Así
mismo por cada fichero alocado se enviará un mensaje informativo (UR0015).
El nombre de los ficheros es distinto por cada COMMIT y se compone de:
XXX.DDDDDDDD.PPPPPPPP.RnnVnnnn
Donde XXX es el prefijo. Parámetro del JCL.
DDDDDDDD es el nombre de la dd del fichero, información contenida en la tabla
DAPROCBATCH.
PPPPPPPP es el nombre del plan. Parámetro del JCL.

Cáceres –
35
Rnn. Número del proceso. Parámetro del JCL.
Vnnnn. Número del COMMIT al que corresponde. Por lo tanto al final del proceso
habrá tantos ficheros por ddname definida en DAPROCBATCH como COMMITS se
hayan hecho.
No necesitan hacer ésta llamada los programas que no utilizan ficheros secuénciales de
salida.
Ext. 3. Abrir los ficheros de salida, si existen en el proceso.
Bucle Interior.
Procesa todos los registros de entrada entre validaciones, hasta que el contador
de registros procesados alcanza el valor de CA-NUMREG (parámetro
introducido en el JCL), se acaban los datos de entrada o hay algún error.
Int. 1. Lectura del siguiente dato de entrada.
Int. 2. Proceso propio de la aplicación. Instrucciones para el
tratamiento de los datos de entrada.
Int. 3. Actualización del contador de registros tratados.
Suma uno al contador de registros tratados.
Ext. 4. Cerrar los ficheros de salida, si los hay.
Ext. 5. Validar las modificaciones DB2.
Se hace COMMIT.
Ext. 6. SI NO HAY FICHEROS DE SALIDA, sumar 1 al número de validaciones
(CACOMMIT)
Sólo si no hay ficheros de salida, se debe sumar 1 al número de validaciones, variable
CA-COMMIT proporcionada por los parámetros del JCL. En caso de que existan
ficheros de salida NO se debe actualizar el número de validaciones, por que lo hace la
rutina UR0000 y si se vuelve a hacer en el programa provocará errores.
Ext. 7. Sólo si hay ficheros de salida, actualizar el número de validaciones y el
puntero en DAREPOS.
Actualiza la fila de la tabla DAREPOS correspondiente a este plan/proceso sumando
uno al número de validaciones y anotando en el puntero la última clave de entrada
tratada correctamente. El plan/proceso con el que estamos trabajando son datos que
se leyeron de los parámetros del JCL al principio del programa, en el paso I. 2.
*---------------------------------------------------------------------------------------
*--- REALIZA UNA LLAMADA DINAMICA A LA COPY DE RURCOMM
*--- PARA MONTAR EL NOMBRE DEL FICHERO Y ALOCARLO
*---------------------------------------------------------------------------------------
* RUR-NEW: LA RUTINA UR0000 LLAMADA DE ESTA MANERA POR EL PROG
* DE APLICACIÓN CONSTRUIRÁ EL NOMBRE DE FICHERO CORRESPONDIENTE
* PARA CADA DDNAME Y NÚMERO DE COMMIT, ALOCANDO DINÁMICAMENTE
* CADA UNO DE ELLOS. ESTA RUTINA A SU VEZ LLAMA A OTRAS RUTINAS
* ENSAMBLADOR. EL NOMBRE DE LOS FICHEROS ES DISTINTO POR CADA
* COMMIT.
CALL RUR-CALL USING RUR-NEW RURCOMM DCLDAREPOS.
*---------------------------------------------------------------------------------------
*--- ABRIMOS EL FICHERO DE SALIDA PARA EL REPOSICIONAMIENTO.
*---------------------------------------------------------------------------------------
OPEN OUTPUT ERRALTA.
IF FS-ERRALTA NOT EQUAL CA-FICH-OK
MOVE CA-ERRALTA TO WK-DDNAME
MOVE FS-ERRALTA TO WK-FILE-STATUS
END-IF
*---------------------------------------------------------------------------------------
*--- INICIALIZA CONTADOR DE REGISTROS A 1
*---------------------------------------------------------------------------------------

Cáceres –
36
MOVE CN-UNO TO UR-CONT-REG
PERFORM S410-UNIDAD-COMMIT
THRU S410-UNIDAD-COMMIT-EXIT
UNTIL UR-CONT-REG GREATER CA-NUMREG OR
FIN-PROCESO OR SI-ERROR
*---------------------------------------------------------------------------------------
*--- CERRAR FICHERO SALIDA ERRALTA
*---------------------------------------------------------------------------------------
CLOSE ERRALTA
END-IF
*---------------------------------------------------------------------------------------
*--- ACTUALIZAR NUMERO DE COMMITS Y PUNTEROS EN DAREPOS.
*---------------------------------------------------------------------------------------
MOVE CA-COMMIT TO UR-COMMIT
MOVE CA-PROCESO TO UR-PROCESO
*---------------------------------------------------------------------------------------
*--- MOVER LOS CAMPOS CLAVE DEL FICHERO A LOS CAMPOS DE WORKING
*--- PARA REPOSICIONAMIENTO: UR-CLAVE-REPOSIC.
*---------------------------------------------------------------------------------------
MOVE CLAVE-ALTAS1 TO UR-VALOR-REGISTRO-TEXT
MOVE CN-DIECIOCHO TO UR-VALOR-REGISTRO-LEN
*
EXEC SQL
UPDATE DAREPOS
SET
RUR_NUMCOMM = :UR-COMMIT,
WHERE RUR_PLANNAME = :CA-PLANNAME
AND RUR_PROCES = :UR-PROCESO
END-EXEC.
EVALUATE TRUE
WHEN OTHER
PARRAFO('UR-MSG-PROC-COMM')
SQLCA('SQLCA')
END-FUN
END-EVALUATE.
*---------------------------------------------------------------------------------------
*---------------------------------------------------------------------------------------
EXEC SQL COMMIT END-EXEC.
EVALUATE TRUE
WHEN OTHER
DESCRIPCION('UR-MSG-PROC-COMM')

Cáceres –
37
PARRAFO('UR-MSG-PROC-COMM')
SQLCA('SQLCA')
END-FUN
END-EVALUATE
*---------------------------------------------------------------------------------------
*--- SI NO HAY ERROR VUELVE A LEER EL FICHERO DE ENTRADA
*---------------------------------------------------------------------------------------
IF SI-ERROR OR FIN-PROCESO
CONTINUE
ELSE
THRU 9100-LEER-FICH-ALTAS1-EXIT.
***
S400-PROCESO-COMMIT-EXIT.
EXIT.
****************************************************************
***
*** S410-UNIDAD-COMMIT
***
****************************************************************
S410-UNIDAD-COMMIT.
*--- AQUÍ COMIENZA LA LÓGICA DEL PROGRAMA.
Este sería el párrafo proceso utilizado en nuestro programa. Enfrentamos el fichero
maestro ALTAS1 con el fichero CONTBA3.
IF CLAVE-ALTAS1 LESS THAN CLAVE-CONTBA3
SET SW-SI-LEE-ALTAS1 TO TRUE
CONTINUE
ELSE
IF CLAVE-ALTAS1 EQUAL CLAVE-CONTBA3
SET SW-SI-LEE-ALTAS1 TO TRUE
PERFORM 2100-PARRAFO-ALTAS
THRU 2100-PARRAFO-ALTAS-EXIT
ELSE
SET SW-NO-LEE-ALTAS1 TO TRUE
UNTIL (CLAVE-ALTAS1 LESS THAN CLAVE-CONTBA3) OR
(CLAVE-ALTAS1 EQUAL CLAVE-CONTBA3)
END-IF
END-IF
*--- AQUÍ TERMINA LA LÓGICA DEL PROGRAMA
(Ver #ANEXO4)
ADD CN-UNO TO UR-CONT-REG
*---------------------------------------------------------------------------------------
----------*
*--- CUANDO EL CONTADOR DE REGISTROS SEA MAYOR AL CAMPO CA-NUMREG
*--- DE "RURCOMM" : CIERRA EL FICHERO, HACE COMMIT Y ACTUALIZA DAREPOS.
*---------------------------------------------------------------------------------------
----------*
IF UR-CONT-REG GREATER THAN CA-NUMREG
CONTINUE
ELSE
IF SW-SI-LEE-ALTAS1

Cáceres –
38
THRU 9100-LEER-FICH-ALTAS1-EXIT
END-IF
END-IF.
S410-UNIDAD-COMMIT-EXIT.
EXIT.
*************************************************************
***
*** A900-FIN-PROGRAMA
***
*************************************************************
A900-FIN-PROGRAMA.
*---------------------------------------------------------------*
*--- CERRAR FICHEROS DE ENTRADA
*---------------------------------------------------------------*
PERFORM 3100-CERRAR-FICHEROS
THRU 3100-CERRAR-FICHEROS-EXIT
PERFORM 9500-ESTADISTICAS
THRU 9500-ESTADISTICAS-EXIT.
A900-FIN-PROGRAMA-EXIT.
EXIT.
*******************************************************************
***
*** S900-FIN
***
*******************************************************************
S900-FIN.
Estado Final (F)
Un proceso se encuentra en estado final cuando después de su última ejecución
correcta AÚN NO SE HAN FUSIONADO SUS FICHEROS DE SALIDA.
Si el programa de reposicionamiento comprueba que el proceso se encuentra en
estado final DEBE TERMINAR sin procesar ningún dato. Puesto que los ficheros de
salida definitivos aún no se han creado. En este caso debería arrancarse el JCL desde
el paso posterior al programa con reposicionamiento, que fusionará los juegos de
ficheros creados por el programa en los ficheros de salida definitivos.
*---------------------------------------------------------------------------------------
----------*
*--- ACTUALIZA DAREPOS CON EL ESTADO IGUAL A "F".
*--- "F" : IMPLICA PROCESO FINALIZADO O PENDIENTE
*--- DE UTILIDADES
*---------------------------------------------------------------------------------------
----------*
EXEC SQL
UPDATE DAREPOS
SET RUR_ESTADO = :CA-ESTADO-F
WHERE RUR_PLANNAME = :CA-PLANNAME
AND RUR_PROCES = :UR-PROCESO
END-EXEC.
EVALUATE TRUE
WHEN OTHER
PARRAFO('UR-MSG-FIN')
SQLCA('SQLCA')
END-FUN

Cáceres –
39
END-EVALUATE.
GOBACK.
***
S900-FIN-EXIT.
EXIT.
**************************************************************************************
* 2100-PARRAFO-ALTAS
*
* POR CADA POSICIÓN SE HA DE DAR UN ALTA EN LA TABLA SALDO_VALOR
* _PTM, COM EL CAMPO POSICIONES LQYCONTL-OSICIONES ES DE 24
* CARACTERES Y CADA POSICIÓN ESTÁ DEFINIDA CON 3 CARACTERES,COMO
* MÁXIMO SERÁN 8 LAS POSICIONES QUE SE PODRÁN DAR DE ALTA
**************************************************************************************
2100-PARRAFO-ALTAS.
MOVE LQYCONTL-POSICIONES TO W-POSICIONES
MOVE CN-UNO TO IND-I
PERFORM 2150-POSICIONES
THRU 2150-POSICIONES-EXIT
UNTIL IND-I GREATER THAN CN-OCHO
OR W-POSICION(IND-I) EQUAL SPACES.
2100-PARRAFO-ALTAS-EXIT.
EXIT.
*************************************************************************************
* 2150-POSICIONES
*
* COMO MÁXIMO SE DAN DE ALTA 8 POSICIONES EN LA TABLA
* SALDO_VALOR_PTM
*************************************************************************************
2150-POSICIONES.
MOVE W-POSICION(IND-I) TO W-POSICION-ALTA
PERFORM 2200-ESCR-SALDO-V-PTM
THRU 2200-ESCR-SALDO-V-PTM-EXIT
ADD 1 TO IND-I.
2150-POSICIONES-EXIT.
**************************************************************************************
* 2200-ESCR-SALDO-V-PTM
*
* SE ESCRIBE EN LA TABLA SALDO_VALOR_PTM UN REGISTRO CON EL
* SALDO A 0 POR CADA POSICIÓN LEÍDA EN EL FICHERO CONTBA3
**************************************************************************************
2200-ESCR-SALDO-V-PTM.
MOVE LQYCONTL-IDCENT TO E4294-IDCENT
MOVE LQYCONTL-IDPROD TO E4294-IDPROD
MOVE LQYCONTL-IDCONTR TO E4294-IDCONTR
MOVE W-POSICION-ALTA TO E4294-TIPMVTO
MOVE LQYCONTL-CODMONBE TO E4294-CODMONSW
MOVE CN-UNO TO E4294-NUMERSEC
MOVE LQYCONTL-IDSTIPRO TO E4294-IDSTIPRO
MOVE LQYCONTL-COESTREF TO E4294-COESTREF
MOVE BNYDE008-FECAPER TO E4294-FHSALV
MOVE CN-CERO TO E4294-SALDCTA
*---
MOVE BNYDE008-FECAPER(1:4) TO FECAPER-NUM(1:4)
MOVE FECAPER-FECHA TO FEC-VALOR-TRA(1, 1)
MOVE CN-CERO TO DIAS-AVX-TRA(1, 1)
MOVE CN-CERO TO DIAS-AVB-TRA(1, 1)
MOVE CN-CERO TO SALDO-VALOR-TRA(1, 1)
MOVE CN-DIECISIETE TO E4294-IMPSALV-LEN
MOVE REG-SALDOS-VALOR-TRA(1) TO E4294-IMPSALV-TEXT

Cáceres –
40
*---
MOVE LQYCONTL-IDEMPR TO E4294-IDEMPR
EXEC SQL
INSERT INTO SALDO_VALOR_PTM
(E4294_IDCENT,
E4294_IDPROD,
E4294_IDCONTR,
E4294_TIPMVTO,
E4294_CODMONSW,
E4294_NUMERSEC,
E4294_IDSTIPRO,
E4294_COESTREF,
E4294_FHSALV,
E4294_SALDCTA,
E4294_IMPSALV,
E4294_IDEMPR)
VALUES
(:E4294-IDCENT,
:E4294-IDPROD,
:E4294-IDCONTR,
:E4294-TIPMVTO,
:E4294-CODMONSW,
:E4294-NUMERSEC,
:E4294-IDSTIPRO,
:E4294-COESTREF,
:E4294-FHSALV,
:E4294-SALDCTA,
:E4294-IMPSALV,
:E4294-IDEMPR)
END-EXEC
EVALUATE TRUE
WHEN DB2-OK
* ACUMULAR PARA ESTADISTICAS
ADD CN-UNO TO CONT-SALDO-VALOR-PTM
WHEN DB2-CLV-DUPLI-INSERT
PERFORM 2300-ESCR-ERR-ALTA
THRU 2300-ESCR-ERR-ALTA-EXIT
WHEN OTHER
MOVE CA-ERROR-INSERT TO WK-DESCRIPCION
MOVE CA-ESCRIBIR-SALDO-PTM TO WK-PARRAFO
MOVE CA-SALDO-VALOR-PTM TO WK-TABLA-DB2
MOVE DCLSALDO-VALOR-PTM TO WK-DATOS-ACCESO
PERFORM 9400-ERROR-DB2
THRU 9400-ERROR-DB2-EXIT
END-EVALUATE.
2200-ESCR-SALDO-V-PTM-EXIT.
EXIT.
**************************************************************************************
* 2300-ESCR-ERR-ALTA
*
* LA PREEXISTENCIA 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)
**************************************************************************************
2300-ESCR-ERR-ALTA.
* ACUMULAR PARA ESTADÍSTICAS
ADD CN-UNO TO CONT-ERRALTA
INITIALIZE W-COPY-TABLA
MOVE E4294-IDEMPR TO W-COPY-IDEMPR
MOVE E4294-IDCENT TO W-COPY-IDCENT
MOVE E4294-IDPROD TO W-COPY-IDPROD
MOVE E4294-IDCONTR TO W-COPY-IDCONTR
MOVE CA-CODERROA TO W-COPY-CODERROA
MOVE E4294-IDSTIPRO TO W-COPY-IDSTIPRO

Cáceres –
41
MOVE E4294-COESTREF TO W-COPY-COESTREF
MOVE E4294-CODMONSW TO W-COPY-CODMONBE
MOVE CA-CODCESTX TO W-COPY-CODCESTX
MOVE CA-AORIGEN TO W-COPY-AORIGEN
MOVE CA-AORIGEN TO W-COPY-ASUBORIG
MOVE CN-OCHENTA TO W-COPY-DATCOMPV-LEN
MOVE E4294-TIPMVTO TO WK-TIPMVTO
MOVE WK-EXISTENCIA-CONTRATO TO W-COPY-DATCOMPV-TEXT
WRITE REGERRALTA FROM W-COPY-TABLA
END-IF.
2300-ESCR-ERR-ALTA-EXIT.
EXIT.
**************************************************************************************
* 3100-CERRAR-FICHEROS.
*
* SE CIERRAN LOS TRES FICHEROS (CONTBA3,ALTAS1 Y ERRALTA)
* Y SE COMPRUEBA QUE SE HAN CERRADO CORRECTAMENTE,EN CASO
* CONTRARIO SE PROCEDE AL TRATAMIENTO DE ERROR DE FICHERO
*
**************************************************************************************
3100-CERRAR-FICHEROS.
CLOSE CONTBA3
ALTAS1
IF FS-CONTBA3 NOT EQUAL CA-FICH-OK
END-IF
IF FS-ALTAS1 NOT EQUAL CA-FICH-OK
END-IF
.
3100-CERRAR-FICHEROS-EXIT.
EXIT.
**************************************************************************************
* 9100-LEER-FICH-ALTAS1
*
* SE REALIZA LA LECTURA DEL FICHERO DE ALTAS1,ACUMULANDO LAS
* ESTADÖSTICAS Y TRATANDO SI PROCEDE UN POSIBLE ERROR EN LA
* LECTURA
**************************************************************************************
9100-LEER-FICH-ALTAS1.
READ ALTAS1 INTO BNYDE008
AT END
SET SW-SI-FIN-ALTAS1 TO TRUE
SET FIN-PROCESO TO TRUE
MOVE HIGH-VALUES TO CLAVE-ALTAS1
NOT AT END
ADD CN-UNO TO CONT-ALTAS1
SET SW-NO-FIN-ALTAS1 TO TRUE
MOVE BNYDE008-IDEMPR TO IDEMPR-ALTAS1
MOVE BNYDE008-IDCENT TO IDCENT-ALTAS1
MOVE BNYDE008-IDPROD TO IDPROD-ALTAS1
MOVE BNYDE008-IDCONTRN TO IDCONTR-ALTAS1
END-READ
IF FS-ALTAS1 NOT EQUAL CA-FICH-OK AND
MOVE CA-LEER-ALTAS1 TO WK-PARRAFO
MOVE CLAVE-ALTAS1 TO WK-DATOS-REGISTRO

Cáceres –
42
MOVE CA-ERROR-LECTURA TO WK-DESCRIPCION
END-IF.
9100-LEER-FICH-ALTAS1-EXIT.
EXIT.
*************************************************************************************
* 9200-LEER-FICH-CONTBA3
*
* SE REALIZA LA LECTURA DEL FICHERO CONTBA3, ACUMULANDO LAS
* ESTADÖSTICAS Y TRATANDO SI PROCEDE UN POSIBLE ERROR EN LA
* LECTURA
**************************************************************************************
9200-LEER-FICH-CONTBA3.
READ CONTBA3 INTO LQYCONTL
AT END
SET SW-SI-FIN-CONTBA3 TO TRUE
MOVE HIGH-VALUES TO CLAVE-CONTBA3
NOT AT END
ADD CN-UNO TO CONT-CONTBA3
SET SW-NO-FIN-CONTBA3 TO TRUE
MOVE LQYCONTL-IDEMPR TO IDEMPR-CONTBA3
MOVE LQYCONTL-IDCENT TO IDCENT-CONTBA3
MOVE LQYCONTL-IDPROD TO IDPROD-CONTBA3
MOVE LQYCONTL-IDCONTR TO IDCONTR-CONTBA3
END-READ
IF FS-CONTBA3 NOT EQUAL CA-FICH-OK AND
MOVE CA-LEER-CONTBA3 TO WK-PARRAFO
MOVE CA-CONTBA3 TO WK-DDNAME
MOVE FS-CONTBA3 TO WK-FILE-STATUS
MOVE CLAVE-CONTBA3 TO WK-DATOS-REGISTRO
MOVE CA-ERROR-LECTURA TO WK-DESCRIPCION
END-IF.
9200-LEER-FICH-CONTBA3-EXIT.
EXIT.
**************************************************************************************
* 9300-ERROR-FICHERO
*
* SE GUARDA EL TIPO DE ERROR Y SE LLAMA A LA RUTINA:
* XX_CANCELACION_PROCESOS_BATCH
**************************************************************************************
9300-ERROR-FICHERO.
MOVE CA-TIPO-ERROR-F TO WK-TIPO-ERROR
MOVE CA-COD-RETORNO TO WK-COD-RETORNO
MOVE CA-RESPONSABLE TO WK-RESPONSABLE
TIPO_ERROR('WK-TIPO-ERROR')
COD_RETORNO('WK-COD-RETORNO')
RESPONSABLE('WK-RESPONSABLE')
DESCRIPCION('WK-DESCRIPCION')
PROGRAMA('WK-PROGRAMA')
PARRAFO('WK-PARRAFO')
DDNAME('WK-DDNAME')
FILE_STATUS('WK-FILE-STATUS')
DATOS_REGISTRO('WK-DATOS-REGISTRO')
END-FUN
.
9300-ERROR-FICHERO-EXIT.
EXIT.
**************************************************************************************

Cáceres –
43
* 9400-ERROR-DB2
*
* SE GUARDA EL TIPO DE ERROR Y SE LLAMA A LA RUTINA:
* XX_CANCELACION_PROCESOS_BATCH
**************************************************************************************
9400-ERROR-DB2.
MOVE CA-TIPO-ERROR-D TO WK-TIPO-ERROR
MOVE CA-RESPONSABLE TO WK-RESPONSABLE
MOVE SQLCODE TO WK-SQLCA
TIPO_ERROR('WK-TIPO-ERROR')
RESPONSABLE('WK-RESPONSABLE')
DESCRIPCION('WK-DESCRIPCION')
PROGRAMA('WK-PROGRAMA')
PARRAFO('WK-PARRAFO')
SQLCA('WK-SQLCA')
TABLA_DB2('WK-TABLA-DB2')
DATOS_ACCESO('WK-DATOS-ACCESO')
END-FUN
.
9400-ERROR-DB2-EXIT.
EXIT.
**************************************************************************************
* 9500-ESTADISTICAS
*
* SE MUESTRAN LAS ESTADISTICAS DE REGISTROS LEIDOS Y ESCRITOS
**************************************************************************************
9500-ESTADISTICAS.
MOVE CONT-CONTBA3 TO WK-CONT-CONTBA3
MOVE CONT-ALTAS1 TO WK-CONT-ALTAS1
MOVE CONT-ERRALTA TO WK-CONT-ERRALTA
MOVE CONT-SALDO-VALOR-PTM TO WK-CONT-SALDO-VALOR-PTM
DISPLAY CA-ASTERISCO
DISPLAY CA-PROGRAMA-LQBBN01
DISPLAY WK-LECTURAS-CONTBA3
DISPLAY WK-LECTURAS-ALTAS1
DISPLAY WK-ESCRITURAS-ERRALTA
DISPLAY WK-ESCRITURAS-SALDO-VALOR-PTM
DISPLAY CA-ASTERISCO.
9500-ESTADISTICAS-EXIT.
EXIT.

Cáceres –
44
8. JCL (JOB CONTROL LANGUAJE)
Lenguaje de Control de Trabajos. Es un conjunto de especificaciones que constituyen
un lenguaje de programación de tareas para el sistema operativo que gobierna un
equipo informático, generalmente un Mainframe.
Mediante declaraciones y sentencias de JCL se informa al sistema operativo de las
tareas que debe realizar, la secuenciación de las mismas y los contenedores de datos
de entrada y salida para cada uno de los trabajos a ejecutar.
Nos ayuda a ejecutar programas, definir ficheros, etc dentro del SO de un Mainframe:
OS 390. Nos conectaremos a través de la interfaz TSO/ISPF.
Proporciona un alto grado de flexibilidad e independencia respecto de la localización
física de los ficheros y de los programas.
JCL define los requisitos de un trabajo ante el sistema operativo: la información de
contabilidad, los programas que hay que ejecutar, la secuencia de ejecución, los
ficheros necesarios, el equipo físico (Hw) necesario, la orientación del proceso, etc.
JCL tiene 18 tipos de sentencias distintas pero las más importantes y las que nos
interesan son: JOB, EXEC Y DD:
- JOB: Asigna un nombre al trabajo y suministra información de contabilidad.
Puede haber una por trabajo.
- EXEC: Ejecuta programas dentro de un JOB.
- DD: Data Definition. Define los recursos que va a utilizar el programa, por
ejemplo los ficheros.
Cada trabajo tiene asignado una clase de ejecución que establece unas prioridades en
la cola de ejecución.
Las sentencias de control de trabajos eran en un principio fichas perforadas, de ahí
que se llame trabajo por lotes al que se ejecuta bajo el control de del JES (subsistema
de ejecución de trabajos.)
Las sentencias JCL se incluyen en el fichero SPOOL en la cola de entrada.
(ver #JCLREPOS)
8.1. Ficheros
Seguimos trabajando con ficheros secuenciales. Definición de registros:
• Registros Lógicos: Es el que mejor se adapta al programa con el que estamos
trabajando.
• Registros Físicos: Es el que mejor le viene a la máquina con la que estemos
trabajando.
8.2. VTOC. Tabla de contenido del volumen.
La etiqueta de volumen en disco se encuentra en registro 2 de la pista 0. Contiene el
nombre del disco e información sobre dónde encontrar la tabla de contenido del
volumen (VTOC).
El VTOC es el equivalente de Mainframe a la tabla FAT en un computador personal.

Cáceres –
45
8.3. Ficheros Particionados: PDS.
Es una biblioteca para el OS-390 de ficheros secuenciales. Contienen cierto número
de miembros (ficheros secuenciales) y un directorio.
El directorio está situado en el comienzo del fichero y contiene una entrada para cada
miembro. Las entradas están ordenadas alfabéticamente por nombre de miembro.
8.4. Formas de localizar un fichero. Catálogos
Hay dos formas posibles:
1. En la descripción de la sentencias DD está el nombre del fichero y su ubicación
(unidad y volumen).
2. Por medio de un catálogo, que es un fichero que contiene el nombre de otros
ficheros y sus ubicaciones. En la sentencia DD hay un parámetro que se utiliza
para este propósito. Una vez creado un fichero, se puede almacenar
información sobre él en un catálogo. Siempre hay un catálogo disponible en
cualquier sistema, el denominando catálogo maestro, que es para ficheros del
sistema.
8.5. Lenguaje de Control de Trabajos. Sintaxis.
Campos de las sentencias JCL:
Identificador Nombre Operación Parámetros
// Campo delimitador de una sentencia, estando ambas barras en las dos
primeras columnas.
// * Continuación de una sentencia en la siguiente línea.
NOMBRES-SENTENCIAS: Han de ser como máximo 8 caracteres alfanuméricos más
#, @ y $, y no pueden comenzar por un número.
Cada sentencia JCL debe estar en mayúsculas.
8.6. Sentencia JOB
// NOMBREJOB JOB parámetros_posicionales: (p1,p2,p3) param_palabra_ clave, campo
contabilidad, programador
La sentencia JOB indica el comienzo de un trabajo e indica al sistema cómo
procesarlo. Es necesaria y debe ser la primera en cada trabajo.
Parámetros de palabra clave en la sentencia JOB:
MSGLEVEL(A,B)
Indica si se han de imprimir o no las sentencias de JCL y los mensajes de asignación
de recursos en el fichero de actividad del trabajo (job log).
A: Sentencias JCL. B: Mensajes
A: 0 JOB B: O NADA
1 JOB, EXEC, DD + procedim. 1 SMS, JES, RACF
2 JOB, EXEC, DD

Cáceres –
46
MSGCLASS
Asigna el fichero de actividad del trabajo a una clase de salida. (spool)
CLASS
Asigna el trabajo a una clase. CLASS=A Clase de Ejecución.
NOTIFY
Solicita que, cuando el trabajo finalice, el sistema envíe un mensaje al ID de usuario
de TSO especificado. NOTIFY=&SYSUID
TIME
Especifica la longitud máxima de tiempo durante la cual un trabajo o un paso de
trabajo utilizarán el procesador. El tiempo de procesador utilizado se indica mediante
mensajes. Con este parámetro podemos evitar que un proceso batch que se quede
bloqueado, ocupe recursos del sistema por un tiempo indefinido.
TYPRUN
Se usa para solicitar un tipo de procesamiento especial para el trabajo.
TYPRUN=SCAN.
RESTART
Se usa para rearrancar un trabajo, comenzando desde un paso especificado y saltando
los pasos anteriores o comenzando desde el punto de comprobación.
RESTART=NombrePaso.
REGION
Se usa para especificar la cantidad máxima de espacio de memoria que puede usar un
trabajo.
COND O IF/END/ELSE
Podemos establecer condiciones para que un trabajo se ejecute o no.
8.7. Sentencia DD
// NOMBREDD DD parámetros_posicionales parámetros_palabra_clave
Los programas referencian NOMBRESDD (definición de datos):
COBOL JCL
SELECT PEDIDOS //BE05R JOB CLASS=…
ASSIGN TO PEDIDOS //*
//INFPEDID EXEC PGM=DEMOPROG
//PEDIDOS DD DSN=PEDIDOS.DIC,DISP=SHR
//INFORME DD SYSOUT=X ( SPOOL)
//*
El NOMBREDD es un nombre lógico.
Un nombre de fichero (data set name es el nombre de un fichero físico (en cinta, disco,
etc).
La salida puede enviarse a un spool en lugar de enviarse a un fichero. La sentencia
DD establece el enlace entre un nombre de DD lógico y un fichero o spool físico.
Parámetros posicionales:

Manual de supervivencia Cobol

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Manual de supervivencia Cobol

Similar a Manual de supervivencia Cobol (20)

Último

Último (20)

Manual de supervivencia Cobol