IBM Rational Developer for z Systems Versión 9.5.1

Guía de referencia de configuración del host

SC43-2925-00

Contenido

Nota: Antes de utilizar esta información, debe leer la información general que figura en el apartado Avisos.

Décima edición (septiembre de 2015)

Inicio del cambioEsta edición corresponde a IBM® Rational Developer for z Systems Versión 9.5 (número de programa 5724-T07, o parte del número de programa 5697-CDT)) y a todos los releases y modificaciones posteriores mientras no se indique lo contrario en nuevas ediciones.Fin del cambio

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, 2015

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.

Acerca de este documento

Este documento proporciona información básica sobre diferentes tareas de configuración de IBM Rational Developer for z Systems y otros componentes y productos de z/OS (como WLM y TCP/IP).

De aquí en adelante, en este manual se utilizarán los siguientes nombres:
  • Inicio del cambioIBM Explorer for z/OS de denomina z/OS Explorer.Fin del cambio
  • IBM Rational Developer for z Systems se denomina Developer for z Systems.
  • ElIBM Rational Developer for z Systems Depurador integrado se denomina Depurador integrado.
  • Common Access Repository Manager se denominará CARMA.
  • Software Configuration and Library Manager Developer Toolkit se denominará SCLM Developer Toolkit, cuya abreviatura es SCLMDT.
  • z/OS UNIX System Services se denomina z/OS UNIX.
  • Customer Information Control System Transaction Server se denomina CICSTS y se abrevia como CICS.
Este documento forma parte de un conjunto de documentos que describen la configuración de host de Developer for z Systems. Cada uno de estos documentos está dirigido a un público específico. No es necesario que lea todos los documentos para completar la configuración de Developer for z Systems.
  • En la Guía de configuración de host de IBM Rational Developer for z Systems SC43-2926 (SC27-8577) se describen detalladamente todas las tareas y opciones (incluidas las que son opcionales) de planificación y configuración y se proporcionan escenarios alternativos.
  • En la Guía de referencia de configuración de host de IBM Rational Developer for z Systems SC43-2925 (SC27-8578) describe el diseño de Developer for z Systems y proporciona información previa para varias tareas de configuración de componentes de Developer for z Systems, z/OS y otros productos (tales como WLM y TCP/IP) relacionados con Developer for z Systems.
  • En la Guía de inicio rápido de configuración de host de IBM Rational Developer for z Systems (GI11-8628) se describe una configuración mínima de Developer for z Systems.

La información de este documento se aplica a todos los paquetes de IBM Rational Developer for z Systems Versión 9.5.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 z Systems SC43-2925 (SC27-8578) 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 recientes de toda la documentación, incluyendo instrucciones de instalación, libros blancos, podcasts y guías de aprendizaje, consulte la página de la biblioteca del sitio web de IBM Rational Developer for z Systems (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).

A quién va dirigido este documento

Este documento está destinado a los programadores de sistemas que configuran y ajustan IBM Rational Developer for z Systems Versión 9.5.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.

Resumen de cambios

Inicio del cambioEn esta sección se muestra un resumen de los cambios de la publicación Guía de referencia de configuración del host de IBM Rational Developer for z Systems Versión 9.5.1, SC43-2925-00 (SC27-8578-00) (actualizada en diciembre de 2015).Fin del cambio

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.

Inicio del cambioInformación nueva:Fin del cambio

Inicio del cambio
  • Utilizar nuevos nombres de conjunto de datos de MVS y vías de acceso de z/OS UNIX
Fin del cambio

Inicio del cambioInformación eliminada:Fin del cambio

Inicio del cambioEn la versión 9.5.1, las funciones relacionadas con el supervisor de trabajos RSE y JES se han trasladado de IBM Rational Developer for z Systems a otro producto, IBM Explorer for z/OS. Este movimiento incluye la documentación relacionada.Fin del cambio

Inicio del cambio
  • Se eliminan de todos los capítulos datos específicos de RSE
  • Se eliminan de todos los capítulos datos específicos del supervisor de trabajos JES
  • Se eliminan de todos los capítulos datos específicos del servicio de mandatos TSO
  • Los datos de envío a cliente para la gestión de configuración y versión se elimina de todos los capítulos
  • Se ha eliminado la documentación sobre cómo configurar TCP/IP
Fin del cambio

Inicio del cambioEste documento contiene información presentada anteriormente en la Guía de referencia de configuración del host de IBM Rational Developer for z Systems Versión 9.5 , SC11-7903-09 (SC14-7290-09)..Fin del cambio

Inicio del cambioInformación nueva:Inicio del cambioFin del cambio Fin del cambio
Inicio del cambioInformación eliminada:Inicio del cambio
  • El Gestor de despliegue de aplicaciones ya no se suministra, por lo que toda la información sobre éste se ha eliminado.
Fin del cambio Fin del cambio

Inicio del cambioEste documento contiene información presentada anteriormente en la Guía de referencia de configuración del host IBM Rational Developer for System z Versión 9.1.1, SC11-7903-08 (SC14-7290-08).Fin del cambio

Información nueva:

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 (SC14-7290-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 9.0.1, SC11-7903-07.

Información nueva:
  • Se añadido información sobre la configuración de AT-TLS. Consulte Configurar AT-TLS.

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.0.1, SC11-7903-05 (SC14-7290-05).

Información nueva:

  • Se ha añadido información sobre nombres de archivos de registro con fecha y hora. Consulte Archivos de registro.
  • Se añadido información sobre sucesos auditables nuevos. Consulte Datos de auditoría.
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.0, SC11-7903-04 (SC14-7290-04).
Información nueva:

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.5.1, SC11-7903-03 (SC14-7290-03).

Información nueva:

Este documento contiene información presentada anteriormente en la IBM Rational Developer for System z versión 8.5 Referencia de configuración de host, SC11-7903-02.

Información nueva:

Descripción del contenido del documento

En esta sección se resume la información presentada en este documento.

Comprender Developer for z Systems

El host de Developer for z Systems 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.

Consideraciones relativas a la seguridad

Inicio del cambioDeveloper for z Systems interactúa con otros componentes de host, lo que tiene implicaciones de seguridad.Fin del cambio

Consideraciones sobre TCP/IP

Developer for z Systems 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.

Consideraciones sobre WLM

Al contrario que las aplicaciones z/OS tradicionales, Developer for z Systems no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for z Systems 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.

Consideraciones sobre Enviar a cliente

Inicio del cambioDeveloper for z Systems amplía el control de cliente basado en host o envío a cliente de z/OS Explorer con soporte para definiciones de proyectos.Fin del cambio

Consideraciones de CICSTS

Este capítulo contiene información útil para un administrador de CICS Transaction Server.

Inicio del cambio

Configurar AT-TLS

Inicio del cambioEsta 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.Fin del cambio

Fin del cambio

Comprender Developer for z Systems

El host de Developer for z Systems 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.

Inicio del cambioDeveloper for z Systems se construye encima de IBM Explorer for z/OS. Para obtener información relacionada con z/OS Explorer, consulte el apartado relativo a las consideraciones sobre seguridad en la publicación IBM Explorer for z/OS Host Configuration Reference (SC27-8438).Fin del cambio

Visión general de los componentes

Figura 1. Visión general de los componentes
Visión general de los componentes
La Figura 1 muestra una visión general del diseño de z/OS Explorer y Developer for z Systems combinado en el sistema host. Inicio del cambio
  • El Explorador de sistemas remotos (RSE) proporciona servicios del núcleo como los de conectar el cliente al host e iniciar otros servidores para servicios específicos. El RSE consta de dos entidades lógicas:
    • El daemon RSE (RSED), que gestiona la configuración de conexiones. El daemon RSE es responsable de la ejecución en modalidad de servidor único. Para ello, el daemon RSE crea uno o varios procesos hijo conocidos como agrupaciones de hebras RSE (RSEDx).
    • El servidor RSE, que maneja las solicitudes de clientes individuales. Un servidor RSE está activo como hebra dentro de una agrupación de hebras RSE.
  • El gestor de depuración (DBGMGR) coordina la actividad del depurador integrado.
  • (z/OS Explorer) El servicio de mandatos TSO (TSO cmd) proporciona una interfaz de tipo por lotes para los mandatos TSO y ISPF.
  • (z/OS Explorer) El Supervisor de trabajos JES (JMON) suministra todos los servicios relacionados con JES.
  • El CARMA (Common Access Repository Manager) proporciona una interfaz para interactuar con SCM (Software Configuration Manager), tales como el CA Endevor.
  • Hay más servicios disponibles, que pueden ser proporcionados por Developer for z Systems o por el software correquisito.
Fin del cambio

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.

Inicio del cambioPara 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 rse.env y en la cantidad de conexiones de cliente reales, el daemon puede iniciar varios espacios de direcciones de agrupaciones de hebras.Fin del cambio

Propietarios de tareas

Figura 2. Propietarios de tareas
Propietarios de tareas

Inicio del cambioLa Figura 2 muestra una visión general básica del propietario de las credenciales de seguridad utilizadas para varias tareas de z/OS Explorer y Developer for z Systems. Fin del cambio

Inicio del cambioLa 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.Fin del cambio

La Figura 2 muestra las tareas iniciadas de z/OS Explorer y Developer for z Systems (DBGMGR, JMON y RSED) y las tareas iniciadas de ejemplo y los servicios del sistema con los que Developer for z Systems se comunica. 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 2 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.

Depurador integrado

 

Figura 3. Depurador integrado
Depurador integrado

 

 

El depurador integrado se utiliza para depurar varias aplicaciones. La imagen 5 muestra una descripción general esquemática que ilustra cómo un cliente Developer for z Systems puede depurar una aplicación.
  1. El cliente se conecta con el host, utilizando el inicio de sesión de host Developer for z Systems habitual.
  2. Como parte del inicio de sesión, un extractor de depuración registrará al usuario con el gestor de depuración, que está activo en la tarea iniciada DBGMGR.
  3. Cuando se inicia una aplicación con un indicador que se debe depurar, Language Environment (LE) invoca la sonda de depuración.
  4. La sonda de depuración se registrará con el gestor de depuración.
  5. Utilizando el extractor de depuración, el gestor de depuración notificará el cliente Developer for z Systems del usuario que recibirá esta sesión de depuración. Si el usuario no está registrado en estos momentos, la sesión de depuración pasa a estado inactivo, a la espera de que el usuario se registre con el gestor de depuración.
  6. El motor de depuración del cliente se pone en contacto con el gestor de depuración, que, a su vez, se encarga de transmitir los datos entre el motor de depuración y la sonda de depuración.

CARMA

Figura 4. Flujo de CARMA
Flujo de 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. La Figura 4 muestra una Visión general esquematizada de cómo un cliente de Developer for z Systems puede acceder a cualquier Software Configuration Manager (SCM) basado en host con soporte.
  1. El cliente tiene un plug-in de Gestor de repositorios de acceso común (CARMA).
  2. El plug-in CARMA se comunica con el miner CARMA, activo como hebra específica de usuario en la agrupación de hebras RSE (RSEDx). Esta comunicación se realiza a través de la conexión RSE existente.
  3. Cuando el cliente solicita acceso a un SCM, el miner CARMA se enlazará a un puerto TCP/IP e iniciará un servidor CARMA específico de usuario con el número de puerto como argumento inicial. El servidor CARMA se conectará a este puerto y utilizará esta vía de acceso para la comunicación con el cliente.Tenga en cuenta que los SCM basados en host espera que los espacios de direcciones de usuario único accedan a sus servicios, lo que requiere que CARMA inicie un servidor de CARMA por usuario. No es posible crear un servidor único que dé soporte a varios usuarios.
  4. El servidor CARMA cargará el Gestor de acceso a repositorios (RAM) que soporta el SCM solicitado.
  5. El RAM se ocupa de los detalles técnicos de interactuar con el SCM específico y presenta una interfaz común al cliente.

Archivos de configuración de CARMA

Developer for z Systems permite utilizar varios métodos para iniciar un servidor CARMA. Cada método tiene ventajas e inconvenientes. Developer for z Systems 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á.

CRASTART

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 z Systems utiliza este entorno para ejecutar el servidor CARMA, CRASERV. Developer for z Systems proporciona varios archivos crastart*.conf, cada uno preconfigurado para un RAM específico.

Sometimiento por lotes

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 las anotaciones 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 z Systems utiliza este entorno para ejecutar el servidor CARMA, CRASERV. Developer for z Systems proporciona varios miembros CRASUB*, cada uno preconfigurado para un RAM específico.

Estructura de directorios de z/OS UNIX

Figura 5. Estructura de directorios de z/OS UNIX
Estructura de directorios de z/OS Unix

La Figura 5 muestra una visión general de los directorios de z/OS UNIX utilizados por Developer for z Systems. La lista siguiente describe cada directorio tocado por Developer for z Systems, cómo se puede cambiar la ubicación y quién mantiene los datos que contiene.

Inicio del cambio
  • /usr/lpp/ibm/rdz/ es la vía de acceso de raíz para el código de producto de Developer for z Systems. La ubicación real se especifica en el archivo de configuración rdz.env (variable RDZ_HOME). SMP/E mantiene los archivos que contienen.
  • Developer for z Systems coloca los archivos en /usr/lpp/ibm/zexpl/bin, el directorio de binarios de z/OS Explorer. La ubicación real se especifica en la configuración de z/OS Explorer. SMP/E mantiene los archivos que contienen.
  • /etc/zexpl/ contiene los archivos de configuración de z/OS Explorer y Developer for z Systems. La ubicación real se especifica en la tarea iniciada RSED (variable CNFG). El programador del sistema mantiene los archivos que contienen.
  • /tmp/ lo utiliza la Pasarela ISPF de legado para almacenar datos temporales. Algunos IVP almacenan aquí su salida. ISPF y los IVP mantienen los archivos que contienen. La ubicación puede personalizarse con la variable TMPDIR en rse.env. También es la ubicación predeterminada para los archivos de vuelco Java™, que pueden personalizarse con la variable _CEE_DUMPTARG de rse.env.
    Nota: /tmp/ requiere la máscara de bit de permiso 777 para permitir a cada cliente crear archivos temporales.
  • La Pasarela ISF y SCLMDT utilizan /var/zexpl/WORKAREA/ para transferir datos entre z/OS UNIX y espacios de direcciones basados en MVS. La ubicación real se especifica en rse.env (variable CGI_ISPWORK). ISPF y SCLMDT mantienen los archivos que contienen.
    Nota: /var/zexpl/WORKAREA/ requiere la máscara de bit de permiso 777 para permitir a cada cliente crear archivos temporales.
    Developer for z Systems graba mensajes de error en los archivos de registro de z/OS Explorer en /var/zexpl/zexpl/logs/$LOGNAME. La ubicación real se especifica en la configuración de z/OS Explorer. Los archivos que contiene los mantiene un administrador de cliente de z/OS Explorer y el código de producto de Developer for z Systems.
  • /var/rdz/sclmdt/CONFIG/ contiene los archivos de configuración SCLMDT generales. La ubicación real se especifica en rdz.env (variable SCLMDT_CONF_HOME). El administrador de SCLM mantiene los archivos que contienen.
  • /var/rdz/sclmdt/CONFIG/PROJECT/ contiene los archivos de configuración de proyectos SCLMDT. La ubicación real se especifica en rdz.env (variable SCLMDT_CONF_HOME). El administrador de SCLM mantiene los archivos que contienen.
  • /var/rdz/sclmdt/CONFIG/script/ contiene los scripts relacionados con SCLMDT que pueden utilizar otros productos. La ubicación actual no se especifica en ningún sitio. El administrador de SCLM mantiene los archivos que contienen.
  • /var/rdz/pushtoclient/ contiene los archivos de configuración del producto del cliente, la información de actualización de cliente y la información de proyectos basados en host que se pasan al cliente tras la conexión al host. La ubicación real se especifica en pushtoclient.properties (variable pushtoclient.folder). Los archivos que contiene los mantiene un administrador de cliente de Developer for z Systems.
  • /var/rdz/pushtoclient/projects/ contiene los archivos de definición de proyectos basados en host. La ubicación real se especifica en el archivo /var/rdz/pushtoclient/keymapping.xml, de cuya creación y mantenimiento se ocupa el administración del cliente Developer for z Systems. El gestor de proyectos o el desarrollador principal mantiene los archivos que contienen.
Fin del cambio

Consideraciones relativas a la seguridad

Inicio del cambioDeveloper for z Systems amplía z/OS Explorer proporcionando funciones adicionales, algunas de las cuales interactúan con otros componentes y productos del sistema, como por ejemplo un SCM (Software Configuration Manager). Se utilizan definiciones de seguridad específicas de Developer for z Systems para proteger las funciones proporcionadas.Fin del cambio

Los mecanismos de seguridad utilizados por los servidores y servicios de Developer for z Systems 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.

Inicio del cambioDeveloper for z Systems se construye encima de IBM Explorer for z/OS. Para obtener información relacionada con z/OS Explorer, consulte el apartado relativo a las consideraciones sobre seguridad en la publicación IBM Explorer for z/OS Host Configuration Reference (SC27-8438).Fin del cambio

En este capítulo se tratan estos temas:

Inicio del cambioFin del cambio

Métodos de autenticación

Inicio del cambio

Autenticación de CARMA

El daemon RSE realiza la autenticación de clientes como parte de la solicitud de conexión del cliente. CARMA se inicia desde una hebra específica del usuario y hereda el entorno de seguridad del usuario, eludiendo la necesidad de autenticación adicional.

Autenticación de SCLM Developer Toolkit

El daemon RSE realiza la autenticación de clientes como parte de la solicitud de conexión del cliente. SCLMDT se inicia desde una hebra específica del usuario y hereda el entorno de seguridad del usuario, eludiendo la necesidad de autenticación adicional.

Fin del cambio

Autenticación del gestor de depuración

Inicio del cambioEl daemon RSE 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.Fin del cambio

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 FEL.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.

Seguridad de conexión

Inicio del cambio

La mayoría de la comunicación entre el host y el cliente de Developer for z Systems va a través de RSE, de tal manera que utiliza la seguridad proporcionada por z/OS Explorer.

Inicio del cambioAlgunos servicios de Developer for z Systems utilizan una vía de acceso externa (cliente-host):
  • El motor del depurador integrado del cliente se conecta con el Gestor de depuración en el host. Los detalles del cifrado se controlan mediante una política AT-TLS (Application Transparent Transport Layer Security).
  • 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.
Fin del cambio
Fin del cambio

Comnicación cifrada con el depurador integrado

Inicio del cambioLa comunicación externa (cliente-host) con el gestor de depuración opcional también puede cifrarse. Para habilitar el cifrado, cree una política AT-TLS (Application Transparent TLS) para el puerto utilizado por el gestor de depuración para comunicaciones externas, 5335 de forma predeterminada. En la Figura 6 se proporciona una política de muestra. Consulte Configurar AT-TLS para obtener más información sobre la configuración de ATS-TLS.
Figura 6. Política AT-TLS para el gestor de depuración
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
}
Fin del cambio
Nota: El método de comunicación que utiliza el motor de depuración en el cliente Developer for z Systems para hablar con el Gestor de depuración en el host está vinculado de forma predeterminada al método de comunicación que utiliza el cliente Developer for z Systems para hablar con el daemon RSE. Esto implica que si el cifrado está habilitado para RSE, se presupone que también está habilitado para el gestor de depuración. Sin embargo, hay escenarios alternativos para otras configuraciones.

Seguridad de depuración

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 z Systems verifica el acceso a los perfiles listados en la Tabla 1 para determinar que permisos de depuración se han concedido.

Tabla 1. Información SAF para funciones de depuración
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
Nota:
  • Developer for z Systems presupone que un usuario no tiene autorización de acceso cuando su software de seguridad indique que no puede determinar si un usuario tiene o no autorización de acceso a un perfil. Un ejemplo sería cuando el perfil no está definido.
  • Las versiones de Developer for z Systems anteriores a la versión 9.1.1 comprobaban los permisos UPDATE en el perfil AQE.AUTHDEBUG.WRITEBUFFER para permitir la depuración de transacciones CICS sólo de lectura. Este perfil ha dejado de utilizarse y se puede eliminar si el sistema host sólo dispone de Developer for z Systems versión 9.1.1 o una superior.
Los siguientes ejemplos de definiciones de seguridad permiten a todos los usuarios del grupo RDZDEBUG depurar aplicaciones sobre el estado del problema:
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
  ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

Seguridad de CICSTS

El depurador integrado opcional puede depurar transacciones CICS. Consulte Depuración de transacción CICS para obtener más detalles.

Seguridad de SCLM

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.

Definiciones de seguridad

Inicio del cambioPersonalice y someta el trabajo de ejemplo FELRACF, que contiene mandatos de ejemplo RACF para crear las definiciones de seguridad básicas para Developer for z Systems. Personalice y someta el trabajo de ejemplo AQERACF, que tiene mandatos de ejemplo RACF para crear definiciones de seguridad para el Depurador integrado.Fin del cambio

Inicio del cambioFELRACF y AQERACF que se encuentran en FEL.#CUST.JCL, a menos que se haya especificado una ubicación distinta al personalizar y someter el trabajo FEL.SFELSAMP(FELSETUP). Para obtener más información, consulte "Configuración de personalización" en la Rational Developer for z SystemsGuía de configuración del hostFin del cambio

Consulte la publicación RACF Command Language Reference (SA22–7687), para obtener más información sobre mandatos RACF.

Requisitos y lista de comprobación

Para completar la configuración de seguridad, el administrador de seguridad necesita conocer los valores enumerados en la Tabla 2. Estos valores se han definido durante los pasos anteriores de la instalación y personalización de Rational Developer for z Systems.
Tabla 2. Variables de configuración de seguridad
Descripción
  • Valor predeterminado
  • Dónde encontrar la respuesta
Valor
Calificador de alto nivel de producto de Developer for z Systems
  • Inicio del cambioFELFin del cambio
  • Instalación de SMP/E
 
Calificador de alto nivel de personalización de Developer for z Systems
  • FEL.#CUST
  • FEL.SFELSAMP(FELSETUP), tal como se describe en "Configuración de personalización" en la Guía de configuración de host de Rational Developer for z Systems.
 
Nombre de tarea iniciada del depurador integrado
  • DBGMGR
  • FEL.#CUST.PROCLIB(DBGMGR), tal como se describe en "Cambios de PROCLIB" en la Guía de configuración de host Rational Developer for z Systems
 
Inicio del cambioLa lista que sigue es una visión general de las acciones necesarias para completar la configuración de seguridad básica de Developer for z Systems. Tal como se describe en las secciones siguientes, se pueden utilizar distintos métodos para cumplir estos requisitos en función del nivel de seguridad necesario. Inicio del cambioFin del cambio Fin del cambio

Activar los valores y las clases de seguridad

Developer for z Systems utiliza diversos mecanismos de seguridad para garantizar un entorno de sistema host seguro y controlado para el cliente. Para ello, deben estar activos varias clases y valores de seguridad, como se muestra en los siguientes mandatos de RACF de muestra:
  • Visualizar valores actuales
    • SETROPTS LIST
  • Activar la clase de recurso para el depurador integrado
    • SETROPTS GENERIC(FACILITY)
    • SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
  • Activar definiciones de tarea iniciada para el depurador integrado
    • SETROPTS GENERIC(STARTED)
    • RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
    • SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
  • Activar el control de programa para el depurador integrado
    • RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
    • SETROPTS WHEN(PROGRAM)
      Nota: No cree el perfil ** si ya tiene un perfil * en la clase PROGRAM. Oscurece y complica la vía de acceso de búsqueda utilizada por el software de seguridad. En este caso, debe fusionar las definiciones * existentes y las definiciones ** nuevas. Utilice el perfil **, tal como se describe en la publicación Security Server RACF Security Administrator's Guide (SA22-7683).
      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.

Definición de un segmento OMVS para usuarios de Developer for z Systems

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 z Systems. 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(#identificador-usuario) HOME(/u/#idusuario) PROGRAM(/bin/sh)
    NOASSIZEMAX)
  • ALTGROUP #nombre-grupo OMVS(GID(#identificador-grupo))

Definir las tareas iniciadas de Developer for z Systems

Inicio del cambioLos siguientes mandatos RACF de ejemplo crean la tarea iniciada DBGMGR, con el ID de usuario protegido (STCDBM) y el grupo STCGROUP asignado al mismo.Fin del cambio

Inicio del cambio
  • ADDGROUP STCGROUP OMVS(AUTOGID)
    DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
  • ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('DEBUG MANAGER')
    OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
    DATA('Rational Developer for z Systems') 
  • RDEFINE STARTED DBGMGR.* DATA('DEBUG MANAGER')
    STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
  • SETROPTS RACLIST(STARTED) REFRESH
Fin del cambio
Nota: Inicio del cambio
  • Asegúrese de que los IDs de usuario de las tareas iniciadas están protegidos especificando la palabra clave NOPASSWORD.
  • La tarea iniciada del Gestor de depuración (DBGMGR) únicamente la utiliza la característica Depurador integrado.
Fin del cambio

Definir el gestor de depuración como servidor z/OS UNIX seguro

Inicio del cambioEl 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. Tenga en cuenta que la utilización de UID(0) para ignorar este requisito no está soportada. Este permiso solo es necesario cuando se utiliza la función de depurador integrado opcional.Fin del cambio

Inicio del cambio
  • RDEFINE FACILITY BPX.SERVER UACC(NONE)
  • PERMIT BPX.SERVER CLASS(FACILITY) ACCESS(UPDATE) ID(STCDBM)
  • SETROPTS RACLIST(FACILITY) REFRESH
Fin del cambio
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).

Definir bibliotecas controladas por programa MVS para el gestor de depuración

Inicio del cambioLos servidores con autorización sobre BPX.SERVER deben ejecutarse en un entorno limpio controlado por programa. Este requisito implica que todos los programas llamados por el gestor de depuración también deben estar controlados por programa. Para las bibliotecas de carga MVS, el control de programa se gestiona mediante el software de seguridad.Fin del cambio

Inicio del cambioEl gestor de depuración utiliza bibliotecas del sistema, tiempo de ejecución de Language Environment y la biblioteca de carga de Developer for z Systems’ (ISP.SISPLOAD).
  • RALTER PROGRAM ** UACC(READ) ADDMEM('SYS1.LINKLIB'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('SYS1.CSSLIB'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('CEE.SCEERUN'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('CEE.SCEERUN2'//NOPADCHK)
  • Inicio del cambioRALTER PROGRAM ** UACC(READ) ADDMEM('FEL.SFELAUTH'//NOPADCHK)Fin del cambio
  • SETROPTS WHEN(PROGRAM) REFRESH
Fin del cambio
Nota: No utilice el perfil ** si ya tiene un perfil * en la clase PROGRAM. El perfil oscurece y complica la vía de acceso de búsqueda utilizada por el software de seguridad. En este caso, debe fusionar las definiciones * existentes y las definiciones ** nuevas. Utilice el perfil **, tal como se describe en la publicación Security Server RACF Security Administrator's Guide (SA22-7683).

Inicio del cambioLas siguientes bibliotecas adicionales prerrequisito deben estar controladas por programa para dar soporte a la utilización de servicios opcionales. La lista no incluye conjuntos de datos específicos de un producto con el que interactúa Developer for z Systems, como IBM Explorer for z/OS.Fin del cambio

Inicio del cambio
  • Biblioteca de tiempo de ejecución REXX alternativa, para SCLM Developer Toolkit
    • REXX.*.SEAGALT
Fin del cambio
Nota: Las bibliotecas diseñadas para colocación en LPA también requieren autorizaciones de control de programa si se accede a ellas por medio de LINKLIST o STEPLIB. Esta publicación documenta la utilización de las siguientes bibliotecas de LPA:Inicio del cambio
  • Biblioteca de tiempo de ejecución REXX, para SCLM Developer Toolkit
    • REXX.*.SEAGLPA
  • Developer for z Systems, para CARMA
    • FEL.SFELLPA
Fin del cambio

Definir el soporte de PassTicket para RSE

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.

Los PassTickets son contraseñas generadas por el sistema con un tiempo de vida aproximado de 10 minutos. Las PassTickets generadas se basan en una clave secreta. Esta clave es un número de 64 bits (16 caracteres hexadecimales). En los mandatos RACF de ejemplo siguientes, sustituya el espacio reservado key16 por una serie hexadecimal de 16 caracteres proporcionada por el usuario cuyos caracteres estén en los rangos 0-9 y A-F.
  • RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16)) 
    APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE') 
    DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  • RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE) 
    DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  • 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 rdz.env 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 z Systems. Las definiciones de clase PTKTDATA deben coincidir con el ID de aplicación real utilizado por RSE.

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 las aplicaciones MVS, incluidos trabajos por lotes de usuarios.
Nota:
  • Si la clase PTKTDATA ya está definida, verifique que lo está como clase genérica antes de crear los perfiles enumerados a continuación. El soporte para los caracteres genéricos de la clase PTKTDATA es nuevo del release 1.7 de z/OS, con la introducción de una interfaz de Java a PassTickets.
  • Sustituya el comodín (*) de la definición IRRPTAUTH.FEKAPPL.* con una máscara de ID de usuario válida para limitar los ID de usuario para los que RSE puede generar un PassTicket.
  • Dependiendo de sus valores RACF, es posible que el usuario que ha definido un perfil aparezca también en la lista de acceso para el perfil en cuestión. Elimine este permiso para los perfiles PTKTDATA.
  • RSE y el supervisor de trabajos JES deben tener el mismo ID de aplicación para que el supervisor de trabajos JES pueda evaluar los PassTickets presentados por RSE. Para el Supervisor de trabajos JES, el ID de aplicación se establece en el archivo de configuración FEJJCNFG con la directiva APPLID.
  • Si el sistema tiene un producto criptográfico instalado y disponible, puede cifrar la clave de la aplicación de inicio de sesión seguro para obtener más protección. Para ello, utilice la palabra clave KEYENCRYPTED, en lugar de KEYMASKED. Para obtener más información, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Atención: La solicitud de conexión del cliente falla si PassTickets no está configurado correctamente.

Definir permiso de acceso de archivos z/OS UNIX para RSE

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.

  • RDEFINE UNIXPRIV SUPERUSER.FILESYS UACC(NONE) DATA('OVERRIDE UNIX FILE ACCESS RESTRICTIONS')
  • RDEFINE UNIXPRIV SUPERUSER.FILESYS.CHOWN UACC(NONE) DATA('OVERRIDE UNIX CHANGE OWNER RESTRICTIONS')
  • PERMIT SUPERUSER.FILESYS CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
  • PERMIT SUPERUSER.FILESYS.CHOWN CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
  • SETROPTS RACLIST(UNIXPRIV) REFRESH

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.

Definir la protección de aplicaciones para el RSE

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 Z SYSTEMS')
  • SETROPTS RACLIST(APPL) REFRESH
Nota:
  • Tal como se describe más detalladamente en Definir el soporte de PassTicket para RSE, RSE soporta el uso de un ID de aplicación distinto de FEKAPPL. La definición de clase APPL debe coincidir con el ID de aplicación real que utiliza RSE.
  • La solicitud de conexión de cliente es satisfactoria si el ID de aplicación no está definido en la clase APPL.
  • La solicitud de conexión del cliente sólo fallará si el ID de aplicación está definido y el usuario no tiene acceso de lectura (READ) al perfil.

Definir archivos controlados por programa z/OS UNIX para el servidor

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).

El servidor RSE utiliza la biblioteca compartida de Java de RACF, (/usr/lib/libIRRRacf*.so).
  • extattr +p /usr/lib/libIRRRacf*.so
Nota:
  • A partir de z/OS 1.9, /usr/lib/libIRRRacf*.so se instala en modalidad controlada por programa durante la instalación de RACF SMP/E.
  • A partir de z/OS 1.10, /usr/lib/libIRRRacf*.so forma parte de SAF, que se proporciona con el producto base z/OS, por lo que también está disponible para los clientes no RACF.
  • La configuración puede ser diferente si utiliza un producto distinto de RACF. Para obtener más información, consulte la documentación de su producto de seguridad.
  • La instalación SMP/E de Developer for z Systems establece el bit de control de programa para los programas internos de RSE.
  • Utilice el mandato ls -Eog z/OS UNIX para visualizar el estado actual del bit de control de programa. El archivo está controlado por programa si la letra p se visualiza en la segunda serie.
    $ 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                                 

Definir la seguridad de mandatos JES

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 Guía de configuración de host Rational Developer for z Systems.

Los mandatos RACF de ejemplo siguientes proporcionan a los usuarios de Developer for z Systems acceso condicional a un conjunto limitado de mandatos JES, que son Retener, Liberar, Cancelar y Depurar. Los usuarios sólo tienen permiso de ejecución si emiten los mandatos a través del Supervisor de trabajos JES. Sustituya el espacio reservado #consola con el nombre de la consola.
  • RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ) 
    DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  • RDEFINE OPERCMDS JES%.** UACC(NONE)
  • PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
  • SETROPTS RACLIST(OPERCMDS) REFRESH
Nota:
  • El uso de la consola está permitido si no está definido el perfil MVS.MCSOPER.#console.
  • La clase CONSOLE debe estar activa para que WHEN(CONSOLE(JMON)) funcione, pero no hay ninguna comprobación real de perfiles en la consola CONSOLE para las consolas de EMCS.
  • No sustituya JMON con el nombre real de la consola en la cláusula WHEN(CONSOLE(JMON)). La palabra clave JMON representa la aplicación de punto de entrada, no el nombre de la consola.
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 3 y la Tabla 4 muestran los mandatos de operador emitidos para JES2 y JES3 y los perfiles de seguridad específicos que pueden utilizarse para protegerlos.

Tabla 3. Mandatos de operador del Supervisor de trabajos JES2
Acción Mandato Perfil OPERCMDS Acceso necesario
Retener $Hx(idtrabajo)

con x = {J, S o T}

jesname.MODIFYHOLD.BAT
jesname.MODIFYHOLD.STC
jesname.MODIFYHOLD.TSU
UPDATE
Liberar $Ax(idtrabajo)

con x = {J, S o T}

jesname.MODIFYRELEASE.BAT
jesname.MODIFYRELEASE.STC
jesname.MODIFYRELEASE.TSU
UPDATE
Cancelar $Cx(idtrabajo)

con x = {J, S o T}

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU
UPDATE
Purgar $Cx(jobid),P

con x = {J, S o T}

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU
UPDATE
Tabla 4. Mandatos de operador del Supervisor de trabajos JES3
Acción Mandato Perfil OPERCMDS Acceso necesario
Retener *F,J=idtrabajo,H
jesname.MODIFY.JOB
UPDATE
Liberar *F,J=idtrabajo,R
jesname.MODIFY.JOB
UPDATE
Cancelar *F,J=idtrabajo,C
jesname.MODIFY.JOB
UPDATE
Purgar *F,J=idtrabajo,C
jesname.MODIFY.JOB
UPDATE
Nota:
  • Los mandatos del operador JES Retener, Liberar, Cancelar y Depurar, y el mandato Mostrar JCL sólo pueden ejecutarse en los archivos de spool propiedad del ID de usuario cliente, a menos que se especifique LIMIT_COMMANDS= con el valor LIMITED, o se especifique NOLIMIT en el archivo de configuración del Supervisor de trabajos JES. Para obtener más información, consulte la sección "Acciones en trabajos - limitaciones de destino" de la publicación Guía de referencia de configuración de host (SC11-7903).
  • Los usuarios pueden examinar cualquier archivos de spool, a menos que se haya definido LIMIT_VIEW=USERID en el archivo de configuración del Supervisor de trabajos JES. Para obtener más información, consulte la sección "Acceso a los archivos de spool" de la publicación Guía de referencia de configuración de host (SC11-7903).
  • Incluso aunque no posean autorización sobre estos mandatos de operador, los usuarios todavía pueden someter trabajos y leer la salida de los trabajos por medio del Supervisor de trabajos JES, en caso de que dispongan de la autorización suficiente sobre los perfiles posibles que protegen estos recursos, como los de las clases JESINPUT, JESJOBS y JESSPOOL.

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.

Definir acceso al depurador integrado

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 por 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                       
Nota: Las versiones de IBM Rational Developer for System z anteriores a la versión 9.1.1 han utilizado otro perfil de clase FACILITY, AQE.AUTHDEBUG.WRITEBUFFER, que ya no se utiliza. Puede eliminarse si el sistema host sólo tiene IBM Rational Developer for System z versión 9.1.1 o posterior.

Definir los perfiles de conjunto de datos

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 z Systems. 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 FEL.#CUST es el calificador de alto nivel predeterminado para los conjuntos de datos creados durante el proceso de personalización.

  • Inicio del cambio
    ADDGROUP (FEL) OWNER(IBMUSER) SUPGROUP(SYS1) 
    DATA('IBM Rational Developer for z Systems - HLQ STUB')
                           
    Fin del cambio
  • Inicio del cambio
    ADDSD  'FEL.*.**' UACC(READ) 
    DATA('IBM Rational Developer for z Systems')
    Fin del cambio
  • Inicio del cambio
    PERMIT 'FEL.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    Fin del cambio
  • SETROPTS GENERIC(DATASET) REFRESH
Nota:
  • Inicio del cambioProteja FEL.SFELAUTH contra actualizaciones porque este conjunto de datos está autorizado por APF.Fin del cambio
  • En los mandatos de ejemplo se esta publicación y en el trabajo FELRACF se presupone que EGN (Denominación genérica mejorada) está activa. Cuando EGN está activa, se puede utilizar el calificador ** para representar cualquier número de calificadores en la clase DATASET. Sustituya ** por * si EGN no está activa en el sistema. Para obtener más información sobre EGN, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Inicio del cambioAlgunos de los componentes de Developer for z Systems requieren perfiles de conjunto de datos de seguridad adicionales. Sustituya los espacios reservados #sysprog y #ram-developer con ID de usuario o nombres de grupos de RACF válidos.
  • Si se utiliza la conversión de nombres largos/abreviados de SCLM Developer Toolkit, los usuarios necesitarán acceso de actualización (UPDATE) al VSAM de correlación, FEL.#CUST.LSTRANS.FILE.
    • Inicio del cambio
      ADDSD  'FEL.#CUST.LSTRANS.*.**' UACC(UPDATE)
       DATA('IBM Rational Developer for z Systems - SCLMDT')
                   
      Fin del cambio
    • PERMIT 'FEL.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    • SETROPTS GENERIC(DATASET) REFRESH
  • Los desarrolladores de RAM (Repository Access Manager) de CARMA requieren acceso de actualización (UPDATE) a los VSAM de CARMA, FEL.#CUST.CRA*.
    • ADDSD  'FEL.#CUST.CRA*.**' UACC(READ) 
      DATA('IBM Rational Developer for z Systems - CARMA')
                              
    • PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    • PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
    • SETROPTS GENERIC(DATASET) REFRESH
Fin del cambio

Verificar los valores de seguridad

Utilice los siguientes mandatos de ejemplo para visualizar los resultados de las personalizaciones relacionadas con la seguridad.

Inicio del cambio
  • Valores y clases de seguridad
    • SETROPTS LIST
  • Tareas iniciadas
    • LISTGRP STCGROUP OMVS
    • LISTUSER STCDBM OMVS
    • RLIST STARTED DBGMGR.* ALL STDATA
  • Gestor de depuración como un servidor z/OS UNIX seguro
    • RLIST FACILITY BPX.SERVER ALL
  • Bibliotecas controladas por programa MVS para el gestor de depuración
    • RLIST PROGRAM ** ALL
  • Acceso al depurador integrado
    • RLIST FACILITY AQE.** ALL
  • Perfiles de conjunto de datos
    • LISTGRP FEL
    • LISTDSD PREFIX(FEL) ALL
Fin del cambio

Consideraciones sobre TCP/IP

Developer for z Systems 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.

En este capítulo se tratan estos temas: Inicio del cambioFin del cambio

Inicio del cambioDeveloper for z Systems se construye encima de IBM Explorer for z/OS. Para obtener información relacionada con z/OS Explorer, consulte el apartado relativo a las consideraciones sobre TCP/IP en la publicación IBM Explorer for z/OS Host Configuration Reference (SC27-8438).Fin del cambio

Puertos TCP/IP

Figura 7. Puertos TCP/IP
Puertos TCP/IP

Inicio del cambioLa Figura 7 muestra los puertos TCP/IP que pueden utilizar z/OS Explorer y Developer for z Systems. Las flechas muestran qué parte realiza el enlace (parte de la punta de la flecha) y que parte realiza la conexión.Fin del cambio

Comunicación externa

Defina los puertos siguientes para el cortafuegos que protege el host z/OS, ya que se utilizan para la comunicación cliente-host (utilizar el protocolo tcp):Inicio del cambio
  • Inicio del cambio(z/OS Explorer) Daemon RSE para la configuración de la comunicación cliente-host, puerto predeterminado 4035. El puerto puede establecerse en el archivo de configuración rse.env. La comunicación en este puerto se puede cifrar.Fin del cambio
  • Inicio del cambio(z/OS Explorer) Servidor RSE para la comunicación cliente-host. Por omisión, se utiliza cualquier puerto disponible, pero puede limitarse a un rango especificado con la definición de _RSE_PORTRANGE de rse.env. El rango de puertos predeterminado para _RSE_PORTRANGE es 8108-8118 (11 puertos). La comunicación en este puerto se puede cifrar.Fin del cambio
  • Inicio del cambioGestor de depuración para servicios de depurador integrado, puerto predeterminado 5335. El puerto se puede establecer en el JCL de la tarea iniciada DBGMGR. La comunicación en este puerto se puede cifrar.Fin del cambio
  • Servicio INETD para acciones remotas (basadas en host) en subproyectos z/OS UNIX:
    • REXEC (versión z/OS UNIX), puerto predeterminado 512.
    • Inicio del cambioSSH (versión z/OS UNIX), puerto predeterminado 22. La comunicación en este puerto está cifrada. Fin del cambio
  • Inicio del cambio(z/OS Explorer) Servicio Telnet TN3270 para el Emulador de conexión de host, puerto predeterminado 23. La comunicación puede estar cifrada (puerto predeterminado 992). El puerto predeterminado que se asigna al servicio Telnet TN3270 depende de si el usuario elige el uso del cifrado.Fin del cambio
  • Inicio del cambioPueden darse instrucciones a la cobertura de código basada en host para que se conecte con el motor del depurador integrado de un cliente de Developer for z Systems. La comunicación en este puerto se puede cifrar. Tenga en cuenta que, en este escenario, el recopilador de cobertura de código basada en z/OS es un cliente para TCP/IP y el motor del depurador integrado del sistema personal del usuario es un servidor para TCP/IP. El valor predeterminado es trabajar con IBM Debug Tool localmente en el mismo host. Fin del cambio
Fin del cambio
Nota: En general, el cliente especifica qué dirección TCP/IP se debe utilizar para establecer conexión con el host. Sin embargo, 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.

Comunicación interna

Varios servicios de host de Developer for z Systems se ejecutan en hebras o espacios de direcciones separados y utilizando sockets TCP/IP como mecanismo de comunicación , mediante la dirección de bucle de retorno del sistema. Todos estos servicios utilizan RSE para comunicarse con el cliente, confinando con ello su corriente de datos solamente al host. Para algunos servicios se utilizará cualquier puerto disponible, mientras que para otros el programador del sistema puede elegir el puerto o rango de puertos que se utilizará:
  • Supervisor de trabajos JES para servicios relacionados con JES, puerto predeterminado 6715. El puerto se puede establecer en el miembro de configuración de FEJJCNFG y se repite en el archivo de configuración de rse.env.
  • (opcional) La comunicación de CARMA utiliza de forma predeterminada un puerto efímero pero se puede establecer un rango de puertos en el archivo de configuración de CRASRV.properties.
  • (opcional) Gestor de depuración para servicios relacionados con la depuración, puerto predeterminado 5336. El puerto se puede establecer en el JCL de la tarea iniciada DBGMGR.
  • La cobertura de código basada en host, que es un trabajo por lotes, asigna un puerto efímero para permitir que IBM Debug Tool for z/OS establezca comunicación y proporcione los datos necesarios para el informe de cobertura de código.

Reserva de puerto TCP/IP

Inicio del cambioSi utiliza la sentencia PORT o PORTRANGE en PROFILE.TCPIP para reservar los puertos utilizados por z/OS Explorer y Developer for z Systems, 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 por RSE, y x, un número aleatorio de un dígito, por lo que es necesario utilizar comodines en la definición.Fin del cambio

Inicio del cambio
PORT      4035     TCP RSED   ; z/OS Explorer  – Daemon RSE
PORT      6715     TCP JMON   ; z/OS Explorer  – Supervisor de trabajos JES
PORT      5335     TCP DBGMGR ;  Developer for z Systems  – Depurador integrado
PORT      5336     TCP DBGMGR ;  Developer for x Systems  – Depurador integrado
PORTRange 8108 11  TCP RSED*  ;  z/OS Explorer  – RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ;  Developer for z Systems  - CARMA
Fin del cambio

CARMA y TCP/IP

Puertos CARMA y TCP/IP

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 miner 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 miner 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 miner 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 miner 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 por 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 Z SYSTEMS - CARMA
Nota: El IVP de CARMA, fekfivpc, fallará si reserva los puertos de CARMA para el uso de espacios de direcciones de RSE. Esto es de prever porque el IVP se ejecuta en el espacio de direcciones de la persona que ejecuta el IVP, no en el espacio de direcciones de RSE y TCP/IP no ejecutará correctamente la solicitud de enlace.

CARMA y afinidad de pila

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.

Inicio del cambioDe forma parecida a las tareas iniciadas de z/OS Explorer y Developer for z Systems started, 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. Fin del cambio

Nota:
  • El nombre exacto del archivo de configuración que contiene el mandato de arranque depende de distintas opciones seleccionadas por el programador de sistemas que ha configurado CARMA. Para obtener más información sobre este asunto, consulte el "Capítulo 3. (Opcional) Common Access Repository Manager (CARMA)" de la publicación Guía de configuración de host SC43-2926 (SC27-8577).
  • _BPXK_SETIBMOPT_TRANSPORT especifica el nombre de la pila TCP/IP que debe utilizarse, como se define en la sentencia TCPIPJOBNAME de la sentencia TCPIP.DATA relacionada.
  • El hecho de codificar una sentencia SYSTCPD DD no establece la afinidad de pila solicitada.
  • De forma predeterminada, CARMA no utiliza las pilas TCP/IP normales. CARMA utiliza la dirección de bucle de retorno para la comunicación entre el minero CARMA y el servidor CARMA. Esto mejora la seguridad (solo los procesos locales tienen acceso a la dirección de bucle de retorno) y es probable que evite tener que añadir afinidad de pila a la comunicación con CARMA.

crastart*.conf

Sustituya la siguiente parte:
... PARM(&CRAPRM1. &CRAPRM2.)
por esta (donde TCPIP representa la pila TCP/IP deseada):
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
Nota: CRASTART no da soporte a continuaciones de línea, pero no existe ningún límite en cuanto a la longitud de línea aceptada.

CRASUB*

Sustituya la siguiente parte:
... PARM(&PORT &TIMEOUT)
por esta (donde TCPIP representa la pila TCP/IP deseada):
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
Nota: el sometimiento de trabajo limita la longitud de línea a 80 caracteres. Puede dividir una línea más larga en un espacio en blanco ( ) y utilizar un signo más (+) al final de la primera línea para concatenar las dos líneas.

Consideraciones sobre WLM

Al contrario que las aplicaciones z/OS tradicionales, Rational Developer for z Systems no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for z Systems 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 z Systems, algunos de estos servicios están activos en diferentes espacios de direcciones, lo que resulta en diferentes clasificaciones WLM.

En este capítulo se tratan estos temas:

Inicio del cambioDeveloper for z Systems se construye encima de IBM Explorer for z/OS. Para obtener información relacionada con z/OS Explorer, consulte el apartado relativo a las consideraciones sobre WLM en la publicación IBM Explorer for z/OS Host Configuration Reference (SC27-8438).Fin del cambio

Clasificación de carga de trabajo

Figura 8. Clasificación de WLM
Clasificación de WLM

Inicio del cambioLa Figura 8 muestra una visión general básica de los subsistemas a través de los cuales se presentan las cargas de trabajo de z/OS Explorer y Developer for z Systems a WLM.Fin del cambio

Inicio del cambioEl daemon RSE (RSED), el Gestor de depuración (DBGMGR) y el Supervisor de trabajos JES (JMON) son tareas iniciadas por z/OS Explorer y Developer for z Systems (o trabajos por lotes de larga ejecución), cada uno con su espacio de direcciones individual.Fin del cambio

Inicio del cambioEl 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.Fin del cambio

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 z Systems, 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 8 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.

Inicio del cambioOtros servicios han creado más espacios de direcciones que Developer for z Systems utiliza, como por ejemplo z/OS UNIX REXEC (construcción USS).Fin del cambio

Reglas de clasificación

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 5 enumera los tipos de subsistema que pueden recibir cargas de trabajo de Developer for z Systems.

Tabla 5. Subsistemas de punto de entrada de WLM
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.
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 6 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.

Tabla 6. Calificadores de trabajo de WLM
    ASCH JES OMVS STC
AI Información de contabilidad x x x x
LU Nombre de LU (*)        
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    
SPM Parámetro de subsistema       x
PX Nombre de Sysplex 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
UI ID de usuario (*) x x x x
Nota: Para los calificadores marcados con (*), puede especificar grupos de clasificación añadiendo una G a la abreviación de tipo. Por ejemplo, un grupo de nombres de transacción sería TNG.

Establecimiento de objetivos

Tal como se explica en Clasificación de carga de trabajo, Developer for z Systems 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 z Systems 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.

Nota:
  • La información de objetivo de esta sección se mantiene deliberadamente a un nivel descriptivo porque los objetivos de rendimiento reales son muy específicos del sitio.
  • Para ayudarle a comprender el impacto de una tarea específica en el sistema, se utilizan términos como utilización de recursos mínima, moderada y sustancial. Todos ellos son relativos a la utilización de recursos total de Developer for z Systems, no de todo el sistema.

La Tabla 7 enumera los espacios de direcciones utilizados por z/OS Explorer y Developer for z Systems. z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.

Inicio del cambio
Tabla 7. Cargas de trabajo WLM
Descripción Nombre de tarea Carga de trabajo
Gestor de depuración DBGMGR STC
Supervisor de trabajos JES (z/OS Explorer) JMON STC
Daemon RSE (z/OS Explorer) RSED STC
Agrupación de hebras RSE (z/OS Explorer) RSEDx OMVS
Inicio del cambio(ISPF) Pasarela ISPF interactiva (Servicio de mandatos TSO)Fin del cambio Inicio del cambio<IDusuario>Fin del cambio Inicio del cambioJESFin del cambio
Inicio del cambio(ISPF) Pasarela ISPF de legado (Servicio de mandatos TSO y SCLMDT)Fin del cambio <IDusuario>x OMVS
Servicio de mandatos TSO (APPC) (z/OS Explorer) 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
Fin del cambio

Consideraciones para la selección de objetivos

Las consideraciones de WLM generales siguientes le pueden ayudar a definir adecuadamente las definiciones de objetivos correctas para Developer for z Systems:
  • Debe basar los objetivos en lo que se puede conseguir realmente, no en lo que desea que ocurra. Si establece los objetivos más arriba de lo necesario, WLM mueve recursos de trabajos menos importantes a trabajos más importantes que realmente no necesitan los recursos.
  • Limite la cantidad de trabajo asignada a las clases de servicio SYSTEM y SYSSTC, porque estas clases tienen una prioridad de despacho más alta que cualquier clase gestionada por WLM. Utilice estas clases para el trabajo que tenga más importancia pero que utilice menos CPU.
  • El trabajo que queda entre las reglas de clasificación termina en la clase SYSOTHER, que tiene un objetivo discrecional. Un objetivo discrecional indica a WLM que haga lo mejor que pueda cuando el sistema tenga recursos de sobra.
Cuándo utilizar los objetivos de tiempo de respuesta:
  • Debe haber una cadencia de llegada de tareas constante (al menos 10 tareas en 20 minutos) para que WLM gestione adecuadamente un objetivo de tiempo de respuesta.
  • Utilice los objetivos de tiempo de respuesta sólo para cargas de trabajo bien controladas porque una sola transacción larga tiene un impacto grande en el tiempo de respuesta promedio y puede hacer que WLM reaccione de manera exagerada.
Cuándo utilizar métodos de velocidad:
  • Normalmente no puede conseguir un método de velocidad mayor del 90% por varias razones. Por ejemplo, todos los espacios de direcciones SYSTEM y SYSSTC tienen una prioridad de despacho mayor que cualquier objetivo de tipo de velocidad.
  • WLM utiliza un número mínimo de ejemplos (utilizar y retardar) sobre los que basar sus decisiones de objetivo de velocidad. Así, cuanto menos trabajo se esté ejecutando en una clase de servicio, más se tardará en recoger el número necesario de ejemplos y en ajustar la política de despacho.
  • Vuelva a evaluar los métodos de velocidad cuando cambie el hardware. Además, pasar a menos y más rápidos procesadores necesita cambios en los objetivos de velocidad.

STC

Inicio del cambioTodas las tareas iniciadas de Developer for z Systems dan servicio a solicitudes de cliente en tiempo real.Fin del cambio

Inicio del cambio
Tabla 8. Cargas de trabajo WLM - STC
Descripción Nombre de tarea Carga de trabajo
Gestor de depuración DBGMGR STC
Fin del cambio
Inicio del cambio
  • Gestor de depuración

    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.

Fin del cambio

OMVS

Inicio del cambioTodas las cargas de trabajo utilizan el ID de usuario de cliente como base para el nombre de espacio de direcciones. (z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.)Fin del cambio

Inicio del cambioLas cargas de trabajo 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.Fin del cambio

Tabla 9. Cargas de trabajo WLM - OMVS
Descripción Nombre de tarea Carga de trabajo
Inicio del cambioPasarela ISPF de legado (Servicio de mandatos TSO y SCLMDT)Fin del cambio <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
Inicio del cambio
  • Inicio del cambioPasarela ISPF de legado

    Inicio del cambioLa pasarela de ISPF de legado es un servicio ISPF invocado por Developer for z Systems para ejecutar mandatos TSO e ISPF no interactivos. Esto incluye mandatos explícitos emitidos por el cliente así como mandatos implícitos emitidos por el componente SCLMDT de Developer for z Systems. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.Fin del cambio

    Fin del cambio
  • CARMA

    CARMA es un servidor Developer for z Systems opcional utilizado para interactuar con Gestores de configuraciones de software (SCM), como por ejemplo CA Endevor® SCM. Developer for z Systems 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.

  • Construcción de z/OS UNIX

    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.

  • Shell de z/OS UNIX

    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.

Fin del cambio

JES

Los procesos por lotes gestionados por JES los utiliza Developer for z Systems 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 z Systems también podría iniciar un servidor CARMA por lotes y comunicarse con el mediante TCP/IP.

Inicio del cambio
Tabla 10. Cargas de trabajo WLM - JES
Descripción Nombre de tarea Carga de trabajo
CARMA (por lotes) CRA<puerto> JES
Construcción de MVS (trabajo por lotes) * JES
Fin del cambio
Inicio del cambio
  • CARMA

    CARMA es un servidor de Developer for z Systems que se utiliza para interactuar con SCM (Software Configuration Manager), tales como CA Endevor® SCM. Developer for z Systems 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.

  • Construcción de MVS
    Cuando un cliente inicia una construcción para un proyecto MVS, Developer for z Systems iniciará un trabajo por lotes 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. En función de sus circunstancias locales, puede ser aconsejable seguir diferentes estrategias de objetivo de rendimiento moderado.
    • Debe especificar un objetivo de varios periodos con un periodo de tiempo de respuesta percentil y un periodo de velocidad final. En este casos, sus desarrolladores deben utilizar principalmente el mismo procedimiento de construcción y archivos de entrada de tamaños parecidos para crear trabajos con tiempos de respuesta uniformes. Debe haber también una cadencia de llegada de trabajos constante (al menos 10 trabajos en 20 minutos) para que WLM gestione adecuadamente un objetivo de tiempo de respuesta.
    • Un objetivo de velocidad se ajusta mejor a los trabajos por lotes porque este objetivo puede manejar tiempos de ejecución y cadencias de llegada muy variables.
Fin del cambio

Consideraciones sobre Enviar a cliente

Enviar a cliente o el control de clientes basado en host, tiene soporte para la gestión central de lo siguiente:
  • Archivos de configuración del cliente
  • Versión del producto del cliente
  • Definiciones de proyecto
En este capítulo se tratan estos temas:Inicio del cambioFin del cambio

Inicio del cambioDeveloper for z Systems se construye encima de IBM Explorer for z/OS. Para obtener información relacionada con z/OS Explorer, consulte el apartado relativo a las consideraciones sobre Envío a cliente en la publicación IBM Explorer for z/OS Host Configuration Reference (SC27-8438).Fin del cambio

Introducción

Inicio del cambioLos clientes de Developer for z Systems 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. Fin del cambio

Inicio del cambioEl 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. Fin del cambio

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.

Un gestor de proyecto de desarrollo define un proyecto y le asigna desarrolladores individuales.

Para obtener detalles sobre cómo el gestor del proyecto de desarrollo pueden realizar las tareas que tienen asignadas, consulte Developer for z Systems IBM Knowledge Center

Cuando habilite el soporte de control de versión o configuración para varios grupos de desarrolladores, hay un equipo adicional implicado en la gestión del Envío a cliente. El equipo que será depende de la opción elegida para identificar los grupos a los que pertenece un desarrollador:
  • Un administrador de LDAP mantiene definiciones de grupo que colocan a cada desarrollador en uno o más grupos de LDAP de FEL.PTC.*, o bien en ninguno.
  • Un administrador de seguridad mantiene listas de acceso a perfiles de seguridad FEL.PTC.*. Un desarrollador puede estar autorizado para ninguno, uno o más perfiles. desarrollador.

Proyectos basados en host

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.

Para configurar proyectos basados en host, el gestor de proyectos o desarrollador encargado necesita definir los tipos de archivos de configuración siguientes. Todos los archivos son archivos XML codificados en UTF-8.
  • Los archivos de instancia de proyecto son específicos para un único ID de usuario, y hacen referencia a archivos de definición de proyectos reutilizables. Cada usuario que trabaja con proyectos basados en host necesita un subdirectorio, /var/zexpl/pushtoclient/projects/<IDusuario>/, que contiene un archivo de instancia de proyecto (*.hbpin) para cada proyecto a descargar.
  • Los archivos de definición de proyectos definen la estructura y contenido del proyecto, y pueden ser reutilizados por varios usuarios. Los archivos de definición de proyectos (*.hbppd) muestran una lista de los subproyectos que se encuentran en el proyecto y están ubicados en el directorio de la definición del proyecto raíz o uno de sus subdirectorios.
  • Los archivos de definición de subproyecto definen la estructura y contenidos del subproyecto y pueden ser reutilizados por varios usuarios. Los archivos de definición de subproyecto (*.hbpsd) definen el conjunto de recursos necesarios para construir un único módulo de carga y se encuentran en el directorio de definición de proyecto raíz o en uno de sus subdirectorios.
  • Los archivos de propiedades de subproyecto son archivos de propiedades con soporte para sustitución de variable y que varios subproyectos pueden reutilizar. Los archivos de propiedades de subproyecto (*.hbppr) tienen soporte para la sustitución de variable, para permitir la compartición de los archivos de propiedades entre varios usuarios, y se encuentran en el directorio de definición de proyecto raíz o en uno de sus subdirectorios.

Inicio del cambioLos proyectos basados en host también se pueden elegir para participar en la configuración de grupo múltiple. 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/.Fin del cambio

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.

Consideraciones de CICSTS

Inicio del cambioEste capítulo agrupa las referencias a los componentes de Developer for z Systems puede pueden funcionar dentro de regiones CICSTS. Fin del cambio

Inicio del cambio

Soporte de idiomas bidireccionales

Inicio del cambio

Para obtener más información sobre el soporte para idioma bidireccional, consulte la sección Soporte de idiomas bidireccionales CICS" en el capítulo "Otras tareas de personalización" de la Guía de configuración de host de Rational Developer for z Systems SC43-2926 (SC27-8577).

Fin del cambio
Fin del cambio
Inicio del cambio

Mensajes IRZ de diagnóstico para Enterprise Service Tools

Inicio del cambio

Para obtener más información sobre los mensajes IRZ de diagnóstico para Enterprise Service Tools, consulte la sección "Mensajes IRZ de diagnóstico para Enterprise Service Tools" en el capítulo "Otras tareas de personalización" de la Guía de configuración de host de Rational Developer for z Systems SC43-2926 (SC27-8577).

Fin del cambio
Fin del cambio

Depuración de transacción CICS

Inicio del cambioPara obtener más información sobre la depuración de transacciones CICS, consulte la sección "Actualizaciones CICS del depurador integrado" en el capítulo "(Opcional) Depurador integrado" de la Guía de configuración de host de IBM Rational Developer for z Systems, SC11-3660-05 (SC23-7658).Fin del cambio

Configurar AT-TLS

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 Developer for z Systems 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 z Systems.

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.

La información en esta sección muestra cómo se configura el agente de política del protocolo TCP/IP que gestiona el protocolo AT-TLS y definir una política para utilizar con el depurador integrado de Developer for z Systems en un sistema z/OS 1.13 con soporte para TLS v1.2.
  1. Configurar syslogd
  2. Configuración AT-TLS en PROFILE.TCPIP
  3. Tarea iniciada del agente de política
  4. Configuración del agente de política
  5. Política AT-TLS
  6. Actualizaciones de seguridad de AT-TLS
  7. Activación de la política AT-TLS
A lo largo de esta sección se utiliza un convenio de denominación uniforme:
  • Puerto de gestor de depuración para comunicación externa: 5335
  • ID de usuario del gestor de depuración: stcdbm
  • ID de usuario del agente de política: pagent
  • Certificado: dbgmgr
  • Almacenamiento de certificados y claves: dbgmgr.racf

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.

Configurar syslogd

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.

Las siguientes actualizaciones del archivo de configuración de muestra se pueden utilizar para configurar e iniciar syslogd, con un simple mecanismo de gestión de archivos de registro (borre los registros existentes cuando se inicie z/OS UNIX y cree otros nuevos con el inicio de syslogd).
  • /etc/services
    syslog          514/udp
  • /etc/syslog.conf
    # /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
  • /etc/rc
    # 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

Configuración AT-TLS en PROFILE.TCPIP

El soporte AT-TLS se activa mediante el parámetro TTLS en la sentencia TCPCONFIG del conjunto de datos PROFILE.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 sentencia AUTOSTART de PROFILE.TCPIP es un buen lugar para activar el inicio de este servidor.

Estos requisitos tienen como resultado cambios en PROFILE.TCPIP, que suele denominarse TCPIP.TCPPARMS(TCPPROF).
TCPCONFIG TTLS         ; Required for AT-TLS
AUTOLOG
  PAGENT               ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG

Tarea iniciada del agente de política

Como mencionamos antes, AT-TLS se gestiona mediante el agente de política, que puede iniciarse como una tarea iniciada. Utilice el siguiente JCL para crear SYS1.PROCLIB(PAGENT), utilizando el archivo de configuración predeterminado y la ubicación de registro recomendada (SYSLOGD). Más adelante se tratan las definiciones necesarias para su software de seguridad.
//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=*
//*

Configuración del agente de política

El agente de política impone las políticas relacionadas con TCP/IP creadas por el administrador TCP/IP. Gestiona políticas para AT-TLS, denominadas TTLS, pero también para otros servicios como IPSec. El agente de política utiliza un archivo de configuración para saber qué políticas hay que imponer y dónde se encuentran. El archivo de configuración predeterminado es /etc/pagent.conf, pero puede especificarse una ubicación diferente en la tarea iniciada JCL del agente de política.
#
# 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.

Política AT-TLS

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.

Inicio del cambioEste ejemplo muestra un política de dos reglas bastante simple que inhabilita SSL v3 y habilita el soporte de TLS v1, TLS v1.1 y TLS v1.2 para las vías de acceso de comunicación soportadas por el gestor de depuración, Probe-Client y el depurador integrado de Developer for z Systems. 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.
##
## 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
Inicio del cambio# TLSV1.2 Activado
# TLSv1 & TLSv1.1 están activados de forma predeterminada
  SSLV3 Desactivado        # inhabilitar SSLv3Fin del cambio }
}
##-----------------------------
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
Inicio del cambio# TLSV1.2 Activado
# TLSv1 & TLSv1.1 están activados de forma predeterminadaFin del cambio
 }
}
##-----------------------------
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
}
Fin del cambio

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.

Dado que la comunicación cifrada requiere 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. SSLv3.0 se inhabilita explícitamente debido a las vulnerabilidades conocidas de este protocolo.

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 z Systems 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 z Systems. 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.

Consideraciones TLS v1.2

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.

Al aplicar los dos siguientes APAR, se añade el soporte TLS v1.2 a z/OS 1.13:
  • Sistema SSL APAR OA39422
  • Servidor de comunicaciones (AT-TLS) APAR PM62905
z/OS 1.13 System SSL, que utiliza AT-TLS para implementar una comunicación TLS encriptada, requiere parámetros adicionales para el soporte TLS v1.2. Estos parámetros se suministran mediante la política AT-TLS utilizando un archivo con variables de entorno de System SSL, /etc/pagent.ttls.TLS1.2zOS1.13.env.
#
# 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

Actualizaciones de seguridad de AT-TLS

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.

Como ya se ha mencionado en Tarea iniciada del agente de política, utilice una tarea iniciada para ejecutar el agente de política. Para esto hace falta un ID de usuario de tarea iniciada y un perfil en la clase STARTED.
#  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
Defina un perfil llamado MVS.SERVMGR.PAGENT en la clase OPERCMDS y conceda al ID de usuario PAGENT acceso de CONTROL al mismo. El perfil restringe quién puede iniciar el agente de política. Si el perfil no se ha definido y se impide acceder a él mediante un perfil genérico, PAGENT no podrá iniciar el agente de política, que impedirá la inicialización de la pila TCP/IP.
 #  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 
Tal y como se menciona en Configuración AT-TLS en PROFILE.TCPIP, el agente de política se inicia una vez inicializado TCP/IP. Esto significa que hay una ventana (pequeña) en la que las aplicaciones pueden utilizar la pila TCP/IP sin que se imponga la política TTLS. Defina el perfil EZB.INITSTACK.** en la clase SERVAUTH para impedir el acceso a la pila durante esta ventana de tiempo, excepto para las aplicaciones con acceso de lectura al perfil. Tiene que permitir un conjunto limitado de aplicaciones administrativas para el perfil para garantizar la inicialización completa de la pila, tal y como se explica en “TCP/IP stack initialization access control" Communications Server IP Configuration Guide (SC31-8775).
Nota: Inicio del cambioEl Agente de política envía el mensaje EZD1586I cuando todas las políticas están activas. Fin del cambio
#  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
(Opcional) El mandato de z/OS UNIX pasearch muestra definiciones de política activas. Defina el perfil EZB.PAGENT.** en la clase SERVAUTH para restringir el acceso al mandato pasearch.
#  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
Inicio del cambioTal y como se menciona en Política AT-TLS, el gestor de depuración necesita un certificado para que AT-TLS pueda configurar una comunicación cifrada en nombre del gestor de depuración. Estos mandatos de ejemplo crean un certificado nuevo denominado dbgmgr, que se almacena en un conjunto de claves RACF llamado dbgmgr.racf. Tanto el certificado como el conjunto de claves son propiedad de STCDBM, el ID de usuario de tarea iniciada del gestor de depuración.
#  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 utilizar 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 firmada a la CA que haya elegido.
#  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
Fin del cambio
La política AT-TLS también documenta el uso del conjunto de claves virtual CERTAUTH para la validación del certificado de servidor presentado por el Debug UI en un escenario Probe-Client. Esto implica que el certificado CA que utiliza Debug UI es considerado de confianza por el host de z/OS.
# 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
Utilice los siguientes mandatos para verificar la configuración:
#  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)

Activación de la política AT-TLS

Se ha completado la configuración de AT-TLS y la política se activará en la siguiente IPL del sistema. Siga estos pasos para empezar a utilizar la política sin una IPL:
  1. Active el soporte AT-TLS en la pila TCP/IP.
    Cree un archivo obey TCP/IP, por ejemplo, TCPIP.TCPPARMS(OBEY), con el siguiente contenido:
    TCPCONFIG TTLS
    Actívelo con este mandato de operador:
    V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
    Compruebe el resultado buscando este mensaje de la consola:
    EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
  2. Inicie el agente de política.
    Emita el mandato de operador:
    S PAGENT
    Verifique el resultado buscando el mensaje de la consola:
    EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
  3. Reinicie el gestor de depuración para interrumpir todas las sesiones activa no encriptadas.
    Emita los mandatos de operador:
    P DBGMGR
    S DBBMGR

Publicaciones a las que se hace referencia

Las publicaciones a las que se hace referencia en este documento son:

Tabla 11. Publicaciones a las que se hace referencia
Título de la publicación Número de pedido Referencia Sitio Web de referencia
Program Directory for IBM Rational Developer for z Systems GI11-8627 (GI11-8298) Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Program Directory for IBM Rational Developer for z Systems Host Utilities GI13-2864 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
       
Guía de configuración de host IBM Rational Developer for z Systems SC43-2926 (SC27-8577) Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Guía de referencia de configuración de host de IBM Rational Developer for z Systems SC43-2925 (SC27-8578) Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
IBM Rational Developer for z Systems Common Access Repository Manager Developer's Guide SC23-7660 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Guía del administrador de SCLM Developer Toolkit SC11-3815-00 (SC23-9801) Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
IBM Explorer for z/OS Host Configuration Guide SC27-8437 z/OS Explorer  
IBM Explorer for z/OS Host Configuration Reference SC27-8438 z/OS Explorer  
Inicio del cambioCommunications Server IP CICS Sockets GuideFin del cambio Inicio del cambioSC31-8807Fin del cambio Inicio del cambioz/OS 1.13Fin del cambio Inicio del cambiohttp://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/Fin del cambio
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/
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 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/
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/
En este documento se hace referencia a los siguientes sitios Web:
Tabla 12. Sitios Web a los que se hace referencia
Descripción Sitio Web de referencia
Developer for z Systems IBM Knowledge Center http://www-01.ibm.com/support/knowledgecenter/SSQ2R2/rdz_welcome.html
Biblioteca de Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Página inicial de Developer for z Systems http://www-03.ibm.com/software/products/en/developerforsystemz/
Servicio recomendado de Developer for z Systems http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335
Solicitud de mejora de Developer for z Systems https://www.ibm.com/developerworks/support/rational/rfe/
Descargar Apache Ant http://ant.apache.org/

Publicaciones informativas

Las publicaciones siguientes pueden serle de utilidad para entender aspectos de configuración de los componentes del sistema host obligatorios:
Tabla 13. Publicaciones informativas
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/

Glosario

Acción de bloquear
Bloquea un miembro.
Archivo de respuestas
  1. Archivo que contiene un conjunto de respuestas predefinidas a preguntas formuladas por un programa y que se utiliza en lugar de entrar dichos valores de uno en uno.
  2. Archivo ASCII que se puede personalizar con los datos de instalación y configuración que automatizan una instalación. Durante una instalación interactiva, es necesario entrar los datos de instalación y configuración, pero si se utiliza un archivo de respuestas, la instalación puede continuar sin ningún tipo de intervención.
atributo bidireccional
Tipo de texto, orientación del texto, intercambio numérico e intercambio simétrico.
Base de datos
Conjunto de elementos de datos interrelacionados o independientes, almacenados conjuntamente para servir a una o más aplicaciones.
Biblioteca de carga
Biblioteca que contiene módulos de carga.
Bidireccional (bi-di)
Relativo a scripts como el árabe o el hebreo que generalmente van de derecha a izquierda, excepto los números, que van de izquierda a derecha. Esta definición pertenece al glosario de la Localization Industry Standards Association (LISA).
Compilar
  1. En los lenguajes Integrated Language Environment (ILE), convertir las sentencias fuente en módulos que luego se pueden enlazar en programas o programas de servicio.
  2. Convertir todo o parte de un programa expresado en un lenguaje de alto nivel en un programa informático expresado en un lenguaje intermedio, ensamblador o lenguaje de máquina.
Conjunto de datos
Unidad principal de almacenamiento y recuperación de datos, que consiste en una colección de datos en una de varias disposiciones prescritas y descritas por la información de control a la que tiene acceso el sistema.
Contenedor
  1. En CoOperative Development Environment/400, objeto del sistema que contiene y organiza archivos fuente. Son ejemplos de contenedor una biblioteca de i5/OS o un conjunto de datos particionado MVS.
  2. En Java EE, entidad que proporciona a los componentes servicios de gestión del ciclo de vida, de seguridad, de despliegue y de tiempo de ejecución. (Sun) Cada tipo de contenedor (EJB, Web, JSP, servlet, applet y cliente de aplicaciones) también proporciona servicios específicos del componente.
  3. En los Servicios BRM, objeto físico utilizado para almacenar y mover medios, como una caja, un estuche o un bastidor.
  4. En un servidor de cintas virtual (VTS), receptáculo en el que es posible almacenar uno o más volúmenes lógicos exportados (LVOL). Volumen apilado que contiene uno o más LVOL y que reside fuera de una biblioteca VTS y que se considera como contenedor de dichos volúmenes.
  5. Ubicación de almacenamiento físico de los datos. Por ejemplo, un archivo, un directorio o un dispositivo.
  6. Columna o fila que se utiliza para disponer el diseño de un portlet o de otro contenedor en una página.
  7. Elemento de la interfaz de usuario que contiene objetos. En el gestor de carpetas, objeto que puede contener otras carpetas o documentos.
Depurar
Detectar, diagnosticar y eliminar errores en programas.
Desinstalación silenciosa
Proceso de desinstalación que no envía mensajes a la consola, sino que almacena los mensajes y los errores en archivos de anotaciones después de haberse invocado el mandato de desinstalación.
Estante lateral
Biblioteca que publica las funciones de un programa DLL. Los nombre de entradas y de módulos se almacenan en la biblioteca una vez compilado el código fuente.
ID de acción
Identificador numérico de una acción, entre 0 y 999
Instalación silenciosa
Instalación que no envía mensajes a la consola, sino que almacena los mensajes y los errores en archivos de anotaciones. Además, en la instalación silenciosa se pueden utilizar archivos de respuestas como entrada de datos.
Instancia de repositorio
Proyecto o componentes que existe en un SCM.
Interactive System Productivity Facility (ISPF)
Programa IBM bajo licencia que funciona como editor de pantalla completa y gestor de diálogos. Si se utiliza para escribir programas de aplicaciones, proporciona una manera de generar paneles de pantallas estándar y diálogos interactivos entre el programador de aplicaciones y el usuario del terminal. ISPF consta de cuatro componentes principales: DM, PDF, SCLM, y C/S. El componente DM es el gestor de diálogos, que proporciona servicios a los diálogos y usuarios finales. El componente PDF es el recurso de desarrollo de programas, que proporciona servicios para ayudar al desarrollador de diálogos o de aplicaciones. El componente SCLM es el gestor de bibliotecas de configuraciones de software, que proporciona servicios a los desarrolladores de aplicaciones para gestionar sus bibliotecas de entorno de aplicaciones. El componente C/S es el cliente/servidor, que permite ejecutar ISPF en una estación de trabajo programable, para visualizar los paneles utilizando la función de visualización del sistema operativo de la estación de trabajo, y para integrar herramientas y datos de la estación de trabajo con las herramientas y datos del host.
Intérprete
Programa que convierte y ejecuta cada instrucción de un lenguaje de programación de alto nivel antes de convertir y ejecutar la siguiente instrucción.
Isomórfico
Cada elemento compuesto (en otras palabras, un elemento que contiene otros elementos) del documento de instancia XML que comienza desde la raíz tiene un y solo un elemento de grupo COBOL correspondiente cuya profundidad de anidación es idéntica a la profundidad de anidación de su equivalente XML. Cada elemento no compuesto (en otras palabras, un elemento que no contiene otros elementos) en el documento de instancia XML que comienza desde la parte superior tiene un y solo un elemento COBOL correspondiente cuya profundidad de anidación es idéntica a la profundidad de anidación de su equivalente XML y cuya dirección de memoria en tiempo de ejecución puede identificarse de forma inequívoca.
Lista de tareas
Lista de procedimientos que se pueden ejecutar mediante un único flujo de control.
Memoria intermedia de error
Parte del almacenamiento utilizado para contener temporalmente la información de salida de errores.
No isomórfico
Correlación simple de elementos COBOL y elementos XML que pertenecen a documentos XML y a grupos COBOL que no son idénticos en la forma (no isomórficos). También se puede crear una correlación no isomorfa entre elementos no isomórficos de estructuras isomórficas.
Nombre de shell
Nombre de la interfaz de shell.
Pasarela
  1. Componente middleware entre Internet y los entornos de intranet durante las invocaciones de servicios Web.
  2. Software que proporciona servicios entre los puntos finales y el resto del entorno Tivoli.
  3. Componente del protocolo de voz por Internet, que proporciona un puente entre VoIP y los entornos de circuitos conmutados.
  4. Dispositivo o programa utilizado para conectar redes o sistemas con diferentes arquitecturas de red. Los sistemas pueden tener distintas características, como distintos protocolos de comunicaciones, distinta arquitectura de red o distingas políticas de seguridad, en cuyo caso la pasarela adquiere un rol de conversión, así como un rol de conexión.
Perspectiva
Grupo de vistas que muestran los diversos aspectos de los recursos del entorno de trabajo. El usuario del entorno de trabajo puede pasar de una perspectiva a otra, en función de la tarea que esté realizando, y personalizar la disposición de las vistas y editores dentro de la perspectiva.
Perspectiva
Proporciona una interfaz para gestionar sistemas remotos utilizando convenciones similares a ISPF.
Petición de construcción
Petición procedente del cliente para realizar una transacción de construcción.
RAM
Gestor de acceso a repositorios
Repositorio
  1. Área de almacenamiento para los datos. Cada repositorio tiene un nombre y un tipo de elemento de negocio asociado. Por defecto, el nombre será el mismo que el nombre del elemento de negocio. Por ejemplo, un repositorio de facturas se llamará Facturas. Hay dos tipos de repositorios de información: local (específico del proceso) y global (reutilizable).
  2. Conjunto de datos VSAM en el que se almacenan los estado de los procesos BTS. Cuando un proceso no se está ejecutando bajo el control de BTS, su estado (y los estados de sus actividades subordinadas) se conservan escribiéndose en un conjunto de datos de repositorio. Los estados de todos los procesos de un tipo de proceso en particular (y los de sus instancias de actividad) se almacenan en el mismo conjunto de datos del repositorio. Es posible escribir registros de varios tipos de proceso en el mismo repositorio.
  3. Área de almacenamiento persistente del código fuente y de otros recursos de las aplicaciones. En un entorno de programación en equipo, el repositorio compartido permite que varios usuarios accedan a los recursos de la aplicación.
  4. Recopilación de información acerca de los gestores de cola que son miembros de un clúster. Esta información incluye nombres de gestores de colas, sus ubicaciones, sus canales, qué colas hospedan, etc.
Script de shell
Archivo que contiene mandatos que la shell puede interpretar. El usuario escribe el nombre del archivo de script en el indicador de mandatos de la shell para hacer que la shell ejecute los mandatos del script.
Sección de enlace
Sección de la división de datos de una unidad activada (un programa al que se llame o un método invocado) que describe los elementos de datos disponibles de la unidad que lo activa (un programa o un método). A estos elementos de datos les puede hacer referencia la unidad activada y la unidad que activa.
Servidor de aplicaciones
  1. Programa que maneja todas las operaciones de aplicación entre los sistemas basados en navegador y las aplicaciones o bases de datos de negocio de fondo de una organización. Hay una clase especial de servidores de aplicación basados en Java que cumplen el estándar Java EE. El código Java EE puede portarse fácilmente entre estos servidores de aplicaciones. Puede soportar JSP y servlets para contenido Web dinámico y EJB para transacciones y acceso a bases de datos.
  2. Destino de una petición procedente de una aplicación remota. En el entorno DB2, la función de servidor de aplicaciones la proporciona el servicio de datos distribuidos, y sirve para acceder a datos de DB2 desde aplicaciones remotas.
  3. En una red distribuida, programa servidor que proporciona el entorno de ejecución de un programa de aplicación.
  4. Destino de una petición procedente de un peticionario de aplicación. El sistema de gestión de bases de datos (DBMS) en el sitio del servidor de aplicaciones proporciona los datos solicitados.
  5. Software que gestiona la comunicación con el cliente que solicita un activo y consultas del gestor de contenido.
Sesión de depuración
Actividades de depuración que tienen lugar entre el momento en que un desarrollador inicia un depurador y el momento en que el desarrollador sale de él.
Shell
Interfaz de software entre los usuarios y el sistema operativo, que interpreta mandatos e interacciones del usuario y los comunica al sistema operativo. Cada sistema puede tiene varias capas de shells para los diversos niveles de interacción de los usuarios.
Sistema de archivos remoto
Sistema de archivos que reside en un servidor o sistema operativo independiente.
Sistema remoto
Cualquier otro sistema en la red con el que puede comunicarse su sistema.
Transacción de construcción
Trabajo iniciado en MVS para realizar construcciones después haberse recibido una petición de construcción procedente del cliente.
URL
Localizador uniforme de recursos.
Vista Consola de salida
Visualiza la salida de un proceso y permite proporcionar entrada de teclado para un proceso.
Vista de definición de datos
Contiene una representación local de bases de datos y de sus objetos y proporciona características para manipular estos objetos y exportarlos a una base de datos remota
Vista Navegador
Vista jerárquica de los recursos que hay en el entorno de trabajo.
Vista repositorios
Muestra la ubicación de los repositorios CVS que se han añadido al entorno de trabajo.
Vista Salida
Muestra los mensajes, parámetros y resultados relacionados con los objetos con los que se esté trabajando.
Vista Servidores
Visualiza una lista de todos los servidores, así como las configuraciones asociadas a ellos.

Avisos

Esta información se ha desarrollado para los productos y los servicios que se ofrecen en Estados Unidos. Este material puede estar disponible en IBM en otros idiomas. No obstante, deberá ser propietario de una copia del producto o una versión del producto en ese idioma para poder acceder a él.

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, MD-NC119
Armonk, NY 10504-1785
EE.UU.

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
Ley de propiedad intelectual y legal
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japón

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 jurisdicciones no permiten la renuncia a las garantías explícitas o implícitas en determinadas transacciones; por lo tanto, es posible que esta declaración no sea aplicable 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 hecha en esta información a sitios web no de IBM se proporciona únicamente para su comodidad y no debe considerarse en modo alguno como promoción de dichos sitios web. 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 proporcione 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:

IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
EE.UU.

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 y los ejemplos de clientes citados se presentan solamente a efectos ilustrativos. Los resultados reales de rendimiento pueden variar en función de configuraciones específicas y condiciones de operación.

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 sobre las prestaciones de los productos que no sean de IBM deberán dirigirse a los proveedores de dichos productos.

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 empresas comerciales o personas reales es mera coincidencia.

LICENCIA DE COPYRIGHT:

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.

Información sobre las interfaces de programación

Marcas registradas

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 "Copyright and trademark information" en www.ibm.com/legal/copytrade.shtml.

Documentación de términos y condiciones para el producto

Los permisos de utilización de estas publicaciones se otorgan sujetos a los términos y condiciones siguientes.

Aplicabilidad

Estos términos y condiciones se añaden a los términos de utilización del 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 ni 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 o volver a exportar esta información excepto en estricto cumplimiento de la legislación y regulaciones aplicables, incluyendo las leyes y regulaciones de exportación de Estados Unidos.

IBM NO GARANTIZA EL CONTENIDO DE ESTAS PUBLICACIONES. LAS PUBLICACIONES SE PROPORCIONAN "TAL CUAL" Y SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUYENDO PERO SIN LIMITARSE A ELLAS, GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, COMERCIALIZACIÓN E IDONEIDAD PARA UN PROPÓSITO DETERMINADO.

Licencia de copyright

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.

Reconocimientos de marcas registradas

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.