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:

12►

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

Local en Obras, instalando el techo:

12►

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:

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:

123►

Fotos del Viernes:

12►

Fotos del Sabado:

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.

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.

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

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

En el anterior artículo, hemos explicado cómo se arranca un PC con Hercules y cómo hemos conseguido una sesión TSO en nuestro emulador de terminal 3270 y hemos establecido una sesión TSO no-SNA con el hercules, bajo una pila TCP/IP proporcionada por el propio Hercules pero que emula un terminal 3278 conectada a una Unidad de Control IBM 3174.

Es decir, que ni tenemos red real, ni SNA, ni TCP/IP, ni nada. Por lo que un acceso de otro PC de la LAN a nuestro mainframe es imposible. De hecho, si desde otro PC hacemos un Telnet 3270 a la IP de nuestro equipo que corre Hercules, se establecería otra sesión TSO, pero del pool de terminales de Hercules que esté emulando una red real, y cogería la dirección 0702, es decir, una sesión VTAM local no-SNA. Pero… ¿Que hacemos para que el z/OS se comunique directamente por TCP/IP y así conseguir que se pueda conectar desde cualquier PC a un DB2 por un puerto?

Lo que hay que hacer es crear una tarjeta de red en el Hercules, para que el z/OS crea que tiene una tarjeta de red real (OSA) por la que puede correr tráfico TCP/IP y por el cual el CICS, DB2, y hasta las propias sesiones TSO puedan comunicarse.

Para definir un enlace de este tipo, primero debemos saber como funciona: Bajo GNU/Linux, se utiliza un dispositivo virtual TUN/TAP, ya que hercules no funciona con dispositivos de red reales. Para ello, se crea un enlace CTC virtual que comunicaría el Hercules con la pila TCP/IP de GNU/Linux. Recordemos que Hercules ya hace uso del TCP/IP, pero solo para emular dispositivos de terminales VTAM locales no-SNA. El grafico siguiente muestra la configuración que se desea realizar:

        +--------------------------------+
        |     GNU/Linux Debian           |
        |                                |
        +-------------+                  |
        |  Hercules   |                  +-------------+
        |-------------|                  |    eth0     |
        |  z/OS 1.6   |      TCP/IP ------------------> Red LAN
        |   TCP/IP    |                  |192.168.101.7|
        |-------------|         |        +-------------+
        |    CTCA     |         |        |
        |192.168.101.8|         |        |
        +------|------+     10.0.0.2     |
        |  /dev/tun           tun0       |
        |      |                |        |
        |      +----------------+        |
        |       Virtual CTC link         |
        |                                |
        +--------------------------------+

Usando el sistema TUN/TAP, podemos crear un enlace de red virtual que luego podremos conectarlo a la tarjeta de red real. Por un lado del TUN, el z/OS verá la dirección IP 192.168.101.8, que es la que utilizaremos para conectarnos desde el exterior y a la que daremos al z/OS para que todo tráfico que vaya a esa IP, sea respondida por z/OS. En el otro lado del enlace CTC, tendremos una dirección intermedia ficticia con la IP 10.0.0.2 que es el otro lado del dispositivo TUN, y este sistema enlaza ambas direcciones.

Luego, se le definiría en Linux una ruta desde la 10.0.0.2 a la 192.168.101.7 que es la IP real de nuestra máquina GNU/Linux y la cual tiene el dispositivo eth0, que harí­a el enrutado. Es decir, cuando todo esté configurado, si accedemos a 192.168.101.8 desde cualquier punto de la red, en realidad accederemos a la 192.168.101.7 y luego nos enrutará directamente al Hercules, con lo que tendríamos una conexión TCP/IP directa con el z/OS.

Sin más, definiremos en enlace en hercules añadiendo la siguiente linea en el fichero de configuración hercules.cnf:

0E20.2 CTCI 192.168.101.8 10.0.0.2

Se deben definir dos direcciones: Una para la transmisión y otra para la recepción, de ahí­ el 0E20.2, porque las direcciones IODEVICEs correspondientes serán 0E20 y 0E21. La razón por la que hemos elegido estas direcciones, es porque en el IODF del z/OS hay definidos esos dispositivos del tipo 3088 que se utilizan para enlaces CTCI y/o OSA, como he explicado en la pasada entrega y que está documentado en las instrucciones del AD/CD.

Los siguientes dos parámetros nos definirán las direcciones IP de los extremos del TUN/TAP: 192.168.101.8, que es la dirección de red que verá el z/OS y que hemos obtenido del administrador de red, y la 10.0.0.2, una dirección interna inventada que verá GNU/Linux y por la cual el driver TUN/TAP poseerá.

Con esto, la definición para el fichero de configuración de Hercules está realizada.

Creación del enlace TUN/TAP en GNU/Linux

Si no encontramos nada en /dev/net/tun, significa que el sistema TUN/TAP no está instalado o configurado. Si tenemos un kernel mayor que 2.4, el sistema tun/tap viene con el kernel, pero si no, habrá que recompilarlo con esa opción habilitada.

Los siguientes comandos (como root) crearán un dispositivo TUN:

mkdir /dev/net
mknod /dev/net/tun c 10 200
chgrp root /dev/net/tun
chmod g+w /dev/net/tun
chmod o-r /dev/net/tun

Luego, editar el fichero /etc/modules.conf añadiendo la siguiente lí­nea:

alias char-major-10-200 tun

Esto hará que el módulo se cargue cada vez que Hercules reclame la apertura de ese enlace. Esto se hace mediante a ejecución de hercules del fichero /usr/local/bin/hercifc quien es quien controla el enlace virtual. Para ello también deberemos configurar este fichero con los permisos adecuados, en nuestro caso con los comandos siguientes:

chgrp root /usr/local/bin/hercifc
chmod 4750 /usr/local/bin/hercifc

Como se deberá usar el IP-Forwarding para el enrutado entre el disposituvo TUN y la red real, ejecutando el siguiente comando lo habilitará:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp

El siguiente comando habilita el forwarding IP de la tarjeta de red virtual a la real:

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Y, por último, definiremos una ruta en GNU/Linux para que sepa que todo lo que sea de 192.168.1.8 se vaya directamente a nuestro recién creado dispositivo TUN:

route add 192.168.101.8 dev tun0

Enrutado en los PCs Clientes

Este paso es opcional, pero no está de más ejecutarlo en todo PC de la red el cual queramos que entre en la máquina hercules, pero por el enlace CTC:

route add 192.168.101.8 mask 255.255.255.255 192.168.101.7 metric 1

Configuración final de TCP/IP en z/OS

Ya tenemos todo listo: Tenemos el camino desde fuera hacia hercules creado. Ahora, debemos customizar algunos datasets del z/OS para que escuchen al interfaz correcto con la IP correcta.

TCPIP.PROFILE.TCPIP

Se deben comentar algunas líneas que hacen referencia a los DEVICEs, los LINKs, los HOMEs y los GATEWAY, e introducir los siguientes valores:

DEVICE CTCDEV1 CTC E20
LINK CTCLINK1 CTC 0 CTCDEV1
HOME 192.168.101.8 CTCLINK1
GATEWAY
; Network   First Hop     Link Name Size   Subnet Mask  Subnet Value
10.0.0.2       =          CTCLINK1  1500   HOST
DEFAULTNET     10.0.0.2 CTCLINK1  1500   0
START CTCDEV1

Como habréis deducido, la primera lí­nea define el dispositivo de red, en la dirección E20. Importante también que el GATEWAY refleje el dispositivo TUN, ya que es por el que va a salir hacia afuera.

TCPIP.TCPIP.DATA

Se cambian los valores de:

DOMAINORIGIN  midominio.com  y
NSINTERADDR  195.235.113.3

Siempre y cuando Internet lo tengas desde Telefonica, ya que su DNS es esa IP. Para el resto, introducir el DNS que utilicéis en la red.

TCPIP.HOSTS.LOCAL

Se cambian los valores de:

HOST : 192.168.101.8   : hercules.midominio.com, p390: y
NSINTERADDR  195.235.113.3

Con esto, ya está todo configurado. Al hacer IPL de nuevo, Hercules levantará el interfaz TUN y a partir de ahi, la IP 192.168.1.8 estará disponible. Si podéis acceder a una sesión TSO por esa IP (y no por la 192.168.1.7), desde cualquier PC de la red, lo habéis conseguido.

NOTA: Es posible que no podáis abrir en modo edición los datasets TCPIP.TCPIP.DATA y el PROFILE. Si se da el caso, desde la master console, introducir el comando STOP TCPIP para parar el proceso. Entonces, si os dejará editarlo sin problemas.

La anterior entrega explicaba a nivel introductorio lo que es un AD/CD y su aplicación. En esta, explicaremos como preparar el PC que va a convertirse próximamente en un mainframe.

Partiremos de un PC con GNU/Linux. En mi ejemplo, he elegido Debian, pero los comandos que voy a dar lo mismo valen para la Ubuntu, ya que voy a utilizar el conocido comando apt para instalar software.
También parto desde el hecho que ese PC está conectado a una LAN por una tarjeta de red y que dicho PC tiene su IP fija y su acceso a Internet, y, evidentemente, si queremos usar una consola 3270 necesaria para Hercules, necesitamos tener algún sistema X-Window funcionando en nuestro equipo aunque no es del todo obligatorio.

Pues bien, si hacemos un apt-get install hercules, nos instalará el emulador Hercules. Así­ de sencillo.

Si hacemos un apt-get install x3270, instalaremos el emulador de terminal 3270 para GNU/Linux. Si no queremos tener X-Window, podríamos instalar un emulador de terminal en modo texto llamado c3270, de modo que con un apt-get install c3270 lo tendríamos instalado y así­ prescindir del entorno X-Window.

Configuración Hercules

De acuerdo, si Hercules se ha instalado bien, deberíamoss tener un directorio llamado /etc/hercules y en su interior, un archivo llamado hercules.cnf. Ese es el archivo de configuración, y ese fichero viene por defecto. Lo renombraremos para tenerlo guardado por si acaso, y añadiremos el nuestro con una información similar a esta:

#
# Configuration file for Hercules & IBM ADCD z/OS 1.6
CPUSERIAL 000000 # CPU serial number
CPUMODEL  9672   # CPU model number
MAINSIZE  768    # Main storage size in megabytes
XPNDSIZE  0      # Expanded storage size in megabytes
CNSLPORT  23     # TCP port number to which consoles connect
NUMCPU    1      # Number of CPUs
TZOFFSET  +0100
OSTAILOR  OS/390  # OS tailoring
PANRATE   FAST    # Panel refresh rate
ARCHMODE  ESAME   # Architecture mode S/370, ESA/390 or ESAME
PGMPRDOS  LICENSED  # Allow OS/390 and Z/OS systems to run 

#
# IPL parameter
#
LOADPARM  0A82CS.. 

# Device list
#---  ----  --------------------
0700  3270
0701  3270
0702  3270
0900  3270
0901  3270
0A80  3390  /ZOS16/s6res1.a80
0A81  3390  /ZOS16/s6res2.a81
0A82  3390  /ZOS16/os39m1.a82
0A83  3390  /ZOS16/s6db21.a83
0A84  3390  /ZOS16/s6cic1.a84
0A85  3390  /ZOS16/s6dis1.a85
0A86  3390  /ZOS16/s6dis2.a86
0A87  3390  /ZOS16/s6uss1.a87
0A88  3390  /ZOS16/s6dis3.a88
0A89  3390  /ZOS16/s6ims1.a89
0A8A  3390  /ZOS16/s6was1.a8a
0A8B  3390  /ZOS16/s6was2.a8b
0A8C  3390  /ZOS16/sares1.a8c
0A8D  3390  /ZOS16/s6dis4.a8d
0A8F  3390  /ZOS16/saipl1.a8f
0E20.2  CTCI  192.168.101.8 10.0.0.2

Como habréis podido comprobar, la parte de arriba hace referencia al tipo de máquina, modelo, etc. Podéis utilizar este fichero como base, o ir a la web del emulador Hercules e investigar que significa cada opción y que valor poner.

Como también podéis ver, he hecho una lista con las direcciones de los discos y la carpeta donde se encuentran, asÍ­ como los terminales, el CTC y luego, el parámetro LOADPARM, que contiene 0A82CS.. el cual significa que el disco IODF es el 0A82 y el parámetro de arranque es CS (Cold Start) debido que existe un miembro LOADCS en SYS1.IPLPARM. Todo esto está documentado en las instrucciones de los CDs, así como todos los parámetros posibles que se pueden poner.

Antes de arrancar hercules, tomad especial atención al parámetro CNSLPORT, ya que si ponemos el 23 (el telnet), debemos estar seguros que no tenemos ningún servidor telnet funcionando en nuestra máquina. He puesto el 23, porque de ese modo, las sesiones x3270 se configuran automáticamente y no hay que pasarle datos del puerto de escucha y demÁs.

Arranque Hercules

Bueno, pues con todo esto, ya está listo. Ejecutando hercules como root, arrancará el emulador. Si no encuentra el fichero de configuración, deberemos escribir hercules -c  /etc/hercules/hercules.cnf

A partir de este momento, en ese terminal de Debian estará el emulador. Si tenemos X-Window, es el momento de volver a Él con un Ctl+Alt+F9 y lanzar el emulador x3270 con una conexión a localhost. En ese momento, debería parecer que el x3270 está conectado a Hercules con un mensaje, y diciendo el número de terminal y la dirección del terminal (como es el primero, debería tener la dirección 0700).

Arranque del z/OS

Si volvemos a la consola donde tenemos el hercules funcionando, basta con escribir IPL 0A80 y veremos como empezarán a salir mensajes y cómo el contador de instrucciones de debajo a la derecha empieza a funcionar.

Entonces, si ahora vamos a la consola x3270 que hemos abierto anteriormente, deberían empezar a salir un montón de mensajes de inicio del z/OS. El texto debe ser de color turquesa, que corresponde al Nucleus Initialization Program o NIP. En este punto, yo os remitiría a las instrucciones del ADCD donde indica cómo y qué responder a los posibles mensajes que vayan apareciendo. El primero probablemente sea para establecer el Sysplex ADCDPL, por lo que responderemos r 00,I y veremos como va progresando el arranque de la máquina.

Una vez arrancada y cargados los programas de inicialización, la pantalla cambiará de texto turquesa a texto verde, los cuales los mensajes de advertencia o preguntas aparecerán en blanco y los mensajes de error, en rojo. Nuevamente, os remito a las instrucciones del ADCD por si aparecen preguntas (por ejemplo, el tipo de arranque del JES2, etc).

En este punto, podéis abrir una nueva sesión x3270, la cual ha tenido que pillar la dirección 0701, la siguiente del rango que Hercules nos da. Al de un rato, esa pantalla debe cambiar a un color de texto rojo y un banner de z/OS.

Ahora, ya estamos preparados para hacer LOGON en vuestra propia máquina mainframe por primera vez en vuestras vidas en casa: El usuario “root” es IBMUSER y su password, SYS1. Y a partir de aquí­ a aprender a usar un poco el ISPF, que es el editor TSO que se utiliza para escribir JCLs, submitirlos, etc.

NOTA con respecto al arranque CS: La primera vez que lo ejecutéis, SIEMPRE debéis arrancar en modo Cold Start para permitir formatear los SPOOLes del JES2, ya que, de lo contrario, dará un casque gordo. Una vez hecha la IPL bien, el resto de las veces, en función de lo que queráis arrancar (DB2, CICS, etc), podéis cambiar el LOADPARM del fichero de configuración del Hercules por DC (ColdStart de CICS y DB2) o DB(Warm Start de DB2 y CICS) y así arrancar todos los productos.
En la siguiente entrega, explicaré como configurar una tarjeta de red virtual con el fin de que el z/OS se comunique directamente por la red sin pasar por el Hercules, con el fin de poder conectarlos al DB2, CICS, etc, por TCP/IP nativo.

El presente artículo viene motivado por algunos comentaristas que piden como instalar un hercules con z/OS para así­ tener un mainframe emulado, al cual se conectarían PCs en red para trabajar con los datos de DB2, CICS, etc. y generar así­ un entorno de desarrollo completo.

Comentaros también que la preparación de este entorno es ilegal, ya que no se dispone de una licencia de IBM para poder hacer funcionar el sistema Operativo z/OS bajo Hercules, pero bueno, como por aquí parece que a la gente le gusta vivir peligrosamente, pues allá vamos.

Para empezar, lo primero que debemos conseguir es el AD/CD (Application Development CD) del Emule, buscando por algo así­ como IBM_ADCD_ZOS. Los resultados pueden ser dispares y de varias versiones del SO. Hay que ser pacientes, no tiene precisamente muchas fuentes y va a tardar en bajarlo, aunque si os bajáis la última versión, la 1.6, debería tener más fuentes. Son 16 ficheros ISO, es decir, 16 CDs, dentro de los cuales hay un ZIP que tiene un volumen 3390-3 comprimido. Es decir, tendremos 16 ZIPs en total y en uno de los CDs, además, también vendrá documentación.

Que es un AD/CD? No, no es un grupo de Heavy Metal Es un conjunto de CDs los cuales tiene un Sistema Operativo de mainframe y todas las aplicaciones habidas y por haber de desarrollo del momento con las últimas versiones en el momento de su lanzamiento. Este sistema, además del propio sistema operativo z/OS, viene la última versión del CICS, del DB2, IMS, JDK, herramientas de TCP/IP, Cobol, Language Environments, etc, del momento de aparición de esa versión, y este paquete de software se distribuye sobre todo a ISVs (Independent Software Vendors) como Computer Associates, Candle, BMC, etc, que programan aplicaciones para esos sistemas, y que necesitan tener un mainframe para poder diseñar esos programas.

Entonces, como estas empresas no van a comprar un mainframe solo para programar aplicaciones accesorias de este entorno, IBM hace años tuvo la idea de vender una solución empaquetada de Hard y Soft llamada PC Server S/390 junto con el AD/CD que era un IBM PC Server 520 con una tarjeta procesadora PCI de S/390 que tenia muy poca potencia, pero que bastaba para tener tu mainframe sin grandes problemas. Se instalaban esos CDs en ese equipo y voila! Los discos se emulaban y las cintas, también, aunque disponía de una cinta DAT de 4mm para el caso por lo que o podrías grabar una cinta real, o un fichero de cinta emulada. Después del PC Server 520, vino el Multiprise 3000 con la misma filosofía pero con un procesador 9672-Generación 5, pero los discos seguían siendo emulados, y la tarjeta de red y unidades de cinta, también. Mas tarde, un emulador llamado FLEX-ES sustituyó a estas máquinas, pero hace pocos años este emulador también ha sido descatalogado, ya que en la actualidad es mucho menos costoso adquirir un mainframe real entry-level como por ejemplo, un z9 Business Class que los mastodontes de aquella Época.

Así­ que imaginaos el ADCD como si fuera una imagen de GHOST de un mainframe completo, con todos los programas y productos IBM instalados en una sola maquina, el cual, una vez “descomprimido”, tendrás un mainframe listo para hacerlo funcionar sin tener que instalar absolutamente nada.

Recopilando Información

Una vez conseguido los 16 volúmenes, y grabados al PC que ejecutará Hercules en la carpeta /ZOS16 (en el caso que os hayáis descargado esa versión), pasaremos a leer las instrucciones que vienen en uno de los CDs, sobre todo lo relativo a cuales son los volúmenes residentes, de catálogo, IODF y que direcciones de terminales debemos configurar para la Master Console y las sesiones TSO no-SNA.

Con que objeto? Pues porque para que el sistema nos funcione, debemos plasmar en Hercules la MISMA configuración con la que viene el Sistema Operativo configurado, cuando se generó la instalación en un mainframe real, de lo contrario, no arrancará. También debemos conocer la dirección de arranque o IPL, la dirección del disco donde está el IODF así­ como saber con que parámetros podemos arrancar (Cold Start, Warm Start, etc). Todo esto viene en las instrucciones, así­ que leéroslas con detenimiento.

Por lo general, en todas las versiones ADCD los discos 3390 han sido siempre 16, desde la dirección 0A80 a la 0A8F, los terminales han sido del 0700 al 071F y del 0900 al 091F, siendo la 0700 la dirección de la Master Console y la 0701, 0702, etc, las sesiones TSO no-SNA. Por Último, las tarjetas de red o CTC-links suelen estar en las direcciones 0E20 a la 0E23 y de la 0E40 a la 0E43. Por tanto, ya sabemos que direcciones debemos configurar en nuestro hercules cuando lo vayamos a instalar, pero nuevamente os remito a leer las instrucciones para que no hayan equívocos.

En la siguiente entrega, explicaré como preparar el equipo e instalar hercules de una manera rápida, sencilla y eficaz.

El presente documento explica como realizar un mantenimiento aplicando parches a un programa concreto. En este documento, trataremos de poner un ejemplo real de aplicación de parches al TSM.

Obtención de la PTF

Si vemos que un programa necesita una PTF concreta nos la descargaremos de la web de IBM, desde el Service Agent. (en nuestro caso, el TSM tiene la PTF UK29650, que soluciona los APARs (Authorized Program Analisys Report) siguientes: PK45022 PK45846 PK46450 PK47066 PK47105 PK47249 PK48211 PK48634 PK48873 PK49063 PK49871 PK49873 PK50061 PK50343 PK50365 PK50373 PK50709).

Una vez descargada, tendremos el fichero en formato Terse, que viene a ser una especie de tar pero para host. Por tanto, con el Personal Communications nos subiremos ese fichero (ocupa unos 12 MB) a un dataset secuencial que tiene un formato FB de longitud de registro 1024 y un blocksize de 10240, (estos datos nos los dan cuando te descargas la PTF) que se llama YGGDRASL.PTF.TEMP0000

UNTERSE de la PTF en el HOST

Con ese PTF recibido en el dataset secuencial YGGDRASL.PTF.TEMP0000, lanzaremos un job como el siguiente que nos hará el Unterse y nos dejará el resultado en YGGDRASL.PTF.BULK0000:

//UNTERSE JOB CLASS=A,MSGCLASS=X
//S1 EXEC PGM=AMATERSE,PARM=UNPACK
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=YGGDRASL.PTF.TEMP0000
//SYSUT2   DD DSN=YGGDRASL.PTF.BULK0000,DISP=(OLD,KEEP,KEEP)

RECEIVE de la PTF en el HOST

Una vez hecho el UNTERSE, tenemos en YGGDRASL.PTF.BULK0000 la PTF “descomprimida”, así que lo siguiente que haremos será ejecutar otro JCL que la reciba, según el producto (en nuestro caso, el Tivoli Storage Manager, Versión 5.3):

//RECTSM52 JOB CLASS=A,MSGCLASS=X,REGION=8192K
//SMPEDPS  EXEC PGM=GIMSMP,
//                      PARM='PROCESS=WAIT',DYNAMNBR=120
//SMPCSI   DD   DSN=TSM53.GLOBAL.CSI,DISP=SHR
//SMPCNTL  DD *
  SET BOUNDARY(GLOBAL).
  RECEIVE .
/*
//SMPHOLD  DD DUMMY
//SMPPTFIN DD DISP=SHR,
//            DSN=YGGDRASL.PTF.BULK0000
 

Este JCL lo que hace es utilizando la zona SMP del TSM, llamada TSM53.GLOBAL.CSI, recibir el contenido del dataset secuencial YGGDRASL.PTF.BULK0000, con lo que mirará si esa PTF esta aplicada ya. Eso el SMP lo hace consultando los datasets de TARGET y DLIBs y si lo encuentra, entonces no lo instala.

Si no los encuentra, como es el caso, esa PTF la deja “recibida” dentro de un dataset llamado TSM53.SMPPTS, que controla la GLOBAL de este SMP, lista para ser aplicada.

APPLY-CHECK de la PTF

Antes de aplicar definitivamente la PTF, lanzaremos el job que aplica la PTF de manera virtual, para ver si hay algún prerrequisito que no se cumpla, o que exista algún problema de ficheros, con el fin de no liarla cuando la queramos instalar. El job es el siguiente:

//APPTSM53 JOB CLASS=A,MSGCLASS=X,REGION=0M
//SMPEDPS  EXEC PGM=GIMSMP,
//                      PARM='PROCESS=WAIT',DYNAMNBR=120
//SMPCSI   DD   DSN=TSM53.GLOBAL.CSI,DISP=SHR
//SMPCNTL  DD *
  SET BOUNDARY(TSMTZN).
  APPLY
         BYPASS   (
                   HOLDSYSTEM
                            (
                              EC
                              DOC
                              DEP
                              ACTION
                              DELETE
                              UCLIN
                            )
                  )
         SELECT (
                 UK29650
                )
         CHECK
         GROUPEXTEND
         JCLINREPORT
         RETRY(YES)

APPLY de la PTF

Si vemos la salida del job y comprobamos que no existe ninguna dependencia no resuelta y que el resultado del job es un Cond. Code de 0 o de 4 (si da 4, dará alguna advertencia, asi que habrá que mirar si seguimos adelante o no), estamos en condiciones de submitir el mismo job, pero quitando el CHECK. Eso hará permanentes los cambios y actualizará la zona TARGET.

ACCEPT-CHECK de la PTF

Antes de aceptar definitivamente la PTF, lanzaremos el job que, al igual que con el APPLY, acepta la PTF de manera virtual, para ver si hay algún prerrequisito que no se cumpla, o que exista algún problema de ficheros, aunque no debería. El job es el siguiente:

//ACCTSM53 JOB CLASS=A,MSGCLASS=X,REGION=0M
//SMPEDPS  EXEC PGM=GIMSMP,
//                      PARM='PROCESS=WAIT',DYNAMNBR=120
//SMPCSI    DD   DSN=TSM53.GLOBAL.CSI,DISP=SHR
//SMPCNTL   DD *
  SET BOUNDARY(TSMTZN)
  ACCEPT
         BYPASS   (
                   HOLDSYSTEM
                            (
                              EC
                              DOC
                              DEP
                              ACTION
                              DELETE
                              UCLIN
                            )
                  )
         SELECT (
                 UK29650
                )
         CHECK
         GROUPEXTEND
         JCLINREPORT
         RETRY(YES)

ACCEPT de la PTF

Si vemos la salida del job y comprobamos que no existe ninguna dependencia no resuelta y al igual que antes, el resultado del job es un Cond. Code de 0 o de 4, estamos en condiciones de submitir el mismo job, pero quitando el CHECK. Eso hará permanentes los cambios y actualizará la DLIB correspondiente.

Este documento pretende explicar como instalar una unidad de cinta IBM 3590 Magstar en un PC con Hercules. De esta forma, se podrían leer cintas reales escritas por mainframes en el hercules, con todos los beneficios que ello supone.

Configuración Hardware
Una unidad IBM 3590, tanto de un robot 3494 como standalone, es básicamente como cualquier unidad de cinta que puedes encontrar en el mercado. Tiene dos interfaces SCSI y por tanto, se pueden conectar a cualquier tarjeta SCSI que puedes encontrar en el mercado, ya sea una tarjeta para PC, para unidad de control de un robot (A50, A60, etc) o lo que sea. En este documento, voy a abordar la instalación y configuración de una unidad 3590-B1A que fue retirada de un robot 3494 en funcionamiento, porque fue sustituida por unas unidades 3592-H1A, con mayor densidad y rapidez que sus antecesoras. Estas unidades estaban conectadas dentro de una unidad de control A60 dentro de un frame del robot 3494.

Unidad 3950-B1A
Por tanto, tenemos una unidad que pesa como unos 20 Kg que en la parte delantera dispone de un panel de control y la boca para insertar los cartuchos y que en su parte trasera tenemos 3 conectores, dos SCSI de 78 pines llamados PORT 0 y PORT 1 y el conector de corriente (monofásico de 220V) y un interruptor que enciende o apaga la unidad.

Fig. 1: Trasera de la Unidad

PC con Hercules y tarjeta SCSI PCI

El PC es una máquina con Linux y tiene instalado Hercules y z/OS. Dicho sistema funciona con normalidad, y hasta el momento, toda cinta que se montaba era de fichero emulado AWS o HET.

Para conectar la unidad de cinta 3590 al PC, hemos instalado una tarjeta PCI Adaptec 2944-UW que, OJO a esto, es una tarjeta DIFFERENTIAL – HVD. Lo comento porque las tarjetas que normalmente se venden en tiendas de informática suelen ser todas SINGLE-ENDED o LVD (de bajo voltaje 5 Voltios ). Estas tarjetas Single Ended en apariencia son EXACTAMENTE IGUALES, aunque su número de serie (en el caso del ejemplo de Adaptec) es AHA-2940UW, y no AHA-2944UW que es la diferencial. Por tanto, la unidad 3590 funciona con interfaz DIFFERENTIAL, que es un bus SCSI de alto voltaje (12 Voltios).

Fig 2: Tarjeta SCSI Diferencial Adaptec 2944UW

Si enchufáramos la unidad de cintas 3590 que es HVD a una tarjeta LVD, lo mas seguro que es el humo que tienen en su interior los circuitos integrados que hace que los susodichos funcionen correctamente, se escape al exterior y por lo tanto dejen de funcionar. Por tanto, si vemos que en la salida del conector pone SCSI-SE, esa tarjeta NO es la apropiada. La tarjeta correcta sería SCSI-DIFF.

He elegido esa tarjeta Adaptec porque es la mas común de todas y se puede encontrar en cualquier web de componentes de segunda mano como eBay y cuestan dos duros.

Cableado

En este tipo de instalaciones SCSI, sobre todo en las de índole DIFFERENTIAL, se deben instalar terminadores activos. Me explico: En una cadena SCSI normal, la cual desde la tarjeta SCSI a los dispositivos conectados a ella se conectan en un modo daisy-chain o la salida de un dispositivo se conecta a la entrada del otro, la salida de este otro a la entrada del siguiente y así­ sucesivamente, al final de la cadena se suele instalar un terminador que indica el final del bus. La mayoría de los casos en los que la cadena se encuentra en el interior del equipos (por ejemplo, discos RAID) el terminador suele ser pasivo y lo emula la tarjeta. Pero en este caso, es necesario instalar un terminador DIFFERENTIAL en el.

Fig 3 y 4: Terminador Diferencial y cable con zapatas SCSI

El tipo de cable también es especial: La unidad 3590 tiene una particularidad que no tienen otros equipos SCSI: No dispone de un puerto de entrada y otro de salida, solo dispone de un puerto, por lo que el cable debe proveer de un conexionado daisy-chain, que por un extremo es de conexión normal, pero que el otro extremo tiene una zapata con dos conectores que hacen las veces de SCSI IN y OUT en el mismo cable. Como cuando me dieron la unidad, me regalaron también los cables, pues a este respecto no he tenido problemas para encontrar este tipo de cables, porque son bastante complicados de encontrar a menos que los compremos a un broker y por tanto, tengamos que desembolsar bastante dinero.

Fig. 5: Conexión del cable con el terminador activo en la 3590

Por lo tanto, para conectar el cable, conectaremos el extremo normal del cable SCSI a la tarjeta SCSI del PC (con el PC apagado) y por el otro, conectaremos la zapata macho al conector hembra  de la unidad 3590 y en el conector hembra de la zapata, colocaremos el terminador activo.

Fig. 6: El otro extremo del cable SCSI conectado a la tarjeta del PC

Con esto, tenemos la parte hardware conectada.

Configuración Firmware 3590

Ahora lo que hay que hacer es configurar la unidad 3590 para que pueda hablar con el PC sin problemas. Por un lado, hay que configurar el número de puerto SCSI que queremos que el sistema configure y por otro lado, hay que configurar el tipo de operación de la unidad (Si esta dentro del robot, no funciona de la misma manera que si es standalone, etc).

Lo primero que haremos será configurar el puerto SCSI. Esta unidad tiene 2 puertos SCSI y dos conectores. Esto hace que la unidad pueda ser compartida por dos sistemas distintos, y a cada puerto se le puede configurar un numero SCSI distinto.

Para ello, encenderemos la unidad y esperaremos a que pase los tests. Una vez pasados, en el panel de control elegiremos con las flechas de cursor el menu Service, y de ahi elegiremos Set Offline. En el menú Offline, elegiremos que queremos poner Offline ambos puertos, asi que pulsaremos sobre Both.

Una vez puestos Offline, si volvemos al menú Service, podemos elegir la opción Set Address y elegimos el puerto al que queremos dar la dirección. Generalmente le daremos la dirección 0, a no ser que el mismo bus tenga algún otro dispositivo con esa misma dirección y por tanto, debamos dar otra. Lo que no se puede hacer es darle la dirección 7, ya que esa suele ser la dirección que reserva la propia tarjeta SCSI del PC.

Una vez cambiada la dirección, la salvaremos, y resetearemos la unidad, para que tenga la nueva dirección configurada. Si los puertos siguen Off-Line, y dado que solo vamos a utilizar uno de ellos, desde el Menú Service podemos poner Online el puerto SCSI al que va conectado el cable del PC.

Por otro lado, hay que configurar el modo de operación de la unidad. La unidad 3590 en función de que si está en un robot o en modo standalone, tiene muchos modos de operación y modos de compatibilidad con otras unidades de cinta. En nuestro caso, y dado que la unidad la sacamos de un robot y ahora la queremos poner standalone, debemos cambiar la modalidad de la unidad. Para ello, seguiremos los siguientes pasos:

1.- Sacaremos el panel de control del sitio donde esta alojado. Eso hará que se muestren 2 botones que estaban ocultos cuando el panel se encuentra en la posición original: Uno de ellos tiene un símbolo de una llave inglesa. Es el modo de Servicio de IBM (CE) y que hará que al pulsarlo se muestre un menú con muchas opciones que ni sabíamoss que existían. Pues lo pulsaremos.

2.- Seleccionaremos Config/Install. Y de ahí­, iremos a Drv Options. En el, debemos estar seguros que esta desactivada la opción Disable CU Mode. Si esta la opción “punteada” es que esta desactivada.

3.- Dentro de ese mismo menú, seleccionaremos la opción Drv Features y cambiaremos lo que estaba por la opción B1A/E1A Deskside.

4.- Seleccionaremos a Yes para salvar todos los datos, y una vez hecho, resetearemos la unidad o bien apagándola y encendiéndola, o bien pulsando el botón que esta a la izquierda del de la llave inglesa que es el de reset.

Configuración PC

Ahora, toca arrancar el PC. Con la unidad encendida y con los diagnósticos pasados, encenderemos el PC. En el arranque del firmware de la tarjeta SCSI, deberíamos ver como ahora en la dirección 0 existe un dispositivo llamado IBM3590B1A. Si se ve, la instalación ha sido un éxito.

Fig. 7: Unidad 3590 correctamente detectada por la tarjeta SCSI

En principio, ahora si arrancamos GNU/Linux, debería autodetectar la unidad y darle un nombre de dispositivo, como por ejemplo, /dev/st0.

Para probar que la unidad funciona, haremos una prueba sencilla: Realizaremos un tar de unos ficheros a la unidad de cinta y luego los recuperaremos. Para ello, lo primero que haremos será introducir una cinta 3590 en la unidad y esperar a que la cargue. Cuando en el panel de control aparezca un READY AT LOAD POINT, la unidad está dispuesta. Entonces, ejecutaremos un comando tal que tar -cvf /dev/st0 /home/prueba.txt siendo prueba.txt un fichero de texto normalito que esta en la /home, y debería grabarlo como un rayo.

Para verificar que restaura, si hacemos un tar -xvf /dev/st0 debería dejarnos en /home el fichero prueba.txt grabado anteriormente. Si esto lo ha hecho bien, la unidad, su configuración y GNU/Linux funcionan perfectamente.

Configuración Hercules

Para añadir esa unidad de cinta al Hercules, basta con editar el fichero de configuración hercules.cnf que reside por defecto en /etc/hercules.cnf y añadir la siguiente línea:

0500   3490     /dev/st0

Esto hace que la unidad de cinta esté conectada a la dirección 0500 y si nuestro z/OS tiene esa dirección en el IODF configurada como unidad 3490 o 3590, será suficiente.

NOTA: Como hercules no reconoce unidades 3590, hemos definido la unidad como 3490. Esto realmente no afecta al grabado de cintas, por lo que si desde z/OS del hercules, mandamos una copia a cinta, a pesar de que la unidad se vea como una 3490, se grabara en formato 3590 con la capacidad de cartuchos 3590 J y K y podrá ser leída desde cualquier mainframe real.