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.

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!

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:

Fig. 1: Arranque de la partición iSeries

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

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.

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:

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.

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

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

Fig. 8: Formato del Disco

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:

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.

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.

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

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.

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

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.

Fig. 16: Inicio de Sesión

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.

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.

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.

Fig. 20: Cambio de contraseña QSECOFR

Fig. 21: Trabajar con Acuerdos de Software

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.

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.

El articulo de hoy trata de explicar como funciona el sistema de mantenimiento de Software en MVS o z/OS, o dicho de otro modo, como mantener el software e instalar parches que arreglan cagadas de software.

A pesar de que el Sistema Operativo MVS tenga mas de 40 años y su desarrollo, robustez e implantación es de sobra probado, cada día salen arreglos de software o fixes que solventan alguna carencia, error u optimización de programas del sistema. Y los que no salen, siempre se recurre a “It is NOT a bug: It’s a Feature”, je, je. Y si, MVS es lo que es y como todo, requiere la instalación de parches y mas parches, porque siempre hay un humano por detrás que mete la gamba programándolo. Afortunadamente, son gambas controladas porque de lo contrario, seria de risa, pero una de las razones por las que MVS es tan robusto es por el magnifico soporte y seguimiento software que tiene (lógico, cuesta la hostia de dinero tener una licencia de MVS, como para dejar que pete, no te fastidia).

El 90% de las veces, salen PTFs (a partir de ahora diré PTF, con “arreglo” no me siento identificado, je, je) de módulos de software que nunca en la vida has utilizado pero que ahí están y no deben ser ignorados. La política de algunas instalaciones es no instalar PTFs que no incumben en programas producto que no se utilicen, en un afán muy conservador que sigue la máxima de “¿Funciona? Pues no lo toques”. En otras instalaciones, la política es instalar todo lo que sale. En cualquier caso cada política tiene sus pros y sus contras, ya que algunas PTFs, sobre todo las que tocan cosas del SYSPLEX o del SYS1.NUCLEUS requieren hacer IPL, y esto en un ambiente de rabioso 24×7 con miles de usuarios conectados concurrentemente es una putada gorda.

Este sistema, al contrario que en Windows, que se instalan automáticamente, en la mayoría de instalaciones es el deber del programador de sistemas el controlar que PTFs hay, en que afecta al sistema y que módulos parchea. Esto es muy importante, así que, al contrario que en Windows, que se instalan y se reinicia el equipo automáticamente y muy chupiguay todo, en mainframe no se puede permitir que una PTF haga un reinicio automático teniendo a 40.000 personas tirando de un CICS, así que hay que LEER mucho, cuando tienes la PTF te viene siempre con un documento de ayuda y despliegue, y te dice todo lo que hace, en que afecta al sistema, si hay dependencias (es decir, que para instalar esa PTF hayas tenido antes que instalar otras PTFs), y como aplicarla.

Para ello, se utiliza un Producto que viene con el Sistema Operativo, llamado SMP/E (System Modification Program/Extensions). Mediante este producto, podemos tener controlado perfectamente todo el software instalado en el Mainframe, que versión de productos tiene y toda la Gestión de PTFs.

Como funciona el SMP/E

SMP/E trabaja con ZONAS SMP: Existe la zona GLOBAL, la DLIB y la TARGET. Digamos que se estructuran jerárquicamente.

La zona GLOBAL es la zona raíz, y en ella se contiene información, mucha información, acerca de los productos instalados, cuando se instalaron, como se instalaron, aplicación de parches, versiones de productos, situación en disco, librerías, etc, viene a ser un índice de todo lo que tenemos, como si fuera el Registro de Windows, pero solo la rama de Software, y en GNU/Linux el gestor de paquetes dpkg, por ejemplo (ni se acerca, pero esto lo digo mas o menos para que lo entendáis).

La zona DLIB es una zona donde se tiene un Í­ndice de todos los módulos que suministra IBM con los productos: Pueden ser fuentes, programas objeto, módulos de procedimientos, etc. Siguiendo con la analogía, una zona DLIB podría ser la /usr/src en GNU/Linux.

La zona TARGET en cambio, es la zona donde se controla todos los programas ejecutables y productos finales. Siguiendo con la analogía, seria la /lib y la /bin en GNU/Linux o todo ejecutable EXE o DLL en Windows.

Pues bien, como funciona todo esto? Pues en tiempo de instalación (SYSGEN), para crear un programa ejecutable en MVS, se linkedita con los módulos que sean necesarios de la DLIB y se crea el ejecutable en la Target, que a su vez se guarda en el disco que corresponda dentro de la librería que corresponda, como si se pareciera a un Makefile, oyes. Como veréis, este sistema de funcionamiento tiene muchas analogías con montar una Gentoo desde cero…

Vale, pero ¿Como instalo un parche?

El proceso de PTF tiene 3 fases bien diferenciadas: Recepción, Aplicación y Aceptación. La fase de recepción (RECEIVE) es cuando descargas la PTF de internet y la metes en el MVS y le dices a la GLOBAL que tienes una PTF descargada y lista para instalar. La GLOBAL entonces examina la PTF y determina que trozos de programas deben ser tocados, con la información de la TARGET y la DLIB.

La fase de Aplicación (APPLY) es la fase en la que instalas la PTF que te toca los módulos y programas que están en la TARGET, traduciendo, es cuando la PTF te toca el código para que inmediatamente quede instalada.

Y la ultima fase, la de aceptación (ACCEPT), es cuando ves que la PTF no ha “roto” nada y por tanto, esa PTF también toca la zona de DLIB para que los módulos fuente y objeto queden parcheados.

Esto da mucho juego, ya que si se instala mal la PTF siempre puedes volver atrás (siempre y cuando no hayas hecho un ACCEPT) en caso de que algo deje de funcionar, cosa poco probable, pero no imposible.

También comentar que según como quieras configurar el sistema, la instalación SMP/E puede tener varias zonas GLOBAL, varias DLIBs y varias TARGET, ya que IBM cataloga todos sus productos para mainframe en 4 bloques bien diferenciados: El Bloque OS, que incluye el z/OS, Cobol, VM, PL/I, y el sistema básico de un Sistema Operativo. Luego esta el DB, que incluye todo lo relacionado con bases de datos y tratamientos de datos: DB2, IMSDB, ImagePlus, etc. El tercer bloque hace referencia a todo lo transaccional, CICS, IMS, etc, y por último, el cuarto bloque es el del NCP o Communication Server, en el que se incluyen el propio NCP, el VTAM, TCP/IP, SNA, etc. Por tanto, se pueden llegar a tener, dependiendo de la instalación hasta 4 SMP/E distintos con toda su parafernalia de GLOBAL, DLIB y TARGET.

Así­ a primera vista parece que este sistema es muy manual, pero en realidad no lo es tanto, para mi es un sistema en el que controlas todo en todo momento y es muy eficaz y no te pasa como en Windows, que no sabes que hace cuando te instala algo (y lo peor es que una vez instalado un update en Windows, no lo puedes desinstalar).

Lo bueno de obligarte a leer los requisitos de una PTF es que aprendes mucho sobre la estructura interna y funcionamiento a nivel de programación de como se ensambla todo un Sistema Operativo, de verdad que si os gusta andar con las tripas de un ordenador, esto os encantará.

En un siguiente artículo, expondré un caso practico de cómo aplicar una PTF a un producto concreto para que veáis la mecánica, que no es tan difícil.

El la entrega anterior, vimos como generar un programa COBOL que llamaba a un mapa que mostraba un banner con el Texto Hola Mamones. En el tocho de hoy, vamos a complicar un poco el programa, con el fin de explicar como funciona el procedimiento pseudo-conversacional.

Para ello, añadiremos unos campos en los que, depende de lo que rellenemos, el programa escribirá un texto, o no escribirá nada, y se verá como en modo pseudo-conversacional el CICS no se quedará pillado con la tarea de esperar a que el usuario haga algo.

Como funciona el modo Pseudo-Conversacional?

En los sistemas monousuario / monotarea tradicionales (como DOS), cuando el usuario lanzaba un programa, el procesador dedicaba todos sus recursos a ese programa, y estaba siempre en memoria. Si el programa necesitaba la interacción del usuario, el programa en memoria paraba su ejecución, hasta que el usuario respondiera, pero la CPU no atendía nada más.

Como en un sistema multiusuario, esto es una grave pérdida de recursos, se diseño el modo de programación pseudo-conversacional. Esta metodología, implica que el programa se ejecuta desde el principio al lanzar la transacción que lo llama, hace una acción (por ejemplo, muestra una pantalla con campos a rellenar) y termina dicho programa (pero NO la transacción). Cuando el usuario hace algo (por ejemplo, da al Enter después de rellenar los campos), ese programa vuelve a ejecutarse desde el principio, hace una acción (por ejemplo, recoge los campos escritos por pantalla) y vuelve a terminar (aunque repito que NO la transacción). Esto hace que el CICS mientras el usuario está escribiendo algo, como el programa se ha ejecutado y ha terminado, no consuma nada de memoria RAM, salvo una pequeña zona de memoria común, que es la que controla el ámbito de la transacción, y como dicho área lleva la cuenta de por ejemplo, quien lanzó la transacción y desde donde, dicho programa se ejecutará siempre usando el área común de acuerdo a los parámetros de su sesión..

Os preguntaréis como si el MISMO programa, se ejecuta y termina, puede hacer cosas diferentes cada vez. Ahí reside la clave del pseudo-conversacional. Usando el área común de memoria del CICS asociada a esa transacción, a la que hemos dicho al programa que use tantos bytes de ella, yo puedo controlar cuando ese programa lo he lanzado por primera vez, o es una llamada que viene de antes, y todo con variables que defina dentro de ese área de memoria. Así que la clave es: tengo que saber que hace mi programa en cada momento, por que pasos se ejecuta, y guardar en ese área común los datos que yo considere necesarios para que el programa siga progresando hasta que la transacción se de por finalizada por el programa.

Vamos a programar un poco

Para ver esto de manera practica, voy a listar el programita que he hecho y os voy a explicar que proceso sigue, aunque no nos meteremos de lleno en el área común, porque francamente, solo haremos dos iteraciones del programa, una para mostrar el mapa y otra para dar un resultado. Para empezar, hemos cogido nuestro mapa BMS de la vez pasada y hemos modificado algunas cosas, añadiendo algunos campos, El código es el que sigue:

HOL2MP   DFHMSD TYPE=DSECT,MODE=INOUT,TERM=ALL,STORAGE=AUTO,LANG=COBOL
HOL2MP   DFHMDI SIZE=(24,80),LINE=1,COLUMN=1,COLOR=GREEN,HILIGHT=OFF,  X
MAPATTS=(COLOR,HILIGHT),DSATTS=HILIGHT,CTRL=FREEKB
DFHMDF POS=(1,1),LENGTH=6,INITIAL='HOL2MP',                   X
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(3,10),LENGTH=43,                                  X
INITIAL='PROGRAMA HOLA MAMONES PSEUDOCONVERSACIONAL',   X
ATTRB=(ASKIP,NORM),COLOR=RED
DFHMDF POS=(10,1),LENGTH=6,ATTRB=(ASKIP,NORM),                X
COLOR=YELLOW,INITIAL='CAMPO1:'
CAMPO1   DFHMDF POS=(10,10),LENGTH=10,ATTRB=(UNPROT,NORM,IC)
DFHMDF POS=(11,1),LENGTH=6,ATTRB=(ASKIP,NORM),                X
COLOR=YELLOW,INITIAL='CAMPO2:'
CAMPO2   DFHMDF POS=(11,10),LENGTH=10,ATTRB=(UNPROT,NORM)
MSG      DFHMDF POS=(20,10),LENGTH=60,ATTRB=ASKIP,COLOR=NEUTRAL
DFHMSD TYPE=FINAL
END

Este mapset y mapa lo hemos llamado HOL2MP, y como podéis ver, hemos añadido algunos campos: Por un lado, campos que solo muestran títulos por pantalla, y por otro, campos como CAMPO1, CAMPO2 y MSG, que serán los campos con los que trabajaremos con el programa. CAMPO1 y CAMPO2 serán editables (UNPROT) y el campo MSG que serán de mensajes que queremos que deje en caso de error o lo que nos dé la gana.

Si compilamos este mapa, veremos que la COPY que deberemos pegar en la WORKING-STORAGE SECTION, es algo más grande y con mas movidas que la primera que hicimos:

01 HOL2MP  PIC X(1000).
01  HOL2MPI REDEFINES HOL2MP.
02  FILLER PIC X(12).
02  CAMPO1L    COMP  PIC  S9(4).
02  CAMPO1F    PICTURE X.
02  FILLER REDEFINES CAMPO1F.
03 CAMPO1A    PICTURE X.
02  FILLER   PICTURE X(1).
02  CAMPO1I  PIC X(10).
02  CAMPO2L    COMP  PIC  S9(4).
02  CAMPO2F    PICTURE X.
02  FILLER REDEFINES CAMPO2F.
03 CAMPO2A    PICTURE X.
02  FILLER   PICTURE X(1).
02  CAMPO2I  PIC X(10).
02  MSGL    COMP  PIC  S9(4).
02  MSGF    PICTURE X.
02  FILLER REDEFINES MSGF.
03 MSGA    PICTURE X.
02  FILLER   PICTURE X(1).
02  MSGI  PIC X(60).
01  HOL2MPO REDEFINES HOL2MPI.
02  FILLER PIC X(12).
02  FILLER PICTURE X(3).
02  CAMPO1H    PICTURE X.
02  CAMPO1O  PIC X(10).
02  FILLER PICTURE X(3).
02  CAMPO2H    PICTURE X.
02  CAMPO2O  PIC X(10).
02  FILLER PICTURE X(3).
02  MSGH    PICTURE X.
02  MSGO  PIC X(60).

Veremos entre otras cosas las Redefines que hay entre el mapa de entrada y de salida, y si os fijáis (lo he puesto en negrita), están los campos de entrada y de salida (CAMPO1I, CAMPO1O, etc). Además, hay un campo interesante llamado CAMPOH, que asignándole un valor, podemos hacer que dicho valor parpadee, sea video inverso, etc.

Sin más, pasaré a poner el programa que he escrito, así lo explicaremos paso a paso. Lo he llamado HOL2, para que no interfiera con el primero que hicimos.

*************************************************************
*
*  PROGRAMA DE PRUEBA DE CICS-COBOL
*
*************************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. HOL2.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
*===============================================================
* LA COPY DEL MAPA GENERADO
*===============================================================
01 HOL2MP  PIC X(1000).
01  HOL2MPI REDEFINES HOL2MP.
02  FILLER PIC X(12).
02  CAMPO1L    COMP  PIC  S9(4).
02  CAMPO1F    PICTURE X.
02  FILLER REDEFINES CAMPO1F.
03 CAMPO1A    PICTURE X.
02  FILLER   PICTURE X(1).
02  CAMPO1I  PIC X(10).
02  CAMPO2L    COMP  PIC  S9(4).
02  CAMPO2F    PICTURE X.
02  FILLER REDEFINES CAMPO2F.
03 CAMPO2A    PICTURE X.
02  FILLER   PICTURE X(1).
02  CAMPO2I  PIC X(10).
02  MSGL    COMP  PIC  S9(4).
02  MSGF    PICTURE X.
02  FILLER REDEFINES MSGF.
03 MSGA    PICTURE X.
02  FILLER   PICTURE X(1).
02  MSGI  PIC X(60).
01  HOL2MPO REDEFINES HOL2MPI.
02  FILLER PIC X(12).
02  FILLER PICTURE X(3).
02  CAMPO1H    PICTURE X.
02  CAMPO1O  PIC X(10).
02  FILLER PICTURE X(3).
02  CAMPO2H    PICTURE X.
02  CAMPO2O  PIC X(10).
02  FILLER PICTURE X(3).
02  MSGH    PICTURE X.
02  MSGO  PIC X(60).
*===============================================================
* FIN DE LA COPY DEL MAPA GENERADO
*===============================================================
*
*
01 MI-COMMAREA.
03 CAMPOINICIO PIC X(8).
*
* COPIAMOS AYUDAS DE BMS PARA HACER BONITO EL TERMINAL
COPY DFHAID.
COPY DFHBMSCA.
*
LINKAGE SECTION.
PROCEDURE DIVISION.
*
IF EIBCALEN = 0
MOVE LOW-VALUES TO HOL2MP
PERFORM MANDAR-MAPONLY
PERFORM RETORNO-TRANS
END-IF.
*
EXEC CICS RECEIVE MAP('HOL2MP')
INTO(HOL2MPI)
NOHANDLE
END-EXEC.
*
EVALUATE EIBRESP
WHEN DFHRESP(NORMAL)
CONTINUE
WHEN DFHRESP(MAPFAIL)
PERFORM FALLO-MAPA
PERFORM FIN-PGM
END-EVALUATE.
*===============================================================
* RESPUESTA AL MAPA
*===============================================================
MOVE CAMPO1I TO CAMPO2O.
MOVE DFHBLINK TO MSGH.
MOVE 'OK!!' TO CAMPO1O.
MOVE 'HA!HA!HA! ESTOY USANDO LA MAINFRAME!!11!!1!' TO MSGO.
EXEC CICS SEND MAP('HOL2MP')
ERASE
FROM(HOL2MPO)
NOHANDLE
END-EXEC.
EXEC CICS RETURN
END-EXEC.
GOBACK.
*===============================================================
* PROCEDIMIENTO DEL PSEUDO-CONVERSACIONAL
*===============================================================
RETORNO-TRANS.
EXEC CICS RETURN
TRANSID(EIBTRNID)
COMMAREA(MI-COMMAREA)
LENGTH(8)
END-EXEC.
GOBACK.
*===============================================================
* RESTO DE PROCEDIMIENTOS
*===============================================================
MANDAR-MAPONLY.
EXEC CICS SEND MAP('HOL2MP')
MAPONLY
ERASE
NOHANDLE
END-EXEC.
*
FALLO-MAPA.
MOVE DFHBLINK TO MSGH.
MOVE 'FALLO DEL MAPA!' TO MSGO.
EXEC CICS SEND MAP('HOL2MP')
ERASE
FROM(HOL2MPO)
NOHANDLE
END-EXEC.
*
FIN-PGM.
EXEC CICS RETURN
END-EXEC.
GOBACK.

Como podéis ver, justo después de la COPY del mapa, hay una variable que he creado llamada MI-COMMAREA, de 8 caracteres de tamaño. Esta será ese área común que se mantendrá intacta durante el transcurso de toda la transacción.

También haremos una COPY de las ayudas que CICS nos brinda para poner colorines y parpadeos a nuestros mapas (DFHBMSCA), y la lista de IDentificadores de Atención, es decir, lo que significa para CICS si doy al Enter en mi terminal, o al PF3 (DFHAID). Esto hará que llevemos un control por si el usuario ha tecleado algo que no debía, o que hacer si ha dado al enter, o lo que sea.

Sin más, empezamos con los procedimientos, y los iré explicando a medida que sigamos el flujo de nuestro programa. Cuando lanzamos la transacción que invoca al programa HOL2, lo primero que va a hacer es comprobar si la longitud del área común de memoria (EIBCALEN) es cero. Esto nos indica si el programa es llamado por primera vez, o se ha ejecutado más veces. Si es cero, es que es la primera vez que llamamos al programa porque ese área todavía no se ha usado, en cambio si contiene algo, significa que el programa ya ha dejado algo anteriormente, por lo que nos indica que este programa ya ha sido invocado con anterioridad en esta transacción.
Resumiendo, con ese IF lo que estamos comprobando es si el programa se ha ejecutado por primera vez.

Siguiendo nuestro flujo, y dado que es la primera vez que lo lanzamos, la longitud es cero. Así pues, lo que va a hacer es inicializar la memoria que ocupara el mapa a ceros binarios para machacar los residuos de memoria que pudieran quedar en ese área por otra transacción y que pueden llegar a poner algún dato en algún campo “lo he visto” (LOW-VALUES) y seguidamente, llamará al procedimiento de MANDAR-MAPONLY. Este procedimiento enviará nuestro mapa con los 3 campos por pantalla, pero sin valores, para que el usuario tenga con que trabajar. El vería algo como esto:

HOL2MP

PROGRAMA HOLA MAMONES PSEUDOCONVERSACIONAL

CAMPO1
CAMPO2

Y seguidamente, ejecutamos un RETORNO-TRANS. Este procedimiento hace que el programa termine, pero no sin antes hacer un EXEC CICS RETURN y le pasemos nuestro ID único de la transacción que hemos lanzado y nuestro área común llamada MI-COMMAREA. A partir de este momento, en nuestra área común, CICS almacenará diversos datos (entre otros, el ID de nuestra transacción asociada a nuestro terminal), para que la transacción sepa donde se ha terminado de ejecutar nuestro programa. Así que el CICS esta libre para hacer caso a mas gente.

Mientras tanto, el usuario ha rellenado “HOLA” en el CAMPO1, y le ha dado al enter. En este momento, CICS recibe una interrupción porque alguien ha dado al enter en nuestro terminal, y como CICS sabe que transacción teníamos en ese terminal, vuelve a ejecutar el programa HOL2.

Atención: Ahora, la longitud del área común NO es cero, debido a que hemos grabado varias cosas al hacer el CICS RETURN de antes, así que el IF se lo salta y va directamente a ejecutar la recepción del mapa. Pueden pasar dos cosas: Que el mapa se reciba bien, con datos, y que se los pase a todos los campos que acaban en I (CAMPO1I, CAMPO2I), o que se reciba mal (sin rellenar). Para eso, usamos el control de errores de a continuación, de acuerdo a lo que contenga la variable EIBRESP.
Si DFHRESP es NORMAL, es decir, que no ha habido errores al recibir el mapa, continuamos y nos salimos de la evaluación. Eso hará que el programa continúe en secuencia y haga lo siguiente: Que mueva el contenido del CAMPO1I al CAMPO2O, que hagamos un parpadeo al campo de mensaje y que cuyo contenido de salida sea ‘HA!HA!HA! ESTOY USANDO LA MAINFRAME!!11!!1!’ y pondremos un OK en el CAMPO1O. Con estos datos, enviaremos el MAPA con un SEND MAP, y los campos que hemos tocado que acaban en O, son los que se visualizarán.

La pantalla sería algo como esto:

HOL2MP

PROGRAMA HOLA MAMONES PSEUDOCONVERSACIONAL

CAMPO1   OK!!
CAMPO2   HOLA

HA!HA!HA! ESTOY USANDO LA MAINFRAME!!11!!1!

Por último, saldremos del programa con un EXEC CICS RETURN, pero como no guardaremos nada con ese return en nuestra área común, ni siquiera nuestro ID de transacción, para el CICS eso significa que ha terminado nuestro programa y con ello, la transacción. Facilillo, no? Pues en esto se basa todo.

Supongamos que el usuario NO teclea nada, en vez de teclear algo. Para el CICS, eso es un FALLO, y debe ser tratado como tal. Hay que tener en cuenta que si al CICS no le das de comer datos, que va a procesar? Por eso lo trata como fallo. El fallo en este caso es el MAPFAIL, y eso lo sabremos cuando evaluemos el EIBRESP. Así pues, si el mapa ha fallado porque está carente de contenido, nuestro programa entonces ejecutará un procedimiento llamado FALLO-MAPA, que pondrá en mensaje FALLO DEL MAPA en el campo del mensaje MSGO, y luego hará una SEND del mapa. Y de ahí, se irá a FIN-PGM, que hará un EXEC CICS RETURN y saldremos del programa y de la transacción.

HOL2MP

PROGRAMA HOLA MAMONES PSEUDOCONVERSACIONAL

CAMPO1
CAMPO2

FALLO DEL MAPA!

A partir de aquí, es complicarlo como uno quiera. Se pueden usar las DFHAID para salirnos de la transacción si hemos pulsado F3, por ejemplo, o se pueden añadir mas campos, que sean leídos y escritos desde un fichero, en definitiva, se pueden hacer virguerías, pero todo se basa en lo mismo: un EXEC CICS RETUN con datos de nuestra área común para hacer que nuestro programa, que siempre se ejecutará una y otra vez hasta que al CICS RETURN no le pasemos nada, tenga los datos adecuados para tratar nuestro flujo del programa.