Toda instalación host tiene sentido por la gran cantidad de datos que trata, por lo que en esta entrega explicaré como está distribuido el espacio de almacenamiento de un host y como se gestiona.
Al igual que en los PCs, el host dispone de Jerarquías de almacenamiento: La primera es la memoria principal o RAM, de acceso increíblemente rápido, la cual mueve el sistema, ya que un programa para ser ejecutado debe residir en esta memoria. Como es cara, este modelo de almacenamiento es finito y pequeño.
Además, tiene el inconveniente de que dicha memoria se borra si se deja de alimentar eléctricamente. Es por ello que surgió el modelo de almacenamiento auxiliar o secundario, mucho mas lento, pero cuyos datos perduran en el tiempo. Pues bien, el tocho de hoy se centrará en la disposición física de los datos en este tipo de almacenamiento.
Comencemos por las cintas, que son las más simples: Almacenamiento increíblemente barato, es EL soporte de almacenamiento elegido para contingencias o para migración de datos poco utilizados. Como ya expliqué en otra entrega anterior como se escriben físicamente los datos, vamos a abordar el aspecto lógico de tratamiento de los mismos.
Cuando inicializas una cinta, lo primero que hace es escribir el VOLSER o etiqueta de esa cinta en el primer registro, justo después de la marca física del BOT (Beginning Of Tape). Luego, los datos se graban por registros secuenciales de un tamaño que tú determines, dejando un IRG (Inter-Record GAP o zona sin escribir de un tamaño concreto) entre dichos registros. Ese IRG sirve de búsqueda secuencial de registros, y hace las veces del AMS de un Walkman de casetes, que te busca la siguiente canción porque entre canción y canción hay 3 segundos sin música y el Walkman detecta que la canción ha acabado.
Aquí sucede de manera similar. No se si habéis tenido la oportunidad de ver cintas de carrete antiguas funcionando, pero se ve como giran a gran velocidad, paran en seco, tiran un poco para atrás y luego vuelven a tirar para adelante, y todo esto ya digo que a toda velocidad. Pues eso es que ha leído el fin de un registro y que esta posicionando para leer el siguiente. Vamos, mecánico a tope.
Evidentemente, cuantos más registros haya, mas espacio desperdiciado en la cinta por los IRGs sucesivos, así que hay que saber que tamaño de registro se debe poner para evitar tantos IRGs. Pero claro, cuanto mas grande es el registro, menos entran, porque si el último que se graba en la cinta llega al EOT (marca de fin de cinta), ese registro no se graba y entonces si que has desperdiciado todo el final de cinta por ese registro a medio escribir… Así que es un tema interesante conocer muy bien la instalación y hasta cuanto puede dar de sí el almacenamiento.
Ahora, pasemos a hablar de los discos. En el mundo Host mainframe hay principalmente dos tipos de discos: FBA (Fixed Block Address), que son como los discos que tenemos en el PC, direccionables a sectores de 512 bytes de tamaño (es decir, que la unidad mínima de transferencia son 512 bytes), y por otro lado están los del tipo CKD (Count Key Data) o discos direccionables a pistas.
Pero el 95% de las instalaciones mundiales lleva discos CKD, y os diré por que: En un disco FBA de tu ordenador, editas con el Notepad un fichero y escribes “Hola” y lo salvas. Esos 4 bytes que ocupa el Hola, se escriben en disco, pero como el tamaño mínimo direccionable es un sector y dicho sector tiene 512 bytes, el fichero físicamente ocupa un sector, y claro, ahí nos quedamos con 508 bytes inutilizados a los que no podremos acceder. O imaginad que el fichero ocupa 513 bytes: pillará dos sectores de 512, y físicamente ocupara 1 KB, de los cuales 511 se han "perdido".
De hecho, podéis ver las propiedades de una carpeta grande de Windows, veréis que salen dos datos: Tamaño de la Carpeta y Tamaño en Disco (siendo el tamaño de disco siempre mayor, por el espacio desperdiciado de los sectores).
Si este tema lo extrapolas a instalaciones grandes, os podéis imaginar el posible derroche de información, máxime cuando en los años 60, 512 bytes era una burrada, así que se tenían que buscar soluciones super-óptimas para no desperdiciar ni un bit. Explicado esto, paso a comentar la disposición física de los discos CKD, que no tiene nada que ver con FBA.
Un sistema CKD es un sistema basado en Cilindros y Pistas. No hay sectores. En un disco modelo 3390 por ejemplo, cada pista contiene 56.664 bytes y los registros se graban jerárquicamente.
Cada registro que se va a grabar, tiene 3 campos: Cuenta, Clave y los Datos. De ahí que las búsquedas físicas de registros se hagan a unas velocidades asombrosas, ya que estos sistemas tienen una FAT muy muy elaborada con unas jerarquías de almacenamiento determinadas y trabaja con heurísticas de búsqueda muy bien diseñadas.
Ya, pero… ¿Y si quiero grabar o leer algo? Bueno, no nos impacientemos. Para empezar, deberíais decirme que quieres grabar y como. Porque, al contrario que con los PCs, que o tienes ficheros o tienes carpetas o enlaces simbólicos, un host maneja ficheros secuenciales, particionados, VSAM, etc. Y cada uno tiene su tema. Un fichero (en adelante, DataSet) secuencial, es un dataset cuyos registros solo se pueden leer de manera consecutiva. Si, porque un dataset tiene dentro registros, y dentro de cada registro, campos de datos.
En cambio, un PDS (dataset Particionado), en su interior tiene miembros, y dentro de cada miembro tiene registros. Esto se parecería a una carpeta de PC con ficheros en su interior y cada fichero fuera una base de datos.
Un fichero VSAM es un fichero virtual con una parte de índices y otra parte de datos, y es el precursor de las bases de datos. Hasta los años 70, que se desarrolló el DB2, todo dato se almacenaba en ficheros VSAM que hacían las veces de tablas con índices primarios, alternativos, campos con datos, etc. Comentar la estructura interna de un VSAM es muy tema muy interesante, pero necesitaría hacer otro documento (aunque ya sabéis que bajo petición popular os escribo lo que sea y sepa).
Una vez creado un dataset, con el tamaño de ese dataset (si, primero hay que hacer un "allocate" o reservar ese espacio que va a ocupar) y decirle el tamaño de bloques que va a usar, tamaño de registro y demás, el Sistema Operativo z/OS lo que hace es catalogarlo, es decir, añade una entrada en el catálogo para facilitar la búsqueda.
Decir que hay dos tipos de catálogos: El Master Catalog o catálogo del sistema, donde están catalogados los datasets del SO, y los user catalogs o catálogos de usuario, que pueden ser muchos y variados que es donde se catalogan el resto de los datasets, como nuestros datos, por ejemplo. Estos catálogos de usuario dependen del Maestro, y se organizan de una forma jerárquica, dando una rapidez de búsqueda increíble (sí, ya se que me repito).
Si un dataset no se cataloga, no pasa nada, lo que ocurre es que para buscar dicho dataset le tienes que decir el nombre del mismo y el VOLSER de disco o cinta donde reside (y teniendo en una instalación media, 1024 volúmenes de disco es algo complicado), por lo que el catalogo te ahorra que le digas el volumen donde reside y luego, las búsquedas son mas rápidas y fáciles. Uhmm, podría ser algo como el Index Server... o como hacer un find... uhm... no, se parecen poco.
Decir también que cuando grabamos un dataset a cinta, ese dataset también se puede catalogar para saber en que cinta se escribió y facilitar la búsqueda (y con imaginaros el volumen de cartuchos que maneja una instalación media, con robots que almacenan decenas de miles de cartuchos comprenderéis la importancia y necesidad de los catálogos y del cristo que supondría no poder acceder a un catalogo o que dicho catalogo se pueda corromper -- que alguna vez me ha pasado --).
Cuando quiero grabar un dataset a disco o a cinta, debo decirle con que nombre grabarlo. Aquí no hay carpetas, por lo que es como si todos los datasets estuvieran siempre en la raíz del disco.
Por ello, se desarrolló un sistema de nomenclaturas para facilitar la ordenación de esos miles de millones de datasets que pueden conformar nuestra instalación.
Un dataset puede tener 42 caracteres de largo como máximo, en grupos de 8 caracteres separados por puntos. Un típico nombre de dataset podría ser SYS1.PARMLIB o KUJAKU.YGDRASIL.PROD.JOBS.
El primer nombre (SYS1 o KUJAKU en los ejemplos) se le llama HLQ (High Level Qualifier) y es como un índice dentro del sistema que sirve para que un catálogo pueda direccionarlo. El HLQ SYS1 del ejemplo, es un fichero de Sistema y por lo tanto, el Master Catalog contendrá la información para buscar todo lo que empiece por SYS1.
Para evitar comernos marrones de cientos de miles de ficheros, se suelen crear catálogos de usuario que busquen cada uno por HLQ, en lugar de tenerlos todos en el Master Catalog. El proceso sería el siguiente: Si busco por KUJAKU, esa petición realiza una consulta al Master Catalog. El Master Catalog se da cuenta de que tiene un puntero a un catalogo de usuario que cataloga todo lo que empieza por KUJAKU (porque a mi me ha dado por crearlo así, ya os digo que para este tipo de cosas se pueden personalizar al máximo), así que se va a buscar a ese catalogo de usuario y devuelve el dataset (o la lista de datasets que empiecen por KUJAKU) y el volumen donde reside para poder empezar a trabajar con él. Sencillo, ¿no?.
En fin, creo que por hoy ya es suficiente también. Hemos pasado por explicar disposiciones de ficheros, tipos que hay, y como se almacenan. En la próxima entrega, a ver si me animo a explicaros como arranca un mainframe desde que enciendes el botón hasta que ves el login en la pantalla.
Comentarios