Trabajando con ficheros SAVF y Transferencia FTP

El presente articulo explica algunos procedimientos de cómo trabajar con ficheros SAVF y operar con ellos, haciendo transferencias y demás entre equipos.

Un fichero SAVF es un tipo de fichero de salvado de datos, como si fuera un ZIP en Windows o un TAR en Unix, solo que este tipo de ficheros se dan entre equipos AS/400. El concepto de copia a cinta es el mismo, solo que un fichero SAVF se graba a disco en vez de a cinta. Lo bueno es que se puede crear un fichero SAVF desde un conjunto de bibliotecas o incluso incluirlo dentro de una copia completa de todo el sistema, ya que esta opción, si se dispone del disco suficiente, es mucho mas rápida que un salvado tradicional a cinta.

Crear un fichero SAVF y salvar una Biblioteca

Si tenemos una biblioteca que queremos salvar a un fichero SAVF, basta con ejecutar los siguientes pasos:

1.- Creamos un archivo de salvar SAVF llamado MIFICHERO dentro de la QGPL con el comando CRTSAVF FILE(QGPL/MIFICHERO).

2.- Con el fichero creado, la idea es salvar la biblioteca que necesitemos salvar, por ejemplo, la biblioteca MILIBRERIA, con el siguiente comando:

SAVLIB LIB(MILIBRERIA) DEV(*SAVF) SAVF(QGPL/MIFICHERO)

Con esto, tendremos un fichero de salvar cuyo contenido sea una biblioteca y todos sus objetos.

Sacar un fichero SAVF del AS/400 y transferirlo al PC

Para ello, lo más sencillo es utilizar el comando FTP. Por tanto, nos conectaríamos con un cliente sencillo de FTP por línea de comandos (el propio FTP del Windows nos vale) y haríamos los siguientes pasos:

1.- Abrir una ventana de Windows (cmd)

2.- Escribir ftp 192.168.1.200 (siendo 192.168.1.200 la IP de nuestro AS/400)

3.- Introducir el nombre de usuario y contraseña de un usuario autorizado del AS/400 (por ejemplo, QSECOFR)

4.- Entrar dentro del directorio QGPL con un cd qgpl

5.- Escribir bin para cambiar el modo de transferencia de modo texto a Binario

6.- Escribir QUOTE SITE NAMEFMT 1 para pasar de modo Biblioteca a modo Fichero -luego explico por que-.

7.- Para recibir el fichero hacer un get mifichero.savf

8.- Una vez recibido, hacer un quit para salir del ftp del sistema.

El modo SITE NAMEFMT es un tipo de nomenclatura que se da al AS/400 para las transferencias tradicionales de AS/400. Por defecto, esta en modo NAMEFMT 0, lo que significa que esta en modo “biblioteca”. En este estado, en el FTP podriamos haber hecho simplemente un get mifichero pero claro, en el PC te lo deja tal cual, sin extensión. Si internamente sabes que ese fichero es un SAVF perfecto, pero luego suelen surgir problemas si ese fichero lo subimos al AS/400, ya que el sistema detectara un fichero tipo FILE con atributo PF-DTA y no un FILE con atributo SAVF que es como deberia ser.

Por tanto, es interesante dotar a todas nuestras transferencias antes el comando QUOTE SITE NAMEFMT 1, ya que en modo 1 es en modo “directorio” y si haces el get de mifichero.savf, con extensión, el sistema ya sabe de que fichero se trata. Y claro, si ese fichero lo vuelves a subir al AS/400, con el NAMEFMT a 1 haces que la extensión SAVF la detecte y entonces el AS/400 crea el fichero SAVF como lo debe crear, es decir como FILE con atributo SAVF.

Por tanto, recomendacion: SITE NAMEFMT siempre a 1.

Transmisión de un fichero SAVF al AS/400

Para transmitir un fichero al AS/400 desde nuestro PC, usaremos el FTP:

1.- Abrimos una ventana de comandos de Windows

2.- Escribiremos ftp 192.168.1.200 (siendo 192.168.1.200 la IP de nuestro AS/400)

3.- Introduciremos el nombre de usuario y contraseña autorizados

4.- Escribiremos cd qgpl para situarnos en esa biblioteca por defecto

5.- Escribiremos QUOTE SITE NAMEFMT 1 para cambiarnos al modo de “directorios” (como hemos explicado).

6.- Escribiremos un bin para poner el modo de transferencia en binario

7.- Haremos un put mifichero.savf para cargar al AS/400.

8.- Opcional: Si queremos “descomprimir” el contenido del fichero SAVF que acabamos de subir, introducir el siguiente comando: QUOTE RCMD RSTLIB SAVLIB(MILIBRERIA) DEV(*SAVF) SAVF(QGPL/MIFICHERO) para que el contenido de ese fichero lo dejemos en la biblioteca MILIBRERIA (debemos tener los privilegios de acceso suficientes, primero para hacer un Remote Command (RCMD) y luego para poder restaurar).

9.- Con un quit, nos saldremos de la máquina.

NOTA: Si hacemos un SAVLIB con un parametro llamado TGTRLS podemos salvar un fichero para que pueda ser leido por una versión anterior del SO en otra máquina diferente, aunque solo mantiene una compatibilidad hacia atras de 2 versiones (un salvado en V6R1M0 puedes restaurarlo en un V5R3M0, pero no en anteriores). Tambien hay que tener cuidado, porque no siempre se pueden salvar todos los programas (sobre todo, aquellos que son RPG compilados para una version del SO en concreto).

Personalizando el sistema (QINTER Y QBATCH vs QBASE)

En esta entrega, explicaré un poco cómo personalizar el sistema, sobre todo en el modo de trabajar de la maquina. Tenemos la maquina recién instalada, pero no la tenemos ajustada como para ponerla en producción, ya que todos los valores son “por defecto” y no siempre sirven para nuestros propósitos (todo depende de la problemática de cada instalación).

Lo primero de todo, es comprobar el Subsistema de Control. En tiempo de instalación, este subsistema se llama QBASE, y engloba tanto los procesos de terminales interactivos como los trabajas Batch que queramos lanzar. En función de cada caso, quizás interese que los trabajos Batch no afecten al rendimiento interactivo, por tanto es necesario disponer de otro modo de funcionamiento que permita separar estos entornos. Esto es llevado a cabo por dos subsistemas que también existen en el iSeries, pero que se encuentran inactivos (porque por defecto se arranca el QBASE), que son QINTER para los trabajos interactivos y QBATCH para los trabajos Batch o de proceso por lotes.

Este método de funcionamiento esta controlado por el valor del sistema QCTLSBSD, que, si entramos con WRKSYSVAL y buscamos el valor QCTLSBSD, veremos que esta en QBASE, como en el ejemplo de la siguiente figura.

Fig. 1: Valor del Sistema QCTLSBSD

Para cambiar el modo de trabajo a dos subsistemas separados QBATCH y QINTER, basta con cambiar el valor QBASE de nuestra variable QCTLSBSD y poner en su lugar QCTL, como en la siguiente figura:

Fig. 2: Cambio de QBASE a QCTL

Por tanto, en la próxima IPL del sistema, el sistema QBASE no arrancará, pero sí lo harán los subsistemas QINTER y QBATCH.

Pero no nos detendremos aquí, vamos a personalizar todavía mas el tema: En ciertas empresas, existe el hecho de que sus terminales esta “personalizados” con el logo de la empresa, o lo que se tercie, abandonando el clásico y sobrio terminal verde de Inicio de Sesión. Por tanto, si es nuestro caso, y queremos que el usuario arranque el terminal y le aparezca el logo de la empresa en vez del clásico inicio de sesión, haremos lo siguiente:

1.- Utilizando el editor de pantallas que mas nos guste (en mi caso, me gusta el CODE400), utilizaremos el fuente de pantalla QDSIGNON que reside dentro de QDDSSRC en la biblioteca QGPL, y haremos una copia de dicho miembro en una biblioteca de trabajo nuestra, con un nombre distinto, como por ejemplo, QINTERSIGN.

2.- Este fichero lo editaremos, teniendo cuidado de no borrar los campos obligatorios y necesarios de la pantalla de inicio de sesión. Una vez visto el resultado, lo compilaremos, dejando el código objeto compilado en una biblioteca que hayamos creado (por ejemplo, SISTEMAS).

3.- Comprobaremos que funciona bien la pantalla, si desde el PDM, ponemos un 5 delante del miembro QINTERSIGN (Visualizar), e introducimos los valores por defecto, con lo que la pantalla se quedaría con una imagen similar a la siguiente:

Fig. 3: Aspecto final de archivo de pantalla QINTERSIGN

4.- Para asignar esta pantalla de inicio de sesión personalizada al subsistema QINTER, de forma que todo terminal que se conecte a él la visualice, ejecutaremos el mandato CHGSBSD SBSD(QINTER) SGNDSPF(SISTEMAS/QINTERSIGN) que hará cambiar la pantalla de inicio de sesión por defecto a la que hemos creado nosotros.

Para ver los cambios, basta con reiniciar el subsistema QINTER y ver que a partir de ahora, todo terminal que se conecte, tendrá esa nueva pantalla de inicio de sesión.

Hasta aquí de momento. Próximamente más, damas y caballeros.

Trabajando con Catálogos Virtuales en AS/400

En el mundo AS/400, hemos tenido una serie de vivencias a lo largo de los mantenimientos de las máquinas, que nos han hecho recopilar una grandísima cantidad de información en soportes de almacenamiento de CDs. Aun recuerdo los 25 CDs de servicios correctivos cumulativos (o PTFs) de cada versión del Sistema Operativo, con la cantidad de horas que se tardaba en cargar todo eso, mas luego todo el tiempo que se tiraba aplicando los susodichos parches o PTFs. O aun hoy, los 19 CDs de los que se compone la versión V5R4M0 del Sistema Operativo, y estamos hablando de un sistema operativo del año pasado…

Pues se acabó el hacer de disk-jockey. Desde la versión del Sistema Operativo V5R1M0, primero para hacer upgrades, y ya desde la versión V5R2M0 y con soporte completo incluso de escritura en la V5R3M0, existe la posibilidad de crear Catálogos Virtuales de Imágenes de CDs.

Que es un Catálogo Virtual de Imagenes?

Un Catálogo Virtual de Imágenes es una herramienta software, que, entre otras cosas, te permite cargar imágenes ISO de los CDs o DVDs de manera sencilla, de tal forma que te habilita crear un “JukeBox” o cargador de CD (como los de los coches), con tantas ISOs quieras que el sistema te leerá bajo petición. Para ello, antes crearás un dispositivo óptico virtual al que podrás asociarles un catálogo de imágenes concreto, y ese catálogo en su interior tendrá tantas ISOs como necesites. También puedes crear multitud de catálogos virtuales y cargarlos según te convenga.

Ya, bueno, pero para que sirve?

Lógicamente, crear un dispositivo virtual y varios catálogos de imágenes te permiten prescindir de los CDs y DVDs para siempre en soporte plástico. Por ejemplo, si necesitas cargar un conjunto cumulativo de PTFs, antes tenías que introducir y sacar CDs de la unidad de CD a medida que el sistema te los pedía, dando lugar a tensas esperas y sobre todo estar pendiente de los mensajes de consola cuando tocaba cambiar de CD para introducir el siguiente en secuencia o aleatoriamente. Ahora, todos esos CDs los puedo subir a los discos del AS/400 como ISOs, y puedo crear un catálogo de PTFs con esas 27 o 50 ISOs, y hacerlo disponible (cargarlo) en un soporte óptico virtual.

De esta forma, cuando quiera aplicar las PTFs, no tengo mas que decirle que las PTFs se encuentran en ese dispositivo virtual (en vez de en el tradicional OPT01 si es un CD, o TAP01 si están en cinta) y el sistema ira leyendo toda la información como le convenga, montando automáticamente las ISOs que necesite, de manera totalmente automática y sin intervención humana.

Además, no es lo mismo leer de un CD que leer directamente del disco ASP del sistema, por lo que la carga de las PTFs se haría con mucha rapidez.

Menuda pasada, no?

Pues si, pero evidentemente, surge un inconveniente: Es necesario espacio en disco para almacenar todas esas ISOs. Si el sistema tiene poco espacio disponible, no podríamos cargar todas las ISOs que nos gustarían, pero en mi experiencia eso no es demasiado problema, ya que en las instalaciones medianas en las que he trabajado, con un cambio de maquina, un sistema que tenia 20 o 30 GB de uso, con los nuevos discos de 300 GB que vienen con la máquina “por defecto”, pues te permite jugar con todo ese excedente de espacio para crear catálogos virtuales variopintos.

A titulo personal, me gusta tener un catálogo de imágenes con las imágenes en ISO de los DVDs del Sistema Operativo (unos 10 GB), de tal forma que si en un futuro quiero instalar una aplicación y necesita un pre-requisito que no he instalado en la instalación inicial del sistema, lo puedo hacer cuando quiera, simplemente por comodidad. Y por otro lado, tener uno o más catálogos de PTFs cumulativas. Más o menos cada 3 meses suelo conectarme a la Web de IBM Fixcentral y me suelo bajar en formato electrónico (es decir, en ISO o BIN, pero que son lo mismo) las últimas PTFs cumulativas que han salido para la release de mi Sistema Operativo. Las subo al iSeries y creo un catálogo con todas esas ISOs, y así, el día que actualice, tendré todo lo necesario para hacerlo desatendidamente y automáticamente. Y siempre guardo los catálogos antiguos por si acaso, habiendo espacio de sobra, no molestan, pero no guardo mas de dos catálogos de PTFs a la vez para que así la ventana de backup de la opción 21 no me suba demasiado.

Bien, y cuales son los pasos a seguir para tener mi catálogo?

Voy a utilizar como ejemplo, el catálogo que me crearé para los DVDs del Sistema Operativo. Lo primero, es tener las ISOs en tu PC, listas para subirlas al iSeries. Yo, las subo al IFS directamente, creando una carpeta llamada /OS y luego dando permisos para  compartirla (todo esto dentro de System i Navigator del iSeries Access for Windows).

Una vez subidas las ISOs, crearemos un dispositivo óptico virtual con el siguiente mandato:

CRTDEVOPT DEVD(OPTVRT01) RSRCNAME(*VRT)

Así que si vamos a ver la pantalla de trabajar con descripción de dispositivos (WRKDEVD), debería aparecernos el dispositivo recién creado.

Este dispositivo será el que gestionará enlazar los catálogos de imágenes, y poder así cargarlos.

Ya que estamos, pondremos On-line el dispositivo con el siguiente mandato:

VRYCFG CFGOBJ(OPTVRT01) CFGTYPE(*DEV) STATUS(*ON)

Ahora, el sistema ya es susceptible de ser leído por el iSeries cuando se lo pidamos.

Fig. 1: Dispositivo OPTVRT01

Una vez creado el dispositivo óptico virtual, procederemos a crear un catálogo de imágenes. Como vamos a crear varios en un futuro, vamos a darle un nombre significativo para saber que ISOs contendrá dicho catálogo, por ejemplo, OSV6R1M0 (porque contendrá el Sistema operativo V6R1M0), y le diremos donde están las ISOs que luego enlazaremos, así que introduciremos el siguiente mandato:

CRTIMGCLG IMGCLG(OSV6R1M0) DIR(‘/OS’)

Con este paso realizado, solo nos falta añadir las imágenes ISO de la carpeta dentro del catálogo. Para ello, tan sencillo como introducir un mandato por ISO a añadir:

ADDIMGCLGE IMGCLG(OSV6R1M0) FROMFILE(‘/OS/B2931_01.ISO’)  TOFILE(*FROMFILE)

Esto añade el primer DVD del SO. Cabe destacar que si no se pone el parámetro TOFILE, es decir, que el parámetro por defecto de TOFILE es *GEN, el sistema crea un nuevo fichero con el mismo tamaño pero su extensión es .ISO01. Esto lo hace para indexarlo en el catálogo, por lo que una vez cargada dicha ISO en el catálogo, nuestro fichero ISO se puede borrar, ya que el sistema utilizará a partir de este momento el que tiene extensión ISO01. De hecho, esto se suele utilizar para pasar de un DVD real a ISO, pero como en nuestro caso, la ISO ya está creada, pues con el TOFILE(*FROMFILE) te evitas crear un fichero adicional.

Con el mandato siguiente, añadiremos el segundo DVD del SO a nuestro catálogo

ADDIMGCLGE IMGCLG(OSV6R1M0) FROMFILE(‘/OS/B2931_02.ISO’)  TOFILE(*FROMFILE)

Y por ultimo, el DVD de programas diversos lo cargaremos así:

ADDIMGCLGE IMGCLG(OSV6R1M0) FROMFILE(‘/OS/F_MULTI_NLV.ISO’)  TOFILE(*FROMFILE)

Si ahora, introducimos el mandato WRKIMGCLGE IMGCLG(OSV6R1M0) podremos apreciar de acuerdo a la siguiente figura que el catálogo esta cargado y las ISOs enlazadas correctamente:

Fig. 2: Trabajar con entradas en el catálogo de imágenes

Como habéis visto en la captura de pantalla, el estado está en No preparado. Esto significa que el catálogo de imágenes no esta asociado a ningún dispositivo óptico virtual. Esto es perfectamente normal, solo que en el momento que queramos utilizar este catálogo para leerlo en el sistema, antes tendremos que cargarlo en nuestro dispositivo óptico virtual llamado OPTVRT01 creado al principio. Para ello, ejecutaremos el siguiente mandato:

LODIMGCLG IMGCLG(OSV6R1M0) DEV(OPTVRT01)

Por último, podéis comprobar que una vez cargado, el dispositivo esta preparado y el primer volumen ISO esta montado, es decir, que es como si hubiéramos metido dentro de la unidad de DVD el primero de los 3 DVDs.

Fig. 3: Catálogo montado y cargado

A partir de este momento, podemos leer el dispositivo OPTVRT01 con la información de todo el Sistema Operativo, a velocidades de disco duro. Con el mandato WRKOPTVOL, vemos según la siguiente figura que el CD ISO introducido en la unidad virtual es el B2931_01.

Fig. 4: Trabajar con volúmenes ópticos

Y todo esto se puede hacer con PTFs, con programas producto, en fin, con lo que se os ocurra. Se acabó estar esclavizado del CD del AS/400!

Instalación de i5/OS V6R1 en un Blade JS12

En artículo de hoy lo dedicaré a explicar como instalar desde cero el Sistema Operativo que corre en los equipos AS/400. Aunque los ejemplos hacen referencia a la oblea JS12, vale cualquier máquina con procesador POWER5 o POWER6, ya que el proceso es siempre el mismo.

A continuación, con todos los elementos disponibles a nuestro servicio, procederemos a realizar la instalación básica del sistema i5/OS (antes llamamdo OS/400), versión 6 Release 1. Para ello, lo primero que hacemos será iniciar la partición desde el portal VIOS y asegurarnos de tener el DVD asignado al JS12, y, por supuesto, el primer DVD de instalación del i5/OS preparado e introducido ( I_BASE_01 ). Y seguiremos los siguientes pasos:

1.- Al iniciar la partición, la debemos iniciar el modo D Manual, para que lea el DVD. Para ello, nos iremos a Propiedades y marcaremos la opción correspondiente. Al de un rato, veremos como lee el DVD esporádicamente y los códigos de referencia pasaran de C1XXYYY a C6XXYYYY, hasta lanzarse la consola de operaciones (una vez introducidos el usuario 11111111 y password 11111111) las figuras siguientes:

i5os01

Fig. 1: Arranque de la partición iSeries

i5os02

Fig. 2: Elección de la característica del idioma

i5os03

Fig. 3: Confirmación de la característica del idioma

2.- En esta figura, elegiremos la opción 1. Instalar Código Interno Bajo Licencia y daremos a Intro.

i5os04

Fig. 4: Instalar Código Interno bajo licencia

3.- A continuación, nos detecta el disco “hdisk3” que ha encontrado como candidato para instalarse. La siguiente opción es pulsar 1 para seleccionarlo y pulsar Intro:

i5os05

Fig. 5: Elección del disco destino del SO

4.- El siguiente paso es elegir la opción 2. Instalar Código Interno Bajo Licencia e Inicializar el Sistema y el sistema formateará el disco y posteriormente instalará el LIC, tal y como muestran las figuras siguientes.

i5os06

Fig. 6: Menú de Instalación del LIC

i5os07

Fig. 7: Confirmar el borrado del disco y la instalación del SO

i5os08

Fig. 8: Formato del Disco

i5os09

Fig. 9: Progreso de instalación del LIC

5.- Una vez terminado, el sistema reiniciará, arrancando en modo A Manual, y al cabo de unos minutos, nos aparecerá una advertencia, la cual aceptaremos pulsando PF10:

i5os10

Fig. 10: Nueva configuración de discos

6.- Una vez aceptada, llegaremos al menú DST. En este menú, directamente elegiremos la segunda opción, 2. Instalar el Sistema Operativo y pulsaremos Intro.

i5os11

Fig. 11: Menú inicial IPL

7.- En esta pantalla, seleccionaremos el medio de instalación, que, en nuestro caso, será desde 2. Medio óptico, y daremos a Intro, para luego volver a confirmar la instalación dando otra vez a Intro.

i5os12

Fig. 12: Elección del medio de instalación

i5os13

Fig. 13: Característica del Idioma de instalación

9.- En estos momentos, comenzará la instalación del sistema operativo. Si no hemos cambiado el CD I_BASE_01 por el DVD B2931_01, nos aparecerá una pantalla de advertencia, pidiendo un cambio en el CD. Una vez hecho el cambio, proseguirá la instalación.

10.- Antes de comenzar la copia de ficheros, aparecerá la siguiente panatlla, la cual rellenaremos con valores por omisión e introduciremos la fecha y la hora.

i5os14

Fig. 14: Elección de instalación y opciones

i5os15

Fig. 15: Progreso de instalación

11.- Durante el proceso, nos pedirá entrar dentro del sistema, por lo que utilizaremos el usuario QSECOFR (sin contraseña). Una vez dentro, nos pedirá introducir de nuevo datos de fecha, y características de arranque de transcriptores, etc. Dejaremos  los valores por defecto y pulsaremos Intro.

i5os16

Fig. 16: Inicio de Sesión

i5os17

Fig. 17: Opciones IPL

12.- Como hemos dejado la opción por defecto Establecer Opciones Principales Sistema en Y, la siguiente figura nos preguntará que opciones queremos establecer. Dejaremos las opciones por defecto.

i5os18

Fig. 18: Establecer Opciones Principales del Sistema

13.- La instalación continuará hasta que al final, nos aparezca por fin, la pantalla de Inicio de Sesión. En ella, nos conectaremos como usuario QSECOFR y password QSECOFR.

i5os19

Fig. 19: Progreso de la Instalación

14.- Evidentemente, la contraseña QSECOFR es la de por defecto, así que el sistema considerará que ha caducado, y por lo tanto, se debe cambiar. Por tanto, elegiremos nueva contraseña. Una vez hecho esto, llegaremos al menú para aceptar los acuerdos de licencia. Y, una vez elegido el acuerdo, y dado al PF15 (aceptar todo), llegaremos al menú principal i5/OS.

i5os20

Fig. 20: Cambio de contraseña QSECOFR

i5os22

Fig. 21: Trabajar con Acuerdos de Software

i5os23

Fig. 22: Menú Principal i5/OS

En este punto, tenemos un sistema que arranca, pero sin ningún producto instalado. Así que en otro artículo, explicaré como se instalan los productos adicionales.

Instalación de un Blade JS12 en un BladeCenter H

Inauguro sección!! En mi experiencia, me ha tocado tratar con muchas arquitecturas, pero rara vez he tenido tiempo para documentarlas y tratar de arrojar algo de luz sobre otras arquitecturas en las que he trabajado muchos años. Así que, para tratar de remediar esto, voy a empezar a escribir mis vivencias con un mainframe venido a menos, el AS/400 (ahora conocido como IBM System i).

Y, que mejor forma de inaugurar la sección, escribiendo un artículo sobre como se instala un nuevísimo iSeries, modelo “Blade”?

Así pues, alla vamos:

Yo siempre he sido de mirar máquinas y decir “ande o no ande, caballo grande”, así que cuando me encuentro cara a cara con este trasto que es como una carpetita de grande, empiezo a desconfiar.

Y no es para menos: Esta máquina se va a pinchar en un BladeCenter H, con una cabina de discos DS4700, fiber-channel por supuesto, a 4 Gbps, y sobradísima para el cliente, pero, claro, el cliente quiere disponer de copia de seguridad tradicional, nada de hacer SAVFs y librerías virtuales, ni nada, el quiere seguir haciendo un SAVE opción 21 en una cinta LTO. Así que, la primera en la frente: La UNICA unidad de cinta certificada para un JS12 es una IBM TS2340, unidad “tabletop” LTO4 con un conector SAS la mar de majo, pero incompatible con el sistema fiber-channel (o al menos, haciendo carísima la convivencia entre los dos, porque habría que añadir módulos de expansión en el BladeCenter adicionales, lo que hace que la solución suba muchisimo de precio).

Solución: Sustitución de la cabina DS4700 por una DS3200, con conectividad SAS, muchisimo mas económica, y añadiendo controladoras SAS al Blade, haciendo que la cabina pueda ser vista por la JS12 y pudiendo conectar la unidad de cinta a la misma red SAS. Bueno, podría haber sido peor, la DS3200 no es tan mala, y para las cargas que necesita el cliente, pues va estupendamente.

Una vez modificadas las configuraciones oportunas, me encuentro frente a frente con la máquina. Así que empiezo:

La máquina dispone de 4 GB de RAM de base, 1 procesador POWER6 y con respecto a las comunicaciones, dispone de dos tarjetas SAS de 3Gbps para almacenamiento y 2 tarjetas de red de GbE. También dispone de dos discos de 73 GB internos, con configuración en mirror (que luego habilitaremos), para albergar el sistema operativo VIOS (Virtual I/O Server).

Este sistema es necesario, de lo contrario, no se podría realizar ninguna instalación del OS/400 (perdón, queria decir i5/OS). Segunda en la frente, el sistema tiene un supervisor basado en AIX por encima, que, aunque muy flexible si se van a crear particiones o LPARes, para nuestro caso que solo irá una instancia i5/OS es un poco tontería, pero como la JS12 es obligatorio ponerlo, pues… a instalar el VIOS.

Instalación VIOS

Una vez cargado el DVD en el Blade, y asignado a la oblea JS12, éste arrancará un sistema VIOS basado en AIX. Los pasos a seguir son los siguientes:

js1201

Fig. 1: Arranque Oblea JS12

1.- Entraremos en el menú 1 = SMS Menu, pulsando un 1, y una vez dentro, elegiremos 5. Select Boot Options. Allí, elegiremos 1. Select Install/Boot Device3 CD/DVD, con lo que a continuación, elegiremos 6 USB y confirmaremos con 1 USB CDROM. Nos preguntará el modo de arranque y elegiremos 2 Normal Mode y 1 Yes para salir de todas las opciones del SMS. Por tanto, reiniciará y tardará unos 5 minutos en cargar el software de nuevo.

2.- Nos aparecerá una pantalla IBM llamada STARTING SOFTWARE (Fig. 2) y al de un rato, deberemos elegir la consola pulsando un 2 y dando a Enter. Lo siguiente es elegir el idioma, por lo que daremos a la opción adecuada y daremos a Enter.

js1202

Fig. 2: Arrancando Software

3.- En el menú Welcome to BOS, elegiremos Change/Show installation Settings and Install, y pulsaremos un 2 para verificar que los discos elegidos son los correctos. Los discos internos deberian ser hdisk0, y hdisk1, y si hay LUNs mapeadas, deberian ser hdisk2, hdisk3, etc. Si la elección es hdisk0, esta correcto, por lo que confirmaremos la instalación con la opción 0. Esto hará comenzar la instalación del VIOS.

4.- Una vez finalizada la instalación, el sistema reiniciará y al cabo de un rato, aparecerá en pantalla el prompt Login: el cual deberemos entrar con el usuario padmin (sin contraseña). Por tanto, la siguiente elección será la de introducir la contraseña. Una vez realizado ese paso, teclear license –accept para aceptar la licencia VIOS.

5.- Lo siguiente es configurar el mirroring de los discos, con el fin de que la partición VIOS este segura en caso de rotura de uno de los discos. Por tanto, y teniendo en cuenta que el disco hdisk1 es el otro disco dentro de la oblea, los comandos a introducir son los siguientes:

chsp –add hdisk1

mirrorios –f –defer hdisk1

(la opción defer es para hacerlo al final, por lo que es mejor reiniciar la partición VIOS).

6.- Para comprobar que se ha mirrorizado bien, introduciremos los comandos siguientes:

lsvg –lv rootvg : Deberían aparecer 2 PVs en vez de 1.

bootlist –mode normal –ls : Deberían aparecer 2 discos, el hdisk0 y hdisk1

7.- Para terminar con la consola, configuraremos las comunicaciones. Para ello, comprobaremos que disponemos de dos tarjetas de red, la ent0 y la ent1. Para comprobarlo, realizaremos un lsdev | grep hea y nos deberían aparecer la dos tarjetas. Por tanto, para configurar la tarjeta ent0, realizaremos el siguiente comando:

mktcpip –hostname VIOS –inetaddr 10.1.1.20 –interface en0 –netmask 255.255.255.0 –gateway 10.1.1.100 –nsrvaddr 10.1.1.100 –nsrvdomain dominio.com –start

Para comprobar que todo funciona bien, haciendo un lstcpip –stored deberíamos comprobar que los datos introducidos están correctos. Y, realizando un ping desde una máquina externa a nuestra IP, deberíamos llegar a ella. Y, por último, veremos si nos podemos conectar con navegador, para ello en el navegador de una máquina externa, introduciremos la URL http://10.1.1.20. Si vemos una imagen como la de la figura siguiente, todo estará perfecto.

js1203

Fig. 3: Interfaz de Administración VIOS


Instalación de Parches VIOS

Conociendo un problema con la bandeja USB de CD-ROM, que al parecer, dicha bandeja se “desconecta” cuando estas instalando el i5/OS, se ha instalado un Fixpack que previene el problema. Los pasos de instalación del Fixpack, han sido los siguientes:

1.- Una vez descargados los 4 CDs del Fixpack desde el Fixcentral de IBM (http://www-933.ibm.com/support/fixcentral/) tendremos a nuestra disposición el fixpack 21 del VIOS. Antes de nada, ejecutaremos el comando ioslevel para comprobar que versión tenemos. La versión es la 2.0.0.

2.- Introduciremos el primero de los 4 CDs y ejecutaremos los comandos siguientes:

updateios –commit (para aceptar los updates que no se hubieran aplicado)

updateios –accept –install –dev /dev/cd0 (esto instalará el fixpack)

Una vez finalizado, realizar un ioslevel para verificar que ahora es el V2.1.1.10 FP-21.

Por tanto, realizar un shutdown –restart para reiniciar el VIOS. Con esto, finaliza el uso de la consola VIOS, a partir de aquí se configura todo por navegador web.

Configuración Ethernet Virtual

Para que nuestro futuro iSeries se comunique con el exterior, es necesario habilitarle una tarjeta de red para su uso. Esto se consigue creando un Ethernet Virtual, que haga de puente usando nuestro Ethernet real. Para ello, seguiremos los siguientes pasos:

1.- Entraremos en la web del VIOS, con el usuario padmin y el password correspondiente.

2.- En el menú Ver/Modificar Adaptadores Ethernet de Sistema Principal, seleccionaremos el primer puerto ethernet (su hardware acaba en –P1-T6) y pulsaremos sobre Propiedades. Marcaremos la casilla Permitir puenteado de ethernet virtual y daremos a OK.

js1204

Fig. 4: Modificar Adaptador Virtual

3.- En el menú Ver/Modificar Ethernet Virtual, elegiremos sobre Puente de Ethernet Virtual y seleccionando Ethernet Virtual 1, cambiaremos su Adaptador Físico a la tarjeta modificada en el punto 2. Y pulsaremos sobre Aplicar.

js1205

Fig. 5:  Permitir Puenteado Ethernet Virtual

js1206

Fig. 6: Elección Ethernet Virtual

Por tanto, llegados a este punto, disponemos ya de una tarjeta de Gigabit Ethernet para el uso del futuro iSeries.

Creación de la Partición iSeries

Para crear un equipo iSeries, primero debemos crear una partición en la que funcionará el equipo. De hecho, el VIOS ya es una partición, la número 1. La partición que tendrá el iSeries, por tanto, es la numero 2. A esta partición se le asignarán recursos (Ethernet, disco, memoria, CPU, etc) y una vez asignada, se procederá a la instalación del iSeries.

js1207

Fig. 7: Partición VIOS en ejecución

Para crear la partición, pulsaremos el botón Crear Partición… lo que nos llevará a un asistente, el cual seguiremos sus pasos por las siguientes figuras:

js1208

Fig. 8: Nombre y Entorno de la partición

js1209

Fig. 9: Tamaño de memoria asignada

js1210

Fig. 10: Número de procesadores asignados

js1211

Fig. 11: Adaptadores de red asignados

js1212

Fig. 12: Asignación de almacenamiento virtual

js1213

Fig. 13: Elección LUN de la DS3200

Lógicamente, hemos creado una LUN para que esté disponible en el iSeries, que está alojada en la DS3200, y, evidéntemente, el zoning SAS está también definido para que esta oblea, pueda ver tanto la cinta LTO4 SAS como la cabina DS3200.

js1214

Fig. 14: Elección de la cinta LTO4 SAS

js1215

Fig. 15: Resumen de la partición que se va a crear

Una vez dado a Finalizar, la partición iSeries se creará sin problemas.

Instalación Consola de Operaciones

Para poder tener consola maestra en el iSeries, es necesario instalar la Consola de Operaciones en un equipo Windows, de modo que procederemos a instalar el IBM System i Access con esta opción.

Este programa sustituye a los clásicos terminales twinaxiales Infowindow que proveían la consola maestra DSP01. A partir de ahora, la DSP01 será una pantalla emulada del sistema. Por tanto, para realizar la instalación, y una vez instalado el IBM System i Access con la opción “Instalación Completa”, seguiremos los siguientes pasos:

1.- Abriremos el programa y pincharemos sobre el icono Nueva Conexión. Esto hará que nos salga un asistente de creación de la conexión de consola, tal y como muestra la figura siguiente. Así que pulsaremos sobre Siguiente.

js1216

Fig. 16: Asistente de Configuración Consola de Operaciones

2.- La siguiente pantalla muestra el tipo de conexión que queremos habilitar. Haremos clic en Consola local en una red (LAN) y luego en Siguiente.

js1217

Fig. 17: Elección del tipo de conexión

3.- Lo siguiente es elegir el nombre de la conexión. Elegiremos el nombre CONSOLA y a continuación, daremos una IP que no este en uso en la red, IP que virtualizará la propia consola.

js1218

Fig. 18: Nombre de la conexión y dirección IP asignada

js1219

Fig. 19: Datos IP de la conexión

3.- En esta figura, introduciremos la dirección IP y mascara de subred relativas a la conexión, así como el número de serie de la máquina JS12 y el número de partición al que se conectara (como el iSeries tiene la 2, pondremos un 2 como Partición Destino) .

js1220

Fig. 20: ID de dispositivo de herramientas de Servicio

4.- Lo siguiente es elegir el ID de dispositivo de herramientas de servicio. En este caso, seleccionaremos QCONSOLE por defecto. Con este paso, se finalizará el asistente.

js1221

Fig. 21: Finalización del asistente

js1222

Fig. 22: Conexión creada

5.- Ahora, pulsaremos sobre Conectar, para dejar a la consola a la espera de una conexión. La primera vez que conectemos, nos pedirá usuario y password, que, será en ambos casos 11111111 (8 unos).

js1223

Fig. 23: Esperando la conexión por parte del iSeries

Pues hasta aqui el artículo. En estos momentos, con introducir el CD del LIC-RSG, y arrancando en modo D Manual, procederíamos a la instalación del Sistema Operativo, pero eso lo dejo para un siguiente articulo.

Nuevas Instalaciones Yggdrasil

Debido al creciente interes que me mueve mi hobby, en Mayo del 2009 adquirí un local de 90 m2 justo debajo de mi domicilio, para poder montar un “txoko” donde poder disfrutar de los mainframes, así como investigar nuevas formas de trabajar con ellos, experimentar, etc.

Hasta el momento, todas las máquinas aguardaban una oportunidad de funcionar y dar algún servicio de utilidad en la Euskal Encounter, mientras que el resto del año languidecían embaladas en contenedores marítimos y garajes sin poder encenderlos ni usarlos absolutamente para nada. Por fortuna, a partir de este momento, estas máquinas tendrán el lugar que les corresponde.

No obstante, el local no se encuentra en condiciones para encender todo y dar servicio, ya que llevaba mas de 7 años cerrado, con multitud de humedades, y ha sido necesaria una reforma integral para que ese “agujero” termine llamadose “Centro de Proceso de Datos”.

A continuación, mostraré con galerías de imágenes, y así se podrá apreciar la evolución y el cambio que está sufriendo.

Local en el momento de la adquisición:

Local en Obras, empezando a tirar tabiques de pladur y escombrando todo:

Local en Obras, con todo el escombro tirado y empezando con el techo registrable:

Local en Obras, instalando el techo:

Estructura del techo instalada, algunas luminarias conectadas:

Arreglo de paredes y raseo con perliscayola:

Paredes arregladas, recepción de mercancía de pavimento tecnico (suelo registrable):

Instalación del pavimento técnico:

Euskal Encounter 17

Este año, como siempre, he llevado todas las máquinas Mainframe para dar el servicio de Direct Connect como todos los años. Por tanto, aprovechando la instalación del año pasado, simplemente hemos reconetcado todo y hemos vuelto a encender todo como el año pasado, cosa que ha funcionado perfectamente.

N0 obstante, este año hemos introducido una serie de novedades: Por una parte, hemos instalado un sistema de robótica IBM 3494, junto con un sistema VTS modelo B18, sistema que virtualiza las cintas, con el fin de automatizar todo el sistema de copias de seguridad. De todas formas, apenas se ha notado diferencia, ya que este año no he bajado nada de interes, y por tanto, no he tenido necesidad de realizar copias de seguridad.

Por otra parte, hemos llevado un sistema de discos SAN, IBM DS4500, que nada tiene que ver con el mainframe, para tener un segundo sistema para compartir datos, que, a pesar de tener 2 enlaces de fiber-channel a tan solo 2 Gbps, ha funcionado perfectamente en todo el transcurso de la party, llegando a subir 8 TB de datos totales a la red de la Euskal.

Sin mas, aqui dejo unas fotos del evento en cuestion.

Fotos del Montaje:

Fotos del Jueves:

Fotos del Viernes:

Fotos del Sabado:

Dobis/Libis: 30 años de servicio tocan a su fin

Dobis Libis Sistema de Multiplexacion de terminales El articulo de hoy lo voy a dedicar a una máquina mainframe que me atrevo a decir que es la más vieja que ha permanecido en servicio en España, la cual ha dejado definitivamente el mundo terrenal informático el 3 de marzo del 2008.
La máquina en cuestión es un mainframe departamental de gama baja que IBM sacó en el año 1990, concretamente un IBM ES/9000 9221 modelo 150, atendiendo una demanda de proceso crí­tico y eficiente a muy bajo coste (si lo comparamos con otros mainframes de la época). Esta máquina, al contrario que sus hermanas mayores (la 9121 y la 9021, respectivamente) no precisa de grandes enchufes de corriente trifásica, aire acondicionado potente debido al calor disipado ni necesita suelo falso para su instalación. Como modelo ES/9000 que es, fue la primera de su especie en implementar la arquitectura System/390 ESA/390 Architecture (31 bits de proceso y hasta 2 GB de RAM direccionables, respecto a los 24 bits de proceso de la arquitectura S/370) y la posibilidad de PR/SM: hacer LPARes en la misma máquina, aunque en este caso, la máquina no tení­a ninguna LPAR configurada, funcionando de este modo en ESA/390 Single-Image Mode. Es una máquina que puede conectarse a cualquier enchufe monofásico de 220V que tengamos en casa, y es una máquina que se instala un rack del tipo IBM 9309 beige de toda la vida.

Este ordenador estaba instalado en la Universidad de Deusto, y daba el soporte principal de todo el servicio de Biblioteca de esta Universidad, tanto de consulta de alumnado como de investigación. En sus tripas estaban catalogados decenas de miles de libros, desde manuscritos del siglo XIV hasta el último libro comprado en Amazon. Para ello, el sistema contaba con una aplicación cliente-servidor basada en CICS llamada Dobis/Libis en la que, mediante ficheros secuenciales indexados de tipo VSAM, gestionaba todo el catálogo de volúmenes que residían en la biblioteca, gestión de préstamos, catalogación de volúmenes, impresión de carnets de socios, códigos de barras, etc.

Hardware

Con sus 16 míseros MB de RAM, y sus 3 sistemas de discos IBM 9336 también enrackables en sendos muebles de color beige, que daban un total de 4 GB aproximadamente, daba servicio a un grupo numeroso de terminales, hasta un máximo configurado de 512, pero en la actualidad estaban conectados simultáneamente unos 170 terminales en una red coaxial de protocolo 3270 y utilizando unos multiplexores IBM 3299 los cuales permití­an utilizar una lí­nea coaxial para dar servicio hasta 8 terminales simultáneamente, dispuestos en una configuración en Árbol o jerárquica.

Por la parte de Backup, tenía 3 unidades de cinta distintas, por temas de compatibilidad: Por una parte, existí­an dos unidades de cinta de carrete, una IBM 9347 que podía escribir y leer cintas de 1200 bpi y 8 pistas y 3000 bpi, vestigio del sistema anterior (IBM 9375) hasta la adquisición del ES/9000 -se utilizó para la migración del viejo sistema al nuevo y para backups ocasionales-, mientras que la otra unidad era una IBM 9348, que leí­a tanto cintas de 1200 bpi como de 6250 bpi, pero mucho más veloz que la primera. La otra unidad de cintas era una unidad de cartuchos IBM 3490E modelo C11, con una boca autocargadora de 5 cartuchos, que escribe a 36 pistas (18 en un sentido y 18 en el otro) con capacidades de 800 MB a 2 GB en función de la compresión y del tipo de cartucho.

Y por la parte de comunicaciones, además de tener múltiples tarjetas coaxiales 3270 para la interconexión de terminales, el ES/9000 disponía de una tarjeta Token-Ring para incluirla en una Red LAN. El sistema también tení­a un interfaz web el cual podí­a ser consultado desde Internet y así­ poder realizar reservas de libros y búsquedas de volúmenes. Pero claro, al tratarse de una máquina cuyas comunicaciones estaban basadas en SNA, ya que el TCP/IP en VSE/ESA (El SO con el que trabajaba el mainframe) es un producto aparte con un coste muy elevado, existía un problema de incompatibilidad de comunicaciones y de protocolos. Por tanto, para salvar dicho problema, se instaló un IBM RS/6000 con un procesador PowerPC y con AIX como Sistema Operativo, el cual disponí­a de un software que realizaba la conversión de protocolos entre SNA y TCP/IP y que hacía de Servidor Web, que mostraba una página web cuyos datos se actualizaban de acuerdo a las transacciones CICS apropiadas. Para ello, este equipo tení­a una tarjeta Token-Ring que estaba conectada al Token-Ring del ES/9000 y configurada con una LU de SNA, mientras que por otra parte, tení­a una tarjeta Ethernet conectada a un Router que daba el acceso a la Red de Deusto que a su vez salía para Internet. Para finalizar con el apartado de comunicaciones, la máquina disponía de 2 líneas punto a punto del tipo X.25, que comunicaban la máquina con máquinas análogas de otras universidades (como la de Oviedo) que tenían el mismo sistema Dobis/Libis y por tanto, se pasaban datos de Í­ndices de libros maestros para no tener que darlos de alta en los dos sitios a la vez y cosas del estilo.

La máquina está compuesta por 3 armarios IBM 9309 de tipo rack beige estandar. Cada Rack tiene su regleta de alimentación, pero el encendido está gobernado por el rack principal (donde se aloja el bastidor ES/9000) ya que él da la orden de encendido con unos cables de tipo Power-Sequence.

Para que todos los dispositivos puedan funcionar, el sistema ES/9000 está conectado con cables de datos a unos bastidores IBM 5010 también enrackados los cuales tienen la tarjetería I/O de expansión correspondiente: Tarjetas controladores de terminales, controladoras de disco, cintas, tarjeta de red, de comunicaciones X25, modems, etc. Por tanto, cada bastidor tiene su sistema de expansión que controla los dispositivos alojados en ese rack, lo que evita que existan cables sueltos entre racks, exceptuando los cables del ES/9000 a los bastidores 5010 y los cables de secuencia de encendido.

Software

Para que todo esto funcionara de una manera tan eficiente (recordemos que sólo tenía 16 MB de RAM con 170 personas conectadas al mismo tiempo), el ES/9000 contaba con un sistema operativo de época, el VSE/ESA Versión 2 Release 3. Este sistema operativo tení­a un modo de trabajar bastante curioso, ya que estaba dividido por regiones, las cuales se las podía dar un peso de CPU y una cantidad de memoria determinada. Así pues, el propio SO estaba funcionando en la región BG, mientras que existían otras regiones cada una para cada aplicación: F2 para el CICS/ICCF (CICS que gestiona el propio SO), F3 para el VTAM,  F4 para el CICS/VSE que soporta la aplicación Dobis/Libis, etc.

Mención especial a como una máquina de 5 MIPS y 16 MB de RAM era capaz de atender simultáneamente a 170 terminales trabajando contra un CICS, lo que da a entender la enorme eficiencia de hardware de la época y sobre todo del dispatcher del SO VSE, cosa que en las máquinas PC de la época era imposible de darse.

Aunque la máquina fuera de 1990, el software VSE y el sistema Dobis/Libis era muy anterior, ya que antes de la instalación de ese mainframe, en el mercado existí­an otros mainframes S/370 como el IBM 9375 que tenían instalados en la Biblioteca de la Universidad de Deusto que no llegue a conocer, y aunque no corrían VSE/ESA, corrían VSE/SP y su CICS especial de la Época de los 80.

Relevo

Este sistema ha sido sustituido por una máquina Linux con Oracle como Base de Datos y AMICUS como nuevo sistema de gestión de bibliotecas. En lo personal, hubiera sido una opción válida una actualización del mainframe con los últimos niveles de software y hardware para multiplicar el rendimiento, pero la decisión final de migrar a ese entorno entiendo que ha podido tomarse por medidas económicas mas que productivas.

Desmontaje

El primer día de desmontaje, nos encontramos con la máquina encendida, por lo que tuvimos tiempo para trastear un poco con la consola y ver que discos tiene, ocupación, etc. Al de un rato, la responsable de los sistemas informáticos de la biblioteca, Pilar Isusi, realizó un apagado ordenado del CICS, VTAM y por último, VSE, por lo tanto la máquina se cerró por última vez, la memorable fecha del 3 de marzo del 2008  a las 18:00 horas.

Una vez apagada, se desembornaron los 3 cables de alimentación de cada rack, para evitar cualquier peligro de electrocución.

Se fueron anotando con unas pegatinas numeradas los números de los cables y sus conectores, con el fin de poder saber a donde va cada cable cuando haya que volver a montar todo, porque la cantidad de cables era increíble.

Lo siguiente que se hizo, fue desenmarañar la increíble cantidad de cables coaxiales, y de comunicaciones que existían. Nos encontramos con cables que antaño pertenecieron a modems, pero que en la actualidad estaban desconectados, pero que no se quitaron de la máquina por respeto, así­ que tuvimos una ardua tarea de catalogación de cada cable y ver si era necesario volver a conectarlo cuando la máquina se lleve al otro centro de datos (evidentemente, si el cable uno de los extremos no lo tiene conectado a nada, huelga decir que es tontería conectarlo). Así­ que al final, la gran maraña de cables que nos dedicamos a etiquetar resulto que de los que realmente eran importantes en la instalación eran 3 cables, así­ que al final el trabajo se simplificó mucho.

Una vez recogidos los cables y guardados en cajas, procedimos a embalar las máquinas para evitar que se golpeen en el transporte. Así­ que dejamos todo listo para cuando el transportista venga a retirar los 3 muertos.

También realizamos una limpieza de todos los manuales que guardaba la responsable del sistema, así­ como de cintas de carrete de software de la máquina, llenando casi dos furgonetas con documentación tanto escrita como magnética. Aunque no nos hacía falta todo, no es la primera vez que no te llevas un manual por creerlo inútil y resulta que cuando realmente te das cuenta de que lo necesitas, lo han tirado a la basura, así­ que por precaución, nos llevamos todo. Ya habrá tiempo de ordenarlo todo sin peligro ni prisas.

En la misma furgoneta entraron también las dos impresoras que estaban conectadas la máquina para obtener listados de todo tipo: Una IBM 4224 y una IBM 4234, esta última de líneas, cuya velocidad de impresión es mucho mayor que la primera (también mucho mas voluminosa debido a la cajonera que tiene debajo para el papel-pijama).

Montaje y Uso de Linux

Una vez desmantelada la máquina del Centro de Proceso de Datos de la Biblioteca y llevada a nuestro CPD, y vuelta a montar, la encendimos y pudimos comprobar que todo arrancó a la primera, incluso el VSE/ESA y el CICS, aunque no el Dobis/Libis ya que la responsable de sistemas descargo toda la información pertinente para cumplir con la ley de Protección de Datos y así­ no pasarnos información que podría llegar a ser sensible.

Pero la idea es darle otro uso. Borramos todos los discos, porque la idea es pretender instalar Linux en esa máquina y así­ comprobar que una máquina de 18 años de antigüedad es capaz de correr un sistema operativo actual. Lamentablemente, al tratarse de una máquina sin una Integrated Console como con los S/390 y z/Series más actuales, consola que usa Linux en el arranque del Kernel y donde se le definen las direcciones IP para realizar la instalación, comprobamos que el arranque tenía éxito (el procesador quedaba en Operating y no en Disabled Wait), pero no pudimos comprobar en ninguna consola haciendo un telnet a la máquina para ver un Linux login: adecuado, ya que al no poder darle una dirección IP, no puedes hacer telnet a la máquina. Pero, nos creemos que Linux funciona, dado que el procesador no aborta su operación. Estamos en pruebas para generar un cartucho con opciones de IPL para que Linux dé una IP en el arranque, pero nos hemos encontrado con problemas de otro tipo con lo que respecta a la tarjeta de Red Token-Ring, que parece no estar soportada.

Futuro

Esta máquina la guardaré celosamente por tratarse una antigüedad casi por motivos sentimentales, ya que a día de hoy es imposible conseguir piezas de repuesto o ampliación de memoria RAM, por poner unos ejemplos, de modo que la dejare con un VSE/ESA básico instalado desde las cintas originales que nos dieron con la máquina para experimentar e investigar sobre este sistema operativo fuera de mantenimiento, a pesar de que IBM lo sigue comercializando bajo el nombre de z/VSE ya que funciona bajo máquinas z/Series.

Euskal Encounter 16

CPD Mainframe Graficas de Uso del Mainframe Como cada año, he llevado una instalación mainframe a la edición anual de la Euskal Encounter que se celebra en el pabellón 5 del BEC. Este año, el stand que me ha colocado la organización para albergar el CPD, ha sido sensiblemente mas pequeño, pero infinitamente mejor, ya que se trata de una cristalera y un entramado que hacía las veces de techo, con lo que el aspecto vestía mucho el sitio con respecto al año pasado.

Como dije en el otro post anterior, se llevaron dos mainframes completos, basados en tecnologia zSeries de IBM (uno donado de la Bolsa de Bilbao y otro de Hunosa), con almacenamiento ESS (un F20 donado de Lantik, S.A. y un 800 donado de Servimática S.A.). Se les instaló SuSE Linux Enterprise Server 10 SP2, la última versión para zSeries creada por Novell. En una partición, se instaló el HUB servidor de Direct Connect llamado VerliHub, y en otra partición, se trató de instalar un cliente de DC con un LVM de 2,5 TB. Y digo “trató” por que al final, el LVM dió un montón de problemas y no pudimos instalarlo satisfactóriamente.

PartyPlace, de noche ESS-800Este año se conectaron 1000 personas menos que el año anterior, este año fueron unas 1.800 personas, pico que se produjo la madrugada del sabado al domingo. Sin mas, el equipo respondió perfectamente al alubión de gente, por lo que junto con lo expléndido que funcionó la red, este año no hubo absolutamente ninguna queja.

Si deseas ver las fotos que se hicieron del evento, visita mi Galeria.

Preparativos Euskal Encounter 16

El Lúnes, día 14 de Julio del 2008, aterrizaremos en el BEC para instalar como cada año, un Centro de Proceso de Datos basado en tecnología Mainframe. Dicha instalación dará, entre otros servicios, un HUB de Direct Connect con el fin de que los usuarios a la party se conecten a él y puedan utilizarlo para descargar programas y compartir conocimiento.

La instalación este año contará con un sistema mainframe de alta disponibilidad: Se van a llevar dos CPCs: Por un lado, un 2066-002 (z800) que será la máquina principal que dará el servicio de DC y por ora parte, otro 2066-0C1 que hará de sistema de backup en caso de que el sistema primario falle (improbable, pero no imposible). Dichos sistemas tendrán conectividad con dos sistemas de discos ESS (un ESS-F20 y un ESS800)  que estarán cruzados, de tal forma   que quedará completamente garantizada la conectividad de fibras independientemente de que fallen discos o procesadores.

El sistema no actuará como un cluster Activo-Pasivo: Mientras que el HUB de DC funcione en la máquina principal, la máquina secundaria estará funcionando con un Cliente de DC, con el fin de realizar pruebas de Rendimiento ya que vamos a tratar de “estresar” la máquina asignando muchos mas slots de los que podría aguantar un PC corriente y asi demostrar que unas máquinas que tienen mas de 8 años son capaces todavía de dar mil vueltas al mejor de los servidores actuales (y eso que la familia IBM 2066 -z800- es la más baja que IBM ha creado dentro de la tecnología mainframe).

Como periferia, contaremos con una unidad 3590 en la que realizaremos copias de seguridad de los volúmenes de discos, así como una unidad 3490E y una unidad 3422 que se llevarán para exhibir.

Además, este año llevaremos unos proyectores y unas pantallas de proyección para proyectar gráficos de uso de CPU, disco, Red, etc, a la vez que se mostrará un sináptico con un dibujo de la instalación en la que en caso de que algo falle, se pondrá en rojo parpadeante.

En cuanto a la conectividad, contaremos con 4 enlaces de Gigabit ethernet, dos para cada máquina, de tal forma que el sistema de conectividad queda garantizado en este punto. También se contarán con dos redes, una Token-Ring y otra ethernet, que gestionarán las consolas HMC de las máquinas, por lo que serán privadas.

He escrito una documentacón en PDF para ir sobre seguro a la hora de instalar los siguientes sistemas:

Guia de Instalación de SuSE Linux Enterprise Server 10 SP2 para zSeries

Guia de Instalación de SNMP y MRTGbajo SuSE Linux

Guia de Instalación de VerliHub y VHCP bajo SuSE Linux

Guia de Instalación del Cliente de Direct Connect para SUSE Linux

Guia de Instalación del Cliente de Direct Connect para MS Windows