Resumen: Funcionamiento, definiciones, aclaraciones
Relaciones entre las parametrizaciones necesarias
PROCEDIMIENTO DE ARRANQUE DE TCP
//TCPIPROC JOB MSGLEVEL=1
//STARTING EXEC TCPIPROC
XXPROFILE DD DSN=SW.TCPIP.SEZAPARM(CPUBPROF),DISP=SHR
XXSYSTCPD DD DSN=SW.TCPIP.SEZAPARM(TCPDATAB),DISP=SHRFICHERO PROFILE(SW.TCPIP.SEZAPARM(CPUBPROF))
PORT
7777 TCP CICSSITD ; CICS Socket
KEEPALIVEOPTIONS
INTERVAL 2
ENDKEEPALIVEOPTIONS
DEVICE LOSAB4 LCS 1002
LINK OSAB4TCP IBMTR 0 LOSAB4
HOME
192.168.172.088 OSAB4TCP
GATEWAY
192.168.172 = OSAB4TCP 1500 0
PARAMETROS DE BUFFER. (DATABUFFERPOOLSIZE EN 2.4 Y TCPSENDBUFFERSIZE-TCPRECEIVEBUFFERSIZE EN POSTERIORES)FICHERO TCPDATA (SW.TCPIP.SEZAPARM(TCPDATAB))
ARRANQUE DE CICS
TABLA DCT
TABLA PLT
FICHERO DE CONFIGURACION (EZACONFG).
Editran (ENTORNO LOCAL)
Editran (SESION DE TRANSMISION)
TIPOS CONEXION ADMITIDOS: I
Descripción de parametrizaciones necesarias
El procedimiento de arranque tcp, arranca una pila TCP y tiene 2 ficheros:
Fichero PROFILE. En el mismo se asignan:
Puertos (PORT). No es obligatorio hacerlo. En caso de que se codifique, estaremos asignando permanentemente dicho puerto a un CICS, para todas las direcciones IP de la pila, esto es, todas las llamadas entrantes que lleguen por dicha pila y por dicho puerto, se pasarán al CICS que se codifique en dicha macro. En CICS, tendrá que existir un registro en el fichero EZACONFG que contenga una transid editran (ZTBA), asignada a dicho puerto. Si no se codifica, existirá en CICS el registro descrito, pero no podrá estar asignado a un puerto que reservemos para otra cosa, esto es, si por ejemplo reservamos el puerto 23 para TELNET, en CICS no se podrá asignar dicho puerto a la transid ZTBA. Si queremos enganchar 2 monitores de teleproceso a la misma pila, y codificamos la macro PORT, no podremos recibir llamadas por dicho puerto por el monitor que no haya sido asignado a la macro.
Parámetro KEEPALIVE. Es conveniente ponerlo bajo (2-3 minutos) para que informe a editran en caso de caídas de conexión que no son informadas por TCP. Editran por su parte, incorpora una función, SETSOCKOPT, en relación con éste parámetro.
Direcciones locales de la pila. En el ejemplo se ha introducido una tarjeta OSA, Para ello, se codifica una macro LINK con el nombre de la misma. A continuación, se asocia la OSA en la macro HOME, con la dirección IP local de la misma. Por último, se incluye una macro GATEWAY para especificar las rutas seguidas para llamadas salientes. Si tenemos 2 direcciones IP, tendríamos por tanto 2 OSA y 2 macro LINK. Las llamadas salientes en éste caso, podríamos limitarlas a una única. Es labor del propio administrador de sistema, la definición de rutas de acceso, en función de sus necesidades, sobre todo en temas de seguridad.
Tamaño de buffer de la pila. Se especifican, en conjunto, los tamaños de envío y recepción. Es obligación del administrador una correcta distribución para el buen funcionamiento de editran.
Fichero TCPDATA. En el mismo se asignan:
Las direcciones de los servidores de nombres (parámetro NSINTERADDR). Si se genera desde CICS una petición de conexión, para una sesión editran, cuyas IP adress son DNS, éstos deben resolverse como direcciones reales IP. Para ello, se generan llamadas a los distintos servidores de nombres que codifiquemos. La dirección de éstos servidores es lo que se codifica aquí. Si en los mismos existe la correspondencia del DNS pedido devolverán por tanto la dirección IP a la que se deberá hacer el connect.
El puerto de los mismos (parámetro NSPORTADDR)
El nombre del address space del tcp en la pila (TCPIPJOBNAME). Dicho nombre debe coincidir con el miembro BPXPRMXX (XX es el sufijo) de la SYS1.PARMLIB y con el parámetro TCPNAME de la segunda pantalla de entorno de editran.
Arranque de CICS. Se definen los siguientes elementos:
Librerías TCP que solucionen llamadas a sockets y que contengan programas IBM.
DCSNAME de la tabla de destinos extrapartición. Se incluirá por tanto una DCT con dicho nombre. Sirve para generar mensajes de salida TCP.
Una SYSTCPD que apunta a un FICHERO TCPDATA (en principio debería ser el mismo al que apunta el procedimiento de la pila TCP). Sirve para apuntar a las direcciones de los servidores de nombres (parámetro NSINTERADDR). Dicho TCPDATA no tiene porqué ser el de la pila a la que está asociado el CICS. Las llamadas a ésta SYSTCPD sirven sólo para procesos cliente. editran, por tanto, resolverá los DNS de las sesiones, en función de los servidores que contenga el TCPDATA de la SYSTCPD y no en función del TCPDATA del procedimiento de arranque TCP, aunque se insiste en que podría ser el mismo.
Tabla DCT. Se define el DCSNAME descrito en el arranque de CICS, y el destino para sacar por el mismo los mensajes de la interfaz de sockets. Dicho destino deberá codificarse también en el registro CICS del fichero EZACONFG, en concreto en el parámetro ERRORTD.
PLT. Se divide en 2 partes:
PLT de inicio- Se llama a programas que activan-desactivan los sockets y los listener. En concreto, los primeros los activa el programa IBM EZACIC20 y los segundos el programa editran ZTBPOTCI, que arranca la transid ZTBZ (ZTBPOTCZ). Esta, a partir de la lectura del EZACONFG arrancará todos los registros listener que se encuentre con el parámetro SECEXIT = editran. Las transid de arranque son el parámetro TRANID de dicho registro. Si tenemos varios listener (cada uno escuchando por un puerto distinto), se definirán todas las tranid en la PCT y todas ellas, se asociarán al programa ZTBPOTCC. Estas transacciones listener arrancadas, permanecerán activas, escuchando indicaciones de conexión, cada una por su puerto, hasta que se tire el CICS de nuevo o hasta que se paren los sockets for cics. Si algún listener no ha sido activado en este punto, se puede invocar a la transid ZTBZ para que lo active.
PLT de finalización. En el momento de la caída de CICS, entrará en funcionamiento la PLT de finalización En concreto, el programa IBM EZACIC20 que desactiva los sockets for CICS y a continuación el programa editran ZTBPOTCF, que se comunicará son los LISTENER editran activos, para que éstos últimos finalicen ordenadamente.
Fichero EZACONFG se definen, (en el ejemplo a través de la transid EZAC):
Registros CICS. En el mismo, se asocia el nombre del monitor de teleproceso a la pila a la que se engancha (address space del TCP) esto es, al nombre que aparece en el TCPIPJOBNAME de la pila con la que se conecta el CICS (parámetro del TCPDATA). También se define el destino DCT (parámetro ERRORTD). Si se definen registros CICS que no corresponden al monitor de teleproceso sobre el que estamos, el EZACONFG deberá ser el mismo en los CICS definidos.
Registros LISTENER. Se asocian siempre a un CICS determinado, es decir podríamos tener 2 iguales asociados a distintos CICS. En los mismos se incluye la transid editran y el puerto por el que va a escuchar. Se pueden definir, por tanto, a un mismo registro CICS, varias transid editran (con distinto nombre), pero asociadas al mismo programa, y escuchando por puertos distintos. El fichero EZACONFG se define mediante jcl y se modifica vía transid EZAC.
PPT. Se definen los programas ZTBPOTCC (Programa server padre o listener) ZTBPOTCD (Programa server child o cliente) ZTBPOTCZ (Programa que arrancará las distintas copias de ZTBPOTCC según las transid definidas con los mismos), ZTBPO201 (Núcleo editran para conexiones TCP), ZTBPOTCI (PLT de inicio) ZTBPOTCF (PLT de finalización) y Programas IBM.
PCT. Se definen: ZTBB (programa ZTBPOTCD) (se codifica en entorno editran como TRANSID API TCP), ZTBZ (programa ZTBPOTCZ), ZTBA o XXXX (programa ZTBPOTCC) y transacciones IBM (EZAC, EZAO y las que se requieran).
Ejemplo práctico y conclusiones
Se ha buscado un ejemplo muy complejo para poder encontrar las relaciones necesarias y verificar los puntos de funcionamiento erróneo, por lo que se recomienda su no implementación.
Tenemos 2 PILAS TCP (PILA001 Y PILA002) con las siguientes características:
PILA001 tiene un procedimiento de arranque que tira de un PROFILE001 Y DE UN TCPDATA001.
El PROFILE001 tiene PORT 7777 contra CICS002 y un home con las direcciones 111.111.111.111 asociada a una OSA11 y 111.111.111.112, asociada a una OSA12
El TCPDATA001 tiene un TCPIPJOBNAME TCPIP001 y no tiene NSINTERADDR
PILA002 tiene un procedimiento de arranque que tira de un PROFILE002 Y DE UN TCPDATA002.
El PROFILE002 no tiene PORT y tiene un home con la dirección 222.222.222.222 asociada a la OSA21
El TCPDATA002 tiene un TCPIPJOBNAME TCPIP002, un NSINTERADDR 002.002.002.002 y otro NSINERADDR 002.002.002.001.
Tenemos 2 CICS (CICS001 Y CICS002) con las siguientes características):
CICS001. En el arranque apunta a TCPDATA002.
CICS002. En el arranque apunta a TCPDATA002.
Tenemos 1 ó 2 ficheros de configuración (EZACONFG). En el ejemplo se definen 2: CONFG001 para CICS001 y CONFG002 para CICS002) con las siguientes características (todas las transid están asociadas al programa ZTBPOTCC):
CONFG001: Un registro CICS APPLID= CICS001, TCPADDR=TCPIP001
CONFG001: Un registro CICS APPLID= CICS001, TRANID=ZTBQ, PORT =7777
CONFG001: Un registro CICS APPLID= CICS001, TRANID=ZTBR, PORT =7778
CONFG001: Un registro CICS APPLID= CICS001, TRANID=ZTBS, PORT =7779
CONFG001: Un registro CICS APPLID= CICS001, TRANID=ZTBY, PORT =7779
CONFG002: Un registro CICS APPLID= CICS002, TCPADDR=TCPIP002
CONFG002: Un registro CICS APPLID= CICS002, TRANID=ZTBQ, PORT =7777
CONFG002: Un registro CICS APPLID= CICS002, TRANID=ZTBR, PORT =7778
CONFG002: Un registro CICS APPLID= CICS002, TRANID=ZTBT, PORT =7779
Tenemos 2 editran:
EDICICS001. En entorno TCPNAME apunta a TCPIP002 y en API TCP a ZTBB.
EDICICS002. En entorno TCPNAME apunta a TCPIP001 y en API TCP a ZTBB.
Si se arrancan los listener en ambos CICS (PLT, transid ZTBZ o transid EZAO start LISTENER), siempre y cuando se hayan arrancado los sockets for cics, se van a enganchar los siguientes procesos:
La transid ZTBQ de CICS001 se tendría que quedar escuchando llamadas entrantes por el puerto 7777 de la dirección 111.111.111.111 y 111.111.111.112, puesto que en el registro CICS del EZACONFG se especificó TCPIP001, y por tanto tira de la PILA001, que tiene dicho TCPIPJOBNAME = TCPIP001, en su TCPDATA001, sacando la dirección local de la macro HOME del PROFILE001. Sin embargo, como en dicha PILA001 se especifica en el PROFILE001 el PORT 7777 asignado a CICS002, no va a ser posible la activación del LISTENER descrito, puesto que está asignado a otro CICS (ERRNO 13 ó permiso denegado). Si un remoto llama a dicha dirección y puerto le dará un error de connect 61 (no existe LISTENER activo)
La transid ZTBR de CICS001 se engancha correctamente al puerto 7778 de la dirección 111.111.111.111. y 111.111.111.112
La transid ZTBS de CICS001 se engancha correctamente al puerto 7779 de la dirección 111.111.111.111 y 111.111.111.112
La transid ZTBY de CICS001 NO se engancha correctamente al puerto 7779 de las direcciones anteriores, puesto que ya lo tiene la ZTBS de CICS001. Da un errno 48 (otro proceso ya lo tiene cogido)
La transid ZTBQ de CICS002 se engancha correctamente al puerto 7777 de la dirección 222.222.222.222.
La transid ZTBR de CICS002 se engancha correctamente al puerto 7778 de la dirección 222.222.222.222. (el CICS001 está enganchado a través de SU ZTBR al mismo puerto de las direcciones 111.111.111.111 y 111.111.111.112).
La transid ZTBT de CICS002 se engancha correctamente al puerto 7779 de la dirección 222.222.222.222 (el CICS001 está enganchado a través de SU ZTBS al mismo puerto de las direcciones 111.111.111.111 y 111.111.111.112).
Los listener de ambos CICS, aunque a nivel de EZACONFG tienen un TCPADDR que no coincide con el TCPNAME del entorno de editran, van a funcionar correctamente, a pesar de que editran utiliza en la macro INITAPI el parámetro TCPNAME de ENTORNO. Sin embargo, la interfaz TCPIP hace caso omiso del mismo, de momento. Esto no ocurre en monitor de teleproceso IMS, en cuyo caso la interfaz sigue fielmente lo indicado en editran. En dicho monitor no existe fichero EZACONFG, con lo que la relación se produce entre el TCPIPJOBNAME y el parámetro de entorno editran.
En éste punto, tendremos:
CICS001. Tiene 2 listener editran, que escuchan las llamadas entrantes que le llegan por las direcciones 111.111.111.111 y 111.111.111.112, Dichos listener son:
ZTBR. Sólo atiende a las llamadas entrantes por dichas direcciones y puerto 7778.
ZTBS. Sólo atiende a las llamadas entrantes por dichas direcciones y puerto 7779.
CICS002. Tiene 3 listener editran, que escuchan las llamadas entrantes que le llegan por la dirección 222.222.222.222, Dichos listener son:
ZTBQ. Sólo atiende a las llamadas entrantes por dicha dirección y puerto 7777.
ZTBR. Sólo atiende a las llamadas entrantes por dicha dirección y puerto 7778.
ZTBT. Sólo atiende a las llamadas entrantes por dicha dirección y puerto 7779.
Dichos listener, permanecerán arrancados hasta la caída de CICS o hasta la caída de los sockets for cics. Al entrar cualquier llamada por una dirección y puerto de los descritos, las transid asociadas a los mismos aceptarán la llamada y cederán control a la ZTBB (TRANSACCION SERVER CHILD) para que sea ésta la que esté en contacto con el núcleo de editran y con los extremos remotos, de modo que las transid listener quedan únicamente a la espera de nuevas indicaciones de conexión. Así, por ejemplo, si entran 6 llamadas en el CICS001, 2 de ellas por la dirección 111.111.111.111 puerto 7778, otras 2 por la dirección 111.111.111.112 puerto 7778, y otras 2 por la dirección 111.111.111.111 puerto 7779, se verán en ejecución al menos 8 tareas (ZTBR, ZTBS y 6 ZTBB). Las ZTBB finalizan cuando se libera la conexión entre ambos extremos. A su vez, la transid ZTBB es también la transid CLIENTE de editran, de modo que, si en éste punto se hubieran realizado 10 llamadas salientes desde CICS, se verían en ejecución 18 tareas (las anteriores más otras 10 ZTBB). En el proceso cliente también se va a utilizar el TCPNAME de entorno editran para la macro INITAPI, pero como se ha explicado anteriormente, hace caso omiso de dicho valor y se engancha a lo que se haya codificado en el TCPADDR del registro CICS del EZACONFG.
Otras acciones que podrían ocurrir son:
Si en editran de CICS001 se define a un remoto con un DNS y no con un ip-address, y se intenta generar una solicitud de llamada desde CICS, ésta se resuelve correctamente, porque, aunque dicho CICS está asociado a la PILA001 (que no tiene NSINTERADDR en el TCPDATA001), en el arranque de dicho CICS se le referenció que acudiese al TCPDATA002 para éste tipo de situaciones. Si en dicho arranque se le hubiera seleccionado el TCPDATA001, no hubiera sido posible la resolución del DNS por no disponer de un servidor de nombres. Si el servidor que soluciona el DNS es el 002.002.002.001, se habrán realizado 2 llamadas a 2 servidores de nombres (primero al asociado a la dirección 002.002.002.002 y luego al que resuelve 002.002.002.001)
Un monitor de teleproceso no puede estar enganchado a 2 pilas tcp a la vez.
Dos monitores de teleproceso pueden convivir con la misma pila TCP, pero no pueden arrancar simultáneamente dos listener sobre el mismo puerto. Esto es lo mismo que arrancar dentro de un monitor de teleproceso 2 transid distintas sobre el mismo puerto. También es lo mismo que intentar arrancar 2 veces el mismo listener, en cuyo caso la propia programación editran no lo va a permitir, aunque tampoco lo permitiría la interfaz de sockets pues ya existe otro activo sobre el mismo puerto. Tampoco es posible que un CICS esté como servidor en una PILA y como cliente en otra.
En las actuaciones como servidor, en la macro BIND, no se utiliza la dirección IP local, de modo que un listener quedaría escuchando por un puerto a todas las direcciones IP de una pila de arranque (DIRECCION 00000000 del PUERTO XXXXX). En la pila se pueden incluir además VIPAS (Virtual ip address). Sin embargo, no se le ve mucha utilidad a que una VIPA ó una OSA quiera ser escuchada por un puerto y otra VIPA-OSA, ser escuchada por otro distinto del anterior. La solución implementada pasa porque ambas escuchan por ambos puertos. En el router que tiene acceso al host habría que codificar la VIPA con una dirección estática.
El fichero EZACONFG PUEDE ser único, y ser actualizado (transid EZAC) desde un ÚNICO CICS, puesto que en la clave se incluye el NOMBRE del monitor de teleproceso. En éste caso requiere ser visto con el mismo DSN por el otro CICS. Sin embargo, no se pueden arrancar-parar los sockets for cics o los LISTENER de otro CICS que no sea el propio, esto es, podremos definir en EZACONFG de CICS001, al CICS002 (clave CICS) y a los LISTENER de CICS002 (en éste último CICS estaría definido el mismo EZACONFG que en CICS001), pero no podríamos activar desde CICS001 los sockets for CICS ni los LISTENER de CICS002. Estos, son activados desde CICS002 con la transid EZAO.
Si queremos asignar otra PILA, sin parar el CICS, pararíamos los LISTENER, con EZAO STOP CICS (los listener dan un error 10300 en el log de editran), de modo que con éste comando se paran también los sockets for cics. A continuación, modificamos el registro del CICS correspondiente con EZAC ALTER CICS, poniendo en el parámetro TCPADDR, el nombre del address space del TCP en la nueva pila. Tras esto, activaríamos los sockets for cics (EZAO START CICS) y por ÚLTIMO activaríamos los listener (EZAO START LISTENER ó ejecutando la ZTBZ). Si se produce un error 121 en MACRO takesocket, puede significar que ha entrado una llamada y que el listener principal (ZTBA u otros), ha arrancado el listener hijo (ZTBB) y éste no ha contestado al anterior con dicha macro en el tiempo especificado en EZACONFG, parámetro GIVTIME. Si es así, revise parametrizaciones de CICS, prioridades de transid, parámetro EAS en la definición del CICS a VTAM y relación entre parámetro TCLASS de la PCT y CMXT de la SIT (en la SIT está el parámetro MXT para indicar el número de transid CICS), puesto que puede ocurrir que no ha dado tiempo a arrancar la tarea y esto puede producirse tanto por stress de CICS, como por parametrizaciones que limitan el número de tareas en ejecución.
El parámetro EAS, en la definición del CICS a VTAM, es el número de tareas de comunicación en ejecución. En la PCT se puede apuntar la tarea a una clase (de 01 a 10), con el parámetro TCLASS y en la SIT con el parámetro CMXT se dice el número de transid en ejecución de cada una de las clases y el CMXT para indicar el número total. Para TCP, hay al menos en ejecución permanente: un listener (hasta caída de CICS o SOCKETS for CICS), n ZTBB (1 por cada conexión establecida, que mueren cuando acaba la transmisión) y n ZTB0 (núcleos editran), que se arrancan y mueren por cada ráfaga de mensaje (parámetro NUM.REG.SINCRONISMO, de los perfiles de la sesión editran) que se envía-recibe sobre cada conexión. Así, por ejemplo, si tenemos 4 conexiones, tendremos 1 + 4 + x tareas en ejecución simultánea. Si los parámetros no son adecuados se ralentiza el CICS.
Consideraciones sobre el espacio de buffer
Es posible controlar el tamaño de los buffer de envío y recepción, (para ver las definiciones, consulte el Utilidades y Códigos.
En cuanto a la velocidad de proceso la entidad debe ser la que limite o haga una adecuación correcta de las parametrizaciones. Todo ello, tiene relación con la ráfaga de envío de cada sesión de transmisión (nro de registros enviados entre cada confirmación), la velocidad de la línea local, la velocidad de la línea remota, el nro de procesos simultáneos, el tamaño de la MTU, la longitud de transmisión, etc.
Así, por ejemplo, si nos conectamos contra un remoto al que le vamos a emitir ráfagas de 100 mensajes (de 4050) implica que grabaremos unos 400 K en los buffers de emisión. Si a esa sesión la definimos con buffer de envío tcp 0, cogerá el valor que haya en la pila. Si no hay nada, cogerá el defecto 16 K y probablemente se ralentizará la transmisión. Si, por el contrario, hubiéramos codificado 200000 bytes (200 K) en el buffer de envío de la sesión, (mientras grabamos en el buffer, este va sacando y dejando nuevo espacio disponible), probablemente no habría ninguna ralentización.
En la SIT y definición del arranque de CICS a VTAM se define el número máximo de tareas simultaneas. En el ejemplo anterior había 18 SIMULTÁNEAS y habría que añadir núcleos simultáneos, procesos editran batch, procesos de time-out, etc.
Trazas TCP/IP de buffer
En alguna entidad, se ha conseguido sacar una traza de buffer, en la que se observa la ventana de envío y recepción y se puede hacer un cálculo de utilización de buffer.
Se refleja a continuación y únicamente a efectos informativos (sin soporte alguno por parte de editran) los pasos que dicha entidad ha seguido para sacar dicho trace (al parecer es necesario disponer de IPCS):
En el manual OS/390 V2R6.0 eNetwork CS IP Diagnosis aparece el procedimiento de “IP Packet Trace". (Hay otro tipo de trace denominado "Component Trace" cuyo procedimiento es muy similar a éste).
Los pasos que se siguen son:
Arrancar el trace TCP/IP: V TCPIP,proc_arranque_TCPIP,CMD=O,DSN=data_set_name
data_set_name : Fichero o miembro de librería que debe contener las siguientes instrucciones:
Arrancar el external writer. TRACE CT, WTRSTART=TRTCP1, WRAP
El trace quedará, sin formatear, en el DSN representado por TRCOUT01.
Conectar el external writer con la pila TCP/IP:
Reproducir el problema.
Desconectar el external writer.
No suele pedir esta reply.
Parar el external writer.
Parar el trace TCP/IP.
data_set_name: Fichero o miembro de librería que debe contener las siguientes instrucciones:
Procesar los datos del trace existentes en la data set anterior y obtenerlos en otra data set, esto es:
Crear el DATA SET y asociarlo a la DDNAME IPCSPRNT, esto es, desde la opción P.6 de ISPF, ejecutar los siguientes comandos tal cual están:
FREE FI (IPCSPRNT)
ALLOCATE DDNAME (IPCSPRNT) DATASET ('CUALIF1...CUALIFn.PRINT') NEW
KEEP SPACE (10, 5) TRACKS DSORG (PS) RECFM (V B A) LRECL (125)
BLKSIZE (1254)
(El nombre del DATA SET puede ser cualquiera, lo importante es que quede asociado a la DDNAME IPCSPRINT)
Desde TSO, acceder a IPCS.
Menú 0: Source: DSNAME ('CUALIF1...CUALIFn.TRACETC1')
Message Routing: PRINT TERMINAL
Menú 2.7.1.D: Component: SYSTCPDA
GMT/Local: L
Report Type: FULL
Options: PACKETTRACE
Menú 2.7.1.S.
Salir de IPCS. En el DATA SET IPCSPRNT obtenemos el trace formateado.