Nota: Antes de utilizar esta información, debe leer la
información general que figura en el apartado
Avisos.
|
Esta edición corresponde a IBM® Rational Developer for System z Versión 9.1.1 (número de programa 5724-T07) y a todos los releases y modificaciones ulteriores hasta que se indique lo contrario en nuevas ediciones.
Puede pedir las publicaciones por teléfono o por fax. IBM Software Manufacturing Solutions acepta los pedidos de publicaciones entre las 8:30 de la mañana y las 7:00 de la tarde, hora estándar del este (EST). El número de teléfono es (800) 879-2755. El número de fax es (800) 445-9269. Los faxes deben enviarse a Attn: Publications, 3rd floor.
También puede pedir publicaciones a través de su representante de IBM o de la sucursal de IBM que presta servicio en su localidad. En la dirección que figura más abajo no hay publicaciones almacenadas.
IBM agradece sus comentarios. Puede enviar sus comentarios por correo a la siguiente dirección:
IBM Corporation
Attn: Information Development Department 53NA
Building 501 P.O. Box 12195
Research Triangle Park NC 27709-2195
Estados Unidos de América
Puede enviar sus comentarios por fax a: 1-800-227-5088 (EE.UU. y Canadá)
Cuando envía información a IBM, otorga a IBM un derecho no exclusivo a utilizar o distribuir la información del modo que IBM considere oportuno sin incurrir por ello en ninguna obligación para con usted.
© Copyright IBM Corporation 2000, 2014
Nota sobre los derechos restringidos de los usuarios del Gobierno de EE. UU. - El uso, la duplicación o la divulgación están sujetos a las restricciones establecidas en el contrato GSA ADP Schedule Contract con IBM Corp.
Este documento proporciona información básica sobre diferentes tareas de configuración de IBM Rational Developer for System z y otros componentes y productos de z/OS (como WLM y CICS).
La información de este documento se aplica a todos los paquetes de
IBM Rational Developer for System z Versión 9.1.1.
Para obtener las versiones más actualizadas de este documento, consulte la Guía de referencia de configuración de host de IBM Rational Developer for System z (SC11-7903) que está disponible en http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SC14-7290.
Para obtener las versiones más actualizadas de toda la documentación, incluyendo instrucciones de instalación, libros blancos, podcasts y guías de aprendizaje, consulte la página de biblioteca del sitio web de IBM Rational Developer for System z (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).
Este documento está destinado a los programadores de sistemas que configuran y ajustan
IBM Rational Developer for System z Versión 9.1.1.
Mientras que los pasos de configuración reales se describen en otra publicación, esta publicación proporciona una lista detallada de diversos temas relacionados, como por ejemplo, el ajuste, la configuración de seguridad y otros temas. Para utilizar esta documentación, debe estar familiarizado con z/OS UNIX System Services y con los sistemas de hospedaje MVS.
En esta sección se resumen los cambios de la Guía de referencia de configuración de host de IBM Rational Developer for System z Versión
9.1.1, SC11-7903-08 (actualizada en diciembre de 2014).
Los cambios técnicos o las adiciones al texto y las ilustraciones se indican mediante una línea vertical situada a la izquierda del cambio.
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host IBM Rational Developer for System z Versión 9.1.1, SC11-7903-07.
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host de IBM Rational Developer for System z Versión 9.0.1, SC11-7903-07.
Este documento contiene información presentada anteriormente en la IBM Rational Developer for System z Versión 9.0.1 Guía de referencia de configuración de host, SC11-7903-07.
Información nueva:
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host de IBM Rational Developer for System z Versión 8.5.1, SC11-7903-07.
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host de IBM Rational Developer for System z Versión 8.5, SC11-7903-07.
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host IBM Rational Developer for System z Versión 8.0.3, SC11-7903-07.
Este documento contiene información presentada anteriormente en la Guía de referencia de configuración de host de IBM Rational Developer for System z Versión 8.0.1, SC11-7903-00.
En esta sección se resume la información presentada en este documento.
El host de Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Comprender el diseño de estos componentes puede ayudarle a tomar las decisiones de configuración correctas.
Developer for System z proporciona a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. Algunos aspectos importantes de la configuración del producto son: validar las solicitudes de conexión, proporcionar una comunicación segura entre el host y la estación de trabajo, y autorizar y auditar la actividad.
Developer for System z utiliza TCP/IP para proporcionar a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. También utiliza TCP/IP para establecer comunicación entre distintos componentes y otros productos.
Al contrario que las aplicaciones z/OS tradicionales, Developer for System z no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Algunos de estos servicios están activos en diferentes espacios de direcciones, lo que resulta en diferentes clasificaciones WLM.
RSE (Explorador de Sistemas remotos) es el núcleo de Developer for System z. Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente.
Ello hace que RSE sea el destino principal para ajustar la configuración de Developer for System z. Sin embargo, para mantener a cientos de usuarios, cada uno de los cuales utiliza 17 o más hebras, una cantidad determinada de almacenamiento y, posiblemente, uno o más espacios de direcciones es necesario configurar correctamente Developer for System z y z/OS.
z/OS es un sistema operativo sumamente personalizable, y los cambios de sistema (a veces pequeños) pueden afectar considerablemente al rendimiento global. En este capítulo se resaltan algunos de los cambios que se pueden hacer para mejorar el rendimiento de Developer for System z.
Este capítulo contiene información útil para un administrador de CICS Transaction Server.
Este capítulo le ayuda a mejorar Developer for System z escribiendo rutinas de salida.
Este capítulo le ayuda a emular un procedimiento de inicio de sesión TSO añadiendo sentencias DD y conjuntos de datos al entorno TSO en Developer for System z.
En algunas ocasiones le interesará tener múltiples instancias de Developer for System z activas en el mismo sistema; por ejemplo, al probar una ampliación. Sin embargo, algunos recursos como los puertos TCP/IP no se pueden compartir, por lo que los valores predeterminados no siempre son aplicables. Utilice la información de este capítulo para planificar la coexistencia de distintas instancias de Developer for System z y después podrá usar esta guía de configuración para personalizarlas.
Esta sección se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar la capa de sockets segura (SSL) o durante la comprobación o modificación de una configuración existente. Esta sección también facilita una configuración de ejemplo para admitir que los usuarios se autentiquen con un certificado X.509.
Esta sección se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar TCP/IP, o durante la tarea de comprobar o modificar una configuración existente.
El host de Developer for System z consta de varios componentes que interactúan para dar al cliente acceso a los servicios y datos del host. Comprender el diseño de estos componentes puede ayudarle a tomar las decisiones de configuración correctas.
La descripción del párrafo y la lista anteriores muestra el rol central asignado al RSE. Salvo algunas excepciones, toda la comunicación de cliente va a través del RSE. Ello permite una configuración de la red de seguridad sencilla, ya que únicamente se utiliza un conjunto limitado de puertos para la comunicación cliente-host.
Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente. Basándose en los valores definidos en el archivo de configuración rsed.envvars y en la cantidad de conexiones de cliente reales, el daemon puede iniciar varios espacios de direcciones de agrupaciones de hebras.
La Figura 2 muestra una vista básica del uso de recursos (procesos y almacenamiento) por RSE.
RSE es una aplicación Java™, lo que significa que está activo en el entorno z/OS UNIX. Ello permite establecer puertos de forma sencilla a otras plataformas de host y una comunicación directa con el cliente de Developer for System z, que también es una aplicación Java (basada en la infraestructura de Eclipse). Por ello, tener un conocimiento básico de cómo funcionan z/OS UNIX y Java es de gran ayuda para comprender Developer for System z.
En z/OS UNIX un programa se ejecuta en un proceso, identificado por un PID (ID de proceso). Cada programa está activo en su propio proceso, de manera que el hecho de invocar otro programa crea un proceso nuevo. Se hace referencia al proceso que ha iniciado un proceso con un PPID (PID padre), y el proceso nuevo se denomina proceso hijo. El proceso hijo se puede ejecutar en el mismo espacio de direcciones, o bien se puede engendrar (crear) en un espacio de direcciones nuevo. Un proceso nuevo que se ejecuta en el mismo espacio de direcciones puede compararse con la ejecución de un mandato en TSO; mientras que engendrar uno en un espacio de direcciones nuevo es similar a someter un trabajo por lotes.
Tenga un proceso puede tener una sola o varias hebras. En una aplicación de varias hebras (como RSE), las distintas hebras compiten por los recursos del sistema, como si fueran espacios de direcciones separados (con menos sobrecarga).
RSE es capaz de ejecutarse en modalidad de direccionamiento de 31 bits o de 64 bits, lo que resulta en diferentes límites de almacenamiento. En la modalidad de 31 bits, el almacenamiento disponible se limita a 2 GB, mientras que en la modalidad de 64 bits no hay límite, a menos que se especifique en SYS1.PARMLIB.
Las aplicaciones Java, tales como RSE, no asignan almacenamiento directamente, sino que utilizan los servicios de gestión de memorias de Java. Estos servicios, como la asignación de almacenamiento, la liberación de almacenamiento, y la recogida de basura, funcionan dentro de los límites del almacenamiento dinámico de Java. El tamaño mínimo y máximo del almacenamiento dinámico se define (ya sea implícita o explícitamente) durante el inicio de Java. Cuando se ejecuta en modalidad de 64 bits, Java intentará asignar el almacenamiento dinámico por encima de la barra de 2 GB, liberando el espacio por debajo de la barra.
Ello implica que obtener el máximo del tamaño de espacio de direcciones disponible es un acto de equilibrio que consiste en definir un tamaño de almacenamiento dinámico grande y dejar suficiente espacio para que z/OS almacene una cantidad variable de bloques de control del sistema (que depende del número de hebras activas).
La Figura 3 muestra una visión general básica del propietario de las credenciales de seguridad utilizadas para varias tareas de Developer for System z.
La propiedad de una tarea se puede dividir en dos secciones. Las tareas iniciadas son propiedad del ID de usuario asignado a la tarea iniciada en el software de seguridad. El resto de tareas con las agrupaciones de hebras RSE (RSEDx) como excepción son propiedad del ID de usuario del cliente.
La Figura 3 muestra las tareas iniciadas de Developer for System z (DBGMGR, JMON y RSED y las tareas iniciadas de ejemplo y los servicios del sistema con los que Developer for System z se comunica. Application Deployment Manager (ADM) está activo dentro de una región CICS. El código USS REXEC representa el servicio z/OS UNIX REXEC (o SSH).
El daemon RSE (RSED) crea uno o varios espacios de direcciones de agrupaciones de hebras RSE (RSEDx) para procesar las peticiones de cliente. Cada agrupación de hebras RSE soporta varios clientes y es propiedad del mismo usuario que el daemon RSE. Cada cliente tiene sus propias hebras dentro de una agrupación de hebras y estas hebras son propiedad del ID de usuario de cliente.
Según las acciones realizadas por el cliente, se pueden iniciar uno o varios espacios de direcciones, todos propiedad del ID de usuario cliente para realizar la acción solicitada. Estos espacios de direcciones pueden estar en un trabajo por lotes MVS, una transacción APPC o un proceso hijo z/OS UNIX. Tenga en cuenta que un proceso hijo z/OS UNIX está activo en un iniciador z/OS UNIX (BPXAS) y que el proceso hijo aparece como una tarea iniciada en JES.
La mayoría de las veces es una hebra de usuario en una agrupación de hebras la que desencadena la creación de estos espacios de direcciones, ya sea directamente o a través de servicios del sistema como por ejemplo ISPF. Sin embargo, el espacio de direcciones también lo puede crear un tercero. Por ejemplo, z/OS UNIX REXEC o SSH se invocan al iniciar construcciones en z/OS UNIX.
Los espacios de direcciones específicos del usuario terminan cuando finaliza la tarea o cuando caduca el temporizador de inactividad. Las tareas iniciadas permanecen activas. Los espacios de direcciones que aparecen en la lista de la Figura 3 permanecen en el sistema lo suficiente para ser visibles. Sin embargo, debe tener en cuenta que debido al diseño de z/OS UNIX, también hay varios espacios de direcciones temporales de vida breve.
La descripción anterior muestra el diseño orientado a hebras de RSE. En lugar de iniciar un espacio de direcciones por usuario, un único espacio de direcciones de agrupaciones de hebras proporciona servicio a varios usuarios. Dentro de la agrupación de hebras, cada extractor (un servicio específico del usuario) se activa en su propia hebra con el contexto de seguridad del usuario que tiene asignado, asegurando así una configuración segura. Este diseño acomoda un mayor número de usuarios con un uso limitado de recursos, pero conlleva que cada cliente utilice varias hebras (17 o más, según las tareas realizadas).
El uso de PassTickets para todos los servicios de z/OS que requieren autenticación permite Developer for System z invocar estos servicios sin tener que almacenar la contraseña ni solicitarle al usuario continuamente que la introduzca. El uso de PassTickets para todos los servicios de z/OS también permite métodos de autenticación alternativos durante el inicio de sesión, como las contraseñas para una sola vez y los certificados X.509.
Developer for System z permite utilizar varios métodos para iniciar un servidor CARMA. Cada método tiene ventajas e inconvenientes. Developer for System z proporciona también varios Gestores de acceso a repositorio (RAM) que se pueden dividir en dos grupos, los RAM de producción y los RAM de ejemplo. Hay varias combinaciones de RAM y métodos de inicio de servidor como configuración preconfigurada.
Todos los métodos de inicio de servidor comparten un archivo de configuración común, CRASRV.properties, que (entre otras cosas) especifica qué método de inicio se utilizará.
El método "CRASTART" inicia el servidor CARMA como subtarea dentro de RSE. Ofrece una configuración muy flexible mediante la utilización de un archivo de configuración independiente que define las asignaciones de conjunto de datos e invocaciones de programa necesarias para iniciar un servidor CARMA. Este método ofrece el mejor rendimiento y utiliza la menor cantidad de recursos, pero requiere que el módulo CRASTART se encuentre en LPA.
CRASTART utiliza las definiciones de crastart*.conf para crear un entorno válido para ejecutar mandatos TSO e ISPF por lotes. Developer for System z utiliza este entorno para ejecutar el servidor CARMA, CRASERV. Developer for System z proporciona varios archivos crastart*.conf, cada uno preconfigurado para un RAM específico.
El método "sometimiento por lotes" inicia un servidor CARMA sometiendo un trabajo. Este es el método predeterminado utilizado en los archivos de configuración de ejemplo suministrados. La ventaja de este método es que puede accederse fácilmente a los registros de CARMA en la salida del trabajo. También permite utilizar JCL de servidor personalizado para cada desarrollador, cuyo mantenimiento realiza el propio desarrollador. Sin embargo, este método utiliza un iniciador de JES por cada desarrollador que inicia un servidor CARMA.
RSE invoca CLIST CRASUB*, que a su vez somete un JCL incorporado JCL para crear un entorno válido para ejecutar mandatos TSO e ISPF de proceso por lotes. Developer for System z utiliza este entorno para ejecutar el servidor CARMA, CRASERV. Developer for System z proporciona varios miembros CRASUB*, cada uno preconfigurado para un RAM específico.
Con una configuración de Developer for System z con un solo servidor, donde hay varios usuarios asignados a un único espacio de direcciones de agrupaciones de hebras, z/OS pierde la capacidad de rastrear quién es propietario de un bloqueo en un conjunto de datos o un miembro con el mandato del operador DISPLAY GRS,RES=(*,dataset*). Los mandatos del sistema se detienen a nivel de espacio de dirección, que es la agrupación de hebras.
Para solucionar este problema, Developer for System z proporciona el mandato de operador MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset, tal como se describe en "Mandatos de operador" en la Guía de configuración de host SC11-3660 (SC23-7658). El mandato de operador puede resolver todos los bloqueos de miembros y conjunto de datos realizados por usuarios de RSE, así como los bloqueos realizados por otros productos, como por ejemplo ISPF.
En circunstancias normales, un conjunto de datos o un miembro está bloqueado cuando un cliente lo abre en modalidad de edición, y este se libera cuando el cliente cierra la sesión de edición.
Algunas condiciones de error pueden provocar que este mecanismo no funcione tal como debe. En este caso, se puede cancelar el usuario que está manteniendo el bloqueo mediante el mandato de operador modify cancel de RSE, como se describe en "Mandatos de operador" en la publicación Guía de configuración de host (SC11-3660). Los bloqueos de conjuntos de datos activos de este usuario se liberan durante el proceso.
La Figura 8 muestra una visión general de los directorios de z/OS UNIX utilizados por Developer for System z. La lista siguiente describe cada directorio tocado por Developer for System z, cómo se puede cambiar la ubicación y quién mantiene los datos que contiene.
Los datos de /var/rdz/pushtoclient/ los mantienen los usuarios no administradores del sistema, que es posible que no dispongan de demasiados privilegios de actualización en z/OS UNIX. Por consiguiente, es importante comprender cómo z/OS UNIX establece los permisos de acceso durante la creación de archivos a fin de garantizar que la instalación funcione y sea segura.
Los estándares de UNIX indican que pueden establecerse permisos para tres tipos de usuario: propietario, grupo y otro. Pueden establecerse permisos de lectura, escritura y ejecución de forma individualizada para cada tipo.
Cada sitio puede establecer su propia máscara de permisos de acceso; no obstante, una máscara común concede permiso de lectura y escritura al tipo propietario y permiso de lectura a los tipos grupo y otro.
Los datos de /var/rdz/pushtoclient/ se crean utilizando la máscara de permisos de acceso definida en la directiva file.permission de pushtoclient.properties. El valor predeterminado concede permiso de lectura y de escritura para los tipos propietario y grupo, y permiso de lectura para el tipo otro. Todos tienen permiso de ejecución. Los permisos de acceso finales deberían permitir el acceso de lectura y ejecución a todos, y el acceso de escritura para los administradores de clientes de Developer for System z que mantienen los datos.
Los datos de /var/rdz/pushtoclient/projects/ se crean utilizando una máscara de permisos de acceso no específico. Los permisos de acceso finales deberían permitir acceso de lectura a todos, y permiso de escritura para los gestores de proyectos que mantienen los datos.
ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)
ls -lR /var/rdz/pushtoclient/
chown –R IBMUSER /var/rdz/pushtoclient/
chgrp -R RDZPROJ /var/rdz/pushtoclient/
chmod -R 775 /var/rdz/pushtoclient/
En el siguiente escenario, todos los gestores de proyectos de desarrollo, un equipo de tres personas, tienen asignada la tarea de ser administrador de un cliente de Developer for System z.
# chmod 775 /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER SYS1
/var/rdz/pushtoclient
# chgrp RDZPROJ /var/rdz/pushtoclient
# ls –ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER RDZPROJ
/var/rdz/pushtoclient
DE este modo concluye la configuración necesaria para limitar los permisos de escritura de /var/rdz/pushtoclient al programador del sistema (IBMUSER) y a los gestores de proyectos (RDZPROJ).
Developer for System z proporciona a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. Algunos aspectos importantes de la configuración del producto son: validar las solicitudes de conexión, proporcionar una comunicación segura entre el host y la estación de trabajo, y autorizar y auditar la actividad.
Los mecanismos de seguridad utilizados por los servidores y servicios de Developer for System z se basan en que los conjuntos de datos y los sistemas de archivos en los que residen sean seguros. Esto implica que sólo los administradores del sistema que sean de confianza puedan actualizar las bibliotecas de programa y los archivos de configuración.
En este capítulo se tratan estos temas:
Consulte Comprender Developer for System z para conocer los conceptos de diseño básicos de Developer for System z.
Developer for System z admite varias formas de autenticar un ID de usuario facilitado por un cliente durante la conexión.
El cliente facilita un ID de usuario y una contraseña coincidente durante la conexión. El ID de usuario y la contraseña se utilizan para autenticar al usuario en el producto de seguridad.
Basándose en una única señal, un producto externo puede generar una contraseña para una sola vez. Las contraseñas para una sola vez mejoran la configuración de seguridad, ya que la señal exclusiva no se puede copiar y utilizar sin el conocimiento del usuario, y una contraseña interceptada no sirve para nada porque solamente es válida una vez.
El cliente facilita un ID de usuario y una contraseña para una sola vez durante la conexión que se utiliza para autenticar el ID de usuario con la salida de seguridad proporcionada por un programa externo. Se espera que esta salida de seguridad ignore los PassTickets utilizados para satisfacer las solicitudes de autenticación durante el proceso normal. Su software de seguridad debe procesar los PassTickets.
El cliente facilita un ID de usuario y una frase de contraseña coincidente durante la conexión. El ID de usuario y la frase de contraseña se utilizan para autenticar al usuario en el producto de seguridad.
Un tercer puede proporcionar uno o varios certificados X.509 que se pueden utilizar en la autenticación de un usuario. Cuando están almacenados en dispositivos seguros, los certificados X.509 combinan una configuración segura con un uso sencillo para el usuario (no son necesarios ni ID de usuario ni contraseña).
Durante la conexión, el cliente facilita un certificado seleccionado y, opcionalmente, una extensión seleccionada, que se utiliza para autenticar el ID de usuario con su producto de seguridad.
El daemon RSE (o REXEC/SSH) realiza la autenticación de clientes como parte de la solicitud de conexión del cliente. Una vez se autentica el usuario, se utilizan PassTickets autogenerados para las solicitudes de autenticación que se realicen en el futuro, incluido el inicio de sesión automático en el Supervisor de trabajos JES.
Para que el Supervisor de trabajos JES valide el ID de usuario y el PassTicket presentado por RSE, el Supervisor de trabajos JES debe poder evaluar el PassTicket. Ello implica:
El daemon RSE (o REXEC/SSH) realiza la autenticación de clientes como parte de la solicitud de conexión del cliente. Una vez se autentica el usuario, se utilizan PassTickets autogenerados para las solicitudes de autenticación que se realicen en el futuro, incluido el inicio de sesión automático en el gestor de depuración.
Para que el gestor de depuración valide el ID de usuario y el PassTicket presentado por RSE, el gestor de depuración debe poder evaluar el PassTicket. Por tanto, el módulo de carga AQEZPCM, ubicado de forma predeterminada en la biblioteca de carga FEK.SFEKAUTH, debe estar autorizado por APF.
Cuando un motor de depuración basado en un cliente se conecta al gestor de depuración, debe presentar una señala de seguridad válida para la autenticación.
Developer for System z depende de productos de terceros, como el servidor TN3270, para proporcionar algunos servicios. Consulte la documentación de producto correspondiente para conocer las opciones de seguridad de conexión.
El programador del sistema puede especificar los puertos en los que el servidor RSE se puede comunicar con el cliente. Por omisión, se utiliza cualquier puerto disponible. Este rango de puertos no tiene conexión con el puerto del daemon RSE.
Todas las corrientes de datos externas de Developer for System z que pasan a través de RSE pueden cifrarse mediante SSL (Capa de sockets seguros) o TLS (Seguridad de capa de transporte). El uso de comunicación cifrada está controlado por los valores del archivo de configuración ssl.properties, tal como se describe en la sección Comunicación cifrada con SSL/TLS. La variable DSTORE_SSL_ALGORITHM de la directiva _RSE_JAVAOPTS de rsed.envvars permite elegir entre SSL y su eventor TLS como método de cifrado, tal como se indica en la sección "Definición de parámetros de inicio de Java adicionales con _RSE_JAVAOPTS" en la Guía de configuración de host (SC11-3660).
El motor del depurador integrado del cliente se conecta con el Gestor de depuración en el host. El uso de SS o TLS se controla mediante una directiva Application Transparent TLS (AT-TLS).
El Emulador de conexión de host del cliente se conecta a un servidor TN3270 del host. La utilización de SSL está controlada por TN3270, tal como se describe en la publicación Communications Server IP Configuration Guide (SC31-8775).
Las acciones remotas (basadas en host) de subproyectos z/OS UNIX utilizan un servidor REXEC o SSH en el host. La comunicación SSH siempre se cifra utilizando SSL.
El cliente Gestor de despliegue de aplicaciones utiliza el servicio Web de CICS TS de la interfaz RESTful para invocar los servicios de host del Gestor de despliegue de aplicaciones. La utilización de SSL está controlada por CICS TS, tal como se describe en la publicación RACF Security Guide for CICS TS .
Developer for System z da soporte a la comprobación de puerto de entrada (POE), que permite el acceso de host sólo a las direcciones TCP/IP de confianza. La utilización de POE está controlada por la definición de perfiles específicos del software de seguridad y por la directiva enable.port.of.entry del archivo rsed.envvars, como se describe en la sección Comprobación de puerto de entrada (POE).
Tenga en cuenta que la activación de POE influirá sobre otras aplicaciones TCPIP que den soporten a la comprobación de POE, como INETD.
Después de del inicio de sesión, se utilizan Pases (PassTickets) para establecer la seguridad de las hebras dentro del servidor RSE. Esta característica no puede inhabilitarse. Los PassTickets son contraseñas generadas por el sistema con un tiempo de vida aproximado de 10 minutos. Los PassTickets generados se basan en el algoritmo de cifrado DES, en el ID de usuario, en el ID de aplicación, en la indicación de fecha y hora, y en una clave secreta. Esta clave secreta es un número de 64 bits (16 caracteres hexadecimales) que deben definirse en el software de seguridad. Para seguridad adicional, el software de seguridad de z/OS utiliza PassTickets de forma predeterminada como contraseñas de un solo uso.
La contraseña real del cliente ya no es necesaria después de la autenticación inicial porque los productos de seguridad compatibles con SAF pueden evaluar tanto los PassTickets como las contraseñas habituales. El servidor RSE genera y utiliza un PassTicket cada vez que es necesaria una contraseña, cuyo resultado es una contraseña válida (temporal) para el cliente.
El uso de PassTickets permite a RSE configurar un entorno de seguridad específico del usuario a voluntad, sin necesidad de almacenar todos los ID de usuario y las contraseñas en una tabla, cosa que podría poner en peligro esta información. También lo permite para métodos de autenticación de cliente que no utilizan contraseñas reutilizables, como los certificados X.509.
Los perfiles de seguridad de las clases de APPL y PTKTDATA son necesarios para poder utilizar los PassTickets. Estos perfiles son específicos de la aplicación y, por ello, no afectan a la configuración de su sistema actual.
El hecho de que los PassTickets sean específicos de la aplicación implica que tanto RSE como el Supervisor de trabajos JES deben utilizar el mismo ID de aplicación (APPLID). Por omisión, ambos servidores utilizan FEKAPPL como APPLID, pero esto puede verse modificado por la directiva APPLID de rsed.envvars para RSE y de FEJJCNFG para el Supervisor de trabajos JES.
No debe utilizar OMVSAPPL como ID de aplicación porque abrirá la clave secreta a la mayoría de aplicaciones z/OS UNIX. Tampoco debe utilizar el ID de aplicación MVS predeterminado, que es MVS seguido por el ID SMF del sistema, porque esto abrirá la clave secreta a la mayoría de aplicaciones MVS (incluyendo trabajos por lotes de usuarios).
La unidad más pequeña de indicación de fecha y hora del PassTicket es de 1 segundo. Esto implica que todos los PassTicket generados en un mismo segundo por la misma aplicación para el mismo ID de usuario serán idénticos. Esto, junto con el software de seguridad de z/OS gestionando los PassTicket como contraseñas de un solo uso, genera un problema para Developer for System z durante el inicio de sesión, ya que harán falta varios PassTickets en un mismo segundo. Por lo tanto, Developer for System z precisa de un distintivo en las definiciones de PassTicket que permita la reutilización de los PassTicket generados.
Atención: La solicitud de conexión del cliente fallará si los PassTickets no están configurados correctamente.
|
Developer for System z da soporte a los registros de auditoría de acciones gestionadas por el daemon RSE. Los registros de auditoría se almacenan como archivos de texto en el directorio de registro del daemon, utilizando el formato CSV (valores separados por comas).
Puede utilizarse el mandato de operador modify switch para pasar manualmente a un nuevo archivo de registro de auditoría, como se indica en "Mandatos de operador" en la publicación Guía de configuración de host (SC11-3660).
Se envía un mensaje de aviso a la consola cuando el sistema de archivos que contiene los archivos de registro de auditoría se está quedando sin espacio libre. Este mensaje de consola (FEK103E) se repite regularmente hasta que se ha resuelto el problema de falta de espacio.
Un archivo de registro de auditoría nuevo se inicia después de un tiempo predeterminado o cuando se emite el mandato de operador modify switch. El archivo de registro antiguo se guarda como audit.log.aaaammdd.hhmmss, donde aaaammdd.hhmmss es la fecha/indicación de fecha y hora de cierre de los registros. La fecha/indicación de fecha y hora del sistema asignada al archivo indica la creación del archivo de registro. La combinación de las dos fechas muestra el período de tiempo cubierto por este archivo de registro de auditoría.
Las directivas audit.action* en rsed.envvars le permiten especificar una salida de usuario (script de shell de z/OS UNIX, REXX de z/OS UNIX o programa de z/OS UNIX), que invocará RSE cuando se cierre una anotación de auditoría. Esta salida de usuario podrá así procesar los datos dentro de la anotación de auditoría.
Los archivos de anotación de auditoría tienen la máscara de bit de permiso 640 (-rw-r-----), si no la cambia la directiva audit.log.mode en rsed.envvars. Esto quiere decir que el propietario (uid de z/OS UNIX del daemon RSE) tiene acceso de grabación y lectura, y el grupo del propietario (predeterminado) tiene acceso de lectura. Todos los demás intentos de acceso se denegarán, a menos que los realice un superusuario (UID 0) o alguien con permiso suficiente sobre el perfil SUPERUSER.FILESYS de la clase de seguridad UNIXPRIV.
aaaa/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
[,additional_information]]
aaaa/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n…
Developer for System z permite a los clientes acceder al spool de JES por medio del Supervisor de trabajos JES. El servidor proporciona limitaciones básicas de acceso, que pueden ampliarse con las características estándar de protección de archivos de spool de su producto de seguridad. Las acciones del operador (Retener, Liberar, Cancelar y Depurar) en los archivos de spool se realizan por medio de la consola de EMCS, para la que deben configurarse permisos condicionales.
El supervisor de trabajos JES no proporciona a los usuarios de Developer for System z acceso de operador pleno al spool JES. Sólo están disponibles los mandatos Retener, Liberar, Cancelar y Depurar, y, por omisión, sólo para los archivos de spool propiedad del usuario. Para emitir los mandatos, se selecciona la opción pertinente en la estructura de menús del cliente (no hay indicador de mandatos). El ámbito de los mandatos puede ampliarse utilizando perfiles de seguridad para definir para qué trabajos están disponibles los mandatos.
Parecido a la acción de SDSF SJ, el Supervisor de trabajos JES también soporta el mandato Mostrar JCL para recuperar el JCL que creó la salida del trabajo seleccionado y visualizarlo en una ventana de editor. El Supervisor de trabajos JES recupera el JCL de JES y lo convierte en una función útil para los casos en que no se puede ubicar el miembro de JCL fácilmente.
Acción | JES2 | JES3 |
---|---|---|
Retener | $Hx(idtrabajo) con x = {J, S o T} |
*F,J=idtrabajo,H |
Liberar | $Ax(idtrabajo) con x = {J, S o T} |
*F,J=idtrabajo,R |
Cancelar | $Cx(idtrabajo) con x = {J, S o T} |
*F,J=jobid,C |
Purgar | $Cx(jobid),P con x = {J, S o T} |
*F,J=idtrabajo,C |
Mostrar JCL | no aplicable | no aplicable |
Por omisión, los mandatos de JES disponibles listados en la Tabla 1 están limitados a los trabajos que son propiedad del usuario. Esto puede cambiarse mediante la directiva LIMIT_COMMANDS, como se describe en el apartado "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" de la Guía de configuración de host (SC11-3660).
Propietario del trabajo | ||
---|---|---|
LIMIT_COMMANDS | Usuario | Otros |
USERID (valor predeterminado) | Permitido | No permitido |
LIMITED | Permitido | Permitido sólo si lo permiten explícitamente los perfiles de seguridad |
NOLIMIT | Permitido | Permitido si lo permiten los perfiles de seguridad o cuando la clase JESSPOOL no está activa |
JES utiliza la clase JESSPOOL para proteger los conjuntos de datos SYSIN/SYSOUT. Parecido a SDSF, el Supervisor de trabajos JES amplía la utilización de la clase JESSPOOL para proteger también los recursos de trabajo.
Mandato | Perfil JESSPOOL | Acceso necesario |
---|---|---|
Retener | nodeid.userid.jobname.jobid | ALTER |
Liberar | nodeid.userid.jobname.jobid | ALTER |
Cancelar | nodeid.userid.jobname.jobid | ALTER |
Purgar | nodeid.userid.jobname.jobid | ALTER |
Mostrar JCL | nodeid.userid.jobname.jobid.JCL | READ |
idnodo | ID del nodo NJE del subsistema JES destino |
idusuario | ID de usuario local del propietario del trabajo |
nombretrabajo | Nombre del trabajo |
idtrabajo | ID del trabajo JES |
SI la clase JESSPOOL no está activa, se produce un comportamiento diferente para los valores LIMITED y NOLIMIT de LIMIT_COMMANDS, como se describe en la sección "tabla de matriz de permisos del mandato LIMIT_COMMANDS" en "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" de la publicación Guía de configuración de host (SC11-3660). El comportamiento es idéntico si JESSPOOL está activa, ya que, por omisión, la clase deniega el permiso si un perfil no está definido.
La segunda fase de la seguridad de mandatos de spool JES, una vez especificados los destinos permitidos, incluye los permisos necesarios para ejecutar realmente el mandato de operador. Las comprobaciones de seguridad de JES y z/OS aplican esta autorización de ejecución.
Tenga en cuenta que Mostrar JCL no es un mandato de operador igual que el resto de mandatos del supervisor de trabajos JES (Retener, Liberar, Cancelar y Depurar), de manera que las limitaciones en la lista siguiente no son de aplicación porque no hay ninguna comprobación de seguridad más.
El Supervisor de trabajos JES emite todos los mandatos de operador de JES solicitados por un usuario por medio de una consola de EMCS ampliada (EMCS), cuyo nombre está controlado por la directiva CONSOLE_NAME, tal como se describe en el apartado "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" de la Guía de configuración de host (SC11-3660).
El Supervisor de trabajos JES permite definir cuánta autoridad se otorga a la consola EMCS con la directiva LIMIT_CONSOLE, tal como se documenta en "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" in la Guía de configuración de host SC11-3660-07 (SC23-7658).
LIMIT_CONSOLE | Perfil activo en la clase OPERCMDS | No hay ningún perfil activo en la clase OPERCMDS |
---|---|---|
LIMITED (predeterminado) | Permitido si está permitido por el perfil de seguridad | No permitido |
NOLIMIT | Permitido si está permitido por el perfil de seguridad | Permitido |
El software de seguridad impide la asunción de identidad del servidor Supervisor de trabajos JES creando una consola JMON desde una sesión TSO. Aunque la consola se puede crear, el punto de entrada es distinto (supervisor de trabajos JES versus TSO). Los mandatos JES emitidos desde esta consola fallarán la comprobación de seguridad, si la seguridad está configurada según se describe en esta publicación.
Para obtener más información sobre la protección de los mandatos de operador, consulte el manual Security Server RACF Security Administrator's Guide (SA22-7683).
Por omisión, el Supervisor de trabajos JES permite acceder a todos los archivos de spool. Esto puede cambiarse mediante la directiva LIMIT_VIEW, como se describe en la sección "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" de la publicación Guía de configuración de host (SC11-3660).
Propietario del trabajo | ||
---|---|---|
LIMIT_VIEW | Usuario | Otros |
USERID | Permitido | No permitido |
NOLIMIT (valor predeterminado) | Permitido | Permitido si lo permiten los perfiles de seguridad o cuando la clase JESSPOOL no está activa |
Para limitar a los usuarios de forma que solo utilicen sus propios trabajos en el spool de JES, defina la sentencia "LIMIT_VIEW=USERID" en el archivo de configuración del supervisor de trabajos JES, FEJJCNFG. Si los usuarios necesitan acceso a un rango de trabajos más amplio, pero no a todos, utilice las características de protección de archivo de spool estándar de su producto de seguridad, como la clase JESSPOOL.
Al definir protección adicional, tenga presente que el supervisor de trabajos JES utiliza SAPI (interfaz de programación de aplicaciones SYSOUT) para acceder al spool. Ello implica que el usuario necesita como mínimo el acceso de actualización (UPDATE) a los archivos de spool, incluso para la función de examen. Este requisito no es necesario si se ejecuta z/OS 1.7 (z/OS 1.8 para JES3) o superior. En este caso, el permiso de lectura (READ) es suficiente para la función de examen.
Para obtener más información sobre la protección del archivo spool de JES, consulte el manual Security Server RACF Security Administrator's Guide (SA22-7683).
La comunicación externa (cliente-host) con RSE puede cifrarse mediante SSL (Capa de sockets seguros) o TLS (Seguridad de la capa de transporte). Esta característica está inhabilita por omisión y está controlada por los valores de ssl.properties. Consulte la sección "(Opcional) ssl.properties, cifrado SSL de RSE" en la publicación Guía de configuración de host (SC11-3660).
El daemon RSE y el servidor RSE soportan distintos mecanismos para almacenar certificados debido a las diferencias de su arquitectura. Esto hace que las definiciones y certificados SSL sean necesarias tanto para el daemon RSE como para el servidor RSE. Se puede utilizar un certificado compartido si el daemon RSE y el servidor RSE utilizan el mismo método de gestión de certificados.
Almacenamiento de certificados | Creado y gestionado por | Daemon RSE | servidor RSE |
---|---|---|---|
anillo de claves | producto de seguridad compatible con SAF | soportado | soportado |
base de datos de claves | gskkyman de z/OS UNIX | soportado | / |
almacén de claves | Keytool de Java | / | soportado |
Los anillos de claves compatibles con SAF puede almacenar la clave privada del certificado en la base de datos de seguridad o mediante el ICSF (recurso de servicio criptográfico integrado), la interfaz al hardware criptográfico de System z.
Se recomienda el ICSF para el almacenamiento de claves privadas relacionadas con certificados digitales, ya que es una solución más segura que la gestión de claves privadas sin ICSF. ICSF asegura que las claves privadas se cifran con la clave maestra de ICSF y que el acceso a ellas está controlado por los recursos generales de las clases de seguridad CSFKEYS y CSFSERV. Además, el rendimiento operativo mejora porque ICSF utiliza el hardware Coprocesador criptográfico. Consulte Cryptographic Services ICSF Administrator's Guide (SA22-7521) para obtener más detalles sobre ICSF y cómo controlar qué usuarios pueden utilizar los servicios y claves criptográficas.
El daemon RSE utiliza funciones de SSL del sistema para gestionar las comunicaciones cifradas con SSL. Ello implica que SYS1.SIEALNKE debe estar controlado por programa por su software de seguridad y disponible para RSE a través de la directiva LINKLIST o STEPLIB en rsed.envvars.
La variable DSTORE_SSL_ALGORITHM de la directiva _RSE_JAVAOPTS de rsed.envvars permite elegir entre el método de cifrado SSL y su eventor TLS, tal como se documenta en "Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS" en la Guía de configuración de host SC11-3660 (SC23-7658).
Consulte Configurar SSL y autenticación de X.509 para obtener más detalles sobre cómo activar SSL para Developer for System z.
De forma predeterminada, el daemon RSE se basa en valores predeterminados System SSL para protocolos de cifrado soportados y definiciones de paquete de cifrado. Puede alterar estos valores predeterminados especificando las variables de entorno GSK_PROTOCOL_* y GSK_V3_CIPHER_SPECS* en rsed.envvars. Para obtener más información sobre estas variables de entorno, consulte la publicación Cryptographic Services System SSL Programming (SC24-5901).
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Dirección De entrada
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Conjunto de claves dbgmgr.racf
# El gestor de depuración debe poseer el conjunto de claves
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled Activado
Rastreo 2
}
El daemon RSE admite que los usuarios se autentiquen con un certificado X.509. El uso de una comunicación cifrada con SSL es un requisito previo para utilizar esta función, dado que es una extensión de la autenticación de host con un certificado utilizado en SSL.
El daemon RSE inicia el proceso de autenticación de cliente validando el certificado de cliente. Algunos de los aspectos clave que se comprueban son las fechas de validez del certificado y la fiabilidad de la autoridad certificadora (CA) utilizada para la firma del certificado. Opcionalmente, también se puede consultar una Lista de certificados revocados (CLR) (externa).
Una vez el daemon RSE ha validado el certificado, este es procesado para su autenticación. El certificado pasa a su producto de seguridad para que lo autentique, a menos que la directiva de rsed.envvars enable.certificate.mapping tenga un valor false, en cuyo caso el daemon RSE se encargará de la autenticación.
Si se realiza con éxito, el proceso de autenticación determinará el ID de usuario que deberá utilizarse para esta sesión; posteriormente, el daemon RSE lo probará para asegurar que es adecuado para el sistema host donde se está ejecutando el daemon RSE.
La última comprobación (que realizar para todos los mecanismos de autenticación, no sólo para los certificados X.509) verifica que el ID de usuario puede utilizar Developer for System z.
Si está familiarizado con las clasificaciones de seguridad SSL utilizadas por TCP/IP, la combinación de estos pasos de validación coinciden con las especificaciones del “Nivel 3 de autenticación de cliente” (el nivel más alto disponible).
Parte del proceso de validación del certificado incluye la comprobación de que el certificado ha sido firmado por una autoridad certificadora (CA) de confianza. Para ello, el daemon RSE debe tener acceso a un certificado que identifique a la CA.
Al utilizar la base de datos de claves gskkyman para su conexión SSL, debe añadirse a la base de datos de claves el certificado de CA.
Consulte el manual Security Server RACF Command Language Reference (SA22-7687) para obtener más información sobre el mandato RACDCERT.
Atención: si confía más en el daemon RSE que en su software de seguridad para autenticar un usuario, debe tener cuidado de no mezclar las CA con los estados TRUST y HIGHTRUST en su anillo de claves de SAF ni en su base de datos de claves de gskkyman. El daemon RSE no los puede diferenciar, por lo que los certificados firmados por una CA con estado TRUST serán válidos para la autenticación del ID de usuario. |
Consulte el manual Cryptographic Services System Secure Sockets Layer Programming (SC24-5901) para obtener más información sobre estas y otras variables de entorno utilizadas por SSL del sistema de z/OS.
RACF lleva a cabo varias comprobaciones para autenticar un certificado y devolver el ID de usuario asociado. Tenga en cuenta que puede que otros productos de seguridad lo hagan de manera distinta. Consulte la documentación de su producto de seguridad para obtener información adicional sobre la función initACEE utilizada para llevar a cabo la autenticación (modalidad de consulta).
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1}
HostIdMappings::= SET OF HostIdMapping
HostIdMapping::= SEQUENCE{
hostName IMPLICIT[1] IA5String,
subjectId IMPLICIT[2] IA5String,
proofOfIdPossession IdProof OPTIONAL
}
IdProof::= SEQUENCE{
secret OCTET STRING,
encryptionAlgorithm OBJECT IDENTIFIER
}
Consulte la publicación Security Server RACF Security Administrator’s Guide (SA22-7683) para obtener más información sobre los certificados X.509, sobre cómo los gestiona RACF y sobre cómo definir filtros de nombres de certificado. Consulte el manual Security Server RACF Command Language Reference (SA22-7687) para obtener más información sobre el mandato RACDCERT.
Developer for System z puede llevar a cabo la autenticación básica de certificados X.509 sin basarse en su producto de seguridad. La autenticación llevada a cabo por el daemon RSE requiere que se definan un ID de usuario y un nombre de host en una extensión de certificado, y solamente se activa si la directiva enable.certificate.mapping de rsed.envvars tiene el valor de FALSE.
Esta función debe utilizarse cuando su producto de seguridad no admita la autenticación de un usuario en base a un certificado X.509, o bien si en el caso que su certificado fallara la(s) prueba(s) realizadas por el producto de seguridad (por ejemplo, si el certificado tiene un identificador erróneo para la extensión de HostIdMappings y no hay ninguna definición ni filtro de nombre en DIGTCERT).
El cliente consultará al usuario qué identificador de extensión (OID) utilizar, que es, de forma predeterminada, el OID de HostIdMappings {1 3 18 0 2 18 1}.
El daemon RSE le extraerá el ID de usuario y el nombre de host utilizando el formato de la ampliación de HostIdMappings. Este formato se describe en Autenticación del software de seguridad.
Atención: Es decisión del administrador de seguridad asegurar que todas las CA reconocidas por el daemon RSE sean de confianza total, dado que el daemon RSE no puede comprobar si la persona que ha firmado el certificado de cliente es de confianza total o es simplemente de confianza. Consulte Validación de la autoridad certificadora (CA) para obtener más información sobre los certificados de CA accesibles.
|
Consulte la publicación Communications Server IP Configuration Guide (SC31-8775) para obtener más información acerca del control de acceso a la red mediante comprobaciones de POE.
Los clientes de Developer for System z versión 8.5.1 y superior pueden comprobar la autorización de acceso a perfiles de seguridad SAF y, en función del resultado, habilitar o inhabilitar la función relacionada para el usuario.
Developer for System z verifica los permisos de acceso a los perfiles listados en la Tabla 7 para determinar qué opciones deben estar habilitadas o inhabilitadas para el usuario.
Perfil FACILITY | Longitud fija | Acceso necesario | Resultado |
---|---|---|---|
FEK.USR.OFF.REMOTECOPY.MVS.sysname | 27 | READ | El cliente inhabilita copiar y las funciones relacionadas para los conjuntos de datos MVS |
El valor de sysname coincide con el nombre de sistema del sistema de destino.
La columna "Longitud fija" indica la longitud de la parte fija del perfil de seguridad relacionado.
De forma predeterminada, Developer for System z espera que los perfiles FEK.* estén en la clase de seguridad FACILITY. Tenga en cuenta que los perfiles en la clase FACILITY tienen 39 caracteres como máximo. Si la suma de la longitud de la parte fija de perfil (FEK.USR.<key>) y la longitud de la parte de perfil específica del sitio (sysname) sobrepasa este número. puede colocar los perfiles en otra clase e instar a Developer for System z a que utilice esta clase en su lugar. Para ello, active _RSE_FEK_SAF_CLASS en rsed.envvars y proporcione el nombre de clase que quiera.
RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Cuando los usuarios tienen acceso de lectura (READ) al perfil FEK.USR.OFF.REMOTECOPY.MVS.sysname, su versión de cliente de Developer for System z 8.5.1 y superior inhabilitaran las acciones arrastrar, copiar, guardar como y trabajar sin conexión para los conjuntos de datos MVS. El resultado es que los usuarios pueden acceder a los conjuntos de datos en este sistema, pero los usuarios no pueden crear una copia local de un conjunto de datos en su estación de trabajo. Esto ayuda a prevenir la exposición de información confidencial si la estación de trabajo local se pierde o es robada.
Los clientes de Developer for System z versión 8.0.1 y posteriores pueden tomar la información de actualización y de los archivos de configuración del cliente desde el host cuando se conectan, asegurando que todos los cliente tienen valores comunes y que están actualizados.
Desde la versión 8.0.3, el administrador del cliente puede crear varios conjuntos de configuraciones de cliente y varios escenarios de actualización del cliente para ajustar las necesidades de distintos grupos de desarrolladores. Esto permite a los usuarios recibir una configuración personalizada basada en un criterio como la pertenencia de un grupo LDAP o permiso para un perfil de seguridad.
Cuando utilice definiciones en su base de datos de seguridad como mecanismo de selección (el valor de SAF se especifica para las directivas en pushtoclient.properties), Developer for System z comprueba los permisos de acceso a los perfiles listados en la Tabla 8 para determinar a qué grupo de desarrolladores pertenece el usuario y si el usuario tiene permiso para rechazar actualizaciones.
Perfil FACILITY | Longitud fija | Acceso necesario | Resultado |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | El cliente acepta actualizaciones de configuración para el grupo especificado |
FEK.PTC.PRODUCT. |
24 | READ | El cliente acepta actualizaciones de producto para el grupo especificado |
FEK.PTC.REJECT.CONFIG. |
30 | READ | El usuario puede rechazar actualizaciones de configuración |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | El usuario puede rechazar actualizaciones de producto |
El valor de devgroup coincide con el nombre de grupo asignado a un grupo específico de desarrolladores. Tenga en cuenta que el nombre de grupo es visible en clientes de Developer for System z.
El valor de sysname coincide con el nombre de sistema del sistema de destino.
La columna "Longitud fija" indica la longitud de la parte fija del perfil de seguridad relacionado.
De forma predeterminada, Developer for System z espera que los perfiles FEK.* estén en la clase de seguridad FACILITY. Tenga en cuenta que los perfiles en la clase FACILITY tienen 39 caracteres como máximo. Si la suma de la longitud de la parte fija del perfil (FEK.PTC.<key>) y la longitud de la parte del perfil específica del sitio (sysname o sysname.devgroup) sobrepasa este número, puede colocar los perfiles en otra clase e indicar a Developer for System z que utilice esta clase en su lugar. Para ello, active _RSE_FEK_SAF_CLASS en rsed.envvars y proporcione el nombre de clase que quiera.
Tenga en cuenta que el administrador del cliente debe estar en la lista de acceso de perfiles FEK.PTC.*.ENABLED.* para definir y gestionar los metadatos Envío a cliente relacionados. Esto implica que los perfiles se deben definir con (al menos) el administrador de cliente en la lista de acceso para poder implementar el Envío a cliente con soporte para grupo.
Para obtener más información sobre la habilitación de varios soportes de grupo, consulte "(Opcional) pushtoclient.properties, control del cliente basado en host" en la publicación Guía de configuración de host SC11-3660 (SC23-7658). Para obtener más información sobre conceptos e implementación del Envío a cliente, consulte Consideraciones sobre envío a cliente.
Los directorios de registro y los archivos de registro que ha creado Developer for System z tienen, de forma predeterminada, permisos de acceso seguros donde sólo el propietario tiene acceso (lectura y escritura). Para los registros de servidor (y auditoría) el propietario es el ID de usuario de tarea iniciada RSED. Para registros de usuario el propietario es el ID de usuario proporcionado por el usuario final durante el inicio de sesión. La directiva log.file.mode en rsed.envvars se puede utilizar para establecer permisos de acceso diferentes. Tenga en cuenta que los permisos de acceso para los archivos de auditoría están controlados por separado y se establecen con la directiva audit.log.mode en rsed.envvars.
Antes de escribir en un directorio de registro, Developer for System z validará la propiedad del archivo y fallará la escritura si un usuario diferente es propiedad del archivo. Este comportamiento es nuevo en la versión 9.1.0 y es posible que necesite modificar una estructura de archivos de registro existente. La directiva log.secure.mode en rsed.envvars se puede utilizar para inhabilitar la comprobación de propiedad.
El JCL de ejemplo FEKPBITS se puede utilizar para convertir los permisos de acceso y de propiedad de una infraestructura de archivo de registro existente. FEKPBITS se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación cuando ha personalizado y sometido el trabajo FEK.SFEKSAMP(FEKSETUP). Para obtener más información, consulte "Configuración de personalización" en la Guía de configuración del host (SC11-3660).
La tarea iniciada RSED da soporte al mandato de operador MODIFY LOGS para recopilar registros de host de Developer for System z e información de configuración. Los datos recopilados se sitúan en el archivo z/OS UNIX, $TMPDIR/feklogs%sysname.%jobname, donde $TMPDIR es el valor de la directiva TMPDIR en rsed.envvars (/tmp predeterminado), %sysname es el nombre del sistema z/OS y %jobname es el nombre de la tarea iniciada RSED.
Developer for System z consultará el producto de seguridad para permisos de acceso a perfiles FEK.CMD.LOGS.** para determinar si el peticionario tiene permiso para recopilar los registros especificados. De forma predeterminada, el peticionario es el ID de usuario de la tarea iniciada RSED, a menos que se especifique la opción OWNER. Sólo el peticionario tiene acceso al archivo que contiene los datos recopilados.
Perfil FACILITY | Longitud fija | Acceso necesario | Resultado |
---|---|---|---|
FEK.CMD.LOGS.AUDIT.jobname | 19 | READ | El peticionario puede recopilar registros de auditoría de nombre de trabajo |
FEK,CMD.LOGS.SERVER.jobname | 20 | READ | El peticionario puede recopilar registros de servidor de nombre de trabajo |
FEK,CMD.LOGS.USER.userid | 18 | READ | El peticionario puede recopilar registros de usuario de ID de usuario |
FEK,CMD.LOGS.OWNER.userid | 19 | READ | El peticionario cambia del ID de usuario de la tarea iniciada RSED al ID de usuario |
El valor jobname coincide con el nombre de la tarea iniciada RSED. El valor userid coincide con un ID de usuario válido.
La columna "Longitud fija" indica la longitud de la parte fija del perfil de seguridad relacionado.
De forma predeterminada, Developer for System z espera que los perfiles FEK.* estén en la clase de seguridad FACILITY. Tenga en cuenta que los perfiles en la clase FACILITY tienen 39 caracteres como máximo. Si la suma de la longitud de la parte fija del perfil (FEK.CMD.LOGS.<key>) y la longitud de la parte del perfil específica del sitio (jobname o userid) sobrepasa este número, puede colocar los perfiles en otra clase e indicar a Developer for System z que utilice esta clase en su lugar. Para ello, active _RSE_FEK_SAF_CLASS en rsed.envvars y proporcione el nombre de clase que quiera.
Las violaciones de acceso se notifican mediante el mensaje de consola FEK302E.
Las definiciones de seguridad de ejemplo siguientes permiten a todo el mundo recopilar registros de host, pero sólo el grupo SYSPROG puede recopilar datos de auditoría:
RDEFINE FACILITY (FEK.CMD.LOGS.**) UACC(READ) -
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
RDEFINE FACILITY (FEK.CMD.LOGS.AUDIT.**) UACC(NONE) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
PERMIT FEK.CMD.LOGS.AUDIT.** CLASS(FACILITY) -
ID(SYSPROG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
El mandato de operador MODIFY LOGS utiliza el ID de usuario de la tarea iniciada RSED para recopilar registros de host e información de configuración y, de forma predeterminada, los archivos de registro de usuario se crean con permisos de acceso de archivos (el único que tiene acceso es el propietario). Para poder recopilar archivos de registro de usuario seguros, se debe otorgar permiso al ID de usuario de tarea iniciada RSED para leerlos.
El argumento OWNER del mandato del operador MODIFY LOGS hace que el ID de usuario especificado se convierta en el propietario de los datos recopilados. Para poder cambiar la propiedad, el ID de usuario de tarea iniciada RSED debe tener permiso para utilizar el servicio CHOWN de z/OS UNIX.
Hay tres formas de que estos permisos se suministren al ID de usuario de la tarea iniciada RSED. En orden de preferencia, son
La clase UNIXPRIV contiene perfiles que permiten al administrador de seguridad otorgar selectivamente permisos z/OS UNIX relacionados especiales, en lugar de otorgar todos los permisos z/OS UNIX relacionados con el procedimiento de superusuario.
Perfil | Permiso | Resultado |
---|---|---|
SUPERUSER.FILESYS | READ | Se permite al usuario leer cualquier archivo o directorio. |
SUPERUSER.FILESYS.ACLOVERRIDE | READ | Sólo se requiere permiso si ACLOVERRIDE ya está definido. Permite al usuario leer leer cualquier archivo o directorio, independientemente de las definiciones ACL. |
SUPERUSER.FILESYS.CHOWN | READ | Se permite al usuario cambiar el propietario de cualquier archivo o directorio. |
Cuando el ID de usuario de tarea iniciada RSED tiene permiso READ al perfil BPX.SUPERUSER en la clase FACILITY, puede crear temporalmente un superusuario z/OS UNIX, para quien los permisos de archivos z/OS UNIX no cuentan.
Cuando el ID de usuario de tarea iniciada RSED tiene UID 0 especificado en su segmento OMVS, es un superusuario z/OS UNIX, para quien no cuentan los permisos de acceso de archivos z/OS UNIX. No obstante, este procedimiento no es aconsejable puesto que UID 0 es probablemente un UID compartido y es aconsejable dar al ID de usuario de tarea iniciada RSED un UID exclusivo debido a otros permisos otorgados al ID. (Por ejemplo, los administradores de z/OS UNIX requieren UID 0 para determinadas tareas de gestión del sistema.)
El Depurador integrado opcional requiere que los usuarios dispongan de suficientes permisos de acceso a los perfiles de seguridad especificados. Si el usuario no dispone del permiso necesario, la sesión de depuración no se iniciará.
Developer for System z verifica el acceso a los perfiles listados en la Tabla 10 para determinar que permisos de depuración se han concedido.
Perfil FACILITY | Acceso necesario | Resultado |
---|---|---|
AQE.AUTHDEBUG.STDPGM | READ | El usuario puede depurar aplicaciones sobre el estado del problema |
AQE.AUTHDEBUG.AUTHPGM | READ | El usuario puede depurar aplicaciones sobre el estado del problema y aplicaciones autorizadas |
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
El depurador integrado opcional puede depurar transacciones CICS. Consulte Depuración de transacción CICS para obtener más detalles.
Developer for System z permite, mediante el Gestor de despliegue de aplicaciones, que los administradores de CICS controlen qué definiciones de recursos CICS puede editar el desarrollador, sus valores predeterminados y la visualización de una definición de recurso CICS por medio del servidor CRD (definiciones de recursos CICS). Consulte la sección Consideraciones de CICSTS para obtener más información acerca de las definiciones de recursos CICS TS necesarias.
El conjunto de datos VSAM del repositorio del servidor CRD contiene todas las definiciones de recurso predeterminadas y, por tanto, debe protegerse contra actualizaciones, pero los desarrolladores deben poder leer los valores almacenados en él.
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Cuando se conecta la transacción, la comprobación de la seguridad de recursos CICS, si está habilitada, se asegura de que el ID de usuario tiene autorización para ejecutar el ID de transacción.
El cliente Gestor de despliegue de aplicaciones utiliza la interfaz RESTful o los servicios Web de CICS TS para invocar el servidor CRD. El uso de SSL para esta comunicación está controlado por la definición CICS TS TCPIPSERVICE, según se indica en la documentación de RACF Security Guide for CICS TS.
El servicio SCLM Developer Toolkit ofrece funciones de seguridad opcionales para las funciones de construcción, promoción y despliegue.
Si el administrador de SCLM habilita la seguridad para una función, se realizan llamadas SAF para comprobar la autorización para ejecutar la función protegida con el ID de usuario del llamante o uno subordinado.
Consulte la Guía del administrador de SCLM Developer Toolkit, SC11-3815 (SC23-9801), para obtener más información acerca de las definiciones de seguridad de SCLM necesarias.
La primera vez que un espacio de direcciones insta a RACF a acceder a una clase de recurso que no está en RACLIST (almacenada en memoria), como por ejemplo la clases DATASET, RACF recuperará y almacenará todos los perfiles genéricos relacionados en el espacio de direcciones del usuario, en una lista conocida como GATE (Entrada de tabla de anclas genéricas). Hasta z/OS 1.12, RACF mantiene cuatro anclase genéricas para cada espacio de direcciones y cuatro para cada TCB de MVS que tiene su propio ACEE. Cuando se han utilizado las cuatro, RACF sustituye la referida menos recientemente cuando entra una nueva.
Si los usuarios acceden frecuentemente a más de cuatro calificadores de alto nivel de conjuntos de datos, las agrupaciones de hebras de RSE (que sirven a varios usuarios que utilizan hebras con ACEEs específicas de usuario) pueden experimentar la operación de desecho de GATE ya que RACF debe rotar las entradas nuevas a través de las ranuras de ancla disponibles.
En z/OS 1.12, RACF introdujo la opción GENERICANCHOR del mandato SET que permite aumentar el tamaño de la tabla. Esto se puede establecer para todo el sistema o para cada nombre de trabajo.
Developer for System z utiliza servicios del kernel de z/OS UNIX, como pthread_security_np() y __passwd(), que utilizan el servicio de seguridad InitACEE, que tiene como resultado bloques de control de seguridad "gestionados por ACEE". Su producto de seguridad pone un ACEE (Accessor Environment Element) gestionado en memoria caché, y dicho producto no tendrá en cuenta determinados cambios (como cambios de contraseña fuera de Developer for System z) hasta que transcurra el tiempo de espera de la memoria caché. (La caducidad puede tardar varios minutos).
Actualice la memoria caché del ACEE gestionado tras los cambios de seguridad para asegurase de que Developer for System z utiliza los datos nuevos.
RACF puede ahorrar entornos ACEE (Accessor Environment Elements) utilizando el recurso VLF (Virtual Lookaside Facility) y recuperarlos para utilizarlos más tarde. Developer for System z solicita al software de seguridad que cree varios entornos de seguridad (ACEE) para el mismo usuario (uno para cada hebra específica de usuario en la agrupación de hebras RSE) y, por consiguiente, se puede beneficiar del almacenamiento en memoria caché ACEE.
Para obtener mas información sobre el almacenamiento en memoria caché ACEE, consulte “ACEEs and VLF considerations” en la publicación Security Server RACF System Programmer's Guide (SA22-7681).
Existen varios archivos de configuración de Developer for System z, cuyas directivas afectan a la configuración de seguridad y auditoría. En base a la información de este capítulo, el administrador de seguridad y el programados de sistemas pueden decidir cuáles deberían ser los valores para las directivas siguientes.
Definir en qué trabajos pueden realizarse las acciones (excluidas las acciones examinar y someter). Para obtener más información, consulte Acciones en trabajos - limitaciones de destino.
Definir el nivel de autorización de la consola EMCS utilizada para ejecutar acciones. Para obtener más información, consulte Acciones en trabajos - limitaciones de destino.
Definir qué archivos de spool pueden examinarse. Para obtener más información, consulte Acceso a los archivos de spool.
Definir si se puede acceder al Supervisor de trabajos JES desde fuera de este sistema z/OS. Para obtener más información, consulte el apartado FEJJCNFG, archivo de configuración del supervisor de trabajos JES del capítulo Personalización básica de la Guía de configuración de host SC11-3660 (SC23-7658).
ID de aplicación utilizado para la creación/validación de PassTicket. Para obtener más información, consulte Uso de PassTickets.
Clase de seguridad que contiene perfiles FEK.**. Para obtener más información, consulte Grupos de desarrollador Envío a cliente and Alterar las funciones de cliente.
Denegar a los usuarios que guarden la contraseña del host en el cliente. Para obtener más información, consulte la sección "Definición de parámetros de inicio de Java adicionales con _RSE_JAVAOPTS" de la publicación Guía de configuración de host (SC11-3660).
Temporizador para desconectar a los clientes desocupados. Para obtener más información, consulte la sección "Definición de parámetros de inicio de Java adicionales con _RSE_JAVAOPTS" de la publicación Guía de configuración de host (SC11-3660).
ID de aplicación utilizado para la creación/validación de PassTicket. Para obtener más información, consulte Uso de PassTickets.
Habilitar la comprobación de puerto de entrada. Para obtener más información, consulte Comprobación de puerto de entrada (POE).
Seleccionar SSL o TLS como método de cifrado de comunicaciones. Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
Utilizar su producto de seguridad para autenticar a los usuarios con un certificado X.509. Para obtener más información, consulte Autenticación de cliente mediante certificados X.509.
GSK_LDAP_SERVER=*
GSK_LDAP_PORT={389 | *}
GSK_LDAP_USER=*
GSK_LDAP_PASSWORD=*
Comprobaciones de seguridad adicionales para autenticación de X.509. Para obtener más información, consulte (Opcional) Consulta en una lista de certificados revocados (CRL).
Máscara de permisos de acceso de los directorios y archivos de registro de host.
Comprobaciones de seguridad adicionales (como la propiedad) para directorios y archivos de registro de host.
Vía de acceso que lleva a los archivos de registro de auditoría. Para obtener más información, consulte Registro de auditoría.
Máscara de permisos de acceso de los archivos de registro de auditoría. Para obtener más información, consulte Registro de auditoría.
(_RSE_JAVAOPTS)
-Daudit.action.id=<ID de usuario>
Salida de usuario basada en z/OS UNIX que procesa registros de auditoría. Para obtener más información, consulte Registro de auditoría.
Ubicación del certificado del daemon RSE. Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
Nombre del certificado del daemon RSE. Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
Ubicación del certificado del servidor RSE. Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
Nombre del certificado del servidor RSE. Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
Tipo de almacén de claves utilizado (almacén de claves Java o anillo de claves de SAF). Para obtener más información, consulte Comunicación cifrada con SSL/TLS.
reject.config.updates={true | false | SAF | LDAP}
Control basado en host de archivos de configuración de cliente de Developer for System z. Para obtener más información, consulte Consideraciones sobre envío a cliente.
reject.product.updates={true | false | SAF | LDAP}
Control basado en host de actualizaciones del producto del cliente de Developer for System z. Para obtener más información, consulte Consideraciones sobre envío a cliente.
Personalice y someta el miembro de ejemplo FEKRACF, que contiene mandatos de ejemplo RACF y z/OS UNIX para crear las definiciones básicas de seguridad para Developer for System z.
FEKRACF se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Para obtener más detalles, consulte "Configuración de personalización" en la Guía de configuración de host de IBM Rational Developer for System z.
Consulte la publicación RACF Command Language Reference (SA22–7687), para obtener más información sobre los mandatos RACF.
Las siguientes sesiones describen los pasos necesarios, la configuración opcional y las posibles alternativas.
Descripción |
|
Valor |
---|---|---|
Calificador de alto nivel de producto de Developer for System z |
|
|
Calificador de alto nivel de personalización de Developer for System z |
|
|
Nombre de tarea iniciada del depurador integrado |
|
|
Nombre de tarea iniciada del Supervisor de trabajos JES |
|
|
Nombre de tarea iniciada del daemon RSE |
|
|
ID de aplicación |
|
Atención: Algunos productos, por ejemplo FTP, deben estar controlados por programa si "WHEN PROGRAM" está activo. Debe someter a prueba este control de programa antes de activarlo en un sistema de producción. |
Debe definirse un segmento OVMS de RACF o equivalente que especifique un ID de usuario (UID) de z/OS UNIX válido que no sea cero, un directorio inicial y un mandato de shell para cada usuario de Developer for System z. Su grupo predeterminado también requiere un segmento OMVS con un ID de grupo.
Al utilizar el depurador integrado opcional, el ID de usuario cuya aplicación se está depurando está activo y el grupo predeterminado correspondiente también requiere un segmento OMVS de RACF o equivalente activo.
En los mandatos RACF de ejemplo que figuran a continuación, sustituya los espacios reservados #idusuario, #identificador-usuario, #nombre-grupo e #identificador-grupo por los valores reales:
ALTUSER #idusuario
OMVS(UID(#identif.-usuario) HOME(/u/#idusuario) PROGRAM(/bin/sh) NOASSIZEMAX)
Los siguientes mandatos RACF de ejemplo crean las tareas iniciadas DBGMGR, JMON y RSED, con ID de usuario protegido (STCDBM, STCJMON y STCRSE) y el grupo STCGROUP asignado a los mismos. Sustituya los espacios reservados #id-grupo e #id-usuario-* por identificadores de OMVS válidos.
ADDGROUP STCGROUP OMVS(AUTOGID)
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ – DEBUG MANAGER')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCJMON DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED DBGMGR.* DATA('RDZ – DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR')
STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON')
STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
ALTUSER STCRSE RESTRICTED
Para asegurarse de que los usuarios restringidos no obtengan acceso a los recursos del sistema de archivos de z/OS UNIX mediante los “otros” bits de permiso, defina el perfil RESTRICTED.FILESYS.ACCESS en la clase UNIXPRIV con UACC(NONE). Para obtener más información sobre cómo restringir IDs de usuario, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Atención: Si utiliza IDs de usuario restringidos, añada explícitamente el permiso
para acceder a un recurso utilizando los mandatos PERMIT de TSO o setfacl de
z/OS UNIX.
Los recursos incluyen los recursos en los que la documentación de
Developer
for System z utiliza UACC, como por ejemplo el perfil
** de la clase PROGRAM, o los basados en convenciones comunes de
z/OS UNIX, como por ejemplo que todos los
usuarios tengan permiso de lectura y ejecución sobre las bibliotecas de Java.
Pruebe el acceso antes de activarlo en un sistema de producción.
|
RSE requiere acceso de actualización (UPDATE) al perfil BPX.SERVER para crear o suprimir el entorno de seguridad de la hebra del cliente. Si este perfil no está definido, RSE requiere el UID(0). Este paso es necesario para que los clientes se puedan conectar.
El depurador integrado requiere acceso de actualización (UPDATE) al perfil BPX.SERVER para crear o suprimir el entorno de seguridad de la hebra del cliente. Si este perfil no se ha definido, se requiere UID(0) para el ID de usuario de tarea iniciada STCDBM. Este permiso solo es necesario cuando se utiliza la función de depurador integrado opcional.
Atención: Definir el perfil BPX.SERVER hace que z/OS UNIX como un todo cambie de la seguridad a nivel de UNIX a la seguridad a nivel de z/OS UNIX, la cual es más segura. Este conmutador puede afectar a otras operaciones y aplicaciones de z/OS UNIX. Pruebe la seguridad antes de activarlo en un sistema de producción. Para obtener más información sobre los diferentes
niveles de seguridad, consulte UNIX System Services Planning
(GA22-7800).
|
Los servidores con autorización sobre BPX.SERVER deben ejecutarse en un entorno limpio controlado por programa. Este requisito implica que todos los programas a los que llama RSE también deben estar controlados por programa. Para las bibliotecas de carga MVS, el control de programa se gestiona mediante el software de seguridad. Este paso es necesario para que los clientes se puedan conectar.
Las siguientes bibliotecas adicionales prerrequisito deben estar controladas por programa para dar soporte a la utilización de servicios opcionales. Esta lista no incluye los conjuntos de datos específicos de un producto con el que interactúa Developer for System z, como IBM File Manager.
La contraseña del cliente u otras formas de identificación, como un certificado X.509 sólo se utiliza para verificar la identidad durante la conexión. Después de eso, se utilizan Pases (PassTickets) para mantener la seguridad de las hebras. Este paso es necesario para que los clientes se puedan conectar.
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16))
APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE')
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE soporta el uso de un ID de aplicación distinto de FEKAPPL. Elimine el comentario y personalice la opción "APPLID=FEKAPPL" en rsed.envvars para activar esto, según lo documentado en "Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS" en la Guía de configuración de host de IBM Rational Developer for System z. Las definiciones de clase PTKTDATA deben coincidir con el ID de aplicación real utilizado por RSE.
Atención: La solicitud de conexión del cliente falla si PassTickets no está
configurado correctamente.
|
El mandato MODIFY LOGS del operador utiliza el ID de usuario de tarea iniciada RSED para recopilar registros de host e información de instalación. Y de forma predeterminada, los archivos de registro de usuario se crean con permisos de acceso de archivos (el único que tiene acceso es el propietario). Para poder recopilar archivos de registro de usuario seguros, se debe otorgar permiso al ID de usuario de tarea iniciada RSED para leerlos.
El argumento OWNER del mandato del operador MODIFY LOGS hace que el ID de usuario especificado se convierta en el propietario de los datos recopilados. Para poder cambiar la propiedad, el ID de usuario de tarea iniciada RSED debe tener permiso para utilizar el servicio CHOWN de z/OS UNIX.
Observe que cuando está definido el perfil SUPERUSER.FILESYS.ACLOVERRIDE, los permisos de acceso definidos en ACL (access Control List) tienen prioridad sobre los permisos otorgados a través de SUPERUSER.FILESYS. El ID de usuario de la tarea iniciada RSED necesitará permiso de acceso READ al perfil SUPERUSER.FILESYS.ACLOVERRIDE para eludir las definiciones ACL.
Durante el inicio de sesión de clientes, el daemon RSE verifica que un usuario pueda utilizar la aplicación.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
Los servidores con autorización sobre BPX.SERVER deben ejecutarse en un entorno limpio controlado por programa. Este requisito implica que todos los programas a los que llama RSE también deben estar controlados por programa. Para archivos z/OS UNIX, el control del programa viene gestionado por el mandato extattr. Para ejecutar este mandato, necesita acceso de lectura (READ) a BPX.FILEATTR.PROGCTL en la clase FACILITY o tener el UID(0).
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
El Supervisor de trabajos JES emite todos los mandatos de operador de JES solicitados por un usuario por medio de una consola de EMCS ampliada (EMCS), cuyo nombre está controlado por la directiva CONSOLE_NAME, tal como se describe en el apartado "FEJJCNFG, archivo de configuración del supervisor de trabajos de JES" en IBM Rational Developer for System z - Guía de configuración de host.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Atención: El hecho de definir mandatos JES con el acceso universal
NONE en su software de seguridad puede afectar a otras operaciones y
aplicaciones. Pruebe la seguridad antes de activarlo en un sistema de producción.
|
La Tabla 12 y la Tabla 13 muestran los mandatos de operador emitidos para JES2 y JES3 y los perfiles de seguridad específicos que pueden utilizarse para protegerlos.
Acción | Mandato | Perfil OPERCMDS | Acceso necesario |
---|---|---|---|
Retener | $Hx(jobid) con x = {J, S o T} |
|
UPDATE |
Liberar | $Ax(jobid) con x = {J, S o T} |
|
UPDATE |
Cancelar | $Cx(jobid) con x = {J, S o T} |
|
UPDATE |
Purgar | $Cx(jobid),P con x = {J, S o T} |
|
UPDATE |
Acción | Mandato | Perfil OPERCMDS | Acceso necesario |
---|---|---|---|
Retener | *F,J=idtrabajo,H |
|
UPDATE |
Liberar | *F,J=idtrabajo,R |
|
UPDATE |
Cancelar | *F,J=idtrabajo,C |
|
UPDATE |
Purgar | *F,J=idtrabajo,C |
|
UPDATE |
El software de seguridad impide la asunción de identidad del servidor Supervisor de trabajos JES creando una consola JMON desde una sesión TSO. Aunque la consola se puede crear, el punto de entrada es distinto, supervisor de trabajos JES versus TSO. Los mandatos JES emitidos desde esta consola fallarán la comprobación de seguridad, si la seguridad está configurada según se describe en esta publicación.
Los usuarios requieren acceso READ a uno de los perfiles AQE.AUTHDEBUG.* listados para poder utilizar el depurador integrado para depurar programas de estado del problema. Los usuarios con permiso para el perfil AQE.AUTHDEBUG.AUTHPGM también tienen permiso para depurar programas autorizados APF. Sustituya el espacio reservado #apf con ID de usuario o nombres de grupo RACF válidos para dichos usuarios que pueden depurar programas autorizados.
RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)
SETROPTS RACLIST(FACILITY) REFRESH
El acceso de lectura (READ) para los usuarios y de modificación (ALTER) para los programadores de sistemas es suficiente para la mayoría de conjuntos de datos de Developer for System z. Sustituya el espacio reservado #progsis por identificadores de usuario o nombres de grupo de RACF válidos. Solicite al programador del sistema que ha instalado y configurado el producto los nombres de conjunto de datos correctos. FEK es el calificador de alto nivel predeterminado utilizado durante la instalación y FEK.#CUST es el calificador de alto nivel predeterminado para los conjuntos de datos creados durante el proceso de personalización.
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#desarr.-ram)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#admincics)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
ADDGROUP (FEK)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLMOD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.SQL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKLMOD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.SQL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.SQL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#desarr.-ram)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#admincics)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#ims)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#batch)
SETROPTS GENERIC(DATASET) REFRESH
Utilice los siguientes mandatos de ejemplo para visualizar los resultados de las personalizaciones relacionadas con la seguridad.
Developer for System z utiliza TCP/IP para proporcionar a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. También utiliza TCP/IP para establecer comunicación entre distintos componentes y otros productos.
Tenga en cuenta que la mayoría de funciones de Developer for System z están basadas en z/OS UNIX, por tanto, TCP/IP utilizará la orden de búsqueda de z/OS UNIX para buscar sus archivos de configuración. Consulte Configurar TCP/IP para obtener más información.
La Figura 10 muestra los puertos de TCP/IP que Developer for System z puede utilizar. Las flechas muestran qué parte realiza el enlace (parte de la punta de la flecha) y que parte realiza la conexión.
Si utiliza la sentencia PORT o PORTRANGE en PROFILE.TCPIP para reservar los puertos utilizados por Developer for System z, tenga en cuenta que las hebras activas en una agrupación de hebras de RSE realizarán varios enlaces. El nombre de trabajo de la agrupación de hebras de RSE es RSEDx, donde RSED es el nombre de la tarea iniciada RSE, y x, un número aleatorio de un dígito, por lo que es necesario utilizar comodines en la definición.
PORT 4035 TCP RSED ; Developer for System z - daemon de RSE
PORT 6715 TCP JMON ; Developer for System z - supervisor de trabajos JES
PORT 5335 TCP DBGMGR ; Developer for System z – Integrado
integrado
PORT 5336 TCP DBGMGR ; Developer for System z – Integrado
integrado
PORTRange 8108 11 TCP RSED* ; Developer for System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer for System z - CARMA
CARMA (Common Access Repository Manager) se utiliza para acceder a un CSM ( (Software Configuration Manager) basado en host, como por ejemplo, CA Endevor® SCM. En la mayoría de los casos, como con el daemon RSE, un servidor se enlaza a un puerto y escucha las solicitudes de conexión. Sin embargo, CARMA utiliza otro procedimiento, dado que el servidor CARMA no está activo cuando el cliente inicia la solicitud de conexión.
Cuando el cliente envía una solicitud de conexión, el extractor de CARMA, que está activo como hebra de usuario en una agrupación de hebras RSE, solicitará un puerto efímero o buscará un puerto libre dentro del rango especificado en el archivo de configuración CRASRV.properties y se enlaza a dicho puerto. El extractor inicia entonces el servidor CARMA y pasa el número de puerto, de manera que el puerto sepa a qué puerto conectarse. Cuando el servidor está conectado, el cliente puede mandar solicitudes al servidor y recibir los resultados.
Desde una perspectiva de TCP/IP, RSE (a través del extractor de CARMA) es el servidor que se enlaza al puerto, y el servidor CARMA es el cliente que se conecta.
Si utiliza la sentencia PORT o PORTRANGE en PROFILE.TCPIP para reservar el rango de puertos utilizados por CARMA, debe tener en cuenta que el extractor CARMA está activo en una agrupación de hebras RSE. El nombre de trabajo de la agrupación de hebras de RSE es RSEDx, donde RSED es el nombre de la tarea iniciada RSE, y x, un número aleatorio de un dígito, por lo que es necesario utilizar comodines en la definición.
PORTRange 5227 100 RSED* ; Developer for System z - CARMA
El ACK retardado retrasa el acuse de recibo (ACK) del paquete TCP en hasta unos 200ms. Este retardo aumenta la oportunidad de que el ACK se pueda enviar junto con la repuesta al paquete recibido, reduciendo así el tráfico de red. No obstante, si el remitente está esperando el ACK antes de enviar un paquete nuevo (por ejemplo, debido a la implementación del algoritmo de Nagle) y no hay respuesta al paquete recién enviado (por ejemplo, porque es parte de una transferencia de archivo), la comunicación se retrasa innecesariamente.
Developer for System z le permite inhabilitar la función de ACK retardada. En el host, esto se hace con la directiva DSTORE_TCP_NO_DELAY en rsed.envvars, según se indica en la documentación de la Guía de configuración del host SC11-3660 (SC23-7658).
z/OS Communication Server permite tener varias pilas TCP/IP activas simultáneamente en un mismo sistema. Esto se conoce como configuración CINET.
Si Developer for System z no está activo en la pila predeterminada, es posible que las funciones de Developer for System z seleccionadas fallen. Utilizar la afinidad de pila es una forma segura de resolver este problema. La afinidad de pila indica a Developer for System z que utilice únicamente una pila TCP/IP específica (en lugar de todas las pilas TCP/IP disponibles, que es el valor predeterminado para las tareas iniciadas).
Anule el comentario y personalice la directiva _BPXK_SETIBMOPT_TRANSPORT en el archivo de configuración rsed.envvars para establecer la afinidad de pila para la tarea iniciada RSED. Consulte la sección correspondiente del "Capítulo 2 Personalización básica" de la publicación Guía de configuración de host (SC11-3660) para obtener más detalles sobre cómo personalizar estos archivos de configuración.
CARMA (Common Access Repository Manager) se utiliza para acceder a un CSM ( (Software Configuration Manager) basado en host, como por ejemplo, CA Endevor® SCM. Para ello, CARMA inicia un servidor específico de usuario, que necesita una configuración adicional para aplicar la afinidad de pila.
De forma parecida a las tareas iniciadas por Developer for System z, la afinidad de pila para un servidor CARMA se establece con la variable _BPXK_SETIBMOPT_TRANSPORT, que debe pasarse a LE (Language Environment). Esto puede hacerse ajustando el mandato de arranque en el archivo de configuración crastart*.conf o CRASUB* activo.
... PARM(&CRAPRM1. &CRAPRM2.)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
... PARM(&PORT &TIMEOUT)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
DVIPA (Direccionamiento IP virtual dinámico) distribuido permite ejecutar simultáneamente configuraciones de Developer for System z idénticas en diferentes sistemas en su sysplex y hacer que TCP/IP, con la ayuda opcional de WLM, distribuya las conexiones de cliente entre esos sistemas.
Por lo tanto, Developer for System z requiere la definición de SYSPLEXPORTS en la sentencia VIPADISTRIBUTE para asegurarse de que los puertos utilizados por las hebras del servidor RSE sean exclusivos dentro del sysplex.
El Supervisor de trabajos JES, CARMA y otros servidores Developer for System z sólo interactúan con el RSE local y por lo tanto no necesitan una configuración DVIPA.
El depurador integrado interactúa con el RSE local y no requiere la configuración de DVIPA. Para asegurarse de que las sesiones de depuración se comuniquen con el host correspondiente, el gestor de depuración dicta al cliente las direcciones TCP/IP que se deben utilizar y, por tanto, no requiere una configuración de DVIPA.
Los DVIPA distribuidos se definen mediante las palabras clave VIPADEFine y VIPABackup del bloque VIPADynamic en su perfile TCP/IP. La palabra clave VIPADISTribute añade las definiciones de Sysplex Distributor. DVIPA distribuido necesita que todas las pilas participantes conozcan la existencia de sysplex, lo que se hace a través de las palabras clave SYSPLEXRouting y DYNAMICXCF del bloque IPCONFIG del perfil TCP/IP. Consulte la publicación Communications Server: IP Configuration Reference (SC31-8776) para obtener más detalles sobre estas directivas.
Consulte las publicaciones MVS Setting Up a Sysplex (SA22-7625) y Communication Server: SNA Network Implementation Guide (SC31-8777) para obtener más información sobre la configuración de la estructura EZBEPORTS en su recurso de acoplamiento.
La utilización de SYSPLEXPORTS implica que TCP/IP seleccionará un puerto efímero para la conexión secundaria. Un puerto efímero es cualquier puerto libre y no reservado de ninguna forma. El uso de un puerto efímero choca con los procedimientos recomendados de cortafuegos para limitar los puertos abiertos para comunicación ya que no se sabe qué puerto se utilizará.
Puede saltarse este problema forzando a Developer for System z a que utilice puertos conocidos para la conexión secundaria definiendo un _RSE_PORTRANGE exclusivo por sistema y asegurándose de que los rangos de puertos usados se reservan para el uso de Developer for System z en todos los sistemas. Debe tener en cuenta que este salto requiere TCP/IP APAR PM63379.
Para asegurarse de que TCP/IP dirigirá la conexión secundaria al sistema correcto, Developer for System z debe utilizar un rango de puertos exclusivo en cada sistema. Esto implica que no puede utilizar una configuración compartida e idéntica para los sistemas ya que _RSE_PORTRANGE en rsed.envvars debe ser exclusivo. Consulte Archivos de configuración diferentes con idéntico nivel de software in Ejecutar varias instancias para obtener información sobre cómo configurar varios servidores con archivos de configuración diferentes mientras se utiliza el mismo código. Debe utilizar una copia maestra de rsed.envvars y un script para ajustarlo y copiarlo en una configuración específica del sistema para asegurarse de que el archivo permanece idéntico entre los sistemas distintos.
$ oedit /etc/rdz/rsed.envvars
-> añada lo siguiente al FINAL:
# -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/update.sh
$ chmod 755 /etc/rdz/update.sh
#! /bin/sh
# Materiales bajo licencia - Propiedad de IBM
# 5724-T07 Copyright IBM Corp. 2012
# clonar rsed.envvars y establecer PORTRANGE para utilizarlo con RDz y DDVIPA
file=rsed.envvars #; echo file $file
sys=${1:-$(sysvar SYSNAME)} #; echo sys $sys
dir=$(dirname $0) #; echo dir $dir
# si sysname tiene un car. especial, anteponer \ (p. ej. SYS\$1)
case "$sys" in # #### PERSONALIZAR ESTA SECCIÓN ####
"SYS1") range=8108-8118;;
"SYS2") range=8119-8129;;
esac #; echo range $range
echo "setting port range $range for $sys using $dir/$file"
if test ! $range ; then
echo ERROR: no port range defined for $sys ; exit 12 ; fi
if test ! -e $dir/$file ; then
echo ERROR: file $dir/$file does not exist ; exit 12 ; fi
if test ! -d $dir/$sys ; then
echo ERROR: directory $dir/$sys does not exist ; exit 12 ; fi
mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
sed "$sed" $dir/$file > $dir/$sys/$file
if test ! -s $dir/$sys/$file ; then
echo ERROR creating $dir/$sys/$file, restoring backup
mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi
$ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
$ /etc/rdz/update.sh SYS1
setting port range 8108-8118 for SYS1 using
/etc/rdz/rsed.envvars
$ /etc/rdz/update.sh SYS2
setting port range 8119-8129 for SYS2 using
/etc/rdz/rsed.envvars
// CNFG='/etc/rdz/&SYSNAME.'
PORTRange 8108 22 RSED* ; 8108-8129 - Developer for System z
; - conexión secundaria
Tal como se explica en Flujo de conexión, el rango de puertos de _RSE_PORTRANGE puede ser pequeño. El servidor RSE no necesita el puerto exclusivamente para la duración de la conexión de cliente. Está sólo en el lapso de tiempo entre el enlace (servidor) y la conexión (cliente) que ningún otro servidor RSE puede enlazar al puerto. Esto significa que la mayoría de las conexiones utilizarán el primer puerto del rango, y el resto del rango será un almacenamiento intermedio en caso de varios inicios de sesión simultáneos.
En el ejemplo siguiente hay dos sistemas z/OS, SYS1 y SYS2 que forman parte de un sysplex. System SYS1 está definido como el sistema que normalmente alberga el Sysplex Distributor del DVIPA distribuido de Developer for System z.
Después de definir el DVIPA distribuido, Developer for System z se puede iniciar en los sistemas para permitir el equilibrado de carga de conexiones de cliente entre los sistemas. El Supervisor de trabajos JES solo interactúa con el RSE local y por tanto no requiere una configuración de a DVIPA. Los clientes se conectarán al puerto 4035 en la dirección IP 10.10.10.1.
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING es necesario ya que esta pila necesita comunicación sysplex
DYNAMICXCF 9.9.9.1 255.255.255.0 1
; DYNAMICXCF define el dispositivo/enlace con la dirección inicial 9.9.9.1
; según sea necesario
IGNORERedirect
VIPADYNAMIC
VIPADEFINE 255.255.255.0 10.10.10.1
; VIPADEFINE define 10.10.10.1 como DVIPA principal en SYS1 para RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE convierte 10.10.10.1 en un DVIPA distribuido, debe coincidir
; con SYS2
SYSPLEXPORTS ; Prerrequisito de RDz
DISTMETHOD BASEWLM ; BASEWLM o ROUNDROBIN
10.10.10.1 ; Dirección DVIPA utilizada por clientes RDz
PORT 4035 ; Puerto utilizado por clientes RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz activo en SYS1 y SYS2
ENDVIPADYNAMIC
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING es necesario ya que esta pila necesita comunicación sysplex
DYNAMICXCF 9.9.9.2 255.255.255.0 1
; DYNAMICXCF define el dispositivo/enlace con la dirección inicial 9.9.9.2
; según sea necesario
IGNORERedirect
VIPADYNAMIC
VIPABACKUP 255.255.255.0 10.10.10.1
; VIPABACKUP define 10.10.10.1 como DVIPA de seguridad en SYS2 para RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE convierte 10.10.10.1 en un DVIPA distribuido, debe coincidir
; con SYS1
SYSPLEXPORTS ; Prerrequisito de RDz
DISTMETHOD BASEWLM ; BASEWLM o ROUNDROBIN
10.10.10.1 ; Dirección DVIPA utilizada por clientes RDz
PORT 4035 ; Puerto utilizado por clientes RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz activo en SYS1 y SYS2
ENDVIPADYNAMIC
Al contrario que las aplicaciones z/OS tradicionales, Developer for System z no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Tal como se describe en Comprender Developer for System z, algunos de estos servicios están activos en diferentes espacios de direcciones, lo que resulta en diferentes clasificaciones WLM.
La Figura 13 muestra una visión general básica de los subsistemas a través de los cuales se presentan las cargas de trabajo de Developer for System z a WLM.
El Gestor de despliegue de aplicaciones (ADM) está activo en una región CICS y por lo tanto seguirá las reglas de clasificación CICS en WLM.
El daemon RSE (RSED), el Gestor de depuración (DBGMGR) y el Supervisor de trabajos JES (JMON) son tareas iniciadas por Developer for System z (o trabajos por lotes de larga ejecución), cada uno con su espacio de direcciones individual.
Tal como se explica en RSE como aplicación Java, el daemon RSE genera un proceso hijo para cada servidor de agrupaciones de hebras RSE (que soporta un número variable de clientes). Cada agrupación de hebras está activo en un espacio de direcciones aparte (utilizando un iniciador z/OS UNIX, BPXAS). Como se trata de procesos generados, se clasifican mediante las reglas de clasificación WLM OMVS, no las reglas de clasificación de tareas iniciadas.
Los clientes activos en una agrupación de hebras pueden crear muchos otros espacios de direcciones, según las acciones realizadas por los usuarios. Dependiendo de la configuración de Developer for System z, algunas cargas de trabajo, como por ejemplo el servicio de mandatos TSO (TSO cmd) o CARMA, se pueden ejecutar en subsistemas diferentes.
Los espacios de direcciones que aparecen en la lista de la Figura 13 siguen permaneciendo en el sistema durante tiempo suficiente para ser visibles pero debe tener en cuenta que debido al diseño de z/OS UNIX, también hay varios espacios de direcciones temporales de vida breve. Estos espacios de direcciones temporales están activos en el subsistema OMVS.
Tenga en cuenta que mientras que las agrupaciones de hebras de RSE utilizan el mismo ID de usuario y un nombre de trabajo parecido al del daemon RSE, todos los espacios de direcciones iniciados por una agrupación de hebras son propiedad del IDE de usuario del cliente que solicita la acción. El ID de usuario cliente también se utiliza como (es parte del) nombre de trabajo para todos los espacios de direcciones basados en OMVS declarados por la agrupación de hebras.
Otros servicios han creado más espacios de direcciones que Developer for System z utiliza, como por ejemplo Gestor de archivos (FMNCAS) o z/OS UNIX REXEC (construcción USS).
WLM utiliza reglas de clasificación para correlacionar el trabajo que entra en el sistema con una clase de servicio. Esta clasificación se basa en calificadores de trabajo. El primer calificador (obligatorio) es el tipo de subsistema que recibe la petición de trabajo. La Tabla 14 enumera los tipos de subsistema que pueden recibir cargas de trabajo de Developer for System z.
Tipo de subsistema | Descripción de trabajo |
---|---|
ASCH | Las peticiones de trabajo incluyen todos los programas de transacción APPC planificados por el planificador de transacciones APPC/MVS proporcionados por IBM, ASCH. |
CICS | Las peticiones de trabajo incluyen todas las transacciones procesadas por CICS. |
JES | Las solicitudes de trabajo incluyen todos los trabajos iniciados por JES2 o JES3. |
OMVS | Las peticiones de trabajo incluyen el trabajo procesado en espacios de direcciones hijo bifurcados de z/OS UNIX System Services. |
STC | Las peticiones de trabajo incluyen todo el trabajo iniciado por los mandatos START y MOUNT. STC también incluye espacios de direcciones de componentes del sistema. |
En la Tabla 15 se enumeran calificadores adicionales que se pueden utilizar para asignar una carga de trabajo a una clase de servicio específica. Consulte la planificación de MVS: Workload Management (SA22-7602) para obtener más detalles sobre los calificadores de trabajo de la lista.
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Información de contabilidad | x | x | x | x | |
LU | Nombre de LU (*) | x | ||||
PF | Realizar (*) | x | x | |||
PRI | Prioridad | x | ||||
SE | Nombre de entorno de planificación | x | ||||
SSC | Nombre de recogida de subsistema | x | ||||
SI | Instancia de subsistema (*) | x | x | |||
SPM | Parámetro de subsistema | x | ||||
PX | Nombre de Sysplex | x | x | x | x | x |
SY | Nombre de sistema (*) | x | x | x | ||
TC | Clase de transacción/trabajo (*) | x | x | |||
TN | Nombre de transacción/trabajo (*) | x | x | x | x | x |
UI | ID de usuario (*) | x | x | x | x | x |
Tal como se explica en Clasificación de carga de trabajo, Developer for System z crea varios tipos de cargas de trabajo en el sistema. Estas diferentes tareas se comunican entre sí, lo que implica que el tiempo transcurrido real se vuelve importante para evitar los problemas de tiempo de espera para las conexiones entre las tareas. Como resultado, las tareas de Developer for System z deben colocarse en clases de servicio de alto rendimiento o en clases de servicio de rendimiento moderado con una alta prioridad.
Por lo tanto, es recomendable revisar y posiblemente actualizar sus objetivos de WLM. Esto es especialmente cierto para las tiendas MVS tradicionales sin experiencia con cargas de trabajo OMVS para las que el tiempo es muy importante.
La Tabla 16 enumera los espacios de direcciones utilizados por Developer for System z. z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Gestor de depuración | DBGMGR | STC |
Supervisor de trabajos JES | JMON | STC |
Daemon RSE | RSED | STC |
Agrupación de hebras RSE | RSEDx | OMVS |
Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <IDusuario>x | OMVS |
Servicio de mandatos TSO (APPC) | FEKFRSRV | ASCH |
CARMA (por lotes) | CRA<puerto> | JES |
CARMA (crastart) | <IDusuario>x | OMVS |
CARMA (Pasarela de cliente ISPF) | <IDusuario> e <IDusuario>x | OMVS |
Construcción de MVS (trabajo por lotes) | * | JES |
Construcción de z/OS UNIX (mandatos de shell) | <IDusuario>x | OMVS |
Shell de z/OS UNIX | <IDusuario> | OMVS |
Gestor de despliegue de aplicaciones | CICSTS | CICS |
Todas las tareas iniciadas por Developer for System z, daemon de RSE y Supervisor de trabajos JES están dando servicio en tiempo real a peticiones de cliente.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Supervisor de trabajos JES | JMON | STC |
Gestor de depuración | DBGMGR | STC |
Daemon RSE | RSED | STC |
El Supervisor de trabajos JES proporciona todos los servicios relacionados con JES como por ejemplo el sometimiento de trabajos, el examen de archivos en spool y la ejecución de mandatos de operador JES. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea entre mínima y moderada.
El Gestor de depuración proporciona servicios para conectar programas que se depuran a clientes que los depuran. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
El daemon RSE maneja el inicio de sesión y la autenticación de clientes y gestiona las diferentes agrupaciones de hebras de RSE. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. Se espera que la utilización de recursos sea moderada, con un pico al principio del día de trabajo.
Las cargas de trabajo de OMVS pueden dividirse en dos grupos, agrupaciones de hebras RSE y todo lo demás. Esto es porque todas las cargas de trabajo excepto las agrupaciones de hebras RSE utilizan el ID de usuario de cliente como base para el nombre del espacio de direcciones. (z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.)
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Agrupación de hebras RSE | RSEDx | OMVS |
Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <IDusuario>x | OMVS |
CARMA (crastart) | <IDusuario>x | OMVS |
CARMA (Pasarela de cliente ISPF) | <IDusuario> e <IDusuario>x | OMVS |
Construcción de z/OS UNIX (mandatos de shell) | <IDusuario>x | OMVS |
Shell de z/OS UNIX | <IDusuario> | OMVS |
Una agrupación de hebras RSE es como el corazón y el cerebro Developer for System z. Casi todos los datos fluyen por aquí, y los extractores (hebras específicas de usuario) de dentro de la agrupación de hebras controlan las acciones para la mayoría de las otras tareas relacionadas de Developer for System z. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea sustancial.
Las cargas de trabajo restantes finalizarán todas en la misma clase de servicio debido a un convenio de denominación de espacios de direcciones común. Debe especificar un objetivo de varios periodos para esta clase de servicio. Los primeros periodos deberían ser objetivos de tiempo de respuesta percentil de alto rendimiento, mientras que el último periodo debería tener un objetivo de velocidad de rendimiento moderado. Algunas cargas de trabajo como por ejemplo la Pasarela de cliente ISPF informarán de transacciones individuales a WLM, mientras que otras no lo harán.
La Pasarela de cliente ISPF es un servicio ISPF invocado por Developer for System z para ejecutar mandatos TSO y ISPF no interactivos. Esto incluye mandatos explícitos emitidos por el cliente así como mandatos implícitos emitidos por Developer for System z, como por ejemplo obtener una lista de miembros de PDS. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
CARMA es un servidor Developer for System z opcional utilizado para interactuar con Gestores de configuraciones de software (SCM), como por ejemplo CA Endevor® SCM. Developer for System z permite diferentes métodos de inicio para un servidor CARMA, algunos de los cuales se convierten en una carga de trabajo OMVS. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
Cuando un cliente inicia una construcción para un proyecto z/OS UNIX, z/OS UNIX REXEC (o SSH) iniciará una tarea que ejecuta un número de mandatos de shell z/OS UNIX para realizar la construcción. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea entre moderada y sustancial, dependiendo del tamaño del proyecto.
Esta carga de trabajo procesa mandatos shell z/OS UNIX emitidos por el cliente. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
Los procesos por lotes gestionados por JES los utiliza Developer for System z de varias maneras. La utilización más común es para construcciones MVS, donde un trabajo se somete y supervisa para determinar cuándo finaliza. Pero Developer for System z también podría iniciar un servidor CARMA por lotes y comunicarse con el mediante TCP/IP.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
CARMA (por lotes) | CRA<puerto> | JES |
Construcción de MVS (trabajo por lotes) | * | JES |
CARMA es un servidor Developer for System z opcional utilizado para interactuar con Gestores de configuraciones de software (SCM), como por ejemplo CA Endevor® SCM. Developer for System z permite diferentes métodos de inicio para un servidor CARMA, algunos de los cuales se convierten en una carga de trabajo JES. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
En las versiones actuales Developer for System z, la Pasarela de cliente ISPF se utiliza para ejecutar mandatos TSO e ISPF no interactivos. Por razones históricas, Developer for System z también soporta la ejecución de estos mandatos a través de una transacción APPC. Debe tener en cuenta que el método APPC está en desuso.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Servicio de mandatos TSO (APPC) | FEKFRSRV | ASCH |
El servicio de mandatos TSO puede iniciarse como una transacción APPC por parte de Developer for System z para ejecutar mandatos TSO e ISPF no interactivos. Esto incluye mandatos explícitos emitidos por el cliente así como mandatos implícitos emitidos por Developer for System z, como por ejemplo obtener una lista de miembros de PDS. Debe especificar un objetivo de varios periodos para esta clase de servicio. Para los primeros periodos debe especificar objetivos de tiempo de respuesta percentil de alto rendimiento. Para el último periodo debe especificar un objetivo de velocidad de rendimiento moderado. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
El Gestor de despliegue de aplicaciones es un servidor de Developer for System z opcional que está activo dentro de una región de CICS Transaction Server.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Gestor de despliegue de aplicaciones | CICSTS | CICS |
El servidor Gestor de despliegue de aplicaciones que está activo dentro de una región CICSTS, permite descargar de forma segura las tareas de gestión CICSTS seleccionadas para los desarrolladores. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima. El tipo de clase de servicio que utilice depende del resto de transacciones activas en esta región CICS y por lo tanto no se trata en detalle.
El objeto se establece en una clase de servicio que gestiona los espacios de dirección CICS. Sólo puede utilizar un objetivo de velocidad de ejecución para esta clase de servicio. WLM utiliza las reglas de clasificación de JES o STC para los espacios de dirección pero no utiliza las reglas de clasificación de subsistemas CICS para transacciones.
Se puede establecer un objetivo de tiempo de respuesta en una clase de servicio asignada a una sola transacción o a un grupo de transacciones. WLM utiliza las reglas de clasificación JES o STC para los espacios de dirección y las reglas de clasificación de subsistema CICS para transacciones.
Tal como se explica en Comprender Developer for System z, RSE (Explorador de Sistemas remotos) es el núcleo de Developer for System z. Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente.
Ello hace que RSE sea el destino principal para ajustar la configuración de Developer for System z. Sin embargo, para mantener a cientos de usuarios, cada uno de los cuales utiliza 17 o más hebras, una cantidad determinada de almacenamiento y, posiblemente, 1 o más espacios de direcciones es necesario configurar correctamente Developer for System z y z/OS.
Utilice la información de esta sección para estimar el uso normal y máximo de recursos por parte de Developer for System z, de manera que pueda planificar acorde la configuración del sistema.
Al utilizar los números y las fórmulas presentadas en esta sección para definir los valores para los límites del sistema, tenga en cuenta que está trabajando con estimaciones bastante precisas. Deje un margen suficiente al establecer los límites del sistema para permitir el uso de recursos por las tareas temporales o por otras tareas, o por usuarios que se conecten varias veces al host simultáneamente. (Por ejemplo, a través de RSE y TN3270).
Tarea iniciada | Espacios de direcciones | Procesos | Hebras |
---|---|---|---|
JMON | 1 | 1 | 3 |
DBGMGR | 1 | 1 | 4 |
RSED | 1 | 3 | 16 |
RSEDx | (a) 1 + 2 | 1 + 3 | 1 + 14 |
Software requisito | Espacios de direcciones | Procesos | Hebras |
---|---|---|---|
Pasarela de cliente ISPF | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
Acción de usuario | Espacios de direcciones ID usuario |
Procesos ID usuario |
Hebras |
||
---|---|---|---|---|---|
Inicio de sesión | - | - | - | 17 | 1 |
Temporizador para tiempo de espera desocupado | - | - | - | 1 | - |
Buscar | - | - | - | 1 | - |
Ampliar PDS(E) | ISPF | ISPF | ISPF | - | - |
Abrir conjunto de datos | ISPF | ISPF | ISPF | 1 | - |
Mandato TSO | ISPF | ISPF | ISPF | - | - |
Shell de z/OS UNIX | 1 | 1 | 1 | 6 | - |
Construcción de MVS | 1 | - | - | - | - |
Construcción de z/OS UNIX | 3 | 3 | 3 | - | - |
CARMA (por lotes) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 1 | - |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Recuento | Descripción | Nombre de tarea | Compartido | Finaliza tras |
---|---|---|---|---|
1 | Supervisor de trabajos JES | JMON | Sí | Nunca |
1 | Gestor de depuración | DBGMGR | Sí | Nunca |
1 | Daemon RSE | RSED | Sí | Nunca |
1 | Autorización APF daemon RSE | RSEDx | Sí | Nunca |
(a) | Agrupación de hebras RSE | RSEDx | Sí | Nunca |
(a) | Autorización APF de agrupación de hebras RSE | RSEDx | Sí | Nunca |
lu | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <IDusuario>x | No | 15 minutos o fin de sesión de usuario |
lu | Servicio de mandatos TSO (APPC) | FEKFRSRV | No | 60 minutos o fin de sesión de usuario |
lu | CARMA (por lotes) | CRA<puerto> | No | 7 minutos o fin de sesión de usuario |
lu | CARMA (crastart) | <IDusuario>x | No | 7 minutos o fin de sesión de usuario |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
4u | CARMA (ispf, en desuso) | (1)<IDusuario> o (3)<IDusuario>x | No | 7 minutos o fin de sesión de usuario |
(b) | Uso simultáneo de la Pasarela de cliente ISPF por 1 usuario | <IDusuario>x | No | Compleción de la tarea |
1u | Construcción de MVS (trabajo por lotes) | * | No | Compleción de la tarea |
3u | Construcción de z/OS UNIX (mandatos de shell) | <IDusuario>x | No | Compleción de la tarea |
1u | Shell de z/OS UNIX | <IDusuario> | No | Fin de sesión de usuario |
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC |
---|---|---|---|
1 | No | No | Sí |
1 | No | Sí | No |
1 | Sí | Sí | No |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, en desuso) |
Ubicación | Límite | Recursos afectados |
---|---|---|
rsed.envvars | maximum.threadpool.process | Limita el número de agrupaciones de hebras RSE |
IEASYMxx | MAXUSER | Limita el número de espacios de direcciones |
ASCHPMxx | MAX | Limita el número de iniciadores APPC para el servicio de mandatos TSO (APPC) |
Procesos | Espacios de direcciones | Descripción | ID de usuario |
---|---|---|---|
1 | 1 | Supervisor de trabajos JES | STCJMON |
1 | 1 | Gestor de depuración | STCDBM |
3 | 1 | Daemon RSE | STCRSE |
1 | 1 | Autorización APF daemon de RSE | STCRSE |
2 | (a) | Agrupación de hebras RSE | STCRSE |
1 | (a) | Autorización APF de agrupación de hebras RSE | STCRSE |
2 | (b) | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <IDusuario> |
2 | (a) | Agrupación de hebras RSE | STCRSE |
1 | 1u | Servicio de mandatos TSO (APPC) | <IDusuario> |
1 | 1u | CARMA (por lotes) | <IDusuario> |
1 | 1u | CARMA (crastart) | <IDusuario> |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
1 | 1u | CARMA (ispf, en desuso) | <IDusuario> |
1 | 3u | Construcción de z/OS UNIX (mandatos de shell) | <IDusuario> |
1 | 1u | Shell de z/OS UNIX | <IDusuario> |
(5) | (u) | SCLM Developer Toolkit | <IDusuario> |
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC |
---|---|---|---|
1 | No | No | Sí |
2 | No | Sí | No |
7 | Sí | Sí | No |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, en desuso) |
Ubicación | Límite | Recursos afectados |
---|---|---|
BPXPRMxx | MAXPROCSYS | Limita el número total de procesos |
BPXPRMxx | MAXPROCUSER | Limita el número de procesos por UID de z/OS UNIX |
Segmento OMVS | PROCUSERMAX | Limita el número de procesos para un ID de usuario |
Hebras |
ID de usuario | Descripción | ||
---|---|---|---|---|
RSEDx | Activa | Prog. arranque | ||
- | (f) 3 + 1u | - | STCJMON | Supervisor de trabajos JES |
- | 4 | - | STCDBM | Gestor de depuración |
- | 14 | 2 | STCRSE | Daemon RSE |
- | 1 | - | STCRSE | Autorización APF daemon RSE |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | Agrupación de hebras RSE con extractores de una sola hebra |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | Agrupación de hebras RSE, con extractores de varias hebras |
- | (a) 1 | - | STCRSE | Autorización APF de agrupación de hebras RSE |
- | (b) 4u | (b) 1u | <IDusuario> | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) |
- | 2u | - | <IDusuario> | Servicio de mandatos TSO (APPC) |
1u | 2u | - | STCRSE e <IDusuario> | CARMA (por lotes) |
![]() ![]() |
2u | - | STCRSE e <IDusuario> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE e <IDusuario> | CARMA (ispf, en desuso) |
- | (c) 1u | 2u | <IDusuario> | Construcción de z/OS UNIX (mandatos de shell) |
6u | 1u | - | STCRSE e <IDusuario> | Shell de z/OS UNIX |
(d) 1 | - | - | STCRSE | Descargar |
(e) 1 | - | - | STCRSE | Buscar |
- | (5) | - | <IDusuario> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporizador para tiempo de espera desocupado |
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC | Tiempo de espera |
---|---|---|---|---|
0 | No | No | Sí | No |
0 | No | Sí | No | No |
0 | Sí | Sí | No | No |
1 | No | No | Sí | Sí |
1 | No | Sí | No | Sí |
1 | Sí | Sí | No | Sí |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, en desuso) |
Ubicación | Límite | Recursos afectados |
---|---|---|
Segmento OMVS | THREADSMAX | Limita el número de hebras para un ID de usuario |
BPXPRMxx | MAXTHREADS | Limita el número de hebras en un proceso |
BPXPRMxx | MAXTHREADTASKS | Limita el número de tareas de MVS en un proceso. |
BPXPRMxx | MAXASSIZE | Limita el tamaño de espacio de direcciones y, con ello, el almacenamiento disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | Xmx | Establece el tamaño del almacenamiento dinámico Java máximo. Este almacenamiento está reservado, por lo que no está disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | maximum.clients | Limita el número de clientes (y sus hebras) de una agrupación de hebras RSE. |
rsed.envvars | maximum.threads | Limita el número de hebras de cliente en una Agrupación de hebras RSE. |
FEJJCNFG | MAX_THREADS | Limita el número de hebras en el Supervisor de trabajos JES. |
El uso de recursos que se documenta en las secciones anteriores es permanente durante el lapso de vida de Developer for System z o semipermanente para determinadas tareas específicas del usuario.
Hebras |
ID de usuario | Descripción | ||
---|---|---|---|---|
RSEDx | Activa | Prog. arranque | ||
- | (f) 3 + 1u | - | STCJMON | Supervisor de trabajos JES |
- | 4 | - | STCDBM | Gestor de depuración |
- | 14 | 2 | STCRSE | Daemon RSE |
- | 1 | - | STCRSE | Autorización APF daemon RSE |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | Agrupación de hebras RSE con extractores de una sola hebra |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | Agrupación de hebras RSE, con extractores de varias hebras |
- | (a) 1 | - | STCRSE | Autorización APF de agrupación de hebras RSE |
- | (b) 4u | (b) 1u | <IDusuario> | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) |
- | 2u | - | <IDusuario> | Servicio de mandatos TSO (APPC) |
1u | 2u | - | STCRSE e <IDusuario> | CARMA (por lotes) |
![]() ![]() |
2u | - | STCRSE e <IDusuario> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE e <IDusuario> | CARMA (ispf, en desuso) |
- | (c) 1u | 2u | <IDusuario> | Construcción de z/OS UNIX (mandatos de shell) |
6u | 1u | - | STCRSE e <IDusuario> | Shell de z/OS UNIX |
(d) 1 | - | - | STCRSE | Descargar |
(e) 1 | - | - | STCRSE | Buscar |
- | (5) | - | <IDusuario> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporizador para tiempo de espera desocupado |
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC | Tiempo de espera |
---|---|---|---|---|
0 | No | No | Sí | No |
0 | No | Sí | No | No |
0 | Sí | Sí | No | No |
1 | No | No | Sí | Sí |
1 | No | Sí | No | Sí |
1 | Sí | Sí | No | Sí |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, en desuso) |
Ubicación | Límite | Recursos afectados |
---|---|---|
Segmento OMVS | THREADSMAX | Limita el número de hebras para un ID de usuario |
BPXPRMxx | MAXTHREADS | Limita el número de hebras en un proceso |
BPXPRMxx | MAXTHREADTASKS | Limita el número de tareas de MVS en un proceso. |
BPXPRMxx | MAXASSIZE | Limita el tamaño de espacio de direcciones y, con ello, el almacenamiento disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | Xmx | Establece el tamaño del almacenamiento dinámico Java máximo. Este almacenamiento está reservado, por lo que no está disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | maximum.clients | Limita el número de clientes (y sus hebras) de una agrupación de hebras RSE. |
rsed.envvars | maximum.threads | Limita el número de hebras de cliente en una Agrupación de hebras RSE. |
FEJJCNFG | MAX_THREADS | Limita el número de hebras en el Supervisor de trabajos JES. |
RSE es una aplicación Java, que implica que la planificación de uso de almacenamiento (memoria) para Developer for System z debe tener en cuenta dos límites de asignación de almacenamiento, el almacenamiento dinámico Java y el tamaño de Espacio de direcciones.
Java ofrece varios servicios para facilitar los esfuerzos de codificación para las aplicaciones Java. Uno de estos servicios es la gestión de almacenamiento.
La gestión de almacenamiento de Java asigna bloques grandes de almacenamiento, y los utiliza para las solicitudes de almacenamiento de la aplicación. Este almacenamiento gestionado por Java se denomina almacenamiento dinámico Java. La recogida de basura periódica (desfragmentación) reclama el espacio no utilizado del almacenamiento dinámico y reduce su tamaño. Tenga en cuenta que para guardar ciclos de CPU, la recogida de basura tiende a esperar hasta que el almacenamiento ocupado sea realmente necesario, dejando así almacenamiento que ya no se utiliza asignado (y convirtiéndose en paginado) durante más tiempo que el absolutamente necesario.
El tamaño máximo de almacenamiento dinámico Java se define en rsed.envvars con la directiva Xmx. Si no se especifica esta directiva, Java utiliza un tamaño predeterminado de 512 MB. Debe especificar un valor de 256 MB o superior. Cuando se ejecuta en modalidad de 64 bits, Java intentará asignar el almacenamiento dinámico por encima de la barra de 2 GB, liberando el espacio por debajo de la barra.
Cada agrupación de hebras RSE (que proporciona servicio a las acciones de cliente) es una aplicación Java individual, por lo que tiene un almacenamiento dinámico Java personal. Tenga en cuenta que todas las agrupaciones de hebras utilizan el mismo archivo de configuración rsed.envvars, por lo que tienen el mismo límite de tamaño de almacenamiento dinámico Java.
El uso de la agrupación de hebras del almacenamiento intermedio Java depende sobre todo de las acciones realizadas por los clientes conectados. Es necesario supervisar regularmente el uso del almacenamiento dinámico para establecer el límite de tamaño de almacenamiento dinámico óptimo. Utilice el mandato de operador modify display process para supervisar el uso del almacenamiento dinámico Java por parte de las agrupaciones de hebras RSE.
Todas las aplicaciones z/OS, incluidas las aplicaciones Java, están activas dentro de un espacio de direcciones, por lo que están limitadas por las limitaciones de tamaño del espacio de direcciones.
Las agrupaciones de hebras RSE heredan los límites de tamaño del espacio de direcciones del daemon RSE. El tamaño del espacio de direcciones debe ser suficiente para albergar el almacenamiento dinámico Java, el propio Java, las áreas de almacenamiento comunes y todos los bloques de control que el sistema crea para soportar la actividad de las agrupaciones de hebras, por ejemplo, un TCB (bloque de control de tareas) por hebra. Tenga en cuenta que parte del uso de este almacenamiento está por debajo de la línea de 16 MB. Cuando se ejecuta en modalidad de 64 bits, Java intentará asignar el almacenamiento dinámico por encima de la barra de 2 GB, liberando espacio por debajo de la barra.
Debe supervisar el tamaño del espacio de direcciones real antes de cambiar ningún valor que tenga una influencia sobre el mismo, como cambiar el tamaño del almacenamiento dinámico Java o la cantidad de usuarios soportados por una única agrupación de hebras. Utilice el software de supervisión del sistema habitual para rastrear el uso del almacenamiento real por Developer for system z. Si no dispone de una herramienta de supervisión para ello, se puede reunir la información básica con herramientas como la vista SDSF DA o TASID (una herramienta de información del sistema tal cual disponible en el sitio Web de ISPF "Soporte y descargas").
Tenga en cuenta que RSE muestra el almacenamiento dinámico Java actual y el límite de tamaño del espacio de direcciones durante el inicio en el mensaje de consola FEK004I.
Como referencia, la Tabla 33 muestra valores utilizados por clientes de Developer for System z reales en valores clave rsed.envvars que tienen impacto en el uso de almacenamiento.
xmx (almacenamiento dinámico de Java máximo) | maximum.clients | Tipo de desarrollo primario |
---|---|---|
512M | 30 | PL/I |
512M | 10 | COBOL |
384M | 12 | COBOL |
800M (64 bits) | 20 | No especificado |
Tamaño máx. almacenamiento dinámico=10MB y Tamaño AS privado=1,959MB
inicio
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(7%) Clientes(0)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.01 2740 72
RSED 4.47 32.8M 15910
RSED8 1.15 27.4M 12612
inicio de sesión 1
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 81
RSED 4.55 32.8M 15980
RSED8 3.72 55.9M 24128
inicio de sesión 2
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(23%) Clientes(2)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.02 2944 86
RSED 4.58 32.9M 16027
RSED8 4.20 57.8M 25205
inicio de sesión 3
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(37%) Clientes(3)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.02 3020 91
RSED 4.60 32.9M 16076
RSED8 4.51 59.6M 26327
inicio de sesión 4
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(41%) Clientes(4)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.02 3108 96
RSED 4.61 32.9M 16125
RSED8 4.77 62.3M 27404
inició de sesión 5
BPXM023I (STCRSE)
ProcessId(268 ) Uso de memoria(41%) Clientes(4)
ProcessId(33554706) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.03 3184 101
RSED 4.64 32.9M 16229
RSED8 4.78 62.4M 27413
RSED9 4.60 56.6M 24065
Tamaño máx. almacenamiento dinámico=10MB y Tamaño AS privado=1,959MB
inicio
BPXM023I (STCRSE)
ProcessId(212 ) Uso de memoria(7%) Clientes(0)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.01 2736 71
RSED 4.35 32.9M 15117
RSED8 1.43 27.4M 12609
inicio de sesión
BPXM023I (STCRSE)
ProcessId(212 ) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.48 33.0M 15187
RSED8 3.53 53.9M 24125
ampliar árbol de MVS grande (195 conjuntos de datos)
BPXM023I (STCRSE)
ProcessId(212 ) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.58 33.1M 16094
RSED8 4.28 56.1M 24740
ampliar PDS pequeño (21 miembros)
BPXM023I (STCRSE)
ProcessId(212 ) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 4.40 56.2M 24937
abrir miembro de tamaño medio (86 líneas)
BPXM023I (STCRSE)
ProcessId(212 ) Uso de memoria(13%) Clientes(1)
Jobname Tiempo Cpu Almacenamiento EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 8.12 62.7M 27044
La mayoría de datos relacionados con Developer for System z que no se escriben una una sentencia DD terminan en un archivo z/OS UNIX. El programador del sistema controla qué datos se escriben y a dónde van. Sin embargo, no controla la cantidad de datos que se escriben.
De forma predeterminada, en los registros sólo se escriben los mensajes de error y de aviso. De manera que, si todo sale según se prevé, estos directorios deberían contener únicamente archivos vacíos o prácticamente vacíos (sin contar los registros de auditoría).
Puede habilitar los registros de mensajes informativos, preferiblemente bajo la dirección del centro de soporte de IBM, cosa que aumenta significativamente el tamaño de los archivos de registro.
inicio
$ ls -l /var/rdz/logs/server
total 144
-rw-rw-rw- 1 STCRSE STCGRP 33642 10 Jul 12:10 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1442 10 Jul 12:10 rseserver.log
inicio de sesión
$ ls -l /var/rdz/logs/server
total 144
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw------- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 303 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log
fin de sesión
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw------- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 609 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log
detener
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
A excepción de los registros de auditoría, los archivos de registro se sobrescriben cada vez que se reinicia (para la tarea iniciada RSE) o se finaliza la sesión (para un cliente), manteniendo el tamaño total adecuado. Los registros de auditoría se eliminan después de que caduque el intervalo especificado en audit.retention.period. La directiva keep.last.log de rsed.envvars cambia esto ligeramente, ya que puede hacer que RSE mantenga una copia de los registros anteriores. Las copias antiguas se eliminan siempre. Si la directiva keep.all.logs en rsed.envvars está habilitada, todos los registros tienen una indicación de fecha y hora que se añade al nombre y los archivos se eliminan después de que caduque el intervalo especificado en log.retention.period.
Se envía un mensaje de aviso a la consola cuando el sistema de archivos que contiene los archivos de registro se está quedando sin espacio disponible. Este mensaje de consola (FEK103E) se repite regularmente hasta que se ha resuelto el problema de falta de espacio. Cuando el sistema de archivos se queda sin espacio, RSE intentará suprimir los archivos de registro existentes para liberar espacio. Los registros de auditoría no están afectados por este proceso.
Ubicación | Directiva | Función |
---|---|---|
resecomm.properties | debug_level | Establecer el nivel de detalle de registro predeterminado |
rsecomm.properties | USER | Habilite nivel_depuración 2 para usuarios especificados. |
rsed.envvars | keep.all.logs | Conserva una copia de los registros previos antes del inicio/inicio de sesión. |
rsed.envvars | keep.last.log | Conserva una copia de los registros previos antes del inicio/inicio de sesión. |
rsed.envvars | enable.audit.log | Mantener un rastreo de auditoría de las acciones de clientes. |
rsed.envvars | enable.standard.log | Escribir las secuencias stdout y stderr de la agrupación (o agrupaciones) de hebras en un archivo de registro. |
rsed.envvars | DSTORE_TRACING_ON | Habilitar registro de acciones de DataStore. |
rsed.envvars | DSTORE_MEMLOGGING_ON | Habilitar registro de uso de memoria de DataStore. |
Mandato de operador | modify rsecommlog <nivel> | Cambiar dinámicamente el nivel de detalle de registro de rsecomm.log |
Mandato de operador | modify rsedaemonlog <nivel> | Cambiar dinámicamente el nivel de detalle de registro de rsedaemon.log |
Mandato de operador | modify rseserverlog <nivel> | Cambiar dinámicamente el nivel de detalle de registro de rseserver.log |
Mandato de operador | modify rsestandardlog {on|off} | Cambiar dinámicamente la actualización de std*.*.log |
Mandato de operador | modify trace {on|off} USER=userid | Habilite nivel_depuración 2 para usuarios especificados. |
Mandato de operador | modify trace {on|off} SERVER=pid | Habilite nivel_depuración 2 para usuarios especificados. |
Mandato de operador | modify trace clear | Inhabilite la configuración de rastreo |
Mandato de operador | modify logs | Recopilar registros de host e información de configuración |
rsed.envvars | daemon.log | Vía de acceso inicial para la tarea iniciada RSE y los registros de auditoría. |
rsed.envvars | user.log | Vía de acceso inicial de los registros de usuario. |
rsed.envvars | CGI_ISPWORK | Vía de acceso de inicio para los registros de pasarela de cliente ISPF |
rsed.envvars | TMPDIR | Directorio para registros IVP y mandato de operador modify logs |
rsed.envvars | _CEE_DMPTARG | Directorio para vuelcos Java |
Developer for System z junto con el software requisito, como la Pasarela de cliente ISPF, también escribe datos temporales en /tmp y /var/rdz/WORKAREA. La cantidad de datos escritos aquí como resultado de las acciones de usuario no es predecible, de manera que debe tener mucho espacio libre en los sistemas de archivos que contienen estos directorios.
Developer for System z siempre intenta limpiar estos archivos temporales, pero se puede realizar la limpieza manual en cualquier momento, tal como se describe en el apartado "(Opcional) Borrado de WORKAREA y /tmp" de la Guía de configuración de host (SC11-3660), se puede realizar prácticamente en cualquier momento.
Ubicación | Directiva | Función |
---|---|---|
rsed.envvars | CGI_ISPWORK | Vía de acceso de inicio para datos temporales. |
rsed.envvars | TMPDIR | Directorio para datos temporales. |
RSE, Java y z/OS UNIX utilizan las variables de entorno definidas en rsed.envvars. El archivo de ejemplo que viene con Developer for System z tiene como destino instalaciones pequeñas o de tamaño medio que no requieren los componentes opcionales de Developer for System z. En el apartado "rsed.envvars, archivo de configuración RSE" de la Guía de configuración de host (SC11-3660) se describe cada variable definida en el archivo de ejemplo, en el que las siguientes variables precisan de atención especial:
RSE es una aplicación Java, lo que significa que está activo en el entorno z/OS UNIX. Ello hace que BPXPRMxx se convierta en un miembro parmlib crucial, ya que contiene los parámetros que controlan el entorno z/OS UNIX y los sistemas de archivos. BPXPRMxx se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Rango del valor: nnnnn es un valor decimal del 5 al 32767.
Valor predeterminado: 900
Rango del valor: nnnnn es un valor decimal del 3 al 32767.
Valor predeterminado: 25
Rango del valor: nnnnnn es un valor decimal del 0 al 100000.
Valor predeterminado: 200
Rango del valor: nnnnn es un valor decimal del 0 al 32768.
Valor predeterminado: 1000
Rango del valor: nnnnn es un valor decimal del 1 al 32767.
Valor predeterminado: 200
Rango del valor: nnnnn es un valor decimal de 10485760 (10 Megabytes)
a 2147483647 (2 Gigabytes).
Valor predeterminado: 209715200 (200 Megabytes)
Rango del valor: nnnnnn es un valor decimal del 3 al 524287.
Valor predeterminado: 64000
Rango del valor: nnnnn es un valor decimal del 1 al 16777216.
Valor predeterminado: 40960
Utilice el mandato de operador SETOMVS o SET OMVS para aumentar o disminuir dinámicamente (hasta la próxima IPL) el valor de cualquiera de las variables BPXPRMxx anteriores. Para realizar un cambio permanente, edite el miembro BPXPRMxx que se utilizará para las IPL. Consulte la publicación MVS System Commands (SA22-7627) para obtener más información sobre estos mandatos de operador.
Las definiciones siguientes son subparámetros de la sentencia NETWORK.
Rango del valor: nnnnnnnn es un valor decimal del 0 al 16777215.
Valor predeterminado: 100
Rango del valor: nnnn es un valor decimal del 1 al 4000.
Valor predeterminado: si no se especifica ni INADDRANYPORT
ni INADDRANYCOUNT,
el valor predeterminado para
INADDRANYCOUNT es 1000.
De lo contrario, no se reservará ningún puerto (0).
Se recomienda añadir las siguientes definiciones a la tarjeta EXEC del JCL de los servidores de Developer for System z.
El Supervisor de trabajos JES utiliza las variables de entorno definidas en FEJJCNFG. El archivo de ejemplo que viene con Developer for System z está destinado a instalaciones pequeñas-medias. En el apartado "FEJJCNFG, archivo de configuración del supervisor de trabajos JES" de la Guía de configuración de host (SC11-3660) se describe cada variable definida en el archivo de ejemplo, en el que las siguientes variables precisan de atención especial:
IEASYSxx contiene parámetros del sistema y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Rango del valor: nnnnn es un valor decimal del 0 al 32767. Observe
que la suma de los valores especificados para los
parámetros de sistema MAXUSER, RSVSTRT,
y RSVNONR no puede superar 32767.
Valor predeterminado: 255
IVTPRMxx establece los parámetros para el Communication Storage Manager (CSM) y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Rango del valor: maxfix es un valor de 1024K a 2048M.
Valor predeterminado: 100M
Rango del valor: maxecsa es un valor de 1024K a 2048M.
Valor predeterminado: 100M
El miembro parmlib de ASCHPMxx contiene información de planificación para el planificador de transacciones ASCH y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Rango del valor: nnnnn es un valor decimal del 1 al 64000.
Valor predeterminado: 1
Dado que las cargas de trabajo pueden cambiar la necesidad de los recursos del sistema, es necesario supervisar el sistema regularmente para medir el uso de recursos, de manera que se pueda ajustar Rational Developer for System z y las configuraciones del sistema en respuesta a los requisitos de los usuarios. Los siguientes mandatos se pueden utilizar como ayuda en este proceso de supervisión.
FEK004I Daemon Rse: Tamaño máx. almacenamiento dinámico=65MB y
Tamaño AS privado=1,959MB
f rsed,appl=d p
BPXM023I (STCRSE)
ProcessId(16777456) Uso de memoria(33%) Clientes(4) Orden(1)
f rsed,appl=d p,detail
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 10 56 100
CLIENTS 0 25 30
MAXFILEPROC 83 103 64000
MAXPROCUSER 97 99 200
MAXTHREADS 9 14 1500
MAXTHREADTASKS 9 14 1500
f rsed,appl=d p,cpu
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
USERID THREAD-ID TCB@ ACC_TIME TAG
STCRSE 0EDE540000000000 005E6B60 822 1/ThreadPoolProcess
STCRSE 0EDE870000000001 005E69C8 001
STCRSE 0EDE980000000002 005E6518 1814
STCRSE 0EDEBA0000000003 005E66B0 2305
STCRSE 0EDECB0000000004 005E62F8 001
STCRSE 0EDEDC0000000005 005E60D8 001
STCRSE 0EDF860000000006 005C2BF8 628 6/ThreadPoolMonitor$Memory
UsageMonitor
STCRSE 0EDF970000000007 005C2D90 003 7/ThreadPoolMonitor
IBMUSER 0EE2C70000000024 005C08B0 050 38/JESMiner
IBMUSER 0EE2B60000000026 005C0690 004 40/FAMiner
IBMUSER 0EE30B0000000027 005C0250 002 41/LuceneMiner
IBMUSER 0EE31C0000000028 005C0030 002 42/CDTParserMiner
IBMUSER 0EE32D0000000029 005BDE00 002 43/MVSLuceneMiner
IBMUSER 0EE33E000000002A 005BDBE0 002 44/CDTMVSParserMiner
La mayoría de límites de z/OS UNIX que afectan a Developer for System z se pueden visualizar con mandatos de operador. Algunos mandatos muestran incluso el uso simultáneo y la marca de límite superior para un límite concreto. Consulte la publicación MVS System Commands (SA22-7627) para obtener más información sobre estos mandatos.
d omvs,o
BPXO043I 13.10.16 DISPLAY OMVS 066
OMVS 000D ETC/INIT WAIT OMVS=(M7)
CURRENT UNIX CONFIGURATION SETTINGS:
MAXPROCSYS = 256 MAXPROCUSER = 16
MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT
MAXCPUTIME = 1000 MAXUIDS = 200
MAXPTYS = 256
MAXMMAPAREA = 256 MAXASSIZE = 209715200
MAXTHREADS = 200 MAXTHREADTASKS = 1000
MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096
IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000
IPCMSGNIDS = 500 IPCSEMNIDS = 500
IPCSEMNOPS = 25 IPCSEMNSEMS = 1000
IPCSHMMPAGES = 25600 IPCSHMNIDS = 500
IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144
SUPERUSER = BPXROOT FORKCOPY = COW
STEPLIBLIST =
USERIDALIASTABLE=
SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1
SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1
PRIORITYPG VALUES: NONE
PRIORITYGOAL VALUES: NONE
MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864
SHRLIBMAXPAGES = 4096 VERSION = /
SYSCALL COUNTS = NO TTYGROUP = TTY
SYSPLEX = NO BRLM SERVER = N/A
LIMMSG = NONE AUTOCVT = OFF
RESOLVER PROC = DEFAULT
AUTHPGMLIST = NONE
SWA = BELOW
d omvs,l
BPXO051I 14.05.52 DISPLAY OMVS 904
OMVS 0042 ACTIVE OMVS=(69)
SYSTEM WIDE LIMITS: LIMMSG=SYSTEM
CURRENT HIGHWATER SYSTEM
USAGE USAGE LIMIT
MAXPROCSYS 1 4 256
MAXUIDS 0 0 200
MAXPTYS 0 0 256
MAXMMAPAREA 0 0 256
MAXSHAREPAGES 0 10 4096
IPCMSGNIDS 0 0 500
IPCSEMNIDS 0 0 500
IPCSHMNIDS 0 0 500
IPCSHMSPAGES 0 0 262144 *
IPCMSGQBYTES --- 0 262144
IPCMSGQMNUM --- 0 10000
IPCSHMMPAGES --- 0 256
SHRLIBRGNSIZE 0 0 67108864
SHRLIBMAXPAGES 0 0 4096
El mandato muestra las marcas de nivel superior y el uso actual de un proceso individual cuando se especifica también la palabra clave PID=processid.
d,omvs,l,pid=16777456
BPXO051I 14.06.28 DISPLAY OMVS 645
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
PROCESS LIMITS: LIMMSG=NONE
CURRENT HIGHWATER PROCESS
USAGE USAGE LIMIT
MAXFILEPROC 83 103 256
MAXFILESIZE --- --- NOLIMIT
MAXPROCUSER 97 99 200
MAXQUEUEDSIGS 0 1 1000
MAXTHREADS 9 14 200
MAXTHREADTASKS 9 14 1000
IPCSHMNSEGS 0 0 500
MAXCORESIZE --- --- 4194304
MAXMEMLIMIT 0 0 16383P
d omvs,p
BPXO046I 14.35.38 DISPLAY OMVS 092
OMVS 000E ACTIVE OMVS=(33)
PFS CONFIGURATION INFORMATION
PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED
TCP SOCKETS AF_INET EZBPFINI 50000 244 8146
UDS SOCKETS AF_UNIX BPXTUINT 64 6 10
ZFS LOCAL FILE SYSTEM IOEFSCM
14:32.00 RECYCLING
HFS LOCAL FILE SYSTEM GFUAINIT
BPXFTCLN CLEANUP DAEMON BPXFTCLN
BPXFTSYN SYNC DAEMON BPXFTSYN
BPXFPINT PIPE BPXFPINT
BPXFCSIN CHAR SPECIAL BPXFCSIN
NFS REMOTE FILE SYSTEM GFSCINIT
PFS NAME DESCRIPTION ENTRY STATUS FLAGS
TCP41 SOCKETS EZBPFINI ACT CD
TCP42 SOCKETS EZBPFINI ACT
TCP43 SOCKETS EZBPFINI INACT SD
TCP44 SOCKETS EZBPFINI INACT
PFS PARM INFORMATION
HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100)
CURRENT VALUES: FIXED(55) VIRTUAL(100)
NFS biod(6)
d omvs,pid=16777456
BPXO040I 15.30.01 DISPLAY OMVS 637
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE
0E08A00000000000 005E6DF0 OMVS .927 RCV FU
0E08F00000000001 005E6C58 .001 PTX JYNV
0E09300000000002 005E6AC0 7.368 PTX JYNV
0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV
0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV
0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Developer for System z utiliza sistemas de archivos de z/OS UNIX para almacenar varios tipos de datos, como archivos de registro y temporales. Utilice el mandato de z/OS UNIX df para ver cuántos descriptores de archivos quedan disponibles, y cuánto espacio libre queda hasta que se crea la siguiente extensión del conjunto de datos HFS o zFS subyacente.
$ df
Montado en Filesystem Disp/Total Archivos Estado
/tmp (OMVS.TMP) 1393432/1396800 4294967248 Disponible
/u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Disponible
/usr/lpp/rdz (OMVS.LPP.FEK) 3062/43200 4294967147 Disponible
/var (OMVS.VAR) 27264/31680 4294967054 Disponible
De forma predeterminada, Developer for System z intenta añadir 30 usuarios a una única agrupación de hebras. Sin embargo, nuestros requisitos indican que el tiempo de espera de inactividad estará activo. La Tabla 31 muestra que esto añadirá una hebra por cada cliente conectado. Esta hebra es una hebra temporizadora, por lo que está activa constantemente. Esto impedirá que RSE coloque a 30 usuarios en una única agrupación de hebras, dado que 10+30*(17+1)=550 y maximum.threads se ha establecido en 520 de forma predeterminada.
Podríamos aumentar maximum.threads, pero debido al requisito de tener una media de 20 MB de almacenamiento dinámico Java por usuario, decidimos reducir maximum.clients a 25 (10+25*18 = 460). Con esto, sigue dentro del tamaño de almacenamiento dinámico Java máximo de 512 MB predeterminado (20*25 = 500).
Con 25 clientes por agrupación de hebras y la necesidad de admitir 500 conexiones, sabemos que necesitaremos 20 espacios de direcciones de agrupaciones de hebras.
3 + 2*A + N*(x + y + z) + (2 + N*0.01)
3 + 2*20 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1050
x + y + z
1 + 1 + 1 = 3
6 + 3*A + N*(x + y + z) + (10 + N*0.05)
6 + 3*20 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1591
4 + 3*A
4 + 3*20 = 64
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
12 + N*(19 + x + y + z) + (20 + N*0.1)
12 + 25*(19 + 1 + 4 + 0) + (20 + 25*0.1) = 635
3 + N+ (20 + N*0.1)
3 + 500+ (20 + 500*0.1) = 573
4
4
500 + 3 = 503
Los 3 ID de usuario adicionales son para STCJMON, STCDBM y STCRSE, los ID de usuario de tarea iniciada de Developer for System z.
no cambia
no cambia
Este cambio es opcional; RSE iniciará nuevas agrupaciones de hebras según sea necesario
mínimo de 1591, almacenamiento intermedio extra añadido para otras
tareas que las de
Developer
for System z
mínimo de 64, almacenamiento intermedio extra añadido en caso de que
las agrupaciones de hebra de RSE
den soporte a menos de los 25
clientes previstos
debe ser, como mínimo, 573 (para el Supervisor de trabajos JES) si
THREADSMAX en el
segmento OMVS del ID de usuario STCRSE se utiliza para
establecer el límite para RSE
(mínimo 635)
debe ser, como mínimo, 573 (para el Supervisor de trabajos JES) si
THREADSMAX en el
segmento OMVS del ID de usuario STCRSE se utiliza para
establecer el límite para RSE
(mínimo 635)
mínimo de 503, almacenamiento intermedio extra añadido para
tareas que no sean las de
Developer
for System z
no cambia (valor predeterminado del sistema 200 MB), utilizamos
ASSIZEMAX en el segmento OMVS
del ID de usuario STCRSE
mínimo de 1050, almacenamiento intermedio extra añadido para otras
tareas que las de
Developer
for System z
2 GB
Después de activar los límites del sistema según se explica en Definición de límites, podemos empezar a supervisar la utilización de recursos por parte de Developer for System z para ver si es necesario ajustar varias variables. La Figura 31 muestra el uso de recursos después de que 499 usuarios hayan iniciado sesión. (El ejemplo de la figura muestra sólo el inicio de sesión. No se han indicado acciones de usuario en el ejemplo.)
F RSED,APPL=D P
BPXM023I (STCRSE)
ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
ProcessId(91 ) Memory Usage(17%) Clients(25) Order(2)
ProcessId(122 ) Memory Usage(17%) Clients(25) Order(3)
ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)
F RSED,APPL=D P,D
BPXM023I (STCRSE)
ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 17 17 100
CLIENTS 25 25 25
MAXFILEPROC 365 366 64000
MAXPROCUSER 64 64 100
MAXTHREADS 362 363 1500
MAXTHREADTASKS 363 363 1500
TASID
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.00 1780 73
RSED 5.88 95.2M 41958
RSED1 8.26 190.1M 58669
RSED1 8.17 187.0M 58605
RSED2 8.06 185.3M 58653
RSED2 8.19 183.1M 60209
RSED3 8.12 189.1M 58650
RSED3 8.03 186.7M 58590
RSED4 8.15 188.2M 58646
RSED4 5.50 182.5M 58585
RSED5 7.72 184.4M 58631
RSED5 7.82 184.1M 58576
RSED6 7.14 184.1M 58622
RSED6 6.27 186.9M 58583
RSED7 5.17 185.1M 58804
RSED7 6.57 185.2M 58621
RSED7 5.86 182.8M 58565
RSED8 0.36 1560 2459
RSED8 7.94 184.1M 58615
RSED8 7.45 181.8M 58548
RSED9 8.16 190.6M 58802
RSED9 7.62 183.8M 58610
RSED9 7.36 177.7M 57478
z/OS es un sistema operativo sumamente personalizable, y los cambios de sistema (a veces pequeños) pueden afectar considerablemente al rendimiento global. En este capítulo se resaltan algunos de los cambios que se pueden hacer para mejorar el rendimiento de Developer for System z.
Consulte las publicaciones MVS Initialization and Tuning Guide (SA22-7591) y UNIX System Services Planning (GA22-7800) para obtener más información acerca del ajuste del sistema.
Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de zFS.
Cada proceso z/OS UNIX que tenga una STEPLIB que se propague de padre a hijo o a través de un exec consumirá unos 200 bytes de ECSA (área de almacenamiento común ampliada). Si no se define ninguna variable de entorno STEPLIB, o si se define como STEPLIB=CURRENT, z/OS UNIX propaga todas las asignaciones de TASKLIB, STEPLIB y JOBLIB actualmente activas durante una función fork(), spawn() o exec().
Developer for System z tiene el valor predeterminado STEPLIB=NONE codificado en rsed.envvars, como se describe en la sección dedicada al archivo de configuración rsed.envvars. Por los motivos mencionados más arriba, no debe cambiar esta directiva, y sí debería colocar los conjuntos de datos tomados como objetivo en LINKLIST o en LPA (área de módulos residentes).
Algunas bibliotecas del sistema y algunos módulos de carga se utilizan intensivamente en z/OS UNIX y en las actividades de desarrollo de aplicaciones. El hecho de mejorar el acceso a ellas (por ejemplo, añadirlas al área de módulos residentes, LPA) puede mejorar el rendimiento del sistema. En el manual MVS Initialization and Tuning Reference (SA22-7592) hallará más información sobre cómo cambiar los miembros SYS1.PARMLIB descritos a continuación:
Los programas C (incluida la shell de z/OS UNIX), cuando se ejecutan, suelen utilizar rutinas de la biblioteca de tiempo de ejecución de Language Environment (LE). Como promedio, unos 4 MB de la biblioteca de tiempo de ejecución se cargan en memoria para cada espacio de direcciones que se ejecute en un programa habilitado para LE, y se copian en cada bifurcación.
CEE.SCEELPA
El conjunto de datos CEE.SCEELPA contiene un subconjunto de rutinas de tiempo de ejecución de LE, que se utilizan muy a menudo en z/OS UNIX. Debe añadir este conjunto de datos a SYS1.PARMLIB(LPALSTxx) para obtener el máximo rendimiento. Así, los módulos se leen del disco una sola vez y se colocan en una ubicación compartida.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Conviene asimismo colocar las bibliotecas de tiempo de ejecución de LE CEE.SCEERUN y CEE.SCEERUN2 en LINKLIST, añadiendo los conjuntos de datos a SYS1.PARMLIB(LNKLSTxx) o a SYS1.PARMLIB(PROGxx). Ello elimina la actividad adicional que supone utilizar la STEPLIB de z/OS UNIX, y se reduce la entrada/salida debido a la gestión por parte de LLA y VLF, o de productos similares.
Si decide que no quiere colocar estas bibliotecas en LINKLIST, debe configurar la sentencia STEPLIB pertinente en rsed.envvars, como se describe en la sección dedicada al archivo de configuración rsed.envvars. Aunque este método siempre utiliza almacenamiento virtual adicional, podrá mejorar el rendimiento definiendo las bibliotecas de tiempo de ejecución de LE en LLA o en un producto similar. Esto reduce la E/S necesaria para cargar los módulos.
En los sistemas cuya actividad principal es el desarrollo de aplicaciones, el rendimiento también podrá mejorar si coloca el editor de enlaces en la LPA dinámica, añadiendo las líneas siguientes a SYS1.PARMLIB(PROGxx):
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN)
LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
En el caso del desarrollo C/C++, también puede añadir el conjunto de datos de compilador CBC.SCCNCMP a SYS1.PARMLIB(LPALSTxx).
Las sentencias anteriores son ejemplos de posibles candidatos a la LPA, pero las necesidades en su local puede ser distintas. Consulte la publicación Language Environment Customization (SA22-7564) para obtener más información acerca de la colocación de otros módulos de carga de LE en la LPA dinámica. Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de la colocación de módulos de carga de compilador C/C++ en la LPA dinámica.
Cada local tiene sus necesidades específicas, y puede personalizar el sistema operativo z/OS para poder sacar el mayor partido de los recursos disponibles y responder a dichas necesidades. Con la gestión de cargas de trabajo (WLM), se definen objetivos de rendimiento y se asigna una importancia de negocio a cada objetivo. Los objetivos se definen para el trabajo en términos de negocio, y el sistema decide la cantidad de recursos (por ejemplo, la cantidad de CPU y de almacenamiento) que hay que dar al trabajo para responder a su objetivo.
El rendimiento de Developer for System z se puede equilibrar estableciendo los objetivos correctos para sus procesos. A continuación figuran algunas directrices generales:
Consulte la publicación MVS Planning Workload Management (SA22-7602) para obtener más información sobre este tema.
Con una memoria dinámica de tamaño fijo, no se producen ampliaciones ni contracciones de la memoria dinámica, lo que puede aumentar notablemente el rendimiento en algunas situaciones. Sin embargo, el hecho de utilizar una memoria dinámica de tamaño fijo no suele ser una buena idea, porque retarda el inicio de la recogida de basura hasta que la memoria dinámica esté llena, y en ese momento pasará a ser una tarea importante. También aumenta el riesgo de fragmentación, lo que exige una compactación de la memoria dinámica. Por lo tanto, solo debe utilizar memorias dinámicas de tamaño fijo después de haberlas probado debidamente o cuando así lo indique el centro de soporte de IBM. Consulte la publicación Java Diagnostics Guide (SC34-6650) para obtener más información acerca de los tamaños del almacenamiento dinámico y la recogida de basura.
Los tamaños inicial y máximo del almacenamiento dinámico de una z/OS Java Virtual Machine (JVM) se pueden establecer con las opciones de línea de mandatos -Xms (inicial) y -Xmx (máximo) de Java.
En Developer for System z, las opciones de línea de mandatos Java se definen en la directiva _RSE_JAVAOPTS del archivo rsed.envvars, como se describe en el apartado "Definición de parámetros de inicio de Java adicionales con _RSE_JAVAOPTS" de la Guía de configuración de host (SC11-3660).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
La opción -Xquickstart puede utilizarse para mejorar el tiempo de inicio de algunas aplicaciones Java. -Xquickstart hace que el compilador JIT (Just In Time) se ejecute con un subconjunto de optimizaciones; es decir, una compilación rápida. Esta compilación rápida permite mejorar el tiempo de inicio.
La opción -Xquickstart es adecuada para aplicaciones de corta ejecución, especialmente para aquellas en las que el tiempo de ejecución no está concentrado en un pequeño número de métodos. -Xquickstart puede degradar el rendimiento si se utiliza en aplicaciones de larga ejecución que contienen métodos dinámicos.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
La máquina virtual Java (JVM) de IBM versión 5 y posteriores permite compartir clases de aplicación y programa de arranque entre las JVM almacenándolas en una memoria caché de memoria compartida. El hecho de compartir clases reduce el consumo global de memoria virtual cuando hay más de una JVM que comparte una caché. El hecho de compartir clases también reduce el tiempo de arranque de una JVM después de haberse creado la caché.
La caché de clases compartidas es independiente de las JVM activas y persiste más allá del tiempo de vida de la JVM que creó la caché. Dado que la caché de clases compartidas persiste más allá del tiempo de vida de las JVM, la caché se actualiza dinámicamente para reflejar las modificaciones que se hayan podido hacer en los JAR o en las clases del sistema de archivos.
La actividad adicional que supone crear y poblar una caché nueva es mínima. El coste en tiempo del arranque de una sola JVM se suele situar entre 0 y el 5% más de tiempo si se compara con un sistema que no utilice clases compartidas, y depende de la cantidad de clases cargadas. La mejora del tiempo de arranque de JVM con una caché poblada se suele situar entre el 10% y el 40% menos de tiempo si se compara con un sistema que no utilice clases compartidas, y depende del sistema operativo y del número de clases que se carguen. Si hay múltiples JVM en ejecución concurrente, el tiempo de arranque global mejorará.
Consulte la publicación Java SDK and Runtime Environment User Guide para obtener más información acerca del compartimiento de clases.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal
#_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
_RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
El tamaño máximo de la caché teórica compartida es 2 GB. El tamaño de caché que se puede especificar está limitado por la cantidad de memoria física y de espacio de intercambio físico disponible en el sistema. Dado que el espacio de direcciones virtuales de un proceso se comparte entre la memoria caché de clases compartidas y el almacenamiento dinámico de Java, el aumento del tamaño máximo del almacenamiento dinámico de Java reducirá el tamaño de la memoria caché de clases compartidas que puede crear.
El acceso a la caché de clases compartidas está limitado por los permisos del sistema operativo y por los permisos de la seguridad Java.
Por defecto, las cachés de clases se crean con seguridad a nivel de usuario, por lo que el usuario que ha creado la caché es el único que puede acceder a ella. En z/OS UNIX, existe una opción, groupAccess, que da acceso a todos los usuarios del grupo primario del usuario que creó la caché. Sin embargo, sea cual sea el nivel de acceso que se emplee, el único que puede destruir una caché es el usuario que la ha creado o un usuario root (UID 0).
Consulte Java SDK and Runtime Environment User Guide para obtener más información sobre las opciones de seguridad adicionales usando un SecurityManager de Java.
Estos valores afectan a la cantidad de páginas de memoria compartida disponibles para la JVM. El tamaño de páginas compartidas en el caso de un servicio de sistema z/OS UNIX de 31 bits se ha fijado en 4 KB. Las clases compartidas intentan crear una caché de 16 MB por defecto. Por tanto, establezca IPCSHMMPAGES en un valor superior a 4096.
Si establece un tamaño de caché utilizando -Xscmx, la JVM redondeará el valor por exceso al megabyte más cercano. Debe tenerlo en cuenta cuando establezca IPCSHMMPAGES en su sistema.
Estos valores afectan a la cantidad de semáforos disponibles en los procesos UNIX. Las clases compartidas utilizan semáforos IPC para la comunicación entre máquinas virtuales Java (JVM).
La caché de clases compartidas necesita espacio en disco en el que almacenar información de identificación sobre las cachés que existen en el sistema. Esta información se almacena en /tmp/javasharedresources. Si el directorio de información de identificación se suprime, la JVM no puede identificar las clases compartidas en el sistema y debe volver a crear la caché.
$ java -Xshareclasses:listAllCaches
Caché compartida OS shmid en uso Hora de última desconexión
RSE 401412 0 Lun Jun 18 17:23:16 2007
No se ha podido crear la máquina virtual Java (JVM).
$ java -Xshareclasses:name=RSE,printStats
Estadísticas actuales de la caché "RSE":
dirección base = 0x0F300058
dirección final = 0x0F8FFFF8
puntero de asignación = 0x0F4D2E28
tamaño de caché = 6291368
bytes libres = 4355696
bytes de ROMClass = 1912272
bytes de metadatos = 23400
% de metadatos usados = 1%
nº de ROMClasses = 475
nº de vías de acceso de clases = 4
nº de URL = 0
nº de símbolos = 0
nº de clases obsoletas = 0
% de clases obsoletas = 0%
La caché está 30% llena
No se ha podido crear la máquina virtual Java (JVM).
$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I La caché compartida "RSE" se ha destruido
No se ha podido crear la máquina virtual Java (JVM).
Los clientes de Developer for System z versión 8.0.1 y posteriores pueden tomar la información de actualización de producto y de los archivos de configuración del cliente desde el host cuando se conectan, asegurando que todos los cliente tienen valores comunes y que están actualizados.
Desde la versión 8.0.3, el administrador del cliente puede crear varios conjuntos de configuraciones de cliente y varios escenarios de actualización del cliente para ajustar las necesidades de distintos grupos de desarrolladores. Esto permite a los usuarios recibir una configuración personalizada basada en un criterio como la pertenencia de un grupo LDAP o permiso para un perfil de seguridad.
Los proyectos de z/OS se pueden definir individualmente a través de la perspectiva Proyectos de z/OS en el cliente; los proyectos de z/OS también se pueden definir de forma centralizada en el host y luego propagarse al cliente en base a usuarios individuales. Estos "proyectos basados en host" tienen el mismo aspecto y funcionan exactamente igual que proyectos definidos en el cliente, salvo porque el cliente no puede modificar la estructura, miembros y propiedades, y sólo se puede acceder a ellos cuando se está conectado al host.
pushtoclient.properties indica al cliente si estas funciones están habilitadas, y dónde se almacenan los datos relacionados. Para obtener más información, consulte "(Opcional) pushtoclient.properties, Control de cliente basado en host" en la Guía de configuración del host SC11-3660 (SC23-7658).
Para obtener detalles sobre cómo el administrador del cliente y el gestor del proyecto de desarrollo pueden realizar las tareas que tienen asignadas, consulte el Information CenterDeveloper for System z Information Center (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html).
Envío a cliente está diseñado para almacenar datos específicos de sistema por cada sistema, mientras matiene datos comunes (globales) en un único sistema (el sistema primario) para reducir el esfuerzo de gestión. El sistema primario está identificado por la directiva primary.system en pushtoclient.properties. El valor predeterminado es false.
Asegúrese de que tiene un sistema (y sólamente uno) definido como sistema primario. Los administradores del cliente Developer for System z no pueden exportar datos de configuración global a menos que el sistema de destino sea un sistema primario. Los clientes de Developer for System z podrían mostrar un comportamiento errático al conectarse a varios sistemas primarios con configuraciones no sincronizadas.
La regla "sólo uno" no se aplica cuando varios sistemas comparten la configuración de Developer for System z (/etc/rdz) y los metadatos de Envío a cliente (/var/rdz/pushtoclient). Como la configuración está compartida, todos los sistemas implicados se indentifican como el sistema primario. Pero en tanto que todos los sistemas también comparten los metadatos, esta duplicación no es un problema.
La directiva pushtoclient.folder en pushtoclient.properties identifica el directorio base en el que se almacenan los metadatos de Envío a cliente. El valor predeterminado es /var/rdz/pushtoclient.
El directorio base tiene el archivo de configuración de Envío a cliente raíz, keymapping.xml. El resto de metadatos está en subdirectorios.
La mayoría de los subdirectorios se crean dinámicamente cuando el administrador de cliente exporta la configuración de estación de trabajo de Envío a cliente. Estos subdirectorios agrupan los metadatos por asunto, como correlaciones y preferencias. A medida que hay más componentes de cliente de Developer for System z disponibles para ser gestionados por el Envío a cliente, se crean más subdirectorios de forma dinámica. Consulte el asistente de exportación en el cliente de Developer for System z (Archivo > Exportar… > Rational Developer for System z > Archivos de configuración) para ver qué se almacena en estos subdirectorios.
Para obtener más información sobre la creación de estos subdirectorios, consulte "Configuración de personalización" en el capítulo "Personalización básica" de la Guía de configuración de host SC11-3660 (SC23-7658).
De forma predeterminada (consulte la directiva file.permission en pushtoclient.properties), todos los archivos y directorios creados en el directorio base reciben la máscara de bits de permiso 775 (rwxrwxr-x), lo que permite al propietario y al grupo predeterminado del propietario acceso de lectura y grabación a la estructura de directorios y los archivos que contiene. El resto sólo tiene acceso de lectura a la estructura de directorios y los archivos que contiene.
Es importante establecer el UID de propietario (ID de usuario) y GID (ID de grupo) para estos directorios antes de iniciar la configuración del Envío a cliente.
ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))
chown –R rdzadm1:rdzadmin /var/rdz/pushtoclient
chmod –R 775 /var/rdz/pushtoclient
Para obtener más información sobre los mandatos RACF de ejemplo, consulte Security Server RACF Command Language Reference (SA22-7687). Para obtener más información sobre los mandatos de z/OS UNIX de ejemplo, consulte UNIX System Services Command Reference (SA22-7802). Para obtener información adicional, consulte Estructura de directorios de z/OS UNIX.
Los metadatos de Enviar al cliente utilizan una cantidad de espacio en disco razonablemente pequeña en z/OS UNIX, porque el grueso de los metadatos esta en archvios XML codificados en UTF-8. Tenga en cuenta el código de producto utilizado para los escenarios de actualización del cliente se puede almacenar en cualquier lugar de la red; no tiene que estar almacenado en z/OS UNIX, ya que los metadatos de Enviar al cliente relacionados (denominados archivos de respuestas), indican al cliente la ubicación correcta.
Cuando un cliente de Developer for System z (versión 8.0.1. o posterior) se conecta al host, lee las definiciones en pushtoclient.properties. Si la directiva config.enabled está habilitada, el cliente compara su configuración actual con las definiciones en los metadatos de Envío al cliente. Si se encuentran diferencias, el cliente inicia un asistente que recupera los datos necesarios y activa la configuración según determine Envío al cliente.
La directiva reject.config.updates en pushtoclient.properties controla si un usuario tiene permiso para rechazar las actualizaciones de configuración que Envío al cliente está a punto de entregar.
Un cliente de Developer for System z (versión 8.0.1 y posteriores) tiene un asistente, que el administrador del cliente puede utilizar para exportar la configuración actual que, por otro lado, podrán importar todos los clientes de Developer for System z por medio de Envío al cliente. Tenga en cuenta que esta función está disponible en todos los clientes, por lo que debe asegurarse de que sólo los administradores del cliente tengan permiso de escritura para los directorios de z/OS UNIX en los que se encuentran los metadatos del Envío al cliente (/var/rdz/pushtoclient).
Para habilitar el soporte de grupos, tanto el cliente como el host deben tener la versión 8.0.3 o posterior, según se indica en la documentación Varios grupos de desarrollador.
Cuando un cliente de Developer for System z (versión 8.0.1. o posterior) se conecta al host, lee las definiciones en pushtoclient.properties. Si la directiva product.enabled está habilitada, el ciente compara su versión del producto actual con las definiciones en los metadatos de Envío al cliente. Si se encuentran diferencias, el cliente inicia un asistente que recupera los datos necesarios y activa la configuración según determine Envío al cliente.
La directiva reject.product.updates en pushtoclient.properties controla si un usuario tiene permiso para rechazar las actualizaciones del producto que Envío al cliente está a punto de entregar.
Para habilitar el soporte de grupos, tanto el cliente como el host deben tener la versión 8.0.3 o posterior, según se indica en la documentación Varios grupos de desarrollador.
Desde la versión 8.0.3, el administrador del cliente puede crear varios conjuntos de configuraciones de cliente y varios escenarios de actualización del cliente para ajustar las necesidades de distintos grupos de desarrolladores. Esto permite a los usuarios recibir una configuración personalizada basada en un criterio como la pertenencia de un grupo LDAP o permiso para un perfil de seguridad.
El soporte para varios grupos de desarrolladores, cada uno de ellos con su propios requisitos de actualización de cliente y configuración de cliente, se habilita mediante la asignación del valor desado a las directivas relacionadas (config.enabled y product.enabled) en pushtoclient.properties, según se indica en la Tabla 36.
*.enabled value | Función habilitada | Soporte para varios grupos |
---|---|---|
Falso | No | No |
Verdadero | Sí | No |
LDAP | Sí | Sí, basado en pertenencia a grupos LDAP FEK.PTC.*.ENABLED.sysname.devgroup |
SAF | Sí | Sí, basado en permiso a perfiles de seguridad FEK.PTC.*.ENABLED.sysname.devgroup |
Tenga en cuenta que cuando la función está habilitada (esto incluye el valor TRUE), los desarrolladores siempre son parte de un grupo predeterminado. Un desarrollador puede no ser ser parte de ningún grupo adicional, o bien ser parte de uno o varios grupos.
Se puede hacer que el rechazo de las actualizaciones también sea condicional, según se muestra en la Tabla 37.
Valor reject.*.updates | Función habilitada |
---|---|
Falso | No |
Verdadero | Sí |
LDAP | Depende de la pertenencia a grupo LDAP FEK.PTC.REJECT.*.UPDATES.sysname.** |
SAF | Depende del permiso al perfil de seguridad FEK.PTC.REJECT.*.UPDATES.sysname.** |
Tenga en cuenta que las directivas de pushtoclient.properties funcionan de forma independiente entre ellas. Puede asignar cualquier valor con soporte a cualquier directiva. No hay requisito alguno por el que los valores deban ser iguales.
Consulte Selección de grupo basada en LDAP y Selección de grupo basada en SAF para obtener detalles sobre la configuración necesaria para la función respectiva. Para obtener más información sobre la habilitación de varios soportes de grupo, consulte "(Opcional) pushtoclient.properties, control del cliente basado en host" en la publicación Guía de configuración de host SC11-3660 (SC23-7658).
Cuando la función *.enabled está habilitada (esto incluye el valor TRUE) en pushtoclient.properties, los desarrolladores siempre son parte de un grupo predeterminado para la función relacionada. Un desarrollador puede no ser ser parte de ningún grupo adicional, o bien ser parte de uno o varios grupos.
Para limitar la complejidad de la aplicación de cambios definidos en varios grupos, Developer for System z limita las definiciones a utilizar, en base a una selección realizada por el usuario.
Grupos adicionales | Definiciones usadas |
---|---|
Ninguno | Valor predeterminado |
Uno | Predeterminada o (predeterminada + grupo) |
Varios | Predeterminada o (predeterminada + 1 grupo) |
Aunque un desarrollador puede ser parte de varios grupos de forma simultánea, el espacio de trabajo del desarrollador no puede. El espacio de trabajo activo debe estar enlazado a un grupo de configuración específico (que puede ser el grupo predeterminado) para recibir actualizaciones de producto o de configuración. Una vez realizado el enlace, no se puede deshacer. Se debe crear un espacio de trabajo nuevo si hace falta un nuevo enlace de grupo.
Cuando un espacio de trabajo que no tenga enlace de grupo de configuración se conecta al host y config.enabled indica que la función Envío al cliente está activa, Developer for System z consulta todos los grupos de configuración para determinar a qué grupos pertenece el usuario y solicita al usuario seleccionar un grupo. Tras sucesivas conexiones, sólo se consulta al grupo seleccionado para ver si la pertenencia al grupo aún es válida.
config.enabled | Espacio de trabajo vinculado a este grupo de actualización configuración |
---|---|
Falso | Ninguno |
Verdadero | Valor predeterminado |
LDAP | Predeterminado o grupo (tras solicitud) |
SAF | Predeterminado o grupo (tras solicitud) |
Cuando un espacio de trabajo que no tenga enlace de grupo se conecta al host y product.enabled indica que la función Envío al cliente está activa, Developer for System z consulta todos los grupos para determinar a qué grupos pertenece el usuario, y solicita al usuario seleccionar un grupo. Tras sucesivas conexiones, sólo se consulta al grupo seleccionado para ver si la pertenencia al grupo aún es válida.
product.enabled | Espacio de trabajo vinculado a este grupo de actualización de grupo |
---|---|
Falso | Ninguno |
Verdadero | Valor predeterminado |
LDAP | Predeterminado o grupo (tras solicitud) |
SAF | Predeterminado o grupo (tras solicitud) |
Las directivas reject.*.updates pueden trabajar con y sin definiciones de grupos. Si se utilizan grupos para reject.*.updates, se utiliza el enlace de grupo de la directiva relacionada *.enabled. Cuando hay una actualización, Developer for System z determina si el usuario tiene permiso para rechazarla, y actúa en consecuencia.
El soporte de grupo para las directivas reject.*.updates es nuevo en la versión 9.1.0 y requiere que el host y el cliente de Developer for System z estén en la versión 9.1.0 o posterior. El soporte cambia el modo en que se procesan las palabras clave LDAP y SAF.
Antes de la versión 9.1.0, estar en la lista de acceso para FEK.PTC.REJECT.*.UPDATES.sysname era suficiente para rechazar una actualización, independientemente del enlace de grupo de espacio de trabajo. Desde la versión 9.1.0, FEK.PTC.REJECT.*.UPDATES.sysname sólo se utiliza para rechazar actualizaciones por espacios de trabajo vinculados al grupo predeterminado. Los espacios de trabajo vinculados a un grupo requieren que esté en la lista de acceso para FEK.PTC.REJECT.*.UPDATES.sysname.groupname para rechazar actualizaciones.
La personalización inicial del producto crea el directorio grouping/ en /var/rdz/pushtoclient/. El administrador del cliente es responsable de añadir los directorios <devgroup>/ a /var/rdz/pushtoclient/grouping/.
Tenga en cuenta que durante la personalización inicial de producto, se crean los directorios projects/, install/ e install/responsefiles/ en /var/rdz/pushtoclient/. El administrador de cliente debe repetir las acciones make-directory (crear directorio) en /var/rdz/pushtoclient/grouping/<devgroup>/ si se necesitaran escenarios de actualización de productos específicos de grupos o proyectos basados en host específicos de grupos.
La secuencia de mandatos z/OS UNIX de ejemplo siguiente crea los subdirectorios con la máscara de bits de permisos correcta. Los mandatos los debe ejecutar el administrador del cliente para evitar problemas de propiedad.
saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir –m775 <devgroup>
cd <devgroup>
mkdir –m775 install
mkdir –m775 install/responsefiles
mkdir –m775 projects
umask $saved_umask
Para obtener más información sobre los mandatos de z/OS UNIX de ejemplo, consulte UNIX System Services Command Reference (SA22-7802).
/var/rdz/pushtoclient/grouping/<devgroup>
para
cada grupo de Envío a cliente.Aunque LDAP (Lightweight Directory Access Protocol) es el nombre de un protocolo basado en TCP/IP, se suele utilizar para describir un conjunto de sevicios de directorio distribuidos. Como una base de datos, un directorio es un conjunto estructurado de registros. Developer for System z puede utilizar un servidor LDAP como base de datos jerárquica sencilla, en la que los grupos tienen uno o más miembros.
Cuando utilice definiciones en su servidor LDAP como mecanismo de selección (el valor de LDAP se especifica para las directivas en pushtoclient.properties), Developer for System z comprueba la pertenecia de los nombres de grupos listados en la Tabla 41 para determinar a qué grupo de desarrolladores pertenece el usuario y si el usuario tiene permiso para rechazar actualizaciones.
Nombre de grupo (cn=) | Resultado |
---|---|
FEK.PTC.CONFIG.ENABLED.sysname.devgroup | El cliente acepta actualizaciones de configuración para el grupo especificado |
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup | El cliente acepta actualizaciones de producto para el grupo especificado |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname | El usuario puede rechazar actualizaciones de configuración cuando el espacio de trabajo está enlazado al grupo predeterminado |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname.devgroup | El usuario puede rechazar actualizaciones de configuración cuando el espacio de trabajo está enlazado al grupo especificado |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname | El usuario puede rechazar actualizaciones de producto cuando el espacio de trabajo está enlazado al grupo predeterminado |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname.devgroup | El usuario puede rechazar actualizaciones de producto cuando el espacio de trabajo está enlazado al grupo especificado |
El valor de devgroup coincide con el nombre de grupo asignado a un grupo específico de desarrolladores. Tenga en cuenta que el nombre de grupo es visible en clientes de Developer for System z.
El valor de sysname coincide con el nombre de sistema del sistema de destino.
Un usuario puede seleccionar enlazar un espacio de trabajo al grupo predeterminado para actualizaciones de configuración si config.enabled en pushtoclient.properties está establecido en SAF o LDAP. Si config.enabled está establecido en TRUE, el espacio de trabajo se enlaza automáticamente al grupo predeterminado.
Un usuario puede seleccionar enlazar un espacio de trabajo al grupo predeterminado para actualizaciones de producto si product.enabled en pushtoclient.properties está establecido en SAF o LDAP. Si product.enabled está establecido en TRUE, el espacio de trabajo está enlazado automáticamente al grupo predeterminado.
El soporte de grupo para las directivas reject.*.updates es nuevo en la versión 9.1.0 y cambia el modo en que se procesan las palabras claveLDAP y SAF.
La Figura 32 es un ejemplo de definición de LDAP para un grupo y usuario, expresados en formato LDIF.
# Definición de grupo
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com
# Definición de usuario
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users
Hay disponible una amplia selección de servidores LDAP tanto gratuitos como comerciales. Un ejemplo es IBM Tivoli Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/). También hay una amplia selección de herramientas basadas en la GUI y en la línea de mandatos para gestionar un servidor LDAP.
Tal y como se ha mencionado en Esquema de LDAP, los usuarios deben estar definidos en el servidor LDAP. Para reducir el esfuerzo de gestión, lo mejor es colocar el esquema del Envío a cliente en un servidor LDAP que ya tenga acceso a todas las definiciones de usuarios. Por ejemplo, puede utilizar el IBM Tivoli Directory Server activo en z/OS usando una base de datos SDBM (que es una envoltura para su base de datos de seguridad).
Según las políticas del sitio, el esquema del Envío a cliente en el servidor LDAP podría estar gestionado por el administrador de cliente. Esto reduciría las necesidades de colaboración, así como posibles retrasos y errores de comunicación.
Una ventaja de la gestión de LDAP por parte del administrador de cliente es que el esquema del Envío a cliente no tiene nada confidencial ni relacionado con la seguridad. Cuando las definiciones de usuario están disponibles para el servidor LDAP a través de otros esquemas, los objetos LDAP de Developer for System z determinan qué opciones tiene un desarrollador en la selección del diseño del espacio de trabajo y las actualizaciones automáticas de producto del cliente Developer for System z.
Cualquier servidor de bases de datos que tenga soporte para el protocolo LDAP se puede utilizar para albergar el esquema de Envío a cliente de Developer for System z. Por lo tanto, Developer for System z le permite especificar la información necesaria para conectar al servidor LDAP. También puede especificar un sufijo que haga que la base de datos sea exclusiva dentro del servidor LDAP.
Directiva rsed.envvars | Valor predeterminado |
---|---|
_RSE_LDAP_SERVER | Sistema de hosts locales |
_RSE_LDAP_PORT | 389 |
_RSE_LDAP_PTC_GROUP_SUFFIX | "O=PTC,C=DeveloperForZ" |
Supongamos que una empresa tiene Developer for System z activo en el sistema CDFMVS08. IBM Tivoli Directory Server, también activo en CDFMVS08, se usa como servidor LDAP. El servidor LDAP esta configurado según se describe en Adición del extremo de Envío a cliente a LDAP.
Cada grupo de desarrolladores precisa de los archivos de configuración de cliente específicos, y todos los desarrolladores están sujetos al mismo control de versiones del cliente. Al contrario que los administradores del cliente, los desarrolladores no tienen permiso para rechazar ninguno de los cambios que presente Envío a cliente.
El administrador de cliente y el administrador de LDAP acuerdan usar los nombres de grupo BANKING e INSURANCE para las actualizaciones de configuración.
# nombre de archivo ds.conf
# reniciar la tarea GLDSRV iniciada para activar los cambios
# global section
adminDN "cn=LDAP admin"
adminPW password
listen ldap://:389
schemaPath /etc/ldap
# SDBM back-end section (RACF)
database SDBM GLDBSD31/GLDBSD64
suffix "cn=RACF,o=IBM,c=US"
# LDBM back-end section (z/OS UNIX files)
database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
suffix "o=PTC,c=DeveloperForZ"
databaseDirectory /var/ldap/ldbm/rdz
mkdir -p /var/ldap/ldbm/rdz
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.IBM.ldif
ldapadd -D "cn=LDAP admin" -w password -f
/u/ibmuser/ptc_root.ldif
donde /u/ibmuser/ptc_root.ldif tiene lo siguiente:dn: o=PTC,c=DeveloperForZ
objectclass: top
objectclass: organization
o: PTC
Añada los distintos objetos de grupo LDAP al esquema, y haga que el administrador de cliente sea parte de cada uno de ellos. La definición de usuario para el ID de usuario RDZADM1 se obtiene del esquema RACF.
ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif
# configuración de estación de trabajo de bancos
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# proporcionar acceso de administrador al cliente
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# configuración de estación de trabajo de seguros
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# proporcionar acceso de administrador al cliente
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# rechazar actualizaciones de configuración
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# proporcionar acceso de administrador al cliente
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# rechazar actualizaciones de producto
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# proporcionar acceso de administrador al cliente
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
Añadir los desarrolladores a los objetos del grupo LDAP. Las definiciones de usuario para los ID de usuario se toman del esquema de RACF.
ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif
donde /u/ibmuser/ptc_add.ldif tiene lo siguiente:# configuración de estación de trabajo de bancos
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US
# configuración de estación de trabajo de seguros
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US
# BANKING e INSURANCE tienen distintas necesidades de configuración
config.enabled=LDAP
# todos reciben actualizaciones del producto
product.enabled=TRUE
# sólo RDZADMIN puede rechazar actualizaciones de configuración
reject.config.updates=LDAP
# sólo RDZADMIN puede rechazar actualizaciones del producto
reject.product.updates=LDAP
Como no hay escenarios de actualización de productos individualizados, el administrador del cliente no necesita crear o actualizar los subdirectorios install/ e install/responsefiles/ en /var/rdz/pushtoclient/grouping/<devgroup>.
El administrador del cliente debe crear los archivos de respuestas necesarios para las actualizaciones del producto en el directorio de grupo predeterminado, /var/rdz/pushtoclient/install/responsefiles/.
SAF (Servicio de acceso a seguridad, por su siglas en inglés) es una interfaz para acceder a cualquier producto de seguridad de z/OS. Developer for System z puede utilizar esta interfaz para consultar su producto de seguridad y recuperar la información relacionada de Envío a cliente.
Cuando utilice definiciones en su base de datos de seguridad como mecanismo de selección (el valor de SAF se especifica para las directivas en pushtoclient.properties), Developer for System z comprueba los permisos de acceso a los perfiles listados en la Tabla 42 para determinar a qué grupo de desarrolladores pertenece el usuario y si el usuario tiene permiso para rechazar actualizaciones.
Perfil FACILITY | Longitud fija | Acceso necesario | Resultado |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | El cliente acepta actualizaciones de configuración para el grupo especificado |
FEK.PTC.PRODUCT.ENABLED. |
24 | READ | El cliente acepta actualizaciones de producto para el grupo especificado |
FEK.PTC.REJECT.CONFIG. |
30 | READ | El usuario puede rechazar actualizaciones de configuración cuando el espacio de trabajo está enlazado al grupo predeterminado |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname.devgroup | 30 | READ | El usuario puede rechazar actualizaciones de configuración cuando el espacio de trabajo está enlazado al grupo especificado |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | El usuario puede rechazar actualizaciones de producto cuando el espacio de trabajo está enlazado al grupo predeterminado |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname.devgroup | 31 | READ | El usuario puede rechazar actualizaciones de producto cuando el espacio de trabajo está enlazado al grupo especificado |
El valor de devgroup coincide con el nombre de grupo asignado a un grupo específico de desarrolladores. Tenga en cuenta que el nombre de grupo es visible en clientes de Developer for System z.
El valor de sysname coincide con el nombre de sistema del sistema de destino.
Un usuario puede seleccionar enlazar un espacio de trabajo al grupo predeterminado para actualizaciones de configuración si config.enabled en pushtoclient.properties está establecido en SAF o LDAP. Si config.enabled está establecido en TRUE, el espacio de trabajo se enlaza automáticamente al grupo predeterminado.
Un usuario puede seleccionar enlazar un espacio de trabajo al grupo predeterminado para actualizaciones de producto si product.enabled en pushtoclient.properties está establecido en SAF o LDAP. Si product.enabled está establecido en TRUE, el espacio de trabajo se enlaza automáticamente al grupo predeterminado.
La columna "Longitud fija" indica la longitud de la parte fija del perfil de seguridad relacionado.
De forma predeterminada, Developer for System z espera que los perfiles FEK.* estén en la clase de seguridad FACILITY. Tenga en cuenta que los perfiles en la clase FACILITY tienen 39 caracteres como máximo. Si la suma de la longitud de la parte del perfil fija (FEK.PTC.<key>.) y la longitud de la parte del perfil específica del sitio (sysname o sysname.devgroup) sobrepasa este número, puede colocar los perfiles en otra clase e indicar a Developer for System z que utilice esta clase en su lugar. Para ello, active _RSE_FEK_SAF_CLASS en rsed.envvars y proporcione el nombre de clase que quiera.
Cada grupo de desarrolladores precisa de los archivos de configuración de cliente específicos, y todos los desarrolladores están sujetos al mismo control de versiones del cliente. Al contrario que los administradores del cliente, los desarrolladores no tienen permiso para rechazar ninguno de los cambios que presente Envío a cliente. La regla de rechazo es válida para todos los sistemas, en preparación para ampliación futura.
El cliente y administrador de seguridad acuerdan usar los nombres de grupo de Envío a cliente BANKING e INSURANCE para las actualizaciones de configuración.
# permitir que RDZADMIN y DEVBANK seleccionen el grupo de Envío a cliente BANKING
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(XFACILIT) –
ID(RDZADMIN DEVBANK) ACCESS(READ)
# permitir que RDZADMIN y DEVINSUR seleccionen el grupo de Envío a cliente INSURANCE
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(XFACILIT) –
ID(RDZADMIN DEVINSUR) ACCESS(READ)
# RDZADMIN puede rechazar actualizaciones de configuración en cualquier
sistema y para cualquier grupo
RDEFINE XFACILIT (FEK.PTC.REJECT.CONFIG.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# RDZADMIN puede rechazar actualizaciones de producto en cualquier
sistema y para cualquier grupo
RDEFINE XFACILIT (FEK.PTC.REJECT.PRODUCT.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# activar cambios
SETROPTS RACLIST(XFACILIT) REFRESH
# BANKING e INSURANCE tienen distintas necesidades de configuración
config.enabled=SAF
# todos reciben actualizaciones del producto
product.enabled=TRUE
# sólo RDZADMIN puede rechazar actualizaciones de configuración
reject.config.updates=SAF
# sólo RDZADMIN puede rechazar actualizaciones del producto
reject.product.updates=SAF
_RSE_FEK_SAF_CLASS=XFACILIT
Como no hay escenarios de actualización de productos individualizados, el administrador del cliente no necesita crear o actualizar los subdirectorios install/ e install/responsefiles/ en /var/rdz/pushtoclient/grouping/<devgroup>/.
El administrador del cliente debe crear los archivos de respuestas necesarios para las actualizaciones del producto en el directorio de grupo predeterminado, /var/rdz/pushtoclient/install/responsefiles/.
Supongamos que mientras la configuración de ejemplo está activa, hay disponible un Developer for System zfix-pack con mejoras importantes, pero la planificación del proyecto bancario es tal que los distintos desarrolladores podrían estar muy preocupados sobre cambios en sus estaciones de trabajo en ese preciso momento del proyecto.
Para resolver el problema, el administrador de seguridad puede proporcionar a todos los desarrolladores de DEVBANK un periodo de gracia en el que pueden elegir si retrasar (rechazar) la actualización.
# inicio del periodo de gracia
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) ACCESS(READ)
# activar cambios
SETROPTS RACLIST(FACILITY) REFRESH
# fin del periodo de gracia
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) DELETE
# activar cambios
SETROPTS RACLIST(FACILITY) REFRESH
Los proyectos de z/OS se pueden definir individualmente a través de la perspectiva Proyectos de z/OS en el cliente; los proyectos de z/OS también se pueden definir de forma centralizada en el host y luego propagarse al cliente en base a usuarios individuales. Estos "proyectos basados en host" tienen el mismo aspecto y funcionan exactamente igual que proyectos definidos en el cliente, salvo porque el cliente no puede modificar la estructura, miembros y propiedades, y sólo se puede acceder a ellos cuando se está conectado al host.
El directorio base para proyectos basados en host está definido (por el administrador del cliente) en /var/rdz/pushtoclient/keymapping.xml, y es /var/rdz/pushtoclient/projects de forma predeterminada.
Los proyectos basados en host también se pueden elegir para participar en la configuración de grupo múltiple tratada en Varios grupos de desarrollador. Esta capacidad de elección quiere decir que los proyectos basados en host también se pueden definir en /var/rdz/pushtoclient/grouping/<devgroup>/projects/.
Cuando un espacio de trabajo está enlazado a un grupo específico, y hay definiciones de proyecto para un usuario en este grupo y en el grupo predeterminado, el usuario recibe las definiciones de proyectos tanto desde el grupo predeterminado como desde el grupo específico.
Developer for System z soluciona estos problemas permitiendo que los administradores de CICS controlen los valores predeterminados de la definición de recursos de CICS y que controlen las propiedades de visualización de un parámetro de definición de recursos de CICS mediante el servidor Definición de recursos de CICS (CRD) que forma parte del Gestor de despliegue de aplicaciones.
Por ejemplo, el administrador de CICS puede suministrar determinados parámetros de definición de recurso CICS que el desarrollador de aplicaciones no puede actualizar. Otros parámetros de definición de recurso CICS pueden ser actualizables, con o sin valores predeterminados suministrados, o el parámetro de definición de recurso CICS puede ocultarse para evitar una complejidad innecesaria.
Una vez que el desarrollador de aplicaciones está satisfecho con las definiciones de recurso CICS, éstas pueden instalarse de inmediato en el entorno de prueba CICS en ejecución, o pueden exportarse las definiciones en un manifiesto para que un administrador de CICS las edite y apruebe. El administrador de CICS puede utilizar el programa de utilidad administrativo (programa de utilidad de proceso por lotes) o la herramienta de Proceso de manifiestos para implementar cambios de definición de recurso.
Consulte el apartado "(Opcional) Gestor de despliegue de aplicaciones" de la Guía de configuración de host (SC11-3660) para obtener más información acerca de las tareas necesarias para configurar el Gestor de despliegue de aplicaciones en el sistema host.
El servidor CRD (definición de recurso CICS) del Gestor de despliegue de aplicaciones consta del propio servidor CRD, un repositorio CRD, las definiciones de recursos CICS asociadas y, al utilizar la interfaz de servicios Web, archivos de enlace de servicio Web y un manejador de mensajes de conducto de ejemplo. El servidor CRD debe ejecutarse en una WOR (Web Owning Region), a la que se hace referencia en la documentación de Developer for System z como región de conexión primaria CICS.
Consulte el Information Center de Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) para obtener más información sobre los servicios del Gestor de despliegue de aplicaciones disponibles en el release actual de Developer for System z.
CICS Transaction Server proporciona en la versión 4.1 y superior soporte para una interfaz HTTP diseñada utilizando los principios de la transferencia de estado representativo (RESTful). Esta interfaz RESTful es ahora la interfaz CICSTS estratégica para las aplicaciones de cliente. La interfaz de servicio web anterior se ha estabilizado, y las mejoras serán únicamente para la interfaz RESTful.
El Gestor de despliegue de aplicaciones sigue esta sentencia de dirección y necesita el servidor CRD de RESTful para todos los servicios que son nuevos Developer for System versión 7.6 o superior.
Las interfaces RESTful y de servicio Web puede estar activas simultáneamente en una única región CICS, si lo desea. En este caso, habrá dos servidores CRD activos en la región. Ambos servidores compartirán el mismo repositorio CRD. Tenga en cuenta que CICS emitirá algunos avisos sobre definiciones duplicadas cuando se defina la segunda interfaz en la región.
Un entorno de prueba CICS puede constar de varias regiones MRO (Opción multiregión) conectadas. Con el tiempo, se han utilizado denominaciones no oficiales para categorizar estas regiones. Son designaciones típicas TOR (región propietaria de terminal, WOR (región propietaria Web), AOR (región propietaria de aplicación) y DOR (región propietaria de datos).
Una WOR (región propietaria Web) se utiliza para implementar el soporte de servicios Web de CICS, y el servidor CRD (definición de recurso CICS) del Gestor de despliegue de aplicaciones debe ejecutarse en esta región. Esta región se conoce en el gestor de despliegue de aplicaciones como la región de conexión primaria CICS. El cliente CRD implementa una conexión de servicio Web con la región de conexión primaria CICS.
Las regiones de conexión no primaria CICS son todas las demás regiones a las que el servidor CRD puede dar servicio. Este servicio incluye la visualización de recursos mediante IBM CICS Explorer y la definición de recursos mediante el editor de definiciones de recurso CICS.
Si se utiliza BAS (Business Application Services) de CICSPlex SM para gestionar las definiciones de recursos CICS de la región de conexión primaria CICS, el servidor CRD puede dar servicio a todas las demás regiones CICS gestionadas por BAS.
Las regiones CICS no gestionadas por BAS requieren cambios adicionales para que el servidor CRD pueda darles servicio.
Las acciones realizadas por el servidor CRD en los recursos CICS se anotan en la cola TD CSDL de CICS, que generalmente señala hacia a la DD MSGUSR de la región CICS.
Si se utiliza CICSPlex SM Business Application Services (BAS) para gestionar sus definiciones de recursos de CICS, la directiva de CICSPlex SM EYUPARM BASLOGMSG se debe establecer en (YES) para que se cree la anotación cronológica.
El conjunto de datos VSAM del repositorio del servidor CRD contiene todas las definiciones de recurso predeterminadas y, por tanto, debe protegerse contra actualizaciones, pero los desarrolladores deben poder leer los valores almacenados en él. Consulte Definir los perfiles de conjunto de datos para obtener mandatos RACF de ejemplo para proteger el repositorio de CRD.
Cuando CICS recibe un mensaje SOAP a través de la interfaz de servicios Web, un conducto lo procesa. Un conducto es un conjunto de manejadores de mensajes que se ejecutan por orden. CICS lee el archivo de configuración del conducto para determinar qué manejadores de mensajes deben invocarse en el conducto. Un manejador de mensajes es un programa en el que pueden realizarse procesos especiales de solicitudes y respuestas de servicios Web.
El Gestor de despliegue de aplicaciones suministra un archivo de configuración de conducto de ejemplo que especifica la invocación de un manejador de mensajes y un programa de proceso de cabeceras SOAP.
El manejador de mensajes de conducto (ADNTMSGH) se utiliza para la seguridad, mediante el proceso del ID de usuario y la contraseña de la cabecera SOAP. El archivo de configuración de conducto de ejemplo hace referencia a ADNTMSGH, que, por lo tanto, se debe colocar en la concatenación RPL de CICS.
CPIH es el ID de transacción predeterminado bajo el que se ejecutará una aplicación invocada por un conducto. Generalmente, CPIH se establece para un nivel de autorización mínimo.
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Estos ID de transacción se establecen mediante el servidor CRD, dependiendo de la operación solicitada. Consulte el apartado "(Opcional) Gestor de despliegue de aplicaciones" de la publicación Guía de configuración de host (SC11-3660) para obtener más información sobre cómo personalizar los ID de transacción.
Transacción | Descripción |
---|---|
ADMS | Para las solicitudes de la herramienta de Proceso de manifiestos para cambiar recursos CICS . Normalmente, está destinado a los administradores de CICS. Esta transacción requiere un alto nivel de autorización. |
ADMI | Para las peticiones que definen, instalan o desinstalan recursos CICS. Esta transacción puede requerir un nivel de autorización medio, dependiendo de las políticas establecidas en la ubicación. |
ADMR | Para todas las demás peticiones que recuperan información de recursos o de entorno de CICS. Esta transacción puede requerir un nivel de autorización mínimo, dependiendo de las políticas establecidas en la ubicación. |
Algunas de las solicitudes de definiciones de recurso realizadas por las transacciones del servidor CRD, o todas ellas, deben protegerse. Como mínimo, los mandatos de actualización (actualizar parámetros de servicio Web predeterminados, parámetros de descriptor predeterminados y enlace de nombre de archivo a nombre de conjunto de datos) deben protegerse para impedir nadie, excepto los administradores de CICS, emita estos mandatos utilizados para establecer valores predeterminados de recursos globales.
Cuando se conecta la transacción, la comprobación de la seguridad de recursos CICS, si está habilitada, se asegura de que el ID de usuario tiene autorización para ejecutar el ID de transacción.
La comprobación de recursos está controlada por la opción RESSEC en la transacción que se ejecuta, por el parámetro de inicialización del sistema RESSEC y, para el servidor CRD, por el parámetro de inicialización del sistema XPCT.
La comprobación de recursos sólo tiene lugar si el parámetro de inicialización del sistema XPCT tiene un valor que no es NO y la opción RESSEC de la definición de TRANSACTION es YES o el valor del parámetro de inicialización del sistema RESSEC es ALWAYS.
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#admincics)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#desarrolladorcics)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
El cifrado SSL de la secuencia de datos está soportada cuando el cliente Gestor de despliegue de aplicaciones utiliza la interfaz de servicios Web para invocar el servidor CRD. La utilización de SSL para esta comunicación está controlada por la palabra clave SSL(YES) en la definición de CICSTS TCPIPSERVICE, tal como se documenta en RACF Security Guide for CICSTS.
CICSTS proporciona la capacidad de proteger recursos, además de los mandatos para manipularlos. Algunas acciones del Gestor de despliegue de aplicaciones pueden fallar si la seguridad está activada pero no está completamente configurada (por ejemplo, otorgar permisos para la manipulación de tipos de recursos nuevos).
Cuando falle una función en el Gestor de despliegue de aplicaciones, examine los registros de CICS para buscar mensajes similares al siguiente, y realice la acción correctiva, tal como se documenta en RACF Security Guide for CICSTS.
DFHXS1111 %date %time %applid %tranid Security violation by user
%userid at netname %portname for resource %resource in class
%classname. Los códigos SAF son (X'safresp',X'safreas'). Los códigos ESM son
(X'esmresp',X'esmreas').
Developer for System z suministra el programa de utilidad administrativo que permite a los administradores de CICS proporcionar los valores predeterminados para las definiciones de recursos CICS. Estos valores predeterminados pueden ser de sólo lectura o pueden ser editables para los desarrolladores de aplicaciones.
El programa de utilidad administrativo se invoca mediante el trabajo de ejemplo ADNJSPAU del conjunto de datos FEK.#CUST.JCL. La utilización de este programa de utilidad requiere acceso de actualización (UPDATE) al repositorio de CRD.
ADNJSPAU se encuentra en FEK.#CUST.JCL, a menos que el programador de sistemas z/OS haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Consulte a sección "Configuración de personalización" de la publicación Guía de configuración de host (SC11-3660) para obtener más detalles.
UPDATE | Un desarrollador de aplicaciones podrá actualizar los atributos situados a continuación de esta palabra clave mediante Developer for System z. Este es también el valor predeterminado para los atributos omitidos. |
PROTECT | Los atributos situados a continuación de esta palabra clave se visualizarán, pero el desarrollador de aplicaciones no podrá actualizarlos mediante Developer for System z. |
HIDDEN | Los atributos situados a continuación de esta palabra clave no se visualizarán, y el desarrollador de aplicaciones no podrá actualizarlos mediante Developer for System z. |
Consulte el siguiente ejemplo de código de ADNJSPAU.
//ADNJSPAU JOB <PARÁMETROS DEL TRABAJO>
//*
//ADNSPAU EXEC PGM=ADNSPAU,REGION=1M
//STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD
//ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
*
* Parámetros de CICSPlex SM
*
DEFINE CPSMNAME( )
*DEFINE STAGINGGROUPNAME(ADMSTAGE)
*
* Regla de exportación de manifiestos
*
DEFINE MANIFESTEXPORTRULE(installOnly)
*
* Valores predeterminados de definición de recurso CICS
* Los atributos omitidos toman por omisión el valor UPDATE.
*
* Atributos predeterminados de DB2TRAN
*
DEFINE DB2TRAN()
UPDATE DESCRIPTION()
ENTRY()
TRANSID()
*
* Atributos predeterminados de DOCTEMPLATE
*
DEFINE DOCTEMPLATE()
UPDATE DESCRIPTION()
TEMPLATENAME()
FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM()
DDNAME(DFHHTML) MEMBERNAME()
HFSFILE()
APPENDCRLF(YES) TYPE(EBCDIC)
*
* Atributos predeterminados de File
*
DEFINE FILE()
UPDATE DESCRIPTION()
RECORDSIZE() KEYLENGTH()
RECORDFORMAT(V) ADD(NO)
BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO)
REMOTESYSTEM() REMOTENAME()
PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1)
STATUS(ENABLED) OPENTIME(FIRSTREF)
DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1)
TABLE(NO) MAXNUMRECS(NOLIMIT)
READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS)
UPDATEMODEL(LOCKING) LOAD(NO)
JNLREAD(NONE) JOURNAL(NO)
JNLSYNCREAD(NO) JNLUPDATE(NO)
JNLADD(NONE) JNLSYNCWRITE(YES)
RECOVERY(NONE) FWDRECOVLOG(NO)
BACKUPTYPE(STATIC)
PASSWORD() NSRGROUP()
CFDTPOOL() TABLENAME()
*
* Atributos predeterminados de Mapset
*
DEFINE MAPSET()
UPDATE DESCRIPTION()
PROTECT RESIDENT(NO) STATUS(ENABLED)
USAGE(NORMAL) USELPACOPY(NO)
** Atributos predeterminados de Processtype
*
DEFINE PROCESSTYPE()
UPDATE DESCRIPTION()
FILE(BTS)
PROTECT STATUS(ENABLED)
AUDITLOG() AUDITLEVEL(OFF)
*
* Atributos predeterminados de Program
*
DEFINE PROGRAM()
UPDATE DESCRIPTION()
CEDF(YES) LANGUAGE(LE370)
REMOTESYSTEM() REMOTENAME() TRANSID()
PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT)
DATALOCATION(ANY) DYNAMIC(NO)
EXECKEY(USER) EXECUTIONSET(FULLAPI)
RELOAD(NO) RESIDENT(NO)
STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO)
HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR)
*
* Atributos predeterminados de TDQueue
*
DEFINE TDQUEUE()
UPDATE DESCRIPTION()
TYPE(INTRA)
* Parámetros extra-partición
DDNAME() DSNAME()
REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1)
RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED)
BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR)
* Parámetros intra-partición
FACILITYID() TRANSID() TRIGERRLEVEL(1)
USERID()
* Parámetros indirectos
INDIRECTNAME()
PROTECT WAIT(YES) WAITACTION(REJECT)
* Parámetros extra-partición
DATABUFFERS(1)
SYSOUTCLASS() ERROROPTION(IGNORE)
OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT)
* Parámetros intra-partición
ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Atributos predeterminados de Transaction
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* Atributos de URDIMAP
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Enlace de nombre de archivo opcional a nombre de conjunto de datos VSAM
*
*DEFINE DSBINDING() DSNAME()
/*
Developer for System z versión 7.6.1 añadió soporte de URIMAP al programa de utilidad administrativo. Para poder utilizar el soporte URIMAP, el conjunto de datos de repositorio CRD VSAM debe estar asignado con un tamaño de registro máximo de 3000. Hasta Developer for System z Versión 7.6.1, el trabajo de asignación de repositorio CRD de ejemplo utiliza un tamaño de registro máximo de 2000.
El programa de utilidad administrativo emite los mensajes siguientes para la DD SYSPRINT. Los mensajes CRAZ1803E, CRAZ1891E, CRAZ1892E y CRAZ1893E contienen códigos de estado de archivo, retorno VSAM, función VSAM e información de retorno VSAM. Los códigos de retorno, función e información de retorno de VSAM se describen en la publicación DFSMS Macro Instructions for Data Sets (SC26-7408). Los códigos de estado de archivo se describen en la publicación Enterprise COBOL for z/OS Language Reference (SC27-1408).
Descripción: El programa de utilidad administrativo del programador del sistema se ha completado satisfactoriamente.
Respuesta del usuario: Ninguna.
Descripción: El programa de utilidad administrativo del programador del sistema se ha completado con uno o varios avisos encontrados al procesar las sentencias de control.
Respuesta del usuario: Compruebe si hay otros mensajes de aviso.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave.
Respuesta del usuario: Compruebe si hay otros mensajes de aviso.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al abrir el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado una sentencia de control de entrada no reconocida.
Respuesta del usuario: Compruebe que un mandato DEFINE vaya seguido de un solo espacio y de la palabra clave CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING,DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE o TRANSACTION.
Descripción: El programa de utilidad administrativo del programador del sistema está procesando la sentencia de control de entrada de la palabra clave DEFINE.
Respuesta del usuario: Ninguna.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado una regla de exportación de manifiestos no válida.
Respuesta del usuario: Compruebe que el valor de la palabra clave MANIFESTEXPORTRULE sea "installOnly", "exportOnly" o "both".
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE DSBINDING a la que le falta la palabra clave DSNAME.
Respuesta del usuario: Compruebe que la sentencia de control DEFINE DSBINDING contenga la palabra clave DSNAME.
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE y ha encontrado un valor no válido para la palabra clave indicada.
Respuesta del usuario: Compruebe que la longitud y el valor de la palabra clave indicada sean correctos.
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE y ha encontrado un error de sintaxis en una palabra clave o en un valor de palabra clave.
Respuesta del usuario: Compruebe que el valor de palabra clave se haya especificado entre paréntesis y se encuentre inmediatamente a continuación de la palabra clave. La palabra clave y su valor deben encontrarse en la misma línea.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error de clave duplicada al grabar en el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al grabar en el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al leer el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Defina el depurador en un región de CICS, tal como se documenta en el trabajo de actualización CSD de ejemplo de AQECSD. AQECSD se encuentra en FEK.#CUST.JCL, a menos que el programador de sistemas z/OS haya especificado otra ubicación al personalizar y enviar el trabajo FEK.SFEKSAMP(FEKSETUP). Para obtener más información, consulte "Configuración de personalización" en la Guía de configuración del host (SC11-3660).
Este capítulo le ayuda a mejorar Developer for System z escribiendo rutinas de salida.
Developer for System z proporciona puntos de salida para seleccionar eventos de Developer for System z. Un punto de salida es un punto específico en el proceso de una función, donde la función invoca una rutina de salida si es que existe una. Puede escribir una rutina de salida para realizar proceso adicional.
Tenga en cuenta que al contrario que en el caso de los puntos de salida tradicionales, los puntos de salida de Developer for System z no permite cambiar el comportamiento de la función. La rutina de salida, si existe, se invoca asíncronamente, una vez completada la función. El proceso de Developer for System z no espera a que la rutina de salida finalice ni comprueba el estado de completitud.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<punto_salida>.action=<salida_usuario>"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<punto_salida>.action.id=<IDusuario>"
De forma predeterminada, el ID de usuario asignado al daemon RSE se utiliza para ejecutar la rutina de salida proporcionada. Quite el comentario y especifique un ID de usuario para utilizar el ID especificado para ejecutar la salida de usuario. No hay necesidad de especificar una contraseña porque RSE generará un PassTicket para utilizarlo como contraseña cuando conmuta al ID de usuario especificado.
Las rutinas de salida de usuario se invocan como mandato shell de z/OS UNIX con uno o varios argumentos. Esto implica que la rutina de salida que desarrolla debe poder ejecutarse desde la línea de mandatos de z/OS UNIX. Las técnicas de codificación comunes incluyen el script shell de z/OS UNIX y el exec REXX de z/OS UNIX, pero también es posible utilizar código compilado, como por ejemplo C/C++.
Consulte la guía UNIX System Services User's Guide (SA22-7801) para obtener más información sobre los scripts de shell de z/OS UNIX. Consulte Using REXX and z/OS UNIX System Services (SA22-7806) para obtener más información sobre las extensiones específicas de UNIX de z/OS para el lenguaje REXX.
$ chmod 755 process_logon.sh
$ ls -l process_logon.sh
-rwxr-xr-x 1 IBMUSER SYS1 2228 Feb 28 23:44 process_logon.sh
Las definiciones de rsed.envvars están disponibles en la rutina de salida de usuario como variables de entorno.
RSE invoca la rutina de salida de usuario con una sola serie de argumento. La serie de argumento puede ser un solo valor o una sola serie que contiene varias palabras claves y valores delimitados. Consulte Puntos de salida disponibles para obtener más detalles.
Developer for System z utiliza el ID de mensaje de consola FEK910I para visualizar datos relacionados con las salidas de usuario.
FEK910I
<EXIT_POINT> EXIT: invoking <punto_salida> processing exit
in thread <ID_hebra>
FEK910I <EXIT_POINT> EXIT: <mensaje>
FEK910I <EXIT_POINT> EXIT: completed <punto_salida> processing exit
in thread <ID_hebra>
Developer for System z permite ejecutar una rutina de salida con el ID de usuario de tarea o un ID de usuario especificado. Sin embargo, es posible que ejecute algunas acciones en la rutina de salida mediante otro ID de usuario, como por ejemplo el ID de usuario de cliente en la rutina de salida de inicio de sesión. Esto se puede conseguir mediante los servicios de z/OS UNIX estándar, tal como se muestra en los ejemplos siguientes.
#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID
Esta salida de inicio de sesión de ejemplo, ejecutada por el ID de usuario de tarea iniciada, generará los mensajes de consola siguiente:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14 EXEC PGM=IEFBR14
$HASP100 IEFBR14 ON INTRDR FROM STC03919
IBMUSER
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14 STARTED - INIT 2 - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
IEFBR14 IEFBR14 IEFBR14 0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14 ENDED
$HASP309 INIT 2 INACTIVE ******** C=BA
/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2 /* PW_UID = 2 */
say retval errno errnojr
say userid()
Esta salida de inicio de sesión de ejemplo, ejecutada por el ID de usuario de tarea iniciada, generará los mensajes de consola siguiente:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER 1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515
La salida de usuario se invoca cuando se cierra el archivo de registro de auditoría activo. (La auditoría continúa ya que RSE ha cambiado a un archivo de registro de auditoría.)
/usr/lpp/rdz/samples/process_audit.rex
Este z/OS UNIX REXX exec de ejemplo construye un trabajo de proceso por lotes que procesará el registro de auditoría cerrado.
La salida de usuario se invoca cuando un usuario ha completado el proceso de inicio de sesión.
/usr/lpp/rdz/samples/process_logon.sh
Este script de shell z/OS UNIX de ejemplo escribe un mensaje de inicio de sesión en la consola.
Este capítulo está destinado a servir de ayuda para emular un procedimiento de inicio de sesión TSO añadiendo sentencias DD y conjuntos de datos al entorno TSO en Developer for System z.
El servicio de mandatos TSO es el componente de Developer for System z que ejecuta mandatos TSO e ISPF (por lotes) y devuelve el resultado al cliente solicitante. Estos mandatos puede solicitarlos implícitamente el producto o explícitamente el usuario.
Los miembros de ejemplo suministrados con Developer for System z crean un entorno TSO/ISPF mínimo. Si los desarrolladores de su establecimiento necesitan acceso a bibliotecas personalizadas o de terceros, el programador del sistema z/OS debe añadir las sentencias DD y bibliotecas necesarias al entorno de servicio de mandatos TSO. Aunque la implementación es diferente en Developer for System z, la lógica subyacente es idéntica al procedimiento de inicio de sesión de TSO.
El archivo de configuración ISPF.conf (por omisión ubicado en /etc/rdz/) define el entorno TSO/ISPF utilizado por Developer for System z. Sólo existe un archivo de configuración ISPF.conf activo, que utilizan todos los usuarios de Developer for System z.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2
#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"
Descomente la sentencia (elimine el carácter de almohadilla (#) inicial) y especifique el nombre totalmente calificado del conjunto de datos del perfil ISPF existente para utilizar este recurso.
*allocjob = ISP.SISPSAMP(ISPZISP2)
Aunque ISPF.conf sólo da soporte a la llamada a un exec de asignación, no hay límite para que ese exec llame a otro exec. Y el ID de usuario del cliente que se pasa como parámetro abre la posibilidad de llamar a ejecutables de asignación personalizados. Por ejemplo, puede comprobar si el miembro USERID’.EXEC(ALLOC)’ existe y ejecutarlo.
Si los escenarios de exec de asignación descritos en las secciones anteriores no pueden manejar sus necesidades específicas, puede crear instancias diferentes del servidor de comunicaciones RSE de Developer for System z, cada una de ellas con su propio archivo ISPF.conf. El principal inconveniente del método descrito más abajo es que los usuarios de Developer for System z deben conectarse a servidores diferentes del mismo host para obtener el entorno TSO deseado.
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
-> cambiar: _RSE_RSED_PORT=4037
-> cambiar: CGI_ISPCONF=/etc/rdz/tso2
-> cambiar: -Ddaemon.log=/var/rdz/logs/tso2
-> cambiar: -Duser.log=/var/rdz/logs/tso2
-> añadir al FINAL:
# -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/tso2/ISPF.conf
-> cambiar: cambiar según las necesidades
Los mandatos del ejemplo anterior copian los archivos de configuración de Developer for System z que necesitan cambios en un directorio tso2 de reciente creación. La variable CGI_ISPCONF en rsed.envvars se debe actualizar para definir el nuevo directorio de inicio de ISPF.conf, y daemon.log y user.log se deben actualizar para definir una nueva ubicación de registro (que se crea automáticamente si no existe). La actualización de _RSE_RSED_PORT asegura que tanto el daemon RSE existente como el nuevo utilicen números de puerto exclusivos. La actualización de CLASSPATH garantiza que RSE pueda encontrar los archivos de configuración que no se han copiado en tso2. El propio archivo ISPF.conf puede actualizarse para ajustarlo a las necesidades. Tenga en cuenta que el área de trabajo de ISPF (variable CGI_ISPWORK de rsed.envvars) puede compartirse entre ambas instancias.
La tarea restante consiste en crear una tarea iniciada para RSE que utilice un número de puerto nuevo y los nuevos archivos de configuración /etc/rdz/tso2. Tenga en cuenta que si no se cambia _RSE_RSED_PORT en rsed.envvars, la tarea nueva iniciada debe especificar un puerto nuevo como argumento de inicio.
Consulte la Guía de configuración de host de IBM Rational Developer for System z (SC11-3660) para obtener más información sobre las acciones mostradas anteriormente en este apartado.
En algunas ocasiones le interesará tener múltiples instancias de Developer for System z activas en el mismo sistema; por ejemplo, al probar una ampliación. Sin embargo, algunos recursos como los puertos TCP/IP no se pueden compartir, por lo que los valores predeterminados no siempre son aplicables. Utilice la información de esta sección para planificar la coexistencia de distintas instancias de Developer for System z y después podrá usar esta guía de configuración para personalizarlas.
Aunque es posible compartir algunos componentes de Developer for System z entre dos (o más) instancias, es mejor que NO lo haga, a menos que los correspondientes niveles de software sean idénticos y que los únicos cambios estén en los miembros de configuración. Developer for System z deja suficiente margen de personalización para crear múltiples instancias que no se solapen, y le aconsejamos encarecidamente que utilice estas características.
En un conjunto de circunstancias limitado, puede compartir todo salvo (algunos de) los componentes personalizables. Por ejemplo, proporcionar acceso no SSL para la utilización en el local y comunicación codificada por SSL para la utilización fuera del local.
Atención: La configuración compartida NO se puede utilizar de manera segura
para
probar el mantenimiento, un avance tecnológico o un nuevo release.
|
Para configurar otra instancia de una instalación activa de Developer for System z, rehaga los pasos de personalización para los componentes que sean distintos, utilizando diferentes conjuntos de datos, directorios y puertos para evitar que se solape con la instalación actual.
En el ejemplo SSL mencionado anteriormente, la configuración del daemon RSE actual se puede clonar y, después, la configuración clonada se puede actualizar. A continuación, el JCL de inicio del daemon RSE puede clonarse y personalizarse con un nuevo puerto TCP/IP y la ubicación de los archivos de configuración actualizados. Las personalizaciones de MVS (supervisor de trabajos JES, etc.) se pueden compartir entre las instancias SSL y las no SSL. Ello daría como resultado las siguientes acciones:
$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
-> cambiar: _RSE_RSED_PORT=4047
-> cambiar: -Ddaemon.log=/var/rdz/logs/ssl
-> cambiar: -Duser.log=/var/rdz/logs/ssl
-> añadir al FINAL:
# -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/ssl/ssl.properties
-> cambiar: cambiar según las necesidades
Los mandatos del ejemplo precedente copian los archivos de configuración de Developer for System z que necesitan cambios en un directorio ssl de reciente creación. Las variables daemon.log y user.log de rsed.envvars deben actualizarse para definir una ubicación de registro nueva (que se crea automáticamente en caso de que no exista). La actualización de CLASSPATH garantiza que RSE pueda encontrar los archivos de configuración que no se han copiado en ssl. El propio archivo ssl.properties puede actualizarse para ajustarlo a las necesidades.
La tarea restante consiste en crear una tarea iniciada para RSE que utilice un número de puerto nuevo y los nuevos archivos de configuración /etc/rdz/ssl.
Consulte las secciones relacionadas en la IBM Rational Developer for System zGuía de configuración de host (SC11-3660) para obtener más información sobre las acciones mostradas anteriormente en esta sección.
En el ejemplo de SSL mencionado anteriormente, los cambios entre el daemon RSE no habilitado por SSL y habilitado por SSL son mínimos, lo que permite automatizar el proceso de mantenimiento de la sincronización de los archivos rsed.envvars correspondientes. Esto simplifica el lanzamiento del servicio porque sólo es necesario mantener un archivo rsed.envvars.
El ejemplo siguiente añade el número de puerto RSED a los nombres de directorio de registro y actualiza la variable CLASSPATH de modo que los clones encontrarán los archivos de configuración restantes. A continuación, el ejemplo mejora la tarea iniciada JCL iniciada del daemon de RSE habilitado por SSL para clonar el archivo rsed.envvars del daemon de RSE no SSL al iniciar, actualizando el número de puerto en los procesos. Puesto que el número de puerto está incorporado en el nombre del directorio, es diferente para ambos daemons.
$ oedit /etc/rdz/rsed.envvars
-> change: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
-> change: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
-> añadir al FINAL:
# -- NECESARIO PARA LOS CLONES PARA ENCONTRAR LOS ARCHIVOS DE
CONFIGURACIÓN RESTANTES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ mkdir /etc/rdz/ssl
$ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
$ oedit /etc/rdz/ssl/ssl.properties
-> cambiar: cambiar según las necesidades
//*
//* RSE DAEMON - SSL
//*
//RSED PROC IVP=, * 'IVP' para hacer una prueba de IVP
// HOME='/usr/lpp/rdz',
// CNFG='/etc/rdz/ssl'
//*
// SET SED='"/RSED_PORT/s/4035/4034/"'
// SET FILE='rsed.envvars'
//*
//* copy /etc/rdz/rsed.envvars to /etc/rdz/ssl/rsed.envvars
//* and alter RSED_PORT
//*
//CLONE EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
// PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//* iniciar RSED con el archivo rsed.envvars recién creado
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT),
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
Cuando hay cambios de código implicados (de mantenimiento, avances tecnológicos, nuevo release), o cuando los cambios son bastante complejos, debe hacer otra instalación de Developer for System z. En este apartado se describen los posibles puntos de conflicto entre distintas instalaciones.
La siguiente lista es una visión general resumida de los elementos que deben ser distintos (o conviene que lo sean) entre las instancias de Developer for System z:
A continuación se proporciona una visión general más detallada:
La publicación Developer for System z Messages and Codes (SC14-7497) documenta los mensajes y los códigos de retorno generados por los componentes de Developer for System z. Developer for System z Answers to common host configuration and maintenance issues (SC14-7373) describe varios casos de problemas y sus soluciones.
Encontrará más información en la sección de soporte del sitio Web de Developer for System z (http://www-03.ibm.com/software/products/us/en/developerforsystemz/), donde hay fichas técnicas que le aportarán la información más reciente de nuestro equipo de soporte.
En la sección de biblioteca del sitio Web (http://www-01.ibm.com/support/docview.wss?uid=swg27038517) también hallará la versión más reciente de la documentación de Developer for System z los libros blancos.
El Information Center de Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) documenta el clienteDeveloper for System z y cómo interactúa con el host (desde una perspectiva del ciente).
También encontrará información valiosa en la biblioteca Internet de z/OS, disponible en http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
https://www.ibm.com/developerworks/support/rational/rfe/
La tarea iniciada RSED da soporte al mandato de operador MODIFY LOGS para recopilar registros de host de Developer for System z e información de configuración. Los datos recopilados se sitúan en el archivo z/OS UNIX, $TMPDIR/feklogs%sysname.%jobname, donde $TMPDIR es el valor de la directiva TMPDIR en rsed.envvars (/tmp predeterminado), %sysname es el nombre del sistema z/OS y %jobname es el nombre de la tarea iniciada RSED.
De forma predeterminada, sólo se recopilan registros del servidor. Las opciones de mandato le permiten recopilar diferentes registros:
USER | Recopilar archivos de registro para el ID de usuario especificado |
AUDIT | Recopilar registros de auditoría |
NOSERVER | No recopilar registros del servidor |
Developer for System z consultará el producto de seguridad para permisos de acceso a perfilesFEK.CMD.LOGS.** para determinar si el peticionario tiene permiso para recopilar los registros especificados. De forma predeterminada, el peticionario es el ID de usuario de la tarea iniciada RSED, a menos que se especifique la opción OWNER. Sólo el peticionario tiene acceso al archivo que contiene los datos recopilados.
Para recopilar datos antes de que se pueda iniciar la tarea iniciada RSED, Developer for System z proporciona un trabajo de ejemplo, FEKLOGS, que recopila todos los archivos de registro z/OS UNIX así como información de instalación y configuración de Developer for System z.
El trabajo de ejemplo FEKLOGS se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Consulte a sección "Configuración de personalización" de la publicación Guía de configuración de host (SC11-3660) para obtener más detalles.
La personalización de FEKLOGS se describe en el JCL. La personalización abarca la provisión de algunas variables clave.
Developer for System z crea archivos de registro que le ayudarán a usted y al centro de soporte de IBM a identificar y resolver problemas. La lista que sigue es una visión general de los archivos de registro que se pueden crear en su sistema host z/OS. Junto a estos archivos de registro específicos del producto, no olvide consultar SYSLOG por si hay mensajes relacionados.
Los registros basados en MVS se pueden localizar mediante la sentencia DD pertinente. Los archivos de registro basados en z/OS UNIX se encuentran en los siguientes directorios:
Los archivos de registro específicos del usuario están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
El daemon RSE y los archivos de registro específicos de la agrupación de hebras RSE se encuentran en daemon-home/server, donde daemon-home es el valor de la directiva daemon.log en rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
Los archivos de registro específicos de IVP (Installation Verification Program) se encuentran en el directorio al que hace referencia la variable TMPDIR, si esta variable está definida en rsed.envvars. Si la variable no está definida, los archivos se crean en /tmp.El mandato de operador MODIFY LOGS para la tarea iniciada RSED también crea su salida en este directorio.
El registro de rastreo y el registro de operaciones normales. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(DBGMGR) es SYSOUT=*.
Registro de las operaciones normales. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(JMON) es SYSOUT=*.
Registro de rastreo. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(JMON) es SYSOUT=*. El rastreo se activa con el parámetro –TV; hallará más detalles en: Rastreo del supervisor de trabajos JES.
Los datos redirigidos de stdout, la salida estándar de Java del daemon RSE. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(RSED) es SYSOUT=*.
Los datos redirigidos de stderr, la salida de error estándar de Java del daemon RSE. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(RSED) es SYSOUT=*.
Los archivos de registro específicos del daemon RSE y de la agrupación de hebras RSE se encuentran en daemon-home, donde daemon-home es el valor de la directiva daemon.log de rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
Los componentes relacionados con RSE crean varios archivos de registro. Todos están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Registro de comunicación de SCLM Developer Toolkit, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Al abrir una conexión con CARMA mediante la interfaz de proceso por lotes, FEK.#CUST.SYSPROC(CRASUBMT) iniciará un trabajo servidor (cuyo propietario será el ID del usuario) llamado CRApuerto, siendo puerto el número de puerto TCP/IP que se utiliza.
Si se especifica la sentencia DD CARMALOG en el método de inicio de CARMA elegido, los registros de CARMA se redirigen a esta sentencia DD en el trabajo servidor; de lo contrario, van a SYSPRINT.
El SYSPRINT DD del trabajo servidor contiene los registros de CARMA, si la sentencia DD CARMALOG no está definida.
El SYSTSPRT DD del trabajo del servidor contiene los mensajes del sistema (TSO) para el inicio del servidor CARMA.
Registro de comunicación de CARMA, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
El mandato fekfivpc (prueba IVP relacionada con CARMA) creará el archivo fekfivpc.log para documentar la comunicación entre RSE y CARMA. El registro se creará en el directorio al que hace referencia la variable TMPDIR, si esta variable está definida en rsed.envvars. Si la variable no está definida, el archivo se creará en /tmp.
Salida del mandato fekfivpi -file (prueba IVP relacionada con la pasarela de cliente TSO/ISPF). El registro se creará en el directorio al que hace referencia la variable TMPDIR, si esta variable está definida en rsed.envvars. Si la variable no está definida, el archivo se creará en /tmp.
Salida del mandato fekfivps -file (prueba IVP relacionada con SCLMDT). El registro se creará en el directorio al que hace referencia la variable TMPDIR, si esta variable está definida en rsed.envvars. Si la variable no está definida, el archivo se creará en /tmp.
El SYSTSPRT DD del paso que invoca el procedimiento de revisión de código alberga los mensajes del componente frontal que controla el proceso de análisis de código.
El WORKSPCE DD del paso que invoca el procedimiento de revisión de código alberga los mensajes de registro de espacio de trabajo de Eclipse del proceso de análisis de código.
El ERRMSGS DD del paso que invoca el procedimiento de revisión de código alberga la salida stderr del proceso de análisis de código.
El SYSTSPRT DD del paso que invoca el procedimiento de revisión de código alberga los mensajes del componente frontal que controla el proceso de análisis de código.
El WORKSPCE DD del paso que invoca el procedimiento de revisión de código alberga los mensajes de registro de espacio de trabajo de Eclipse del proceso de análisis de código.
El ERRMSGS DD del paso que invoca el procedimiento de revisión de código alberga la salida stderr del proceso de análisis de código.
Cuando un producto se interrumpe de forma anómala, se crea un vuelco de almacenamiento para ayudar a determinar el problema. La disponibilidad y la ubicación de los vuelcos depende en gran medida de los valores específicos del local. Los vuelcos podrían no crearse, o bien se podrían crear en distintas ubicaciones de las mencionadas en las secciones siguientes.
Si el programa se ejecuta en MVS, compruebe los archivos de vuelco del sistema y compruebe también el JCL de las siguientes sentencias DD (en función del producto):
Consulte las publicaciones MVS JCL Reference (SA22-7597) y Language Environment Debugging Guide (GA22-7560) para obtener más información acerca de estas sentencias DD.
En z/OS UNIX, la mayoría de vuelcos de Developer for System z están controlados por la máquina virtual Java (JVM).
La JVM crea por defecto un conjunto de agentes de vuelco durante su inicialización (SYSTDUMP y JAVADUMP). Puede alterar temporalmente este conjunto de agentes de vuelco utilizando la variable de entorno JAVA_DUMP_OPTS, y aún puede alterar adicionalmente el conjunto utilizando -Xdump en la línea de mandatos. Las opciones de línea de mandatos de la JVM están definidas en la directiva _RSE_JAVAOPTS de rsed.envvars . No cambie ninguno de los valores, a menos que se lo indique el centro de soporte de IBM.
El vuelco se escribe en un conjunto de datos MVS secuencial, utilizando un nombre predeterminado con el formato %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S, o tal como viene determinado por el valor de la variable de entorno JAVA_DUMP_TDUMP_PATTERN.
Variable | Uso |
---|---|
%uid | ID de usuario |
%job | Nombre de trabajo |
%y | Año (2 dígitos) |
%m | Mes (2 dígitos) |
%d | Día (2 dígitos) |
%H | Hora (2 dígitos) |
%M | Minuto (2 dígitos) |
%S | Segundo (2 dígitos) |
El vuelco se escribe en un archivo de z/OS UNIX llamado CEEDUMP.aaaammdd.hhmmss.pid, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de volcados de z/OS UNIX.
El vuelco se escribe en un archivo de z/OS UNIX llamado HEAPDUMP.aaaammdd.hhmmss.pid.TXT, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de volcados de z/OS UNIX.
Tenga en cuenta que Developer for System z proporciona un mandato de operador para desencadenar este vuelco. Consulte el capítulo "Mandatos de operador" en la publicación Guía de configuración del host SC11-3660 (SC23-7658) para obtener más detalles.
El vuelco se escribe en un archivo de z/OS UNIX llamado JAVADUMP.aaaammdd.hhmmss.pid.TXT, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de volcados de z/OS UNIX.
Tenga en cuenta que Developer for System z proporciona un mandato de operador para desencadenar este vuelco. Consulte el capítulo "Mandatos de operador" en la publicación Guía de configuración del host SC11-3660 (SC23-7658) para obtener más detalles.
Consulte las publicaciones Java Diagnostic Guide (SC34-6358), para obtener más información acerca de los vuelcos de JVM, y Language Environment Debugging Guide (GA22-7560) para obtener información específica acerca de LE.
La JVM comprueba cada una de las siguientes ubicaciones para ver si tienen permiso de escritura y existencia, y almacena los archivos CEEDUMP, HEAPDUMP y JAVADUMP en la primera ubicación disponible. Tenga en cuenta que debe tener suficiente espacio en disco libre para que el archivo de vuelco se escriba correctamente.
El rastreo del gestor de depuración está controlado por el operador del sistema, tal como se describe en "Mandatos de operador" en Guía de configuración de host (SC11-3660).
El rastreo del Supervisor de trabajos JES está controlado por el operador del sistema, como se describe en la sección "Mandatos de operador" de la publicación Guía de configuración de host (SC11-3660).
Los componentes relacionados con RSE crean varios archivos de registro. La mayoría están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
La cantidad de datos escritos en ffs*.log, lock.log y rsecomm.log se controla mediante el mandato del operador modify rsecommlog o estableciendo debug_level en rsecomm.properties. Para obtener más detalles, consulte la sección "Mandatos de operador" de la publicación Guía de configuración de host (SC11-3660) y la sección "(Opcional) Rastreo RSE" de la publicación Guía de configuración de host (SC11-3660).
La creación de los archivos de registro .dstore* está controlada por las opciones de inicio –DDSTORE_* Java, como se describe en el apartado "Definición de parámetros de inicio de Java adicionales con _RSE_JAVAOPTS" de la publicación Guía de configuración de host (SC11-3660).
Los archivos de registro específicos del daemon RSE y de la agrupación de hebras RSE se encuentran en daemon-home, donde daemon-home es el valor de la directiva daemon.log de rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
La cantidad de datos escritos en rsedaemon.log y rseserver.log se controla mediante los mandatos del operador modify rsedaemonlog y modify rseserverlog o estableciendo debug_level en rsecomm.properties. Para obtener más detalles, consulte la sección "Mandatos de operador" de la publicación Guía de configuración de host (SC11-3660) y la sección "(Opcional) Rastreo RSE" de la publicación Guía de configuración de host (SC11-3660).
serverlogs.count, stderr.*.log y stdout.*.log solamente se crean si la directiva enable.standard.log de rsed.envvars está activa, o si la función está activada dinámicamente con el mandato de operador modify rsestandardlog on.
El usuario puede controlar la cantidad de información de rastreo generada por un servidor
CARMA estableciendo el Nivel de rastreo en la pestaña de propiedades de la conexión CARMA en el cliente.
Las opciones de nivel de rastreo son:
Registro de error
Para obtener más información sobre la ubicación de los archivos de registro, consulte: Archivos de registro.
El programador del sistema z/OS puede controlar la cantidad de información de rastreo que genera el método de inicio CRASTART de CARMA estableciendo el valor crastart.syslog en CRASRV.properties y estableciendo el nivel de depuración para rsecomm.log en rsecomm.properties o con un mandato de operador.
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K,
//* PARM=('EXIT(ADEXIT(ELAXMGUX))',
// PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))',
// 'ADATA',
// 'LIB',
// 'TEST(NONE,SYM,SEP)',
// 'LIST',
// 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682746.XML
23 //COBOL.WSEDSF2 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z requiere que el sistema de archivos de z/OS UNIX y algunos archivos de z/OS UNIX tengan establecidos determinados bits de permiso.
Explorador de Sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios del núcleo como por ejemplo la conexión del cliente con el host. Debe permitírsele realizar tareas tales como crear el entorno de seguridad del usuario.
Se pueden esperar errores similares (como por ejemplo los mensajes BPXP014I y BPXP015I) si los sistemas de archivos que albergan binarios Java o z/OS UNIX se montan con el parámetro NOSETUID.
Utilice el mandato ISHELL de TSO para listar el estado actual del bit SETUID. En el panel de ISHELL, seleccione Sistemas de archivos > 1. Tabla de montaje... para listar los sistemas de archivos montados. El mandato abreviado a mostrará los atributos del sistema de archivos seleccionado, donde el campo “Ignorar SETUID” debe ser 0.
Explorador de Sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios del núcleo como por ejemplo la conexión del cliente con el host. Se debe ejecutar en modalidad controlada por programa para poder realizar tareas como las de pasar al ID de usuario del cliente.
El bit de control de programa de z/OS UNIX se establece durante la instalación de SMP/E cuando es necesario, excepto para la interfaz de Java del producto de seguridad, tal como se documenta en la sección Consideraciones relativas a la seguridad. Este bit de permiso puede perderse si no lo ha conservado durante una copia manual de los directorios de Developer for System z.
Utilice el mandato ls -E de z/OS UNIX para listar los atributos ampliados, en los que el bit de control de programa está marcado con la letra p, según se muestra en el ejemplo siguiente ($ es el indicador de mandatos de z/OS UNIX):
$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Explorador de Sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios del núcleo como por ejemplo la conexión del cliente con el host. Se debe ejecutar con autorización de APF para poder realizar tareas como por ejemplo visualizar la utilización de recursos de proceso detallados.
El bit de z/OS UNIX APF se establece durante la instalación de SMP/E, cuando sea necesario. Este bit de permiso puede perderse si no lo ha conservado durante una copia manual de los directorios de Developer for System z.
Utilice el mandato ls -E de z/OS UNIX para listar los atributos ampliados, en los que el bit de APF está marcado con la letra a, según se muestra en el ejemplo siguiente: ($ es el indicador de mandatos de z/OS UNIX):
$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Utilice el mandato extattr +a de z/OS UNIX para establecer el bit de APF manualmente, como se muestra en el ejemplo siguiente ($ y # son las solicitudes de z/OS UNIX):
$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Algunos de los servicios opcionales de Developer for System z requieren que los módulos de carga de MVS estén disponibles para z/OS UNIX. Esta operación se realiza creando un apéndice (un archivo ficticio) en z/OS UNIX con el bit de "permanencia" activado. Al ejecutar el apéndice, z/OS UNIX buscará un módulo de carga de MVS con el mismo nombre y ejecutará el módulo de carga en su lugar.
El bit de permanencia de z/OS UNIX se establece durante la instalación de SMP/E, cuando es necesario. Estos bits de permiso pueden perderse si no los ha conservado durante una copia manual de los directorios de Developer for System z.
$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Con el mandato netstat (TSO o z/OS UNIX) puede obtener una visión general de los puertos que se utilizan en este momento. Los datos de salida de este mandato se parecerán a los del ejemplo siguiente. Los puertos utilizados son el último número (a continuación de "..") en la columna "Socket local". Como estos puertos ya se están utilizando, no se pueden utilizar para la configuración de Developer for System z.
MVS TCP/IP NETSTAT CS VxRy TCPIP Nombre TCPIP: TCPIP 16:36:42
ID us. Conexión Socket Local Socket Foráneo Estado
------- ---- ------------ -------------- -----
BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Escucha
INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Escucha
RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Escucha
JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Escucha
MVS TCP/IP NETSTAT CS VxRy Nombre TCPIP: TCPIP 12:46:25
ID usuario Conexión Estado
------- ---- -----
BPXOINIT 00000018 Escucha
Socket local: 0.0.0.0..10007
Socket foráneo: 0.0.0.0..0
INETD4 00000046 Escucha
Socket local: 0.0.0.0..512
Socket foráneo: 0.0.0.0..0
RSED 0000004B Escucha
Socket local: 0.0.0.0..4035
Socket foráneo: 0.0.0.0..0
JMON 00000037 Escucha
Socket local: 0.0.0.0..6715
Socket foráneo: 0.0.0.0..0
Otra posible limitación son los puertos TCP/IP reservados. Hay dos lugares comunes en los que se reservan puertos TCP/IP:
Este es el conjunto de datos al que hace referencia la sentencia DD PROFILE de la tarea iniciada TCP/IP, que a menudo se llama SYS1.TCPPARMS(TCPPROF).
Consulte la publicación Communications Server: IP Configuration Guide (SC31-8775) para obtener más información acerca de estas sentencias.
Para obtener una lista de estos puertos reservados, se puede utilizar el mandato netstat portl (TSO o z/OS UNIX), que crea una salida parecida a la del ejemplo siguiente:
MVS TCP/IP NETSTAT CS VxRy Nombre TCPIP: TCPIP 17:08:32
NºPto Prot Usuario Dstivos Rango Dirección IP
----- ---- ---- ----- ----- ----------
00007 TCP MISCSERV DA
00009 TCP MISCSERV DA
00019 TCP MISCSERV DA
00020 TCP OMVS D
00021 TCP FTPD1 DA
00025 TCP SMTP DA
00053 TCP NAMESRV DA
00080 TCP OMVS DA
03500 TCP OMVS DAR 03500-03519
03501 TCP OMVS DAR 03500-03519
Consulte la publicación Communications Server: IP System Administrator’s Commands (SC31-8781) para obtener más información acerca del mandato NETSTAT.
Para el daemon RSE, que es un proceso z/OS UNIX Java se necesita una región de gran tamaño para efectuar sus funciones. Por lo tanto, es importante establecer límites de almacenamiento grandes para los espacios de direcciones de OMVS.
El daemon RSE se inicia mediante JCL utilizando BPXBATSL, cuyo tamaño de región debe ser 0.
Establezca que MAXASSIZE en SYS1.PARMLIB(BPXPRMxx), que define el tamaño de región (proceso) de espacio de direcciones OMVS predeterminado, en 2G. Es el tamaño máximo permitido. Este es un límite a escala del sistema y, por ello, está activo para todos los espacios de direcciones z/OS UNIX. Si no desea este límite, puede establecer el límite únicamente para Developer for System z en el software de seguridad.
Compruebe ASSIZEMAX, en el segmento OMVS del ID de usuario del daemon, y establézcalo en 2147483647 o, preferiblemente, en NONE para que utilice el valor SYS1.PARMLIB(BPXPRMxx).
Asegúrese de que no permite que las rutinas de salida IEFUSI o IEALIMIT del sistema controlen los tamaños de las regiones del espacio de direcciones de OMVS. Una manera posible de lograrlo es escribiendo SUBSYS(OMVS,NOEXITS) en el código de SYS1.PARMLIB(SMFPRMxx).
La palabra clave MEMLIMIT en SYS1.PARMLIB(SMFPRMxx) limita el almacenamiento virtual que una tarea de 64 bits puede asignar por encima de la barra de 2GB. Al contrario que el parámetro REGION en JCL, MEMLIMIT=0M significa que el proceso no puede utilizar almacenamiento virtual por encima de la barra.
Si no se especifica MEMLIMIT en SMFPRMxx, el valor predeterminado es 0M, con lo que las tareas están limitadas a los 2GB (31 bits) por debajo de la barra. El valor predeterminado cambió en z/OS 1.10 a 2G, permitiendo que las tareas de 64 bits utilicen hasta 4GB (los 2GB por debajo de la barra y los 2GB por encima de la barra otorgados por MEMLIMIT).
MEMLIMIT también se puede especificar como parámetro en una tarjeta EXEC en JCL. Si no se especifica ningún parámetro MEMLIMIT, el valor predeterminado es el valor definido por SMF, excepto cuando se especifica REGION=0M, en cuyo caso el valor predeterminado es NOLIMIT.
Cuando un usuario selecciona el retorno de errores durante una acción de compilación, Developer for System z crea varios conjuntos de datos temporales. Si uno de estos conjuntos de datos se queda sin espacio, los trabajos de compilación finalizan con una terminación anómala de espacio B37-04.
Ajuste la asignación de espacio en FEK.SFEKPROC(FEKFERRF) si los usuarios se encuentran con este problema. El valor predeterminado es SPACE(200,40) TRACKS.
SYS1.PARMLIB(BPXPRMxx) define muchas limitaciones relacionadas con z/OS UNIX, que se podrían alcanzar cuando hay varios clientes Developer for System z activos. La mayoría de los valores BPXPRMxx se pueden cambiar dinámicamente con los mandatos de consola SETOMVS y SET OMVS.
Utilice el mandato de consola SETOMVS LIMMSG=ALL para que z/OS UNIX muestre los mensajes de consola (BPXI040I) cuando se está a punto de alcanzar alguno de los límites de BPXPRMxx.
Esta sección se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar la capa de sockets segura (SSL) o durante la comprobación o modificación de una configuración existente. Esta sección también facilita una configuración de ejemplo para admitir que los usuarios se autentiquen con un certificado X.509.
Que una comunicación sea segura implica asegurarse de que su interlocutor sea la persona que afirma ser y transmitir información de tal manera que a las otras personas les resulte difícil interceptar los datos y leerlos. SSL proporciona capacidad para ello en una red TCP/IP. Funciona utilizando certificados digitales para identificarse a sí mismo, y un protocolo de claves públicas para cifrar la comunicación. Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de los certificados digitales y el protocolo de claves públicas utilizado por SSL.
Las acciones necesarias para configurar las comunicaciones SSL para Developer for System z variarán según el local, en función de las necesidades exactas, del método de comunicación RSE empleado y de lo que ya esté disponible en el local.
En esta sección clonaremos las definiciones actuales de RSE para poder tener una segunda conexión del daemon RSE que utilice SSL. También crearemos nuestros propios certificados de seguridad para que los utilicen diferentes componentes de la conexión RSE.
En algunas tareas que se describen en las secciones siguientes, se espera que esté activo en z/OS UNIX. Para ello, emita el mandato TSO OMVS. Utilice el mandato exit para volver a TSO.
La variable DSTORE_SSL_ALGORITHM de la directiva _RSE_JAVAOPTS de rsed.envvars permite elegir entre el método de cifrado SSL y su eventor TLS (seguridad de la capa de transporte), tal como se documenta en "Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS" en la Guía de configuración de host SC11-3660 (SC23-7658).
Los certificados de identidad y las claves de cifrado/descifrado que SSL emplea se almacenan en un archivo de claves. Existen distintas implementaciones de este archivo de claves, en función del tipo de aplicación.
sin embargo, todas las implementaciones siguen el mismo principio. Un mandato genera un par de claves (una clave pública y una clave privada asociada). Este envuelve luego la clave pública en un certificado X.509 autofirmado, que se almacena como cadena de certificados de un solo elemento. Esta cadena de certificados y la clave privada se almacenen como una entrada (identificado por un alias) en un archivo de claves.
Almacenamiento de certificados | Creado y gestionado por | Daemon RSE | servidor RSE |
---|---|---|---|
anillo de claves | producto de seguridad compatible con SAF | soportado | soportado |
base de datos de claves | gskkyman de z/OS UNIX | soportado | / |
almacén de claves | Keytool de Java | / | soportado |
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Para obtener información sobre RACF y certificados digitales, consulte Security Server RACF - Guía del adminsitrador de seguridad (SA22-7683). La documentación relativa a gskkyman se encuentra en la publicación System SSL Programming (SC24-5901) y la documentación de keytool está disponible en el sitio http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
No realice este paso si utiliza gskkyman para crear la base de datos de claves del daemon RSE y keytool para crear el almacén de claves del servidor RSE.
El mandato RACDCERT instala y mantiene claves privadas y certificados en RACF. RACF permite gestionar múltiples claves privadas y certificados en forma de grupo. Estos grupos se llaman anillos de claves.
Los certificados pueden ser autofirmados o estar firmados por una autoridad certificadora (CA). Un certificado firmado por una CA implica que la CA garantiza que el propietario del certificado es quién dice ser. El proceso de firma añade las credenciales de la CA (otro certificado) al certificado, constituyendo una cadena de certificados de varios elementos.
Al utilizar un certificado firmado por una CA, puede evitar las preguntas de validación de la confianza realizadas por el cliente de Developer for System z, si para el cliente la CA ya es de confianza.
Para obtener detalles sobre el mandato RACDCERT, consulte Security Server RACF Command Language Reference (SA22-7687).
# permita al daemon RSE acceder a los certificados
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
# renueve para que los cambios sean visibles
SETROPTS RACLIST(FACILITY) REFRESH
# cree un certificado autofirmado
RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') +
OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE)
# (opcional) pasos adicionales necesarios para utilizar un certificado con firma
# 1. cree una solicitud de firma para el certificado autofirmado
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
# 2. envíe la solicitud de firma a la CA de su elección
# 3. compruebe si las credenciales de la CA (también un certificado)
ya se conocen
RACDCERT CERTAUTH LIST
# 4. marque el certificado de autoridad emisora de certificados como fiable
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# o añada el certificado de autoridad emisora de certificados a la base
# de datos
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. añada el certificado firmado a la base de datos;
# de esta forma se sustituye el autofirmado
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
# NO suprima el certificado autofirmado antes de sustituirlo.
# Si lo hace, perderá la clave privada que acompaña al certificado,
# lo que hace que el certificado no sirva para nada.
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) +
DEFAULT USAGE(PERSONAL))
# paso adicional necesario para utilizar un certificado firmado
# 6. añada el certificado de autoridad emisora de certificados al conjunto de
claves
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') +
RING(rdzssl.racf))
# renueve para que los cambios sean visibles
SETROPTS RACLIST(DIGTCERT) REFRESH
En el ejemplo anterior se empieza por crear los perfiles necesarios y permitir que el ID de usuario STCRSE tenga acceso a los anillos de claves y a los certificados propiedad de ese ID de usuario. El ID de usuario que se utilice debe coincidir con el ID de usuario utilizado para ejecutar para el daemon RSE SSL. El próximo paso consiste en crear un certificado autofirmado con la etiqueta rdzrse . No se necesita ninguna contraseña. Luego, este certificado se añade a un anillo de claves recién creado (rdzssl.racf). Igual que con el certificado, tampoco se necesita una contraseña para el anillo de claves. También se enumeran los pasos necesarios para utilizar un certificado con firma.
Tenga en cuenta que el certificado de CA utilizado para firmar su certificado puede, por otro lado, ser firmado por otro certificado de CA, de mayor nivel. Si eso sucediera, el certificado de CA también se debe añadir al conjunto de claves. Este proceso se repite hasta que el certificado de CA de mayor nivel es un certificado de CA raíz, que siempre es un certificado autofirmado.
El resultado puede verificarse con las opciones list ylistring:
RACDCERT ID(stcrse) LIST
Información de certificado digital para el usuario STCRSE:
Etiqueta: rdzrse
ID de certificado: 2QjW1OXi0sXZ1aaEqZmihUBA
Estado: TRUST
Fecha inicial: 2007/05/24 00:00:00
Fecha final: 2017/05/21 23:59:59
Número de serie:
>00<
Nombre del emisor:
>CN=my CA.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Nombre del sujeto:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Tipo de clave privada: Non-ICSF
Tamaño de clave privada: 1024
Asociaciones de anillo:
Propietario de anillo: STCRSE
Anillo:
>rdzssl.racf<
RACDCERT ID(stcrse) LISTRING(rdzssl.racf)
Digital ring information for user STCRSE:
Ring:
>rdzssl.racf<
Certificate Label Name Cert Owner USAGE DEFAULT
-------------------------------- ------------ -------- -------
rdzrse ID(STCRSE) PERSONAL YES
CA cert CERTAUTH CERTAUTH NO
En este paso se crea una nueva instancia de los archivos de configuración de RSE para que la configuración de SSL pueda ejecutarse en paralelo con las existentes. En los mandatos que siguen se presupone que los archivos de configuración se encuentran en /etc/rdz/, que es la ubicación predeterminada utilizada en la sección "Configuración de personalización" de la publicación Guía de configuración de host (SC11-3660).
$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars ssl.properties
Los mandatos z/OS UNIX que figuran en el ejemplo anterior crean un subdirectorio llamado ssl y lo llenan con los archivos de configuración que requieren cambios. Podemos compartir el resto de archivos de configuración, el directorio de instalación y los componentes de MVS, puesto que no son específicos de la SSL.
Reutilizando la mayor parte de los archivos de configuración existente, podemos centrarnos en los cambios que son realmente necesarios para la configuración de la SSL y evitar tener que volver a realizar la configuración de RSE completa. (Por ejemplo, podemos ahorrarnos definir una nueva ubicación para ISPF.conf.)
Hasta el momento, las definiciones son una copia exacta de la configuración actual, lo que implica que los registros del daemon RSE nuevo se superponen a los archivos de registro del servidor actual. RSE también necesita saber dónde encontrar los archivos de configuración que no se han copiado en el directorio ssl. Ambas emisiones pueden direccionarse por cambios sin importancia a rsed.envvars.
$ oedit /etc/rdz/ssl/rsed.envvars
-> cambiar: _RSE_RSED_PORT=4047
-> cambiar: -Ddaemon.log=/var/rdz/logs/ssl
-> cambiar: -Duser.log=/var/rdz/logs/ssl
-> añadir al FINAL:
# -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
Los cambios del ejemplo anterior definen una nueva ubicación de registro (que el daemon RSE creará en caso que la ubicación de registro no exista). Los cambios también actualizan la CLASSPATH de manera que los procesos RSE de la SSL buscarán los archivos de configuración primero en el directorio actual (/etc/rdz/ssl) y luego en el directorio original (/etc/rdz).
Actualizando ssl.properties el RSE sigue instrucciones para empezar a utilizar la comunicación cifrada de la SSL.
$ oedit /etc/rdz/ssl/ssl.properties
-> cambiar: enable_ssl=true
-> descomentar y cambiar: daemon_keydb_file=rdzssl.racf
-> descomentar y cambiar: daemon_key_label=rdzrse
-> descomentar y cambiar: server_keystore_file=rdzssl.racf
-> descomentar y cambiar: server_keystore_label=rdzrse
-> descomentar y cambiar: server_keystore_type=JCERACFKS
Los cambios del ejemplo siguiente habilitan la SSL e indican al daemon RSE y al servidor RSE que el certificado (compartido) está almacenado bajo la etiqueta rdzrse en el anillo de claves rdzssl.racf. La palabra clave JCERACFKS indica al servidor RSE que se está utilizando un anillo de claves compatible con SAF como almacén de claves.
Tenga en cuenta que el SSL del sistema (usado por el daemon) siempre utiliza ICSF, la interfaz al hardware de cifrado de System z, si está disponible. Para poder compartir las definiciones de daemon con el servidor cuando se utiliza ICSF, server_keystore_type JCECCARACFKS debe especificarse. Aquí, el conjunto de claves compatible con SAF también se utiliza como almacén de claves para las claves públicas, pero la clave privada se almacena en ICSF. Según se muestra en la documentación Cryptographic Services ICSF Administrator's Guide (SA22-7521), ICSF utiliza los perfiles en las clases de seguridad CSFKEYS y CSFSERV para controlar quién puede utilizar servicios y claves criptográficas.
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE DAEMON - SSL
//*
//RSED PROC TMPDIR=,
// PORT=,
// IVP=, * 'IVP' para hacer una prueba de IVP
// CNFG='/etc/rdz/ssl',
// HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
//RSED EXEC RSED
//*
La configuración del host de SSL está completa y el daemon RSE para SSL puede iniciarse sometiendo el trabajo FEK.#CUST.PROCLIB(RSEDSSL) creado anteriormente.
Ahora, puede probarse la configuración nueva conectándose con el cliente de Developer for System z. Dado que hemos creado una nueva configuración (clonando la existente) para que SSL la utilice, hay que definir una nueva conexión en el cliente utilizando el puerto 4047 para el daemon RSE.
Al conectarse, el host y el cliente se iniciarán con algún establecimiento de enlace para poder configurar una vía de acceso segura. Parte del establecimiento de enlace es el intercambio de certificados. El cliente Developer for System z, si no reconoce el certificado del host o la CA que lo ha firmado, el cliente de Developer for System z preguntará al usuario si el certificado es de confianza.
Con el botón Finalizar, el usuario puede aceptar este certificado como de confianza, después de lo cual continuará la inicialización de la conexión.
Una vez reconocido el certificado ante el cliente, este diálogo ya no vuelve a aparecer. La lista de certificados de confianza se puede gestionar seleccionando Ventana > Preferencias... > Sistemas Remotos > SSL, con lo cual aparece el diálogo:
Si la comunicación SSL falla, el cliente devolverá un mensaje de error. Hay más información en los distintos archivos de registro del usuario y del servidor, como se describe en: Daemon RSE y registro de la agrupaciones de hebras y Registro de usuario de RSE.
El daemon RSE admite que los usuarios se autentiquen con un certificado X.509. El uso de una comunicación cifrada con SSL es un requisito previo para utilizar esta función, dado que es una extensión de la autenticación de host con un certificado utilizado en SSL.
Hay varias formas de realizar la autorización de certificados para un usuario, tal como se describe en Autenticación de cliente mediante certificados X.509. Los siguientes pasos describen la configuración necesaria para soportar el método por el cual su software de seguridad autentica el certificado mediante la ampliación de certificado HostIdMappings.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') +
RING(rdzssl.racf))
Esta acción concluye la configuración del software de seguridad para el certificado de CA.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) +
ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
o bien
SETROPTS RACLIST(SERVAUTH) REFRESH
Esta acción concluye la configuración del software de seguridad para ampliación de HostIdMappings.
No realice este paso si utiliza un anillo de claves compatible con SAF para la base de datos de claves del daemon RSE.
gskkyman es un programa dirigido por menú y basado en la shell z/OS UNIX que crea, puebla y gestiona un archivo z/OS UNIX que contiene claves privadas, peticiones de certificado y certificados. Este archivo z/OS UNIX se llama base de datos de claves.
PATH=$PATH:/usr/lpp/gskssl/bin
export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH
export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl
$ gskkyman Menú de base de datos
1 - Crear base de datos nueva
Entre el número de opción: 1
Especifique el nombre de la base de datos de claves (pulse Intro para volver
al menú): rdzssl.kdb
Entre la contraseña de la base de datos (pulse Intro para volver al menú): rsessl
Vuelva a entrar la contraseña de la base de datos: rsessl
Entre el tiempo de caducidad de la contraseña en días (pulse Intro si no caduca):
Entre la longitud de registro de la base de datos (pulse Intro para utilizar 2500):
Se ha creado la base de datos de claves /etc/rdz/ssl/rdzssl.kdb.
Pulse Intro para continuar.
Menú de gestión de claves
6 - Crear un certificado autofirmado
Entre el número de opción (pulse Intro para volver al menú anterior): 6
Tipo de certificado
5 - Certificado de usuario o servidor con clave RSA de 1024 bits
Seleccione el tipo de certificado (pulse Intro para volver al menú): 5
Entre la etiqueta (pulse Intro para volver al menú): rdzrse
Entre el nombre de sujeto del certificado
Nombre común (necesario): rdz rse ssl
Unidad de organización (OU, opcional): rdz
Organización (necesario): IBM
Ciudad/Localidad (opcional): Raleigh
Estado/Provincia (opcional): NC
País/Región (2 caracteres - necesario): US
Entre el número de días durante los que el certificado será válido (valor
predeterminado, 365): 3650
Entre 1 para especificar nombres de sujetos alternativos o 0 para continuar: 0
Espere por favor .....
El certificado se ha creado.
Pulse Intro para continuar.
Menú de gestión de claves
0 - Salir del programa
Entre el número de opción (pulse Intro para volver al menú anterior): 0
$ ls -l rdzssl.*
total 152
-rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
$ chmod 644 rdzssl.*
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
En el ejemplo anterior se empieza por crear una base de datos de claves llamada rdzssl.kdb con la contraseña rsessl. Una vez creada la base de datos, ésta se llena creando un certificado autofirmado, válido durante 10 años (sin contar los días bisiestos). El certificado se almacena bajo la etiqueta rdzrse y que tiene la misma contraseña (rsessl) que la que se empleó para la base de datos de claves (este es un requisito de RSE).
gskkyman asigna la base de datos de claves con una máscara de bit de permiso 600 (muy seguro, el único que tiene acceso es el propietario). Los permisos se tienen que establecer para que sean menos restrictivos, a menos que el daemon utilice el mismo ID de usuario que el creador de la base de datos de claves. 644 (el propietario tiene acceso de lectura/escritura y los demás tienen acceso de lectura) es una máscara que se puede usar para el mandato chmod.
El resultado se puede verificar seleccionando la opción Mostrar información de certificado, en el submenú Gestionar claves y certificados, del siguiente modo:
$ gskkyman
Menú de base de datos
2 - Abrir base de datos
Entre el número de opción: 2
Especifique el nombre de la base de datos de claves (pulse Intro para volver
al menú): rdzssl.kdb
Entre la contraseña de la base de datos (pulse Intro para volver al menú): rsessl
Menú de gestión de claves
1 - Gestionar claves y certificados
Entre el número de opción (pulse Intro para volver al menú anterior): 1
Lista de claves y certificados
1 - rdzrse
Entre el número de etiqueta (Intro para volver al menú de selección, p para
lista anterior): 1
Menú de claves y certificados
1 - Mostrar información de certificado
Entre el número de opción (pulse Intro para volver al menú anterior): 1
Información de certificado
Etiqueta: rdzrse
ID de registro: 14
ID de registro del emisor: 14
De confianza: Sí
Versión: 3
Número de serie: 45356379000ac997
Nombre del emisor: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Nombre de sujeto: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Fecha de efectividad: 2007/05/24
Fecha de caducidad: 2017/05/21
Algoritmo de clave pública: rsaEncryption
Tamaño de clave pública: 1024
Algoritmo de signatura: sha1WithRsaEncryption
ID exclusivo del emisor: Ninguno
ID exclusivo del sujeto: Ninguno
Número de extensiones: 3
Entre 1 para visualizar las extensiones, entre 0 para volver al menú: 0
Menú de claves y certificados
0 - Salir del programa
Entre el número de opción (pulse Intro para volver al menú anterior): 0
El siguiente ejemplo de ssl.properties muestra que las directivas de daemon_* difieren del ejemplo de anillo de claves de SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties
-> cambiar: enable_ssl=true
-> descomentar y cambiar: daemon_keydb_file=rdzssl.kdb
-> descomentar y cambiar: daemon_keydb_password=rsessl
-> descomentar y cambiar: daemon_key_label=rdzrse
-> descomentar y cambiar: server_keystore_file=rdzssl.racf
-> descomentar y cambiar: server_keystore_label=rdzrse
-> descomentar y cambiar: server_keystore_type=JCERACFKS
Los cambios anteriores habilitan SSL e indican al daemon RSE que el certificado está almacenado bajo la etiqueta rdzrse en la base de datos de claves rdzssl.kdb con la contraseña rsessl. El servidor RSE sigue utilizando un anillo de claves compatible con SAF.
No realice este paso si utiliza un anillo de claves compatible con SAF para el almacén de claves del servidor RSE.
Toda la información se puede pasar como un parámetro, pero debido a las limitaciones de longitud que tiene la línea de mandatos, se necesita algo de interactividad, del siguiente modo:
$ cd /etc/rdz/ssl
$ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass
rsessl -keypass rsessl
¿Cuál es su nombre y su apellido?
[Desconocido]: rdz rse ssl
¿Cuál es el nombre de su unidad de organización (OU)?
[Desconocido]: rdz
¿Cuál es el nombre de su organización?
[Desconocido]: IBM
¿Cuál es el nombre de su ciudad o localidad?
[Desconocido]: Raleigh
¿Cuál es el nombre de su estado o provincia?
[Desconocido]: NC
¿Cuál es el código de dos letras de esta unidad?
[Desconocido]: US
¿Es CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US correcto? (escriba "yes"
o "no")
[no]: yes
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
El certificado autofirmado creado en el ejemplo anterior es válido durante 10 años (sin contar los días bisiestos). Se almacena en /etc/rdz/ssl/rdzssl.jks utilizando el alias rdzrse. Su contraseña (rsessl) es idéntica a la contraseña del almacén de claves, que es un requisito para RSE.
El resultado se puede verificar con la opción -list, del siguiente modo:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Nombre de alias: rdzrse
Fecha de creación: May 24, 2007
Tipo de entrada: keyEntry
Longitud de la cadena de certificados: 1
Certificado 1¨:
Propietario: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Emisor: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Número de serie: 46562b2b
Válido desde: 5/24/07 2:17 PM hasta: 5/21/17 2:17 PM
Huellas digitales del certificado
MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
El siguiente ejemplo de ssl.properties muestra que las directivas de server_* difieren del ejemplo de anillo de claves de SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties
-> cambiar: enable_ssl=true
-> descomentar y cambiar: daemon_keydb_file=rdzssl.racf
-> descomentar y cambiar: daemon_key_label=rdzrse
-> descomentar y cambiar: server_keystore_file=rdzssl.jks
-> descomentar y cambiar: server_keystore_password=rsessl
-> descomentar y cambiar: server_keystore_label=rdzrse
-> descomentar y cambiar (opcional): server_keystore_type=JKS
Los cambios anteriores habilitan la SSL e indican al servidor RSE que el certificado está almacenado bajo la etiqueta rdzrse en el almacén de claves rdzssl.jks con la contraseña rsessl. El daemon RSE sigue utilizando un anillo de claves compatible con SAF.
Esta sección se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar el protocolo AT-TLS (Application Transparent Transport Layer Security), o durante la comprobación o modificación de una configuración existente.
El protocolo de seguridad de la capa de transporte (TLS) definido en RFC 2246 proporciona privacidad en las comunicaciones realizadas a través de internet. Al igual que se predecesor SSL (capa de sockets seguros), el protocolo permite que las aplicaciones de servidor y cliente se comuniquen de una forma diseñada para evitar escuchas no autorizadas, manipulaciones indebidas y falsificaciones de mensajes. AT_TLS (Application Transparent Transport Layer Security) consolida la implementación de TLS para aplicaciones basadas en z/OS en una ubicación, permitiendo a todas las aplicaciones soportar el cifrado basado en TLS sin conocer el protocolo TLS. Consulte la publicación Communications Server IP Configuration Guide (SC31-8775) para obtener más información sobre AT-TLS.
El depurador integrado en IBM Rational Developer for System z confía en AT-TLS para las comunicaciones cifradas con el cliente, porque la sesión de depuración no fluye por el mismo sitio que otra comunicación entre el host y el cliente Developer for System z.
Las acciones necesarias para configurar AT-TLS varían de un sitio a otro, dependiendo de las necesidades exactas y de lo que ya esté disponible en ese momento.
En algunas tareas que se describen en las secciones siguientes, se espera que esté activo en z/OS UNIX. Para ello, emita el mandato TSO OMVS. Utilice el mandato oedit para editar archivos en z/OS UNIX. Utilice el mandato exit para volver a TSO.
La documentación de TCP/IP recomienda escribir mensajes del agente de política en el syslog de z/OS UNIX en lugar de utilizar el archivo de registro predeterminado. AT-TLS siempre escribe mensajes en el syslog de z/OS UNIX.
Para ello, el daemon syslog de z/OS UNIX, syslogd, tiene que estar configurado y activo. También necesitará un mecanismo para controlar el tamaño de los archivos de registro creados por syslogd.
syslog 514/udp
# /etc/syslog.conf - control output of syslogd
# 1. todos los archivos se imprimirán en /tmp/syslog.auth.log
auth.* /tmp/syslog.auth.log
# 2. todos los mensajes de error se imprimirán en /tmp/syslog.error.log
*.err /tmp/syslog.error.log
# 3. todos los mensajes anteriores y de depuración se imprimirán en
/tmp/syslog.debug.log
*.debug /tmp/syslog.debug.log
# Los archivos nombrados tienen que existir antes de que se inicie el
# daemon syslog,
a no ser que se utilice la opción de inicio -c
# Inicie el daemon SYSLOGD para el registro
# (limpie registros antiguos)
sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
# (cree registros nuevos y añada el ID de usuario del remitente del mensaje)
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
sleep 5
El soporte AT-TLS se activa mediante el parámetro TTLS en la sentencia TCPCONFIG del conjunto de datosPROFILE.TCPIP. AT-TLS se gestiona mediante el agente de política, que tiene que estar activo para poder imponer la política AT-TLS. Como el agente de política tiene que esperar a que TCP/IP esté activo, la sentenciaAUTOSTART de PROFILE.TCPIP es un buen lugar para activar el inicio de este servidor.
TCPCONFIG TTLS ; Required for AT-TLS
AUTOLOG
PAGENT ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG
//PAGENT PROC PRM='-L SYSLOGD' * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//* (PARM) (envar)
//* default cfg file: /etc/pagent.conf (-C) (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log (-L) (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
// PARM='ENVAR("TZ=EST5DST")/&PRM'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//*
#
# Información de configuración del agente de política TCP/IP.
#
TTLSConfig /etc/pagent.ttls.conf
# Especifica la vía de acceso de un archivo de política TTLS que retiene sentencias
# específicas de la pila.
#
#TcpImage TCPIP /etc/pagent.conf
# Si no se especifica ninguna sentencia TcpImage, se instalarán todas las políticas
# en la pila TCP/IP predeterminada.
#
#LogLevel 31
# La suma de los siguientes valores que representan niveles de registro:
# LOGL_SYSERR 1
# LOGL_OBJERR 2
# LOGL_PROTERR 4
# LOGL_WARNING 8
# LOGL_EVENT 16
# LOGL_ACTION 32
# LOGL_INFO 64
# LOGL_ACNTING 128
# LOGL_TRACE 256
# El nivel de registro 31 es el nivel de registro predeterminado.
#
#Página de códigos IBM-1047
# Especifique la página de códigos EBCDIC que se va a utilizar para leer todos
# los archivos de configuración y los archivos de definición de políticas.
# IBM-1047 es la página de códigos predeterminada.
Este archivo de configuración de muestra especifica dónde puede encontrar el agente de política la política TTLS. Utiliza los valores predeterminados del agente de política para otras sentencias.
Una política TTLS describe las reglas AT-TLS deseadas. Tal y como se define en el archivo de configuración del agente de política, la política TTLS se encuentra en /etc/pagent.ttls.conf. Más adelante se tratan las definiciones necesarias para su software de seguridad.
##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Dirección De entrada
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Conjunto de claves dbgmgr.racf
# El gestor de depuración debe poseer el conjunto de claves
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 solo para z/OS 2.1 y superior
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1
# están activados de forma predeterminada
}
}
##-----------------------------
TTLSRule RDz_Debug_Probe-Client
{
RemotePortRange 8001
Direction Outbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Probe-Client
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring *AUTH*/* # virtual key ring holding CA certificates
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 solo para z/OS 2.1 y superior
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSGroupAction grp_Production
{
TTLSEnabled Activado
## TLSv1.2zOS1.13 solo para z/OS 1.13
TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
Trace 3 # Log Errors to syslogd & IP joblog
#Trace 254 # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms TLSv1.2zOS1.13
{
Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
Una política TTLS tiene en cuenta gran cantidad de filtros para especificar cuando se aplica una regla.
El gestor de depuración es un servidor que escucha en el puerto 5335 conexiones de entrada del motor de depuración. Esta información se almacena en la regla RDz_Debug_Manager.
Como SSL y TLS requieren el uso de un certificado de servidor, especifique que el gestor de políticas tiene que utilizar los certificados del conjunto de claves dbgmgr.racf, propiedad del Id de usuario de tarea iniciada del gestor de depuración. De forma predeterminada, el soporte de TLS v1.2 está inhabilitado, por lo que esta política lo habilita explícitamente.
Cuando se inicia el analizador de depuración con la opción de Language Environment (LE) TEST(,,,TCPIP&&ipaddress%8001:*), se le solicita que no utilice el gestor de depuración, sino que se ponga en contacto con el cliente de Developer for System z directamente en el puerto 8001. Esto implica, desde una perspectiva TCP/IP, que el analizador de depuración basado en host es un cliente que se pone en contacto con un servidor (el Debug UI) en el cliente Developer for System z. Esta información se captura en la regla RDz_Debug_Probe-Client.
como el host es un cliente TCP/IP, el gestor de políticas necesitará validar el certificado de servidor presentado por el Debug UI. En lugar de utilizar un conjunto de claves con nombre para todos los usuarios que pueden necesitar una sesión de depuración cifrada, utilizamos en conjunto de claves virtual CERTAUTH de RACF (*AUTH*/*). Este conjunto de claves virtual contiene los certificados públicos de las entidades emisoras de certificados y puede utilizarse si el Debug UI presenta un certificado de servidor firmado por una de las entidades emisoras de certificados de confianza.
Tenga en cuenta que para políticas más complejas, debe utilizar el Asistente de configuración de IBM para z/OS Communications Server. Se trata de una herramienta basada en GUI que proporciona una interfaz guiada para configurar funciones de red basadas en políticas TCP/IP y está disponible como tarea en IBM z/OS Management Facility (z/OSMF) y como aplicación autónoma de la estación de trabajo.
El soporte de TLS v1.2 está disponible a partir de z/OS 2.1, y está inhabilitado de forma predeterminada. Esta política muestra el mandato (TLSV1.2 On) para habilitarlo de forma explícita, pero lo tiene descomentado porque el sistema de destino está utilizando z/OS 1.13.
#
# Añada soporte TLSv1.2 a AT-TLS
# es necesario z/OS 1.13 con OA39422 y PM62905
#
GSK_RENEGOTIATION=ALL
GSK_PROTOCOL_TLSV1_2=ON
Hay varias actualizaciones necesarias para su configuración de seguridad para que AT-TLS funcione correctamente. Esta sección incluye mandatos RACF de ejemplo para realizar la configuración necesaria.
# defina el ID de usuario de tarea iniciada
# El permiso BPX.DAEMON es necesario para un ID de usuario no cero
ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
NAME('TCP/IP POLICY AGENT') NOPASSWORD
# defina la tarea iniciada
RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
DATA('TCP/IP POLICY AGENT')
# renueve para que los cambios sean visibles
SETROPTS RACLIST(STARTED) REFRESH
# restrinja el inicio del agente de política
RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
DATA('restrict startup of policy agent')
PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)
# renueve para que los cambios sean visibles
SETROPTS RACLIST(OPERCMDS) REFRESH
# bloquee el acceso de pila entre la pila y la disponibilidad AT-TLS
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
# Agente de política
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
# Daemon OMPROUTE
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
# Agente SNMP y subagentes
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
# Daemon NAME
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)
# renueve para que los cambios sean visibles
SETROPTS RACLIST(SERVAUTH) REFRESH
# restrinja el acceso al mandato pasearch
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) +
# DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)
# renueve para que los cambios sean visibles
# SETROPTS RACLIST(SERVAUTH) REFRESH
# permita al gestor de depuración que acceda al certificado
#RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
# renueve para que los cambios sean visibles
SETROPTS RACLIST(FACILITY) REFRESH
# cree el certificado autofirmado
RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')
# (opcional) pasos adicionales necesarios para usar un certificado con firma
# 1. cree una solicitud de firma para el certificado autofirmado
RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
# 2. envíe la solicitud de firma a la CA de su elección
# 3. compruebe si las credenciales de la CA (también un certificado)
# ya se conocen
RACDCERT CERTAUTH LIST
# 4. marque el certificado de autoridad emisora de certificados como fiable
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# o añada el certificado de autoridad emisora de certificados a la base
# de datos
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. añada el certificado firmado a la base de datos;
# de esta forma se sustituye el autofirmado
RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
# NO suprima el certificado autofirmado antes de sustituirlo.
# Si lo hace, perderá la clave privada que acompaña al certificado,
# lo que hace que el certificado no sirva para nada.
# cree un conjunto de claves
RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)
# añada el certificado al conjunto de claves
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)
# paso adicional necesario para utilizar un certificado firmado
# 6. añada el certificado de autoridad emisora de certificados al conjunto de
claves
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
RING(dbgmgr.racf))
# renueve para que los cambios sean visibles
SETROPTS RACLIST(DIGTCERT) REFRESH
# compruebe si las credenciales de la CA (también un certificado) ya se conocen
RACDCERT CERTAUTH LIST
# marque el certificado de autoridad emisora de certificados como fiable
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# o añada el certificado de autoridad emisora de certificados a la base
# de datos
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# renueve para que los cambios sean visibles
SETROPTS RACLIST(DIGTCERT) REFRESH
# verifique la configuración de la tarea iniciada
LISTGRP SYS1 OMVS
LISTUSER PAGENT OMVS
RLIST STARTED PAGENT.* ALL STDATA
# verifique el permiso de inicio dl agente de política
RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL
# verifique la protección de initstack
RLIST SERVAUTH EZB.INITSTACK.** ALL
# verifique la protección de pasearch
RLIST SERVAUTH EZB.PAGENT.** ALL
# verifique la configuración del certificado
RACDCERT CERTAUTH LIST(LABEL('CA cert'))
RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)
TCPCONFIG TTLS
V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
S PAGENT
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
P DBGMGR
S DBBMGR
Esta sección se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar TCP/IP, o durante la tarea de comprobar o modificar una configuración existente.
Consulte las publicaciones Communications Server: IP Configuration Guide (SC31-8775) y Communications Server: IP Configuration Reference (SC31-8776) para obtener más información acerca de la configuración de TCP/IP.
Al utilizar APPC para el servicio de mandatos TSO, Developer for System z depende de que TCP/IP tenga el nombre de host correcto cuando se inicializa. Ello implica que los distintos archivos de configuración de TCP/IP y del resolviente estén configurados correctamente.
Puede probar la configuración de TCP/IP con IVP (programa de verificación de la instalación) fekfivpt. El mandato debe devolver datos de salida parecidos a los de este ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpt
Wed Jul 2 13:11:54 EDT 2008
uid=1(USERID) gid=0(GROUP)
using /etc/rdz/rsed.envvars
-------------------------------------------------------------
configuración del resolviente TCP/IP (orden de búsqueda de z/OS UNIX):
-------------------------------------------------------------
Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964
Valores de resolviente res_init:
Conjunto de datos Tcp/Ip global = Ninguno
Conjunto de datos Tcp/Ip predeterminado = Ninguno
Conjunto de datos Tcp/Ip local = /etc/resolv.conf
Tabla de conversión = Predeterminada
IDusuario/NombreTrabajo = USERID
API llamante = LE C Sockets
Modalidad llamante = EBCDIC
(L) DataSetPrefix = TCPIP
(L) HostName = CDFMVS08
(L) TcpIpJobName = TCPIP
(L) DomainOrigin = RALEIGH.IBM.COM
(L) NameServer = 9.42.206.2
9.42.206.3
(L) NsPortAddr = 53 (L) ResolverTimeout = 10
(L) ResolveVia = UDP (L) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (L) MessageCase = MIXED
(*) LookUp = DNS LOCAL
res_init Satisfactoria
res_init Iniciada: 2008/07/02 13:11:54.755363
res_init Finalizada: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9 Nombre TCPIP: TCPIP 13:11:54
Tcpip iniciado a las 01:28:36 el 06/23/2008 con IPv6 habilitado
-------------------------------------------------------------
dirección IP del host:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75
Satisfactorio, coincidencia de direcciones
El resolviente funciona en nombre de los programas como un cliente que accede a los servidores de nombres para obtener una resolución de nombre en dirección o una resolución de dirección en nombre. Para resolver la consulta del programa peticionario, el resolviente puede acceder a los servidores de nombres disponibles, utilizar definiciones locales (por ejemplo, /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO o ETC.IPNODES), o utilizar una combinación de ambos.
El resolviente, al iniciarse su espacio de direcciones, lee un conjunto de datos de instalación opcional del resolviente hacia el que señala la tarjeta DD SETUP en el procedimiento del JCL del resolviente. Si no se proporciona información de instalación, el resolviente utiliza el orden de búsqueda nativo de MVS o z/OS UNIX aplicable sin ninguna información de GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES o COMMONSEARCH.
Es importante comprender el orden de búsqueda de archivos de configuración que las funciones de TCP/IP utilizan, y conviene saber cuándo se puede alterar temporalmente el orden de búsqueda predeterminado con las variables de entorno, con el JCL o con otras variables que proporcione. Este conocimiento le permite acomodar sus estándares de denominación de los conjuntos de datos y archivos de HFS locales, y también le resultará de utilidad conocer el conjunto de datos o archivo de HFS de configuración al diagnosticar problemas.
Otro punto importante a tener en cuenta es que cuando se aplica un orden de búsqueda para cualquier archivo de configuración, la búsqueda finaliza con el primer archivo que se encuentre. Por lo tanto, es posible obtener resultados inesperados si coloca información de configuración en un archivo que nunca se va a encontrar, ya sea porque existen otros archivos antes según el orden de la búsqueda, o porque el archivo no está incluido en el orden de búsqueda elegido por la aplicación.
Al buscar archivos de configuración, puede indicar explícitamente a TCP/IP dónde está la mayoría de los archivos de configuración, utilizando para ello sentencias DD en los procedimientos del JCL o estableciendo variables de entorno. Por otro lado, puede dejar que sea TCP/IP el que determine dinámicamente la ubicación de los archivos de configuración, basándose en el orden de búsqueda documentado en la publicación Communications Server: IP Configuration Guide (SC31-8775).
El componente de configuración de la pila de TCP/IP utiliza TCPIP.DATA durante la inicialización de la pila de TCP/IP para determinar el nombre de host (HOSTNAME) de la pila. Para obtener este valor, se utiliza el orden de búsqueda del entorno z/OS UNIX.
El archivo o tabla concreto que se busca puede ser un conjunto de datos MVS o un archivo HFS, en función de los valores de configuración del resolviente y de la presencia de determinados archivos en el sistema.
El archivo de configuración de resolviente base contiene sentencias TCPIP.DATA. Además de las directivas del resolviente, se le hace referencia para determinar, entre otras cosas, el prefijo de conjunto de datos (valor de la sentencia DATASETPREFIX) que hay que utilizar al intentar acceder a algunos de los archivos de configuración especificados en esta sección.
El orden de búsqueda empleado para acceder al archivo de configuración resolviente base es el siguiente:
Si está definido, se utiliza el valor de la sentencia de configuración GLOBALTCPIPDATA del resolviente (vea también: ¿Qué son los resolvientes?). La búsqueda continúa hasta encontrar un archivo de configuración adicional. La búsqueda finaliza con el próximo archivo encontrado.
Se utiliza el valor de la variable de entorno. Esta búsqueda fallará si el archivo no existe o si se ha asignado de manera exclusiva en otra parte.
Se utiliza el conjunto de datos asignado a la DD de nombre SYSTCPD. En el entorno z/OS UNIX, un proceso hijo no tiene acceso a la DD SYSTCPD. Ello se debe a que la asignación de SYSTCPD no se hereda del proceso padre por las llamadas a fork() o a la función exec.
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones, tarea o hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
Si está definido, se utiliza el valor de la sentencia de configuración DEFAULTTCPIPDATA del resolviente (vea también: ¿Qué son los resolvientes?).
A las tablas de conversión (de EBCDIC a ASCII y de ASCII a EBCDIC) se les hace referencia para determinar los conjuntos de datos de conversión que hay que utilizar. El orden de búsqueda empleado para acceder a este archivo de configuración es el siguiente. La búsqueda finaliza en el primer archivo encontrado:
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones o tarea/hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
Por defecto, en primer lugar el resolviente intenta utilizar los servidores de nombres de dominio que estén configurados para las peticiones de resolución. Si la petición de resolución no se puede satisfacer, se emplean las tablas de hosts locales. El comportamiento del resolviente se controla mediante las sentencias TCPIP.DATA.
Las sentencias TCPIP.DATA del resolviente definen si hay que utilizar los servidores de nombres de dominio y cómo hay que hacerlo. La sentencia LOOKUP TCPIP.DATA también puede servir para controlar cómo se utilizan los servidores de nombres de dominio y las tablas de hosts locales. Para obtener más información sobre las sentencias TCPIP.DATA, consulte la publicación Communications Server: IP Configuration Reference (SC31-8776).
El resolviente emplea el orden de búsqueda exclusivo de Ipv4 para obtener información de nombres de locales incondicionalmente para las llamadas a la API getnetbyname. El orden de búsqueda exclusivo de Ipv4 para obtener información de nombres de locales es el siguiente. La búsqueda finaliza en el primer archivo encontrado:
El valor de la variable de entorno es el nombre del archivo de información HOSTS.SITEINFO creado por el mandato TSO MAKESITE.
El valor de la variable de entorno es el nombre del archivo de información HOSTS.ADDRINFO creado por el mandato TSO MAKESITE.
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones o tarea/hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
Tal como se ha indicado antes, Developer for System z depende de que TCP/IP tenga el nombre de host correcto en el momento de la inicialización cuando se está utilizando APPC. Ello implica que los distintos archivos de configuración de TCP/IP y del resolviente estén configurados correctamente.
El ejemplo siguiente se centra en algunas tareas de configuración de TCP/IP y del resolviente. Tenga en cuenta que no se trata de describir una configuración completa de TCP/IP o del resolviente, sino tan solo de resaltar algunos aspectos clave que podrían ser válidos para su local:
//TCPIP PROC PARMS=’CTRACE(CTIEZB00)’,PROF=TCPPROF,DATA=TCPDATA
//*
//* RED TCP/IP
//*
//TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS
//PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF)
//SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA)
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSERROR DD SYSOUT=*
; HOSTNAME especifica el nombre de host TCP de este sistema. Si no
; se especifica, el HOSTNAME predeterminado será el nombre de nodo especificado
; en el miembro IEFSSNxx PARMLIB.
;
; HOSTNAME
;
; DOMAINORIGIN especifica el origen de dominio que se añadirá
; a los nombres de host que se pasen al resolviente. Si un nombre de host
; contiene puntos, el DOMAINORIGIN no se añadirá al final del
; nombre de host.
;
DOMAINORIGIN RALEIGH.IBM.COM
;
; NSINTERADDR especifica la dirección IP del servidor de nombres.
; LOOPBACK (14.0.0.0) especifica el servidor de nombres local. Si
; no se va a emplear uno, no codifique una sentencia NSINTERADDR.
; (Descomente la siguiente línea NSINTERADDR). Hará que todos los nombres
; se resuelvan por medio de la búsqueda de la tabla de locales.
;
; NSINTERADDR 14.0.0.0
;
; TRACE RESOLVER provocará un rastreo completo de todas las consultas y
; respuestas del servidor de nombres o de las tablas de locales, que se
; van a grabar en la consola de usuario. Este mandato solo tiene fines
; de depuración.
;
; TRACE RESOLVER
//RESOLVER PROC PARMS=’CTRACE(CTIRES00)’
//*
//* IP NAME RESOLVER – START WITH SUB=MSTR
//*
//RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP
DomainOrigin RALEIGH.IBM.COM
HostName CDFMVS08
Como ya se ha mencionado en: Orden de búsqueda utilizado en el entorno z/OS UNIX, el archivo de configuración base contiene sentencias TCPIP.DATA. Si el nombre del sistema es CDFMVS08 (TCPDATA indicaba que se utiliza el nombre del sistema como nombre de host), podemos ver que /etc/resolv.conf está en sincronización con SYS1.TCPPARMS(TCPDATA). No hay definiciones de DNS y, por lo tanto, se utilizará la búsqueda de la tabla de locales.
# Resolviente /etc/hosts file cdfmvs08
9.42.112.75 cdfmvs08 # Host CDFMVS08
9.42.112.75 cdfmvs08.raleigh.ibm.com # Host CDFMVS08
127.0.0.1 localhost
El contenido mínimo de este archivo es información sobre el sistema actual. En el ejemplo anterior, tanto cdfmvs08 como cdfmvs08.raleigh.ibm.com se definen como un nombre válido para la dirección IP del sistema z/OS.
Si utiliza un servidor de nombres de dominio (DNS), el DNS contendría la información de /etc/hosts, y /etc/resolv.conf y SYS1.TCPPARMS(TCPDATA) tendrían sentencias que identificarían el DNS ante su sistema.
Para evitar confusiones, debe mantener los archivos de configuración de TCP/IP y del resolviente sincronizados entre sí.
Descripción de tipo de archivo | Interfaces API afectadas | Archivos candidatos |
---|---|---|
Archivos de configuración de resolviente base | Todas las API |
|
Tablas de conversión | Todas las API |
|
Tablas de hosts locales | endhostent |
IPv4
IPv6
|
clientip(0.0.0.0) <> callerip(<dirección IP host>)
Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964
Valores de resolviente res_init:
Conjunto de datos Tcp/Ip global = Ninguno
Conjunto de datos Tcp/Ip predeterminado = Ninguno
Conjunto de datos Tcp/Ip local = /etc/resolv.conf
Tabla de conversión = Predeterminada
IDusuario/NombreTrabajo = USERID
API llamante = LE C Sockets
Modalidad llamante = EBCDIC
Asegúrese de que las definiciones del archivo (o del conjunto de datos) a las que hace referencia “Conjunto de datos Tcp/Ip local” sean correctas.
Este campo estará en blanco si no utiliza un nombre predeterminado para el archivo resolviente de IP (utilizando el orden de búsqueda de z/OS UNIX). Si es así, añada la sentencia siguiente a rsed.envvars, donde <archivo resolviente> o <conjunto datos resolviente> representa el nombre del archivo resolviente de IP:
RESOLVER_CONFIG=<archivo resolviente>
o bien
RESOLVER_CONFIG=’<conjunto datos resolviente>’
Las publicaciones a las que se hace referencia en este documento son:
Título de la publicación | Número de pedido | Referencia | Sitio Web de referencia |
---|---|---|---|
Program Directory for IBM Rational Developer for System z | GI11-8298 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Program Directory for IBM Rational Developer for System z Host Utilities | GC43-0676 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Requisitos previos de IBM Rational Developer for System z | SC43-0674 (SC23-7659) | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Guía de inicio rápido de configuración de host de IBM Rational Developer for System z | GI11-8628 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Guía de configuración de host IBM Rational Developer for System z | SC11-3660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Guía de referencia de configuración de host de IBM Rational Developer for System z | SC11-7903 (SC14-7290) | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Guía del programa de utilidad de configuración de host de IBM Rational Developer for System z | SC11-7871 (SC14-7282) | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Messages and Codes | SC14-7497 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Answers to common host configuration and maintenance issues | SC14-7373 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Requisitos previos de IBM Rational Developer for System z | SC43-0674 (SC23-7659) | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
Guía de inicio rápido de configuración de host de IBM Rational Developer for System z | GI11-8628 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
Guía del administrador de SCLM Developer Toolkit | SC11-3815-00 (SC23-9801) | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using APPC to provide TSO command services | SC14-7291 | Libro blanco | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using ISPF Client Gateway to provide CARMA services | SC14-7292 | Libro blanco | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Diagnóstico: Ayudas de servicio y herramientas | GA22-7589 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Java™ Diagnostic Guide | SC34-6650 | Java 6.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 6.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Resource Definition Guide | SC34-7181 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-7179 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Language Reference | SC27-1408 | Enterprise COBOL para z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Descripción | Sitio Web de referencia |
---|---|
Developer for System z IBM Knowledge Center | http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html |
Biblioteca de Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Página inicial de Developer for System z | http://www-03.ibm.com/software/products/en/developerforsystemz/ |
Servicio recomendado de Developer for System z | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Solicitud de mejora de Developer for System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
Biblioteca internet de z/OS | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
CICSTS IBM Knowledge Center | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
IBM Tivoli Directory Server | http://www-01.ibm.com/software/tivoli/products/directory-server/ |
Plug-ins de herramientas de determinación de problemas | http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/ |
Información de seguridad de Java | http://www.ibm.com/developerworks/java/jdk/security/ |
Descargar Apache Ant | http://ant.apache.org/ |
Documentación de keytool de Java | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Página inicial de soporte de CA | https://support.ca.com/ |
Título de la publicación | Número de pedido | Referencia | Sitio web de referencia |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
System Programmer’s Guide to: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli Directory Server for z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation 1992, 2013.
Derechos restringidos de los usuarios del Gobierno de EE. UU. - El uso, la reproducción o la divulgación están sujetos a las restricciones establecidas en el contrato GSA ADP Schedule Contract con IBM Corp.
Esta información se ha desarrollado para productos y servicios ofrecidos en los Estados Unidos de América.
Es posible que IBM no ofrezca en otros países los productos, servicios o características que se describen en este documento. El representante local de IBM le puede informar acerca de los productos y servicios que actualmente están disponibles en su localidad. Las referencias hechas a productos, programas o servicios de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios de IBM. Puede utilizarse en su lugar cualquier otro producto, programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedad intelectual de IBM. No obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.
IBM puede tener patentes o solicitudes de patente pendientes de aprobación que cubran alguno de los temas tratados en este documento. La posesión de este documento no le otorga ninguna licencia sobre dichas patentes. Puede enviar consultas sobre licencias por escrito a:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
Estados Unidos de América
Para consultas sobre licencias relativas a la información de juego de caracteres de doble byte (DBCS), póngase en contacto con el departamento de propiedad intelectual de IBM en su país o envíe las consultas, por escrito, a:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japón
El párrafo que sigue no se aplica al Reino Unido ni a ningún otro país en el que tales disposiciones sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL", SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, DE COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la declaración de limitación de responsabilidad, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso.
Esta información puede contener imprecisiones técnicas o errores tipográficos. La información incluida en este documento está sujeta a cambios periódicos; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento y sin previo aviso.
Cualquier referencia de esta información a sitios web que no sean de IBM se proporciona únicamente como ayuda y no se consideran en modo alguno como aprobados por IBM. Los materiales de dichos sitios web no forman parte de los materiales para este producto de IBM y el uso de dichos sitios web corre a cuenta y riesgo del Cliente.
IBM puede utilizar o distribuir la información que usted le suministre del modo que IBM considere conveniente sin incurrir por ello en ninguna obligación para con usted.
Los licenciatarios de este programa que deseen obtener información acerca de él con el fin de: (i) intercambiar la información entre los programas creados independientemente y otros programas (incluido este) y (ii) utilizar mutuamente la información que se ha intercambiado, deben ponerse en contacto con:
Intellectual Property Dept. for Rational Software
IBM Corporation
Silicon Valley Lab
555 Bailey Avnue
San Jose, CA 95141-1003
Estados Unidos de América
Dicha información puede estar disponible, sujeta a los términos y condiciones apropiados, incluyendo en algunos casos el pago de una cantidad.
IBM proporciona el programa bajo licencia descrito en este documento, así como todo el material bajo licencia disponible, según los términos del Acuerdo de Cliente de IBM, del Acuerdo Internacional de Programas bajo Licencia de IBM o de cualquier otro acuerdo equivalente entre ambas partes.
Los datos de rendimiento que se indican en este documento se han obtenido en un entorno controlado. Por consiguiente, es posible que los resultados que se obtengan en otros entornos operativos sean notablemente distintos. Es posible que algunas mediciones se hayan tomado en sistemas de nivel de desarrollo y no existe ningún tipo de garantía de que dichas mediciones sean las mismas en sistemas disponibles para el público en general. Además, es posible que algunas mediciones se hayan estimado mediante extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deberán verificar los datos aplicables para su entorno específico.
La información concerniente a productos no IBM se ha obtenido de los suministradores de dichos productos, de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no ha comprobado dichos productos y no puede afirmar la exactitud en cuanto a rendimiento, compatibilidad u otras características relativas a productos no IBM. Las consultas acerca de las posibilidades de los productos que no son de IBM deben dirigirse a las personas que los suministran.
Todas las declaraciones relacionadas con la dirección o intención futuras de IBM están sujetas a cambio o retirada sin previo aviso, y únicamente representan objetivos.
Esta información contiene ejemplos de datos e informes utilizados en operaciones comerciales diarias. Para ilustrarlos de la forma más completa posible, los ejemplos incluyen nombres de personas, empresas, marcas y productos. Todos estos nombres son ficticios y cualquier parecido con los nombres y direcciones utilizados por una empresa real es mera coincidencia.
Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que ilustran las técnicas de programación en diversas plataformas operativas. Puede copiar, modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar a IBM, con intención de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con la interfaz de programación de aplicaciones (API) de la plataforma operativa para la que están escritos los programas de ejemplo. Los ejemplos no se han probado minuciosamente bajo todas las condiciones. Por lo tanto, IBM no puede garantizar ni dar por sentada la fiabilidad, la facilidad de mantenimiento ni el funcionamiento de los programas. Los programas de ejemplo se proporcionan "TAL CUAL", sin ningún tipo de garantía. IBM no se hace responsable de los daños que se hayan podido causar debido al uso de los programas de ejemplo.
Cada copia o parte de estos programas de ejemplo o cualquier trabajo derivado debe incluir un aviso de copyright como el siguiente:
© (nombre de la empresa) (año). Partes de este código se derivan de IBM Corp. Sample Programs. © Copyright IBM Corp. 1992, 2013.
Si está visualizando esta información en formato de copia software, es posible que las fotografías y las ilustraciones en color no aparezcan.
Los productos de software de IBM, incluyendo el software como soluciones de servicio, (“Ofertas de software”) pueden utilizar cookies u otras tecnologías para recopilar información de utilización del producto, para ayudar a mejorar la experiencia del usuario final, para adaptar interacciones con el usuario final o a otros efectos. En muchos casos las Ofertas de software no recopilan información que permita la identificación personal. Algunas de nuestras Ofertas de software pueden ayudarle a recopilar información que permite la identificación personal. Si esta Oferta de software utiliza cookies para recopilar información que permite la identificación personal, a continuación se expondrá información específica sobre el uso de cookies por parte de esta oferta.
Esta Oferta de software no utiliza cookies ni otras tecnologías para recopilar información identificable personalmente.
IBM, el logotipo de IBM e ibm.com son marcas comerciales o marcas registradas de International Business Machines Corp., registradas en muchas jurisdicciones de todo el mundo. Otros nombres de productos y servicios pueden ser marcas registradas de IBM u otras empresas. Hay una lista actualizada de marcas registradas de IBM en la web "Copyright and trademark information" en www.ibm.com/legal/copytrade.shtml.
Aplicabilidad
Estos términos y condiciones son adicionales a los términos de uso para el sitio web de IBM.
Utilización personal
Puede reproducir estas publicaciones para su uso personal, no comercial suponiendo que se conserven todos los avisos de propiedad. No puede distribuir ni mostrar estas publicaciones o partes de ellas ni realizar trabajos derivados de ellas sin el consentimiento expreso de IBM.
Utilización comercial
Puede reproducir, distribuir y mostrar estas publicaciones solamente dentro de su empresa suponiendo que se conserven todos los avisos de propiedad. No puede realizar trabajos derivados de estas publicaciones ni reproducir, distribuir o mostrar estas publicaciones o partes de ellas fuera de su empresa sin el consentimiento expreso de IBM.
Derechos
Excepto lo expresamente otorgado en este permiso, no se otorga ningún otro permiso, licencia o derecho, ya sea expresa o implícitamente, sobre las publicaciones o sobre cualesquiera información, datos, software u otro tipo de propiedad intelectual contenida dentro.
IBM se reserva el derecho de retirar los permisos otorgados aquí siempre que, según su criterio, la utilización de las publicaciones vaya en detrimento de sus intereses o, según determine IBM, las instrucciones indicadas más arriba no se sigan adecuadamente.
No puede descargar, exportar ni reexportar esta información si no es en total conformidad con las leyes y regulaciones aplicables, incluyendo todas las leyes y regulaciones de exportación de Estados Unidos de América.
IBM NO GARANTIZA EL CONTENIDO DE ESTAS PUBLICACIONES. LAS PUBLICACIONES SE PROPORCIONAN "TAL-CUAL" Y SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPRESA O IMPLÍCITA, INCLUYENDO PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS DE COMERCIALIZACIÓN, NO VULNERACIÓN E IDONEIDAD PARA UN PROPÓSITO DETERMINADO.
Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que ilustran las técnicas de programación en diversas plataformas operativas. Puede copiar, modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar a IBM, con intención de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con la interfaz de programación de aplicaciones (API) de la plataforma operativa para la que están escritos los programas de ejemplo. Los ejemplos no se han probado minuciosamente bajo todas las condiciones. Por lo tanto, IBM no puede garantizar ni dar por sentada la fiabilidad, la facilidad de mantenimiento ni el funcionamiento de los programas. Los programas de ejemplo se proporcionan "TAL CUAL", sin ningún tipo de garantía. IBM no se hace responsable de los daños que se hayan podido causar debido al uso de los programas de ejemplo.
IBM, el logotipo de IBM e ibm.com son marcas comerciales o marcas registradas de International Business Machines Corp., registradas en muchas jurisdicciones de todo el mundo. Otros nombres de productos y servicios pueden ser marcas registradas de IBM u otras empresas. Hay una lista actual de marcas registradas de IBM disponible en la web en www.ibm.com/legal/copytrade.shtml
Adobe y PostScript son marcas registradas de Adobe Systems Incorporated.
Cell Broadband Engine - Sony Computer Entertainment Inc.
Rational es una marca registrada de International Business Machines Corporation y Rational Software Corporation, en los Estados Unidos o en otros países.
Intel, Intel Centrino, Intel SpeedStep, Intel Xeon, Celeron, Itanium y Pentium son marcas registradas de Intel Corporation, en los Estados Unidos y/o en otros países.
IT Infrastructure Library es una marca registrada de Central Computer and Telecommunications Agency
ITIL es una marca registrada de The Minister for the Cabinet Office
Linear Tape-Open, LTO y Ultrium son marcas registradas de HP, IBM Corp. y Quantum
Linux es una marca registrada de Linus Torvalds
Microsoft, Windows y el logotipo de Windows son marcas registradas de Microsoft Corporation en los Estados Unidos y/o en otros países.
Java y todas las marcas registradas y logotipos basados en Java son marcas registradas de Sun Microsystems, Inc. en los Estados Unidos y en otros países.
UNIX es una marca registrada de The Open Group en los Estados Unidos y/o en otros países.