Cuando adquirimos un compilador de Cobol, sin darnos cuenta a la vez estamos obteniendo un completo administrador de ficheros, algo que con otros lenguajes tienes que implementar con bases de datos u otras herramientas externas.
No voy a entrar en la polémica de que es mejor, si ficheros Cobol o Bases de datos, pero la experiencia me permite decir que la fiabilidad, seguridad y potencia de los ficheros es perfecta para nuestras aplicaciones de gestión.
La gran potencia sin duda, viene dada por los archivos indexados y será sobre ellos sobre los que gire prácticamente todo el tema, además con longitud fija. Los secuenciales se utilizan para la impresión y para determinados procesos de exportación de datos, pero cada uno es libre de utilizar el tipo de fichero que desee.
En la sección de Instrucciones relativas a ficheros tengo una pequeña explicación sobre lo que es un fichero y una clave y la voy a repetir aquí, porque nos viene muy bien para comprender perfectamente como se comportan.
¿Que es un fichero?
-
- Podríamos definir un fichero como un conjunto de registros, pero estaríamos mas o menos igual. Si comparásemos un fichero de cobol con nuestra vieja agenda de teléfonos, para cada amigo tendríamos los mismos datos, es decir, nombre, teléfono, dirección, etc … cada uno de esos datos es lo que llamamos campo y el conjunto de todos esos campos para cada amigo sería un registro. Ahora podemos comprender mejor que un fichero o archivo es un conjunto de registros, como una agenda es un conjunto de datos de amigos.
¿Que es una clave?
-
- Una clave, es un campo de nuestra agenda que nos sirve para identificar a cada amigo, en la agenda normal la clave podría ser la lengüeta con la letra del abecedario correspondiente a los apellidos del amigo. Informáticamente es mas completa y con ella podremos identificar a cada uno de ellos, por ejemplo con su nombre o su teléfono o un código que le asignemos nosotros personalmente.
Algunos tipos de ficheros indexados, dividen el fichero en dos archivos físicos, uno para las claves y otro para los datos, otros en cambio lo guardan todo en uno mismo, pero eso no significa que no lo haga igual, sino que al usuario solo le muestra un fichero físico, que puede resultar mas cómodo.
Cuando se graba un nuevo registro, éste se ordena automáticamente en orden ascendente por la clave principal. Luego podremos modificar tantas veces como deseemos los datos, pero la clave nunca se podrá alterar. Si queremos cambiar la clave, tendremos que borrar el registro y grabar otro con la clave deseada. De esa manera Cobol se asegura el perfecto funcionamiento de su sistema de índices.
La parte de índices es como una tabla con las posiciones de memoria de los datos que le corresponden. Si el fichero está abierto en modo I-O y se produce una salida brusca del programa o un corte de luz, puede ocurrir que esa información sobre los datos que corresponden a cada índice se alteren y de ahí el famoso y terrible error 98. Por eso yo siempre aconsejo tener nuestro fichero abierto solo como Input y abrirlo como I-O solo en el preciso momento de grabar o borrar su contenido.
Lo realmente importante para Cobol cuando crea un fichero, es el tamaño del registro y el de la clave en bytes. El resto le da igual, incluso la estructura se puede definir de maneras totalmente diferentes.
Para Cobol, si generamos un fichero con un registro de 128 posiciones, eso es lo que guarda, si nosotros le indicamos que el nombre ocupa 40 y comienza en la posición 18 perfecto, pero si la próxima vez le indicamos otra estructura el también la aceptará.
Un ejemplo, antes de entrar mas en materia:
| ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT FICHERO ASSIGN TO RANDOM «FICHERO.DAT» ORGANIZATION INDEXED ACCESS DYNAMIC RECORD KEY KEYAGE. DATA DIVISION. FILE SECTION. FD FICHERO LABEL RECORD STANDARD. 01 REGAGE. 02 KEYAGE. 03 CAMPOCODIGO PIC 9(4). 02 CAMPONOMBRE PIC X(30). 02 CAMPOPOBLACION PIC X(20). |
| Suponemos que CAMPONOMBRE = ‘UN NOMBRE CUALQUIERA’ CAMPOCODIGO = 1001 CAMPOPOBLACION = ‘UNA LOCALIDAD’Ahora en otro programa cambiamos la estrutura a por ejemplo: |
| FD FICHERO LABEL RECORD STANDARD. 01 REGAGE. 02 KEYAGE. 03 CAMPOCLAVE1 PIC 999. 03 CAMPOCLAVE2 PIC 9. 02 CAMPODATO1 PIC X(10). 02 CAMPODATO2 PIC X(15). 02 CAMPODATO3 PIC X(25). |
| Como veis, los tamaños son igual la clave sigue teniendo 4 y el registro 54 pero la estructura ha cambiado. Si ahora le decimos que nos displaye el mismo registro obtendríamos lo siguiente: CAMPOCLAVE1 = 100 CAMPOCLAVE2 = 1 CAMPODATO1 = ‘UN NOMBRE ‘. CAMPODATO2 = ‘CUALQUIERA ‘. CAMPODATO3 = ‘ UNA LOCALIDAD’.He puesto este ejemplo, porque muchas veces aprendemos las cosas tan literalmente que pensamos que cambiar algo puede provocar errores. |
CLAVES ALTERNATIVAS
Las claves alternativas, nos dan la posibilidad de acceder al fichero indexado por mas de un índice, con lo que la rapidez de acceso se incrementa muchísimo.
¿Por que son necesarias ?
Imaginemos un fichero de ventas, cuya clave es el número de factura, pero en su registro también guardamos la fecha, el cliente, el artículo, etc ….. Si ahora quisieramos listar todos los registros de ventas relativos a un solo clientes y no existieran las claves alternativas, tendríamos que leer todo el fichero para saber de que cliente es cada factura e imprimir solo esos registros.
Pues bien, con este tipo de claves lo que hacemos es posicionarnos directamente en el cliente en concreto y leer secuencialmente por esa clave, con lo cual tendremos una relación de todas sus facturas directamente hasta que el cliente cambie. En los ejemplos que pondré en esta sección intentaré que se vea todo esto.
En la actualidad, las claves alternativas se definen de manera diferente y no hacen la información redundante, es decir, antes, si creábamos una clave alternativa, había que implementar en el registro dicha clave, con lo que repetiamos los datos y hacíamos el registro de mayor longitud. Hoy en día eso no es necesario y las claves se pueden definir en la propia SELECT con lo cual evitamos la repetición de campos, espacio y además ganamos en comodidad, sencillez y comprensión.
Veamos que es lo que he dicho:
| ANTES:
|
| Fijaros como tenemos que repetir dos campos, ocupando mas espacio y teniendo siempre cuidado de que ambos estén actualizados a la vez.
|
| AHORA:
|
| Todo es mucho mas claro, la definición de los ficheros se asemeja mas a los relativos y en la SELECT es donde se describen las claves. Si la clave fuera compuesta, es decir con mas de un campo, haríamos lo siguiente:
RECORD KEY CLAVE = CODIGO, NOMBRE Si tuvieramos que hacer un START nos dirigiriamos por la palabra CLAVE, como ese conjunto de campos.
|
Aquí termina la primera parte del tema. Antes de continuar, es necesario tener claro todo lo aquí expuesto e igualmente si alguien tiene alguna queja o comentario al respecto que me lo haga llegar.
Siempre me gusta recordaros que yo soy un programador mas, al igual que vosotros y por lo tanto, con las mismas dudas, inquietudes y meteduras de pata.
Continuará…