El presente documento explica como habilitar una característica en las comunicaciones para que nuestro tráfico SNA nativo pueda ser llevado por redes TCP/IP.
Tradicionalmente, todas las comunicaciones desde el Host a dispositivos tanto remotos como locales se hacían mediante SNA (Systems Network Architecture), creando una compleja red de Nodos, PUs, LUs, DLUR/DLUS, etc, que gestionaba el VTAM. Los dispositivos externos o controladoras de comunicaciones (3725, 3745, 3746, etc) mediante un sistema llamado NCP (Network Control Program) controlaban y enrutaban las comunicaciones de SNA entre VTAM y el resto de dispositivos mediante el uso de Nodos y líneas punto a punto dedicadas (Frame Relay, X25, etc), pero la gran expansión de Internet y el abaratamiento de las comunicaciones, ha hecho que estos sistemas sean inmanejables y tremendamente costosos de mantener. Además de esto, todos aquellos programas que dependen de SNA para sus comunicaciones (CICS, por ejemplo) y todos los APIs y millones de líneas de código que se han escrito para utilizar SNA como protocolo de comunicaciones, se quieren seguir utilizando, por lo que quitar el SNA sin más y migrarlo a TCP/IP no es una opción abordable.
Por lo tanto, la mejor forma de conseguir mantener el SNA pero olvidarte de costosas líneas de punto a punto o procesadores de comunicaciones costosos, es trabajar con las comunicaciones TCP/IP, o lo que es lo mismo, crear un TUNEL punto a punto que sea TCP/IP pero que en cuyo interior, viajen paquetes con el protocolo SNA. Sencillo, verdad? Pues esto se configura con una aplicación que viene de serie en z/OS desde la versión 1.4 llamada Enterprise Extender.
1.1 Como funciona el Enterprise Extender
El Enterprise Extender esta basado en el funcionamiento de un túnel IP por el que transcurre todo el tráfico SNA, por lo que tenemos, por un lado, el VTAM, que gestiona las comunicaciones SNA, y por otro tenemos el TCP/IP, que nos permite acceder a terminales vía IP a otros sistemas.
Para que VTAM y TCP/IP puedan verse entre sí, se crea un dispositivo virtual (por lo que necesitaremos tener una VIPA o Virtual IP Address) llamado IUTSAMEH, dentro de la definición del TCP/IP del z/OS. Este dispositivo virtual IUTSAMEH, mediante un nodo XCA que definiremos bajo el VTAM, hará las veces de “puente” entre TCP/IP y VTAM. Esta estructura se asemejaría, en GNU/Linux, a algo similar al dispositivo tun/tap, que permite crear puentes virtuales de red.
Una vez creado ese puente, en VTAM se crearían los MAJOR NODES y las DLUs de los dispositivos SNA que van a ir encapsulados bajo TCP/IP, y esto no tiene ningún misterio porque es como se viene haciendo siempre (es decir, si querías conectarte de forma remota a un host vía SNA, tu terminal SNA debía estar definida como una LU dentro de una PU definida en una DLUR, que a su vez dependía de un Major Node o controlador de comunicaciones en el que se definen líneas, grupos y protocolos dentro de VTAM. Aquí es lo mismo, pero cambiando el tipo de Major Node para que en vez de usar una línea SNA, use en Enterprise Extender).
Lógicamente, el otro lado -es decir, el cliente-, debe saber que el trafico SNA viene encapsulado en una línea TCP/IP, y aquí es donde entran soluciones de software como el Microsoft HIS o Host Integration Server (o lo que antiguamente se llamaba Microsoft SNA Server), u otros sistemas servidores con los que se necesita tener comunicación SNA, como por ejemplo otro z/OS o un AS/400.
1.2 Entorno a instalar
Esta “receta” va a utilizar una instalación real de un sistema z/OS (emulado bajo Hercules, aunque las configuraciones se pueden aplicar a un Sistema Real), y lo conectará a un IBM iSeries, o AS/400, con el Sistema Operativo OS/400 versión V6R1M0 (aunque desde la versión V5R4M0 ya soporta conexión Enterprise Extender de forma nativa).
La idea es que queremos que el AS/400 haga de pasarela entre los terminales VTAM del z/OS, de forma que cuando la gente se conecte al AS/400, pueda abrir una emulación 3270 SNA pura contra el mainframe. Si, es cierto que conectándote directamente al TCP/IP del z/OS puedes hacer lo mismo, pero la idea es que así demostramos como un sistema comunicado por SNA con su propio controlador como es el AS/400, puede utilizar un túnel TCP/IP, y además, por ejemplo, este acercamiento es bastante utilizado en muchas empresas cuando el AS/400 tiene más servicios instalados que interactúan con el mainframe (Servidor de Impresión, Front-End de Servidor de Aplicaciones, etc).
1.3 Preparación Hercules
Este paso puede saltarse si el mainframe es real, ya que este punto explicará cómo se configura Hercules para que funcionen bien las VIPAs y la salida de red.
Ante todo, el pre-requisito es que tengamos el Hercules funcionando perfectamente con el z/OS a nivel de TCP/IP, es decir, disponer de un enlace LCS configurado en el hercules.cnf y que la pila TCPIP del z/OS utilice ese enlace para salir al exterior.
Ejemplo de Hercules.cnf:
D000.2 LCS -n 192.168.1.70 192.168.1.246
Por ejemplo, supongamos que nuestro enlace LCS está en la dirección D000 y D001 y que la IP que tiene el PC donde funciona Hercules es la 192.168.1.70, y que la IP que utiliza el z/OS para comunicarse y comunicarnos con él es la 192.168.1.246.
Para crear una VIPA o Virtual IP Address dentro del z/OS, paradójicamente se deben añadir dos direcciones adicionales a nuestro enlace LCS de Hercules, ya que Hercules debe crear otro túnel tun/tap para que dicha IP virtual pueda salir. No me digáis muy bien por qué, pero si no se hace así, el sistema no funciona.
El caso es que cuando ya son más de una IP las que entran en juego -porque la VIPA tendrá la suya-, lo ideal es contar con una tabla OAT u OSA Address Table, con la siguiente configuración:
D000.4 LCS -n 192.168.1.70 --oat oat.txt
Añadimos 2 direcciones mas a nuestro LCS, de forma que ahora tenga las direcciones D000, D001, D002 y D003, y cambiamos la IP final que tendrá z/OS para que con el parámetro –oat nos apunte a un fichero llamado OAT.TXT. Recordar que las direcciones de LCS se enumeran de dos en dos, ya que siempre son dispositivos pares -uno para envío y otro para recepción-.
El contenido del fichero OAT sería el siguiente:
*********************************************************
* Dev Mode Port Entry specific information... *
*********************************************************
D000 IP 00 PRI 192.168.001.246
D002 IP 01 SEC 192.168.001.247
Es decir, que las direcciones D000 y D001 cojan la IP real del z/OS (es decir, la 192.168.1.246) y que de las direcciones D002 y D003 cojan como secundaria la IP 192.168.1.247, que será la IP que configuraremos como VIPA mas adelante.
Con esto, hemos terminado de configurar la parte de Hercules. El siguiente punto explicaré como configurar el z/OS y su pila TCPIP.
1.4 Configuración TCP/IP z/OS
Para configurar el túnel del Enterprise Extender, he comentado más arriba que es importante crear un dispositivo llamado IUTSAMEH que se sostiene en base a una VIPA. Si nuestra pila TCP/IP carece de VIPAs, habrá que cambiarla para que las soporte, así que eso se arregla fácilmente editando el miembro o dataset PROFILE de la pila TCP/IP. Para hacer eso, seguiremos los siguientes pasos:
1.4.1 Localizar el miembro PROFILE
Para ello, basta con ver el interior de nuestra Strarted Task del TCPIP y ver a que miembro llama en su configuración. Esto se ve desde el SDSF, entrando a ver el log del TCPIP, o bien entrando en el miembro de la PROCLIB que llama al TCPIP:
Fig. 1: Interior del TCPIP bajo SDSF
Fig. 2: Dataset donde está nuestro PROFILE
1.4.2 Añadir IUTSAMEH y VIPA en el PROFILE del TCPIP
Con en miembro PROFILE del TCPIP localizado, procederemos a modificarlo para, si no lo tiene ya, dotar de VIPA a nuestra pila TCP/IP -añadiendo SOURCEVIPA-, y añadir además el dispositivo IUTSAMEH que luego enlace con el VTAM. El listado de a continuación es un ejemplo, y en negrita está puesto lo que habría que añadir:
; TCPIP.PROFILE.TCPIP
; ===================
;
; COPYRIGHT = NONE.
;
; NOTES:
;
; The device configuration statements MUST be changed to match your
; hardware and software configuration.
;
; The BEGINVTAM section must be changed to match your VTAM
; configuration.
;
;
; For more information about this file, see "Configuring the TCPIP
; Address Space" and "Configuring the Telnet Server" in the
; IP Configuration manual.
;
ARPAGE 5
IPCONFIG SOURCEVIPA
NODATAGRAMFWD
IGNOREREDIRECT
TCPCONFIG
RESTRICTLOWPORTS
UDPCONFIG
RESTRICTLOWPORTS
DATASETPREFIX TCPIP
DEVICE OSAGE000 MPCIPA
LINK OSAGBE1 IPAQENET OSAGE000
DEVICE LCS1 LCS D000 AUTORESTART
LINK ETH1 ETHERNET 0 LCS1
;*******************************
; Enterprise Extender VIPA
;*******************************
DEVICE VIPA01 VIRTUAL 0
LINK LVIPA1 VIRTUAL 0 VIPA01
;*******************************
; VTAM to TCPIP Stack
;*******************************
DEVICE IUTSAMEH MPCPTP
LINK EELINK MPCPTP IUTSAMEH
HOME
; 192.168.252.167 OSDL
192.168.1.246 ETH1
192.168.1.247 LVIPA1
192.168.1.248 EELINK
192.168.1.244 OSAGBE1
;
; 9.67.43.110 FDDI1
; 193.7.2.1 SNA1
BEGINRoutes
ROUTE 192.168.1.0/24 = ETH1 MTU 1500
ROUTE 192.168.1.0/24 = OSAGBE1 MTU 1500
ENDRoutes
START LCS1
START IUTSAMEH
START OSAGE000
Como se ha podido comprobar, se han creado dos interfaces: LVIPA1 y EELINK. EELINK es el dispositivo IUTSAMEH, mientras que el LVIPA1 es una VIPA creada para que, usando la pila TCPIP, salga hacia fuera del z/OS, por lo que su IP debe coincidir con la configurada en el Hercules.CNF, dentro del fichero OAT.TXT (en nuestro ejemplo, 192.168.1.247). La IP del EELINK se usará de forma interna, por lo que no saldrá hacia fuera -ni tiene la necesidad de hacerlo- ya que esta IP se usará internamente por el sistema. Con esto, y reiniciando el TCPIP, lógicamente, ya tenemos uno de los lados del túnel preparado para transportar SNA sobre IP.
1.5 Configuración VTAM
Esta es quizás la parte más compleja del sistema, ya que no solo hay que crear el otro lado del túnel, sino que hay que configurar nodos, líneas y demás, así que vamos a ir por partes. Lo primero de todo es saber donde están los miembros de configuración del VTAM, así que, siguiendo la lógica del punto 1.4.1, podemos adivinar que la configuración de la que se nutre en nuestro ejemplo es desde el dataset ADCD.Z110.VTAMLST.
1.5.1 Modificación ATCSTR00
Este miembro es el primero que lee el VTAM para cargar toda la configuración, de modo que para habilitar el Enterprise Extender, es necesario modificarlo, añadiendo algunas configuraciones y modificando alguna existente, como tamaños de buffer y esas cosas. A continuación, pego mi ATCSTR00 de ejemplo, y pondré en negrita lo que añadí y/o modifiqué:
CONFIG=00,SUPP=NOSUP, X
SSCPID=06,NOPROMPT, X
HOSTSA=6,MAXSUBA=31, X
SSCPNAME=PROD,HOSTPU=WYC$PU, X
NETID=WEYLAND, X
NODETYPE=NN, X
TCPNAME=TCPIP, X
IPADDR=192.168.1.247, X
CPCP=YES, X
HPR=RTP, X
DYNADJCP=YES, X
DYNLU=YES, X
CRA4BUF=(4000,,0,,10,20), X
CRA8BUF=(396,,0,,6,2), X
CRPLBUF=(1300,,0,,60,29), X
IOBUF=(2000,447,19,,8,48), X
LFBUF=(8160,,0,,1,1), X
LPBUF=(54,,0,,6,2), X
SFBUF=(192,,0,,1,1), X
SPBUF=(84,,0,,1,1), X
TIBUF=(2000,,0,,60,120), X
XDBUF=(60,,0,,1,4), X
PPOLOG=YES
*/*
*/* LIB: SYS1.VTAMLST(ATCSTR00)
*/* GDE: CBIPO COMMUNICATIONS
*/* DOC: THIS MEMBER CONTAINS THE ACF/VTAM DEFAULT
*/* START OPTIONS ON THE MODEL INSTALLATION SYSTEM.
*/*
Los valores más representativos son los que emparejan el túnel VTAM con el TCP/IP, a saber, TCPNAME para poner el nombre de la pila a la que hará uso, y IPADDR para decirle al VTAM que IP usará por defecto (que, como habréis podido observar, es la misma que la VIPA).
Importante también la opción HPR=RTP, esto es el protocolo High Performance Routing de SNA para encapsular las tramas SNA sobre IP.
NOTA: Especial atención a las X del final, que indican continuación de línea. De ponerlas mal o no ponerlas (deben coincidir en la columna 80), podría hacer que el VTAM no arrancara por fallo de sintaxis, por lo que antes de modificar el miembro original, haced una copia por si acaso.
1.5.2 Modificación IBMTGPS
Este miembro debe ser modificado para utilizar definiciones de la capa de transporte (Ethernet, fibra, etc) para que soporten Enterprise extender, ya que posteriormente, estas definición serán utilizadas en los nodos y líneas.
Si este fichero NO está en vuestra VTAMLST, se debería incluir, así como las nuevas definiciones. Para ello, en la SYS1.SAMPLIB disponemos del miembro IBMTGPS que podemos copiar libremente a nuestra VTAMLST y modificarlo.
Así pues, hay que añadir 2 tipos adicionales:
**********************************************************************
* Enterprise Extender, i/Series *
**********************************************************************
TGPAS400 TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
PDELAY=TERRESTR,CAPACITY=100M, *
UPARM1=128,UPARM2=128,UPARM3=128
**********************************************************************
* Enterprise Extender, Fast Ethernet *
**********************************************************************
FASTENET TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
PDELAY=NEGLIGIB,CAPACITY=100M, *
UPARM1=128,UPARM2=128,UPARM3=128
Estos tipos están pensados para que el primero se conecte a un IBM AS/400 y el siguiente, a cualquier red Ethernet.
NOTA: Al igual que en el punto anterior, los * del final denotan continuación, por lo que deben ponerse en la línea 80, de lo contrario, no funcionará bien el sistema.
1.5.3 Modificación ATCCON00
Este miembro se utiliza para cargar los Nodos, Líneas, DLURs, DLUs, etc, así como definiciones del VTAM. Si no disponemos del miembro IBMTGPS, deberíamos añadirlo al miembro ATCCON00:
A0600,NSNAFXX,NSNA70X,NSNA90X,DYNMODEL,XCAE40R,XCAE40E,COSAPPN, *
A0TCP,DB8GLU,OSATRL1,IMS10APL,DB9GLU,OSAGE000,OSAGF000,IBMTGPS
Con estos valores, y reiniciando el VTAM, el otro lado del túnel queda también configurado.
1.5.4 Creación Nodo XCA (External Communication Adapter)
Con el VTAM arrancado, preparado para la infraestructura Enterprise Extender, necesitamos definir una serie de nodos para poder transmitir y recibir los datos, y preparar la red de terminales o impresoras o dispositivos como NJE a los que luego se conectaran los clientes. Entre ellos, el más importante es el nodo XCA o Adaptador de Comunicaciones Externo. En cualquier instalación, debe haber por lo menos uno definido, ya que es el nodo que VTAM utilizará para derivar las comunicaciones a nuestra tarjeta de red, o lo que es lo mismo, le dice al VTAM como y por donde enrutar el tráfico del que dependerán los nodos que bajo él se configuren.
Por tanto, como queremos utilizar el Enterprise Extender para encapsular trafico SNA en IP, debemos crear un nodo XCA que el VTAM utilizará para este propósito, que llamaremos XCAEE y lo guardaremos con el mismo nombre en la VTAMLST:
XCAEE VBUILD TYPE=XCA
PORTXCAE PORT MEDIUM=HPRIP, *
IPTOS=(20,40,80,C0,C0), *
SRQTIME=15, *
SRQRETRY=3
GRXCAEE GROUP AUTOGEN=(16,LINV,P),DIAL=YES,CALL=INOUT, *
KEEPACT=YES,DYNPU=YES
Como podéis observar, el nodo es del tipo XCA, un puerto que hará uso del HPR/IP (enrutado de tráfico SNA vía IP) y luego un grupo de líneas, que se autogenerarán dinámicamente, serán 16 y empezarán por LINV0001 hasta la LINV000F, podrá generar PUs dinámicas al conectarse, etc. Con esto, VTAM ya sabe en qué forma dirigir el tráfico cuando vaya a ser HPRIP, aunque si tenemos más de 16 nodos dependientes, las 16 líneas punto a punto configuradas no serán suficientes, por lo que o bien aumentamos el número de líneas a auto-generar, o bien creamos otro nodo XCA. Y no me quiero repetir, pero ojo con los asteriscos del final. En nuestro ejemplo, solo configuraremos 1 nodo, así que en principio nos sobrarían 15 líneas, pero no pasa nada.
1.5.5 Creación Nodo HPR (High Performance Routing)
Hemos definido en el punto 1.5.4 el nodo XCA. El nodo HPR se debe crear con CADA dispositivo que queremos conectar -y que queramos que use el Enterprise Extender-. Si tuviéramos 2 AS/400 cada uno con IPs distintas, deberíamos definir otro nodo HPR para dicho AS/400, y así sucesivamente. En nuestro ejemplo, como solo conectaremos 1 AS/400, solo definimos el nodo HPR que se conectará a él (y viceversa).
HPREE01 VBUILD TYPE=SWNET
PUHPR01 PU CPNAME=I810, *
NETID=WEYLAND, *
TGN=6, *
CPCP=YES, *
HPR=YES, *
DISCNT=NO, *
DWACT=NO, *
DWINOP=NO, *
TGP=TGPAS400
PATH01 PATH IPADDR=192.168.1.33, *
SAPADDR=4, *
GRPNM=GRXCAEE
Lo que he puesto en negrita es lo más importante: Por una parte, debemos configurar la PU (Physical Unit) que conectará al cliente externo, en este caso, el AS/400, debemos conocer el nombre del Servidor (CPNAME) y el Identificador de Red (NETID) de la máquina destino. En nuestro ejemplo, tanto el AS/400 como el z/OS comparten ID de Red, así que será WEYLAND. El CPNANE del AS/400 es I810. Estos dos datos los obtenemos del propio AS/400, con el mandato DSPNETA, explicado con detalle posteriormente en el punto 1.7.1. También le diremos que use la configuración de comunicaciones TGPAS400 (recordáis el miembro IBMTGPS??). Con esto, la PU queda configurada.
Pero necesitamos un camino para salir del VTAM del z/OS para usar la tarjeta de red de salida (recordemos el nodo XCA antes mencionado), así que introduciremos la IP del AS/400 (192.168.1.33) y el nombre del GRUPO de líneas por el que queremos que salga. Como en el nodo XCA se autogeneran y son dinámicas, cuando levantemos el nodo, el camino o path se asignará a la línea que le dé la gana de forma automática y podremos escuchar la VIPA en busca de peticiones del AS/400.
1.5.6 Creación DLUR (Dependent LU Requester)
Por último, debemos crear una DLUR, o “pool de LUs”, donde los terminales del AS/400 se conecten a nuestro VTAM, porque, sin un terminal, VTAM no puede mostrarte la pantalla de acceso al sistema. La DLUR se configura como cualquier otra, y claramente, se diferencian por el nombre, por lo que si deseas conectarte a una DLUR existente -que tradicionalmente se utilizaba ya en la instalación cuando las comunicaciones eran SNA puras- con poner en el AS/400 el mismo nombre de controlador, sería suficiente.
Pero para ilustrarlo mejor, pondré un ejemplo de DLUR que más tarde configuraremos en el AS/400 para que luego la use:
DLUEE01 VBUILD TYPE=SWNET
CTLEE01 PU PUTYPE=2, *
ANS=CONT, *
IDBLK=056, *
IDNUM=33333, *
MODETAB=LOGMODES, *
DLOGMOD=DYNAMIC
CV01 LU LOCADDR=1,USSTAB=USSS
CV02 LU LOCADDR=2,USSTAB=USSS
CV03 LU LOCADDR=3,USSTAB=USSS
CV04 LU LOCADDR=4,USSTAB=USSS
Lo que he puesto en negrita lo usaremos luego en la definición del controlador PU en el AS/400, viene a ser la “matricula” del controlador para que sea único -además de tener el nombre CTLEE01-. Debajo, hay varias LU (Logical Unit), que en este caso, son 4 terminales 3270, que van del CV01 al CV04. Importante señalar el MODETAB, LOGMODE y la USSTAB que queremos que nuestro terminal tenga, en mi ejemplo son esas las relativas a la definición de terminales, pero cada instalación es un mundo.
Con todo esto, tenemos todo preparado desde la parte z/OS para conectarnos.
1.6 Activación de Nodos Enterprise Extender
Ahora, ha llegado el momento de activar los nodos que acabamos de editar, para que VTAM tenga consciencia de ellos. Para ello, basta con activar en este orden los nodos, mediante los siguientes comandos de z/OS, desde la consola maestra:
1.- Primero: El nodo XCA:
V NET,ACT,ID=XCAEE
La salida de la consola, debería ser la siguiente:
00- 02.32.56 v net,act,id=xcaee
02.32.56 STC01954 IST097I VARY ACCEPTED
02.32.56 STC01954 IST093I XCAEE ACTIVE
- 02.32.56 STC01972 EZZ4324I CONNECTION TO 192.168.1.247 ACTIVE FOR DEVICE
- IUTSAMEH
02.32.56 STC01954 IST1685I TCP/IP JOB NAME = TCPIP
02.32.56 STC01954 IST1680I LOCAL IP ADDRESS 192.168.1.247
Como habréis podido observar, en el momento que se levanta el nodo XCA, se levanta la VIPA IUTSAMEH y se pone a escuchar a la IP 192.168.1.247
Si hacemos un D NET,ID=XCAEE,SCOPE=ALL, debería salirnos una lista de las 16 líneas que hemos configurado:
D NET,ID=XCAEE,SCOPE=ALL
IST097I DISPLAY ACCEPTED
IST075I NAME = XCAEE, TYPE = XCA MAJOR NODE 232
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1679I MEDIUM = HPRIP
IST1685I TCP/IP JOB NAME = TCPIP
IST924I -------------------------------------------------------------
IST089I GRXCAEE TYPE = LINE GROUP , ACTIV
IST1680I LOCAL IP ADDRESS 192.168.1.247
IST924I -------------------------------------------------------------
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST170I LINES:
IST1901I LINES UNDER GROUP: GRXCAEE
IST232I LINV000 ACTIV
IST232I LINV001 ACTIV
IST232I LINV002 ACTIV
IST232I LINV003 ACTIV
IST232I LINV004 ACTIV
IST232I LINV005 ACTIV
IST232I LINV006 ACTIV
IST232I LINV007 ACTIV
IST232I LINV008 ACTIV
IST232I LINV009 ACTIV
IST232I LINV00A ACTIV
IST232I LINV00B ACTIV
IST232I LINV00C ACTIV
IST232I LINV00D ACTIV
IST232I LINV00E ACTIV
IST232I LINV00F ACTIV
IST314I END
2.- Segundo: El nodo HPR.
V NET,ACT,ID=HPREE01
00- 02.39.34 V NET,ACT,ID=HPREE01
02.39.34 STC01954 IST097I VARY ACCEPTED
02.39.34 STC01954 IST093I PUHPR01 ACTIVE
02.39.34 STC01954 IST093I HPREE01 ACTIVE
Si vemos el nodo con detalle, con un D NET,ID=HPREE01,SCOPE=ALL, podremos ver lo siguiente:
00- 02.41.16 d net,id=hpree01,scope=all
02.41.16 STC01954 IST097I DISPLAY ACCEPTED
02.41.16 STC01954 IST075I NAME = HPREE01, TYPE = SW SNA MAJ NODE
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I PUHPR01 TYPE = PU_T2 , CONCT
IST1500I STATE TRACE = OFF
IST314I END
El Nodo PUHPR01 está en modo CONCT o CONECTABLE, es decir, que está esperando que el nodo remoto -en nuestro ejemplo, el AS/400 se conecte a él-.
3.- Tercero: La DLUR:
V NET,ACT,ID=DLUEE01
00- 02.44.37 V NET,ACT,ID=DLUEE01
02.44.37 STC01954 IST097I VARY ACCEPTED
02.44.37 STC01954 IST093I CTLEE01 ACTIVE
02.44.37 STC01954 IST093I DLUEE01 ACTIVE
Y si la vemos con detalle con un D NET,ID=DLUEE01,SCOPE=ALL:
00- 02.45.35 D NET,ID=DLUEE01,SCOPE=ALL
02.45.35 STC01954 IST097I DISPLAY ACCEPTED
02.45.35 STC01954 IST075I NAME = DLUEE01, TYPE = SW SNA MAJ NODE
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I CTLEE01 TYPE = PU_T2 , CONCT
IST089I CV01 TYPE = LOGICAL UNIT , CONCT
IST089I CV02 TYPE = LOGICAL UNIT , CONCT
IST089I CV03 TYPE = LOGICAL UNIT , CONCT
IST089I CV04 TYPE = LOGICAL UNIT , CONCT
IST314I END
Vemos que están los 4 terminales 3270 esperando conexión (CONCT).
Para mayor comodidad, se puede editar el miembro ATCCON00 de la VTAMLST y añadir estos nodos para que cada vez que arranque el VTAM, se lancen automáticamente siguiendo el mismo orden de arranque:
A0600,NSNAFXX,NSNA70X,NSNA90X,DYNMODEL,XCAE40R,XCAE40E,COSAPPN, *
A0TCP,DB8GLU,OSATRL1,IMS10APL,DB9GLU,OSAGE000,OSAGF000,IBMTGPS, *
XCAEE,HPREE01,DLUEE01
Con estos sencillos pasos, ya tenemos el z/OS preparado para recibir de brazos abiertos al AS/400. Ahora, solo queda configurar el AS/400 para conectarse al z/OS usando el Enterprise Extender.
1.7 Configuración del AS/400
En este punto, configuraremos el sistema AS/400 o iSeries para que los nodos creados en el z/OS puedan ser conectados sin mayor problema. Por tanto, seguiremos los siguientes pasos:
1.7.1 Obtención de Datos de Red (DSPNETA)
DSPNETA es el mandato que hay que lanzar para saber cómo se ha configurado nuestro nodo HPR en el punto 1.5.5. Es decir, esos datos, como CPNAME y NETID, los hemos obtenido lanzando este mandato en nuestro AS/400. Esta sería la salida del comando DSPNETA en nuestro AS/400 de este ejemplo:
Visualizar Atributos de Red
Sistema: I810
Nombre de sistema actual . . . . . . . . . . . . : I810
Nombre de sistema pendiente . . . . . . . . . :
ID de red local . . . . . . . . . . . . . . . . : WEYLAND
Nombre de punto de control local . . . . . . . . : I810
Ubicación local por omisión . . . . . . . . . . : I810
Modalidad por omisión . . . . . . . . . . . . . : BLANK
Tipo de nodo APPN . . . . . . . . . . . . . . . : *ENDNODE
Compresión de datos . . . . . . . . . . . . . . : *NONE
Compresión de datos en nodo intermedio . . . . . : *NONE
Número máximo de sesiones intermedias . . . . . : 200
Resistencia de adición de direccionamiento . . . : 128
ID de red de servidor/nombre de punto de control : *LCLNETID *ANY
…
…
Permitir soporte virtual de APPN . . . . . . . . : *NO
Permitir soporte de torre de transporte HPR . . : *NO
Como se puede apreciar, el ID de RED es WEYLAND y el CPNAME o Punto de control local es I810. Estos datos serán los que habrá que tener en cuenta cuando se cree el nodo HPREE01 de VTAM.
No obstante, hay que configurar el AS/400 -si no lo está ya- para que active el Enterprise Extender por defecto, ya que normalmente no está configurado -las opciones de “Permitir soporte virtual de APPN y Permitir soporte de torre de transporte HPR”. Para ello, con el mandato CHGNETA podemos cambiar los valores del AS/400 (aunque si existen controladores SNA activos en ese momento, no dejará hacerlo hasta que se desactiven) para habilitarlos, de forma que quede así:
Permitir soporte virtual de APPN . . . . . . . . : *YES
Permitir soporte de torre de transporte HPR . . : *YES
1.7.2 Creación Controlador HPRIP AS/400 – HPREE01
Para conectar punto a punto una red o túnel, como este caso, debemos crear un controlador análogo en el AS/400 para que hable con el nodo de VTAM que hemos configurado. La idea es que este controlador será el que haga de camino entre el z/OS y el AS/400. Para ello, debemos configurar los datos del Nodo HPR HPREE01 del z/OS en el AS/400. Esto se consigue con el mandato CRTCTLAPPC, e introduciendo lo siguiente:
Crear descr controlador (APPC) (CRTCTLAPPC)
Teclee elecciones, pulse Intro.
Descripción controlador . . . . > CTLAPPCEE Nombre
Tipo de enlace . . . . . . . . . > *HPRIP *ANYNW, *FAX, *FR, *HPRIP…
En línea en IPL . . . . . . . . *YES *YES, *NO
Dirección Internet remota . . . > ‘192.168.1.247’
Dirección Internet local . . . . *SYS
Temporizadores LDLC:
Cuenta reintentos LDLC . . . . 3 0-255
Temporizador reintento LDLC . 15 0-65535 segundos
Temorizador de vigencia LDLC 10 0-65535 segundos
Velocidad de enlace LDLC . . . . *CAMPUS
Tamaño máximo de trama . . . . . *LINKTYPE 265-16393, 256, 265, 512…
Id red remota . . . . . . . . . *NETATR Nombre, *NETATR, *NONE, *ANY
Punto control remoto . . . . . . > PROD Nombre, *ANY
Más…
Identificador de intercambio . . > 05633333 00000000-FFFFFFFF
LAN DSAP . . . . . . . . . . . . 04 04, 08, 0C, 10, 14, 18, 1C…
LAN SSAP . . . . . . . . . . . . 04 04, 08, 0C, 10, 14, 18, 1C…
Soporte de sesión CP APPN . . . *YES *YES, *NO
Tipo de nodo APPN remoto . . . . *ENDNODE *ENDNODE, *LENNODE…
Cometido de expansor de rama . . *NETNODE *NETNODE, *ENDNODE
Conmutación de vía acceso HPR . *NO *NO, *YES
Número grupo transmisión APPN . 1 1-20, *CALC
Creación automá dispositivo . . *ALL *ALL, *NONE
Suprimir disp. automáticamente 1440 1-10000, *NO
Definido por usuario 1 . . . . . 128 0-255, *LIND
Definido por usuario 2 . . . . . 128 0-255, *LIND
Definido por usuario 3 . . . . . 128 0-255, *LIND
Texto descriptivo . . . . . . . > ‘Controlador HPREE01 z/OS’
Lo puesto en negrita es lo que hay que cambiar o añadir. Vemos que el controlador del AS/400 se llamará CTLAPPCEE, será HPRIP y la IP remota será la VIPA de nuestro z/OS por la que irá el tráfico Enterprise Extender, es decir, la 192.168.1.247.
Lo siguiente a añadir será la ID de Red remota, que es WEYLAND, pero al ser la misma Red la que comparten el z/OS y el AS/400, con poner *NETATR basta. Y por supuesto, hay que saber el nombre del punto de control remoto o SSCPNAME, que, según nuestro VTAM del z/OS, se llama PROD (viendo el ATCSTR00 de la VTAMLST).
También hay que introducir el identificador de Intercambio, que es un número único en el sistema que identifica el enlace al nodo VTAM o mejor dicho, el nodo DLUR de VTAM. Recordáis el IDBLK y el IDNUM? Pues esos números son los que hay que emparejar aquí.
Dando al Intro, el controlador se creará.
Fig. 3: Controlador creado
En este momento, podemos entrar con un 8=Trabajar con estado y activarlo con un 1=Activar
Fig. 4: Activación del controlador
Al activar el controlador, y si volvemos a la pantalla de la figura 3, veremos cómo automáticamente se ha creado un controlador adicional llamado QAPENDXXX que controlará el entorno SNA, esto es perfectamente normal.
Si vamos a la consola de z/OS, debemos ver que al haberse activado, el nodo ha logrado comunicación por VTAM:
- 15.40.21 STC02003 IST2180I DYNLU = YES FOR WEYLAND.I810 SET FROM PUHPR01
15.40.21 STC02003 IST590I CONNECTIN ESTABLISHED FOR PU PUHPR01 ON LINE
LINV00F
15.40.21 STC02003 IST1086I APPN CONNECTION FOR WEYLAND.I810 IS ACTIVE –
TGN = 6
00 15.40.23 STC02003 IST1488I ACTIVATION OF RTP CNR00003 AS PASSIVE TO
WEYLAND.I810
15.40.23 STC02003 IST1096I CP-CP SESSIONS WITH WEYLAND.I810 ACTIVATED
Se ve como ha pillado la primera línea que ha querido, la LINV00F y se ha establecido contacto con el sistema WEYLAND.I810, creando una sesión APPN entre los dos sistemas. En estos momentos, el túnel SNA/IP está funcionando perfectamente.
1.7.3 Creación Controlador DLUR AS/400 – DLUEE01
Una vez creado el camino según el punto anterior, ahora hay que crear en el AS/400 el controlador equivalente que se conectará al VTAM con los terminales que hemos definido (recordemos que definimos una PU y 4 LUs). La PU se crea en el AS/400 con el mandato CRTCTLHOST, e introduciremos los datos siguientes, de acuerdo a la configuración de nuestra DLUR DLUEE01:
Crear descr contr (S prpl SNA) (CRTCTLHOST)
Teclee elecciones, pulse Intro.
Descripción controlador . . . . > CTLEE00001 Nombre
Tipo de enlace . . . . . . . . . > *DLUR *DLUR, *FR, *LAN, *SDLC, *X25
En línea en IPL . . . . . . . . *YES *YES, *NO
Conexión conmutada . . . . . . . > *YES *NO, *YES
Con posibilidad APPN . . . . . . *YES *YES, *NO
Tamaño máximo de trama . . . . . *LINKTYPE 265-16393, 256, 265, 512…
Identificador SSCP . . . . . . . 050000000000-05FFFFFFFFFF
ID de intercambio local . . . . *LIND 05600000-056FFFFF, *LIND
Conexión inicial . . . . . . . . *DIAL *DIAL, *ANS
Inicio de marcación . . . . . . *LINKTYPE *LINKTYPE, *IMMED, *DELAY
Estado conmutado mínimo APPN . . *VRYONPND *VRYONPND, *VRYON
Texto descriptivo . . . . . . . > ‘Controlador DLUR CTLEE01 z/OS’
Nombre de DLUS primario:
Nombre de punto de control . . > PROD Nombre, *NONE
Identificador de red . . . . . > WEYLAND Nombre, *NETATR
Nombre de DLUS de reserva:
Nombre de punto de control . . *NONE Nombre, *NONE
Identificador de red . . . . . Nombre, *NETATR
Nombre de PU dependiente . . . . > CTLEE01 Nombre, *NONE
Temporizador de activación . . . 170 30 a 2550 (segundos)
Tempor Dsc/reconexión (T309) . . 170 1-2550 (seg)
El controlador lo he llamado CTLEE00001. En enlace es DLUR, y el punto de control será PROD, mientras que el ID de Red será WEYLAND. Por último, PU dependiente será CTLEE01, que es la PU definida dentro de la DLUR donde nos conectaremos.
1.7.4 Creación Dispositivos Terminales AS/400 – DLUEE01
Y con la PU creada, vamos a crear los dispositivos terminales o LUs, concretamente 4, del CV01 al CV04. Estos dispositivos dependerán de la PU configurada en el punto 1.7.3, de la misma forma que en la DLUR, las LUs dependen de la PU. Para añadir un dispositivo en el AS/400, usaremos el mandato CRTDEVHOST, con las opciones siguientes:
Crear desc disp (Sis Prin SNA) (CRTDEVHOST)
Teclee elecciones, pulse Intro.
Descripción de dispositivo . . . > TERMINAL01 Nombre
Dirección ubicación local . . . > 01 01-FF
Ubicación remota . . . . . . . . > CV01 Nombre
En línea en IPL . . . . . . . . *YES *YES, *NO
Controlador conectado . . . . . > CTLEE00001 Nombre
Tipo de aplicación . . . . . . . > *EML *RJE, *EML, *PGM
Longitud máx. unidad petición . *CALC *CALC
Dispositivo emulado . . . . . . 3278 3278, 3284, 3286, 3287…
Teclado emulado . . . . . . . . *UPPER *UPPER, *LOWER
Bloqueo numérico emulado . . . . *NO *NO, *YES
Estación trabajo de emulación . *ANY Nombre, *ANY
Finalizar sesión con sist prin *UNBIND *UNBIND, *RSHUTD
Texto descriptivo . . . . . . . *BLANK
Nombre ubicación dependiente . . *NONE Nombre, *NONE
Con esto, acabamos de crear una emulación SNA que depende del controlador CTLEE00001, la ubicación remota o LU será CV01, y la dirección será la 01.
Para crear un segundo terminal:
Crear desc disp (Sis Prin SNA) (CRTDEVHOST)
Teclee elecciones, pulse Intro.
Descripción de dispositivo . . . > TERMINAL02 Nombre
Dirección ubicación local . . . > 02 01-FF
Ubicación remota . . . . . . . . > CV02 Nombre
En línea en IPL . . . . . . . . *YES *YES, *NO
Controlador conectado . . . . . > CTLEE00001 Nombre
Tipo de aplicación . . . . . . . > *EML *RJE, *EML, *PGM
Longitud máx. unidad petición . *CALC *CALC
Dispositivo emulado . . . . . . 3278 3278, 3284, 3286, 3287…
Teclado emulado . . . . . . . . *UPPER *UPPER, *LOWER
Bloqueo numérico emulado . . . . *NO *NO, *YES
Estación trabajo de emulación . *ANY Nombre, *ANY
Finalizar sesión con sist prin *UNBIND *UNBIND, *RSHUTD
Texto descriptivo . . . . . . . *BLANK
Nombre ubicación dependiente . . *NONE Nombre, *NONE
Y así, sucesivamente, hasta completar los 4 (porque no hemos definido mas).
Si ahora, trabajamos con el estado del controlador CTLEE00001, veremos que los terminales dependen del controlador, justo como la DLUR del VTAM:
Fig. 5: Terminales y Controlador.
Por tanto, si ahora activamos el controlador, deberíamos ver en la consola de z/OS las correctas activaciones:
Fig. 6: Activación de terminales.
00 16.10.18 STC02003 IST1488I ACTIVATION OF RTP CNR00004 AS PASSIVE TO
WEYLAND.I810
16.10.18 STC02003 IST1488I ACTIVATION OF RTP CNR00005 AS PASSIVE TO
WEYLAND.I810
16.10.19 STC02003 IST1883I SESSION ESTABLISHED WITH CTLEE01 - DLUR
WEYLAND.I810
Si ahora hacemos un D NET,ID=DLUEE01,SCOPE=ALL, veremos cómo los 4 terminales definidos ya no están en CONCT (conectable), sino ACTIV (Activos).
00- 16.11.08 d net,id=dluee01,scope=all
16.11.08 STC02003 IST097I DISPLAY ACCEPTED
16.11.08 STC02003 IST075I NAME = DLUEE01, TYPE = SW SNA MAJ NODE
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I CTLEE01 TYPE = PU_T2 , ACTIV
IST089I CV01 TYPE = LOGICAL UNIT , ACTIV
IST089I CV02 TYPE = LOGICAL UNIT , ACTIV
IST089I CV03 TYPE = LOGICAL UNIT , ACTIV
IST089I CV04 TYPE = LOGICAL UNIT , ACTIV
IST314I END
1.8 Conexión Final desde el AS/400 al z/OS vía SNA/IP
Ahora que tenemos todas las comunicaciones levantadas, basta con lanzar una emulación 3270 desde el AS/400 para ver como adquiere un terminal, y nos muestra la pantalla de logo del z/OS. Para ello, ejecutaremos el mandato STREML3270, y rellenaremos los datos:
Arrancar Emulación Pant 3270 (STREML3270)
Teclee elecciones, pulse Intro.
Controlador de emulación, o . . CTLEE00001 Nombre
Dispositivo de emulación, o . . Nombre
Ubicación de emulación . . . . . Nombre
Disp pantalla, solo por lotes . *CURRENT Nombre, *CURRENT
Tecla Retroc Pág (Giro Abajo) . *PA2 *PA2, *PA1, *PA3, *NONE…
Tecla Avance Pág (Giro Arriba) *PA1 *PA1, *PA2, *PA3, *NONE…
Tecla Petición Prueba . . . . . *DFT *DFT, *CLEAR, *ERASEINP
Tecla de Selección de Cursor . . *NONE *NONE, *F1, *F2, *F3, *F4…
Emulación SNA DBCS 3270PC . . . *NO *NO, *YES
También podríamos poner en vez del controlador (CTLEE00001), el dispositivo (TERMINAL01) o la ubicación (CV01), lo mismo da, el caso es que se arrancaría la emulación:
Fig. 7: Logo de bienvenida emulación 3270 SNA
Si echamos un ojo al log de la consola del z/OS, veremos que se ha activado un dispositivo de forma dinámica:
16.16.54 STC02003 IST1488I ACTIVATION OF RTP CNR00006 AS ACTIVE TO
WEYLAND.I810
00- 16.17.06 TSU02047 $HASP373 IBMUSER STARTED
Fig.8: ISPF bajo SNA
A partir de ahora, se trabaja como una sesión 3270 normal y corriente.
Pero para verificar que realmente es así, basta con emitir el comando D NET,ID=DLUEE01,SCOPE=ALL para comprobar que el terminal CV01 está ACT/S, es decir, activo y en uso.
00- 16.18.33 d net,id=dluee01,scope=all
16.18.33 STC02003 IST097I DISPLAY ACCEPTED
16.18.33 STC02003 IST075I NAME = DLUEE01, TYPE = SW SNA MAJ NODE
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I CTLEE01 TYPE = PU_T2 , ACTIV
IST089I CV01 TYPE = LOGICAL UNIT , ACT/S
IST089I CV02 TYPE = LOGICAL UNIT , ACTIV
IST089I CV03 TYPE = LOGICAL UNIT , ACTIV
IST089I CV04 TYPE = LOGICAL UNIT , ACTIV
IST314I END
Y, si abrimos otra sesión 5250 al AS/400, podremos ver como nuestro usuario está usando el TERMINAL01.
Fig. 9: Terminal SNA 3270 en uso por QSECOFR
Pues esto es todo. A partir de aquí, se abre un mundo lleno de posibilidades con el SNA bajo IP, de modo que ahora os toca a vosotros experimentarlas.
El documento en PDF para que se vea mejor, podeis descargarlo desde aqui: Enterprise Extender
