ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN

October 9, 2016 | Author: María Antonia Acuña Lagos | Category: N/A
Share Embed Donate


Short Description

1 ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN Titulación: INGENIERO E...

Description

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN

Titulación:

INGENIERO EN INFORMÁTICA

Título del proyecto:

INTEROPERABILIDAD Y MODERNIZACIÓN DE APLICACIONES EN ENTORNO MAINFRAME

Alumno: Mikel Castillejo Erviti Tutor: Federico Fariña Figueredo Pamplona, 25 de Febrero de 2011

Mikel Castillejo Erviti

Universidad Pública de Navarra

Objeto y desarrollo ......................................................................................... - 4 1.- Introducción .............................................................................................. - 8 1.1.- Introducción a los elemenos que vamos a utilizar.................................................. - 8 1.1.1.- Introducción a los mainframe ............................................................................. - 8 1.1.1.1.- Breve historia de los mainframe .................................................................. - 8 1.1.1.2.- Hardware y software de un mainframe ........................................................ - 9 1.1.1.3.- Data sets.................................................................................................... - 13 1.1.2.- Introducción a CICS ......................................................................................... - 15 1.1.2.1.- Qué es CICS .............................................................................................. - 15 1.1.2.2.- Transacciones............................................................................................ - 16 1.1.2.2.1.- Transacciones conversacionales/ pseudo-conversacionales.................. - 16 1.1.2.2.2.- Transacciones no-conversacionales ..................................................... - 16 1.1.2.3.- Programas ................................................................................................. - 17 1.1.2.4.- Tareas ....................................................................................................... - 17 1.1.2.5.- LUWs ........................................................................................................ - 18 1.1.3.- Introducción a TSO e ISPF ............................................................................... - 18 1.1.3.1.- TSO ........................................................................................................... - 18 1.1.3.2.- ISPF .......................................................................................................... - 20 1.1.3.3.- Ejemplos.................................................................................................... - 22 1.2.- Soluciones propuestas y solución elegida ............................................................. - 25 1.3.- Hardware y software necesario ............................................................................ - 29 1.3.1.- Hardware.......................................................................................................... - 29 1.3.1.1.- Hardware en la parte mainframe ............................................................... - 29 1.3.1.1.- Hardware en la parte del ordenador personal ........................................... - 30 1.3.2.- Software ........................................................................................................... - 30 1.3.2.1.- Software en la parte mainframe ................................................................. - 30 1.3.2.2.- Software en la parte del ordenador personal ............................................. - 30 -

2.- CICS Transaction Gateway .................................................................... - 32 2.1.- Introducción a CICS Transaction Gateway ......................................................... - 32 2.2.- Posibilidades en las arquitecturas y API’s ........................................................... - 34 2.2.1.- Posibilidades en las arquitecturas...................................................................... - 34 2.2.1.1.- Modo Local ............................................................................................... - 34 2.2.1.2.- Modo remoto ............................................................................................. - 35 2.2.2.- Posibilidades en las API’s ................................................................................ - 37 2.2.2.1.- ECI ............................................................................................................ - 37 2.2.2.2.- EPI ............................................................................................................ - 37 2.2.2.3.- ESI ............................................................................................................ - 38 2.2.2.4.- CCI............................................................................................................ - 38 2.2.2.5.- Posibles API’s según la arquitectura ......................................................... - 39 2.2.3.- Tipos de conexiones ......................................................................................... - 41 2.2.3.1.- Canales y Contenedores ............................................................................ - 42 2.3.- Instalación del CTG .............................................................................................. - 43 2.3.1.- Requisitos de instalación .................................................................................. - 43 2.3.2.- Configuración del sistema ................................................................................ - 44 2.3.2.1.- Reserva de puertos..................................................................................... - 44 2.3.2.2.- Configuración de la parte Unix ................................................................. - 45 2.3.2.3.- Miembro de variables de entorno............................................................... - 49 2.3.2.4.- Procedimiento de arranque ....................................................................... - 56 2.3.2.5.- Definiciones de RACF ............................................................................... - 57 2.3.3.- Creación de la conexión entre el CTG y el CICS .............................................. - 58 -1-

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.3.1.- Conexiones EXCI....................................................................................... - 59 2.3.2.- Conexiones IPIC .......................................................................................... - 62 2.3.4.- Arranque y parada del CTG .............................................................................. - 62 2.3.4.1.- Arranque del CTG ..................................................................................... - 62 2.3.4.2.- Parada del CTG ........................................................................................ - 64 2.4.- Prueba con COMMAREA .................................................................................... - 64 2.4.1.- Aplicaciones Java ............................................................................................. - 64 2.4.1.1.- Tipo de llamada ......................................................................................... - 70 2.4.1.2.- Nombre del servidor CICS ......................................................................... - 71 2.4.1.3.- Usuario ..................................................................................................... - 71 2.4.1.4.- Contraseña ................................................................................................ - 71 2.4.1.5.- Programa .................................................................................................. - 72 2.4.1.6.- Transid ...................................................................................................... - 72 2.4.1.7.- COMMAREA ............................................................................................. - 72 2.4.1.8.- Longitud de la COMMAREA ..................................................................... - 72 2.4.1.9.- Modo extendido ......................................................................................... - 73 2.4.1.10.- Token LUW.............................................................................................. - 73 2.4.3.- Transacción CICS ejecutada ............................................................................. - 73 2.4.4.- Manejo de LUWs ............................................................................................. - 74 2.4.5.- Conversión de datos ......................................................................................... - 76 2.4.5.1.- Conversión en el mainframe ...................................................................... - 76 2.4.5.2.- Conversión en la aplicación cliente ........................................................... - 77 2.4.2.- Aplicaciones .Net ............................................................................................. - 77 2.5.- Prueba con Canales y Contenedores .................................................................... - 81 2.6.- Seguridad............................................................................................................... - 85 2.7.- SSL......................................................................................................................... - 86 2.7.1.- Configuración de SSL ...................................................................................... - 86 2.7.2.- Realizar peticiones sobre SSL desde Java ......................................................... - 91 2.8.- Port Sharing .......................................................................................................... - 93 2.9.- Rendimiento .......................................................................................................... - 94 2.9.1.- Obtener estadísticas .......................................................................................... - 96 2.9.2.1.- Estadísticas ofrecidas por el CTG.............................................................. - 96 2.9.2.2.- Estadísticas desde SDSF ............................................................................ - 97 2.9.2.3.- Estadísticas desde Java ............................................................................. - 98 2.9.2.- Medidas de rendimiento ................................................................................. - 100 2.9.2.1.- Hilos administradores de conexiones ....................................................... - 100 2.9.2.2.- Hilos trabajadores ................................................................................... - 100 2.9.2.3.- Mostrar nombres TCP/IP ........................................................................ - 101 2.9.2.4.- Valores de timeout ................................................................................... - 101 2.9.2.5.- Logging de conexiones............................................................................. - 101 2.9.2.6.- Tamaño máximo del área de almacenamiento de Java o Java heap ......... - 101 2.9.2.7.- Objetos JavaGateway .............................................................................. - 101 2.9.2.8.- Tamaño de la COMMAREA ..................................................................... - 102 2.9.2.9.- Llamadas ECI síncronas o asíncronas ..................................................... - 102 2.9.2.10.- Trazas.................................................................................................... - 102 2.9.2.11.- Tamaño de la región y condiciones de “out of memory” ........................ - 102 2.9.2.12.- Tiempos de respuesta mediditos con estadísticas ................................... - 103 2.9.3.- Retraso introducido por el CTG ...................................................................... - 106 -

3.- CICS Service Flow Feature ...................................................................- 107 3.1.- Introducción a SFF ............................................................................................. - 107 -

-2-

Mikel Castillejo Erviti

Universidad Pública de Navarra

3.2.- Instalación de SFR y SFM .................................................................................. - 108 3.2.1.- Instalación del SFM........................................................................................ - 108 3.2.2.- Requisitos de instalación del SFR ................................................................... - 109 3.2.3.- Instalación del SFR ........................................................................................ - 109 3.2.3.1.- Configuración y ejecución del DFHMAINJ.............................................. - 109 3.2.3.2.-Configuración y ejecución del DFHMASET .............................................. - 113 3.3.- Flujo básico e instalación de flujos ..................................................................... - 114 3.3.1.- Crear el entorno de trabajo y configurarlo ....................................................... - 114 3.3.2.- Grabación de un primer flujo básico ............................................................... - 123 3.3.3.- Instalación del flujo ........................................................................................ - 139 3.3.4.- Comandos problemáticos en los flujos ............................................................ - 152 3.4.- Invocación de flujos............................................................................................. - 153 3.4.1.- Invocación por medio del CTG....................................................................... - 153 3.4.2.- Invocación por medio de servicios Web.......................................................... - 159 3.4.2.1.- Llamar a servicios Web desde Java ......................................................... - 160 3.4.2.2.- Llamar a servicios Web desde VB.Net ...................................................... - 163 3.5.- Flujo con alternativas.......................................................................................... - 166 3.6.- Flujo con bucles ................................................................................................... - 169 3.6.1.- Grabación de bucle con una pantalla de listado ............................................... - 177 3.7.- Elegir elemento de una página concreta............................................................. - 180 3.8.- Archivos que forman un flujo y borrado de flujos ............................................ - 192 3.9.- Tiempo de ejecución de flujos ............................................................................. - 196 -

4.- Conclusiones ...........................................................................................- 198 4.1.- Logros en los objetivos del proyecto ................................................................... - 198 4.2.- Vías futuras de trabajo ....................................................................................... - 199 -

Anexo 1.- Uso del BlueZone FTP ................................................................- 200 Bibliografía ..................................................................................................- 204 -

-3-

Mikel Castillejo Erviti

Universidad Pública de Navarra

Objeto y desarrollo Con este proyecto se trata de mejorar la interoperabilidad y modernizar las aplicaciones CICS que operan sobre un mainframe System z de IBM. En concreto, vamos a utilizar un mainframe IBM System z10 Business Class. En general, cuando nos refiramos a mainframe nos estaremos refiriendo al mainfarme que vamos a utilizar. Lo que vamos a buscar es integrar la lógica CICS dentro de otros sistemas de información externos al mainframe como pueden ser aplicaciones Java, .NET, etc. y “modernizar” en la medida de lo posible la interfaz que nos permite interactuar con esta lógica. El CICS o Customer Information Control System, parte fundamental de las mainframes System z de IBM, es un gestor transaccional o monitor de teleproceso que permite procesar transacciones tanto en forma online como batch. Las formas de acceder y operar con el CICS son: 

por medio de una terminal 3270, conocidas de manera informal, debido al color del texto en los modelos originales, como terminales de pantalla verde. Como podemos ver en la Figura 0.1, este tipo de terminales ni siquiera tienen ratón.

Figura 0.1 Terminal 3270

-4-

Mikel Castillejo Erviti



Universidad Pública de Navarra

por medio de un emulador Telnet3270 o TN3270 funcionando sobre un sistema operativo como puede ser Windows, Linux, etc. que tenga conexión con el mainframe. Esta es la forma de acceder más habitual hoy en día.

En ambos casos la interfaz es textual, es decir, la interfaz sólo usa texto para su funcionamiento, ya sea para dibujar ventanas, menús, etc. como para introducir datos y comunicarse con la interfaz. No es posible la utilización del ratón para pinchar en un menú y que se despliegue el menú o se ejecute una acción. Esta característica hace muy poco amigable su uso. Por ejemplo: 

La Figura 0.2 muestra un ejemplo de pantalla TN3270 con un formulario de entrada de datos. Se aprecia que sólo se usa texto para “dibujar” las pantallas en vez de elementos propios de las interfaces gráficas. Podemos apreciar que los lugares donde podemos introducir datos están subrayados en lugar de tener, por ejemplo, un cuadro de texto como tendríamos en una interfaz gráfica. Esto complica al usuario la labor de localizar las zonas de la pantalla dónde debe escribir. Además, dependiendo del emulador utilizado, ni siquiera se tiene la posibilidad de acceder a dichas zonas utilizando una herramienta intuitiva como el ratón, debe acceder empleando múltiples veces el tabulador o la tecla de salto de línea.

Figura 0.2 Pantalla TN3270 con formulario de entrada



La Figura 0.3 muestra otro ejemplo. En este caso se trata de un menú de personalización. La interfaz es poco clara: cada opción se debe seleccionar poniendo el símbolo “/” delante en lugar de utilizar un check box para seleccionar las opciones que deseemos.

-5-

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 0.3 Pantalla TN3270 con menú de configuración



La Figura 4 muestra un menú desplegable. Para desplegarlo hemos tenido que situar el cursor debajo de la letras del menú que queremos seleccionar y pulsar “ENTER” en vez de hacer clic con el ratón como haríamos en una interfaz gráfica.

Figura 0.4 Pantalla TN3270 con menú desplegable

Algunos simuladores de TN3270, como el que utilizaremos nosotros, permiten usar el ratón pero solo para situar el cursor en el lugar que queramos. Para ejecutar la acción que queramos llevar a cabo debemos aún pulsar “ENTER”.

-6-

Mikel Castillejo Erviti

Universidad Pública de Navarra

Tampoco es posible usar el botón derecho del ratón para acceder a diferentes opciones como copiar, pegar, etc. Para ello, y en caso de que lo permita el emulador que usemos, podemos configurar atajos de teclado. El problema es que dichas opciones las debe configurar cada usuario, no suelen venir configuradas por defecto en los diferentes emuladores. Es obvio que el uso de un interfaz de tipo texto, aunque pueda ofrecer un buen rendimiento y productividad para usuarios expertos, es difícil de usar para usuarios principiantes. En estos usuario provoca, además, un rechazo inicial por el aspecto “anticuado” y poco amigable de las pantallas que se nos muestran. Uno de los objetivos de este proyecto consiste en mejorar este modo de trabajo de modo que los usuarios dispongan de las funcionalidades que hoy en día son comunes a todos las interfaces gráficas por medio del ratón y los interfaces gráficos. La mejora de los interfaces se puede traducir en una mayor independencia del trabajador respecto al puesto de trabajo. Cada usuario puede tener configurado el emulador de diferente manera a fin de obtener las funcionalidades que su terminal no le proporciona. Esto puede hacer difícil que un usuario trabaje sobre el emulador de otro para hacer tareas puntuales. La introducción de interfaces más modernas y amigables (escritas en Java, .Net, etc.) haría innecesaria la personalización de los terminales. Por otra parte, normalmente no es posible integrar el tráfico TN3270 que se genera entre el mainframe en general, y el CICS en particular, con un emulador de terminal con otros sistemas de información externos al mainframe, como pueden ser aplicaciones escritas en Java o .NET, de forma que estas aplicaciones puedan trabajar con los datos recibidos al hacer peticiones al CICS. Esto proyecto también busca integrar la lógica CICS con otros sistemas externos, en concreto con aplicaciones Java y .NET, de forma que puedan interoperar entre ellos. A continuación vamos a ver la estructura del presente documento: 









Objeto y desarrollo o Muestra qué se pretende conseguir con el proyecto y la estructura del presente documento. Capítulo 1: Introducción o Explica brevemente los diferentes elementos que se van a utilizar en la realización del proyecto como qué es un mainframe, el CICS, etc. o Presenta diferentes soluciones para alcanzar los objetivos del proyecto y elige una de ellas. o Lista los diferentes elementos hardware y software que se van a necesitar para realizar el proyecto. Capítulo 2: CTG o Explica las posibilidades que ofrece una de las soluciones elegidas. o Muestra como instalar el producto. o Presenta diferentes pruebas llevadas a cabo. Capítulo 3: CSFF o Explica las posibilidades que ofrece otra de las soluciones elegidas. o Muestra como instalar el producto. o Presenta diferentes prueba llevadas a cabo. Capítulo 4: Conclusiones o Resume los logros conseguidos con este proyecto. o Presenta posibles vías de trabajo futuras.

-7-

Mikel Castillejo Erviti

Universidad Pública de Navarra

1.- Introducción 1.1.- Introducción a los elemenos que vamos a utilizar 1.1.1.- Introducción a los mainframe 1.1.1.1.- Breve historia de los mainframe Un mainframe, o computadora central, es un ordenador grande y potente usado principalmente para el procesamiento de grandes cantidades de datos como puede ser el procesamiento de transacciones bancarias. Tradicionalmente, un mainframe ha sido un ordenador pensado para el trabajo de proceso por lotes o BATCH. Este sistema se caracteriza en el tratamiento de grandes volúmenes de información, teniendo una entrada de datos, un proceso interno, y una salida de datos. Un típico proceso BATCH es, por ejemplo, el cierre diario de cuentas en un banco donde hay que actualizar el saldo de las cuentas con las operaciones que se han ejecutado en el día. El sistema va leyendo los ficheros de cuentas bancarias y los fichero de movimientos del día, estos son los datos de entrada, los procesa para actualizar el saldo y plasmar esos movimientos en la cuenta, proceso interno, y devuelve los ficheros de cuentas actualizados y, en algunos casos, los extractos informativos que se envían a las casa, salida de datos. Donde decimos el cierre de cuentas de un banco podemos decir el procesamiento de las nóminas de una empresa, la contratación de unas vacaciones o casi cualquier cosa que se nos ocurra. En general, un proceso BATCH es un proceso repetitivo que se realiza con millones de fragmentos de información. Nos hay que confundir con los llamados supercomputadores. Este tipo de ordenadores se centra en problemas limitados por la velocidad de cálculo mientras que los mainframe se centran en problemas limitados por los dispositivos de E/S y la fiabilidad. El primero realiza cálculos y operaciones muy complejas sobre una cantidad “reducida” de datos mientras que el segundo realiza operaciones más sencillas sobre miles o millones de datos. Normalmente, un supercomputador es usado en áreas científicas y militares para realizar cálculos muy complejos -8-

Mikel Castillejo Erviti

Universidad Pública de Navarra

mientras que un mainframe es utilizado por empresas que necesitan procesar grandes cantidades de datos como por ejemplo instituciones bancarias para procesar las transacciones que se han realizado a lo largo de un día. Entre los diferentes tipos de mainframes nos encontramos con los diferentes modelos de System z de IBM, que es el nombre que desde 2006 IBM le da a sus diferentes modelos de mainframe. Es sobre uno de estos modelos, el System z10, es sobre el que vamos a trabajar. En 1964, y con la llegada del transistor, IBM creo el primer mainframe de la historia, el Mainframe IBM System/360. Estosprimeros mainframe, aunque potentes, eran especialmente caros. A partir de esa fecha, y con la llegada el microprocesador, los costes se redujeron muchísimo y los mainframes empezaron a comercializarse a nivel de empresa, donde todos los procesos de producción Batch como nóminas, control de almacenes, etc. se volvieron muy eficaces. Esto hizo que se ahorraron grandes sumas de dinero y tiempo en cosas que antes se hacían de manera manual por lo que las empresas pagaban el gran precio que suponía uno de estos ordenadores. De esta forma ahorraban muchos miles de millones al año que antes invertían en realizar estas tareas de forma manual. En la década de los 70 y 80 aparecieron varios competidores a IBM en el terreno de los mainframe como Hitachi, Fujitsu, etc. que vendían diferentes tipos de mainframe aunque todos estaban basados en la arquitectura de los mainframe de IBM. Es por ello que a pesar de que cada uno tenía su propio sistema operativo, multiprogramación, etc. todos funcionaban prácticamente de la misma manera. En los años 70 ya era célebre el proceso interactivo donde miles de usuarios podían interactuar al mismo tiempo con el mainframe dando un buen tiempo de respuesta, realizando miles y miles de transacciones por segundo, consultas concurrentes a enormes bases de datos, etc. debido a que el sistema operativo era una pieza de gran precisión y eficacia. El único pero era el altísimo coste de los terminales, entre 12.000 y 20.000 euros de aquella época, que hacía que el tener terminales fuera un lujo demasiado caro. Sin embargo, en la década de los 80 estas máquinas bajaron su precio hasta los 2 o 3 millones de euros y, junto a la reducción también del precio de los terminales, hicieron que miles de empresas adoptaron esa forma de trabajar. En la década de los 90 IBM redujo bastante los precios para hacer frente al fenómeno Downsizing, un intento de descentralizar en arquitecturas más baratas toda la lógica del negocio, por lo que varios competidores abandonaron la producción de mainframes al no poder hacer frente a los precios que ofrecía IBM. Finalmente, los mainframe de IBM también se impusieron al fenómeno Downsizing debido a su gran robustez y eficiencia. Actualmente podemos encontrarnos con la posibilidad de tener un mainframe por un millón de euros, Con esto nos encontramos con una máquina muy potente, eficaz, con gran capacidad de almacenamiento, etc. lo que la hace muy apetecible para medianas-grandes empresas que diariamente tengan que realizar operaciones con miles o millones de datos. 1.1.1.2.- Hardware y software de un mainframe Actualmente, un modelo de mainframe de la serie System z es un armario de aproximadamente 2 metros de alto y casi otros tantos de ancho y largo, con un peso aproximado de 900 kilos, donde se sitúa los componentes principales de la máquina como lo que sería la CPU de un PC tradicional, su memoria RAM, el módulo que se encarga de gestionar el sistema de I/O, etc. En diferentes armarios situados aparte, y aproximadamente del mismo tamaño, nos encontramos con los distintos periféricos de E/S como pueden ser las unidades de cinta, de disco, etc.

-9-

Mikel Castillejo Erviti

Universidad Pública de Navarra

Estos módulos pueden tener su propio sistema operativo almacenado en firmware o en microcódigo que dotan al módulo de una cierta inteligencia. Actualmente las unidades de cinta de un mainframe son cartuchos de 300GB aunque se están empezando a comercializar unidades de 600GB y hasta de 1,2TB que, a un precio que no llega a los 60 euros, hace que esta forma de almacenamiento sea la más barata para almacenar grandes cantidades de datos, aunque también es la más lenta a la hora de acceder a la información. Por último, tendríamos diferentes conexiones externas utilizadas para operar con el mainframe. Entre estas nos podemos encontrar las terminales 3270 propiamente dichas, similares a la que hemos visto anteriormente, o un PC normal corriendo un emulador de 3270, un servidor de aplicaciones que realiza diferentes peticiones al mainframe, etc. En cuanto al software, el sistema operativo que utilizan estas máquinas también ha sufrido cambios desde sus inicios. Cuando IBM lanzó sus primeros modelos de mainframe, en 1964, desarrolló dos sistemas operativos llamados DOS y OS/360. El primero de ellos estaba pensado para máquinas pequeñas mientras que el segundo era el sistema operativo elegido en los mainframe más grandes y potentes. Nos vamos a fijar en este último ya que es su evolución la que ha dado lugar al sistema operativo z/OS que es el que vamos a utilizar. De este sistema operativo aparecieron varias versiones llamadas PCP, MFT y MVT: 





El primero, el PCP o Primary Control Program, era similar a DOS en el sentido de que ambos eran monotarea, aunque necesitaba más recursos para funcionar, por lo que prácticamente no llegó a salir de los laboratorios de IBM. El MFT, Multiprogramming with Fixed number of Tasks, Multipogramación con número Fijo de Tareas, salió en 1966, meses más tarde que el PCP, y fue el primer sistema operativo multitarea de la historia. Tenía la pega de que debías saber previamente cuanto iba a ocupar una ejecución de un proceso ya que si ocupaba más que la región seleccionada no se ejecutaba. El MVT, Multiprogramming with Variable number of Tasks, Multipogramación con número Variable de Tareas, era similar al MFT pero podía crear y borrar regiones de memoria sin tener que apagar todo el sistema por lo que no necesitabas conocer a priori cuanto iba a ocupar un proceso. A partir de esta versión evolucionó el sistema operativo z/OS actual.

Más adelante, al OS/360 se le añadió el TSO, o Time Sharing Option, que permitía a cientos de terminales trabajar simultáneamente contra la misma máquina. Del MVT se pasó al MVS, Multiple Virtual Storage, o Múltiple Almacenamiento Virtual, en 1974 cuando le añadieron múltiples espacios de direcciones virtuales. Este sistema operativo se renombró a MVS/370 con la llegada de los nuevos mainframes de IBM. Más tarde se renombró a MVS/XA y MSV/ESA por los nombres en inglés de arquitectura extendida y arquitectura de sistemas empresariales respectivamente. Con la llegada de los nuevos modelos z/390 y la compatibilidad con Unix se paso a llamar OS/390 en 1995 y finalmente con la llegada de los 64 bits y el cambio nombre de los mainframe a zSeries actualmente tenemos el z/OS desde el año 2000. En la Figura 1.1 podemos ver, por décadas, la evolución del sistema operativo z/OS, el que opera actualmente en los mainframe, junto con la inclusión de ciertos componentes al mismo.

- 10 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 1.1 Evolución del sistemas operativos z/OS IBM para mainframes

En la Figura 1.2 podemos ver la evolución del sistema operativo junto a la evolución de la arquitectura.

Figura 1.2 Evolución del sistema operativo z/OS y de la arquitectura

Aunque z/OS ofrece muchas de las funcionalidades de los sistemas operativos modernos también nos sigue ofreciendo muchas de las funcionalidades que ofrecía en sus orígenes, o en evoluciones anteriores del sistema operativos, como el soporte para COBOL, y el CICS, RACF, DB2, etc. que explicaremos más adelante. El actual sistema operativo z/OS soporta las APIs de Unix al tener una parte de compatibilidad con servicios Unix. También nos ofrece la posibilidad de tener en una misma máquina diferentes particiones lógicas o LPARs, de Logical PARtition, similar a las particiones que nos podemos encontrar en otros sistemas operativos. Esto nos ofrece la posibilidad de tener virtualmente diferentes máquinas independientes sobre un mismo mainframe, cada una de ellas ejecutando su propio sistema operativo. Cada LPAR puede compartir o tener de forma dedicada diferentes recursos hardware como procesadores, dispositivos de E/S, etc. Esto nos permite por ejemplo, teniendo una única máquina, hacer pruebas en una LPAR si riesgo a que un posible fallo ponga en peligro todo el sistema, tener diferentes configuraciones del sistema para diferentes propósitos, etc. - 11 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Una vez que hemos vista la evolución que ha sufrido el sistema operativo de los mainframe vamos a ver diferentes módulos o subsistemas que habitualmente nos podemos encontrar en un mainframe. Estos subsistemas son los siguientes:        

TSO JES2 SMP/E VTAM RACF Servicios UNIX de z/OS CICS DB2

El TSO, o Time Sharing Option, es un subsistema que nos permite accede al mainframe para trabajar con él. Es decir, por medio de un PC corriendo un emulador de terminal 3270, o de una terminal 3270 en caso de tenerla, puedo hacer login en una sesión de TSO. De esta forma puedo controlar cualquier elemento de la máquina que se quiera como ejecutar un programa, escribir, copiar, borrar, etc. un data set, similar a un fichero o archivo en un sistema operativo “tradicional”, etc. Es decir, es similar en un PC corriente a estar sentado delante de la pantalla realizando las operaciones que se consideren oportunas. El JES2, o Job Entry Subsystem versión 2, es el planificador de tareas del sistema. Tenemos un lenguaje de programación llamado JCL, Job Control Languaje, con el que podemos escribir programas tipo bat en MS-DOS a los que se les llama Job. Estos Jobs los podemos submitir, o ejecutar, de forma que entra en una cola de entrada del JES2 para su ejecución. El JES2 se encarga de gestionar todos aquellos recursos que necesitan los diferentes Jobs para ejecutarse sin que se produzcan bloqueos. Una vez terminada su ejecución almacena el resultado de ejecutar el Job en una cola de salida. El JES2 también controla programas cargados en memoria en forma de tareas que se puede inicializar en tiempo de arranque del sistema operativo, o más adelante en el momento que consideremos oportuno. Este tipo de tareas se llaman Started Tasks. Por último, un usuario conectado por medio de TSO será un TSU o Time Sharing User. Para el sistema operativo todos estos son usuarios, es decir, alguien o algo que necesita y obtiene recursos del sistema operativo. En función del tipo de usuario que sea, el JES2 lo tratará de diferente manera. El SMP/E, o System Modification Program/Extended, es una utilidad del sistema operativo z/OS, y también de sus predecesores. Nos permite instalar nuevos productos en nuestro mainframe, así como actualizar y aplicar parches a productos que ya tenemos instalados. También nos permite llevar un inventario de los productos instalados en nuestro sistema y de sus versiones, así como volver a versiones anteriores de un producto en caso de que las versiones instaladas nos den problemas. El subsistema conocido como VTAM, o Virtual Telecommunication Access Mode, nos proporciona la capa de red necesaria para la comunicación inter-procesos, comunicación con el exterior, etc. Originalmente funcionaba usando el protocolo SNA pero actualmente también puede hacer uso del protocolo TCP/IP. Al final, lo que hace esta segunda opción es encapsular el tráfico SNA dentro del TCP/IP.

- 12 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

El RACF, Resource Access Control Facility, es el subsistema que se encarga de proveer la capa de seguridad del sistema. Se encarga de dar acceso a los usuarios, dar permisos sobre los diferentes recursos del sistema, etc. También se encarga de definir qué programas pueden obtener recursos de otros programas, que ficheros pueden usar, etc. Los servicios UNIX de z/OS proveen al sistema operativo de un sistema operativo UNIX que algunos productos necesitan para funcionar. En nuestro caso, un producto lo va a necesitar para almacenar ciertos archivos de configuración mientras que otro lo va a necesitar para almacenar ciertos archivos de propiedades de los programas que desarrollemos. Por último, vamos a ver dos programas que no forman parte propiamente dicha del sistema operativo pero que si nos los podemos encontrar instalados en la mayoría de los mainframe. El CICS, o Customer Interface Control System, es un gestor transaccional o monitor de teleproceso que permite procesar transacciones tanto en forma online como batch. Este programa se arranca como una Started Task dentro del JES2. Diferentes usos de CICS nos los encontramos en las transacciones utilizadas en un banco para consultar en saldo de una cuenta o cuando vamos a reservar unas vacaciones en una agencia de viajes, donde la pantalla de la agencia de viajes normalmente trabaja contra una aplicación llamada Amadeus que está corriendo bajo CICS. Por otra parte nos encontramos con DB2, o DataBase 2, que es una robusta base de datos transaccional donde se almacenan la mayoría de los datos de un mainframe, lo que es similar a decir que almacena la mayoría de los datos “importantes” del mundo. Tiene multitud de herramientas para gestionarla, realizar consultas, etc. y también se arranca como una Started Task en el JES2. 1.1.1.3.- Data sets Una parte importante del sistema operativo de un mainframe son los data sets. Un data set, o conjunto de datos, es un archivo de un ordenador que tiene organización en forma de registros. El término pertenece a los sistemas operativos de los mainframes de IBM y se viene usando desde el OS/360 hasta el actual z/OS. Dependiendo de cómo están organizados los datos de un data set nos encontramos con:    

data set secuencial (physically sequential o PS) data set indexado (indexed sequential o IS) data set particionado (partitioned o PO) data set de acceso directo (direct access o DA).

Podríamos pensar en un PS como en un fichero y en un PO como en un árbol de directorios pero ahí acaba la similitud con el sistema de archivos de un sistema operativo Windows o Unix. Estos dos tipos de data sets son los más utilizados. Un data set particionado (partitioned data set o PDS) es aquel que contiene miembros dentro de él, cada uno a su vez conteniendo un conjunto de datos independientes entre sí. Como ya hemos dicho, esto es similar a un conjunto de directorios en otro sistema operativo. A este tipo de data sets también se les llama librerías ya que a menudo se utilizan para almacenar los programas ejecutables o librerías con los códigos fuente de los programas.

- 13 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Cada miembro de un PDS puede ser accedido de forma directa usando la estructura del data set. Una vez que hemos localizado el miembro que queremos se puede manejar de la misma manera que un PS. Cuando borramos miembros de un PDS este espacio queda sin utilizar. Lo mismo ocurre cuando modificamos un miembro ya que esto causa que automáticamente se almacene en otro sitio, dejando también ese espacio sin utilizar. Para que ese espacio se vuelva a utilizar hay que comprimir el data set. Además, cuando se llena el espacio asignado a un PDS, no podemos ampliarlo y hay que usar un nuevo PDS. Para solucionar estos problemas apareció el PDSE o PDS extendido. Además de solucionar estos problemas también cuenta con un índice para realizar de forma más rápida las búsquedas de un nombre de un miembro. Un data set secuencial (sequential data set o SDS) es aquel en el que la información está grabada de forma secuencial y para llegar a un cierto dato del data set tenemos que recorrer todos los datos anteriores por lo que se puede hacer la similitud con un fichero. En cuanto al nombre de un data set, hay varias cosas que tenemos que tener en cuenta. El nombre de un data set se forma por varios sub-nombres o cualificadores (qualifiers) separados por un punto. Por ejemplo, un nombre válido para un data set puede ser MIKEL.USER.FUENTES y otro MIKEL.USER.LOADLIB. Si es un PDS, al final, entre paréntesis, pondríamos el nombre del miembro, por ejemplo, MIKEL.USER.FUENTES(PROG1), para referirnos al miembro PROG1 dentro del data set MIKEL:USER:FUENTES. Hay que tener varias cosas en cuenta al darle un nombre a un data set:  El nombre completo, con todos sus cualificadores, tiene que ser de un máximo de 44 caracteres incluidos los puntos de separación entre cada cualificador  Se puede usar un máximo de 22 cualificadores  El primer cualificador se conoce como High Level Qualifier o HLQ (cualificador de alto nivel)  El último cualificador se conoce como Low Level Qualifier o LLQ (cualificador de bajo nivel)  Cada uno de los cualificadores tiene que ser de un máximo de 8 caracteres y empezar por un carácter alfabético o los símbolos @, $ o #  Se pueden usar lo caracteres alfabéticos, numéricos o los símbolos @, $, # o –  Normalmente se siguen cierta convenciones en los cualificadores o El HLQ de un data set de usuario está controlado por el sistema de seguridad o Las letras LIB indican que es una librería o Las letras JCL indican que contiene JCLs o Las letras LOAD o LINK indican que contiene ejecutables o Las letras PROC o PRC indican que contiene procedimientos JCL, por ejemplo procedimiento de arranque o Started Class o Usar muchos cualificadores se considera una mala práctica Un tipo particular de data set es el VSAM o Virtual Storage Access Method y se refiere tanto al tipo de data set como al método de acceso. Son data sets que proporcionan funciones más complejas que otros accesos a disco y además almacenan los registros de forma que no son entendibles por otros métodos de acceso.

- 14 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Estos data sets son usados por aplicaciones y no contienen programas fuente, JCLs o módulos ejecutables. Tampoco pueden ser editados o accedidos por medio de rutinas o con el ISPF que veremos más adelante. Dependiendo de la forma en que están organizados los registros nos podemos encontrar con cuatro tipos de data sets VSAM:  Key Sequenced Data Set o KSDS o Cada registro cuenta con uno o más campos de clave y los registros pueden ser accedidos o insertados por el valor de su clave  Entry Sequenced Data Set o ESDS o Son registros en orden secuencial usados por IMS, DB2 o z/OS Unix  Relative Record Data Set o RRDS o Permite accede a sus registros por su número aunque estos números son aleatorios. Asume que la aplicación tiene una forma de conocer los números de los registros  Linear Data Set o LDS o Los datos son un stream de bytes. Es el único stream de bytes en z/OS y raramente es usado en aplicaciones

1.1.2.- Introducción a CICS 1.1.2.1.- Qué es CICS CICS, o Customer Information Control System, Sistema de Control de Información de Cliente, es una familia de productos líder como sistema de procesamiento de transacciones online y pertenece a IBM. La familia de productos CICS engloba servidores de transacciones, conectores, como el CICS TG que veremos más adelante, herramientas de desarrollo y monitorización, etc. Aunque el nombre CICS hace referencia a una gran familia de productos, normalmente se utiliza para referirse al CICS Transaction Server para z/OS, o CICS TS. El CICS TS, simplemente CICS a partir de ahora, es un gestor transaccional o monitor de teleproceso que se instala en computadoras de tipo mainframe de IBM que funcionan con el sistema operativo z/OS. CICS está diseñado para procesar transacciones en modo online y batch y puede dar servicio a miles de transacciones por segundo. Normalmente el procesamiento de transacciones es interactivo con el usuario, a través de terminal, pero también es posible ejecutar transacciones en segundo plano sin la intervención del usuario. Como dato, la revista Fortune dice que más del 90% de las compañías pertenecientes a la lista Fortune 500 utiliza CICS funcionando sobre z/OS para el procesamiento de su negocio principal. Como gestor transaccional, CICS ofrece varias funcionalidades:  Controla los programas en ejecución al mismo tiempo que atiende a las peticiones de los usuarios conectados online.  Acceso a bases de datos y ficheros  Posibilidad de conectarse a otros miembros de la familia CICS a través de SNA o de TCP/IP  Proceso de recuperación y protección de datos en caso de producirse un problema en el sistema - 15 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Vamos a ver diferentes elementos que intervienen en la ejecución de aplicaciones dentro de CICS. 1.1.2.2.- Transacciones Una transacción es una unidad de procesamiento que consta de uno o más programas. Se inicia por medio de una petición, a menudo desde un terminal, aunque se puede realizar desde un sistema externo, desde la ejecución de otra transacción, etc., por lo general usando el identificador de cuatro caracteres de una transacción. Su ejecución puede requerir la apertura de una o más tareas. Además de las transacciones que podemos crear y definir, CICS provee una serie de transacciones de sistema, cuyo identificador empieza por C y que nos permiten realizar diferentes funciones. En este proyecto vamos a utilizar las siguientes:  CESN: Transacción suministrada por el sistema para identificarnos en el CICS.  CEMT: Permite solicitar información de los recursos CICS que se están ejecutando en el sistema y cambiar sus parámetros de control dinámicamente.  CEDA: Permite definir, modificar y consultar los recursos de CICS. También permite instalar los recursos definidos para que se ejecuten en el CICS.  CEDF/CEDX: Permite usar la Utilidad de Diagnóstico de Ejecución (Execution Diagnostic Faculity o EDF) para depurar programas.  CMAN: Permite manejar los flujos creados con el CSFF que veremos más adelante. Permite instalar nuevos flujos, habilitarlos y deshabilitarlos, borrarlos, activar trazas, etc. Tenemos que diferenciar dos tipos de transacciones según su tipo de ejecución:  Transacciones conversacionales/ pseudo-conversacionales  Transacciones no-conversacionales 1.1.2.2.1.- Transacciones conversacionales/ pseudo-conversacionales Estas transacciones son aquellas que interaccionan con el usuario. Por ejemplo, podría ser una transacción que te muestre los diferentes artículos que hay en un almacén y que se quede esperando a que pidas detalles sobre uno de ellos para darte más información sobre él como cantidad en stock, precio de venta a clientes, etc. Tanto la entrada como la salida de datos se realizan por medio de una terminal. La diferencia entre las transacciones conversacionales y las pseudo-conversacionales es que las primeras cargan un programa en memoria y permanece ahí hasta que finaliza su ejecución aunque no este activo, por ejemplo porque está esperando a una entrada de datos desde terminal. Las segundas cargan el programa en memoria pero realizan conexiones y desconexiones descargando el programa de memoria cuando está en espera, liberando así los recursos que está consumiendo la tarea. Este segundo tipo requiere un modo especial de codificar los programas de forma que se establezcan una serie de ciclos que permiten proseguir una tarea a partir del punto en que se produzco la última desconexión. 1.1.2.2.2.- Transacciones no-conversacionales Este segundo tipo de transacciones son aquellas a las que se les pasa un área de datos con los parámetros que necesita para la ejecución y devuelve los resultados de la misma forma, sin que el usuario interactúe con la transacción mientras se está ejecutando. Un ejemplo sería una transacción a la que le pasamos en un área de datos un apellido y nos devuelve todos los - 16 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

usuarios que hay en un sistema con ese apellido pero no nos permite, por ejemplo, interactuar con la transacción por medio de una terminal para pedir más detalles sobre un usuario. Según el tipo de área de datos que utilicemos para comunicarnos con las transacciones nos encontramos con transacciones basadas en COMMAREA o basadas en Canales y Contenedores. Aunque más adelante explicaremos que es cada una y sus similitudes y diferencias, básicamente una COMMAREA es un área de memoria que contiene datos pero que no posee ni nombre ni formato. Los Canales y Contenedores son áreas de memoria que contiene datos y además tienen un nombre y formato. Por ejemplo, la información de una persona, como DNI, nombre, primer apellido, etc. en una COMMAREA estaría toda seguida. Con los Canales y Contenedores tendríamos una zona llamada DNI con la información correspondiente, otra para el nombre, primer apellido, etc.

1.1.2.3.- Programas Un programa es el conjunto de instrucciones que se ejecutan en el CICS para llevar a cabo una determinada tarea. Los programas en CICS pueden estar escritos en los siguientes lenguajes:      

Ensamblador COBOL PL/I C C++ Java

En cuanto a los lenguajes utilizados, algunos estudios revelan los siguientes datos:    

El 85% de todos los programas en mainframes están escritos en Cobol El 7% están escritos en ensamblador, C o C++ El 5% están escritos en PL/I El 3% están escritas en Java

La mayoría de las instrucciones que se van a ejecutar se expresan usando las instrucciones propias del lenguaje pero, para hacer peticiones de servicios CICS, tenemos que usar alguna de las siguientes opciones:   

Comandos EXEC CICS proporcionados por la API de programación de aplicaciones de CICS Biblioteca de clases de Java para CICS (JCICS) Biblioteca de clases de C++ para CICS

1.1.2.4.- Tareas Una tarea es una instancia de la ejecución de una transacción. CICS. El CICS junto con el sistema operativo, maneja el control de múltiples tareas mediante la asignación de un proceso de sistema a cada tarea. Mientras que una tarea está a la espera, por ejemplo a la espera de leer un

- 17 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

archivo o esperando la respuesta desde una terminal, el sistema operativo puede dar el control a otra tarea. 1.1.2.5.- LUWs La ejecución de transacciones dentro del sistema se puede agrupar en unidades lógicas de trabajo (Logical Units of Works o LUWs). Cada LUW es un conjunto de cambios asociados a los datos. Por ejemplo, en un sistema de contabilidad, una LUW consiste en la actualización de las cuentas por pagar, la actualización de los libros, y la creación de un cheque donde cada parte de la LUW podría ser una transacción. El trabajo que realiza cada LUW es completamente independiente de la labor que realiza cualquier otra LUW. Si una LUW realiza modificaciones en múltiples recursos, todos ellos se modifican satisfactoriamente o no se modifica ninguno de ellos. El sistema de procesamiento de transacciones se asegura de que, cuando varios usuarios tienen acceso a los recursos, los cambios parciales que se realizan en una LUW no son puestos a disposición de otros usuarios hasta que la LUW se ha completado. Una LUW puede terminar correctamente y verificar los cambios, commit, o producirse un error en su ejecución y deshacer los cambios realizados, backout o rollback. Cuando una LUW realiza commit sus cambios son permanentes.

1.1.3.- Introducción a TSO e ISPF 1.1.3.1.- TSO La utilidad TSO, Time Sharing Oprtion u Opción de Tiempo Compartido, es un entorno interactivo de tiempo compartido utilizado para realizar la mayoría de las tareas sobre el sistema operativo z/OS de IBM, aunque está disponible desde el sistema operativo OS/MVT. TSO primeramente se ofrecía como una opción en los primeros sistemas operativos MVT pero paso a formar parte del sistema operativo a partir de la salida del MVS en 1974 y se ha mantenido hasta nuestros días. TSO permite a cientos o miles de usuarios tener acceso a MVS al mismo tiempo pero de forma que para cada usuario parezca que es el único usuario en el sistema. Algunas de las tareas que podemos realizar por medio del TSO es el de crear y modificar Jobs, que luego podemos submitir, comprobar los resultados producidos por los Jobs sin tener que esperar a que se produzcan informes por escrito, gestionar data sets, etc. Aunque TSO se puede utilizar en modo línea-por-línea donde escribimos un comando y esperamos a que nos devuelva una respuesta, el modo más común de usarlo es por medio de menús o paneles. El uso de TSO por medio de paneles se realiza a través de otra utilidad llamada ISPF y a la combinación de ambos se conoce como TSO/ISPF. Desde cualquier panel en el que estemos, tenemos una línea de comandos desde donde podemos ejecutar comando de TSO. TSO también se utiliza para acceder al entorno de tipo Unix que hemos comentado anteriormente. Tenemos la opción de acceder a los servicios Unix por ISH o por OMVS. El primero, también conocido como ISHELL o ISPF Shell, proporciona una interfaz por paneles similar a la de TSO e ISPF que veremos más adelanta. Para acceder a esta interfaz podemos simplemente ejecutando desde cualquier menú o panel en el que nos encontremos el siguiente comando: tso ish

- 18 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

También podemos acceder a ISH por medio de los paneles con la opción OM y luego, dentro de esta, con la opción ISH. En la Figura 1.3 podemos ver la pantalla inicial de ISH.

Figura 1.3 Pantalla inicial de ISH

Una vez que hayamos introducido el path al que queremos acceder, nos encontraremos con una pantalla similar a de la Figura 1.4 desde nos manejaremos por paneles de forma similar a como lo hacemos en TSO.

Figura 1.4 Pantalla de ISH

- 19 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

El segundo método proporciona una interfaz similar a la consola de comando de un sistema operativo Unix/Linux. Para acceder a este método ejecutamos desde cualquier menú el siguiente comando: tso omvs Con ello accederemos a la pantalla mostrada en la Figura 1.5 desde nos manejaremos de forma similar a una consola de comando UNIX, incluyendo los mismos comandos, etc.

Figura 1.5 Pantalla de OMVS

1.1.3.2.- ISPF ISPF es una aplicación que nos permite, por medio de paneles, realizar diferentes operaciones sobre TSO como por ejemplo manejar data sets, introducir comandos de TSO, etc. Para poder hacer uso de ISPF el usuario primero se ha tenido que autentificar en el sistema por medio de TSO. ISPF provee al usuario de un editor de textos, un navegador de archivos, así como funciones para localizar y listar data sets. Normalmente ligado a ISPF va el PDF o Product Development Facility que es la utilidad usada para manipular data sets secuenciales o miembros de data set particionados. Aunque frecuentemente ISPF es utilizado para manipular archivos por medio del PDF, el ISPF es ampliable y se puede utilizar como interfaz para operar con otros programas o utilidades. De hecho, muchos productos que vende IBM para MVS utilizan los paneles de ISPF para acceder a sus herramientas. La Figura 1.6 muestra un miembro de un data set que hemos abierto por medio del ISPF/PDF y que podemos consultar, modificar, etc. En la parte superior de la pantalla podemos observar como el miembro abierto es el PREGCONG del data set D424350.USER.JCLLIB.

- 20 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 1.6 Archivo abierto con ISPF/PDF

Para poder submitir este miembro, simplemente escribimos “sub” en la línea “Command” n la parte superior de la pantalla y pulsamos Control. En la Figura 1.6 también podemos observar, en la parte inferior, otro de los “inconvenientes” de una interfaz de tipo texto. Para desplazarnos arriba y abajo en un data set, también en un menú de opciones, un listado, etc. no podemos hacer uso de una barra de desplazamiento o de la rueda de ratón, sino que tenemos que usar teclas programadas para tal fin, normalmente F7 para ir hacia arriba y F8 para ir hacia abajo. Los seis primeros caracteres nos indican la línea del data set en la que nos encontramos pero también nos permiten realizar tareas como copiar, borrar, etc. Por ejemplo, si quisiéramos copiar la línea 18 debajo de la línea 30 situaríamos el cursor sobre alguno de los seis primeros caracteres de la línea 18, escribiríamos c y pulsaríamos Control (el equivalente a ENTER en nuestro emulador de terminal). A continuación situaríamos el cursor en la línea 30, escribiríamos a (para que se copie la línea seleccionada a continuación de la 30) y pulsaríamos Control de nuevo. A continuación podemos ver un listado de alguna de las operaciones que podemos realizar usando estos seis primeros caracteres de cada línea.  i Insertar una línea. Cada vez que hayamos escrito algo en una línea, pulsaremos ENTER (Control en nuestro emulador) para insertar una nueva línea sin necesidad de volver a escribir i. Para salir del modo de inserción pulsaremos ENTER sin haber escrito nada.  i5 Insertar cinco líneas  d Eliminar una línea  d5 Eliminar cinco líneas  dd/dd Eliminar un bloque de líneas. Si queremos borrar desde la línea 6 hasta la 10, escribimos dd en la línea 6 y lo mismo en la línea 10 y pulsamos ENTER.  r Repetir una línea  rr/rr Repetir un bloque de líneas

- 21 -

Mikel Castillejo Erviti     

Universidad Pública de Navarra

c Copiar una línea. Con a o b la pegamos antes o después de la línea seleccionada c5 Copiar 5 líneas. Las pegamos con a o b cc/cc Copiar un bloque de líneas m Mover una línea. Al igual que con los comandos de copiar, m5, mm/mm y su uso con a o b son opciones válidos x Excluir una línea. No la borra, simplemente no la muestra por pantalla

1.1.3.3.- Ejemplos A continuación vamos a poder ver unos ejemplos de TSO/ISPF. Cundo abrimos una sesión de TSO, y una vez identificados en el sistema, nos vamos a encontrar con una pantalla mostrada en la Figura 1.7.

Figura 1.7 Pantalla inicial de TSO

En esta pantalla podemos ver las diferentes operaciones que podemos ejecutar. Para seleccionar una de estar operaciones bastaría con teclear los caracteres que aparecen en blanco ligados a cada una de las operaciones o utilizar algunas de las teclas PF, Programable Function Keys, o Teclas de Función Programable, normalmente las teclas F1-F12, para realizar otro tipo de tareas, por ejemplos F8 para pasar a la siguiente pantalla del listado de operaciones. Por ejemplo, para accede a una utilidad muy usada como es el ISPF/PDF, para poder trabajar con data sets, nos bastaría con teclear P y pulsar ENTER. Esto hará que nos aparezca la pantalla de la Figura 1.8 que nos muestra las diferentes opciones del ISPF/PDF.

- 22 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 1.8 Opciones de ISPF

Ahora, la forma de seleccionar la opción deseada es por medio de números en vez de letras como antes pero funciona de la misma manera. Estando en la pantalla de la Figura 1.7, si sabemos que la opción a la que queremos acudir es directamente la 0 del ISPF/PDF, en vez de tener que teclear P, pulsar ENTER, teclear 0 y pulsar ENTER, podemos directamente teclear P.0 y pulsar ENTER. De esta forma podemos ir rápidamente a la opción que queramos siempre que sepamos el camino que hay que seguir. Por ejemplo es muy usada la opción P.3.4 para buscar data sets. También desde la pantalla principal del ISPF/PDF, Figura 1.8, podemos ir directamente a una opción, por ejemplo tecleando 3.4. La P en este caso no hay que introducirla ya que sirve para ir a la pantalla principal del ISPF que es donde nos encontramos. Otra opción muy usada es la SD que nos permite acceder a la utilidad llamada “System Display and Search Facility” o SDSF. Esta utilidad permite listar y buscar diferentes jobs que se están ejecutando, salidas de jobs ya ejecutados, estado de Started Tasks, TSU conectados, etc. En la Figura 1.9 podemos ver la pantalla inicial del SDSF que nos permite acceder por ejemplo a la cola de usuarios activos, tanto Started Tasks como TSUs, colas de entrada, salida, etc.

- 23 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 1.9 Pantalla inicial del SDSF

Por ejemplo, si nos dirigimos a la opción DA, podemos ver los usuarios activos como las Started Tasks, los usuarios conectados al TSO o TSUs y los jobs. Por ejemplo, en la Figura 1.10 podemos ver una lista de Started Tasks como pueden ser diferentes CICS que están en ejecución, CTGs, etc.

Figura 1.10 Lista de Started Tasks

Podríamos seleccionar una de estas Started Tasks y ver más detalles sobre ellas como posibles errores que se hayan producido en el CICS, conexiones realizadas a un CTG, etc. Desde el SDSF es desde donde arrancaremos y pararemos los CTGs y listaremos sus estadísticas.

- 24 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

1.2.- Soluciones propuestas y solución elegida Entre las diferentes soluciones que satisfacen parte o todos los objetivos que buscamos con nuestro proyecto, nos encontramos con dos grupos de soluciones diferentes. Por un lado tenemos los conectores y adaptadores que permiten a sistemas externos realizar peticiones a CICS. Normalmente estos conectores o adaptadores permiten desde un servidor de aplicaciones como puede ser WebLogic o Websphere conectarse a un mainframe IBM y hacer peticiones al CICS. Esto permite, aparte de integrar la lógica CICS con otros sistemas externos, mejorar la presentación a la hora de hacer peticiones a transacciones CICS y recibir los datos que este nos devuelva. Por ejemplo, podemos arrancar una transacción pulsando un botón o link sin tener que acordarnos de su identificador. Los datos que nos devuelva los podemos mostrar en una tabla por la que nos podemos desplazar usando la rueda del ratón en vez de las teclas PF. En la mayoría de los casos, estas soluciones necesitan tener instalado CICS Transaction Gateway en nuestro sistema. Entre las diferentes soluciones encontradas de este tipo tenemos las siguientes: 





Librados – JCA Plus Adapter for CICS o Adaptador desarrollado por Oracle o Permite, en un principio desde cualquier servidor de aplicaciones conectarse a un mainframe y hacer peticiones CICS o Necesita que esté instalado el CICS Transaction Gateway Atunnity CICS Adapter o Solución desarrollada por la empresa Attunity o Permite, por medio de peticiones XML, que pueden realizarse desde .NET, Java, etc., realizar peticiones CICS a un servidor Attunity instalado en el mainframe JBI4CICS o Solución desarrollada por la empresa Imola Project Partners o Conector que permite, sobre un Enterprise Service Bus, Bus de Servicios de Empresa, llamado OpenESB, realizar peticiones CICS o Necesita del CICS Transaction Gateway para funcionar

Las desventajas que plantean estas soluciones son varias:  

Necesitamos tener instalado algún otro elemento como un servidor de aplicaciones o un bus ya que no podemos utilizarlo desde aplicaciones de escritorio. Ante cambios en la versión de CICS, nos podemos quedar sin servicio temporal o definitivamente hasta que se adapten a los cambios producidos.

En la línea de este tipo de soluciones, y viendo que muchas de ellas lo necesitan, vamos a ver el CICS Transaction Gateway. El CICS Transaction Gateway, o CTG, es un componente de la empresa IBM que se instala en el mainframe y actúa como intermediario entre el CICS y sistemas externos para enviar y recibir peticiones. Aparte del componente instalado en el mainframe, también suministra un conector que puede ser desplegado en un servidor de aplicaciones y una sería de librerías que pueden ser utilizadas desde aplicaciones de escritorio o por medio de Servlets, de forma que nos provee de una API para realizar peticiones al CICS. Las ventajas que ofrece está solución son varias:

- 25 -

Mikel Castillejo Erviti  

 

Universidad Pública de Navarra

Es de IBM con lo que aseguramos una compatibilidad completa con el resto del sistema. Por la misma razón, nos aseguramos el funcionamiento ante posibles cambios en la versión del CICS ya sea desde la versión que tengamos actualmente o actualizándonos a las nuevas versiones que puedan aparecer. Suministra tanto conectores como librerías para poder realizar peticiones tanto desde servidores de aplicaciones como desde aplicaciones de escritorio. Permite enviar y recibir peticiones desde aplicaciones escritas en los siguientes lenguajes: o .NET o C o C++ o COBOL o Java

El mayor inconveniente del CICS Transaction Gateway es que, debido a la arquitectura de nuestro sistema, como veremos más adelante, no es posible realizar peticiones de transacciones conversacionales o pseudo-conversacionales, es decir, aquellas que presentan pantallas. Este problema también lo vamos a tener en la mayoría de las otras soluciones vistas al hacer uso estas del CICS Transaction Gateway. El CICS Transaction Gateway no viene junto con la licencia de CICS TS por lo que hay que pagar por él. Viendo las desventajas que ofrecen otras soluciones, además de que muchas de ellas necesitan el CICS Transaction Gateway, junto con las ventajas que esta última solución presenta, nos decantemos por el CICS Transaction Gateway entre este tipo de soluciones. El inconveniente de no poder llamar a transacciones con pantallas lo solucionaremos con la segunda solución elegida. Para solucionar el inconveniente del CICS Transaction Gateway de no poder llamar a transacciones que presentan pantalla lado tenemos los maquilladores de pantallas 3270. Estas soluciones reciben tráfico 3270 y lo convierten en páginas Web o en pantallas “normales” de un ordenador de forma que podamos usar el ratón, utilizar atajos de teclado para copiar, pegar, etc. Con esto logramos “modernizar” la interacción con la lógica CICS ya que transformamos una interfaz textual en una interfaz gráfica. Entre este tipo de soluciones tenemos las siguientes: 





Micro Focus OnWeb o Producto de la empresa Micro Focus o Muestra las “pantallas verdes” de un mainframe como páginas web o interfaces .NET Passport Web-to-Host o Solución de la empresa Passport o Permite conectarnos al mainframe desde un navegador Web OpenText Terminal Emulation o Producto de la empresa OpenText o Permite accede al mainframe desde el escritorio o desde un navegador web

El mayor problema de este tipo de soluciones es que normalmente introducen un retardo significativo en la comunicación entre el cliente web y el mainframe, que puede ir desde varios cientos de milisegundos hasta algunos segundos lo que hace que la comunicación no sea fluida y que la productividad caiga drásticamente. - 26 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Tampoco podemos hacer uso directo de los datos recibidos en otros sistemas externos sino que desde una aplicación Java, por ejemplo, abría que leer el código HTML o XML que nos llega y extraer los datos para poder operar con ellos. Una solución que no sigue exactamente la línea de las anteriores pero que nos va a permitir llamar a transacciones con pantallas por medio del CICS Transaction Gateway es el CICS Service Flow Feature. Este producto de IBM nos permite agregar múltiples llamadas a transacciones CICS en un solo flujo. También permite automatizar ciertas interacciones con pantallas 3270, como introducción de las opciones necesarias para llegar a la operación que queremos realizar, de forma que podamos reproducir este flujo simplemente pasándole los datos de entrada necesarios. De esta forma podemos grabar flujos que simulen la interacción con una transacción con pantallas, instalar este flujo en el CICS TS y luego invocarlo por medio del CICS Transaction Gateway. Esto nos permite llamar a transacciones conversacionales o pseudo-conversacionales, cuya interacción con el usuario hemos grabado previamente, desde el CICS Transaction Gateway. También mejora la eficiencia al juntar múltiples peticiones en una sola y automatizar ciertas interacciones con la transacción. Nos permite además invocar estos flujos desde servicios Web. Aunque no es una de las características del SFF que más vamos a utilizar en este proyecto, también explicaremos como utilizarla. Pongamos por ejemplo que en una transacción bancaria tenemos que introducir una opción para ir a las cuentas de usuarios, meter el número de cuenta sobre la que queremos operar, introducir la opción de agregar saldo y por último introducir el saldo que queremos añadir a la cuenta. Grabando estas interacciones con la transacción bancaria en un solo flujo simplemente le pasaríamos como datos de entrada el número de cuenta y el saldo que queremos añadir. Él se encargaría de introducir de forma automática las opciones para ir a las cuentas de usuario y para acceder a la operación de agregar saldo que hemos grabado, mejorando así la eficiencia. En la Figura 1.11 vemos como sería un flujo “normal” donde tenemos que interactuar varias veces con el CICS para obtener el resultado requerido.

Figura 1.11 Múltiples interacciones y peticiones para realizar una operación

- 27 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

En la Figura 1.12 vemos que, grabando y reproduciendo el flujo anterior por medio del CICS Service Flow Feature, sólo necesitamos una interacción con el CICS, para decirle que flujo queremos ejecutar y pasarle los datos de entrada, en caso de necesitarlos, y este nos devuelve los resultados obtenidos.

Figura 1.12 Una sola interacción y petición para realizar una operación

Al llamar a los flujos por medio del CICS Transaction Gateway, vamos a poder integrar esta solución son otros sistemas externos, ya sean Java, .NET, etc. de forma que podemos operar directamente con los datos que recibimos. Al igual que con el CICS Transaction Gateway, al ser un producto de IBM la compatibilidad con cada versión de CICS que va apareciendo es completa. El único inconveniente es que cada uno de los flujos que más adelante queremos utilizar hay que grabarlo previamente. Aunque esto al principio puede parecer costoso, grabar un flujo con 5 o 6 pantallas no cuesta más de 15 minutos, tiempo que a la larga vamos a recuperar al no tener que volver a introducir los mismos datos y opciones de navegación entre pantallas una y otra vez. Hay que indicar que el CICS Flow Feature consta de dos partes. Por un lado tenemos el Service Flow Runtime, o SFR, que es un componente que se instala en el mainframe y que permite ejecutar los flujos grabados. Este componente es gratuito y lo podemos instalar en cualquier mainframe en el que tengamos una licencia del CICS TS. Por otro lado tenemos el Service Flow Modeler, o SFM, que es la herramienta que utilizamos para grabar los flujos y que se utiliza desde un ordenador personal. El SFM forma parte del módulo Enterprise Service Tools que a su vez forma parte del Rational Developer for System z. Para poder ejecutar este último necesitamos el Rational Business Developer. Estos programas son de pago y permiten realizar otras muchas tareas como desarrollar programas COBOL para CICS, crear servicios web que podemos ejecutar en el mainframe, etc. Por estas razones elegimos el CICS Service Flow Feature para solucionar la limitación del CICS Transaction Gateway de no poder trabajar con transacciones que presentan pantallas.

- 28 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

1.3.- Hardware y software necesario Para realizar este proyecto vamos a necesitar dos máquinas. Por un lado vamos a necesitar un mainframe donde instalar el CICS Transaction Gateway y el Service Flow Runtime. Por otro lado vamos a necesitar un ordenador personal que vamos a utilizar para desarrollar y probar aplicaciones que se conecten al mainframe. Opcionalmente podríamos hacer uso de otra máquina donde tener instalado un servidor de aplicaciones desde donde hacer las pruebas aunque los propios programas que vamos a utilizar para desarrollar aplicaciones nos permiten simular un servidor de aplicaciones desde donde probarlas. Vamos a especificar los componentes hardware que vamos a necesitar en el mainframe así como en el ordenador personal que utilicemos para conectarnos al mainframe y realizar las pruebas y los componentes software que vamos a necesitar tanto en el mainframe como en el ordenador personal. 1.3.1.- Hardware 1.3.1.1.- Hardware en la parte mainframe El único hardware que vamos a necesitar en la parte mainframe es el propio mainframe que va a ser un IBM System z10 Business Modelo M03 similar al que podemos ver en la imagen.

Figura 1.13 Mainframe System z10

En concreto, el nuestro dispone de las siguientes características:  



16 GB de memoria RAM 1 procesador IFL o Procesador especial para poder instalar Linux para System z o No confundir con la parte Unix del z/OS 1 procesador zIIP o Procesador especial para DB2

- 29 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

1.3.1.1.- Hardware en la parte del ordenador personal El hardware necesario en el ordenador personal es el propio ordenador que cumpla los requerimientos necesarios para poder ejecutar el software que veremos a continuación. En particular, vamos a utilizar un ordenador con las siguientes características:    

Pentium 4 a 3.20 GHz 80 GB de disco duro 1.5 GB de RAM Lector de DVDs

Este ordenador cumple todos los requerimientos de hardware del software que vamos a utilizar. Aunque el Rational Business Developer pide una cantidad recomendad de RAM de 2 GB, la cantidad necesaria es de 1 GB y la experiencia nos dice que 1.5 GB es suficiente para su funcionamiento.

1.3.2.- Software 1.3.2.1.- Software en la parte mainframe El software que vamos a necesitar en la parte mainframe es el siguiente, las versiones podrían ser otras siempre y cuando sean compatibles entre ellas:  

 



z/OS v1.8 CICS Transaction Server v3.2 o Esta es la versión mínima para poder usar conexiones IPIC, que veremos más adelante CICS Service Flow Runtime para CICS TS v3.2 CICS Transaction Gateway v7.2 o Para poder hacer uso de conexiones IPIC necesitamos como mínimo la versión 7.1 DB2 v8.1 o Aunque no es estrictamente necesario para nuestro proyecto, si que va a ser utilizado por alguno de los programas CICS que utilicemos.

1.3.2.2.- Software en la parte del ordenador personal En el ordenador personal vamos a necesitar el siguiente software:     

Personal Communications v5.8 o Emulador de terminal 3270 Rational Business Developer v7.5.1.5 o Necesario para poder instalar el Rational Developer for System z Rational Developer for System z v7.6.0 o Con el modulo Enterprise Service Tools Microsoft Visual Studio 2005 v8.0.50727.42 o Suite de desarrollo de aplicaciones .NET NetBeans IDE v6.5

- 30 -

Mikel Castillejo Erviti



Universidad Pública de Navarra

o Suite de desarrollo de aplicaciones Java BlueZone Secure FTP v5.0 o Permite transferir ficheros o data sets entre un ordenador personal y un mainframe

El emulador utilizado tiene varias características que vale la pena comentar:    

El ENTER habitual, para validar o realizar una acción, no se simula con la tecla habitual sino con la tecla Control, o Intro del teclado numérico La tecla Intro habitual nos lleva al primer campo de la siguiente línea donde podemos introducir texto Con la tecla Fin en un campo de entrada, borramos todo lo que hay desde el punto donde tenemos el cursos hasta el final del campo En una sesión CICS, con la tecla Pausa borramos la pantalla

En la Figura 1.14 podemos ver el emulador Personnal Comunnications v5.8.

Figura 1.14 Personnal Comunnications v5.8

- 31 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.- CICS Transaction Gateway 2.1.- Introducción a CICS Transaction Gateway El CICS Transaction Gateway, también conocido como CICS TG, o CTG que será como lo llamemos a partir de ahora, es un componente de la empresa IBM que se instala en el mainframe y actúa como intermediario entre el CICS y sistemas externos para invocar servicios en el primero. Esto permite integrar la lógica de negocio de CICS con otros sistemas externos al mainframe, como pueden ser aplicaciones escritas en diferentes lenguajes de programación, para así mejorar y modernizar el sistema de información que se desee. El CTG consta de un componente que actúa como servidor escuchando peticiones que lleguen de los clientes. Este componente invoca los servicios correspondientes y devuelve los resultados obtenidos al cliente que le ha hecho la petición. Por otro lado consta de una parte cliente que son un grupo de conectores, llamados resource adapter según la especificación JCA, utilizada para conectar servidores de aplicaciones Java con sistemas de información de empresa, y librerías que van a permitir utilizar las API’s necesarias para realizar peticiones al CTG. Este grupo de conectores y librerías va a permitir realizar peticiones al CTG desde aplicaciones escritas en diferentes lenguajes como Java, .NET, etc. ya sean desarrolladas como aplicaciones de escritorio o como aplicaciones Web desplegadas en un servidor de aplicaciones. En la Figura 2.1 podemos ver los diferentes componentes que se van a emplear para realizar una petición al CICS por medio del CTG.

- 32 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 2.1 Componentes que se utilizan en una petición con CTG

Primero tenemos la aplicación que va a realizar la petición. Esta aplicación podrá ser de escritorio o tipo Web y estar escrita en variados lenguajes de programación como veremos más adelante. La petición viaja por TCP o TCP con SSL hasta un demonio de CTG que está escuchando peticiones. Este demonio y el demonio utilizado para conectarse al CICS se configuran por medio de un fichero .ini. El CTG obtiene los datos necesarios de la petición dependiendo de la API utilizada. Esta API puede ser ECI, EPI o ESI como veremos posteriormente. Comprueba que todo está correcto y, en caso de ser así, realiza una petición al CICS para lo que inicia un demonio cliente. El tipo de conexión entre el CTG y el CICS puede variar bastante dependiendo de la arquitectura que tengamos montada en nuestro sistema, como veremos más adelante. La petición llega al CICS el cual la procesa y los resultados obtenidos viajan en sentido inverso hasta el cliente. CTG tiene numerosas características de las que podemos hacer uso siendo algunas de las más importantes las siguientes:    

 

Conexión por TCP o SSL entre el cliente y el CTG Peticiones a programas basadas en COMMAREA o en Canales y Contenedores Peticiones a transacciones conversacionales o pseudo-conversacionales Soporte para lenguajes o interfaces de programación: o Java o .Net o C o C++ o COBOL o COM Autentificación por usuario o usuario y contraseña a la hora de realizar peticiones Soporte para transacciones XA y two-phase commit, o commit de dos fases

En general vamos a hacer uso de todas ellas excepto de la posibilidad de realizar peticiones a transacciones conversacionales o pseudo-conversacionales y el soporte de transacciones XA y two-phase commit. La primera de ellas no la vamos a utilizar debido a que, como veremos más adelante, la arquitectura de nuestro sistema no lo permite. - 33 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

La segunda de ellas no la vamos a utilizar al no tener nuestro sistema preparado para utilizar este tipo de transacciones y de protocolo. Tampoco vamos a hacer uso de todos los lenguajes de programación que permiten acceso al CTG sino que vamos a utilizar Java y .Net únicamente porque consideremos que son las opciones más utilizadas. Además, el uso de la API de .Net para realizar peticiones al CTG y el del resto de lenguajes, exceptuando Java, es el mismo. Nosotros vamos a trabajar con la versión 7.2 del CTG aunque la versión más actual en estos momentos es la posterior a esta que es la 8.0. En ambas versiones existe la opción de instalar el CTG en un sistema operativo z/OS, el llamado CTG para z/OS, o en un sistema operativo Windows, Unix o Linux, el llamado CTG multiplataforma. La licencia de CTG que poseemos sólo nos permite instalar el CTG en un sistema operativo z/OS. En general los cambios introducidos con esta nueva versión 8.0 no son demasiado importantes exceptuando el soporte en C, C++ y .Net de los Canales y Contenedores que veremos más adelante.

2.2.- Posibilidades en las arquitecturas y API’s 2.2.1.- Posibilidades en las arquitecturas El CTG nos provee de dos posibles arquitecturas a la hora de instalarlo. El Modo Local y el Modo Remoto. Ambos Modos nos van a permitir instalar el CTG de z/OS o el CTG multiplataforma, lo que va a posibilitar el uso de unas API’s u otras. 2.2.1.1.- Modo Local Este Modo se da cuando tanto el CTG como el cliente que realiza las peticiones, ya sea una aplicación de escritorio o un servidor de aplicaciones, se encuentran instalados en la misma máquina. Este modo nos permite la posibilidad de instalar el CTG tanto en un servidor con Windows, Unix o Linux como en un mainframe System z ya sea sobre z/OS o sobre la versión Linux para System z. Para poder instalar el CTG en Modo Local sobre z/OS, el servidor de aplicaciones que utilicemos tiene que tener una versión para este sistema operativo cosa que actualmente sólo cumple el WebSphere Application Server, propiedad de IBM. En la Figura 2.2 podemos ver el CTG y un servidor de aplicaciones en Modo Local instalado sobre una plataforma distribuida, es decir, sobre Windows, Unix o Linux.

- 34 -

Mikel Castillejo Erviti

Universidad Pública de Navarra Figura 2.2 CTG multiplataforma en Modo Local

Vemos como en este caso los modos de conectar el CTG al CICS son por medio de SNA, modo de conexión propietario de IBM, TCP62, que es SNA sobre TCP/IP, o TCP/IP. En la Figura 2.3 podemos ver también el Modo Local pero esta vez con el CTG y el servidor de aplicaciones instalados sobre z/OS.

Figura 2.3 CTG sobre z/OS en Modo Local

Esta opción nos permite conectar el CTG y el CICS por medio de EXCI o IPIC. Por último, en la Figura 2.4 podemos ver el CTG en Modo Local con el servidor de aplicaciones, ambos sobre un sistema operativo Linux instalado en el mainframe.

Figura 2.4 CTG en Modo Local sobre Linux para mainframes

En esta opción vemos como las posibilidades de conexión entre el CTG y el CICS aumentan permitiéndonos conectarnos por APPC, TCP62, TCP/IP, Communications Server o HiperSockets, siendo APPC, TCP62 e HiperSockets propietarias de IBM. 2.2.1.2.- Modo remoto El Modo Remoto se da cuando la aplicación cliente, ya sea de escritorio o Web por medio de un servidor de aplicaciones, se encuentran en distinta máquina. Al igual que antes, el CTG puede estar instalado sobre Windows, Unix o Linux, en este último caso en un mainframe o no, o en un mainframe sobre el sistema operativo z/OS aunque lo normal es que esté instalado en un mainframe sobre z/OS.

- 35 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

En la Figura 2.5 podemos ver un CTG sobre z/OS en Modo Remoto. Debido a que sólo tenemos licencia de CTG para z/OS y no tenemos licencia de WebSphere Application Server para z/OS, esta es la única arquitectura que vamos a poder montar.

Figura 2.5 CTG en Modo Remoto sobre z/OS

Como podemos observar, en esta arquitectura tenemos la posibilidad de conectar la aplicación cliente y el CTG por medio de TCP o SSL. Las posibilidades de conexión entre el CTG y el CICS son por medio de EXCI o IPIC. Más adelante veremos las posibilidades de cada una. En la Figura 2.6 podemos ver los diferentes tipos de topologías que podemos montar atendiendo a las conexiones que necesitamos.

Figura 2.6 Topologías según las conexiones utilizadas

En la Topología 1 vemos como necesitamos una conexión entre el navegador Web y el servidor de aplicaciones. No sería necesaria ninguna conexión entre el servidor de aplicaciones y el CTG al encontrarse en la misma máquina, independientemente del sistema operativo que utilice esta máquina. También necesitamos una conexión entre el CTG y el CICS. La Topología 2 necesita una conexión entre el servidor de aplicaciones y el CTG, o entre la aplicación de escritorio y el CTG, y otra entre el CTG y el CICS, a pesar de encontrarse en la misma máquina. Esta será la topología que utilicemos y como vemos es la única donde el servidor de aplicaciones y el CTG están en Modo Remoto. - 36 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Por último, la Topología 3 necesita, al igual que la 1, una conexión entre el navegador Web y el servidor de aplicaciones y otra entre el CTG y el CICS, independientemente de que el sistema operativo donde estén el servidor de aplicaciones y el CTG sea Linuz para System z o z/OS. 2.2.2.- Posibilidades en las API’s El CTG nos ofrece tres diferentes API’s de las que podemos hacer uso para realizar peticiones de servicios CICS desde aplicaciones de escritorio o aplicaciones Web sin hacer uso de la tecnología JCA. Cada una de ellas nos va a permitir realizar un tipo de petición y, dependiendo del tipo de arquitectura y del sistema operativo donde tengamos instalado el CTG, podremos hacer uso de unas u otras API’s. Estas API’s se llaman ECI, EPI y ESI. En caso de querer usar la tecnología JCA propuesta por Java para conectar el CTG con un sistema externo, utilizaremos la interfaz CCI, Common Client Interface o Interfaz de Cliente Comun, para realizar las peticiones al CTG. En caso de usar esta tecnología también necesitaremos usar los adaptadores CICS ECI o CICS ECI XA, dependiendo de si queremos hacer uso de transacciones XA o no. Para hacer peticiones al CTG desde una aplicación Web, tenemos la opción de importar la librería correspondiente en cada aplicación que despleguemos o utilizar la tecnología JCA para hacer uso de un adaptador previamente desplegado en el servidor de aplicaciones. Por motivos que veremos más adelante, vamos a hacer uso de la primera opción. 2.2.2.1.- ECI La API ECI, External Call Interface o Interfaz de Llamada Externa, nos va a permitir realizar peticiones a transacciones CICS no conversacionales, es decir, aquellas que no utilizan pantallas para la comunicación entre el CICS y el usuario. También nos va a permitir realizar peticiones para hacer commit o rollback sobre una LUW. Los programas CICS invocados pueden utilizar tanto COMMAREA como Canales Contenedores para enviar y recibir datos. La aplicación de usuario que haga uso de esta interfaz va a poder conectarse a varios servidores CICS al mismo tiempo y realizar varias peticiones de servicios CICS para que se ejecuten concurrentemente. Los programas CICS invocados por medio de esta API van a hacer uso de DPL, o Distributed Program LINK, y deben seguir sus reglas. En un principio estas reglas no son muy restrictivas ya que son reglas como tener que pasarle la longitud de la COMMAREA, en caso de utilizarla, el nombre del programa CICS que queremos que se ejecute, etc. Siguiendo las indicaciones que más adelante veremos para realizar peticiones con esta interfaz no debemos preocuparnos de estas reglas aunque se pueden consultar en el documento SC33-1687 - CICS Application Programming Guide. Para poder hacer uso de esta interfaz, en nuestras aplicaciones haremos uso de la librería ctgclient.jar, en caso de ser una aplicación Java, o las librerías ctgclient.dll y IBM.CTG.Client.dll en caso de ser una aplicación .NET, que son las dos opciones que vamos a utilizar. 2.2.2.2.- EPI La API EPI, External Presentation Interface o Interfaz de Presentación Externa, permite a una aplicación de usuario instalar y borrar terminales virtuales 3270 en un servidor CICS. Esto nos

- 37 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

va a permitir realizar peticiones de transacciones conversacionales o pseudo-conversacionales, es decir, aquellas que hacen uso de pantallas para comunicarse con el usuario. Debido a que utilizamos el Modo Remoto entre el la aplicación de usuario y el CTG, y que este está instalados sobre z/OS, no nos va a ser posible utilizar esta API. 2.2.2.3.- ESI La API ESI, External Security Interface o Interfaz de Seguridad Externa, permite utilizar ciertas funcionalidades de seguridad desde una aplicación de usuario por medio de CTG. Entre estas funcionalidades tenemos las siguientes:   

  

Verificar que una contraseña es válida para cierto identificador de usuario Cambiar la contraseña almacenada para un identificador de usuario Comprobar si el usuario está revocado, esto suele ocurrir por introducir una contraseña errónea un número determinado de veces, normalmente tres. Cuando esto pasa el usuario no puede entrar al sistema hasta que un administrador de seguridad no le vuelva a dar permiso Determinar si una contraseña a expirado Obtener información sobre el identificador de usuario que está realizando las peticiones Establecer unas credenciales de seguridad predeterminadas para comunicarse entre la aplicación cliente y el servidor CICS

Para hacer uso de esta API, las credenciales de seguridad tienen que estar gestionadas por un External Security Manager, ESM, válido para CICS como RACF. Este ESM tiene que ser accesible para el servidor CICS particular sobre el que estamos trabajando. Al igual que con la API EPI, debido a que utilizamos el Modo Remoto entre el la aplicación de usuario y el CTG, y que este está instalados sobre z/OS, no nos va a ser posible utilizar esta API. 2.2.2.4.- CCI La API CCI, Common Client Interface o Interfaz de Cliente Común, permite a servidores de aplicaciones Java conectarse y hacer uso de un sistema de información de una empresa como puede ser el CICS. CCI no es propiedad de IBM sino que es parte de la tecnología JCA desarrollada por Java. Para hacer uso de esta interfaz deberemos desplegar en el servidor de aplicaciones un adaptador que nos de acceso al sistema de información específico que queremos utilizar. El CTG para z/OS nos provee de dos adaptadores como son CICS ECI y CICS ECI XA. Ambos nos permiten utilizar la API ECI que hemos visto anteriormente con la diferencia de que el segundo nos da la posibilidad de utilizar transacciones XA. También hay un adaptador para poder hacer uso de la API EPI pero no se suministra con el CTG de z/OS ya que no podemos hacer uso de é. No existe un adaptador para hacer uso de la API ESI ya que no es posible usar esta API por medio de JCA. Las restricciones a la hora de usar estos adaptadores para hacer peticiones son las mismas que si utilizásemos las librerías importándolas en cada aplicación exceptuando las siguientes:  No podemos hacer uso de LUW’s que llamen a más de una transacción. Esto significa que el valor para el parámetro Extend_Mode debe de ser ECI_NO_EXTEND  Todas las peticiones deben de ser síncronas. Esto significa que sólo los tipos ECI_SYN y ECI_SYNC_TPN son válidos para el tipo de llamada - 38 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Para poder utilizar estos adaptadores, antes de desplegarlos en el servidor de aplicaciones, vamos a tener que establecer ciertos parámetros como la URL del servidor CICS, su puerto de escucha, el usuario y contraseña que se va a utilizar para realizar las peticiones, etc. Esto tiene varios inconvenientes:  En caso de tener varios servidores CICS tenemos que desplegar tantos adaptadores como servidores tengamos  Cada aplicación tiene que indicar el adaptador que va a usar por lo que, si queremos que una aplicación acceda a más de un CICS, tendremos que desplegar la aplicación varias veces, cada una haciendo uso de un adaptador  El usuario utilizado para realizar las peticiones es fijo, lo que nos impide llevar en caso necesario una auditoría del uso que cada usuario hace del CTG  Si al contraseña cambia, debido a que ha expirado o a que se ha modificado por razones de seguridad, habría que volver a desplegar el adaptador modificando los parámetro necesarios Estos inconvenientes superan en mi opinión al inconveniente de tener que importar la librería correspondiente en cada aplicación Web que desarrollemos. Por esto vamos a usar esta segunda opción en caso de querer desarrollar una aplicación Web. 2.2.2.5.- Posibles API’s según la arquitectura Dependiendo del Modo de arquitectura utilizado y del sistema operativo sobre el que esté instalado el CTG, vamos a poder hacer uso de unas API’s o de otras. En general, si tenemos el CTG para multiplataforma instalado en Modo Local podemos hacer uso de cualquier API desde cualquier lenguaje de programación. Si el CTG está en Modo Remoto sólo vamos a poder usar las API’s ECI y EPI desde Java y sólo la ECI desde C y .Net. Si el CTG está instalado sobre z/OS, como es nuestro caso, sólo vamos a poder usar la API ECI desde Java y .Net si está en Modo Remoto y sólo desde Java en modo Local. En la Tabla 2.1 podemos ver un resumen de las API’s que podemos usar en Modo Local según el Sistema Operativo sobre el que está instalado el CTG.

API Windows ECI EPI ESI Unix y Linux ECI EPI ESI z/OS ECI EPI ESI

C

C++

COBOL

COM

.Net

Java

JCA

X X X

X X X

X X X

X X X

X X X

X X X

X X

X X X

X X X

X X X

X X X

X X X

X X

X

X

Tabla 2.1 API’s utilizables en Modo Local

- 39 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

En la Tabla 2.2 podemos ver las API’s que tenemos la ocasión de utilizar en Modo Remoto dependiendo del sistema operativo sobre el que tengamos instalado el CTG. API Windows ECI EPI ESI Unix y Linux ECI EPI ESI z/OS ECI EPI ESI

C

C++

COBOL

COM

.Net

Java

JCA

X

X

X X X

X X

X

X

X X X

X X

X

X

X

X

Tabla 2.2 API’s utilizables en Modo Remoto

Vemos como si tenemos el CTG instalado sobre z/OS en Modo Remoto, como es nuestro caso, sólo podemos hacer uso de la API ECI desde Java y JCA, .Net y C. Probaremos la API desde los lenguajes Java y .Net ya que la forma de utilizarla desde los lenguajes JCA y C es similar respectivamente a Java y .Net. En la Figura 2.7 podemos ver de forma más gráfica las diferentes API’s que podemos usar con el CTG multiplataforma así como las posibles conexiones entre el servidor de aplicaciones, o aplicación de escritorio, y el CTG, como desde esta al CICS.

Figura 2.7 API’s utilizables con el CTG multiplataforma

- 40 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

En la Figura 2.8 podemos ver las API’s que se pueden usar por medio del CTG para z/OS y las conexiones posibles entre los diferentes componentes.

Figura 2.8 API’s utilizables con el CTG para z/OS

Además de ver, como antes, que vamos a tener la posibilidad de utilizar la API ECI, también vemos que entre la aplicación cliente y el CTG vamos a poder usar TCP o SSL y entre el CTG y el CICS EXCI o IPIC. 2.2.3.- Tipos de conexiones Como ya hemos visto, tenemos varias posibilidades de conexión, ya sea entre la aplicación de usuario y el CTG, como entre el CTG y el CICS. La conexión entre la aplicación usuario y el CTG puede ser TCP o TCP con SSL. Esto no representa mayores diferencias en el uso y características del CTG que podemos utilizar. Simplemente añade un componente de autentificación y seguridad a la comunicación y los datos que se transmiten entre la aplicación cliente y el CTG. Al estar tanto el CTG como el CICS instalados sobre z/OS, las posibles conexiones que podemos establecer entre ellos tienen que ser EXCI o IPIC. Las diferencias entre ambas conexiones a la hora de usar CTG son las siguientes:    

EXCI no soporta las peticiones de programas que usan Canales y Contenedores IPIC soporta transacciones XA sin tener que realizar ninguna configuración adicional Es más fácil habilitar seguridad en IPIC IPIC sólo soporta SSL cuando el CTG y el CICS están instalados en la misma máquina, como es nuestro caso

En general, la tendencia de IBM parece que es la de evolucionar hacia el uso de conexiones IPIC dejando de lado las conexiones EXCI en el uso del CTG. Aunque veremos como configurar ambas conexiones, en general usaremos IPIC.

- 41 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

La mayor ventaja, desde mi punto de vista, de utilizar conexiones IPIC sobre EXCI es la posibilidad de utilizar una nueva interfaz para desarrollar programas CICS, como es la interfaz de Canales y Contenedores, sobre la antigua interfaz de COMMAREA. En el siguiente apartado pasamos a explicar las diferencias entre ambas y las ventajas de los Canales y Contenedores sobre la COMMAREA. 2.2.3.1.- Canales y Contenedores En 1975 se introdujo la COMMAREA, comunnication area o área de comunicaciones, como un método para pasar datos de una aplicación a otra. Debido a que la opción de longitud de un comando CICS es generalmente expresado como un valor de longitud media palabra con signo, 15 bits en CICS., esto nos da un límite de longitud teórico de 32763 bytes. Esto significa que la máxima área de datos que se puede intercambiar es de 32KB. Esto no era un problema en sus inicios porque los datos de las aplicaciones estaban basados en 3270 y estos no consumían muchos recursos. El límite de 32KB era suficiente para manejar la propagación de datos entre aplicaciones. Sin embargo, debido a que la integración entre aplicaciones CICS y elementos de las soluciones empresariales se están convirtiendo en la norma, las aplicaciones CICS cada vez necesitan procesar mayor cantidad de datos. La consecuencia de extender las aplicaciones CICS a nuevas soluciones empresariales es que las restricciones impuestas por el sistema en el tamaño de la COMMAREA pueden ser muy restrictivas. La COMMAREA es un gran bloque de datos contiguo que contiene todos los datos pasados a un programa invocado, incluso si parte de los datos no son necesarios o son nulos. Para el diseño moderno de aplicaciones la flexibilidad de las estructuras de datos es un componente básico que ofrece la posibilidad de acomodarse a futuros requerimientos empresariales. Aunque hay diferentes opciones que solucionan el límite de 32KB de la COMMAREA, como pasar en la COMMAREA la dirección de un área de almacenamiento mayor, las diversas soluciones que se plantearon son válidas en algunos casos pero fallan o tienen problemas en otros por lo que se desarrolló una nueva interfaz para intercambiar datos entre aplicaciones CICS o desde el CICS hacia el exterior. Este nuevo enfoque es conocido como Channels y Containers o Canales y Contenedores. Fue introducido por primera vez en el CICS Transaction Server v3.2 y es posible utilizarlo a partir del CICS Transaction Gateway v7.1. Un Canal es un nombre de referencia único a una colección de datos de aplicación contenidos en Contenedores. Un Canal es análogo a una COMMAREA pero sin tener las restricciones de esta última. Esta es una forma fácil de agrupar estructuras de datos que pueden ser pasados a una aplicación que invoques. CICS destruye un Canal cuando ya no puede ser referenciado más veces, esto es, cuando el Canal esté out of scope, fuera de ámbito, por lo que no tenemos que gestionar personalmente la memoria como con la COMMAREA. Un Contenedor es un nombre de referencia a un área de almacenamiento manejada por CICS que puede contener cualquier forma de datos de aplicación. Un Contenedor puede ser teóricamente de cualquier tamaño, aunque en realidad está limitado por el direccionamiento de 31-bit de una región CICS, lo que implica un límite de 2GB por Contenedor, casi como si fuese ilimitado. Puede contener datos de cualquier tipo que las aplicaciones requieran. Una aplicación puede referenciar cualquier número de Contenedores.

- 42 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Este nuevo enfoque nos permite intercambiar cantidades de datos superiores a 32KB al mismo tiempo que permite dar una estructura lógica a los mismos. También tiene una mejora sustancial con respecto a la COMMAREA y es que cuando enviamos un Canal sólo se envían los Contenedores nuevos o que se han modificado. No así con la COMMAREA donde se enviaba toda la COMMAREA cada vez. Esto hace que la cantidad de datos transferidos disminuya significativamente. El único inconveniente es que necesitamos conocer el nombre de los Contenedores, no así del Canal normalmente, donde nos pasan los datos. De todas maneras, siempre es posible recorrer todos los Contenedores comprobando su contenido y quedándonos con la información que necesitemos. La manera de manejar los Canales y Contenedores desde una aplicación Java, las aplicaciones .Net no pueden hacer uso de esta funcionalidad con la versión 7.2, se describe más adelante. En este proyecto no se va a tratar la manera de manejar Canales y Contenedores desde programas CICS aunque podemos encontrar como hacerlo en el manual EXEC CICS application programming interface.

2.3.- Instalación del CTG 2.3.1.- Requisitos de instalación El CICS Transaction Gateway v7.2 no tiene grandes requisitos para su instalación. Simplemente necesitamos tener instalado un sistema operativo z/OS v1.8 o superior y un CICS Transaction Server v2.3 o superior. Aunque estas son las versiones mínimas para que el CTG v7.2 funcione, teniendo unas versiones superiores y ciertos APAR vamos a tener acceso a más funcionalidades. Un APAR es un Authorized Program Analisys Report, similar a un parche de software para corregir errores. En la Tabla 2.3 podemos ver las diferentes funcionalidades a las que tenemos acceso dependiendo las versiones y APAR’s que tengamos instalados. Producto, versión y APAR’s z/OS v1.8 con APAR OA23163 CICS TS v2.3 con APAR’s PQ92943 y PK 17427 CICS TS v3.1 con APAR PK17426 CICS TS v3.2 con APAR’s PK49015, PK49017, PK49021, PK49116, PK49490, PK51587, PK53783, PK55494, PK55495, PK55716, PK57726 y PK65134

Funcionalidad APAR requerido para two-phase commit Transacciones XA APAR’s requeridos para aumentar límite de conexiones EXCI y two-phase commit Transacciones XA APAR requerido para two-phase commit Transacciones XA Conexiones IPIC

Tabal 2.3 Funcionalidades dependiendo de las versiones y APAR’s del software

Nuestro sistema se encuentra en el último caso por lo que nos permite usar tanto transacciones XA y two-phase commit como conexiones IPIC.

- 43 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.2.- Configuración del sistema La instalación de CTG consta de dos partes. La primera de ellas consiste en volcar los data sets y los directorios Unix necesarios para la instalación y funcionamiento del CTG desde la cinta donde IBM suministra sus productos hasta el mainframe. Esta parte ya estaba realizada al empezar a hacer el proyecto por lo que no ha sido posible documentarla. De todas maneras, los pasos necesarios para llevar a cabo este proceso vienen detallados en el siguiente documento que se puede descargar desde la página oficial de IBM http://www.ibm.com/: GI13-0512-02 - CICS Transaction Gateway for z/OS V7.2 Program Directory. La segunda parte consiste crear los archivos de configuración necesarios para que funcione el CTG y personalizarlos con los valores adecuados para nuestra instalación. Estos pasos son los que vamos a describir a continuación. 2.3.2.1.- Reserva de puertos Reservamos los puertos necesarios para nuestra instalación. Para ello se añadirán las siguientes líneas en el miembro PROFILE de la librería PRUEBAS.TCPIP.PARMLIB: 20061 TCP * ; RESERVE CICS TO CTG1A 20062 TCP * ; RESERVE CICS TO CTG1A 20066 TCP * ; RESERVE CICS TO CTG1B 20067 TCP * ; RESERVE CICS TO CTG1B 2006 TCP CTG1* SHAREPORT ; TCP/IP TO CTG 8050 TCP CTG1* ; SSL TO CTG Tal como están hechas las reservas, las únicas reservas válidas serían las dos últimas ya que les indicamos para quien lo reservamos. El resto servirían más bien para que si en otro momento queremos ver los puertos disponibles para instalar otro CTG u otro programa, saber que estos puertos los queremos utilizar en un futuro para estos CTGs. Las primeras reservas las hacemos para conectar el CTG con el CICS. Las dos últimas, para reservar el puerto donde va a escuchar el CTG las peticiones que le lleguen del exterior. En un principio, con reservar un solo puerto para conectar al CTG con el CICS y otro para que el CTG escuche peticiones sería suficiente. Hacemos más reservas en previsión de instalar más de un CTG, por lo menos dos. También hacemos reservas extra para conectar cada CTG a más de un CICS. La penúltima línea indica que en el puerto 2006 vamos a tener dos o más CTGs escuchando en Port Sharing. Aunque esto lo explicaremos más adelante, lo que queremos hacer es tener dos o más CTGs escuchando en el mismo puerto de forma que ofrezcan alta disponibilidad. Esto quiere decir que se reparten la carga de trabajo o que si uno cae el resto siga escuchando peticiones en ese puerto. Para el usuario final esto es transparente. La última línea la utilizamos para reservar el puerto 8050, por defecto, para escuchar peticiones que vengan por TCP sobre SSL. Para que se lleven a cambio estos cambios en el sistema, habría que parar y arrancar todo el mainframe o reiniciar la LPAR donde queremos hacer los cambios.

- 44 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.2.2.- Configuración de la parte Unix Una vez reservados los puertos que vamos a utilizar, el siguiente paso es crear y configurar con respecto a nuestra instalación un archivo .ini que va a servir para inicializar el CTG. Este archivo se almacena en la parte Unix del z/OS. Como personalmente me resulta más cómodo manejarme con una interfaz tipo línea de comandos de Unix que con los paneles de TSO/ISPF, accedemos a la parte Unix por medio de OMVS ejecutando en cualquier panel de TSO el comando tso omvs. Como ya hemos dicho, los comandos para crear carpetas, copiar archivos, etc. son los mismos que en un sistema operativo Unix normal por lo que no los vamos a nombrar aquí. A continuación vamos a ver los pasos que vamos a seguir para crear y modificar el archivo .ini como consideremos adecuado. 1.- Creamos el siguiente directorio donde vamos a almacenar los diferentes archivos .ini que podamos crear. /etc/ctgvar/ 2.- Copiamos el siguiente archivo /usr/lpp/cicstg/v7r2m0/bin/ctgsamp.ini a /etc/ctgvar/ 3.- Renombramos el siguiente archivo /etc/ctgvar/ctgsamp.ini a /etc/ctgvar/ctg1a.ini El número 1 se lo damos para distinguirlo de otros posibles CTGs, o grupos de CTGs en Port Shared, que podamos instalar más adelante. La letra A se la damos para diferenciarlo dentro del grupo de CTGs que instalemos más adelante en Port Shared. Nos tenemos que acordar de este nombre, y de la ruta donde está almacenado, ya que lo necesitaremos más adelante. 4.- Configuramos el archivo .ini según los parámetros de nuestra instalación. Para poder leer y modificar un archivo utilizamos el comando oedit . Esto nos llevará a una pantalla similar a la que hemos visto anteriormente de ISPF/PDF pudiendo utilizar las mismas técnicas para copiar líneas, borrarlas, etc. A continuación vamos a ver como quedaría el archivo una vez configurado e intentaremos explicar cada uno de los parámetros y valores que hemos establecido. Hay que indicar que las líneas que empiezan por Ñ o, en una línea, el texto que va después de una Ñ, son comentarios. El Documento 2.1 muestra el fichero .ini con los parámetros adecuados para nuestra instalación. Ñ Sección para indicar algunos parámetros que necesita el CTG SECTION PRODUCT applid = CTG1A Ñ Establece el APPLID del CTG Ñ Es el “nombre” del CTG applidqualifier = VTAM Ñ El cualificador APPLID del Gateway Ñ Daemon

- 45 -

Mikel Castillejo Erviti

defaultserver = CICS1

Universidad Pública de Navarra Ñ Ñ Ñ Ñ Ñ Ñ

Es el “nombre” de la red donde está conectado Ya definido en el sistema Nombre del servidor CICS al que se va a conectar por defecto Ya definido en el sistema

ENDSECTION Ñ Sección para indicar ciertos parámetros de conexión al CICS por IPIC Ñ Creamos una SECTION IPICSERVER por cada servidor CICS al que queremos que Ñ se pueda conectar el CTG Ñ Sólo hay que ponerla si vamos a usar conexiones IPIC SECTION IPICSERVER = CICS1 Ñ Nombre que le damos al servidor CICS Ñ Aparecerá cuando listemos los Ñ servidores al que podemos hacer Ñ peticiones desde el CTG description = Con. IPIC a CICS1 Ñ Descripción de la conexión hostname = pruebas Ñ Dirección TCP/IP donde está el CICS Ñ Al estar ambos en la misma máquina Ñ sobre z/OS podemos usar su nombre Ñ Sino, tendríamos que usar la IP port = 20061 Ñ Puerto donde más adelante definiremos Ñ el TCPIPSERVICE para conectar el CTG Ñ al CICS tcpkeepalive = Y Ñ Con YES comprueba periódicamente que Ñ seguimos conectados al CICS srvidletimeout = 60 Ñ Tiempo en mins. que una conexión parada Ñ sigue abierta connecttimeout = 60 Ñ Tiempo en segs. que el CTG espera al Ñ CICS en un intento de establecer Ñ conexión sendsessions = 100 Ñ Número de transacciones o tareas CICS Ñ simultáneas sobre la conexión Ñ Establecido por este parámetro y por Ñ el parámetro RECEIVECOUNT de la Ñ definición de IPCONN (el que sea menor) Ñ Los siguientes parámetros son opcionales y sirven para hacer comprobaciones Ñ O se utilizan ambos a no se utiliza ninguno Ñ Se utilizan en algunos casos cuando el CTG y el CICS no se encuentran en la Ñ misma máquina lo que no es nuestro caso Ñ cicsapplid = CICSAPPL Ñ APPLID del CICS Ñ cicsapplidqualifier = CICSQUAL Ñ APPLID de la red donde está el CICS ENDSECTION Ñ Ñ Ñ Ñ

Antes de la SECTION GATEWAY iría una sección que mapearía el nombre lógico de un servidor CICS con su nombre actual, llamada SECTION LOGICALSERVER. Como en nuestro sistema estos nombre coinciden no hace falta usar esta sección

Ñ Esta sección define algunos parámetros de configuración del CTG. Ñ Estos parámetros los podríamos establecer al arrancar el CTG o modificarlos Ñ una vez arrancado desde el SD aunque normalmente no lo vamos a hacer. Ñ Estos valores quedan invalidados por aquellos que demos desde el SD. SECTION GATEWAY Ñ Número de hilos iniciales que esperan conexiones desde el exterior Ñ Por defecto es 1 Ñ initconnect=1 Ñ Número de hilos máximos para esperar conexiones desde el exterior Ñ Por defecto es 100

- 46 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Ñ maxconnect=100 Ñ Número de hilos iniciales para establecer conexión entre el CTG y el CICS Ñ Por defecto es 1 Ñ initworker=1 Ñ Número de hilos máximos para establecer conexión entre el CTG y el CICS Ñ Por defecto es 100 Ñ maxworker=100 Ñ Habilitar mensajes extra de traza (en caso de tener la traza activada). Ñ trace=on Ñ Ñ Ñ Ñ

Deshabilita la entrada de comandos desde consola (SDSF). Por defecto está habilitada la entrada de comandos. Nos permitirá parar el CTG desde SDSF, listar estadísticas, etc. noinput=on

Ñ Si está a on muestra en los mensajes la IP en vez nombres simbólicos usando Ñ un servidor de DNS. Ñ Mostrar los nombres (parámetro a off) puede afectar sustancialmente el Ñ rendimiento por lo que al no ser estrictamente necesario lo dejamos a on. nonames=on Ñ Ñ Ñ Ñ

Lo contrario del anterior. No se especifica cual tiene preferencia pero lo dejamos deshabilitado ya que es lo que queremos. dnsnames=on

Ñ Ñ Ñ Ñ

Suprime todas las salidas por consola (SDSF) (implica noinput=on) No lo habilitamos ya que queremos que nos muestre cierta información como errores, conexiones y desconexiones, etc. quiet=on

Ñ Especifica la ruta Unix donde se va a guardar el fichero de traza Ñ tfile=/tmp/ctg.trc Ñ Ñ Ñ Ñ

Establece el tamaño máximo en KB del fichero de traza. Cuando se llega al máximo empieza a sobrescribir por el principio. Por defeecto es 80 KB. tfilesize=80

Ñ Tamaño máximo en bytes de cada bloque de datos de traza. Ñ Por defecto es 80 bytes. Ñ truncationsize=80 Ñ Desplazamiento en bytes de los datos antes de empezar a escribir la traza. Ñ dumpoffset=0 Ñ Habilita el volcado de la pila de excepciones en la traza. Ñ Por defecto a off. Ñ stack=on Ñ Ñ Ñ Ñ

La siguiente sección habilita el Puerto que indiquemos (en este caso el 2980) junto con algunos parámetros (conexiones máximas, timeout, etc.), para recibir peticiones de estadísticas. Si no vamos a utilizar esta funcionalidad, comentar las líneas [email protected]=com.ibm.ctg.server.RestrictedTCPHandler [email protected]=connecttimeout=2000;\ port=2980;\ bind=;\

- 47 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

maxconn=5;

Ñ Habilita el Puerto 2006 (por defecto) para recibir peticiones por TCP junto Ñ con algunas características (timeouts, intervalo entre pings para comprobar Ñ que el CTG sigue activo, etc.). Ñ Comentar si no vamos a utilizar TCP. [email protected]=com.ibm.ctg.server.TCPHandler [email protected]=port=2006;\ connecttimeout=2000;\ idletimeout=600000;\ pingfrequency=60000

Ñ Lo mismo que en el caso anterior pero para SSL. Ñ Lo descomentaremos para probar el protocolo SSL. Ñ[email protected]=com.ibm.ctg.server.SslHandler Ñ[email protected]=port=8050;\ Ñ connecttimeout=2000;\ Ñ idletimeout=600000;\ Ñ pingfrequency=60000;\ Ñ keyring=ServerKeyRing;\ Ñ keyringpw=default;\ Ñ clientauth=off; Ñ Activa soporte para transacciones XA (si usamos conexiones EXCI) Ñ En caso de conexiones IPIC está siempre activado, aunque no lo vamos a usar Ñ xasupport=on Ñ Ñ Ñ Ñ

Validar LUW’s Sirve para que una LUW sólo pueda ser usada por la conexión que la crea Por defecto está activado que es lo que queremos uowvalidation=off

Ñ Indica en formato HHMMSS (horas, minutos y segundos) cuanto dura un Ñ intervalo de estadísticas Ñ De esta forma dura 3 horas statint=030000 Ñ Indica en formato HHMMSS (horas, minutos y segundos) cuanto es el final del Ñ día para las estadísticas Ñ De esta forma acaba a las 00:00 horas stateod=000000 Ñ Graba las estadísticas en SMF Ñ Lo dejamos sin habilitar porque no nos hace falta Ñ statsrecording=on Ñ Envía estadísticas sobre comunicaciones a un balanceador de carga TCP/IP Ñ No lo habilitamos al no tener un balanceador de carga Ñ healthreporting=on Ñ Lista de clases Java para usar como monitor de peticiones Ñ No lo usamos Ñ requestexits=com.ibm.ctg.samples.requestexit.NullMonitor Ñ Clase que remapea los nombres de los servidores CICS en peticiones ECI Ñ No lo usamos Ñ cicsrequestexit=com.ibm.ctg.samples.ha.BasicCICSRequestExit Ñ Tiempo en msg que pasa esperando a que se asigne un hilo de conexión entre

- 48 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Ñ el CTG y el CICS. Si pasa este tiempo sin asignar un hilo se produce un Ñ error. Por defecto se establece a 10000 msg. (10 seg) Ñ workertimeout=10000 Ñ Tiempo en msg que pasa intentando finalizar peticiones una vez que se Ñ cierra una conexión. Ñ closetimeout=10000 Ñ Muestra las conexiones y desconexiones de las aplicaciones cliente connectionlogging=on Ñ Indica donde se muestran los datos de las conexiones y desconexiones. Ñ De esta forma se muestran por la pantalla del SDSF. [email protected]=console [email protected]=console ENDSECTION Documento 2.1 Fichero ctg1a.ini de configuración del CTG

Con esto ya tendríamos preparado el archivo de inicialización del CTG. Esto es todo lo que tenemos que hacer en la parte Unix del mainframe. 2.3.2.3.- Miembro de variables de entorno En esta paso vamos a ver como crear una librería, o data set PDS/E, para almacenar los diferentes miembros de variables de entorno del CTG que podamos tener. También crearemos un primer miembro de variables de entorno y lo configuraremos según nuestra instalación. 1.- Crear la librería para almacenar los miembros de variables de entorno. Para ello, desde la pantalla inicial de TSO tecleamos P.3.2 para acceder a la pantalla que se muestra en la Figura 2.9 desde donde podemos realizar diversas operaciones sobre data sets como crearlos (allocarlos), borrarlos, copiarlos, etc.

Figura 2.9 Pantalla P.3.4 para realizar operaciones sobre data sets

- 49 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Si nos fijamos en la parte superior, si escribimos A en la línea de comandos podemos crear un nuevo data set. Para ello escribimos también el nombre que le queremos dar al data set que en este caso es CICSTG.V7R2M0.CTGENVAR. La pantalla quedará como se puede ver en la Figura 2.10.

Figura 2.10 Resultado de la pantalla para crear el data set CICSTG.V7R2M0.CTGENVAR

Una vez hecho esto pulsamos Control, que en nuestro emulador simula al ENTER, para llegar a la pantalla mostrada en la Figura 2.11 donde podemos indicarle las propiedades del data set que vamos a crear que serán las que se muestran.

Figura 2.11 Propiedades del data set a crear

- 50 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.- Copiar el miembro siguiente a la librería que hemos creado: CICSTG.V7R2M0.SCTGSAMP(CTGENV) a CICSTG.V7R2M0.CTGENVAR(ENVCTG1A) Nos tenemos que acordar del data set y miembro a donde hemos hecho la copia ya que lo necesitaremos más adelante. Para copiar un miembro de una librería, desde la pantalla de inicio de TSO tecleamos P.3.4 para dirigirnos a la pantalla que se muestra en la Figura 2.12 y escribir en “Dsname Level” el nombre del data set que queremos listar que en este caso será CICSTG.V7R2M0.SCTGSAMP.

Figura 2.12 Pantalla para listar data sets

Una vez pulsado Control nos lleva a la pantalla de la Figura 2.13. En esta podemos ver un listado de los data sets que coinciden con el nombre buscado. En este caso sólo hay uno. Introducimos una “v” delante del nombre del data set para listar los miembros que contiene. Si quisiéramos editar alguno de los miembros del data ser, introduciríamos delante del nombre del data set una “e” en vez de una “b”.

- 51 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 2.13 Listado de data sets

Una vez pulsado Control nos llevará a la pantalla de la Figura 2.14 donde se muestran los miembros que contiene este data set. Ahora nos situamos con el cursor delante del miembro que queremos copiar y escribimos una “c” delante de él.

Figura 2.14 Listado de miembros de un data set con el miembro CTGENV seleccionado para copiarlo

- 52 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Pulsamos Control con lo que nos aparece la pantalla de la Figura 2.15 donde podemos introducir ciertos parámetros para copiar el miembro.

Figura 2.15 Panel para copiar de un miembro

A nosotros nos interesan los campos “To Library” donde introducimos el nombre del data set donde queremos copiar el miembro, que en este caso es el CICSTG.V7R2M0.CTGENVAR. En “NEW member name” le damos el nombre con el que queremos que se copie el miembro, en caso de que no queramos que sea el mismo que el miembro original, que en este caso será ENVCTG1A. Pulsamos Control con lo que ya tenemos copiado el miembro. 3.- Una vez copiado lo adaptamos a nuestra instalación definiendo los siguientes valores para las variables que hay en el miembro. Para poder editar el miembro, desde la pantalla principal de TSO tecleamos P.3.4 para poder buscar el data set que queramos como hemos visto en la Figura 2.12. Buscamos el data set CICSTG.V7R2M0.CTGENVAR. Ahora, en la pantalla de la Figura 2.13 en vez de introducir una “v” delante del data set introducimos una “e” para poder modificar sus miembros además de listarlos. Situamos el cursor delante del miembro que queremos modificar y pulsamos Control. De esta forma se abre el miembro para que lo podamos consultar y editar, como se muestra en la Figura 2.16.

- 53 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 2.16 Miembro ENVCTG1A abierto para consulta y edición

Editamos el miembro para quede de la siguiente manera. Como cuando hemos editado un archivo Unix, las líneas que empiezan por Ñ son comentarios. En el Documento 2.2 podemos ver como queda el miembro con las variables de entorno para nuestra instalación Ñ Ruta Unix donde está el fichero .ini que hemos modificado anteriormente que Ñ es el que vamos a usar para inicializar este CTG CICSCLI=/etc/ctgvar/ctg1a.ini Ñ Ruta Unix donde se encuentran los archivos mínimos para poder ejecutar Ñ el ctgstart (arranque del CTG). Son las utilidades básicas de Unix que Ñ normalmente se encuentran en /bin y la ruta bin donde está instalado Java PATH=/bin:/usr/lpp/java/J5.0/bin Ñ Directorio temporal necesario para iniciar el CTG TMPDIR=/tmp Ñ Ejecuta los daemons del CTG en el mismo espacio de direcciones que Ñ el CTG en si mismo. Recomendado _BPX_SHAREAS=YES Ñ Nombre del recurso CONNECTION definido en el CICS. Necesario sólo si Ñ queremos conexión por EXCI Ñ Cuando usemos conexiones EXCI, descomentamos esta línea ÑDFHJVPIPE=CICSTG1A Ñ Nombre de los servidores CICS a los que queremos conectarnos por EXCI Ñ Creamos una entrada DFHJVSYSTEM_XX por cada CICS al que nos queremos Ñ conectar por EXCI Ñ Cuando usemos conexiones EXCI, descomentamos la primera línea ÑDFHJVSYSTEM_00=CICS1 – Conexión EXCI a CICS 1 ÑDFHJVSYSTEM_01=-Example production server

- 54 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Ñ Indica si vamos a usar EXCI y el data set donde se encuentran los Ñ módulos necesarios CTG_EXCI_INIT=NO ÑSTEPLIB=CICSTS.V3R2M0.CICS.SDFHEXCI Ñ Determina como los daemons del CTG van a reusar las pipes EXCI Ñ Por defecto está a ALL CTG_PIPE_REUSE=ALL Ñ Especifica el nombre del recurso que va a gestionar una instancia en Ñ particular del CTG Ñ Por defecto le damos el nombre del CTG y el sufijo .IBM.UA que tiene Ñ que llevar obligatoriamente CTG_RRMNAME=CTG1A.IBM.UA Ñ Especifica el máximo número de transacciones XA concurrentes Ñ Sólo hay que especificarlo si tenemos xasupport=on ÑCTG_XA_MAX_TRAN=1000 Ñ Indica si usamos autentificación de usuario/contraseña por EXCI AUTH_USERID_PASSWORD=NO Ñ Indica si en las contraseñas se puede usar mayúsculas y minúsculas Ñ Si está a YES podemos usar ambas y si está a NO convierte todo a mayúsculas Ñ Sólo hay que indicarlo se tenemos AUTH_USERID_PASSWORD=YES ÑCTG_MIXEDCASE_PW="NO" Ñ Indica si el CTG puede ser swappable Ñ Swappable significa que si el sistema se queda sin memoria principal Ñ aquellos programas marcados como swappables y que no estén ejecutandose Ñ pueden ser sacados a memoria secundaria hasta que se los necesite Ñ Se recomienda no ponerlo, así el CTG funciona en modo no swappable, a no Ñ ser que el CTG funcione en Modo Local Ñ Si está como swappable y a sido sacado a memoria secundaria, cualquier Ñ petición que se haga al CTG fallará ÑCTG_SWAPPABLE=NO Ñ Diferentes parámetros que se puede usar en el arranque del CTG ÑCTGSTART_OPTS=-x -j-Dgateway.T.setTFile=/ctgtrace.txt \ Ñ-j-Dgateway.T.setJNITFile=/jnitrace.txt Ñ Longitud de los mensajes que devuelve el CTG Ñ Ponemos 80 ya que es el ancho que muestra nuestra configuración de SDSF COLUMNS=80 Ñ Ajuste para reflejar la zona horaria en la que se encuentra el CTG Ñ Para más información consultar SA22-7802 z/OS UNIX System Services Command Ñ Reference Ñ La que se muestra es válida para la zona horaria de Madrid TZ=CET-1CEST,M3.5.0/2,M10.5.0/3 Ñ Directorio para volcar diferentes volcados de memoria en caso de fallo Ñ_CEE_DMPTARG=/tmp/jvmdump Documento 2.2 Miembro ENVCTG1A con las variables de entorno para nuestro CTG

Con esto ya tendríamos configurado el miembro de variables de entorno de acuerdo a nuestros requerimientos.

- 55 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.2.4.- Procedimiento de arranque El siguiente paso es crear un JCL de procedimiento de arranque que ejecutaremos como un job para que se inicie el CTG. 1.- Copiamos el procedimiento de arranque de ejemplo de CICSTG.V7R2M0.SCTGSAMP(CTGPROC) a PRUEBAS.USER.PROCLIB(CTG1A) El nombre del miembro a donde lo copiamos puede ser cualquiera pero lo dejamos con el mismo nombre que el CTG para que sea más fácil recordarlo. 2.- Modificamos el procedimiento de arranque para que quede de la siguiente manera y se adapte a nuestra instalación. En este caso, las líneas con comentario son las que empiezan por //*. En el Documento 2.3 podemos ver como queda el procedimiento de arranque para nuestro CTG. //CTGPROC PROC //* Ruta Unix donde está instalado el CTG // SET CTGHOME='/usr/lpp/cicstg/v7r2m0/' //* Cualificador de los data sets donde se encuentra instalado el CTG // SET CTGHLQ='CICSTG.V7R2M0' //* Data set y miembro donde se encuentran las variables de entorno //* Indicamos el miembro de variables de entorno que acabamos de personalizar // SET CTGUSR='CICSTG.V7R2M0.CTGENVAR(ENVCTG1A)' //* Opciones de ejecución acabadas en / //* No utilizamos ninguna // SET LEOPTS='/' //* //* Opciones de arranque del CTG //* REGION indica cuanta memoria puede coger el CTG para funcionar. //* 0M indica que infinita aunque luego esto lo cambiaremos //* TIME indica el tiempo máximo de CPU por día que puede usar el job //* 1440 es sinónimo de 24 horas, lo que es similar a infinito //CTG EXEC PGM=CTGBATCH,REGION=0M,TIME=1440, // PARM='&LEOPTS.&CTGHOME./bin/ctgstart -noinput ' //STEPLIB DD DSN=&CTGHLQ..SCTGLOAD,DISP=SHR //* //* Lugar donde se muestran los mensajes de salida y de error //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDENV DD DSN=&CTGUSR.,DISP=SHR //* //PEND // Documento 2.3 Procedimiento de arranque para nuestro CTG

Con esto ya tendríamos preparado el procedimiento de arranque que necesitamos para iniciar el CTG. Los siguientes pasos son crear las definiciones de RACF, o definiciones de seguridad, necesarias para que el CTG funcione.

- 56 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.2.5.- Definiciones de RACF El siguiente paso en la instalación del CTG es definir en RACF la Started Class, para que el CTG tenga permisos para ejecutarse, y el usuario al que va esta ligado la Started Class. El nombre de la Started Class será el que le hayamos dado al procedimiento de arranque, CTG1A, y al usuario lo vamos a definir con el nombre SCCTG, de StartedClassCTG. 1.- Creamos en Unix el directorio home con permisos 755 para el usuario al que va a estar ligado la Started Class. El directorio home estará en “/u/SCCTG”. 2.- Tenemos que crear las siguientes definiciones de RACF:  Un usuario Unix  Una Started Class o No definimos la Started Class CTG1A sino la CTG1* de forma que más adelante podamos tener la Started Class CTG1B, etc. para un grupo de CTGs en Port Shared sin tener que volver a hacer definiciones  Asociar el usuario a la Started Class  Para hacer el CTG no swappable, debemos incluir al usuario en la lista de acceso del perfil BPX.STOR.SWAP de la clase FACILITY con permiso de lectura Esto lo haremos ejecutando el JCL que podemos ver en el Documento 2.4. //RACFCTG JOB (77005),'JPM', // CLASS=I,MSGCLASS=X,MSGLEVEL=(1,1), // NOTIFY=&SYSUID //S1 EXEC PGM=IKJEFT01,REGION=1M //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * BPX.SMF //* DEFINICIONES PARA CTG: STARTED CLASS Y USUARIO ADDUSER SCCTG DFLTGRP(STCUSR ) + DATA('USUARIO STARTED CLASS CTG ') + OMVS(UID(0) HOME('/u/SCCTG') PROGRAM('/bin/sh')) NOPASSWORD RDEFINE STARTED CTG1*.* STDATA( USER(SCCTG) PRIVILEGED(NO) + TRUSTED(NO) TRACE(NO) ) PERMIT BPX.STOR.SWAP CLASS(FACILITY) ACCESS(READ) ID(SCCTG) SETROPTS RACLIST(FACILITY) REFRESH SETROPTS RACLIST(STARTED) REFRESH /* Documento 2.4 JCL con definiciones de RACF

En el caso de usar EXCI, debemos añadir los siguientes permisos: RDEFINE SURROGAT *.DFHEXCI UACC(NONE) OWNER(SYSADMIN) PERMIT *.DFHEXCI CLASS(SURROGAT) ID(SCCTG) ACCESS(READ) SETROPTS RACLIST(SURROGAT) REFRESH

Para definir la FACILITY en caso de que no lo estuviera, añadiremos además lo siguiente antes de “PERMIT BPX.STOR.SWAP …”: RDEFINE FACILITY BPX.STOR.SWAP SETR RACLIST(FACILITY) REFRESH

- 57 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Con esto ya hemos realizado todas las operaciones necesarias sobre TSO. El siguiente paso es crear e instalar en CICS las definiciones necesarias tanto si vamos a usar una conexión EXCI como una IPIC. 2.3.3.- Creación de la conexión entre el CTG y el CICS Para poder definir recursos en el CICS e instalarlos, lo primero que tenemos que hacer una vez que nos hemos conectado a CICS correspondiente, en este caso el CICS1, por medio del emulador, es identificarnos en el sistema. Para ello tecleamos CESN y pulsamos Control. Esto arranca la transacción CESN que, como ya hemos indicado, es la transacción suministrada por CICS para identificarnos en el sistema. En algunos sistemas esto no hará falta ya que por defecto se arranca la CESN al conectarnos al CICS. En la Figura 2.17 podemos ver la pantalla inicial de la CESN donde tenemos que introducir nuestro usuario y contraseña y pulsar Control para identificarnos.

Figura 2.17 Pantalla inicial de la CESN

Una vez que nos hayamos identificado correctamente, en la parte inferior de la pantalla nos aparecerá el mensaje que podemos ver en la Figura 2.18.

Figura 2.18 Mensaje de identificación correcta

Con esto ya nos hemos identificado correctamente y podemos seguir definiendo los recursos necesarios e instalándolos.

- 58 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.3.3.1.- Conexiones EXCI Antes de realizar las definiciones necesarias para la conexión EXCI, tenemos que comprobar que en la SIT, o System Initialization Table, del CICS correspondiente, tenemos los siguientes parámetros con los valores adecuados:  

ISC = YES IRCSTRT = YES

Para comprobar estos valores, por medio de una sesión TSO tenemos que comprobar el data set y el miembro que actúa como SIT para el CICS donde nos queremos conectar. En nuestro caso, el data set es el PRUEBAS.CICS1.TABLAS y el miembro es el DFHSITJT. Comprobando este miembro vemos que tenemos los parámetros antes mencionados con el valor adecuado. En caso de no ser así, habría que modificar el miembro y volver a compilar la SIT lo que no vamos a explicar como hacerlo por considerar que queda fuera del ámbito del proyecto. Lo primero que tenemos que hacer para poder usar conexiones EXCI es descomentar las siguientes líneas en el miembro de las variables de entorno:  

DFHJVPIPE=CICSTG1A DFHJVSYSTEM_00=CICS1 – Conexión EXCI a CICS 1

Para crear una conexión EXCI entre el CTG y el CICS, tenemos que definir e instalar los siguientes recursos:  

CONNECTION SESSIONS

Los recursos tienen que ir definidos en un grupo con nombre de 8 caracteres máximos que en este caso le llamaremos EXCTG1A, de EXCI y CTG1A. A las CONNECTION y SESSIONS la llamaremos CTG1 ya que su nombre sólo puede ser de 4 caracteres. No hay ningún problema por definir dos recursos de distinto tipo con el mismo nombre. Una vez que nos hemos identificado en el CICS, ejecutamos el comando CEDA DEF CONNECTION(CTG1) G(EXCTG1A) como podemos ver en la Figura 2.19.

- 59 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 2.19 Comando para definir una CONNECTION

Nos aparecerá una pantalla como la que podemos ver en la Figura 2.20.

Figura 2.20 Pantalla de definición de CONNECTION

Vemos como en la parte inferior nos indica que el grupo se ha creado, ya que no existía. Por medio de las teclas F7 y F8 nos desplazamos adelante y atrás en la pantalla de definición de la CONNECTION. La mayoría de los atributos los dejamos como están por defecto pero a algunos los modificamos para darles los siguientes valores:

- 60 -

Mikel Castillejo Erviti

      

Universidad Pública de Navarra

CONnection : CTG1 Group : EXCTG1A Netname : CTG1A o El applid del CTG ACcessmethod : IRc Protocol : Exci Conntype : Specific ATtachsec : Identify

Una vez que tengamos todos los parámetros adecuados pulsamos Control para terminar con la definición de la CONNECTION. En la parte inferior de la pantalla nos aparecerá el mensaje que podemos ver en la Figura 2.21.

Figura 2.21 Mensaje de definición correcta

Una vez que hemos terminado con la definición de la CONNECTION, pulsamos F3 para salir de la pantalla de definición y luego la tecla Pausa para borrar la pantalla y poder empezar a definir la SESSIONS. Para definir una SESSIONS de nombre CTG1 en el grupo EXCTG1A ejecutamos el comando CEDA DEF SESSIONS(CTG1) G(EXCTG1A). Nos aparecerá una pantalla similar a la de la definición de la CONNECTION pero con diferentes parámetros. Los parámetros a los que ahora tenemos que cambiar su valor son los siguientes:  Sessions : CTG1  Group : EXCTG1A  Connection : CTG1A  Protocol : Exci  RECEIVEPfx : S1  RECEIVECount : 004  SENDSize : 30720  RECEIVESize : 30720 Cuando tengamos los parámetros con sus valores correctos pulsamos Control y nos aparecerá el mensaje de la Figura 2.21. Pulsamos F3 y Pausa para salir de la definición y borrar la pantalla. Con esto ya tenemos definidos los recursos necesarios. Ahora tenemos que instalar el grupo con sus definiciones. Esto lo hacemos ejecutando el comando CEDA I G(EXCTG1A). Nos aparecerá en la parte inferior de la pantalla el mensaje de la Figura 2.22 indicándonos que la instalación del grupo se ha realizado correctamente.

Figura 2.22 Mensaje de instalación correcta de grupo

- 61 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Si acabamos aquí, cada vez que se pare y arranque el CICS tendríamos que instalar el grupo. Para evitar esto, podemos añadir el grupo a una de las listas de arranque de CICS. De esta forma, al arrancar el CICS automáticamente se instalan todos los recursos que se encuentran en los grupos que están en las listas de arranque. En nuestro caso, una de estas listas es la LISTAARR. Para añadir el grupo EXCTG1A a la lista ejecutamos el comando CEDA ADD GROUP(EXCTG1A) LIST(LISTAARR). Con esto ya tendríamos todo lo necesario para que el CTG funcione por medio de conexiones 2.3.2.- Conexiones IPIC Para poder conectarnos por IPIC al CICS, tenemos que tener definidos los siguientes recursos:  

TSPIPSERVICE IPCONN

El primero es obligatorio definirlo mientras que el segundo podemos definirlo a mano o hacer que se defina e instale automáticamente. En principio utilizaremos esta segunda opción ya que, de momento, la definición que hace del IPCONN por defecto nos es válida. Lo definiremos manualmente más adelante cuando queramos habilitar la seguridad. En este caso el nombre del TCPIPSERVICE puede ser de 8 caracteres por lo que le daremos el nombre CTG1A. El grupo donde definimos los recursos para la conexión IPIC será el IPCTG1A. Para definir el TSPIPSERVICE, ejecutamos el comando CEDA DEF TCPIPSERVICE(CTG1A) G(IPCTG1A). Nos aparecerá una pantalla similar a la de la Figura 2.20 pero ahora los parámetros que tenemos que modificar y su valor son los siguientes:  Tcpipservice : CTG1A  Group : IPCTG1A  POrtnumber : 20061 o Puerto reservado en el CICS para conectar el CTG1A  PROtocol : IPIC  TRansaction : CISS Cuando hayamos terminado pulsamos Control y nos aparecerá el mensaje de la Figura 2.21. Con esto ya tenemos definidos los recursos necesarios para poder usar una conexión IPIC. Instalamos el grupo con el comando CEDA I G(IPCTG1A). Nos aparecerá el mensaje de la Figura 2.22 con lo que ya tenemos todo preparado para poder usar conexiones IPIC. Al igual que con la conexión EXCI, si queremos que automáticamente se instale el grupo al arrancar el CICS, añadiremos el grupo IPCTG1A a la lista LISTAARR con el comando CEDA ADD GROUP(EPCTG1A) LIST(LISTAARR). 2.3.4.- Arranque y parada del CTG 2.3.4.1.- Arranque del CTG Siguiendo los pasos vistos anteriormente ya tenemos todo preparado para poder iniciar el CTG. El CTG necesita una serie de subsistemas o productos pare funcionar que tienen que estar

- 62 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

inicializados antes de iniciar la ejecución del CTG. Estos productos y su orden de arranque son los siguientes: 1. 2. 3. 4.

RRS, se inicia al arrancar el mainframe o la LPAR TCP/IP CICS CTG

Para poder iniciar el CTG, desde la pantalla inicial de TSO tecleamos SD y pulsamos Control para iniciar el SDSF. Una vez en la pantalla inicial del SDSF, tecleamos LOG y pulsamos Control para abrir el Log del sistema. En este Log podemos ver mensajes sacados por los programas en ejecución, comandos ejecutados, mensajes de respuesta del z/OS, etc. Esto lo hace idóneo para iniciar el arranque del CTG y ver si este se realiza correctamente. Podríamos arrancar el CTG desde cualquier cola del SDSF utilizando el mismo método que vamos a ver a continuación pero sería más complicado comprobar su arranque correcto. Para iniciar el arranque del CTG, nos situamos como ya hemos dicho en el panel de Log del SDSF que podemos ver en la Figura 2.23.

Figura 2.23 Panel de Log del SDSF

Una vez en este panel pulsamos repetidamente F8 hasta llegar a la parte inferior del Log. Una vez ahí, para arrancar el CTG ejecutamos desde la línea de comandos del panel el comando “/s ”, sin las comillas, lo que en nuestro caso será “/s ctg1a”. Si pulsamos repetidamente F8, veremos que en el Log empezarán a aparecer mensajes que nos indica que el CTG se está arrancando. Sabremos que el CTG ha arrancado correctamente y de forma satisfactoria cuando en el Log veamos que aparece el mensaje que podemos ver en la Figura 2.24.

Figura 2.24 Mensaje de inicialización completa del CTG

- 63 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Con esto ya tendríamos el CTG preparado para recibir y contestar peticiones. 2.3.4.2.- Parada del CTG En algunos casos, por ejemplo porque queremos realizar modificaciones o porque queremos apagar el mainframe, vamos a necesitar parar el CTG. Para ello nos situaremos al final del panel de Log como hemos visto anteriormente y ejecutaremos alguno de los siguientes comandos:  /p  /f ,appl=shutdown  /f ,appl=immediate Los dos primeros comandos realizan una parada normal del CTG. El CTG espera a que las transacciones que se están ejecutando finalicen aunque no admite más peticiones. Se recomienda parar el CTG con alguno de estos comandos. El tercer comando realiza una parada inmediata del CTG. Las transacciones que se estaban ejecutando finalizan de manera anormal, Abnormally END o ABEND para el mainframe. Si se estaba ejecutando alguna LUW, esta finaliza y se hace backout de los cambios que había realizado. Si se estaba ejecutando alguna transacción XA, se hace backout de los cambios que había realizado y las tareas que quedan por realizar se quedan en espera en el RRS hasta que el CTG se reinicia, o se ejecutan en otro CTG del mismo grupo. Cuando lanzamos un comando de parada del CTG, sabemos que este ha parado correctamente cuando en el Log se nos muestra el mensaje que podemos ver en la Figura 2.25.

Figura 2.25 Mensaje de parada correcta del CTG

El orden de parada de los subsistemas o productos que hemos visto anteriormente que son necesarios para que funcione el CTG es el inverso al de arranque.

2.4.- Prueba con COMMAREA Una vez que ya tenemos el CTG configurado y listo para atender peticiones, el siguiente paso es ver como realizar estas peticiones. Para ello vamos mostrar la manera de hacerlo primero desde aplicaciones escritas en Java y luego desde aplicaciones escritas en .Net. Como ya hemos comentado, sólo vamos a utilizar la API ECI ya que tanto la EPI como la ESI no están disponibles debido al tipo de arquitectura que tenemos. 2.4.1.- Aplicaciones Java A la hora de hacer peticiones Java de programas CICS hay dos clases fundamentales que vamos a utilizar:  

JavaGateway ECIRequest

- 64 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

La primera de ellas la utilizaremos para realizar la conexión entre nuestra aplicación y el CTG. Será por donde enviemos y recibamos las peticiones. La segunda la vamos a utilizar para enviar los datos de la petición que vamos a realizar, usuario y contraseña en caso de ser necesario, programa que queremos ejecutar, datos de entrada, etc. También es por donde vamos a recibir la respuesta del CTG con los resultados obtenidos. Estas clases se encuentran ambas en la librería ctgclient.jar que se provee junto con el CTG. Dentro de esta librería, ambas clases se encuentran dentro del paquete com.ibm.ctg.client. Este paquete será el que tengamos que importar a nuestras aplicaciones para hacer uso de ambas clases. Para añadir una librería a un proyecto de NetBeans, que es la suite de programación que vamos a usar, tenemos que hacer lo siguiente: 1. Descargarnos a nuestro ordenador, en modo binario, desde la parte Unix del mainframe el archivo ctgclient.jar que en general se encontrará en la ruta /usr/lpp/cicstg//classes  Para ello nos conectaremos por FTP al mainframe con algún programa que lo permite como el BlueZone Secure FTP v5.0 que se ha usado en nuestro caso y trasferiremos el archivo. Las instrucciones de cómo hacer esto las tenemos en el Anexo 1. 2. Una vez creado el proyecto de NetBeans donde queremos importar la librería, importamos el archivo a la carpeta “Bibliotecas”.  Hacemos clic derecho sobre la carpeta “Bibliotecas” y seleccionamos “Agregar archivo JAR/carpeta…” como podemos ver en la Figura 2.26.

Figura 2.26 Agregar archivo JAR/carpeta…



En la ventana que nos aparece, buscamos el archivo que hemos transferido a nuestro ordenador, lo seleccionamos y pulsamos el botón “Abrir” como podemos ver en la Figura 2.27.

Figura 2.27 Agregar archivo ctgclient.jar

- 65 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

3. Al principio del archivo .java en el cual queramos hacer uso de las clases antes mencionadas, añadimos la siguiente instrucción  import com.ibm.ctg.client.*; Con esto ya tendríamos todo preparado para hace uso de las clases necesarias para realizar peticiones al CTG. Los pasos que vamos a seguir para realizar peticiones al CTG van a ser los siguientes: 1. 2. 3. 4. 5.

Crear la conexión con el CTG Crear la petición con los datos de entrada que vamos a enviar por la conexión Enviar la petición y recoger la respuesta Comprobar que no se a producido ningún error Tratar los datos de salida

Por ejemplo, vamos a ver como invocar a un programa CICS llamado EJEMPLO1 al cual le pasas en una COMMAREA un DNI y te devuelve los datos que hay en el sistema de la persona con ese DNI. En un principio, el programa se haría más dinámico cogiendo la mayoría de los datos por medio de una interfaz gráfica en vez de, por ejemplo, poner la URL del CTG fija, para así poder realizar peticiones a más de un CTG, cambiar los datos de entrada, etc. Iremos comentando los diferentes pasos que vamos realizando y después del ejemplo explicaremos más en profundidad algunos de los pasos. Este ejemplo lo podemos ver en el Documento 2.5. //Declaramos las variables de entrada que vamos a utilizar JavaGateway jg; ECIRequest er; String URL; int puerto; String servidor; String programa; byte[] commarea; int longitudCommarea; String transid; String dni; //Inicializamos las variables con los datos que necesitamos //URL donde se encuentra el CTG URL = "20.20.20.1"; //Puerto donde se encuentra el CTG puerto = 2006; //Nombre del servidor CICS al que queremos hacer la petición ya que el CTG //puede estar conectado a más de un CICS servidor = "CICS1"; //Programa al que queremos hacer la petición programa = "EJEMPLO1"; //Inicializamos el DNI y lo añadimos en forma de bytes a la COMMAREA que será // la que le pasemos al programa dni = "000000001"; commarea = dni.getBytes("ASCII"); //Longitud de la COMMAREA. Necesario para que funcione el programa longitudCommarea = 281;

//Abrimos la conexión con el CTG jg = new JavaGateway(); try {

- 66 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

//Intentamos crear la conexión con el CTG en la URL y puerto indicados jg = new JavaGateway(URL, puerto); } catch (IOException ioe) { //Error al abrir la conexión //Tratamos el error como corresponda, por ejemplo mostrando un mensaje //Comprobamos si la conexión sigue abierta y si es así la cerramos if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } //Finalizamos la ejecución de la aplicación System.exit(1); }catch (Exception e) { //Error de otro tipo al abrir la conexión //Realizamos los mismos pasos que hemos mencionado anteriormente if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); } //Creamos la petición //Nombre de la transacción que queremos que se ejecute //A continuación veremos la importancia de esto transid = "F000"; //Inicializamos la petición con los parámetros adecuados //Más adelante veremos con más detalle cuales son estos parámetros //y los valores que pueden tomar er = new ECIRequest( ECIRequest.ECI_SYNC, servidor, null, null, programa, transid, commarea, longitudCommarea, ECIRequest.ECI_NO_EXTEND, 0); //Lanzamos la petición int iRc = 0; try{ //Lanzamos la petición por la conexión creada iRc = jg.flow(er); } catch (IOException ioe) { //Error al invocar el programa //Lo tratamos como corresponda //Cerramos la conexión si sigue abierta y finalizamos la aplicación if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); } //Comrpobamos si se ha producido algún error switch (er.getCicsRc()) { case ECIRequest.ECI_NO_ERROR: if (iRc == 0) { //No se han producido errores

- 67 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

//Salimos del case ya que no tiene sentido seguir //comprobando errores break; } else { //Error en la Gateway //Cerramos la conexión si sigue abierta y //finalizamos la aplicación if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); } case ECIRequest.ECI_ERR_SECURITY_ERROR: //Error de seguridad //Cerramos la conexión si sigue abierta y //finalizamos la aplicación if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); case ECIRequest.ECI_ERR_TRANSACTION_ABEND: //Error de ABEND (Abnormal End o final anormal) //al ejecutar el programa if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); default: //Problema general invocando al programa //Cerramos la conexión si sigue abierta y //finalizamos la aplicación if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t2) { ; } } System.exit(1); } //Cerramos la conexión si sigue abierta if (jg.isOpen() == true) { try { jg.close(); } catch (Throwable t1) { ; } } //Recuperamos de la COMMAREA los datos que nos ha devuelto el programa //que hemos invocado y los tratamos como corresponda //En este caso sólo los mostramos por pantalla String salida = new String(commarea, "ASCII"); Documento 2.5 Ejemplo de petición Java a programa de COMMAREA

A la hora de crear la conexión entre la aplicación y el CTG por medio de la clase JavaGateway, el formato del parámetro URL que le pasamos tiene que se ://. El protocolo puede ser TCP o SSL. Si no le indicamos nada coge por defecto TCP. Como en la mayoría de los casos usaremos TCP, cuando sea así no le indicamos nada.. Con esto la URL quedaría reducida a . La dirección será la dirección IP donde estará escuchando el CTG que será la IP de la LPAR donde está instalado el CTG. Opcionalmente, si tenemos un servidor de DNS que

- 68 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

transforma las direcciones IP en nombres, le podemos pasar el nombre de la LPAR. Por ejemplo, en nuestro caso le podríamos pasar la IP 20.20.20.1 o el nombre PRUEBAS ya que tenemos un servidor DNS que se encarga de hacer la conversión entre ambos. En general, el tratamiento de los errores será mostrar un mensaje al usuario indicándole el error que se ha producido. En algunos casos, como el error de seguridad, podríamos hacer un tratamiento diferente como podría ser solicitar un usuario o usuario y contraseña válidos. Podríamos tratar cada uno de los errores que se pueden producir por separado pero hemos optado por tratar los más comunes como el error de seguridad o el error porque la transacción ha finalizado con un ABEND o finalización anormal. Agrupamos en el caso default el resto de errores que se pueden producir. Aunque no debería suceder, si dejamos el programa de esta manera, al intentar crear la clase JavaGateway para abrir la conexión con el CTG el programa se queda parado y no pasa de esa instrucción. Para remediar esto, creamos una JavGateway en el main de la aplicación. El main, en el caso de usar NetBeans, se encontrará en el archivo App.java. Creamos la JavaGateway con cualquier URL y puerto. Esto nos producirá una excepción de Entrada/Salida pero la capturamos de la forma habitual y no hay ningún problema. De esta forma ya funciona correctamente la instrucción de crear la JavaGateway para abrir la conexión con el CTG. Así quedaría el main de la aplicación para que todo funcione correctamente: public static void main(String[] args) { JavaGateway jg; try { jg = new JavaGateway("localhost", 65000); } catch (IOException ex) { } //A continuación está la única instrucción que había originalmente //en el main y que la dejamos como estaba launch(App.class, args); }

Es especialmente importante la inicialización de la clase ECIRequest y de sus parámetros por lo que vamos a explicar más detalladamente cada uno de ellos y los valores que pueden tomar. El constructor de la clase ECIRequest para peticiones con COMMAREA tiene los siguientes parámetros:          

Tipo de llamada Nombre del servidor CICS Usuario Contraseña Programa Transid COMMAREA Longitud de la COMMAREA Modo extendido Token LUW

- 69 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Hay más constructores con diferentes parámetros, como no indicar el Modo extendido, un constructor para usar Canales y Contenedores, etc. pero este es el que vamos a usar para realizar peticiones a programas que usan COMMAREA. Vamos a pasar a explicar para que sirve cada uno de estos parámetros, o campos de la clase, y los valores que pueden tomar. 2.4.1.1.- Tipo de llamada Indica el tipo de llamada que queremos hacer con la petición. Para darle valor a este parámetro usaremos unas constantes definidas en la clase ECIRequest. Entre las diferentes llamadas que podemos hacer tenemos las siguientes que son las que más nos pueden interesar:    

Síncrona Síncrona con TPN Asíncrona Asíncrona con TPN

: Constante ECI_SYNC : Constante ECI_SYNC_TPN : Constante ECI_ASYNC : Constante ECI_ASYNC

Las llamadas síncronas envían la petición y se quedan a la espera de recibir una respuesta. Por su parte, las asíncronas envían la petición y continúan ejecutando instrucciones. Tenemos que comprobar cada cierto tiempo que hemos recibido respuesta. Los programas en CICS no tardan mucho en ejecutarse. Como mucho un par de segundos, normalmente medio segundo o menos. Esto, junto con el hecho de que si usamos servlets para desarrollar aplicaciones Web no nos permite hacer uso de los tipos ECI_ASYN y ECI_ASYN_TPN, hace que nos decantemos por usar peticiones síncronas. Las llamadas sin TPN ejecutan el programa que le hayamos indicado bajo el control de la transacción por defecto del CTG que es la CSMI. Las llamadas con TPN ejecutan también el programa que le hayamos indicado pero bajo el control de la transacción que le indiquemos en el parámetro Transid. Veremos más adelante como esto es muy importante por ejemplo para permitir que el programa pueda acceder a DB2. Entre los tipos de llamadas, podemos encontrar útil el tipo CICS_EciListSystems. Esto nos devuelve los servidores CICS a los que podemos tener conectado el CTG. Nos devuelve los servidores conectados por IPIC definidos en las secciones IPICSERVER del archivo .ini de inicialización y los servidores conectados por EXCI definidos como DFHJVSYSTEM_XX en el miembro de variables de entorno. Esto sólo nos devuelve los servidores CICS que tenemos definidos, esto no quiere decir que realmente tengamos conexión con ellos. Más fácil que usar esto, es usar la siguiente instrucción: ECIRequest er = ECIRequest.listSystems(num_servidores); Esto nos devuelve una petición ECI preparada para devolvernos, al lanzarla, los primeros num_servidores servidores definidos. Hay que indicar que, entre los diferentes tipos de llamadas que hay, las conexiones IPIC no soportan los siguientes:   

ECI_GET_REPLY ECI_GET_REPLY_WAIT ECI_GET_SPECIFIC_REPLY - 70 -

Mikel Castillejo Erviti        

Universidad Pública de Navarra

ECI_GET_SPECIFIC_REPLY_WAIT ECI_STATE_ASYNC ECI_STATE_ASYNC_JAVA ECI_STATE_CANCEL ECI_STATE_CHANGED ECI_STATE_IMMEDIATE ECI_STATE_SYNC ECI_STATE_SYNC_JAVA

Esto nos limita los tipos de llamadas a las anteriormente mencionadas síncronas y asíncronas con o sin TPN y la CICS_EciListSystems. 2.4.1.2.- Nombre del servidor CICS Este parámetro nos indica el nombre del servidor CICS al que queremos realizar la petición. Puede tomar cualquier valor que indique un nombre de CICS definido en el archivo de inicialización .ini o en el miembro de variables de entorno. Si indicamos un CICS no definido o uno que no está actualmente funcionando, la petición finalizará con el error ECI_ERR_NO_CICS. 2.4.1.3.- Usuario Por medio de este parámetro le podemos indicar el identificador de usuario con el que queremos hacer la petición. Esto nos sirve en caso de que tengamos configurada seguridad en el CTG. Aunque los usuarios normalmente se definen en RACF con mayúsculas, podemos pasarle el usuario tanto en mayúsculas como en minúsculas ya que, normalmente, el sistema lo convierte automáticamente a mayúsculas. Podemos introducir cualquier valor que indique un identificador de usuario que esté definido en RACF. En caso de no ser así, o de no introducir un identificador de usuario teniendo la seguridad del CTG habilitada, la petición finalizará con el mensaje de error ECI_ERR_SECURITY_ERROR. Aunque no tengamos habilitada la seguridad, si le pasamos un identificador de usuario junto con un tipo de llamada con TPN, el programa se ejecuta bajo el identificador de usuario que le hayamos especificado. Esto puede ser útil por ejemplo por motivos de auditoría, para saber que usuarios ejecutan que programas y transacciones. 2.4.1.4.- Contraseña Este parámetro nos va a permitir especificar una contraseña válida para el identificador de usuario que especifiquemos. En algunos casos, como veremos más adelante, según como tengamos configurada la seguridad en el CTG puede que sea necesario indicar un identificador de usuario pero no una contraseña. Normalmente las contraseñas de RACF contienen tanto mayúsculas como minúsculas por lo que el sistema no convierte todo automáticamente a mayúsculas como hace con el usuario. Esto hace que tengamos que respetar las mayúsculas y minúsculas al introducir la contraseña.

- 71 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Si introducimos una contraseña errónea para el identificador de usuario introducido, o si no introducimos contraseña y es necesaria, la petición finalizará con el mensaje de error ECI_ERR_SECURITY_ERROR. 2.4.1.5.- Programa Por medio de este parámetro indicaremos el identificador de programa CICS, de 8 caracteres máximo, que queremos que se ejecute. El identificador del programa tiene que ser escrito en mayúsculas. En caso de introducir un identificador de programa que no se encuentre instalado en el CICS, o si introducimos el nombre el minúsculas, la petición finalizará dando un error ECI_ERR_TRANSACTION_ABEND y nos indicará un código identificador de ABEND que normalmente será el AEI0 en caso de no encontrar el programa indicado. 2.4.1.6.- Transid Este parámetro nos permite indicar un identificador de transacción CICS de 4 caracteres. En caso de no indicarle un Transid, el programa que ejecutemos lo hará bajo el control de la transacción por defecto que es la CSMI. Si indicamos un Trasnid y el tipo de llamada es ECI_SYNC_TPN, u otro con TPN, el programa se ejecutará bajo el control de la transacción que le indiquemos. En caso de indicarle un Transid pero con el tipo de llamada ECI_SYNC, u otro sin TPN, el programa se ejecuta bajo el control de la transacción por defecto pero esta coge el alias que le indiquemos. Las diferencias entre estas tres posibilidades y lo que ello implica lo explicaremos más adelante. El identificador de transacción normalmente está definido en CICS en mayúsculas. Si le pasamos un identificador en minúsculas no se produce ningún error pero CICS no reconoce esta transacción y el resultado es como si no hubiésemos indicado ningún Transid. 2.4.1.7.- COMMAREA En este parámetro le pasaremos el nombre de una variable de tipo byte[], es decir, un array de bytes. En esta variable introduciremos los datos de entrada que le tengamos que pasar al programa que vamos a ejecutar. Cuando finalice la ejecución del programa, en esta variable encontraremos la respuesta que nos ha devuelto el programa tras su ejecución. 2.4.1.8.- Longitud de la COMMAREA Este parámetro indicará la longitud de la COMMAREA que vamos a utilizar. Esto es muy importante ya que la longitud que indiquemos será la longitud de la COMMAREA que se envíe y reciba al hacer la petición. Si este valor es mayor del necesario, estaremos enviando datos inútilmente con la sobrecarga de la red que esto conlleva. Si este valor es menor que el necesario, no enviaremos o recibiremos todos los datos necesarios. Esto puede producir que no se envíen todos los datos de entrada necesarios para que el programa funcione o que recibamos menos datos de respuesta de los que deberíamos, perdiendo de esta manera información.

- 72 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Normalmente, si indicamos un valor de longitud de COMMAREA menor que el que necesita el programa que queremos ejecutar para funcionar se producirá un ABEND. El código de este ABEND dependerá del programa. Por otro lado, si el valor es mayor que el que necesita el programa, normalmente no se producirá ningún error aunque estaremos desperdiciando conexión. En algunos casos si que se producirá un ABEND y, al igual que antes, el código depende del programa. 2.4.1.9.- Modo extendido Por medio de este parámetro vamos a poder manejar una LUW para realizar varias peticiones al CICS que podremos confirmar, commit, o deshacer, backout o rollback, de forma conjunta. También podemos realizar una petición simple que se confirma automáticamente al finalizar. Como manejar LUWs por medio de este parámetro se explica más adelante. Para realizar una petición simple de un programa y que se confirma le daremos el valor de la constante ECI_NO_EXTEND definida en la clase ECIRequest. 2.4.1.10.- Token LUW Al igual que con el parámetro anterior, este parámetro nos permite manejar LUWs. En caso de que queramos hacer una petición simple le daremos el valor de la constante ECI_LUW_NEW definida en la clase ECIRequest o directamente le daremos el valor 0. 2.4.3.- Transacción CICS ejecutada Como hemos visto anteriormente, por medio del tipo de llamada y del parámetro Transid podemos controlar bajo que transacción se ejecuta el programa que hemos solicitado. Si utilizamos un tipo de llamada con TPN, por ejemplo, ECI_SYNC_TPN, y le especificamos una transacción en Transid, el programa se ejecutará bajo la transacción indicada. Si no utilizamos un tipo de llamada con TPN, por ejemplo ECI_SYNC, pero especificamos en Transid una transacción válida, el programa se ejecuta bajo la transacción por defecto aunque a esta se le da el alias especificado en Transid. La transacción por defecto es la CSMI para el CTG de z/OS y la CPMI para el CTG multiplataforma. Por último, si no usamos una llamada con TPN ni especificamos un Transid, el programa se ejecuta bajo la transacción por defecto. La transacción por defecto, la CSMI en nuestro caso, no tiene permisos de acceso a DB2, a no ser que se los hayamos dado. Si hacemos una petición de un programa que acceda a DB2, como el EJEMPLO1 usado anteriormente, sin usar uno de los dos primeros métodos, no se produce un error al ejecutar el programa pero en vez de devolvernos los datos que debería nos da un error SQL -923. Este error se da, entre otras razones, cuando tenemos un acceso restringido a DB2 como es nuestro caso. Si queremos hacer uso de un programa que acceda a DB2 tenemos que ejecutarlo, o bien bajo una transacción con acceso a DB2 o bien bajo la transacción por defecto pero dándole el alias de una transacción con acceso a DB2. Hay que tener en cuenta que la transacción bajo la que se ejecuta el programa, la CSMI si no usamos una llamada con TPN o la indicada en el parámetro Transid en caso contrario, tiene que apuntar obligatoriamente al programa DFHMIRS que es el que se arranca primeramente cuando hacemos uso del CTG. No vamos a explicar como hacer que una transacción apunte a un programa determinado o como darle acceso a DB2 por considerar que queda fuera del ámbito de este proyecto.

- 73 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Cuando ejecutamos una transacción con el alias de otra, lo que hacemos es darle a la primera las características de la segunda. Entre otras cosas, esto puede ser útil para:   

Control de recursos y comandos Asignación de prioridades iniciales Asignación de selección de plan de base de datos, lo que significa acceso a DB2

La mayor diferencia entre ejecutar una transacción con el alias de otra, o ejecutar directamente la segunda transacción, es que con el segundo método podemos comprobar más fácilmente las transacciones ejecutadas, lo que nos puede ser útil para motivos de auditoría. 2.4.4.- Manejo de LUWs Como hemos indicado anteriormente, una LUW es un grupo de transacciones o programas, a los cuales hacemos commit o rollback en grupo, como si fuesen uno solo. Esto quiere decir que si hacemos commit lo hacemos sobre los cambios que han realizado todos los programas y, si uno falla y hace rollback, hacemos rollback sobre los cambios que han realizado todos los programas. Una LUW finaliza cuando se dan uno de los siguientes sucesos:   

Hacemos commit o rollback específicamente sobre la LUW Una de los programas ejecuta de forma específica un commit Se produce un error y se ejecuta un rollback automáticamente

Para manejar las LUWs vamos a utilizar principalmente tres atributos de las peticiones ECI que son:   

Extend_Mode: modo de la petición ECI Program: nombre del programa que queremos que se ejecute en el CICS Luw_Token: token que identifica a la LUW que estamos manejando

En la Tabla 2.4 podemos ver una relación entre estos atributos y los valores que les tenemos que dar dependiendo de la operación que queramos realizar sobre una LUW. Tarea a realizar Llamada a un programa que es el único de una LUW. Se lanza una petición del cliente al servidor y una respuesta es enviada al cliente sólo cuando todos los cambios realizados por el programa han sido confirmados.

Llamada a un programa que es el primero de una LUW.

Valor de los atributos Extend_Mode = ECI_NO_EXTEND Program = especificar Luw_Token = 0 o ECI_LUW_NEW Extend_Mode = ECI_EXTENDED Program = especificar Luw_Token = 0 o ECI_LUW_NEW Guardar el valor del Luw_Token de la respuesta

Llamada a un programa que es la continuación de una LUW. Llamada a un programa que es la última

Extend_Mode = ECI_EXTENDED Program = especificar Luw_Token = valor_guardado Extend_Mode = ECI_NO_EXTEND

- 74 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

de una LUW y confirmar los cambios. Finalizar una LUW existente y confirmar los cambios. Finalizar una LUW existente y desechar los cambios.

Program = especificar Luw_Token = valor_guardado Extend_Mode = ECI_COMMIT Program = NULL Luw_Token = valor_guardado Extend_Mode = ECI_BACKOUT Program = NULL Luw_Token = valor_guardado

Tabla 2.4 Atributos y valores para manejar LUWs

Si estamos utilizando conexiones EXCI, podemos habilitar una traza llamada JNI donde podemos observar información sobre las diferentes peticiones a una LUW. Para habilitar la traza JNI, en el miembro de variables de entorno añadimos las siguientes líneas:  

CTG_JNI_TRACE_ON=YES CTG_JNI_TRACE=/SYSTEM/tmp/ctg1_jni_trace.txt

La primera línea habilita la traza JNI y la segunda indica la ruta del fichero en la parte Unix donde queremos que se almacene la traza. Si tenemos arrancado el CTG y añadimos estas líneas al miembro de variables de entorno, tendremos que parar y volver a arrancar el CTG para que coja los cambios introducidos. Una vez que tenemos habilitada la traza JNI, ejecutamos una LUW haciendo dos peticiones a un programa llamado EC01 y por último haciendo commit sobre la LUW. En el archivo de la traza JNI, entre otras cosas, podemos ver lo siguiente: Primera petición CTG6800T ECI parameters on entry: Call_Type=1, Extend_Mode=1, Luw_Token=0 CTG6805T ECI parameters on exit: Call_Type=1, Extend_Mode=1, Luw_Token=16777216, Commarea_Length=53, Cics_Rc=0, AV=0

Segunda petición CTG6800T ECI parameters on entry: Call_Type=1, Extend_Mode=1, Luw_Token=16777216 CTG6805T ECI parameters on exit: Call_Type=1, Extend_Mode=1, Luw_Token=16777216, Commarea_Length=53, Cics_Rc=0, AV=0

Petición de commit CTG6800T ECI parameters on entry: Call_Type=1, Extend_Mode=2, Luw_Token=16777216 CTG6805T ECI parameters on exit: Call_Type=1, Extend_Mode=2, Luw_Token=0, Commarea_Length=0, Cics_Rc=0, AV=0

Observamos como el valor del token LUW en la entrada de la primera llamada vale 0, correspondiente a una nueva LUW, mientras que en la salida toma un valor de 16777216. Este valor será el que tengamos que almacenar e indicar en sucesivas peticiones que queramos que pertenezcan a la misma LUW. También podemos observar como el valor de Modo Extendido en las dos primeras llamadas vale 1 y en la tercera, donde hemos puesto el Modo Extendido a ECI_COMMIT, vale

- 75 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2. Estos valores corresponden a los valores de las constantes ECI_EXTENDED y ECI_COMMIT que hemos utilizado. Si estamos utilizando IPIC, para ver si se ha ejecutado la LUW podemos hacer uso de las estadísticas que muestra el CTG. Aunque más adelante veremos en más profundidad las estadísticas, ahora nos basta con fijarnos en las estadísticas GD_LLUWTXNC, GD_ILUWTXNC, GD_LLUWTXNR y GD_ILUWTXNR. Las dos primeras nos dicen las LUWs confirmadas desde que arranco el CTG y en el intervalo actual mientras que las dos últimas nos dicen las LUWs a las que se ha hecho rollback desde que arranco el CTG y en el periodo actual. Si comprobamos estas estadísticas antes y después de ejecutar una LUW veremos que estos valores cambian. En nuestro caso, a aumentado el valor en 1 de las estadísticas GD_LLUWTXNC y GD_ILUWTXNC. 2.4.5.- Conversión de datos Los mainframes utilizan un código de caracteres de 8 bits llamado EBCDIC mientras que un ordenador personal usa el código ASCII. Por ello tenemos que hacer una conversión de los datos que vamos a transmitir entre la aplicación cliente y el mainframe. Esto sólo hay que realizarlo si usamos programas basados en COMMAREA, no hace falta realizarlo si usamos Canales y Contenedores de tipo CHAR. Esta conversión la podemos hacer en el mainframe o en la aplicación cliente. 2.4.5.1.- Conversión en el mainframe Para que la conversión de los datos se realice en el mainframe, tendremos que hacer uso de la tabla de conversión de páginas de códigos llamada DFHCNV. Para cada programa en el CICS que queramos usar, tendremos que introducir en la DFHCNV ese programa para que los datos sean traducidos de EBCDIC a ASCII y viceversa. De esta forma en nuestro programa lo único que tendremos que hacer es coger el array de bytes que nos devuelva el CTG simulando la COMMAREA y convertirlo en una cadena de texto para poder manejarlos o convertir los datos de entrada en un array de bytes para mandárselo al CTG, sin cambiar la página de códigos. En la Figura 2.28 podemos ver una muestra de la tabla DFHCNV donde convierte los datos de los programas EC01 y EC02, programas de ejemplo, de la página de códigos IBM037, página de códigos en inglés del mainframe, a la página de códigos 8859-1 o ISO Latin-1.

Figura 2.28 Muestra de la tabla DFHCNV

- 76 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

2.4.5.2.- Conversión en la aplicación cliente La otra opción que tenemos para convertir los datos que vamos a manejar es hacerlo desde la aplicación cliente. Para esto, en cada uno de las aplicaciones cliente que vayan a acceder al CTG tendremos que añadir líneas extra de programación para convertir los datos que intercambiemos con el CTG. En el Documento 2.6 podemos ver como hacer esto desde Java mientras que cuando expliquemos como desarrollar aplicaciones en .Net lo explicaremos para este lenguaje. byte[] COMMAREA = entrada.getBytes(String codificación); String resultado = new String(byte[] COMMAREA, String codificación); Documento 2.6 Conversión de datos a intercambiar con el mainframe

La primera instrucción convierte la cadena de texto entrada, donde tenemos los datos que queremos pasar al programa CICS que queremos ejecutar, a un array de bytes que pasaremos al CTG simulando la COMMAREA. Este array de bytes se codifica con la página de códigos que le indiquemos que para que sea la IBM037, utilizada por el CTG y el CICS, le pasaremos la cadena de texto 037 o IBM037. La segunda instrucción hace el proceso contrario. Coge el array de bytes que le devuelve el programa CICS y lo convierte a una cadena de texto haciendo uso de la página de códigos que le indiquemos en el segundo argumento para decodificar el array de bytes. Para obtener los datos correctos le indicaremos que la página de códigos es la IBM037. Algunos tipos de datos no se convierten correctamente haciendo uso del segundo método. Esto ocurre por ejemplo con los tipos de datos CVDA. Este tipo de datos son constantes numéricas definidas en el mainframe que se corresponden con valores entendibles por el usuario. Por ejemplo, los valores 147, 148 y 149 indican lenguajes de programación compatibles con el CICS como Java, C++ o C respectivamente. Este tipo de datos se utiliza en algunos comandos o para almacenar cierta información. Si utilizamos programas que devuelvan datos de este tipo tendremos que usar el primer método de conversión o convertir estos datos en el programa CICS a caracteres antes de devolverlos o no recibiremos los datos correctos. 2.4.2.- Aplicaciones .Net Otro de los lenguajes de programación desde los que podemos hacer peticiones al CTG es desde .Net, ya sea VisualBasic.Net o C#.Net. Aunque ambos lenguajes de programación son diferentes, los dos usan la misma API para establecer conexión con el CTG y realizar peticiones. A la hora de hacer peticiones desde aplicaciones .Net principalmente usaremos las clases GatewayConnection y EciRequest similares a las clases JavaGateway y ECIRequest de Java. Para poder hacer uso de estas clases deberemos importar en nuestro proyecto la librería IBM.CTG.Client.dll y que la librería ctgclient.dll se encuentre en el Path del sistema. La primera se encuentra dentro del SupportPac ca 73 que podemos descargar desde la página oficial de IBM mientras que la segunda se puede solicitar a IBM al adquirir la licencia de CTG. Para importar la librería a nuestro proyecto en el Visual Studio 2005 que vamos a utilizar para desarrollar aplicaciones .Net seguiremos los siguientes pasos: 1. Una vez creado el proyecto, en el “Explorador de soluciones” hacemos clic derecho sobre el nombre del proyecto y seleccionamos “Agregar referencia…” como podemos ver en la Figura 2.29.

- 77 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Figura 2.29 Agregar referencia

2. Nos aparecerá la ventana que podemos ver en la imagen 2.30 donde seleccionamos la pestaña “Examinar” y ahí buscamos donde tenemos la librería IBM.CTG.Client.dll, la seleccionamos y pulsamos aceptar.

Figura 2.30 Ventana de selección de la dll

Una vez hecho esto ya podemos hacer uso de las clases que contiene. Los pasos que seguiremos para realizar peticiones al CTG serán los mismos que seguimos en las aplicaciones Java. En el Documento 2.7 podemos ver un ejemplo de una aplicación escrita en VisualBasic.Net para realizar peticiones al programa EJEMPLO1 que hemos visto anteriormente. En este caso, los comentarios van precedidos de '.

- 78 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

'Importamos el paquete que contiene las clases GatewayConnection y EciRequest Imports IBM.CTG Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click 'Definimos las variables que vamos a necesitar Dim jg As GatewayConnection Dim er As EciRequest Dim URL As String Dim puerto As Integer Dim servidor As String Dim programa As String Dim longitudCommarea As Integer Dim transid As String 'Inicializamos las variables URL = "20.20.20.1" puerto = 2006 servidor = "CICS1" programa = "EJEMPLO1" transid = "F000" Dim dni As String dni = "000000001" longitudCommarea = 281 'Creamos la conexion con el CTG Try jg = New GatewayConnection(URL, puerto) Catch ex As Exception 'Error al crear la conexión Dim st1 As String = "Error al crear la conexión con el CTG" + vbCrLf + ex.Message MessageBox.Show(st1) End End Try 'Creamos la Peticion er = New EciRequest() er.ServerName = servidor er.UserId = usuario er.Program = programa er.ExtendMode = EciExtendMode.EciNoExtend Try 'Pasamos los datos de entrada a la COMMAREA convirtiéndolos a la página de 'códigos 037 er.SetCommareaData(System.Text.Encoding.GetEncoding("037").GetByt es(dni) Catch ex As Exception Dim st1 As String = "Error al codificar los datos de entrada" + vbCrLf + ex.Message MessageBox.Show(st1) End End Try er.TransId = transid 'Lanzamos la petición Dim iRc As Integer = 0

- 79 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Try iRc = jg.Flow(er) Catch ex As Exception Dim st1 As String = "Error al lanzar la petición" + vbCrLf + ex.Message MessageBox.Show(st1) End End Try 'Comprobamos si se han producido errores Dim st As String Dim err As Integer = 0 Select Case er.ReturnCode Case EciReturnCode.EciNoError If iRc.Equals(0) Then 'Ejecución correcta de la petición Else 'Error en la conexión al lanzar el programa MessageBox.Show("Error en la Gateway" + er.ReturnCodeString) err = 1 End If Case EciReturnCode.EciErrSecurityError 'Error de seguridad MessageBox.Show("Error de seguridad") err = 1 Case EciReturnCode.EciErrTransactionAbendç 'Error de ABEND st = "The transaction abended: " + er.AbendCode MessageBox.Show(st) err = 1 Case EciReturnCode.EciErrNoCics 'Error al no encontrar el servidor CICS especificado MessageBox.Show("No se encuentra el CICS indicado") err = 1 Case Else 'Otro tipo de error Dim st1 As String = ("ECI return code: " + er.EciReturnCode.ToString() + " (" + CType(er.EciReturnCode, Integer) + ")") MessageBox.Show(st1) err = 1 End Select 'Cerramos la conexión si sigue abierta If (jg.IsOpen) Then jg.Close() End If 'Recogemos los datos y se los mostramos al usuario Dim resultado As String resultado = System.Text.Encoding.GetEncoding("ASCII").GetString(er.GetCommarea()) MessageBox.show(resultado) End Sub End Class Documento 2.7 Ejemplo de petición VB.Net a programa de COMMAREA

- 80 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Vemos como la estructura del programa es similar a la del programa Java excepto que para dar a cada atributo de la clase EciRequest su valor adecuado, en vez de hacerlo por medio de un constructor lo hacemos individualmente. En este caso no podemos indicarle tipo de llamada. Todas son síncronas. Para controlar la transacción que se ejecuta y el alias hacemos uso de los atributos EciRequest.TransId y EciRequest.MirrorTransId. Con el primero ejecutamos la transacción por defecto con el alias especificado en el atributo mientras que con el segundo ejecutamos directamente la transacción especificada en el atributo. Vemos como la forma de convertir los datos también ha cambiado. Si queremos convertir los datos en la aplicación hacemos uso de las instrucciones que podemos ver en el Documento 2.8. er.SetCommareaData(System.Text.Encoding.GetEncoding("037").GetBytes(dni) System.Text.Encoding.GetEncoding("037").GetString(er.GetCommarea()) Documento 2.8 Conversión de datos a intercambiar

Con la primera instrucción convertimos los datos de la cadena dni a la página de códigos IBM037 y lo pasamos a un array de bytes. Con la segunda instrucción hacemos el proceso contrario.

2.5.- Prueba con Canales y Contenedores A la hora de hacer peticiones a programas CICS podemos utilizar programas que funcionen por medio de COMMAREA o por medio de Canales y Contenedores para intercambiar datos. Este segundo método presenta varias ventajas con respecto al uso de la COMMAREA siendo las que más nos afectan a nosotros las siguientes:   

Intercambio de cantidades de datos superiores a los 32KB limitados por la COMMAREA Posibilidad de estructurar los datos Envío de datos únicamente modificados o nuevos, no de todos los datos de un Canal

Para poder utilizar programas CICS que funcionen con Canales y Contenedores tenemos que hacer uso de la nueva conexión IPIC aparecida en la versión 3.1 del CICS. Si tenemos el CTG v7.2 estamos limitados a usar aplicaciones de cliente escritas en Java para hacer uso de este tipo de programas. Si usamos el CTG v8.0 también podemos hacer peticiones a programas CICS que usen Canales y Contenedores desde aplicaciones escritas en .Net. En el Documento 2.8 podemos ver un ejemplo de programa escrito en Java que hace una petición al programa ECICHAN y un método para pasar datos de bytes a entero. El programa ECICHAN es un ejemplo para probar programas CICS que usa Canales y Contenedores. Simplemente recibe unos datos de entrada y devuelve los mismos datos junto con su longitud, la hora actual del CICS y algún dato más. Los Contenedores pueden ser de tipo CHAR, o texto normal, o de tipo BIT, que sirven para enviar texto pero también números, etc. Veremos la forma tanto de crear como de recibir ambos tipos de Contenedores. try {

- 81 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

//Definimos las variables que vamos a necesitar String URL; int puerto; String servidor; String programa; String nombreCanal; String nombreContenedorEntrada; String nombreContenedorError; String datos; //Las inicializamos con los valores adecuados //Normalmente el nombre que le demos al Canal no importa ya que los //programas CICS trabajan con el Canal que les llega sin comprobar //su nombre //El nombre del Contenedor SI es importante URL = "20.20.20.1"; puerto = 2006; servidor = "CICS1"; programa = "ECICHAN"; nombreCanal = "CTGCHANNEL"; nombreContenedorEntrada = "INPUTDATA"; nombreContenedorError = "ERRORDARA"; datos = "Hola CICS"; //Abrimos la conexión con el CTG JavaGateway javaGateObject = new JavaGateway(URL, puerto); //Creamos el Canal Channel theChannel = new Channel(nombreCanal); //Creamos un contenedor con el nombre que espera que tenga el programa //CICS. Este nombre lo tenemos que saber de antemano. //De esta forma creamos un Contenedor de tipo CHAR theChannel.createContainer(nombreContenedorEntrada, datos); //De esta forma crearíamos un Contenedor de tipo BIT en caso necesario //theChannel.createContainer(nombreContenedorEntrada, datos.getBytes("IBM-037"));

//Creamos la petición que vamos a enviar ECIRequest er = new ECIRequest( ECIRequest.ECI_SYNC, servidor, null, null, programa, null, theChannel, ECIRequest.ECI_NO_EXTEND, 0); //Lanzamos la petición por la Conexión javaGateObject.flow(er);

if (er.getRc() == 0) { //Comprobamos que no se han producido errores try { //Comprobamos si hay un contenedor llamado ERRORCONT ya que //sabemos que el programa deja los errores que se han producido //en este Contenedor

- 82 -

Mikel Castillejo Erviti

Universidad Pública de Navarra

Container errorcont = theChannel.getContainer(nombreContenedorError); } catch (ContainerNotFoundException e) { //Si se produce una excepción porque no se encuentra el //Contenedor ERRORCONT suponemos que no se han producido errores } catch (Exception e) { //Capturamos cualquier otra excepción que se pueda producir //al recuperar el Contenedor de errores } //Como no sabemos los nombre de los Contenedores donde el //programa CICS nos va a devolver los datos, recorremos todos //los Contenedores que hay en el Canal tratando sus datos Iterator it = theChannel.getContainers().iterator(); while (it.hasNext()) { //Recogemos el siguiente Contenedor del Canal Container cont = it.next(); //Como no sabemos el tipo de Contenedor, comprobamos de que //tipo es y lo tratamos como corresponda según su tipo switch (cont.getType()) { //Contenedor de tipo CHAR (cadena de texto) case CHAR: //Recuperamos los datos del Contenedor //No hay que hacer ninguna transformación String dataStr = cont.getCHARData(); //Mostramos los datos junto al nombre del //Contenedor System.out.print("\t[CHAR]-" +cont.getCCSID() + "\t" + cont.getName() + "(" + dataStr.length() + " bytes)" + " = "); System.out.println(dataStr); break; //Contenedor de tipo BIT case BIT: //Recuperamos los datos del Contenedor a un //array de bytes byte[] data = cont.getBITData(); //Mostramos el nomrbre del Contenedor y //su longitud System.out.print("\t [BIT] " + "\t\t" + cont.getName() + "(" + data.length + " bytes)" + " = " ); //Pasamos el array de bytes a texto //convirtiéndolo con la página de códigos 037 String str2 = new String(data, "IBM037"); System.out.print("String: " + str2 + " "); //Lo pasamos a entero con el método que hay

- 83 -

Mikel Castillejo Erviti

Universidad Pública de Navarra //más abajo int sum = bytesToInt(data, data.length); System.out.print("Decimal:"); System.out.print(((Integer) sum).toString() + " "); //Lo pasamos a hexadecimal System.out.print(" X'"); for (int i = 0; i < data.length; i++) { String hex = "0" + Integer.toHexString(data[i]); System.out.print(hex.substring(

hex.length()-2)); } System.out.println("'"); } } } else { //Se ha producido un error //Comprobamos los diferentes tipos de errores, de seguridad, ABEND, //etc. como hacíamos en las peticiones de COMMAREA } }catch (IOException ioe) { //Error al crear la conexión con el CTG System.out.println("No se puede conectar con el CTG:"+ ioe.toString()); }catch (Exception e) { //Otro tipo de errores System.out.println("Excepcion ocurrida: " + e.toString()); } //Cerramos la conexión si sigue abierta if (javaGateObject.isOpen() == true) { try { javaGateObject.close(); } catch (Throwable t2) { ; } } //Método para pasar los datos de hexadecimal a entero public static int bytesToInt(byte[] bytesToConvert, int length) { int result = 0; for (int i = 0; i < length; i++) { result |= ((int) bytesToConvert[i] & 0x000000ff)
View more...

Comments

Copyright � 2017 SILO Inc.