Antes de utilizar este documento, lea la información general que figura en el apartado Avisos de documentación de IBM Rational Developer for System z.
Esta edición corresponde al producto IBM Rational Developer para System z Versión 7.6.1 (número de programa 5724-T07) y a todos los releases y modificaciones subsiguientes mientras no se indique lo contrario en nuevas ediciones.
Puede pedir las publicaciones por teléfono o por fax. IBM Software Manufacturing Solutions acepta los pedidos de publicaciones entre las 8:30 de la mañana y las 7:00 de la tarde, hora estándar del este (EST). El número de teléfono es (800) 879-2755. El número de fax es (800) 445-9269. Los faxes deben enviarse a Attn: Publications, 3rd floor.
También puede pedir publicaciones a través de su representante de IBM o de la sucursal de IBM que presta servicio en su localidad. En la dirección que figura más abajo no hay publicaciones almacenadas.
IBM agradece sus comentarios. Puede enviar sus comentarios por correo a la siguiente dirección:
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.
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.
En este documento se describe la configuración de las funciones de IBM Rational Developer for System z. Incluye instrucciones que explican cómo configurar IBM Rational Developer for System z Versión 7.6.1 en su sistema de hospedaje z/OS.
De aquí en adelante, en este manual se utilizarán los siguientes nombres:
En el caso de releases anteriores, incluidos los de IBM WebSphere Developer for System z, IBM WebSphere Developer for zSeries e IBM® WebSphere Studio Enterprise Developer, utilice la información de configuración que se encuentra en la guía de configuración de host y en los directorios de programas de dichos releases.
Este documento está destinado a los programadores de sistemas que instalan y configuran IBM Rational Developer for System z Versión 7.6.1, FMID HHOP760, en su sistema host z/OS.
Lista con detalle los diversos pasos necesarios para realizar una configuración completa del producto, incluidos algunos escenarios que no son predeterminados. Para utilizar esta documentación, debe estar familiarizado con z/OS UNIX System Services y con los sistemas de hospedaje MVS.
En esta sección se resumen los cambios de la Guía de configuración de host de Rational Developer for System z Versión 7.6.1, SC11-3660-04 (actualizado en mayo de 2010).
Los cambios técnicos o las adiciones al texto y las ilustraciones se indican mediante una línea vertical situada a la izquierda del cambio.
Este documento contiene la información presentada anteriormente en la Guía de configuración de host de Rational Developer for System z Versión 7.6, SC11-3660-03.
Información nueva:
En esta sección se resume la información presentada en este documento.
Utilice la información de este capítulo, para planificar la instalación y el despliegue de Developer for System z.
Los pasos de configuración que se indican a continuación corresponden a una configuración básica de Developer for System z:
CARMA (Common Access Repository Manager) es una ayuda de productividad para los desarrolladores que crean RAM (Repository Access Managers). Un RAM es una interfaz de programación de aplicaciones (API) para SCM (Software Configuration Managers) basados en z/OS.
A su vez, las aplicaciones escritas por usuario pueden iniciar un servidor CARMA que cargue los RAM y suministre una interfaz estándar para acceder al SCM.
La interfaz de IBM® Rational® Developer for System zcon el Gestor de configuraciones de software de CA Endevor® proporciona a los clientes de Developer for System z acceso directo a CA Endevor® SCM.
Developer for System z utiliza determinadas funciones del Gestor de despliegue de aplicaciones como procedimiento de despliegue común para varios componentes. La personalización opcional permite tener más características de Application Deployment Manager y puede añadir los servicios siguientes a Developer for System z:
SCLM Developer Toolkit suministra las herramientas necesarias para ampliar las prestaciones de SCLM para el cliente. SCLM en sí es un gestor de código fuente basado en host-based que se suministra como parte de ISPF.
SCLM Developer Toolkit contiene un plug-in de Eclipse-based que intercambia información con SCLM y proporciona acceso a todos los procesos SCLM para el desarrollo de código de legado, así como soporte para el desarrollo completo de Java y J2EE en la estación de trabajo en sincronización con el SCLM del sistema central, incluidas las tareas de construir, ensamblar y desplegar el código J2EE desde el sistema central.
Esta sección combina diversas tareas de personalización opcionales. Siga las instrucciones de la sección adecuada para configurar el servicio que desee.
Después de completar la personalización del producto, puede utilizar los Programas de verificación de la instalación (IVP) descritos en este capítulo para verificar la configuración satisfactoria de componentes de productos clave.
Este capítulo proporciona una visión general de los mandatos del operador (o la consola) disponibles para Developer for System z.
Este capítulo se propone ayudarle a resolver algunos problemas comunes que pueden surgir durante la configuración de Developer for System z, y tiene las secciones siguientes:
Developer for System z proporciona a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. Algunos aspectos importantes de la configuración del producto son: validar las solicitudes de conexión, proporcionar una comunicación segura entre el host y la estación de trabajo, y autorizar y auditar la actividad.
El host de Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Comprender el diseño de estos componentes puede ayudarle a tomar las decisiones de configuración correctas.
Al contrario que las aplicaciones z/OS tradicionales, Developer for System z no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Algunos de estos servicios están activos en diferentes espacios de direcciones, lo que resulta en diferentes clasificaciones WLM.
RSE (Explorador de Sistemas remotos) es el núcleo de Developer for System z. Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente.
Ello hace que RSE sea el destino principal para ajustar la configuración de Developer for System z. Sin embargo, mantener a cientos de usuarios, cada uno de los cuales utiliza 16 hebras o más, una cantidad determinada de almacenamiento y, posiblemente, one o más espacios de direcciones, requiere que la configuración de Developer for System z y z/OS.
z/OS es un sistema operativo sumamente personalizable, y los cambios de sistema (a veces pequeños) pueden afectar considerablemente al rendimiento global. En este capítulo se resaltan algunos de los cambios que se pueden hacer para mejorar el rendimiento de Developer for System z.
Este capítulo contiene información útil para un administrador de CICS Transaction Server.
Este capítulo le ayuda a emular un procedimiento de inicio de sesión TSO añadiendo sentencias DD y conjuntos de datos al entorno TSO en Developer for System z.
En algunas ocasiones le interesará tener múltiples instancias de Developer for System z activas en el mismo sistema; por ejemplo, al probar una ampliación. Sin embargo, algunos recursos como los puertos TCP/IP no se pueden compartir, por lo que los valores predeterminados no siempre son aplicables. Utilice la información de este capítulo para planificar la coexistencia de distintas instancias de Developer for System z, y después podrá usar esta guía de configuración para personalizarlas.
En este apartado se resaltan los cambios de instalación y configuración comparados con los releases anteriores del producto. También se ofrecen algunas directrices generales para la migración a este release. Para obtener más información, consulte las secciones relacionadas de este manual.
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar la capa de sockets segura (SSL), o durante la tarea de comprobar o modificar una configuración existente. Este apéndice también facilita una configuración de ejemplo para admitir que los usuarios se autentiquen con un certificado X.509.
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar TCP/IP, o durante la tarea de comprobar o modificar una configuración existente.
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar INETD, o durante la tarea de comprobar o modificar una configuración existente. Developer for System z utiliza INETD para la función REXEC/SSH.
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar APPC (comunicaciones avanzadas programa a programa) o durante la tarea de comprobar o modificar una configuración existente.
Este apéndice enumera los prerrequisitos y correquisitos del host para esta versión de Developer for System z.
Utilice la información de este capítulo, junto con la información de Apéndice E. Requisitos, para planificar la instalación y el desarrollo de Developer for System z. Se describen los siguientes temas:
Guía de migración describe los cambios de instalación y configuración comparados con los releases anteriores del producto. Utilice esta información para planificar la migración al release actual de Developer for System z.
Developer for System z está formado por un cliente, instalado en el sistema personal del usuario, y un servidor, instalado en uno o varios hosts. Esta documentación se centra en el host como sistema z/OS. Sin embargo, también están soportados otros sistemas operativos como AIX y Linux® on System z.
El cliente proporcionar desarrolladores para un entorno de desarrollo basado en Eclipse que facilita al host una interfaz gráfica uniforme y que, entre otras cosas, puede descargar trabajo del host en el cliente, guardando los recursos en el host.
La parte del host está formada por varias tareas permanentemente activas y por tareas que se inician con un fin. Estas tareas permiten al cliente trabajar con los distintos componentes del host z/OS, tales como conjuntos de datos MVS, mandatos TSO, archivos y comandos z/OS UNIX, sometimientos de trabajos y salidas de trabajos.
Developer for System z también puede interactuar con subsistemas y otro software de aplicaciones en el host, tales como CICS, Debug Tool y Software Configuration Managers (SCM), si Developer for system z está configurado para ello, y si los productos (correquisito) están disponibles.
Consulte Qué es Developer for System z para obtener los conocimientos básicos del diseño de Developer for System z.
Consulte el sitio web de Developer for System z, http://www-01.ibm.com/software/awdtools/rdz/, o a su representante de IBM local para obtener más información acerca de las funciones que ofrece Developer for System z.
Los conocimientos técnicos de SMP/E que se necesitan para la instalación de un host de Developer for System z son mínimos.
Para la configuración de Developer para System z se necesita más que los conocimientos técnicos y permisos normales, de manera que es posible que sea necesaria una ayuda por parte de otras personas. Tabla 3 y Tabla 4 enumeran a los administradores necesarios para las tareas de personalización tanto obligatorias como opcionales.
El tiempo que se necesita par instalar y configurar los componentes de host de Developer for System z depende de varios factores, tales como:
La experiencia ha demostrado que para completar el proceso de instalación y configuración del host de Developer for System z se necesita entre uno y cuatro días. Este requisito de tiempo se calcula para una instalación limpiar realizada por un programador de sistemas con experiencia. Si se encuentran problemas, o si no se dispone de los conocimientos técnicos necesarios, la configuración podría llevar más tiempo.
Consulte la publicación Directorio de programa para IBM Rational Developer for System z, GI11-8627 (GI11-8298), para obtener instrucciones detalladas acerca de la instalación SMP/E del producto.
Consulte la sección Ejecutar varias instancias si tiene previsto ejecutar varias instancias de Developer for System z.
Developer for System z ofrece una opción relativa a cómo acceder al servicio de mandatos TSO. La elección realizada aquí influye sobre la configuración necesaria de los requisitos previos. Debe seleccionarse y configurarse uno de los métodos siguientes:
Apéndice E. Requisitos tiene una lista del software prerrequisito que hay que instalar y debe estar operativo para que Developer for System z funcione. También hay una lista del software correquisito para poder utilizar las características específicas de Developer for System z. Estos requisitos deben estar instalados y ser operativos en tiempo de ejecución para que la correspondiente característica funcione como es debido.
Consulte los Requisitos previos de Rational Developer for System z (SC23-7659) en la biblioteca en línea del Developer for System z en http://www-01.ibm.com/software/awdtools/rdz/library/ si desea obtener una lista actualizada de los productos prerrequisito y correquisito para su versión de Developer for System z. Planee por adelantado la disponibilidad de estos productos requisito, ya que puede tardar algún tiempo en función de las políticas del sitio. Los requisitos clave para una configuración básica son los siguientes:
Developer for System z requiere la asignación de los recursos del sistema indicados en la sección Tabla 1. Los recursos listados en Tabla 2 son necesarios para los servicios opcionales. Prevea la disponibilidad de estos recursos ya que puede llevar algún tiempo conseguirlos, según las políticas de su sitio.
Recurso | Valor predeterminado | Información |
---|---|---|
conjunto de datos autorizado APF | FEK.SFEKAUTH | Autorizaciones APF en PROGxx |
tarea iniciada | JMON, RSED y LOCKD | Consideraciones sobre el servidor |
puerto para uso exclusivo del host | 6715 | FEJJCNFG, archivo de configuración del supervisor de trabajos JES |
puerto para uso exclusivo del host | 4036 | rsed.envvars, archivo de configuración de RSE |
puerto para la comunicación cliente-host | 4035 | Cambios de PROCLIB |
rango de puertos para la comunicación cliente-host | se utiliza cualquier puerto disponible | Definir el rango de puertos (PORTRANGE) disponibles para el servidor RSE |
Definición de seguridad de aplicación | READ de acceso universal para FEKAPPL | Definir la protección de aplicaciones para RSE |
definiciones de seguridad PassTicket | no hay valor predeterminado | Definir el soporte de PassTicket para RSE |
Recurso | Valor predeterminado | Información |
---|---|---|
conjunto de datos LINKLIST | FEK.SFEKAUTH y FEK.SFEKLOAD | (Opcional) SCLM Developer Toolkit |
conjunto de datos LPA | FEK.SFEKLPA | (Opcional) CARMA (Common Access Repository Manager) |
rango de puertos para uso exclusivo del host | 5227-5326 (100 puertos) | (Opcional) CARMA (Common Access Repository Manager) |
puertos para uso exclusivo del host | se utiliza cualquier puerto disponible | (Opcional) Transacción APPC para el servicio de mandatos TSO |
puerto para la comunicación cliente-host | no hay valor predeterminado | (Opcional) Gestor de despliegue de aplicaciones (ADM) |
Actualización CSD de CICS | varios valores | (Opcional) Gestor de despliegue de aplicaciones (ADM) |
Actualización JCL de CICS | FEK.SFEKLOAD |
Para la configuración de Developer for System z se necesita más que los conocimientos técnicos y permisos normales, de manera que es posible que sea necesaria una mínima ayuda por parte de otras personas. Tabla 3 y Tabla 4 enumeran a los administradores necesarios para las tareas de personalización tanto obligatorias como opcionales.
Administrador | Tarea | Información |
---|---|---|
Sistema | Son necesarias acciones típicas del programador de sistemas para todas las tareas de personalización | N/A |
Seguridad |
|
Consideraciones relativas a la seguridad |
TCP/IP | Definir nuevos puertos TCP/IP | Puertos TCP/IP |
WLM | Asignar objetivos de tarea iniciada a los servidores y los procesos hijo | Consideraciones de WLM |
Administrador | Tarea | Información |
---|---|---|
Sistema | Son necesarias acciones típicas del programador de sistemas para todas las tareas de personalización | N/A |
Seguridad |
|
|
TCP/IP | Definir nuevos puertos TCP/IP | Puertos TCP/IP |
SCLM |
|
(Opcional) SCLM Developer Toolkit |
CICS TS |
|
|
DB2 | Definir un procedimiento almacenado DB2 | (Opcional) Procedimiento almacenado DB2 |
WLM |
|
|
APPC | Define una transacción APPC | (Opcional) Transacción APPC para el servicio de mandatos TSO |
Al contrario que las aplicaciones z/OS tradicionales, Developer for System z no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Consulte la sección Consideraciones de WLM para planificar la configuración de WLM en consecuencia.
Cuando se está utilizando, Developer for System z utilizará un número variable de recursos del sistema, como espacios de direcciones, y procesos y hebras z/OS UNIX. La disponibilidad de estos recursos está limitada por varias definiciones de sistema. Consulte Consideraciones acerca de los ajustes para estimar el uso de los recursos clave, de manera que pueda planificar acorde la configuración del sistema.
Consulte al programador del sistema MVS, al administrador de seguridad y al administrador de TCP/IP para saber si los productos y software obligatorios están instalados, se han probado y funcionan. A continuación se indican algunas tareas de personalización obligatorias que es fácil pasar por alto:
El ID de un usuario de Developer for System z debe tener (como mínimo) los siguientes atributos:
Ejemplo (mandato LISTUSER userid NORACF OMVS):
USER=userid INFORMACIÓN de OMVS ---------------- UID= 0000003200 HOME= /u/userid PROGRAM= /bin/sh CPUTIMEMAX= NONE ASSIZEMAX= NONE FILEPROCMAX= NONE PROCUSERMAX= NONE THREADSMAX= NONE MMAPAREAMAX= NONE
Ejemplo (mandato LISTGRP grupo NORACF OMVS):
GROUP grupo INFORMACIÓN de OMVS ---------------- GID= 0000003243
Developer for System z consta de 3 servidores permanentemente activos, que pueden ser tareas iniciadas o trabajos de usuario. Estos servidores proporcionan por sí mismos los servicios solicitados o inician otros servidores (como hebras z/OS UNIX o trabajos de usuario) para suministrar el servicio.
El Supervisor de trabajos JES (JMON) suministra todos los servicios relacionados con JES.
Explorador de sistemas remotos RSE es el componente de Developer for System z que proporciona servicios centrales como los de conectar el cliente al host.
Como se describe en Puertos TCP/IP, determinados servicios de host y, por consiguiente, sus puertos deben estar disponibles para que el cliente se conecte a ellos. Los demás puertos que utiliza Developer for System z tienen tráfico solo de host. A continuación se indican los puertos necesarios para una configuración básica de Developer for System z.
A partir de la versión 7.6.1, Developer for System z proporciona un método alternativo, mediante una aplicación de panel ISPF, para configurar el lado de host del producto. Esto le permite elegir entre los métodos siguientes:
Developer for System z permite clonar una instalación en un sistema distinto, lo cual evita la necesidad de instalar SMP/E en cada sistema.
A continuación se indican los conjuntos de datos, directorios y archivos que son obligatorios para el despliegue en otros sistemas. Si ha copiado un archivo en una ubicación diferente, este archivo debe sustituir a su equivalente en las listas que figuran más abajo.
Consulte la publicación UNIX System Services Command Reference (SA22-7802) para obtener más información acerca de los siguientes mandatos de ejemplo para archivar y restaurar el directorio de instalación de Developer for System z.
Los usuarios del cliente Developer for System z deben conocer el resultado de determinadas personalizaciones del host, como la de los números de puerto TCP/IP, para que el cliente funcione como es debido. Utilice estas listas de comprobación para reunir la información que necesite.
La lista de comprobación de Tabla 5 indica los resultados necesarios de los pasos de personalización obligatorios. Tabla 6 indica los resultados necesarios de los pasos de personalización opcionales.
Personalización | Valor |
---|---|
Número de puerto del servidor del supervisor de
trabajos JES (el valor predeterminado es 6715 ):
Consulte SERV_PORT en FEJJCNFG, archivo de configuración del supervisor de trabajos JES. |
|
Número de puerto TCP/IP del daemon RSE (el valor predeterminado es 4035):
Consulte Daemon RSE. |
Personalización | Valor |
---|---|
Ubicación de los procedimientos
ELAXF* si no están en la biblioteca de procedimientos del
sistema:
Vea la nota de JCLLIB en: Procedimientos de construcción remota ELAXF*. |
|
Nombres de procedimiento o paso de los procedimientos ELAXF*,
si se han cambiado
Vea la nota que indica cómo cambiarlos, en: Procedimientos de construcción remota ELAXF*. |
|
Nombre de procedimiento almacenado DB2 (el valor predeterminado es ELAXMSAM):
Vea información sobre los procedimientos almacenados DB2, en: Ejecutar varias instancias. |
|
Ubicación del procedimiento almacenado DB2 si no está en una biblioteca de procedimientos del sistema: | |
(correquisito) Número de puerto TN3270 para el Emulador de conexión de host (valor predeterminado 23).
Consulte: Consideraciones relativas a la seguridad |
|
(correquisito) Número de puerto REXEC o SSH (valor predeterminado 512 o 22, respectivamente): | |
Ubicación del archivo server.zseries si se utiliza el método de conexión REXEC/SSH (valor predeterminado /etc/rdz). | |
Ubicación del JCL de CRA#ASLM para las asignaciones de
conjuntos de datos RAM de SCLM de CARMA (valor predeterminado FEK.#CUST.JCL):
Vea la nota de CRA#ASLM, en: Activar los RAM de SCLM. |
Los pasos de configuración que se indican a continuación corresponden a una configuración básica de Developer for System z. Consulte los capítulos dedicados a los componentes opcionales para conocer sus requisitos de personalización.
Necesitará ayuda de un administrador de seguridad y de un administrador de TCP/IP para realizar esta tarea de personalización, que requiere los siguientes recursos y tareas de personalización especiales:
A fin de verificar la instalación y empezar a utilizar Developer for System z en su sitio, debe realizar las tareas siguientes. A menos que se indique de otro modo, todas las tareas son obligatorias.
Developer for System z se suministra con varios archivos de configuración y JCL de ejemplo. Para evitar la necesidad de sobrescribir las personalizaciones al aplicar el mantenimiento, debe copiar todos estos miembros y los archivos de z/OS UNIX en una ubicación diferente y personalizar la copia.
Algunas funciones de Developer for System z también requieren la existencia de determinados directorios en z/OS UNIX, que deben crearse durante la personalización del producto. Para facilitar el proceso de instalación, se suministra un trabajo de ejemplo, FEKSETUP, destinado a crear las copias y los directorios necesarios.
Personalice y someta el miembro de ejemplo FEKSETUP del conjunto de datos FEK.SFEKSAMP para crear copias personalizables de los archivos y el JCL de configuración, y para crear los directorios z/OS UNIX necesarios. Los pasos de personalización necesarios se describen dentro del miembro.
Este trabajo realiza las tareas siguientes:
mkdir /usr/lpp/rdz/cust ln -s /usr/lpp/rdz/cust /etc/rdz
Consulte la publicación MVS Initialization and Tuning Reference (SA22-7592) para obtener más información acerca de las definiciones de PARMLIB listadas más abajo. Consulte la publicación MVS System Commands (SA22-7627) para obtener más información sobre los mandatos de consola de ejemplo.
El Explorador de sistemas remotos (RSE), que proporciona servicios del núcleo como los de conectar el cliente al host, es un proceso basado en z/OS UNIX. Por ello, es importante establecer los valores correcto para los límites del sistema z/OS UNIX en BPXPRMxx, basándose en la cantidad de usuarios de Developer for System z que están activos simultáneamente y en su carga de trabajo media.
Consulte Consideraciones acerca de los ajustes para obtener más información sobre los distintos límites de BPXPRMxx y su impacto sobre Developer for System z.
MAXASSIZE especifica el tamaño máximo de la región del espacio de direcciones (proceso). Establezca MAXASSIZE en SYS1.PARMLIB(BPXPRMxx) en 2G. Es el valor máximo permitido. Este es un límite a escala del sistema y, por ello, está activo para todos los espacios de direcciones z/OS UNIX. Si no desea este límite, puede establecer el límite únicamente para Developer for System z en el software de seguridad, tal como se describe en Definir las tareas iniciadas de Developer for System z.
MAXTHREADS especifica el número máximo de hebras activas para un único proceso. Establezca MAXTHREADS en SYS1.PARMLIB(BPXPRMxx) en 1500 o más. Este es un límite a escala del sistema y, por ello, está activo para todos los espacios de direcciones z/OS UNIX. Si no desea este límite, puede establecer el límite únicamente para Developer for System z en el software de seguridad, tal como se describe en Definir las tareas iniciadas de Developer for System z.
MAXTHREADTASKS especifica el número máximo de tareas de MVS activas para un único proceso. Establezca MAXTHREADTASKS en SYS1.PARMLIB(BPXPRMxx) en 1500 o más. Este es un límite a escala del sistema y, por ello, está activo para todos los espacios de direcciones z/OS UNIX. Si no desea este límite, puede establecer el límite únicamente para Developer for System z en el software de seguridad, tal como se describe en Definir las tareas iniciadas de Developer for System z.
MAXPROCUSER especifica el número máximo de procesos que un solo ID de usuario de z/OS UNIX puede tener activos simultáneamente. Establezca MAXPROCUSER en SYS1.PARMLIB(BPXPRMxx) en 50 o más. Este valor pretender ser un límite a nivel del sistema, ya que debe estar activo para cada cliente que utiliza Developer for System z.
Estos valores pueden comprobarse y establecerse dinámicamente (hasta la próxima IPL) con los siguientes mandatos de consola:
Añada mandatos de inicio para los servidores RSED, LOCKD y JMON de Developer for System z a SYS1.PARMLIB(COMMANDxx) para que se inicien automáticamente en la próxima IPL.
Una vez definidos y configurados los servidores, podrán iniciarse dinámicamente (hasta la próxima IPL) con los siguientes mandatos de consola:
El servicio CARMA (Common Access Repository Manager) (opcional) da soporte a métodos alternativos de inicio del servidor que no requieren la utilización de un iniciador JES. La más flexible de estas alternativas requiere que el módulo CRASTART de la biblioteca de carga FEK.SFEKLPA se encuentre en la LPA (Área de paquete de enlace).
Los conjuntos de datos LPA se definen en SYS1.PARMLIB(LPALSTxx).
Las definiciones LPA pueden establecerse dinámicamente (hasta la próxima IPL) con los siguientes mandatos de consola:
Para que el supervisor de trabajos JES pueda acceder a los archivos de spool JES, el módulo FEJJMON de la biblioteca de carga FEK.SFEKAUTH y las bibliotecas de tiempo de ejecución de Language Environment (LE) (CEE.SCEERUN*) deben estar autorizadas por APF.
Para que SCLM Developer Toolkit (opcional) funcione, el módulo BWBTSOW de la biblioteca de carga FEK.SFEKAUTH y las bibliotecas de tiempo de ejecución de REXX (REXX.SEAGLPA) deben estar autorizadas por APF.
Para que ISPF pueda crear la Pasarela de cliente TSO/ISPF, el módulo ISPZTSO de SYS1.LINKLIB debe estar autorizado por APF. El servicio de mandatos TSO de Developer for System z, SCLM Developer Toolkit y opcionalmente CARMA utilizan la Pasarela de cliente TSO/ISPF.
Las autorizaciones de APF se definen en SYS1.PARMLIB(PROGxx), si su local siguió las recomendaciones de IBM.
Las autorizaciones APF pueden establecerse dinámicamente (hasta la próxima IPL) con los siguientes mandatos de consola, donde volser es el volumen en el que reside el conjunto de datos si no está gestionado por SMS:
Las definiciones LINKLIST de Developer for System z se puede agrupar en 3 categorías:
Para que SCLM Developer Toolkit (opcional) funcione, todos los módulos BWB* de las bibliotecas de carga FEK.SFEKAUTH y FEK.SFEKLOAD deben estar disponibles por medio de STEPLIB o LINKLIST.
Si opta por utilizar STEPLIB, debe definir las bibliotecas no disponibles por medio de LINKLIST en la directiva STEPLIB de rsed.envvars, el archivo de configuración de RSE. Sin embargo, tenga en cuenta lo siguiente:
Los conjuntos de datos de LINKLIST se definen en SYS1.PARMLIB(PROGxx), si su sitio ha seguido las recomendaciones de IBM.
Las definiciones necesarias serán parecidas a la siguiente, donde listname es el nombre del conjunto LINKLIST que se activara, y volser es el nombre volumen en el que reside el conjunto de datos si no está catalogado en el catálogo maestro:
Las definiciones LINKLIST pueden crearse dinámicamente (hasta la próxima IPL) con el siguiente grupo de mandatos de consola, donde listname es el nombre del conjunto LINKLIST actual y volser es el volumen en el que reside el conjunto de datos si no está catalogado en el catálogo maestro:
El Explorador de sistemas remotos (RSE) es un proceso z/OS UNIX que requiere acceso a las bibliotecas de carga de MVS. Las bibliotecas siguientes (prerrequisito) deben estar disponibles por medio de STEPLIB o LINKLIST/LPALIB:
Las bibliotecas adicionales siguientes deben estar disponibles por medio de STEPLIB o LINKLIST/LPALIB, para dar soporte a la utilización de servicios opcionales. Esta lista no incluye los conjuntos de datos específicos de un producto con el que interactúa Developer for System z, como IBM Debug Tool:
Los conjuntos de datos de LINKLIST se definen en SYS1.PARMLIB(PROGxx), si su sitio ha seguido las recomendaciones de IBM. Los conjuntos de datos LPA se definen en SYS1.PARMLIB(LPALSTxx).
Si opta por utilizar STEPLIB, debe definir las bibliotecas no disponibles por medio de LINKLIST/LPALIB en la directiva STEPLIB de rsed.envvars, el archivo de configuración de RSE. Sin embargo, tenga en cuenta lo siguiente:
El cliente de Developer for System z tiene un componente de generación de código denominado Enterprise Service Tools (EST). Para que el código generado emita mensajes de error de diagnóstico, todos los módulos IRZ* y IIRZ* de la biblioteca de carga FEK.SFEKLOAD deben estar disponibles a través de STEPLIB o LINKLIST.
Los conjuntos de datos de LINKLIST se definen en SYS1.PARMLIB(PROGxx), si su sitio ha seguido las recomendaciones de IBM.
Si opta por utilizar STEPLIB, debe definir las bibliotecas no disponibles por medio de LINKLIST en la directiva STEPLIB de la tarea que ejecuta el código (IMS o trabajo por lotes). Sin embargo, debe tener en cuenta lo siguiente:
Los procedimientos de tarea iniciada y construcción remota indicados más abajo deben residir en una biblioteca de procedimientos del sistema definida en el subsistema JES. En las instrucciones que siguen, se utiliza la biblioteca de procedimientos predeterminada de IBM, SYS1.PROCLIB.
Personalice el miembro de tarea iniciada de ejemplo FEK.#CUST.PROCLIB(JMON), tal como se describe dentro del miembro, y cópielo en SYS1.PROCLIB. Como se muestra en el ejemplo de código que figura a continuación, debe suministrar lo siguiente:
//*
//* SUPERVISOR DE TRABAJOS JES
//*
//JMON PROC PRM=, * PRM='-TV' TO START TRACING
// LEPRM='RPTOPTS(ON)',
// HLQ=FEK,
// CFG=FEK.#CUST.PARMLIB(FEJJCNFG)
//*
//JMON EXEC PGM=FEJJMON,REGION=0M,TIME=NOLIMIT,
// PARM=('&LEPRM,ENVAR("_CEE_ENVFILE_S=DD:ENVIRON")/&PRM')
//STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKAUTH
//ENVIRON DD DISP=SHR,DSN=&CFG
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// PEND
//*
Personalice el miembro de tarea iniciada de ejemplo FEK.#CUST.PROCLIB(RSED), tal como se describe dentro del miembro, y cópielo en SYS1.PROCLIB. Como se muestra en el ejemplo de código que figura a continuación, debe suministrar lo siguiente:
//* //* DAEMON RSE //* //RSED PROC IVP='', * 'IVP' para realizar una prueba IVP // PORT=4035, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME/bin/rsed.sh &IVP &PORT &CNFG' //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* // PEND //*
Personalice el miembro de tarea iniciada de ejemplo FEK.#CUST.PROCLIB(LOCKD), tal como se describe dentro del miembro, y cópielo en SYS1.PROCLIB. Como se muestra en el ejemplo de código que figura a continuación, debe suministrar lo siguiente:
//* //* RSE LOCK DAEMON //* //LOCKD PROC HOME='/usr/lpp/rdz', // CNFG='/etc/rdz', // LOG=1 //* //LOCKD EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, PARM=PGM &HOME./bin/lockd.sh &CNFG &LOG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* // PEND //*
La longitud máxima para la variable PARM es de 100 caracteres, lo cual puede causar problemas si utiliza nombres de directorio personalizados. Para evitar este problema, puede:
Los enlaces simbólicos pueden utilizarse como taquigrafía de un nombre de directorio largo. El siguiente mandato z/OS UNIX de ejemplo define un enlace simbólico (/usr/lpp/rdz) a otro directorio (/long/directory/name/usr/lpp/rdz).
ln -s /long/directory/name/usr/lpp/rdz /usr/lpp/rdz
Si el campo PARM está vacío, BPXBATSL iniciará una shell z/OS UNIX y ejecutará el script de shell suministrado por STDIN. Tenga en cuenta que STDIN debe ser un archivo z/OS UNIX (asignado como ORDONLY) y que al utilizar STDIN se inhabilita la utilización de las variables PROC para el puerto, etc. Tenga también en cuenta que la shell ejecutará los scripts de inicio de sesión de shell /etc/profile y $HOME/.profile.
Para utilizar este método, primero de actualizar el JCL de inicio para que coincida con un código parecido al del ejemplo siguiente:
//* //* DAEMON RSE - UTILIZACIÓN DE STDIN //* //RSED PROC CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.stdin.sh' //STDENV DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.envvars' // PEND //*
En segundo lugar, debe crear el script de shell (/etc/rdz/rsed.stdin.sh en este ejemplo) que iniciará el daemon RSE. El contenido de este script será como el del ejemplo siguiente:
/long/directory/name/usr/lpp/rdz/bin/rsed.sh 4035 /etc/rdz
Developer for System z proporciona procedimientos JCL de ejemplo que se pueden usar para la generación de JCL, para las construcciones de proyectos remotos y las características de comprobación de sintaxis remota de mapas BMS de CICS, pantallas MFS de IMS y programas COBOL, PL/I, Assembler y C/C++. Estos procedimientos permiten a las instalaciones aplicar sus propios estándares y garantizará que los desarrolladores utilicen los mismos procedimientos con las mismas opciones de compilador y los mismos niveles de compilador.
Los procedimientos de ejemplo y sus funciones se listan en Tabla 7.
Miembro | Finalidad |
---|---|
ELAXFADT | Procedimiento de ejemplo para ensamblar y depurar programas assembler de alto nivel. |
ELAXFASM | Procedimiento de ejemplo para ensamblar programas del ensamblador de alto nivel (HLASM). |
ELAXFBMS | Procedimiento de ejemplo para crear un objeto BMS CICS y el correspondiente miembro de inclusión, dsect o copia. |
ELAXFCOC | Procedimiento de ejemplo para hacer compilaciones COBOL, conversiones CICS integradas y conversiones DB2 integradas. |
ELAXFCOP | Procedimiento de muestra para hacer preproceso DB2 de sentencias EXEC SQL incluidas en programas COBOL. |
ELAXFCOT | Procedimiento de ejemplo para hacer conversión CICS de sentencias CICS EXEC embebidas en programas COBOL. |
ELAXFCPC | Procedimiento de muestra para hacer compilaciones en C. |
ELAXFCPP | Procedimiento de muestra para hacer compilaciones en C++. |
ELAXFCP1 | Procedimiento de ejemplo para compilaciones COBOL con sentencias de preprocesador SCM (-INC e ++INCLUDE). |
ELAXFDCL | Procedimiento de ejemplo para ejecutar un programa en modalidad TSO. |
ELAXFGO | Procedimiento de ejemplo para el paso GO. |
ELAXFLNK | Procedimiento de ejemplo para enlazar programas C/C++, COBOL, PLI y Assembler de alto nivel. |
ELAXFMFS | Procedimiento de ejemplo para crear pantallas MFS IMS. |
ELAXFPLP | Procedimiento de muestra para hacer preproceso DB2 de sentencias EXEC SQL incluidas en programas PLI. |
ELAXFPLT | Procedimiento de ejemplo para hacer conversión CICS de sentencias CICS EXEC embebidas en programas PLI. |
ELAXFPL1 | Procedimiento de ejemplo para hacer compilaciones PL/I, conversiones CICS integradas y conversiones DB2 integradas. |
ELAXFPP1 | Procedimiento de ejemplo para compilaciones PL/I con sentencias de preprocesador SCM (-INC e ++INCLUDE). |
ELAXFTSO | Procedimiento de ejemplo para ejecutar/depurar código DB2 generado en modalidad TSO. |
ELAXFUOP | Procedimiento de ejemplo para generar el paso UOPT al construir programas que se ejecutan en subsistemas CICS o IMS. |
Los nombres de los procedimientos y los nombres de los pasos de cada procedimiento coinciden con las propiedades predeterminadas que se suministran con el cliente Developer for System z. Si decide cambiar el nombre de un procedimiento o el nombre de un paso del procedimiento, también hay que actualizar el correspondiente archivo de propiedades en todos los clientes. Le recomendamos que no cambie el nombre de los procedimientos ni de los pasos.
Personalice los miembros de procedimiento de construcción de ejemplo FEK.#CUST.PROCLIB(ELAXF*), como se describe dentro de los miembros, y cópielos en SYS1.PROCLIB. Debe suministrar los calificadores de alto nivel correctos para las diversas bibliotecas de producto, como se describe en Tabla 8.
Producto | HLQ predeterminado | Valor |
---|---|---|
Developer for System z | FEK | |
CICS | CICSTS32.CICS | |
DB2 | DSN910 | |
IMS | IMS | |
COBOL | IGY.V4R1M0 | |
PL/I | IBMZ.V3R8M0 | |
C/C++ | CBC | |
LE | CEE | |
LINKLIB del sistema | SYS1 | |
MACLIB del sistema | SYS1 |
Si los procedimientos ELAXF* no se pueden copiar en una biblioteca de procedimientos del sistema, solicite a los usuarios de Developer for System z que añadan una tarjeta JCLLIB (justo después de la tarjeta JOB) a las propiedades del trabajo en el cliente.
//MYJOB JOB <parámetros del trabajo> //PROCS JCLLIB ORDER=(FEK.#CUST.PROCLIB)
Personalice y someta el miembro de ejemplo FEKRACF del conjunto de datos FEK.#CUST.JCL para crear las definiciones de seguridad para Developer for System z. El usuario que somete este trabajo debe tener privilegios de administrador de seguridad, como SPECIAL de RACF.
La lista siguiente de definiciones obligatorias relacionadas con la seguridad para Developer for System z se describen con detalle en el Consideraciones relativas a la seguridad. Este capítulo también describe los aspectos generales relacionados con la seguridad de Developer for System z, que incluyen los aspectos de seguridad de los productos obligatorios que no se cubren en el trabajo de ejemplo FEKRACF.
Atención: La solicitud de conexión del cliente fallará si la seguridad de la
aplicación los PassTickets no están configurados correctamente. |
El Supervisor de trabajos JES (JMON) suministra todos los servicios relacionados con JES. El comportamiento del Supervisor de trabajos JES puede controlarse con las definiciones de FEJJCNFG.
FEJJCNFG* se encuentra en FEK.#CUST.PARMLIB, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Personalice el miembro de configuración del supervisor de trabajos JES de ejemplo FEJJCNFG, como se muestra en el ejemplo siguiente. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado; los comentarios no pueden estar en la misma línea.
SERV_PORT=6715
TZ=EST5EDT
#_BPXK_SETIBMOPT_TRANSPORT=TCPIP
#APPLID=FEKAPPL
#AUTHMETHOD=SAF
#CODEPAGE=UTF-8
#CONCHAR=$
#CONSOLE_NAME=JMON
#GEN_CONSOLE_NAME=OFF
#HOST_CODEPAGE=IBM-1047
#LIMIT_COMMANDS=NOLIMIT
#LIMIT_VIEW=USERID
#LISTEN_QUEUE_LENGTH=5
#MAX_DATASETS=32
#MAX_THREADS=200
#TIMEOUT=3600
#TIMEOUT_INTERVAL=1200
#SUBMITMETHOD=TSO
#TSO_TEMPLATE=FEK.#CUST.CNTL(FEJTSO)
Número de puerto del servidor de hospedaje del supervisor de trabajos JES. El puerto predeterminado es 6715. Cámbielo según desee, pero tenga en cuenta que AMBOS, el servidor y los clientes Developer for System z, deben estar configurados con el mismo número de puerto. Si cambia el número de puerto del servidor, todos los clientes también deben cambiar el puerto del supervisor de trabajos JES para este sistema en la vista Sistemas remotos.
Las definiciones que figuran a continuación son opcionales. Si se omiten, se emplearán los valores predeterminados que se especifican más abajo:
Independientemente de qué nombre de consola se utilice, se utiliza el ID de usuario del cliente que solicita el mandato como la LU de la consola, dejando un rastreo en los mensajes de syslog IEA630I y IEA631.
IEA630I OPERATOR console NOW ACTIVE, SYSTEM=sysid, LU=id IEA631I OPERATOR console NOW INACTIVE, SYSTEM=sysid, LU=id
Esta directiva solamente se utiliza cuando CONSOLE_NAME iguala &SYSUID, y el ID de usuario no está disponible como nombre de consola.
Si GEN_CONSOLE_NAME=ON, se genera un nombre de consola alternativo añadiendo un único dígito al ID de usuario. Se intentan todos los dígitos desde el 0 hasta el 9. En caso de que no se encuentre ninguna consola disponible, el mandato emitido por el cliente fallará.
Si GEN_CONSOLE_NAME=OFF, el mandato emitido por el cliente fallará.
A partir de la versión 7.6.1, los clientes de Developer for System z ignoran el valor HOST_CODEPAGE especificado aquí y utilizan la página de códigos especificada localmente en las propiedades del subsistema "Archivos MVS".
Propietario del trabajo | ||
---|---|---|
LIMIT_COMMANDS | Usuario | Otros |
USERID (valor predeterminado) | Permitido | No permitido |
LIMITED | Permitido | Permitido sólo si lo permiten explícitamente los perfiles de seguridad |
NOLIMIT | Permitido | Permitido si lo permiten los perfiles de seguridad o cuando la clase JESSPOOL no está activa |
Los procesos del daemon de bloqueo RSE y del servidor RSE (daemon RSE, agrupación de hebras RSE y servidor RSE) utilizan las definiciones de rsed.envvars. Los servicios opcionales de Developer for System z y de terceros pueden utilizar también este archivo de configuración para definir variables de entorno para su uso.
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 daemon de bloqueo proporciona servicios de rastreo para bloqueos de conjuntos de datos.
rsed.envvars se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
Consulte el siguiente archivo rsed.envvars de ejemplo, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado; los comentarios no pueden estar en la misma línea. Las continuaciones de línea y los espacios alrededor del signo igual (=) no están soportados.
#============================================================= # (1) definiciones obligatorias JAVA_HOME=/usr/lpp/java/J5.0 RSE_HOME=/usr/lpp/rdz _RSE_LOCKD_PORT=4036 _RSE_HOST_CODEPAGE=IBM-1047 TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin _CEE_DMPTARG=/tmp STEPLIB=NONE #STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL _RSE_SAF_CLASS=/usr/include/java_classes/IRRRacf.jar _RSE_JAVAOPTS="" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms1m -Xmx256m" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddaemon.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_LOG_DIRECTORY=" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=1000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dipv6=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dkeep.last.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.standard.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.port.of.entry=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.certificate.mapping=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.automount=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.audit.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.cycle=30" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.retention.period=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddeny.nonzero.port=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dsingle.logon=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dprocess.cleanup.interval=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DAPPLID=FEKAPPL" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDENY_PASSWORD_SAVE=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DHIDE_ZOS_UNIX=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IDLE_SHUTDOWN_TIMEOUT=3600000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_TRACING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_MEMLOGGING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) definiciones obligatorias para la Pasarela de cliente TSO/ISPF _CMDSERV_BASE_HOME=/usr/lpp/ispf _CMDSERV_CONF_HOME=/etc/rdz _CMDSERV_WORK_HOME=/var/rdz #STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB _RSE_CMDSERV_OPTS="" #_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF" #============================================================= # (3) definiciones obligatorias para SCLM Developer Toolkit _SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 #============================================================= # (4) definiciones opcionales #_RSE_PORTRANGE=8108-8118 #_BPXK_SETIBMOPT_TRANSPORT=TCPIP #_FEKFSCMD_TP_NAME_=FEKFRSRV #_FEKFSCMD_PARTNER_LU_=nombre_lu #GSK_CRL_SECURITY_LEVEL=HIGH #GSK_LDAP_SERVER=ldap_server_url #GSK_LDAP_PORT=ldap_server_port #GSK_LDAP_USER=ldap_userid #GSK_LDAP_PASSWORD=ldap_server_password #=============================================================
# (5) no lo cambie a menos que así se lo indique el centro de soporte de IBM _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES JAVA_PROPAGATE=NO RSE_LIB=$RSE_HOME/lib PATH=.:$JAVA_HOME/bin:$RSE_HOME/bin:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$RSE_LIB:$RSE_LIB/icuc LIBPATH=.:/usr/lib:$LIBPATH CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.jar CLASSPATH=$CLASSPATH:$RSE_LIB/zosserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_miners.jar CLASSPATH=$CLASSPATH:$RSE_LIB/universalminers.jar:$RSE_LIB/mvsminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/carma.jar:$RSE_LIB/luceneminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsluceneminer.jar:$RSE_LIB/cdzminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvscdzminer.jar:$RSE_LIB/jesminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/FAMiner.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsutil.jar:$RSE_LIB/jesutils.jar CLASSPATH=$CLASSPATH:$RSE_LIB/lucene-core-2.3.2.jar CLASSPATH=$CLASSPATH:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=$CLASSPATH:$_RSE_SAF_CLASS CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DISPF_OPTS='$_RSE_CMDSERV_OPTS'" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DA_PLUGIN_PATH=$RSE_LIB" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xbootclasspath/p:$RSE_LIB/bidiTools.jar" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dfile.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dconsole.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_SPIRIT_ON=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_EXPIRY_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_INTERVAL_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlow.heap.usage.ratio=15" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.heap.usage.ratio=40" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_ENABLED=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_RESPONSE_TIMEOUT=30000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IO_SOCKET_READ_TIMEOUT=90000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DRSECOMM_LOGFILE_MAX=0" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.port=$_RSE_LOCKD_PORT" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.cleanup.interval=1440" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_SERVER_CLASS=org.eclipse.dstore.core.server.Server _RSE_DAEMON_CLASS=com.ibm.etools.zos.server.RseDaemon _RSE_POOL_SERVER_CLASS=com.ibm.etools.zos.server.ThreadPoolProcess _RSE_LOCKD_CLASS=com.ibm.ftt.rse.mvs.server.miners.MVSLockDaemon _RSE_SERVER_TIMEOUT=120000 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME #============================================================= # (6) variables de entorno adicionales
Las definiciones que se necesitan son las siguientes:
Hallará información adicional en la publicación UNIX System Services Command Reference (SA22-7802).
Puede pasar por alto la necesidad de contar con bibliotecas prerrequisito en LINKLIST/LPALIB descomentando y personalizando una o varias de las siguientes directivas STEPLIB. Consulte la sección Cambios de PARMLIB para obtener más información acerca de la utilización de las bibliotecas indicadas a continuación:
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD
Por omisión, Developer for System z utiliza la Pasarela de cliente TSO/ISPF de ISPF para el servicio de mandatos TSO. Se utiliza una transacción APPC cuando la siguiente opción _RSE_JAVAOPTS no está comentada:
RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
Las definiciones siguientes son obligatorias si se utiliza la Pasarela de cliente TSO/ISPF de ISPF para el servicio de mandatos TSO, SCLM Developer Toolkit o CARMA.
Notas:
Las definiciones siguientes son necesarias si se utiliza SCLM Developer Toolkit.
Las definiciones que figuran a continuación son opcionales. Si se omiten, se emplearán los valores predeterminados:
El nombre de host puede ser una dirección TCP/IP o un URL. Cada nombre de host puede contener un número de puerto opcional separado del nombre de host por dos puntos (:).
Las siguientes definiciones son necesarias y no se deben cambiar, a menos que así lo indique el centro de soporte de IBM:
Esta es una parte de la personalización de rsed.envvars que especifica los puertos en los que el servidor RSE se puede comunicar con el cliente. Este rango de puertos no tiene conexión con el puerto del daemon RSE.
Para ayudarle a comprender la utilización de los puertos, se proporciona esta descripción corta del proceso de conexión del RSE:
Para especificar el rango de puertos para que el cliente se comunique con z/OS, descomente y personalice la siguiente línea del archivo rsed.envvars:
#_RSE_PORTRANGE=8108-8118
El formato de PORTRANGE es: _RSE_PORTRANGE=min-max (max no es inclusive; por ejemplo, _RSE_PORTRANGE=8108-8118 significa que los puertos utilizables son los comprendidos entre los números 8108 y 8117). El número de puerto que el servidor RSE utiliza se determina en el siguiente orden:
Con las distintas directivas _RSE_*OPTS, el archivo rsed.envvars ofrece la posibilidad de proporcionar parámetros adicionales a Java cuando inicia los procesos RSE. Las opciones de ejemplo incluidas en el archivo rsed.envvars se pueden activar a base de quitarles el carácter de comentario.
_RSE_JAVAOPTS define opciones Java estándar y específicas de RSE.
Las directivas siguientes están comentadas por omisión.
Con las distintas directivas _RSE_*OPTS, el archivo rsed.envvars ofrece la posibilidad de proporcionar parámetros adicionales a Java cuando inicia los procesos RSE. Las opciones de ejemplo incluidas en el archivo rsed.envvars se pueden activar a base de quitarles el carácter de comentario.
Las directivas _RSE_CMDSERV_OPTS son opciones Java específicas de RSE y solo entran en vigor cuando el Developer for System z utiliza la Pasarela de cliente TSO/ISPF de ISPF. (Este es el valor predeterminado.)
Pueden utilizarse las variables siguientes en el nombre del conjunto de datos:
La Pasarela de cliente TSO/ISPF de ISPF utiliza las definiciones de ISPF.conf para crear un entorno válido para ejecutar mandatos TSO e ISPF por lotes. Developer for System z utiliza este entorno para ejecutar algunos de los servicios basados en MVS. Estos servicios incluyen el servicio de mandatos TSO, SCLM Developer Toolkit y un método de inicio alternativo de CARMA.
ISPF.conf se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
Las líneas de comentarios empiezan por un asterisco (*) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado. Los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas. Al concatenar nombres de conjuntos de datos, añádalos en la misma línea y separe los nombres con una coma (,).
Además de suministrar los nombres correctos para los conjuntos de datos de ISPF, también debe añadir el nombre del conjunto de datos del servicio de mandatos TSO, FEK.SFEKPROC, a la sentencia SYSPROC o SYSEXEC, como se muestra en el ejemplo siguiente.
* OBLIGATORIO:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
* OPCIONAL:
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
*ISPF_timeout = 900
Por ejemplo:
ISPTRACE=nullfile
Los pasos de personalización indicados anteriormente corresponden a una configuración básica de Developer for System z. Consulte los capítulos dedicados a los componentes opcionales para conocer sus requisitos de personalización.
La descripción de los programas de verificación de la instalación (IVP) está ubicada en Verificación de la instalación, porque algunos de los IVP son para componentes opcionales.
CARMA (Common Access Repository Manager) es una ayuda de productividad para los desarrolladores que crean RAM (Repository Access Managers). Un RAM es una interfaz de programación de aplicaciones (API) para SCM (Software Configuration Managers) basados en z/OS.
A su vez, las aplicaciones escritas por usuario pueden iniciar un servidor CARMA que cargue los RAM y suministre una interfaz estándar para acceder al SCM.
Developer for System z da soporte a varios métodos para iniciar un servidor CARMA, cada uno de los cuales con sus propias ventajas e inconvenientes.
Necesitará ayuda de un administrador de seguridad y de un administrador de TCP/IP para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
A fin de empezar a utilizar CARMA en su sitio, debe realizar las tareas siguientes. A menos que se indique de otro modo, todas las tareas son obligatorias.
Los siguientes componentes de CARMA deben personalizarse, independientemente del método de inicio elegido. Los siguientes miembros de ejemplo se encuentran en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Developer for System z Versión 7.6.1 soporta un diseño de estructura de datos nuevo para el conjunto de datos VSAM de información personalizada de CARMA, CRASTRS, para eliminar limitaciones de longitud de mensaje.
Antes de Developer for System z Versión 7.6.1, las series definidas en el conjunto de datos VSAM de información personalizada de CARMA estaban limitadas a las longitudes predefinidas. Esta limitación hace que los desarrolladores RAM abrevien las series descriptivas o que utilicen plug-ins del lado del cliente para visualizar series en toda su longitud.
Developer for System z Versión 7.6.1 soporta un diseño de estructura de datos de longitud variable nuevo para el conjunto de datos VASAM de información personalizada de CARMA, CRASTRS, en el que las series están separadas por un carácter delimitador en lugar de tener una longitud fija.
Personalice y someta el JCL FEK.SFEKSAMP(CRA#VS2) JCL para convertir el conjunto de datos VSAM de información personalizada de CARMA de longitud fija existente, CRASTRS, en el formato de longitud variable nueva.
El servidor CARMA suministra una API estándar para que otros productos basados en host-based puedan acceder a uno o varios SCM (Software Configuration Manager). Sin embargo, no suministra métodos para la comunicación directa con un PC cliente. Para ello se basa en otros productos, como por ejemplo el servidor RSE. El servidor RSE utiliza los valores de CRASRV.properties para iniciar un servidor CARMA y conectarse a él.
CRASRV.properties se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
# CRASRV.properties - Opciones de configuración de CARMA # port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)' crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
El valor predeterminado es 'FEK.#CUST.CNTL(CRASUBMT)'. Esta CLIST iniciará un servidor CARMA cuando se abra una conexión mediante el método de sometimiento por lotes.
A (Todo | Toda la información de rastreo se graba en SYSLOG |
P (Parcial) | Sólo la información de conexión, desconexión y errores se graba en SYSLOG |
resto de información | Sólo las condiciones de error se graban en SYSLOG |
Esta directiva sólo se utiliza si la directiva clist.dsname tiene el valor *CRASTART.
La información de esta sección describe cómo configurar el método predeterminado para que Developer for System z inicie un servidor CARMA. Este paso de personalización puede pasarse por alto si se utiliza otro método de inicio.
Developer for System z utiliza, por omisión, el método de inicio del servidor CARMA de sometimiento por lotes que no requiere que el módulo CRASTART se encuentre en LPA y que no depende de la Pasarela de cliente TSO/ISPF. El método somete el servidor CARMA como un trabajo por lotes de larga ejecución en su JES.
El servidor RSE utiliza los valores de /etc/rdz/CRASRV.properties para iniciar un servidor CARMA y conectarse a él, como se indica en la sección Interfaz RSE con CARMA. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
Cambie el valor de la directiva clist.dsname por el conjunto de datos y el nombre de miembro de la CLIST de inicio del servidor CARMA CRASUBMT, como se muestra en el ejemplo siguiente. Consulte la sección Interfaz RSE con CARMA para obtener más información sobre las diferentes directivas.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)'
Personalice la CLIST de CRASUBMT, como se muestra en el ejemplo de código siguiente. Las instrucciones de personalización están en la documentación de CRASUBMT. La CLIST de CRASUBMT somete un servidor CARMA.
CRASUBMT se encuentra en FEK.#CUST.CNTL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=25,REGION=1024K,TIME=NOLIMIT //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //* DD DISP=SHR,DSN=FEK.#CUST.LOAD //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //*CRARAM1 DD DISP=SHR,DSN=FEK.#CUST.CRARAM1 //* //ISPPROF DD DISP=(NEW,DELETE,DELETE), // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB,UNIT=SYSALLDA //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB //* //CARMALOG DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ISPSTART PGM(CRASERV) PARM(&PORT &TIMEOUT) //* $$ EXIT CODE(0)
La información de esta sección describe cómo configurar un método alternativo para que Developer for System z inicie un servidor CARMA. Este paso de personalización puede pasarse por alto si se utiliza otro método de inicio.
Developer for System z da soporte a un método de inicio alternativo del servidor CARMA que no depende de la Pasarela de cliente TSO/ISPF y que no somete un trabajo servidor mediante un iniciador de JES. El método utiliza CRASTART para iniciar el servidor CARMA como subtarea de RSE y es similar al servicio de Pasarela de cliente TSO/ISPF.
El servidor RSE utiliza los valores de /etc/rdz/CRASRV.properties para iniciar un servidor CARMA y conectarse a él, como se indica en la sección Interfaz RSE con CARMA. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
Cambie el valor de la directiva clist.dsname por *CRASTART y suministre los valores correctos para las directivas crastart.*, como se muestra en el ejemplo siguiente. Consulte la sección Interfaz RSE con CARMA para obtener más información sobre las diferentes directivas.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
Tenga a mano una copia impresa del CRASUBMT personalizado (consulte la sección Inicio del servidor CARMA mediante el sometimiento por lotes) para poder consultarlo con facilidad durante este paso de configuración. La copia impresa será de utilidad aunque no haya personalizado el miembro.
CRASTART utiliza las definiciones de crastart.conf para crear un entorno válido para ejecutar mandatos TSO e ISPF por lotes. Developer for System z utiliza este entorno para ejecutar el servidor CARMA CRASERV.
crastart.conf se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
Son necesarios los siguientes pasos de personalización para ajustar el archivo de configuración que se muestra en el ejemplo de código que figura más adelante.
* crastart.conf - Opciones de asignación de CARMA TASKLIB = FEK.SFEKLOAD CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS *CRARAM1 = FEK.#CUST.CRARAM1 * CARMALOG = SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY -COMMAND=ALLOC FI(SCRATCH) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) UNIT(VIO) * PROGRAM=IKJEFT01 CRASERV &CRAPRM1. &CRAPRM2.
Pueden utilizarse las variables siguientes en el archivo de configuración:
&CRAUSER. | ID de usuario de inicio de sesión del cliente. |
&CRADATE. | Fecha actual en el formato Daaaaddd (Juliano de 7 caracteres). |
&CRATIME. | Hora actual en el formato Thhmmss (horas, minutos y segundos). |
&CRAPRM3. a &CRAPRM9. |
Variables adicionales con valores asignados por el usuario. La utilización de estas variables requiere la personalización del REXX de inicio de CARMA al que se hace referencia en startup.script.name de CRASRV.properties. Cuando utiliza estas variables, debe personalizar una copia del REXX de inicio predeterminado, /usr/lpp/rdz/bin/carma.startup.rex y hace que startup.script.name apunte a esta copia. Esto es para evitar que pierda su trabajo cuando el mantenimiento actualice el REXX predeterminado. |
símbolo del sistema | Cualquier símbolo del sistema definido en SYS1.PARMLIB(IEASYMxx) |
-<DD> | Un guión (-) seguido de un nombre DD definido anteriormente actúa como retrorreferencia *.ddname de JCL. La DD original debe asignarse mediante la sentencia -COMMAND. |
La información de esta sección describe cómo configurar un método alternativo para que Developer for System z inicie un servidor CARMA. Este paso de personalización puede pasarse por alto si se utiliza otro método de inicio.
Developer for System z da soporte a un método de inicio alternativo del servidor CARMA que no requiere que el módulo CRASTART se encuentre en LPA y que no somete un trabajo servidor mediante un iniciador de JES. El método utiliza la Pasarela de cliente TSO/ISPF de ISPF y es similar al procedimiento predeterminado para acceder al servicio de mandatos TSO.
El servidor RSE utiliza los valores de /etc/rdz/CRASRV.properties para iniciar un servidor CARMA y conectarse a él, como se indica en la sección Interfaz RSE con CARMA. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
Cambie el valor de la directiva clist.dsname por *ISPF, como se muestra en el ejemplo siguiente. Consulte la sección Interfaz RSE con CARMA para obtener más información sobre las diferentes directivas.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*ISPF
Tenga a mano una copia impresa del CRASUBMT personalizado (consulte la sección Inicio del servidor CARMA mediante el sometimiento por lotes) para poder consultarlo con facilidad durante este paso de configuración. La copia impresa será de utilidad aunque no haya personalizado el miembro.
La Pasarela de cliente TSO/ISPF de ISPF utiliza las definiciones de ISPF.conf para crear un entorno válido para ejecutar mandatos TSO e ISPF por lotes. Developer for System z utiliza este entorno para ejecutar el servidor CARMA.
ISPF.conf se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
Son necesarios los siguientes pasos de personalización para ajustar el archivo de configuración que se muestra en el ejemplo de código que figura más adelante.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispllib=FEK.SFEKLOAD ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB CRADEF =FEK.#CUST.CRADEF CRAMSG =FEK.#CUST.CRAMSG CRASTRS=FEK.#CUST.CRASTRS *CRARAM1=FEK.#CUST.CRARAM1 allocjob=FEK.#CUST.CNTL(CRAISPRX)
DD CARMALOG hace referencia por omisión a SYSOUT=*, que no puede correlacionarse en ISPF.conf. No puede correlacionar las DD directamente con un conjunto de datos cualquiera, ya que todos los usuarios de Developer for System z van a utilizar el mismo archivo ISPF.conf y, por tanto, los mismos conjuntos de datos.
Sin embargo, tal como se describe en Personalizar el entorno TSO, sección Avanzado - Utilizar un exec de asignación, puede utilizar un exec de asignación para crear y asignar un conjunto de datos en función del ID de usuario activo. Consulte el miembro de ejemplo CRAISPRX del conjunto de datos FEK.#CUST.CNTL para obtener un ejemplo de cómo asignar la DD CARMALOG al nombre de conjunto de datos TSOPREFIX'.'USERID'.CRA.'TIMESTAMP'.CARMALOG'.
Los RAM (Repository Access Managers) son API escritas por el usuario para intercambiar información con los SCM (Software Configuration Managers) de z/OS. Siga las instrucciones de los apartados que figuran más abajo para los RAM de ejemplo que desea activar.
Consulte la publicación Rational Developer for System z Common Access Repository Manager Developer's Guide (SC23-7660) para obtener más información acerca de los RAM de ejemplo y el código fuente de ejemplo que se suministran.
Los siguientes miembros de ejemplo se encuentran en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
El RAM de PDS proporciona una lista de conjuntos de datos similar a MVS Archivos -> Mis conjuntos de datos en la vista Sistemas remotos. El RAM de PDS utiliza el ID de RAM 0 de forma predeterminada.
El RAM de SCLM le proporciona una entrada básica a SCLM, el Software Configuration Manager de ISPF. El RAM de SCLM utiliza el ID de RAM 1 de forma predeterminada.
El RAM de esqueleto proporciona una infraestructura de esqueleto que se puede utilizar para desarrollar sus propias RAM. El RAM de esqueleto utiliza el ID de RAM 3 de forma predeterminada.
La interfaz de IBM® Rational® Developer for System z con el Gestor de configuraciones de software de CA Endevor® proporciona a los clientes de Developer for System z acceso directo a CA Endevor® SCM. En adelante, nos referiremos a la interfaz de IBM® Rational® Developer for System z con CA Endevor® SCM como CA Endevor® SCM RAM (Gestor de acceso a repositorios).
Al contrario que los RAM de ejemplo documentados en esta publicación, CA Endevor® SCM RAM es un RAM de tipo de producción. No debe activar ambos tipos de RAM en la misma configuración.
Atención: los trabajos de configuración proporcionados para CA Endevor® SCM RAM sustituyen la configuración de CARMA activa con una que contiene únicamente CA Endevor® SCM RAM. |
Necesita ayuda de un administrador de seguridad y de un administrador de TCP/IP para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
A fin de empezar a utilizar CA Endevor® SCM RAM en su sitio, debe realizar las tareas siguientes. A menos que se indique de otro modo, todas las tareas son obligatorias.
Los siguientes componentes de CARMA deben personalizarse, independientemente del método de inicio elegido. Los siguientes miembros de ejemplo se encuentran en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
No ejecute este paso si utiliza el método CRASTART para iniciar el servidor CARMA con CA Endevor® SCM RAM.
Developer for System z puede utilizar el método de inicio de servidor CARMA de sometimiento por lotes para iniciar CA Endevor® SCM RAM. El método somete el servidor CARMA como un trabajo por lotes de larga ejecución en su JES.
Consulte la sección Inicio del servidor CARMA mediante el sometimiento por lotes para obtener más información sobre el método de inicio de sometimiento por lotes.
El servidor RSE utiliza los valores de /etc/rdz/CRASRV.properties para iniciar un servidor CARMA y conectarse a él, como se indica en la sección Interfaz RSE con CARMA. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
Cambie el valor de la directiva clist.dsname por el conjunto de datos y el nombre de miembro de la CLIST de inicio del servidor CARMA CRASUBCA, como se muestra en el ejemplo siguiente. Consulte la sección Interfaz RSE con CARMA para obtener más información sobre las diferentes directivas.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBCA)'
Personalice la CLIST de CRASUBCA, como se muestra en el ejemplo de código siguiente. Las instrucciones de personalización están en la documentación de CRASUBCA. La CLIST CRASUBCA somete un servidor CARMA para CA Endevor® SCM.
CRASUBCA se encuentra en FEK.#CUST.CNTL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=125,REGION=0M,TIME=NOLIMIT, // PARM='%CRANDVRA NDVRC1 PGM(CRASERV) PARM(&PORT &TIMEOUT)' //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD // DD DISP=SHR,DSN=CA.NDVR.AUTHLIB // DD DISP=SHR,DSN=CA.NDVRU.AUTHLIB //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //* //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB // DD DISP=SHR,DSN=FEK.SFEKPROC //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPCTL0 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPCTL1 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //* //CARMALOG DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY //* //CONLIB DD DISP=SHR,DSN=CA.NDVR.CONLIB //JCLOUT DD SYSOUT=(A,INTRDR),DCB=(LRECL=80,RECFM=F,BLKSIZE=80) //EXT1ELM DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //EXT1DEP DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //MSG3FILE DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1MSGS1 DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1EXMSGS DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //TYPEMAP DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRATMAP) //SHOWVIEW DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRASHOW) $$ EXIT CODE(0)
No ejecute este paso si utiliza el método de sometimiento por lotes para iniciar el servidor CARMA con CA Endevor® SCM RAM.
Developer for System z puede utilizar el método de inicio de servidor CARMA CRASTART para iniciar CA Endevor® SCM RAM. El método utiliza CRASTART para iniciar el servidor CARMA como subtarea dentro de RSE..
Consulte (Opcional) Inicio alternativo del servidor CARMA mediante CRASTART para obtener más información sobre el método de inicio de CRASTART.
El servidor RSE utiliza los valores de /etc/rdz/CRASRV.properties para iniciar un servidor CARMA y conectarse a él, como se indica en la sección Interfaz RSE con CARMA. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
Cambie el valor de la directiva clist.dsname por *CRASTART y suministre los valores correctos para las directivas crastart.*, como se muestra en el ejemplo siguiente. Consulte la sección Interfaz RSE con CARMA para obtener más información sobre las diferentes directivas.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.endevor.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
CRASTART utiliza las definiciones de crastart.endevor.conf para crear un entorno (TSO/ISPF) válido para invocar CA Endevor® SCM. Developer for System z utiliza este entorno para ejecutar CA Endevor ® SCM RAM.
crastart.endevor.conf se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
TASKLIB = FEK.SFEKLOAD,CA.NDVR.AUTHLIB,CA.NDVRU.AUTHLIB CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS SYSPROC = ISP.SISPCLIB,FEK.SFEKPROC SYSEXEC = ISP.SISPEXEC ISPMLIB = ISP.SISPMENU ISPPLIB = ISP.SISPPENU ISPSLIB = ISP.SISPSENU -COMMAND=ALLOC FI(ISPCTL0) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPCTL1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPPROF) NEW DELETE DSORG(PO) DIR(5) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) ISPTLIB = -ISPPROF,ISP.SISPTENU ISPTABL = -ISPPROF CARMALOG = SYSOUT(H) SYSPRINT= SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY TYPEMAP = FEK.#CUST.PARMLIB(CRATMAP) SHOWVIEW= FEK.#CUST.PARMLIB(CRASHOW) CONLIB = CA.NDVR.CONLIB -COMMAND=ALLOC FI(JCLOUT) SYSOUT(A) WRITER(INTRDR) RECFM(F) LRECL(80) BLKSIZE(80) -COMMAND=ALLOC FI(EXT1ELM) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(EXT1DEP) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(MSG3FILE) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1EXMSGS) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1MSGS1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) PROGRAM=IKJEFT01 %CRANDVRA NDVRC1 PGM(CRASERV) PARM(&CRAPRM1. &CRAPRM2.)
Ambos métodos de inicio, el de sometimiento por lotes y CRASTART invocan REXX exec CRANDVRA para asignar conjuntos de datos específicos de usuario utilizados por CA Endevor® SCM RAM.
DD | Nombre de conjunto de datos | Tipo |
---|---|---|
DEPEND | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.DEPEND | Permanente |
BROWSE | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.BROWSE | Temporal |
C1PRINT | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.LISTING | Temporal |
Puede personalizar una copia de este REXX exec si ciertos valores predeterminados, como por ejemplo el nombre del conjunto de datos, no cumplen los estándares del sitio. CRANDVRA está ubicado en FEK.SFEKPROC, a menos que haya utilizado un calificador de alto nivel diferente durante la instalación SMP/E de Developer for System z.
Las instrucciones de personalización están en la documentación de CRANDVRA.
Los siguientes componentes de CARMA se pueden personalizar, independientemente del método de inicio elegido. Los siguientes miembros de ejemplo se encuentran en FEK.#CUST.PARMLIB, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
CARMA permite definir varios RAM y puede ejecutarlos simultáneamente. Sin embargo, puesto que sólo hay un servidor CARMA activo por usuario, incluso cuando haya varios RAM, es posible que sean necesarios algunos cambios de configuración para que esta configuración funcione.
Los RAM los define un desarrollador de RAM en el conjunto de datos VSAM de configuración de CARMA. CRADEF. Durante el inicio, el servidor CARMA, CRASERV, identificará todos los RAM definidos y presentará la información al cliente CARMA. El usuario puede seleccionar entonces uno o varios RAM que se cargarán en el servidor CARMA.
Puesto que los RAM están activos como plug-ins del servidor CARMA, debe asegurarse de que todos los prerrequisitos (como por ejemplo asignaciones de conjuntos de datos) para cada uno de los RAM están disponibles en el espacio de dirección del servidor CARMA. Para ello será necesario realizar cambios en los ejemplos de configuración de CARMA, como por ejemplo CRASUBMT o crastart.conf, que se envían con Developer for System z.
En el ejemplo siguiente, empieza desde una configuración de CA Endevor® SCM RAM existente, mediante el método de inicio CRASTART y añade el PDS RAM de ejemplo.
Definiciones para CA Endevor® SCM RAM:
Definiciones para el PDS RAM:
El proceso empieza con un desarrollador de RAM recopilando los datos y la información necesarios para que el programador del sistema realice la configuración.
El programador del sistema utiliza entonces estos datos para crear los conjuntos de datos CARMA VSAM actualizados y utiliza la información de prerrequisito para crear un archivo de configuración CRASTART capaz de soportar ambos RAM.
CA Endevor® SCM RAM está activo en un entorno ISPF, lo que implica que el entorno TSO necesario para PDS RAM también está disponible.
Si el servidor CARMA se ha iniciado mediante TSO (IKJEFTxx), puede experimentar problemas si los RAM llaman a servicios que, a su vez, llaman a IRXJCL, la interfaz de proceso por lotes de REXX. El problema puede producirse cuando los procesadores llamados por los RAM se ejecutaron anteriormente sin TSO o sólo en TSO en línea, y se asignaban dinámicamente DD SYSTSIN o SYSTSPRT. Se suministra un programa de ejemplo, CRAXJCL, para solucionar este problema.
El procesador puede fallar si intenta asignar SYSTSIN o SYSTSPRT (necesarias para IRXJCL) debido a que el TSO por lotes (necesario para CARMA) ya tiene asignados y abiertos esos nombres de DD. El módulo de sustitución CRAXJCL intenta asignar SYSTSIN y SYSTSPRT a DUMMY, pero ignora los errores producidos si fallan las asignaciones.
Esto significa que, cuando los procesadores se ejecutan en un entorno CARMA iniciado por TSO, las asignaciones a SYSTSIN y SYSTSPRT son las mismas que las utilizadas por CARMA. Cuando los procesadores se ejecutan fuera de TSO/CARMA, CRAXJCL creará las asignaciones de SYSTSIN y SYSTSPRINT. Por tanto, los procesadores no deben confiar en el contenido del conjunto de datos asignado a SYSTSIN.
Se presupone que las llamadas a IRXJCL utilizan el campo PARM para pasar el nombre y los parámetros de inicio de REXX, como se describe en la publicación TSO/E REXX Reference (SA22-7790). Esto significa que CARMA puede utilizar SYSTSIN de forma segura. Cualquier salida enviada a SYSTSPRT por IRXJCL finalizará en las anotaciones de CARMA.
Los procesadores que llaman al módulo de sustitución CRAXJCL no deben intentar asignar las DD SYSTSIN o SYSTSPRT antes de llamar a CRAXJCL.
El módulo de sustitución CRAXJCL se suministra en formato fuente, ya que deberá personalizarlo para especificar las asignaciones específicas que desea utilizar para SYSTSPRT. Generalmente, SYSTSIN debe asignarse a un conjunto de datos ficticio.
Se suministran código fuente de ensamblado de ejemplo y un trabajo de compilación/enlace de ejemplo como FEK.#CUST.ASM(CRAXJCL) y FEK.#CUST.JCL(CRA#CIRX), respectivamente, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Personalice el código fuente de ensamblado de CRAXJCL según sus necesidades utilizando la documentación del miembro. Después, personalice y someta el JCL de CRA#CIRX para crear el módulo de carga CRAXJCL. Las instrucciones de personalización se encuentran en la documentación de CRA#CIRX.
Developer for System z utiliza determinadas funciones del Gestor de despliegue de aplicaciones como procedimiento de despliegue común para varios componentes. Los pasos de personalización indicados en este capítulo son necesarios si los desarrolladores utilizan alguna de las funciones siguientes:
Personalizar el Gestor de despliegue de aplicaciones Manager añade el servidor CDR (definiciones de recursos CICS), que se ejecuta como una aplicación CICS de z/OS para soportar estas funciones:
Los administradores de CICS pueden encontrar más información acerca del servidor CRD en consideraciones de CICSTS.
Necesitará ayuda de un administrador de CICS, de un administrador de TCP/IP y de un administrador de seguridad para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
A fin de empezar a utilizar el Gestor de despliegue de aplicaciones en su sitio, debe realizar las tareas siguientes. A menos que se indique de otro modo, todas las tareas son obligatorias.
Personalice y someta el trabajo ADNVCRD para asignar e inicializar el conjunto de datos VSAM del repositorio CRD. Consulte la documentación del miembro para obtener instrucciones de personalización.
ADNVCRD se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Debe crear un repositorio aparte para cada región de conexión primaria CICS. El hecho de compartir el repositorio implica que todas las regiones CICS relacionadas utilizarán los mismos valores almacenados en el repositorio.
Los usuarios necesitan acceso de lectura (READ) al repositorio CRD, y los administradores de CICS necesitan acceso de actualización (UPDATE).
Developer for System z suministra el programa de utilidad administrativo que permite a los administradores de CICS proporcionar los valores predeterminados para las definiciones de recursos CICS. Estos valores predeterminados pueden ser de sólo lectura o pueden ser editables para los desarrolladores de aplicaciones.
El programa de utilidad administrativo se invoca mediante el trabajo de ejemplo ADNJSPAU. La utilización de este programa de utilidad requiere acceso de actualización (UPDATE) al repositorio de CRD.
ADNJSPAU se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Encontrará más información en la sección consideraciones de CICSTS.
CICS Transaction Server proporciona en la versión 4.1 y superior soporte para una interfaz HTTP diseñada utilizando los principios de la transferencia de estado representativo (RESTful). Esta interfaz RESTful es ahora la interfaz CICSTS estratégica para las aplicaciones de cliente. La interfaz de servicio web anterior se ha estabilizado, y las mejoras serán únicamente para la interfaz RESTful.
El Gestor de despliegue de aplicaciones sigue esta sentencia de dirección y necesita el servidor CRD de RESTful para todos los servicios que son nuevos Developer for System versión 7.6 o superior.
Las interfaces RESTful y de servicio Web puede estar activas simultáneamente en una única región CICS, si lo desea. En este caso, habrá dos servidores CRD activos en la región. Ambos servidores compartirán el mismo repositorio CRD. Tenga en cuenta que CICS emitirá algunos avisos sobre definiciones duplicadas cuando se defina la segunda interfaz en la región.
La información de esta sección describe cómo definir el servidor CRD que utiliza la interfaz RESTful para comunicarse con el cliente de Developer for System z.
Las interfaces RESTful y de servicio Web puede estar activas simultáneamente en una única región CICS, si lo desea. En este caso, habrá dos servidores CRD activos en la región. Ambos servidores compartirán el mismo repositorio CRD. Tenga en cuenta que CICS emitirá algunos avisos sobre definiciones duplicadas cuando se defina la segunda interfaz en la región.
El servidor CRD debe estar definido en la región de conexión primaria. Es la WOR (región propietaria Web) que procesará las peticiones de servicios Web procedentes de Developer for System z.
ADNCSDRS se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
CEDA INSTALL GROUP(ADNPCRGP)
El servidor CRD también se puede usar con una o más regiones de conexión no primarias adicionales, que suelen ser regiones propietarias de aplicación (AOR).
ADNCSDAR se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS.
Transacción | Descripción |
---|---|
ADMS | Para las solicitudes de la herramienta de Proceso de manifiestos para cambiar recursos CICS. Normalmente, está destinado a los administradores de CICS. |
ADMI | Para las peticiones que definen, instalan o desinstalan recursos CICS. |
ADMR | Para las demás peticiones que recuperan información de recursos o de entorno CICS. |
Puede cambiar los ID de transacción para que coincidan con los estándares del local siguiendo estos pasos:
La información de esta sección describe cómo definir el servidor CRD que utiliza la interfaz de servicio Web para comunicarse con el cliente de Developer for System z.
Las interfaces RESTful y de servicio Web puede estar activas simultáneamente en una única región CICS, si lo desea. En este caso, habrá dos servidores CRD activos en la región. Ambos servidores compartirán el mismo repositorio CRD. Tenga en cuenta que CICS emitirá algunos avisos sobre definiciones duplicadas cuando se defina la segunda interfaz en la región.
El manejador de mensajes de conducto (ADNTMSGH) se utiliza para la seguridad, procesando el ID de usuario y la contraseña en la cabecera SOAP. El archivo de configuración de conducto de ejemplo hace referencia a ADNTMSGH, que, por lo tanto, se debe colocar en la concatenación RPL de CICS. Consulte la sección consideraciones de CICSTS para obtener más información acerca del manejador de mensajes de conducto y la configuración de seguridad necesaria.
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Estos ID de transacción se establecen mediante ADNTMSGH, dependiendo de la operación solicitada. Se proporciona código fuente COBOL para permitir personalizaciones específicas del sitio para ADNTMSGH:
Transacción | Descripción |
---|---|
ADMS | Para las solicitudes de la herramienta de Proceso de manifiestos para cambiar recursos CICS. Normalmente, está destinado a los administradores de CICS. |
ADMI | Para las peticiones que definen, instalan o desinstalan recursos CICS. |
ADMR | Para todas las demás peticiones que recuperan información de recursos o de entorno de CICS. |
Utilizando el valor predeterminado:
Personalizando ADNTMSGH:
Los miembros de ejemplo ADNMSGH* se encuentran en FEK.#CUST.JCL y FEK.#CUST.COBOL a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
El servidor CRD debe estar definido en la región de conexión primaria. Es la región que procesará las peticiones de servicio procedentes de Developer for System z.
ADNCSDWS se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
CEDA INSTALL GROUP(ADNPCRGP)
El servidor CRD también se puede usar con una o más regiones de conexión no primarias adicionales, que suelen ser regiones propietarias de aplicación (AOR).
ADNCSDAR se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z permite a los clientes examinar y opcionalmente cambiar manifiestos que describen recursos CICS seleccionados. En función de los permisos establecidos por el administrador de CICS, los cambios pueden realizarse directamente o exportarse al repositorio de manifiestos para que el administrador de CICS los procese con mayor detalle.
Personalice y someta el trabajo ADNVMFST para asignar e inicializar el conjunto de datos VSAM del repositorio de manifiestos y para definirlo en la región de conexión primaria de CICS. Consulte la documentación del miembro para obtener instrucciones de personalización. Debe crearse un repositorio de manifiesto aparte para cada región de conexión primaria CICS. Todos los usuarios necesitan acceso de actualización (UPDATE) al repositorio de manifiestos.
ADNVMFST se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
SCLM Developer Toolkit suministra las herramientas necesarias para ampliar las prestaciones de SCLM para el cliente. SCLM en sí es un gestor de código fuente basado en host-based que se suministra como parte de ISPF.
SCLM Developer Toolkit contiene un plug-in de Eclipse-based que intercambia información con SCLM y proporciona acceso a todos los procesos SCLM para el desarrollo de código de legado, así como soporte para el desarrollo completo de Java y J2EE en la estación de trabajo en sincronización con el SCLM del sistema central, incluidas las tareas de construir, ensamblar y desplegar el código J2EE desde el sistema central.
Necesitará ayuda de un administrador de SCLM y, opcionalmente, de un administrador de seguridad para realizar esta tarea de personalización, que requiere los siguientes recursos y/o tareas de personalización especiales:
A fin de empezar a utilizar SCLM Developer Toolkit en su sitio, debe realizar las tareas siguientes. A menos que se indique de otro modo, todas las tareas son obligatorias.
Consulte Apéndice E. Requisitos para obtener una lista del mantenimiento de SCLM necesario.
Este apéndice también documenta las especificaciones Ant necesarias para construcciones JAVA/J2EE en SCLM Developer Toolkit.
Atención: SCLM Developer Toolkit requiere la utilización de la Pasarela de cliente
TSO/ISPF de ISPF, lo que implica que sea necesario z/OS 1.8 o
posterior. |
Como se describe en Cambios de PARMLIB, SCLM Developer Toolkit requiere una personalización adicional de los valores del sistema. Estos cambios incluyen:
Asimismo, SCLM Developer Toolkit utiliza SDSF o el mandato OUTPUT de TSO para recuperar el estado de finalización de trabajo y la salida del trabajo. Ambos métodos requieren atención adicional:
Los usuarios requieren las autorizaciones de lectura, grabación y ejecución (READ, WRITE y EXECUTE) sobre los directorios de z/OS UNIX /tmp/ y /var/rdz/WORKAREA/. El directorio WORKAREA/ se encuentra en /var/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
SCLM Developer Toolkit utiliza los esqueletos estándar de ISPF/SCLM, por lo que debe asegurarse de que la biblioteca de esqueletos ISP.SISPSLIB se asigne a la concatenación de ISPSLIB en ISPF.conf. La utilización del conjunto de datos ISP.SISPSENU es opcional.
ISPF.conf se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
El ejemplo de código siguiente muestra el archivo ISPF.conf, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por un asterisco (*). Añada los conjuntos de datos a la concatenación en la misma línea y separe los nombres con una coma (,). Consulte ISPF.conf, archivo de configuración de la Pasarela de cliente TSO/ISPF de ISPF para obtener más detalles acerca de la personalización de ISPF.conf.
* OBLIGATORIO: sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB * OPCIONAL: *allocjob = FEK.#CUST.CNTL(CRAISPRX) *ISPF_timeout = 900
ispslib=hlq.USERSKEL,ISP.SISPSLIB
SCLM Developer Toolkit utiliza algunas directivas establecidas en rsed.envvars para localizar conjuntos de datos y directorios.
rsed.envvars se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
El ejemplo de código siguiente muestra las directivas de SCLMDT del archivo rsed.envvars, que debe personalizarse para que coincida con el entorno del sistema. Consulte la sección rsed.envvars, archivo de configuración de RSE para obtener más detalles acerca de la personalización de rsed.envvars.
_SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME
SCLM Developer Toolkit ofrece la posibilidad de almacenar archivos de nombre largo (archivos cuyos nombres superan los 8 caracteres o con mayúsculas/minúsculas mezcladas) en SCLM. Esto se logra mediante la utilización de un archivo VSAM que contiene la correlación del nombre de archivo largo con el nombre de miembro de 8 caracteres utilizado en SCLM.
Personalice y someta el miembro de ejemplo FLM02LST de la biblioteca de ejemplo ISPF ISP.SISPSAMP para crear el archivo VSAM de conversión de nombres largos/abreviados. En los pasos de configuración de esta publicación se espera que el VSAM se denomine FEK.#CUST.LSTRANS.FILE, como se muestra en el JCL de configuración del ejemplo siguiente.
//FLM02LST JOB <parámetros trabajo> //* //* PRECAUCIÓN: esto no es un procedimiento JCL ni un trabajo completo. //* Antes de usar este ejemplo, tendrá que hacer las siguientes //* modificaciones: //* 1. Cambie los parámetros de trabajo para que respondan a los requisitos de su sistema. //* 2. Sustituya ****** por el volumen que contendrá el VSAM. //* 3. Cambie todas las referencias de FEK.#CUST.LSTRANS.FILE para que //* coincidan con el convenio de denominación del VSAM de conversión SCLM. //* //CREATE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE FEK.#CUST.LSTRANS.FILE SET MAXCC=0 DEFINE CLUSTER(NAME(FEK.#CUST.LSTRANS.FILE) - VOLUMES(******) - RECORDSIZE(58 2048) - SHAREOPTIONS(3 3) - CYLINDERS(1 1) - KEYS(8 0) - INDEXED) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.INDEX)) /* DEFINIR ÍNDICE ALTERNATIVO CON CLAVES NO EXCLUSIVAS -> ESDS */ DEFINE ALTERNATEINDEX(- NAME(FEK.#CUST.LSTRANS.FILE.AIX) - RELATE(FEK.#CUST.LSTRANS.FILE) - RECORDSIZE(58 2048) - VOLUMES(******) - CYLINDERS(1 1) - KEYS(50 8) - UPGRADE - NONUNIQUEKEY) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.AIX.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.AIX.INDEX)) /* //* //PRIME EXEC PGM=IDCAMS,COND=(0,LT) //SYSPRINT DD SYSOUT=* //INITREC DD * INITREC1 /* //SYSIN DD * REPRO INFILE(INITREC) - OUTDATASET(FEK.#CUST.LSTRANS.FILE) IF LASTCC = 4 THEN SET MAXCC=0 BLDINDEX IDS(FEK.#CUST.LSTRANS.FILE) - ODS(FEK.#CUST.LSTRANS.FILE.AIX) IF LASTCC = 0 THEN - DEFINE PATH (NAME(FEK.#CUST.LSTRANS.FILE.PATH) - PATHENTRY (FEK.#CUST.LSTRANS.FILE.AIX)) /*
Antes de utilizar la conversión de nombres largos/abreviados, descomente y establezca la variable de entorno de rsed.envvars _SCLMDT_TRANTABLE para que coincida con el nombre del VSAM de conversión de nombres largos/abreviados.
rsed.envvars se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
Este paso sólo es necesario si tiene previsto utilizar el soporte de construcción JAVA/J2EE en SCLM.
Apache Ant es una herramienta de construcción Java Open Source que puede descargarse desde http://ant.apache.org/. Ant consta de archivos de texto distribuidos en formato ASCII y, por tanto, requieren una conversión ASCII/EBCDIC para poder ejecutarse en z/OS UNIX.
Para implementar Ant en z/OS y definirlo en Developer for System z, siga estos pasos:
JAVA_HOME=/usr/lpp/java/IBM/J5.0
ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1
Por ejemplo:
Para comprobar que la inicialización de Ant ha sido satisfactoria:
Ejemplo:
export PATH=/usr/lpp/Apache/Ant/apache-ant-1.7.1/bin:$PATH export PATH=/usr/lpp/java/IBM/J5.0/bin:$PATH
Ejemplo:
ant -version
El propio SCLM también requiere personalización para funcionar con SCLM Developer Toolkit. Consulte la Guía del administrador de IBM Rational Developer for System z SCLM Developer Toolkit, SC11-3815-00 (SC23-9801), para obtener más información acerca de las tareas de personalización necesarias:
Para realizar las tareas de personalización y definición de proyectos, el administrador de SCLM necesita conocer varios valores personalizables de Developer for System z, como se describe en la Tabla 13.
Descripción |
|
Valor |
---|---|---|
Biblioteca de ejemplos de Developer for System z |
|
|
Directorio de ejemplos de Developer for System z |
|
|
Directorio bin Java |
|
|
Directorio bin Ant |
|
|
Directorio inicial WORKAREA |
|
|
Directorio inicial de configuración de proyectos SCLMDT |
|
|
VSAM de conversión de nombres largos/abreviados |
|
SCLM Developer Toolkit y la Pasarela de cliente TSO/ISPF de ISPF comparten la misma WORKAREA, que puede necesitar operaciones de limpieza periódicas. Consulte la sección (Opcional) Limpieza de WORKAREA para obtener más información.
Esta sección combina diversas tareas de personalización opcionales. Siga las instrucciones de la sección adecuada para configurar el servicio que desee.
Necesitará ayuda de un administrador de WLM y de un administrador de DB2 para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
|
Developer para System z suministra un procedimiento almacenado DB2 de ejemplo (Constructor de procedimientos almacenados PL/I y COBOL) para construir procedimientos almacenados COBOL y PL/I desde el cliente Developer para System z.
Utilice los paneles de gestión de la carga de trabajo (WLM) para asociar un entorno de aplicaciones al procedimiento JCL del espacio de direcciones WLM para el constructor de procedimientos almacenados PL/I y COBOL. Consulte la publicación MVS Planning Workload Management (SA22-7602) para obtener información acerca de esta operación.
Personalice la de procedimiento almacenado de ejemplo FEK.#CUST.PROCLIB(ELAXMSAM), tal como se describe dentro del miembro, y cópielo en SYS1.PROCLIB. Como se muestra en el ejemplo de código que figura a continuación, debe suministrar lo siguiente:
//ELAXMSAM PROC RGN=0M, // NUMTCB=1, // APPLENV=#wlmwd4z, // DB2SSN=#ssn, // DB2PRFX='DSN810', // COBPRFX='IGY.V3R4M0', // PLIPRFX='IBMZ.V3R6M0', // LIBPRFX='CEE', // LODPRFX='FEK' //* //DSNX9WLM EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,DYNAMNBR=10, // PARM='&DB2SSN,&NUMTCB,&APPLENV' //STEPLIB DD DISP=SHR,DSN=&DB2PRFX..SDSNEXIT // DD DISP=SHR,DSN=&DB2PRFX..SDSNLOAD // DD DISP=SHR,DSN=&LIBPRFX..SCEERUN // DD DISP=SHR,DSN=&COBPRFX..SIGYCOMP // DD DISP=SHR,DSN=&PLIPRFX..SIBMZCMP //SYSEXEC DD DISP=SHR,DSN=&LODPRFX..SFEKPROC //SYSTSPRT DD SYSOUT=* //CEEDUMP DD SYSOUT=* //SYSABEND DD DUMMY //SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT4 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT5 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT6 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT7 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //*
Personalice y someta el miembro de ejemplo ELAXMJCL del conjunto de datos FEK.#CUST.JCL para definir el procedimiento almacenado en DB2. Consulte la documentación del miembro para obtener instrucciones de personalización.
//ELAXMJCL JOB <job parameters> //JOBPROC JCLLIB ORDER=(#hlq.SDSNPROC) //JOBLIB DD DISP=SHR,DSN=#hlq.SDSNEXIT // DD DISP=SHR,DSN=#hlq.SDSNLOAD //* //RUNTIAD EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN S(#ssn) R(1) T(1) RUN PROGRAM(DSNTIAD) PLAN(DSNTIAD) - LIB('#hlq.RUNLIB.LOAD') //SYSPRINT DD SYSOUT=* //SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMREX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC , IN SQL_ROUTINE_NAME VARCHAR(27) CCSID EBCDIC , IN SQL_ROUTINE_SOURCE VARCHAR(32672) CCSID EBCDIC , IN BIND_OPTIONS VARCHAR(1024) CCSID EBCDIC , IN COMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRECOMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRELINK_OPTIONS VARCHAR(32672) CCSID EBCDIC , IN LINK_OPTIONS VARCHAR(255) CCSID EBCDIC , IN ALTER_STATEMENT VARCHAR(32672) CCSID EBCDIC , IN SOURCE_DATASETNAME VARCHAR(80) CCSID EBCDIC , IN BUILDOWNER VARCHAR(8) CCSID EBCDIC , IN BUILDUTILITY VARCHAR(18) CCSID EBCDIC , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMREX COLLID DSNREXCS WLM ENVIRONMENT ELAXMSAM PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMREX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMREX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMREX TO PUBLIC; //*
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
El cliente de Developer for System z tiene un componente de generación de código denominado Enterprise Service Tools (EST). Dependiendo del tipo de código que se está generando, este código se basa en las funciones proporcionadas por la instalación de host de Developer for System z. Cómo hacer que estas funciones de host estén disponibles se describe en las secciones siguientes:
Necesitará ayuda de un administrador de CICS para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
|
El componente Herramientas de servicio de empresa (EST) de Developer for System z admite diferentes formatos de mensaje de interfaz en árabe y hebreo, así como la presentación y edición de datos bidireccionales en todos los editores y vistas. En las aplicaciones de terminal, se soportan tanto las pantallas de izquierda a derecha como las pantallas de derecha a izquierda, así como los campos numéricos y los campos con orientación opuesta a la pantalla.
Las características y funciones bidireccionales adicionales son las siguientes:
Además, el código generado por EST puede soportar la transformación bidi en entornos distintos de SFR de CICS (Tiempo de ejecución de flujo de servicios). Un ejemplo son las aplicaciones por lotes. Puede hacer que los generadores de EST incluyan llamadas a las rutinas de conversión bidireccional, especificando las opciones de transformación bidi pertinentes en los asistentes de generación de EST y enlazando los programas generados con la biblioteca de conversión bidireccional pertinente, FEK.SFEKLOAD.
Realice las taras siguientes para activar el soporte de idiomas bidireccionales CICS:
CEDA DEF PROG(FEJBDCMP) LANG(LE) G(xxx) CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Esta tarea de personalización no requiere asistencia, pero sí requiere los siguientes recursos o tareas de personalización especiales:
|
El cliente de Developer for System z tiene un componente de generación de código denominado Enterprise Service Tools (EST). Para que el código generado por EST emita mensajes de error de diagnóstico, todos los módulos IRZ* y IIRZ* de la biblioteca de carga FEK.SFEKLOAD deben estar disponibles para el código generado. EST puede generar un código para los siguientes entornos:
Cuando el código generado se ejecuta en una transacción CICS, añada todos los módulos IRZ* y IIRZ* de FEK.SFEKLOAD al DD DFHRPL de la región CICS. Debe hacerlo añadiendo el conjunto de datos de instalación a la concatenación para que el mantenimiento aplicado esté automáticamente disponible para CICS.
En el resto de casos, haga que todos los módulos IRZ* y IIRZ* de FEK.SFEKLOAD estén disponibles, ya sea través de STEPLIB o de LINKLIST. Debe hacerlo añadiendo el conjunto de datos de instalación a la concatenación para que el mantenimiento aplicado esté automáticamente disponible para CICS.
Si decide utilizar STEPLIB, debe definir los módulos no disponibles por medio de LINKLIST en la directiva STEPLIB de la tarea que ejecuta el código.
Si los módulos de carga no están disponibles y el código generado encuentra un error, se emitirá este mensaje:
IRZ9999S No se ha podido recuperar el texto del mensaje de tiempo de ejecución de Language Environment. Compruebe que el módulo del mensaje de tiempo de ejecución de Language Environment para el recurso IRZ está instalado en DFHRPL o STEPLIB.
Necesitará ayuda de un administrador de seguridad para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
|
La comunicación externa (cliente-host) puede cifrarse mediante SSL (Capa de sockets seguros). Esta característica está inhabilita por omisión y está controlada por los valores de ssl.properties.
ssl.properties se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
El cliente se comunica con el daemon RSE durante la configuración de la conexión y con el servidor RSE durante la propia sesión. Las dos secuencias de datos están cifradas cuando la SSL está habilitada.
El daemon RSE y el servidor RSE soportan distintos mecanismos para almacenar certificados debido a las diferencias de su arquitectura. Esto hace que las definiciones SSL sean necesarias tanto para el daemon RSE como para el servidor RSE. Se puede utilizar un certificado compartido si el daemon RSE y el servidor RSE utilizan el mismo método de gestión de certificados.
Almacenamiento de certificados | Creado y gestionado por | daemon RSE | servidor RSE |
---|---|---|---|
anillo de claves | producto de seguridad compatible con SAF | soportado | soportado |
base de datos de claves | gskkyman de z/OS UNIX | soportado | / |
almacén de claves | Keytool de Java | / | soportado |
El daemon RSE utiliza funciones de SSL del sistema para gestionar la SSL. Ello implica que SYS1.SIEALNKE debe estar controlado por programa por su software de seguridad y disponible para RSE a través de la directiva LINKLIST o STEPLIB en rsed.envvars.
El ejemplo de código siguiente muestra el archivo ssl.properties de ejemplo, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado; los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas.
# ssl.properties - Archivo de configuración SSL enable_ssl=false # Propiedades del daemon #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= # Propiedades del servidor #server_keystore_file= #server_keystore_password= #server_keystore_label= #server_keystore_type=JCERACFKS
Las propiedades del daemon y del servidor solo se deben establecer si se habilita SSL. Para obtener más información sobre la configuración de SSL, consulte: Apéndice A. Configurar SSL y autenticación de X.509.
Palabra clave | Tipo de almacén de claves |
---|---|
JKS | Almacén de claves Java |
JCERACFKS | Anillo de claves compatible con SAF, donde la clave privada del certificado se almacena en la base de datos de seguridad. |
JCECCARACFKS | Anillo de claves compatible con SAF, donde la clave privada del certificado se almacena mediante el ICSF, la interfaz al hardware criptográfico de System z. |
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
El archivo resultante será como este:
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
Developer for System z da soporte a diversos niveles de rastreo del flujo de programa interno a efectos de resolución de problemas. RSE y algunos de los servicios a los que llama RSE utilizan los valores de rsecomm.properties para conocer el nivel de detalle deseado en las anotaciones de salida.
Atención: El hecho de cambiar estos valores puede afectar
negativamente al rendimiento, y solo se deben cambiar cuando así
lo indique el centro de soporte de IBM. |
rsecomm.properties se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT.
El ejemplo de código que sigue muestra el archivo rsecomm.properties, que puede personalizar para que coincida con sus necesidades de rastreo. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado; los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas.
# server.version - ¡NO LO MODIFIQUE! server.version=5.0.0 # Nivel de anotaciones # 0 - Mensajes de error de anotaciones # 1 - Mensajes de aviso y de error de anotaciones # 2 - Mensajes informativos, de aviso y de error de anotaciones debug_level=1 # Ubicación de las anotaciones # Log_To_StdOut # Log_To_File log_location=Log_To_File
Los valores válidos son los siguientes:
0 | Anotar sólo mensajes de error. |
1 | Anotar mensajes de error y aviso. |
2 | Anotar mensajes de error, aviso e informativos. |
Los valores válidos son los siguientes:
Log_To_File | Enviar los mensajes de anotaciones a un archivo separado del directorio de salida de anotaciones.
|
Log_To_StdOut | Enviar los mensajes de anotaciones a stdout.
|
daemonlog es el valor de la directiva daemon.log en rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del ID de usuario asignado a la tarea iniciada RSED. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario.
Las anotaciones específicas del usuario van a userlog/.eclipse/RSE/$LOGNAME, donde userlog es el valor de la directiva user.log de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario.
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
Los clientes de Developer for System z pueden definir grupos de propiedades que contienen valores predeterminados para diversas propiedades (por ejemplo, las opciones de compilador COBOL que deben utilizarse al compilar código fuente COBOL). Developer for System z tiene algunos valores predeterminados incorporados, pero también permite definir valores predeterminados personalizados específicos del sistema.
La ubicación de los archivos de configuración de valores predeterminados y grupos de propiedades personalizadas se define en propertiescfg.properties, que se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP) . Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
El ejemplo de código siguiente muestra el archivo propertiescfg.properties, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado. Los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas.
# # grupos de propiedades basadas en host - archivo de configuración raíz # ENABLED=FALSE RDZ-VERSION=7.5.0.0 PROPERTY-GROUP=/var/rdz/properties DEFAULT-VALUES=/var/rdz/properties
Consulte Developer for System z Information Center (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para obtener más información acerca de la creación del archivo de configuración de grupos de propiedades (propertygroups.xml) y del archivo de configuración de valores predeterminados (defaultvalues.xml).
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
Los proyectos de z/OS se pueden definir individualmente mediante la perspectiva Proyectos z/OS en el cliente, pero también se pueden definir centralmente en el host y propagarse al cliente para cada usuario. Estos "proyectos basados en host" se parecen y funcionan exactamente igual que los proyectos definidos en el cliente, salvo que el cliente no puede modificar su estructura, sus miembros ni sus propiedades, y solo se puede acceder a ellos cuando se está conectado al host.
La ubicación de las definiciones de proyecto se define en projectcfg.properties, que se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP) . Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
El ejemplo de código siguiente muestra el archivo projectcfg.properties, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado. Los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas.
# # proyectos basados en host - archivo de configuración raíz # # WSED-VERSION - ¡no la modifique! WSED-VERSION=7.0.0.0 # Especifique la ubicación de los archivos de definición de los proyectos basados en host PROJECT-HOME=/var/rdz/projects
Consulte Developer for System z Information Center (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para obtener más información sobre los proyectos basados en host.
Necesitará ayuda de un administrador de seguridad para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
|
Developer for System z admite el acceso directo desde el cliente a un conjunto limitado de funciones de IBM File Manager para z/OS. IBM File Manager para z/OS proporciona herramientas completas para trabajar con conjuntos de datos MVS, archivos z/OS UNIX y datos DB2, IMS y CICS. Estas herramientas incluyen los programas de utilidad habituales para examinar, editar, copiar e imprimir existentes en ISPF, mejoradas para responder a las necesidades de los desarrolladores de aplicaciones. En la versión actual de Developer for System z, sólo están permitidos los programas de utilidad para examinar y editar conjuntos de datos MVS (incluidos todos los tipo de VSAM), crear y editar plantillas de conjuntos de datos MVS (incluidas las plantillas dinámicas), y copiar con opciones avanzadas.
Tenga en cuenta que el producto IBM File Manager para z/OS se debe pedir, instalar y configurar por separado. Consulte Rational Developer for System z Prerrequisitos (SC23-7659) para saber qué nivel del gestor de archivos se necesita para su versión de Developer for System z. La instalación y la personalización de este producto no se describe en este manual.
Tenga en cuenta que ni Developer for System z ni el Gestor de archivos soportan la interfaz por lotes para acceder a los servicios del gestor de archivos. Ahora es necesario utilizar la escucha del Gestor de archivos.
Las definiciones de la integración del gestor de archivos que necesita Developer for System z se almacenan en FMIEXT.properties, que se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor.
El ejemplo de código siguiente muestra el archivo FMIEXT.properties, que debe personalizarse para que coincida con el entorno del sistema. Las líneas de comentarios empiezan por el signo de almohadilla (#) cuando se utiliza una página de códigos de EE.UU. Las líneas de datos solamente pueden tener una directiva y su valor asignado. Los comentarios no pueden estar en la misma línea. Las continuaciones de línea no están soportadas.
# Propiedades de la extensión Integración del gestor de archivos (FMI) # enabled=false fmlistenport=1960
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
Algunos caracteres no se convierten correctamente entre las páginas de códigos del host (basadas en EBCDIC) y las páginas de códigos del cliente (basadas en ASCII). El editor del cliente de Developer for System z utiliza las definiciones del archivo uchars.settings para identificar estos caracteres no editables. Cuando abre un conjunto de datos con un carácter identificado en uchars.settings, el editor impondrá la modalidad de sólo lectura para evitar que se dañe el conjunto de datos cuando se guarda.
El archivo uchars.settings se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización. Puede editar el archivo con el mandato TSO OEDIT. Tenga en cuenta que RSE debe reiniciarse para que los cambios entren en vigor. Tenga en cuenta también que no es aconsejable cambiar este archivo, a menos que lo indique el centro de soporte de IBM.
# uchars.settings - puntos de código no editables # * * 0D 15 25; # DBCS (japonés, coreano y chino) IBM-930 * 0D 15 1E 1F 25; IBM-933 * 0D 15 1E 1F 25; IBM-935 * 0D 15 1E 1F 25; IBM-937 * 0D 15 1E 1F 25; IBM-939 * 0D 15 1E 1F 25; IBM-1390 * 0D 15 1E 1F 25; IBM-1399 * 0D 15 1E 1F 25; IBM-1364 * 0D 15 1E 1F 25; IBM-1371 * 0D 15 1E 1F 25; IBM-1388 * 0D 15 1E 1F 25; # UNICODE UTF-8 * 0D 0A; UTF-16BE * 0D 0A; UTF-16LE * 0D 0A; UTF-16 * 0D 0A;
El archivo consta de varias entradas, con el formato siguiente:
PÁGINACÓDIGOS-HOST PÁGINACÓDIGOS-LOCAL PUNTOSCÓDIGO-HEX ;
Donde PUNTOSCÓDIGO-HEX es una lista delimitada por espacios en blanco de puntos de código hexadecimales de 2 dígitos que identifican los caracteres no editables. La lista debe terminar con un signo de punto y coma (;).
Se aplican las siguientes normas de sintaxis:
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
REXEC (Ejecución remota) es un servicio TCP/IP que permite a los clientes ejecutar un mandato en el host. SSH (Shell segura) es un servicios similar, pero en él toda la comunicación se cifra mediante SSL (Capa de sockets seguros). Developer for System z utiliza cualquiera de los servicios para realizar acciones remotas (basadas en host) en subproyectos z/OS UNIX.
Developer for System z también puede configurarse para utilizar REXEC (o SSH) para iniciar un servidor RSE en el host. Sin embargo, tenga en cuenta que cada conexión iniciada de ese modo generará un servidor RSE independiente, cada uno de los cuales utilizará una cantidad considerable de recursos del sistema. Por tanto, este método de conexión alternativo sólo es viable para un pequeño número de conexiones.
Asimismo, dado que el método de conexión alternativo REXEC (o SSH) pasa por alto el daemon RSE, no tiene acceso a todos los servicios de host descritos en esta publicación, como por ejemplo el proceso y auditoría de servidor único. Póngase en contacto con el servicio de soporte de IBM para saber si un servicio de host determinado está soportado por el método de conexión alternativo REXEC.
Para las acciones remotas (basadas en host) de los subproyectos z/OS UNIX, es necesario que REXEC o SSH esté activo en el host. Si REXEC/SSH no está configurado para utilizar el puerto predeterminado, el cliente Developer for System z debe definir el puerto correcto que deben utilizar los subproyectos z/OS UNIX. Para ello, se selecciona la página de preferencias Ventana > >Preferencias... > z/OS Solutions > Subproyectos USS > Opciones de acción remota. Consulte la sección Configuración de REXEC (o SSH) para saber qué puerto se utiliza.
Los clientes de Developer for System z deben conocer dos valores para poder iniciar una conexión RSE a través de REXEC (o SSH):
server.zseries se encuentra en /etc/rdz/, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
cp /usr/lpp/rdz/bin/server.zseries /etc/rdz
Consulte la sección Configuración de REXEC (o SSH) para saber qué puerto se utiliza.
La publicación Communications Server IP Configuration Guide (SC31-8775) describe los pasos necesarios para configurar REXEC (o SSH). Consulte la sección Apéndice C. Configurar INETD para obtener consideraciones de configuración específicas de Developer for System z (no hay pasos de configuración específicos de Developer for System z).
Un puerto común utilizado por REXEC es el 512. Para verificarlo, puede comprobar /etc/inetd.conf y /etc/services para localizar el número de puerto que se emplea.
exec stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV
exec 512/tcp #REXEC Command Server
Este mismo principio es válido para SSH. Su puerto común es el 22, y el nombre de servicio es sshd.
Necesitará ayuda de un administrador de APPC y de un administrador de WLM para realizar esta tarea de personalización, que requiere los siguientes recursos o tareas de personalización especiales:
|
El servicio de mandatos TSO puede implementarse como un programa de transacción APPC, FEKFRSRV. Esta transacción actúa como servidor de hospedaje para ejecutar los mandatos TSO que se emiten desde la estación de trabajo. No se necesita APPC en la estación de trabajo, porque el cliente se comunica con FEKFRSRV por RSE. Cada cliente puede tener una conexión activa con múltiples hosts al mismo tiempo.
/* Administración de REXX -- APPC utilizando paneles ISPF */ address ISPEXEC "LIBDEF ISPMLIB DATASET ID('ICQ.ICQMLIB') STACK" "LIBDEF ISPPLIB DATASET ID('ICQ.ICQPLIB') STACK" "LIBDEF ISPSLIB DATASET ID('ICQ.ICQSLIB') STACK" "LIBDEF ISPTLIB DATASET ID('ICQ.ICQTLIB') STACK" address TSO "ALTLIB ACT APPLICATION(CLIST)", "DSN('ICQ.ICQCCLIB') UNCOND QUIET" "SELECT CMD(%ICQASRM0) NEWAPPL(ICQ) PASSLIB" address TSO "ALTLIB DEACT APPLICATION(CLIST) QUIET" "LIBDEF ISPMLIB" "LIBDEF ISPPLIB" "LIBDEF ISPSLIB" "LIBDEF ISPTLIB" exit
Conocimientos técnicos | Información necesaria:
|
Valor |
---|---|---|
APPC | Nombre de conjunto de datos de TPDATA
|
|
APPC | Nombre de transacción que hay que usar (puede no existir)
|
|
APPC | Clase de transacción APPC que hay que usar
|
|
WLM/SRM | Grupo de rendimiento TSO y dominio
|
|
RACF | Cada usuario de Developer for System z tiene acceso a un segmento OMVS
(es necesario)
|
|
RACF | Cada usuario de Developer for System z debe tener acceso de lectura (READ) a hlq.SFEKPROC(FEKFRSRV)
|
Consulte la publicación MVS Planning Workload Management (SA22-7602) para obtener más información acerca de la gestión de WLM/SRM. Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de los segmentos OMVS y los perfiles de protección de conjuntos de datos.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
Puede probar la configuración de TCP/IP iniciando el daemon RSE con el parámetro IVP=IVP o con el programa de verificación de la instalación (IVP) fekfivpt, como se ha descrito en Verificación de la instalación.
Esta tarea de personalización no requiere asistencia, recursos especiales ni tareas de personalización especiales. |
Las funciones de Pasarela de cliente TSO/ISPF de ISPF y SCLM Developer Toolkit utilizan el directorio WORKAREA para almacenar archivos de trabajo temporales, que se eliminan antes de cerrar la sesión. Sin embargo, a veces queda salida temporal, por ejemplo, si se produce un error de comunicación durante el proceso. Por esta razón, es aconsejable limpiar el directorio WORKAREA de vez en cuando.
z/OS UNIX suministra un script de shell, skulker, que suprime los archivos en función del directorio en el que se encuentran y de su utilización. En combinación con el daemon cron de z/OS UNIX, que ejecuta mandatos en fechas y horas especificadas, puede configurar una herramienta automatizada que limpie periódicamente el directorio WORKAREA. Consulte la publicación UNIX System Services Command Reference (SA22-7802) para obtener más información acerca del script skulker y el daemon cron.
Después de completar la personalización del producto, puede utilizar los Programas de verificación de la instalación (IVP) descritos en este capítulo para verificar la configuración satisfactoria de componentes de productos clave.
Inicie la tarea iniciada JMON (o el trabajo de usuario). La información de inicio de STDOUT de DD debe finalizar con este mensaje:
JM200I Inicialización del servidor completada.
Si el trabajo finaliza con el código de retorno 66, sabrá que FEK.SFEKAUTH no está autorizada por APF.
Inicie la tarea iniciada LOCKD (o el trabajo de usuario). El daemon de bloqueo emite el siguiente mensaje de consola cuando el inicio se realiza correctamente:
FEK501I Daemon de bloqueo iniciado, puerto=4036, intervalo de limpieza=1440, nivel de anotaciones=1
Inicie la tarea iniciada RSED (o el trabajo de usuario) con el parámetro IVP=IVP. Con este parámetro, el servidor finalizará después de realizar algunas pruebas de verificación de la instalación. La salida de estas pruebas está disponible en STDOUT de DD. En caso de errores, también habrá datos disponibles en STDERR de DD. Los datos de STDOUT deben ser similares a los del ejemplo siguiente:
FEK002I Daemon RSE iniciado. (puerto=4035)
Prueba IVP del daemon RSE Wed Jul 2 17:11:52 2008 UTC uid=8(STCRSE) gid=1(STCGROUP) El puerto del daemon RSE es 4035 Archivos de configuración de RSE ubicados en /etc/rdz ------------------------------------------------------------- variables de entorno actuales ------------------------------------------------------------- @="/usr/lpp/rdz/bin/rsed.sh" @[1]="4035" @[2]="/etc/rdz" CGI_DTCONF="/var/rdz/sclmdt" CGI_DTWORK="/var/rdz" CGI_TRANTABLE="FEK.#CUST.LSTRANS.FILE" CLASSPATH=".:/usr/lpp/rdz/lib:/usr/lpp/rdz/lib/dstore_core.jar:/usr/lpp/ ERRNO="0" HOME="/tmp" IFS=" " JAVA_HOME="/usr/lpp/java/J5.0" JAVA_PROPAGATE="NO" LANG="C" LIBPATH=".:/usr/lib:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/classi LINENO="66" LOGNAME="STCRSE" MAILCHECK="600" OLDPWD="/tmp" OPTIND="1" PATH=".:/usr/lpp/java/J5.0/bin:/usr/lpp/rdz/bin:/usr/lpp/ispf/bin:/bin:/ PPID="33554711" PS1="\$ " PS2="> " PS3="#? " PS4="+ " PWD="/etc/rdz" RANDOM="27298" RSE_CFG="/etc/rdz" RSE_HOME="/usr/lpp/rdz" RSE_LIB="/usr/lpp/rdz/lib" SECONDS="0" SHELL="/bin/sh" STEPLIB="NONE" TZ="EST5EDT" _BPX_SHAREAS="YES" _BPX_SPAWN_SCRIPT="YES" _CEE_DMPTARG="/tmp" _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CMDSERV_BASE_HOME="/usr/lpp/ispf" _CMDSERV_CONF_HOME="/etc/rdz" _CMDSERV_WORK_HOME="/var/rdz" _RSE_CMDSERV_OPTS="&SESSION=SPAWN" _RSE_DAEMON_CLASS="com.ibm.etools.zos.server.RseDaemon" _RSE_DAEMON_IVP_TEST="1" _RSE_DAEMON_PORT="4035" _RSE_JAVAOPTS=" -DISPF_OPTS='&SESSION=SPAWN' -DA_PLUGIN_PATH=/usr/lpp/rd _RSE_POOL_SERVER_CLASS="com.ibm.etools.zos.server.ThreadPoolProcess" _RSE_PWD="/tmp" _RSE_SERVER_CLASS="org.eclipse.dstore.core.server.Server" _RSE_SERVER_TIMEOUT="120000" _SCLMDT_BASE_HOME="/usr/lpp/rdz" _SCLMDT_CONF_HOME="/var/rdz/sclmdt" _SCLMDT_TRANTABLE="FEK.#CUST.LSTRANS.FILE" _SCLMDT_WORK_HOME="/var/rdz" _SCLM_BASE="/var/rdz/WORKAREA" _SCLM_BWBCALL="/usr/lpp/rdz/bin/BWBCALL" _SCLM_DWGET="/var/rdz/WORKAREA" _SCLM_DWTRANSFER="/var/rdz/WORKAREA" _SCLM_J2EEPUT="/var/rdz/WORKAREA" ------------------------------------------------------------- prueba de inicio java... ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-2008031 IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-2008 J9VM - 20080314_17962_bHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 ------------------------------------------------------------- pruebe IVP de TCP/IP... ------------------------------------------------------------- Wed Jul 2 13:11:54 EDT 2008 uid=8(STCRSE) gid=1(STCGROUP) using /etc/rdz/rsed.envvars ------------------------------------------------------------- configuración del resolviente TCP/IP (orden de búsqueda de z/OS UNIX): ------------------------------------------------------------- Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964 Valores de resolviente res_init: Conjunto de datos Tcp/Ip global = Ninguno Conjunto de datos Tcp/Ip predeterminado = Ninguno Conjunto de datos Tcp/Ip local = /etc/resolv.conf Tabla de conversión = Predeterminada IDusuario/NombreTrabajo = STCRSE API llamante = LE C Sockets Modalidad llamante = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Satisfactoria res_init Iniciada: 2008/07/02 13:11:54.755363 res_init Finalizada: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 Nombre TCPIP: TCPIP 13:11:54 Tcpip iniciado a las 01:28:36 el 06/23/2008 con IPv6 habilitado ------------------------------------------------------------- dirección IP del host: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Satisfactorio, coincidencia de direcciones ------------------------------------------------------------- Prueba IVP de PassTicket... ------------------------------------------------------------- Satisfactorio, el IVP de PassTicket ha finalizado con normalidad ------------------------------------------------------------- IVP de daemon RSE finalizado
La instalación de Developer for System z proporciona varios programas de verificación de la instalación (IVP) para los servicios básicos y opcionales. Los scripts de los IVP se encuentran en el directorio de instalación, que es /usr/lpp/rdz/bin/ por omisión.
fekfivpa | (Opcional) Conexión del servicio de mandatos TSO mediante APPC |
fekfivpd | Conexión del daemon RSE |
fekfivpi | Conexión de la Pasarela de cliente TSO/ISPF de ISPF |
fekfivpj | Conexión del Supervisor de trabajos JES |
fekfivpl | Conexión del daemon de bloqueo |
fekfivpr | (Opcional) Conexión REXEC |
fekfivps | (Opcional) Conexión SCLMDT |
fekfivpt | Configuración de TCP/IP |
fekfivpz | (Opcional) Script de shell REXEC/SSH |
En las tareas que se describen a continuación, se espera que esté activo en z/OS UNIX. Para ello, emita el mandato TSO OMVS. Utilice el mandato exit para volver a TSO.
El ID de usuario que ejecuta los IVP necesita un tamaño de región grande, ya que se ejecutarán funciones que necesitan mucha memoria, tales como Java. Debe establecer el tamaño de región en 131072 kilobytes (128 megabytes) o superior.
El siguiente error de ejemplo es una indicación clara de un tamaño de región insuficiente. (Pero también pueden producirse otros errores. Por ejemplo, que no se puede iniciar Java.)
CEE5213S Se ha recibido la señal SIGPIPE. %mandato de z/OS UNIX%: el número de serie 13 ha desactivado el mandato %número-línea% *-* %mandato REXX% +++ RC(137) +++
Para todos los mandatos de ejemplo de esta sección se espera que estén establecidas determinadas variables de entorno. De ese modo, los scripts del IVP están disponibles mediante la sentencia PATH, y se conoce la ubicación de los archivos de configuración personalizados. Utilice los mandatos pwd y cd para verificar y cambiar el directorio actual por el directorio que contiene los archivos de configuración personalizados. Luego se puede utilizar el script de shell ivpinit para establecer las variables de entorno de RSE, como en el ejemplo que sigue ($ es el indicador de z/OS UNIX):
$ pwd /u/userid $ cd /etc/rdz $ . ./ivpinit Archivos de configuración de RSE ubicados en /etc/rdz - valor predeterminado /usr/lpp/rdz/bin añadido a PATH
El primer punto "." de . ./ivpinit es un mandato z/OS UNIX que ejecuta la shell en el entorno actual, para que las variables de entorno establecidas en la shell estén en vigor incluso después de salir de la shell. El segundo punto hace referencia al directorio actual.
/usr/lpp/rdz/bin/fekfivpr 512 USERIDAsimismo, la mayoría de los scripts fekfivp* solicitarán la ubicación del archivo rsed.envvars personalizado si . ./ivpinit no se ejecuta en primer lugar.
$ EXPORT STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Tenga en cuenta que al añadir una biblioteca sin autorización APF a un STEPLIB existente se elimina la autorización APF de los conjuntos de datos STEPLIB existentes.
Tenga también en cuenta que si CEE.SCEELKED está en LINKLIST o STEPLIB, TCPIP.SEZALOAD debe colocarse antes de CEE.SCEELKED. Si no lo hace, se producirá una terminación anormal del sistema 0C1 para las llamadas de socket REXX de TCP/IP.
Para obtener información sobre cómo diagnosticar los problemas de conexión del RSE, consulte la sección Resolución de problemas de configuración o las fichas técnicas de la página de soporte de Developer for System z, http://www-306.ibm.com/software/awdtools/rdz/support/.
La disponibilidad del supervisor de trabajos JES, del daemon RSE y, opcionalmente, de REXEC o puerto SSH se puede verificar emitiendo el mandato netstat. El resultado debe mostrar los puertos empleados por estos servicios, como en los siguientes ejemplos ($ es el indicador de z/OS UNIX):
IPv4
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Nombre TCPIP: TCPIP 13:57:36 ID us. Conexión Socket Local Socket Foráneo Estado ------- ---- ------------ -------------- ----- RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Escucha LOCKD 0000004C 0.0.0.0..4036 0.0.0.0..0 Escucha JMON 00000037 0.0.0.0..6715 0.0.0.0..0 Escucha
IPv6
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Nombre TCPIP: TCPIP 14:03:35 ID usuario Conexión Estado ------- ---- ----- RSED 0000004B Escucha Socket local: 0.0.0.0..4035 Socket foráneo: 0.0.0.0..0 LOCKD 0000004C Escucha Socket local: 0.0.0.0..4036 Socket foráneo: 0.0.0.0..0 JMON 00000037 Escucha Socket local: 0.0.0.0..6715 Socket foráneo: 0.0.0.0..0
Al utilizar APPC para el servicio de mandatos TSO, Developer for System z depende de que TCP/IP tenga el nombre de host correcto cuando se inicializa. Ello implica que los distintos archivos de configuración de TCP/IP y del resolviente estén configurados correctamente. Hallará más información sobre la configuración de TCP/IP y el resolviente en la sección Apéndice B. Configurar TCP/IP. Verifique los valores actuales ejecutando el siguiente mandato:
fekfivpt
El mandato debe devolver datos de salida parecidos a los de este ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpt Wed Jul 2 13:11:54 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- configuración del resolviente TCP/IP (orden de búsqueda de z/OS UNIX): ------------------------------------------------------------- Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964 Valores de resolviente res_init: Conjunto de datos Tcp/Ip global = Ninguno Conjunto de datos Tcp/Ip predeterminado = Ninguno Conjunto de datos Tcp/Ip local = /etc/resolv.conf Tabla de conversión = Predeterminada IDusuario/NombreTrabajo = USERID API llamante = LE C Sockets Modalidad llamante = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Satisfactoria res_init Iniciada: 2008/07/02 13:11:54.755363 res_init Finalizada: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 Nombre TCPIP: TCPIP 13:11:54 Tcpip iniciado a las 01:28:36 el 06/23/2008 con IPv6 habilitado ------------------------------------------------------------- dirección IP del host: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Satisfactorio, coincidencia de direcciones
Verifique la conexión del daemon RSE ejecutando el siguiente mandato. Donde pone 4035, escriba el puerto que utiliza el daemon RSE, y donde pone USERID, escriba un ID de usuario válido.
fekfivpd 4035 USERID
Después de solicitarle una contraseña, el mandato debe devolver datos de salida como los que aparecen en el ejemplo siguiente ($ es el indicador de z/OS UNIX):
$ fekfivpd 4035 USERID Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) Contraseña: SSL está inhabilitado conectado 8108 570655399 Éxito
Verifique la conexión del supervisor de trabajos JES ejecutando el siguiente mandato. Donde pone 6715, escriba el número de puerto del supervisor de trabajos JES.
fekfivpj 6715
El mandato debe devolver el mensaje de acuse de recibo del supervisor de trabajos JES, como en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpj 6715 Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 En espera de una respuesta del supervisor de trabajos JES... ACKNOWLEDGE01v03 Éxito
Verifique la conexión del daemon de bloqueo ejecutando el siguiente mandato.
fekfivpl
El mandato debe devolver datos de salida parecidos a los de este ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpl Lun 29 Jun 08:00:38 EDT 2009 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 Registrando usuario en el Daemon de bloqueo... En espera de una respuesta del daemon de bloqueo... Consultando en el Daemon de bloqueo... En espera de una respuesta del daemon de bloqueo... USERID Desregistrando usuario del Daemon de bloqueo... En espera de una respuesta del daemon de bloqueo... Consultando en el Daemon de bloqueo... En espera de una respuesta del daemon de bloqueo... Éxito
Verifique la conexión establecida con la Pasarela de cliente TSO/ISPF de ISPF emitiendo el mandato siguiente:
fekfivpi
El mandato debe devolver el resultado de las comprobaciones relacionadas con la Pasarela de cliente TSO/ISPF de ISPF (variables, módulos HFS, iniciar y detener la sesión TSO/ISPF), como en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpi Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- contenido de /etc/rdz/ISPF.conf: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Verificación de la instalación de host para RSE Revise los mensajes de anotaciones de IVP procedentes del HOST, a continuación: ------------------------------------------------------------- Solo comprobación de inicialización de sesión TSO/ISPF base y conexión RSE *** COMPROBACIÓN : VARIABLES DE ENTORNO - variables clave visualizadas más abajo: Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz ------------------------------------------------------------- *** CHECK : USS MODULES Comprobando directorio de ISPF : /usr/lpp/ispf Comprobando módulos en el directorio /usr/lpp/ispf/bin directory Comprobando el archivo de configuración de ISPF ISPF.conf RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** COMPROBACIÓN : INICIALIZACIÓN DE TSO/ISPF ( La sesión TSO/ISPF se inicializará ) RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** COMPROBACIÓN: Cerrando sesión IVP de TSO/ISPF RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- La verificación de la instalación de host se ha realizado satisfactoriamente -------------------------------------------------------------
fekfivpi tiene los siguientes parámetros opcionales que no dependen de la posición:
Verifique la conexión establecida con el servidor de mandatos TSO (utilizando APPC), emitiendo el siguiente mandato. Sustituya IDUSUARIO por un ID de usuario válido:
fekfivpa USERID
Después de solicitarle una contraseña, el mandato debe devolver la conversación APPC, como en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpa USERID Teclee la contraseña: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) 20070607 13:57:18.584060 /usr/lpp/rdz/bin/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.586800 APPC: Allocate succeeded 20070607 13:57:18.587022 Conversation id is 0DDBD3F80000000D 20070607 13:57:18.587380 APPC: Set Send Type succeeded 20070607 13:57:26.736674 APPC: Confirm succeeded 20070607 13:57:26.737027 Req to send recd value is 0 20070607 13:57:26.737546 APPC: SEND_DATA return_code = 0 20070607 13:57:26.737726 request_to_send_received = 0 20070607 13:57:26.737893 Send Data succeeded 20070607 13:57:26.738169 APPC: Set Prepare to Receive type succeeded 20070607 13:57:26.738580 APPC: Prepare to Receive succeeded 20070607 13:57:26.808899 APPC: Receive data 20070607 13:57:26.809122 RCV return_code = 0 20070607 13:57:26.809270 RCV data_received= 2 20070607 13:57:26.809415 RCV received_length= 29 20070607 13:57:26.809556 RCV status_received= 4 20070607 13:57:26.809712 RCV req_to_send= 0 20070607 13:57:26.809868 Receive succeeded :IP: 0 9.42.112.75 1674 50246 20070607 13:57:26.810533 APPC: CONFIRMED succeeded
Verifique la conexión establecida con SCLM Developer Toolkit emitiendo el mandato siguiente:
fekfivps
El mandato debe devolver el resultado de las comprobaciones relacionadas con SCLM Developer Toolkit (variables, módulos HFS, entorno de ejecución REXX, iniciar y detener la sesión TSO/ISPF), como en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivps Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- contenido de /etc/rdz/ISPF.conf: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Verificación de la instalación de host para RSE Revise los mensajes de anotaciones de IVP procedentes del HOST, a continuación: ------------------------------------------------------------- *** COMPROBACIÓN : VARIABLES DE ENTORNO - variables clave visualizadas más abajo: Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz _SCLMDT_CONF_HOME = /var/rdz/sclmdt _SCLMDT_WORK_HOME = /var/rdz _SCLMDT_TRANTABLE = FEK.#CUST.LSTRANS.FILE ------------------------------------------------------------- *** CHECK : JAVA PATH SETUP VERIFICATION RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** CHECK : USS MODULES Comprobando directorio de ISPF: /usr/lpp/ispf Comprobando módulos en el directorio /usr/lpp/ispf/bin Comprobando el archivo de configuración de ISPF ISPF.conf Comprobando directorio bin de instalación : /usr/lpp/rdz/bin RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** COMPROBACIÓN : ENTORNO DE TIEMPO DE EJECUCIÓN REXX RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** COMPROBACIÓN : INICIALIZACIÓN DE TSO/ISPF ( La sesión TSO/ISPF se inicializará ) RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- *** COMPROBACIÓN: Cerrando sesión IVP de TSO/ISPF RC=0 MSG: SATISFACTORIO ------------------------------------------------------------- La verificación de la instalación de host se ha realizado satisfactoriamente -------------------------------------------------------------
fekfivps tiene los siguientes parámetros opcionales que no dependen de la posición:
Verifique la conexión REXEC ejecutando el siguiente mandato. Donde pone 512, escriba el puerto que utiliza REXEC, y donde pone USERID, escriba un ID de usuario válido.
fekfivpr 512 USERID
Después de solicitarle una contraseña, el mandato debe devolver el rastreo REXEC, un aviso de tiempo de espera, la versión de Java y el mensaje del servidor RSE, como en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpr 512 USERID Teclee la contraseña: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) $ EZYRC01I Llamando a la función rexec_af con: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/rdz;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Socket de datos = 4, Socket de control = 6. Prueba IVP del servidor RSE CDFMVS08 -- Mie 2 Jul 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) Archivos de configuración de RSE ubicados en /etc/rdz --valor predeterminado El ID de usuario de RSE es USERID --valor predeterminado ------------------------------------------------------------- Límites de tamaño del espacio de direcciones ------------------------------------------------------------- el límite de tamaño del espacio de direcciones actual es 2147483647 (2048.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- historial de servicio ------------------------------------------------------------- Vie 19 Jun 00:01:00 2009 -- COPY -- HHOP760 v7600 creado 18 Jun 2009 ------------------------------------------------------------- se esperan mensajes de tiempo de espera tras una prueba de IVP satisfactoria ------------------------------------------------------------- iniciando servidor RSE en el fondo -- Vie 19 Jun 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Servidor DStore iniciándose... El servidor se ha iniciado satisfactoriamente 8108 El servidor se ejecuta en: CDFMVS08
Error de conexión Servidor: error al inicializar el socket: java.net.SocketTimeoutException: La aceptación ha agotado el tiempo de espera
Es posible saltarse esta prueba de IVP si la prueba anterior (descrita someramente en: (Opcional) Conexión REXEC) se llevó a cabo satisfactoriamente.
Verifique el script de shell utilizado por la conexión REXEC y SSH, ejecutando el mandato:
fekfivpz
El mandato debe devolver un aviso de tiempo de espera, la versión de Java y el mensaje del servidor RSE, como en el ejemplo que sigue ($ es el indicador de z/OS UNIX):
$ fekfivpz Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars el límite de tamaño del espacio de direcciones actual es 1914675200 (1826.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- Prueba IVP del servidor RSE CDFMVS08 -- Mie 2 Jul 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) Archivos de configuración de RSE ubicados en /etc/rdz - valor predeterminado El ID de usuario de RSE es USERID --valor predeterminado ------------------------------------------------------------- Límites de tamaño del espacio de direcciones ------------------------------------------------------------- el límite de tamaño del espacio de direcciones actual es 2147483647 (2048.0 MB) el límite de tamaño del espacio de direcciones máximo es 2147483647 (2048.0 MB) ------------------------------------------------------------- historial de servicio ------------------------------------------------------------- Vie 19 Jun 00:01:00 2009 -- COPY -- HHOP760 v7600 creado 18 Jun 2009 ------------------------------------------------------------- se esperan mensajes de tiempo de espera tras una prueba de IVP satisfactoria ------------------------------------------------------------- iniciando servidor RSE en el fondo -- Vie 19 Jun 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Servidor DStore iniciándose... El servidor se ha iniciado satisfactoriamente 8108 El servidor se ejecuta en: CDFMVS08
Error de conexión Servidor: error al inicializar el socket: java.net.SocketTimeoutException: La aceptación ha agotado el tiempo de espera
Este capítulo ofrece una visión general de los mandatos de operador (o consola) disponibles para Developer for System z. Consulte la sección Cómo leer un diagrama de sintaxis si no está familiarizado con los diagramas de sintaxis utilizados para describir el formato de los mandatos.
Utilice el mandato Iniciar (START) para iniciar dinámicamente una tarea iniciada (STC). La versión abreviada del mandato es la letra S.
El mandato Modificar (MODIFY) permite consultar y cambiar dinámicamente las características de una tarea activa. La versión abreviada del mandato es la letra F.
<IDcliente> : <IDusuario> : <conectado desde>
ProcessId(<IDproceso>) Memory Usage(<utilizacón almacenamiento dinámico java>%) Clients(<número de clientes>) Order(<orden de inicio>) <estado de error>
En los casos normales, <estado de error> aparece en blanco. Tabla 18 documenta los posibles valores que no estén en blanco para el <estado de error>.
Estado | Descripción |
---|---|
*error grave* | El proceso de agrupaciones de hebras ha encontrado un error no recuperable y ha interrumpido las operaciones. El resto de campos de estado muestran los últimos valores conocidos. Utilice la opción CLEANUP del mandato de modificación DISPLAY PROCESS para eliminar esta entrada de la tabla. |
*proceso desactivado* | Java, z/OS UNIX o un mandato de operador ha desactivado el proceso de agrupaciones de hebras. El resto de campos de estado muestran los últimos valores conocidos. Utilice la opción CLEANUP del mandato de modificación DISPLAY PROCESS para eliminar esta entrada de la tabla. |
*tiempo de espera* | El proceso de agrupaciones de hebras no ha respondido a tiempo al daemon RSE durante una petición de conexión de cliente. El resto de campos de estado muestran los últimos valores conocidos. La agrupación de hebras queda excluida de futuras peticiones de conexión de clientes. El estado *tiempo de espera* se restablece cuando un cliente que se sirve de esta agrupación de hebras finaliza la sesión. |
Cuando se utiliza la opción DETAIL del mandato de modificación DISPLAY PROCESS, se proporciona más información:
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1) PROCESS LIMITS: CURRENT HIGHWATER LIMIT JAVA HEAP USAGE(%) 10 56 100 CLIENTS 0 25 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
El campo ASId es el ID de espacio de direcciones en notacione hexadecimal. La tabla de límites de proceso muestra la utilización de recursos actual, la marca de límite superior de la utilización de recursos y el límite de recursos. Fíjese en que, debido a otros factores de limitación, es posible que nunca se alcance el límite definido.
E o 0 u OFF | Sólo mensajes de error. |
W o 1 | Mensajes de error y aviso. Este es el valor predeterminado de rsecomm.properties. |
I o 2 u ON | Mensajes de error, aviso e informativos. |
El rastreo detallado afectará negativamente al rendimiento y solo debe realizarse bajo indicación el centro de soporte de IBM.
E o 0 u OFF | Sólo mensajes de error. |
I o 2 u ON | Mensajes de error, aviso e informativos. |
El rastreo detallado afectará negativamente al rendimiento y solo debe realizarse bajo indicación el centro de soporte de IBM.
E o 0 u OFF | Sólo mensajes de error. |
I o 2 u ON | Mensajes de error, aviso e informativos. |
El rastreo detallado afectará negativamente al rendimiento y solo debe realizarse bajo indicación el centro de soporte de IBM.
El rastreo detallado afectará negativamente al rendimiento y solo debe realizarse bajo indicación el centro de soporte de IBM.
BPXM023I (stclock) dataset[(member)] NOT LOCKED BPXM023I (stclock) dataset[(member)] LOCKED BY userid
Se genera el mensaje de consola FEK513W cuando el servidor RSE no puede registrar al cliente con el daemon de bloqueo. Los valores ASID y TCB que aparecen en este mensaje pueden compararse con la salida del mandato de operador D GRS,RES=(*,dataset[(member)]) para buscar el usuario real que está manteniendo el bloqueo.
Utilice el mandato Detener (STOP) para detener una tarea activa. La versión abreviada del mandato es la letra P.
El Supervisor de trabajos JES no tiene mensajes de consola específicos de producto. El servidor se basa en z/OS y JES para generar mensajes de consola para las acciones realizadas por los clientes de Developer for System z.
Tabla 19 lista los mensajes de consola específicos de producto generados por el daemon RSE, el servidor de agrupaciones de hebras RSE y el daemon de bloqueo.
ID de mensaje | Texto del mensaje |
---|---|
FEK001I | RseDaemon inicializado en modalidad de {0} bits |
FEK002I | El daemon RSE se ha inicializado. (puerto={0}) |
FEK003I | El mandato Detener se está procesando |
FEK004I | RseDaemon: tamaño de almacenamiento dinámico={0}MB y tamaño de AS privado={1}MB |
FEK005I | El proceso del servidor se ha iniciado. (processId={0}) |
FEK009I | El daemon RSE está esperando a que se inicie el proceso del servidor. |
FEK010I | (ubicación de rsed.envvars = {0}) |
FEK011I | (directorio de anotaciones = {0}) |
FEK100E | Valor de puerto/tiempo de espera del daemon debe constar de dígitos |
FEK101E | Es necesario JRE {0} o posterior |
FEK102E | Se han recibido argumentos no válidos: {0} |
FEK103E | Disco casi lleno en {0} |
FEK104E | Se ha alcanzado el número máximo de procesos |
FEK105E | Error al enviar datos de auditoría (rc={0}) |
FEK110E | socket() ha fallado. razón=({0}) |
FEK111E | setsockopt() ha fallado. razón=({0}) |
FEK112E | bind() ha fallado. razón=({0}) |
FEK113E | listen() ha fallado. razón=({0}) |
FEK114E | accept() ha fallado. razón=({0}) |
FEK115E | write() ha fallado. razón=({0}) |
FEK116E | pipe() ha fallado. razón=({0}) |
FEK117E | socketpair() ha fallado. razón=({0}) |
FEK118E | select() ha fallado. razón=({0}) |
FEK119E | _console() ha fallado. razón=({0}) |
FEK130E | gsk_environment_open() ha fallado. razón=({0}) |
FEK131E | gsk_attribute_set_enum(PROTOCOLO_GSK_SSLV2) ha fallado. razón=({0}) |
FEK132E | gsk_attribute_set_enum(PROTOCOLO_GSK_SSLV3) ha fallado. razón=({0}) |
FEK133E | gsk_attribute_set_enum(PROTOCOLO_GSK_TLSV1) ha fallado. razón=({0}) |
FEK134E | gsk_attribute_set_buffer(ARCHIVO_ANILLO-CLAVES_GSK) ha fallado. razón=({0}) |
FEK135E | gsk_attribute_set_buffer(CONT_ANILLO-CLAVES_GSK) ha fallado. razón=({0}) |
FEK136E | gsk_environment_init() ha fallado. razón=({0}) |
FEK137E | gsk_secure_socket_open() ha fallado. razón=({0}) |
FEK138E | gsk_attribute_set_numeric_value(FD_GSK) ha fallado. razón=({0}) |
FEK139E | gsk_attribute_set_buffer(ETIQUETA_ANILLO-CLAVES_GSK) ha fallado. razón=({0}) |
FEK140E | gsk_attribute_set_enum(TIPO_SESIÓN_GSK) ha fallado. razón=({0}) |
FEK141E | gsk_attribute_set_callback(DEVOLUCIÓN-LLAMADA_ES_GSK) ha fallado. razón=({0}) |
FEK142E | gsk_secure_socket_init() ha fallado. razón=({0}) |
FEK143E | gsk_attribute_set_enum(GSK_CLIENT_AUTH_TYPE) ha fallado. razón=({0}) |
FEK144E | gsk_get_cert_info ha fallado. razón=({0}) |
FEK145E | gsk_secure_socket_read() ha fallado. razón=({0}) |
FEK146E | gsk_secure_socket_write() ha fallado. razón=({0}) |
FEK150E | El daemon RSE ha terminado anormalmente; {0} |
FEK201I | El mandato {0} se ha procesado |
FEK202E | Se ha especificado un mandato no válido |
FEK203E | Mandato de visualización no válido: Display Process|Client |
FEK204E | Mandato de cancelación no válido: Cancel ID=|User= |
FEK205E | El mandato no se ha procesado debido a SWITCH consecutivos |
FEK206E | El recurso de anotaciones de auditoría no está activo |
FEK207I | No hay ningún cliente que visualizar |
FEK208I | Se ha cancelado {0} |
FEK209I | No hay ningún proceso que visualizar |
FEK210I | {0} cancelado debido a inicio de sesión duplicado |
FEK501I | Daemon de bloqueo iniciado, puerto={0}, intervalo de limpieza={1}, nivel de anotaciones={2} |
FEK502I | Daemon de bloqueo, finalizando |
FEK510E | Daemon de bloqueo, falta el puerto |
FEK511E | Daemon de bloqueo, puerto erróneo, puerto={0} |
FEK512E | Daemon de bloqueo, error del socket, puerto={0} |
FEK513W | Daemon de bloqueo, ha fallado el registro, ASID={0}, TCB={1}, USER={2} |
FEK514W | Daemon de bloqueo, nivel de anotaciones erróneo, nivel de anotaciones={0} |
BPXM023I | (stclock) dataset[(member)] NOT LOCKED |
BPXM023I | (stclock) dataset[(member)] LOCKED BY userid |
BPXM023I | (stclock) command, WRONG COMMAND |
BPXM023I | (stclock) command, MISSING ARGUMENT |
BPXM023I | (stclock) argument, WRONG ARGUMENT |
El diagrama de sintaxis muestra cómo especificar un mandato para que el sistema operativo pueda interpretar correctamente lo que se escribe. Un diagrama de sintaxis se lee de izquierda a derecha y de arriba a abajo, siguiendo la línea horizontal (la vía de acceso principal).
En los diagramas de sintaxis se utilizan los símbolos siguientes:
Símbolo | Descripción |
---|---|
>> | Marca el principio del diagrama de sintaxis. |
> | Indica que el diagrama de sintaxis continúa. |
| | Marca el principio y el final de un fragmento o parte del diagrama de sintaxis. |
>< | Marca el final del diagrama de sintaxis. |
En los diagramas de sintaxis se utilizan los tipos de operandos siguientes:
>>--OPERANDO_OBLIGATORIO--><
>>-*------------------*->< *-OPERANDO_OPCIONAL-*
*-OPERANDO_PREDETERMINADO-* >>-*-----------------*-><
Los operandos se clasifican como palabras clave o variables:
En el ejemplo siguiente, el mandato USER es una palabra clave. El parámetro de variable obligatorio es id_usuario y el parámetro de variable opcional es contraseña. Sustituya los parámetros de variable por sus propios valores:
>>--USER--id_usuario-*----------*---------------------------------->< *-contraseña-*
Si un diagrama muestra un carácter que no es alfanumérico (como por ejemplo paréntesis, puntos, comas, signos de igual y espacios en blanco), debe codificar el carácter como parte de la sintaxis. En este ejemplo, debe codificar OPERAND=(001 0.001):
>>--OPERAND--=--(--001-- --0.001--)------------------------><
Una flecha que señala hacia la izquierda en un grupo de operandos indica que puede seleccionarse más de uno o que uno de ellos puede repetirse:
>>--*----------------------*---------------------------->< *-OPERANDO_REPETIBLE_1-* *-OPERANDO_REPETIBLE_2-* *-<--------------------*
Si un diagrama ocupa más de una línea, la primera línea finaliza con una sola punta de flecha y la segunda línea empieza por una sola punta de flecha:
>>--| La primera línea de un diagrama de sintaxis que ocupa más de una línea |--> >--| La continuación de los submandatos, parámetros o ambos |---------><
Es posible que algunos diagramas contengan fragmentos de sintaxis, que sirven para dividir los diagramas demasiado largos, complejos o con demasiadas repeticiones. Los nombres de los fragmentos de sintaxis se especifican en mayúsculas/minúsculas mezcladas y se muestran en el diagrama y en la cabecera del fragmento. El fragmento se coloca debajo del diagrama principal:
>>--| Fragmento de sintaxis |--------------------------------------->< Fragmento de sintaxis: |--1ER_OPERANDO--,--2º_OPERANDO--,--3ER_OPERANDO--|
Este capítulo se propone ayudarle a resolver algunos problemas comunes que pueden surgir durante la configuración de Developer for System z, y tiene las secciones siguientes:
Encontrará más información en la sección de soporte del sitio Web de Developer for System z (http://www-306.ibm.com/software/awdtools/rdz/support/), donde hay fichas técnicas que le aportarán la información más reciente de nuestro equipo de soporte.
En la sección de biblioteca del sitio Web (http://www-306.ibm.com/software/awdtools/rdz/library/) también hallará la versión más reciente de la documentación de Developer for System z, incluidos los documentos.
Developer for System z Information Center (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) describe el cliente Developer for System z y cómo interactúa con el host (desde la perspectiva del cliente).
También encontrará información valiosa en la biblioteca Internet de z/OS, disponible en http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
Infórmenos si opina que a Developer for System z le falta alguna función. Puede abrir una Solicitud de mejora (RFE) en
https://www.ibm.com/developerworks/support/rational/rfe/
Developer for System z proporciona un trabajo de ejemplo, FEKLOGS, que reúne todos los archivos de anotaciones de z/OS UNIX, así como la información de instalación y configuración de Developer for System z.
El trabajo de ejemplo FEKLOGS se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
La personalización de FEKLOGS se describe en el JCL. La personalización abarca la provisión de algunas variables clave.
Developer for System z crea archivos de anotaciones que le ayudarán a usted y al centro de soporte de IBM a identificar y resolver problemas. La lista que sigue es una visión general de los archivos de anotaciones que se pueden crear en su sistema host z/OS. Junto a estos archivos de anotaciones específicos del producto, no olvide consultar SYSLOG por si hay mensajes relacionados.
Las anotaciones basadas en MVS se pueden localizar mediante la sentencia DD pertinente. Los archivos de anotaciones basados en z/OS UNIX se encuentran en los siguientes directorios:
Los archivos de anotaciones específicos del usuario están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Los archivos de anotaciones específicos del daemon RSE y de la agrupación de hebras RSE se encuentran en daemon-home, donde daemon-home es el valor de la directiva daemon.log de rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
Anotaciones de las operaciones normales. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(JMON) es SYSOUT=*.
Anotaciones de rastreo. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(JMON) es SYSOUT=*. El rastreo se activa con el parámetro -TV; hallará más detalles en: Rastreo del Supervisor de trabajos JES.
Los datos redirigidos de stdout, la salida estándar de Java. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(LOCKD) es SYSOUT=*.
Los datos redirigidos de stderr, la salida de errores estándar de Java. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(LOCKD) es SYSOUT=*.
Los datos redirigidos de stdout, la salida estándar de Java del daemon RSE. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(RSED) es SYSOUT=*.
Los datos redirigidos de stderr, la salida de error estándar de Java del daemon RSE. El valor predeterminado del JCL de ejemplo FEK.#CUST.PROCLIB(RSED) es SYSOUT=*.
Los archivos de anotaciones específicos del daemon RSE y de la agrupación de hebras RSE se encuentran en daemon-home, donde daemon-home es el valor de la directiva daemon.log de rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
Los componentes relacionados con RSE crean varios archivos de anotaciones. Todos están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Anotaciones de Integración del analizador de errores, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Anotaciones de comunicación de la Integración del gestor de archivos, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Anotaciones de comunicación de SCLM Developer Toolkit, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Al abrir una conexión con CARMA mediante la interfaz de proceso por lotes, FEK.#CUST.SYSPROC(CRASUBMT) iniciará un trabajo servidor (cuyo propietario será el ID del usuario) llamado CRApuerto, siendo puerto el número de puerto TCP/IP que se utiliza.
Si se especifica la sentencia DD CARMALOG en el método de inicio de CARMA elegido, las anotaciones de CARMA se redirigen a esta sentencia DD en el trabajo servidor; de lo contrario, van a SYSPRINT.
El SYSPRINT del trabajo servidor contiene las anotaciones de CARMA, si la sentencia DD CARMALOG no está definida.
Anotaciones de comunicación de CARMA, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
El programa de utilidad de administración APPC, cuando añade y modifica un perfil de programa de transacción (TP), comprueba el perfil del TP y su JCL por si hay errores de sintaxis. En esta fase, los datos de salida constan de los mensajes de error de sintaxis del perfil del TP, los mensajes de proceso del programa de utilidad y de las sentencias de conversión del JCL. Las anotaciones de los mensajes de esta fase se controlan mediante la sentencia DD SYSPRINT para el programa de utilidad ATBSDFMU. El valor predeterminado en el JCL de ejemplo FEK.SFEKSAMP(FEKAPPCC) es SYSOUT=*. Consulte la publicación MVS Planning: APPC/MVS Management (SA22-7599) para obtener más detalles.
Cuando se ejecuta un TP, los mensajes de tiempo de ejecución del TP (como los mensajes de asignación y los de terminación) se escriben en un archivo de anotaciones nombrado por la palabra clave MESSAGE_DATA_SET en el correspondiente perfil del TP. El valor predeterminado en el JCL de ejemplo FEK.SFEKSAMP(FEKAPPCC) es &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Consulte la publicación MVS Planning: APPC/MVS Management (SA22-7599) para obtener más detalles.
Salida del mandato fekfivpi -file (Prueba IVP relacionada con la Pasarela de cliente TSO/ISPF), donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Salida del mandato fekfivps -file (Prueba IVP relacionada con SCLMDT), donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
Cuando un producto se interrumpe de forma anómala, se crea un vuelco de almacenamiento para ayudar a determinar el problema. La disponibilidad y la ubicación de los vuelcos depende en gran medida de los valores específicos del local. Por lo que podría suceder que no se crearan o que se creen en ubicaciones distintas de las que se mencionan a continuación.
Si el programa se ejecuta en MVS, compruebe los archivos de vuelco del sistema y compruebe también el JCL de las siguientes sentencias DD (en función del producto):
Consulte las publicaciones MVS JCL Reference (SA22-7597) y Language Environment Debugging Guide (GA22-7560) para obtener más información acerca de estas sentencias DD.
En z/OS UNIX, la mayoría de vuelcos de Developer for System z están controlados por la máquina virtual Java (JVM).
La JVM crea por defecto un conjunto de agentes de vuelco durante su inicialización (SYSTDUMP y JAVADUMP). Puede alterar temporalmente este conjunto de agentes de vuelco utilizando la variable de entorno JAVA_DUMP_OPTS, y aún puede alterar adicionalmente el conjunto utilizando -Xdump en la línea de mandatos. Las opciones de línea de mandatos de la JVM están definidas en la directiva _RSE_JAVAOPTS de rsed.envvars . No cambie ninguno de los valores, a menos que se lo indique el centro de soporte de IBM.
Los tipos de vuelco que se pueden producir son los siguientes:
El vuelco se escribe en un conjunto de datos MVS secuencial, utilizando un nombre predeterminado con el formato %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S, o tal como viene determinado por el valor de la variable de entorno JAVA_DUMP_TDUMP_PATTERN. Si no quiere que se creen vuelcos de transacciones, añada la variable de entorno IBM_JAVA_ZOS_TDUMP=NO a rsed.envvars.
Variable | Uso |
---|---|
%uid | ID de usuario |
%job | Nombre de trabajo |
%y | Año (2 dígitos) |
%m | Mes (2 dígitos) |
%d | Día (2 dígitos) |
%H | Hora (2 dígitos) |
%M | Minuto (2 dígitos) |
%S | Segundo (2 dígitos) |
El vuelco se escribe en un archivo de z/OS UNIX llamado CEEDUMP.aaaammdd.hhmmss.pid, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de vuelcos de z/OS UNIX.
El vuelco se escribe en un archivo de z/OS UNIX llamado HEAPDUMP.aaaammdd.hhmmss.pid.TXT, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de vuelcos de z/OS UNIX.
El vuelco se escribe en un archivo de z/OS UNIX llamado JAVADUMP.aaaammdd.hhmmss.pid.TXT, donde aaaammdd es la fecha actual, hhmmss es la hora actual y pid es el ID del proceso actual. Las posibles ubicaciones de este archivo se describen en: Ubicaciones de vuelcos de z/OS UNIX.
Consulte las publicaciones Java Diagnostic Guide (SC34-6358), para obtener más información acerca de los vuelcos de JVM, y Language Environment Debugging Guide (GA22-7560) para obtener información específica acerca de LE.
La JVM comprueba cada una de las siguientes ubicaciones para ver si tienen permiso de escritura y existencia, y almacena los archivos CEEDUMP, HEAPDUMP y JAVADUMP en la primera ubicación disponible. Tenga en cuenta que debe tener suficiente espacio en disco libre para que el archivo de vuelco se escriba correctamente.
El rastreo del Supervisor de trabajos JES está controlado por el operador del sistema, como se describe en la sección Mandatos de operador.
Los componentes relacionados con RSE crean varios archivos de anotaciones. La mayoría están ubicados en userlog/$LOGNAME/, donde userlog es el valor combinado de la directivas user.log y DSTORE_LOG_DIRECTORY de rsed.envvars, y $LOGNAME es el ID de usuario de inicio de sesión (en mayúsculas). Si la directiva user.log no tiene caracteres de comentario o no está presente, se utiliza la vía de acceso inicial del usuario. La vía de acceso inicial se define en el segmento de seguridad OMVS del ID de usuario. Si la directiva DSTORE_LOG_DIRECTORY no tiene caracteres de comentario o no está presente, se añade .eclipse/RSE/ al valor user.log.
La cantidad de datos escritos en ffs*.log, lock.log y rsecomm.log se controla mediante el mandato del operador modify rsecommlog o estableciendo debug_level en rsecomm.properties. Consulte las secciones Mandatos de operador y (Opcional) Rastreo de RSE para obtener más detalles.
La creación de los archivos de anotaciones .dstore* está controlada por las opciones de inicio -DDSTORE_* de Java, como se describe en la sección Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS.
Los archivos de anotaciones específicos del daemon RSE y de la agrupación de hebras RSE se encuentran en daemon-home, donde daemon-home es el valor de la directiva daemon.log de rsed.envvars. Si la directiva daemon.log no tiene caracteres de comentario o no está presente, se utiliza el directorio inicial del ID de usuario asignado a la tarea iniciada RSED. El directorio inicial se define en el segmento de seguridad OMVS del ID de usuario.
La cantidad de datos escritos en rsedaemon.log y rseserver.log se controla mediante los mandatos del operador modify rsedaemonlog y modify rseserverlog o estableciendo debug_level en rsecomm.properties. Consulte las secciones Mandatos de operador y (Opcional) Rastreo de RSE para obtener más detalles.
serverlogs.count, stderr.*.log y stdout.*.log solamente se crean si la directiva enable.standard.log de rsed.envvars está activa, o si la función está activada dinámicamente con el mandato de operador modify rsestandardlog on.
Las anotaciones específicas del daemon de bloqueo están ubicadas en STDOUT DD de la tarea iniciada LOCKD. La cantidad de datos escritos en las anotaciones se controla mediante el parámetro de inicio LOG. Consulte las secciones Mandatos de operador y (Opcional) Rastreo de RSE para obtener más detalles.
El usuario puede controlar la cantidad de información de rastreo generada por CARMA, estableciendo el Nivel de rastreo en la pestaña de propiedades de la conexión CARMA en el cliente. Las opciones de nivel de rastreo son:
El valor predeterminado es el siguiente:
Anotaciones de error
Para obtener más información sobre la ubicación de los archivos de anotaciones, consulte: Archivos de anotaciones.
El siguiente procedimiento permite reunir la información necesaria para diagnosticar problemas de información de retorno de errores con procedimientos de construcción remotos. Este rastreo afectará negativamente al rendimiento y solo se debe activar cuando así lo indica el centro de soporte de IBM. En este apartado, todas las referencias a hlq se refieren al calificador de alto nivel empleado durante la instalación de Developer for System z. El valor predeterminado de la instalación es FEK, pero quizá no sea válido para su local.
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K, //* PARM=('EXIT(ADEXIT(ELAXMGUX))', // PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))', // 'ADATA', // 'LIB', // 'TEST(NONE,SYM,SEP)', // 'LIST', // 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000' SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000' ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001' SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001' ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002' SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002' ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003' SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF.Z682746.XML 23 //COBOL.WSEDSF2 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z requiere que el sistema de archivos de z/OS UNIX y algunos archivos de z/OS UNIX tengan establecidos determinados bits de permiso.
El Explorador de sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios centrales como los de conectar el cliente al host. Debe permitírsele realizar tareas tales como crear el entorno de seguridad del usuario.
El sistema de archivos (HFS o zFS) en el que se instala Developer for System z debe estar montado con el bit de permiso SETUID (este el valor predeterminado del sistema). El hecho de montar el sistema de archivos con el parámetro NOSETUID impedirá que Developer for System z cree el entorno de seguridad del usuario y la solicitud de conexión fallará.
Utilice el mandato ISHELL de TSO para listar el estado actual del bit SETUID. En el panel de ISHELL, seleccione Sistemas de archivos > 1. Tabla de montaje... para listar los sistemas de archivos montados. El mandato abreviado a mostrará los atributos del sistema de archivos seleccionado, donde el campo "Ignorar SETUID" debe ser 0.
El Explorador de sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios centrales como los de conectar el cliente al host. Se debe ejecutar en modalidad controlada por programa para poder realizar tareas como las de pasar al ID de usuario del cliente.
El bit de control de programa de z/OS UNIX se establece durante la instalación de SMP/E cuando es necesario, excepto para la interfaz de Java del producto de seguridad, tal como se documenta en la sección Consideraciones relativas a la seguridad. Este bit de permiso puede perderse si no lo ha conservado durante una copia manual de los directorios de Developer for System z.
Los siguientes archivos de Developer for System z deben estar controlados por programa:
Utilice el mandato de z/OS UNIX ls -E para listar los atributos ampliados, en los que el bit de control de programa está marcado con la letra p, tal como se muestra en el siguiente ejemplo ($ es la solicitud de z/OS UNIX):
$ cd /usr/lpp/rdz $ ls -E lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Utilice el mandato de z/OS UNIX extattr +p para establecer el bit de control de programa manualmente, como se muestra en el ejemplo siguiente ($ y # son la solicitud de z/OS UNIX):
$ cd /usr/lpp/rdz $ su # extattr +p lib/fekf* # exit $ ls -E lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
El Explorador de sistemas remotos (RSE) es el componente de Developer for System z que proporciona servicios centrales como los de conectar el cliente al host. Se debe ejecutar con autorización de APF para poder realizar tareas como por ejemplo visualizar la utilización de recursos de proceso detallados.
El bit de z/OS UNIX APF se establece durante la instalación de SMP/E, cuando sea necesario. Este bit de permiso puede perderse si no lo ha conservado durante una copia manual de los directorios de Developer for System z.
Los siguientes archivos de Developer for System z deben estar autorizados por APF:
Utilice el mandato z/OS UNIX ls -E para obtener una lista de los atributos ampliados, en la que el bit de APF está marcado con la letra a, tal como se muestra en el ejemplo siguiente ($ es la solicitud de z/OS UNIX):
$ cd /usr/lpp/rdz $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Utilice el mandato z/OS UNIX extattr +a para establecer manualmente el bit APF, tal como se muestra en el ejemplo siguiente ($ y # son las solicitudes de z/OS UNIX):
$ cd /usr/lpp/rdz $ su # extattr +a bin/fekfrivp # exit $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Algunos de los servicios opcionales de Developer for System z requieren que los módulos de carga de MVS estén disponibles para z/OS UNIX. Esta operación se realiza creando un apéndice (un archivo ficticio) en z/OS UNIX con el "sticky" bit activado. Al ejecutar el apéndice, z/OS UNIX buscará un módulo de carga de MVS con el mismo nombre y ejecutará el módulo de carga en su lugar.
El sticky bit de z/OS UNIX se establece durante la instalación de SMP/E, cuando es necesario. Estos bits de permiso pueden perderse si no los ha conservado durante una copia manual de los directorios de Developer for System z.
Los siguientes archivos de Developer for System z deben tener activado el sticky bit:
Utilice el mandato de z/OS UNIX ls -l para listar los permisos, en los que el sticky bit está marcado con la letra t, como se muestra en el ejemplo siguiente ($ es la solicitud de z/OS UNIX):
$ cd /usr/lpp/rdz $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Utilice el mandato de z/OS UNIX chmod +t para establecer el sticky bit manualmente, como se muestra en el ejemplo siguiente ($ y # son la solicitud de z/OS UNIX):
$ cd /usr/lpp/rdz $ su # chmod +t bin/CRA* # exit $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Con el mandato netstat (TSO o z/OS UNIX) puede obtener una visión general de los puertos que se utilizan en este momento. Los datos de salida de este mandato se parecerán a los del ejemplo que sigue. Los puertos utilizados son el último número (a continuación de "..") de la columna "Socket Local". Como estos puertos ya se están utilizando, no se pueden utilizar para la configuración de Developer for System z.
IPv4
MVS TCP/IP NETSTAT CS VxRy TCPIP Nombre TCPIP: TCPIP 16:36:42 ID us. Conexión Socket Local Socket Foráneo Estado ------- ---- ------------ -------------- ----- BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Escucha INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Escucha RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Escucha JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Escucha
IPv6
MVS TCP/IP NETSTAT CS VxRy Nombre TCPIP: TCPIP 12:46:25 ID usuario Conexión Estado ------- ---- ----- BPXOINIT 00000018 Escucha Socket local: 0.0.0.0..10007 Socket foráneo: 0.0.0.0..0 INETD4 00000046 Escucha Socket local: 0.0.0.0..512 Socket foráneo: 0.0.0.0..0 RSED 0000004B Escucha Socket local: 0.0.0.0..4035 Socket foráneo: 0.0.0.0..0 JMON 00000037 Escucha Socket local: 0.0.0.0..6715 Socket foráneo: 0.0.0.0..0
Otra posible limitación son los puertos TCP/IP reservados. Hay dos lugares comunes en los que se reservan puertos TCP/IP:
Este es el conjunto de datos al que hace referencia la sentencia DD PROFILE de la tarea iniciada TCP/IP, que a menudo se llama SYS1.TCPPARMS(TCPPROF).
Consulte la publicación Communications Server: IP Configuration Guide (SC31-8775) para obtener más información acerca de estas sentencias.
Para obtener una lista de estos puertos reservados, se puede utilizar el mandato netstat portl (TSO o z/OS UNIX), que crea una salida parecida a la del ejemplo siguiente:
MVS TCP/IP NETSTAT CS VxRy Nombre TCPIP: TCPIP 17:08:32 NºPto Prot Usuario Dstivos Rango Dirección IP ----- ---- ---- ----- ----- ---------- 00007 TCP MISCSERV DA 00009 TCP MISCSERV DA 00019 TCP MISCSERV DA 00020 TCP OMVS D 00021 TCP FTPD1 DA 00025 TCP SMTP DA 00053 TCP NAMESRV DA 00080 TCP OMVS DA 03500 TCP OMVS DAR 03500-03519 03501 TCP OMVS DAR 03500-03519
Consulte la publicación Communications Server: IP System Administrator's Commands (SC31-8781) para obtener más información acerca del mandato NETSTAT.
Para el daemon RSE, que es un proceso z/OS UNIX Java se necesita una región de gran tamaño para efectuar sus funciones. Por lo tanto, es importante establecer límites de almacenamiento grandes para los espacios de direcciones de OMVS.
El daemon RSE se inicia mediante JCL utilizando BPXBATSL, cuyo tamaño de región debe ser 0.
Establezca que MAXASSIZE en SYS1.PARMLIB(BPXPRMxx), que define el tamaño de región (proceso) de espacio de direcciones OMVS predeterminado, en 2G. Es el tamaño máximo permitido. Este es un límite a escala del sistema y, por ello, está activo para todos los espacios de direcciones z/OS UNIX. Si no desea este límite, puede establecer el límite únicamente para Developer for System z en el software de seguridad.
Este valor se puede comprobar y establecer dinámicamente (hasta la próxima IPL) con los siguientes mandatos de consola, como se describe en el manual MVS System Commands (GC28-1781):
Compruebe ASSIZEMAX, en el segmento OMVS del ID de usuario del daemon, y establézcalo en 2147483647 o, preferiblemente, en NONE para que utilice el valor SYS1.PARMLIB(BPXPRMxx).
Con RACF, este valor se puede comprobar y establecer con los siguientes mandatos TSO, como se describe en el manual Security Server RACF Command Language Reference (SA22-7687):
Asegúrese de que no permite que las rutinas de salida IEFUSI o IEALIMIT del sistema controlen los tamaños de las regiones del espacio de direcciones de OMVS. Una manera posible de lograrlo es escribiendo SUBSYS(OMVS,NOEXITS) en el código de SYS1.PARMLIB(SMFPRMxx).
Los valores de SYS1.PARMLIB(SMFPRMxx) se pueden comprobar y activar con los siguientes mandatos de consola, como se describe en el manual MVS System Commands) (GC28-1781):
La palabra clave MEMLIMIT en SYS1.PARMLIB(SMFPRMxx) limita el almacenamiento virtual que una tarea de 64 bits puede asignar por encima de la barra de 2GB. Al contrario que el parámetro REGION en JCL, MEMLIMIT=0M significa que el proceso no puede utilizar almacenamiento virtual por encima de la barra.
Si no se especifica MEMLIMIT en SMFPRMxx, el valor predeterminado es 0M, con lo que las tareas están limitadas a los 2GB (31 bits) por debajo de la barra. El valor predeterminado cambió en z/OS 1.10 a 2G, permitiendo que las tareas de 64 bits utlicen hasta 4GB (los 2GB por debajo de la barra y los 2GB por encima de la barra otorgados por MEMLIMIT).
Los valores de SYS1.PARMLIB(SMFPRMxx) se pueden comprobar y activar con los siguientes mandatos de consola, como se describe en el manual MVS System Commands) (GC28-1781):
MEMLIMIT también se puede especificar como parámetro en una tarjeta EXEC en JCL. Si no se especifica ningún parámetro MEMLIMIT, el valor predeterminado es el valor definido por SMF, excepto cuando se especifica REGION=0M, en cuyo caso el valor predeterminado es NOLIMIT.
Si no puede usar la versión APPC del servicio de mandatos TSO, las áreas en las que pueden surgir problemas son dos: al iniciar la transacción del servidor APPC y al conectar con RSE.
El REXX suministrado en (Opcional) Transacción APPC para el servicio de mandatos TSO puede ayudarle a resolver problemas de APPC, porque le da la posibilidad de gestionar APPC interactivamente a través de los paneles ISPF. Sin embargo, tenga en cuenta que puede desactivar la transacción APPC con esta herramienta; la transacción sigue ahí, pero no aceptará conexiones.
La lista que sigue es una selección de fichas técnicas disponibles actualmente en el sitio Web de soporte (http://www-306.ibm.com/software/awdtools/rdz/support/). Si desea información adicional, consulte el sitio Web de soporte:
SYS1.PARMLIB(BPXPRMxx) define muchas limitaciones relacionadas con z/OS UNIX, que se podrían alcanzar cuando hay varios clientes Developer for System z activos. La mayoría de los valores BPXPRMxx se pueden cambiar dinámicamente con los mandatos de consola SETOMVS y SET OMVS.
Utilice el mandato de consola SETOMVS LIMMSG=ALL para que z/OS UNIX muestre los mensajes de consola (BPXI040I) cuando se está a punto de alcanzar alguno de los límites de BPXPRMxx.
Cada conexión RSE inicia varios procesos que están permanentemente activos. Se pueden rehusar nuevas conexiones debido al límite establecido en SYS1.PARMLIB(BPXPRMxx) sobre la cantidad de procesos, especialmente cuando los usuarios comparten un mismo UID (como cuando se utiliza el segmento OMVS predeterminado).
Otra fuente de conexiones rehusadas es el límite de la cantidad de espacios de direcciones z/OS activas y de usuarios de z/OS UNIX activos.
Al utilizar APPC para el servicio de mandatos TSO, para leer y escribir un conjunto de datos MVS, se necesita un dominio del sistema de archivos físico por sockets. Si el sistema de archivos no está debidamente definido o si no tiene suficientes sockets, el gestor de bloqueos (FFS) podría no satisfacer las peticiones de lectura/escritura. Los archivos ffs*.log mostrarán mensajes como los siguientes:
Verifique que el miembro SYS1.PARMLIB(BPXPRMxx) contiene las siguientes sentencias:
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(2000) TYPE(UDS)
Otra causa probable de este problema, al utilizar APPC para el servicio de mandatos TSO, es que el Resolviente de TCP/IP no pueda resolver la dirección de host correctamente debido a un archivo de configuración de resolviente faltante o incompleto. Una indicación clara de este problema es el mensaje siguiente en lock.log:
clientip(0.0.0.0) <> callerip(<dirección IP host>)
Ejecute el IVP de TCP/IP fekfivpt, como se describe en Verificación de la instalación. La sección de configuración del resolviente de la salida será como la del ejemplo siguiente:
Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964 Valores de resolviente res_init: Conjunto de datos Tcp/Ip global = Ninguno Conjunto de datos Tcp/Ip predeterminado = Ninguno Conjunto de datos Tcp/Ip local = /etc/resolv.conf Tabla de conversión = Predeterminada IDusuario/NombreTrabajo = USERID API llamante = LE C Sockets Modalidad llamante = EBCDIC
Asegúrese de que las definiciones del archivo (o del conjunto de datos) a las que hace referencia "Conjunto de datos Tcp/Ip local" sean correctas.
Este campo estará en blanco si no utiliza un nombre predeterminado para el archivo resolviente de IP (utilizando el orden de búsqueda de z/OS UNIX). Si es así, añada la sentencia siguiente al archivo rsed.envvars, donde <archivo resolviente> o <datos resolvientes> representa el nombre del archivo resolviente de IP:
RESOLVER_CONFIG=<archivo resolviente>
o bien
RESOLVER_CONFIG='<conjunto de datos resolvientes>'
Developer for System z proporciona a los usuarios acceso al sistema central en una estación de trabajo que no es del sistema central. Algunos aspectos importantes de la configuración del producto son: validar las solicitudes de conexión, proporcionar una comunicación segura entre el host y la estación de trabajo, y autorizar y auditar la actividad.
Los mecanismos de seguridad utilizados por los servidores y servicios de Developer for System z se basan en que el sistema de archivos en el que residen sea seguro. Esto implica que sólo los administradores del sistema que sean de confianza puedan actualizar las bibliotecas de programa y los archivos de configuración.
En este capítulo se tratan estos temas:
Consulte Qué es Developer for System z para conocer los conceptos de diseño básicos de Developer for System z.
Developer for System z admite varias formas de autenticar un ID de usuario facilitado por un cliente durante la conexión.
Tenga en cuenta que los datos de autenticación facilitados por el cliente solamente se utilizan una vez, durante la configuración inicial de la conexión. Una vez se autentica un ID de usuario, este y los PassTickets autogenerados se utilizan para todas las acciones que requieren autenticación.
El cliente facilita un ID de usuario y una contraseña coincidente durante la conexión. El ID de usuario y la contraseña se utilizan para autenticar al usuario en el producto de seguridad.
Basándose en una única señal, un producto externo puede generar una contraseña para una sola vez. Las contraseñas para una sola vez mejoran la configuración de seguridad, ya que la señal exclusiva no se puede copiar y utilizar sin el conocimiento del usuario, y una contraseña interceptada no sirve para nada porque solamente es válida una vez.
El cliente facilita un ID de usuario y una contraseña para una sola vez durante la conexión que se utiliza para autenticar el ID de usuario con la salida de seguridad proporcionada por un programa externo. Se espera que esta salida de seguridad ignore los PassTickets utilizados para satisfacer las solicitudes de autenticación durante el proceso normal. Su software de seguridad debe procesar los PassTickets.
Un tercer puede proporcionar uno o varios certificados X.509 que se pueden utilizar en la autenticación de un usuario. Cuando están almacenados en dispositivos seguros, los certificados X.509 combinan una configuración segura con un uso sencillo para el usuario (no son necesarios ni ID de usuario ni contraseña).
Durante la conexión, el cliente facilita un certificado seleccionado y, opcionalmente, una extensión seleccionada, que se utiliza para autenticar el ID de usuario con su producto de seguridad.
Tenga en cuenta que este método de autenticación solamente está soportado por el método de conexión del daemon RSE y que la SSL debe estar habilitada.
El daemon RSE (o REXEC/SSH) realiza la autenticación de clientes como parte de la solicitud de conexión del cliente. Una vez se autentica el usuario, se utilizan PassTickets autogenerados para las solicitudes de autenticación que se realicen en el futuro, incluido el inicio de sesión automático en el Supervisor de trabajos JES.
Para que el Supervisor de trabajos JES valide el ID de usuario y el PassTicket presentado por RSE, el Supervisor de trabajos JES debe poder evaluar el PassTicket. Ello implica:
El servidor RSE, que controla toda la comunicación entre el cliente y los servicios de Developer for System z, da soporte a varios niveles de seguridad de comunicaciones:
El programador del sistema puede especificar los puertos en los que el servidor RSE se puede comunicar con el cliente. Por omisión, se utiliza cualquier puerto disponible. Este rango de puertos no tiene conexión con el puerto del daemon RSE.
Para ayudarle a comprender la utilización de los puertos, se proporciona esta descripción corta del proceso de conexión del RSE:
Todas las corrientes de datos externas de Developer for System z que pasan a través de RSE pueden cifrarse mediante SSL (Capa de sockets seguros). La utilización de SSL está controlada por los valores del archivo de configuración ssl.properties, como se describe en la sección Comunicación cifrada con SSL.
El Emulador de conexión de host del cliente se conecta a un servidor TN3270 del host. La utilización de SSL está controlada por TN3270, como se describe en la publicación Communications Server IP Configuration Guide (SC31-8775).
El cliente Gestor de despliegue de aplicaciones utiliza el servicio Web de CICS TS de la interfaz RESTful para invocar los servicios de host del Gestor de despliegue de aplicaciones. La utilización de SSL está controlada por CICS TS, tal como se describe en la publicación RACF Security Guide for CICS TS .
Developer for System z da soporte a la comprobación de puerto de entrada (POE), que permite el acceso de host sólo a las direcciones TCP/IP de confianza. La utilización de POE está controlada por la definición de perfiles específicos del software de seguridad y por la directiva enable.port.of.entry del archivo rsed.envvars, como se describe en la sección Comprobación de puerto de entrada (POE).
Tenga en cuenta que la activación de POE influirá sobre otras aplicaciones TCPIP que den soporten a la comprobación de POE, como INETD.
Figura 40 muestra los puertos TCP/IP que Developer for System z puede utilizar. Las flechas muestran qué parte realiza el enlace (parte de la punta de la flecha) y que parte realiza la conexión.
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):
Varios servicios de host de Developer for System z se ejecutan en hebras o espacios de direcciones separados y utilizan sockets TCP/IP como mecanismo de comunicación. 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á:
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, 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. Una vez el servidor está conectado, el cliente puede mandar solicitudes al servidor y recibir los resultados.
Así, 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.
Después de del inicio de sesión, se utilizan Pases (PassTickets) para establecer la seguridad de las hebras dentro del servidor RSE. Esta característica no puede inhabilitarse. Los PassTickets son contraseñas generadas por el sistema con un tiempo de vida aproximado de 10 minutos. Los PassTickets generados se basan en el algoritmo de cifrado DES, en el ID de usuario, en el ID de aplicación, en la indicación de fecha y hora, y en una clave secreta. Esta clave secreta es un número de 64 bits (16 caracteres hexadecimales) que deben definirse en el software de seguridad.
Para ayudarle a comprender la utilización de PassTicket, se proporciona esta breve descripción del proceso de seguridad del RSE:
La contraseña real del cliente ya no es necesaria después de la autenticación inicial porque los productos de seguridad compatibles con SAF pueden evaluar tanto los PassTickets como las contraseñas habituales. El servidor RSE genera y utiliza un PassTicket cada vez que es necesaria una contraseña, cuyo resultado es una contraseña válida (temporal) para el cliente.
El uso de PassTickets permite a RSE configurar un entorno de seguridad específico del usuario a voluntad, sin necesidad de almacenar todos los ID de usuario y las contraseñas en una tabla, cosa que podría poner en peligro esta información. También lo permite para métodos de autenticación de cliente que no utilizan contraseñas reutilizables, como los certificados X.509.
Los perfiles de seguridad de las clases de APPL y PTKTDATA son necesarios para poder utilizar los PassTickets. Estos perfiles son específicos de la aplicación y, por ello, no afectan a la configuración de su sistema actual.
El hecho de que los PassTickets sean específicos de la aplicación implica que tanto RSE como el Supervisor de trabajos JES deben utilizar el mismo ID de aplicación (APPLID). Por omisión, ambos servidores utilizan FEKAPPL como APPLID, pero esto puede verse modificado por la directiva APPLID de rsed.envvars para RSE y de FEJJCNFG para el Supervisor de trabajos JES.
Ahora no debe utilizar OMVSAPPL como ID de aplicación ya que abrirá la clave secreta a la mayoría de las aplicaciones z/OS UNIX. Tampoco debe utilizar el ID de aplicación MVS predeterminado, que es MVS seguido por el ID SMF del sistema, porque esto abrirá la clave secreta a la mayoría de aplicaciones MVS (incluyendo trabajos por lotes de usuarios).
Atención: La solicitud de conexión del cliente fallará si los PassTickets no están configurados correctamente. |
Developer for System z da soporte a las anotaciones de auditoría de acciones gestionadas por el daemon RSE. Las anotaciones de auditoría se almacenan como archivos de texto en el directorio de anotaciones del daemon, utilizando el formato CSV (valores separados por comas).
Varias opciones de rsed.envvars influyen sobre la función de auditoría, como se describe en la sección Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS.
Puede utilizarse el mandato de operador modify switch para pasar manualmente a un nuevo archivo de anotaciones de auditoría, como se describe en la sección Mandatos de operador.
Se envía un mensaje de aviso a la consola cuando el sistema de archivos que contiene los archivos de anotaciones de auditoría se está quedando sin espacio libre. Este mensaje de consola (FEK103E) se repite regularmente hasta que se ha resuelto el problema de falta de espacio. Consulte Mensajes de consola para obtener una lista de los mensajes de consola generados por RSE.
Un archivo de anotaciones de auditoría nuevo se inicia después de un tiempo predeterminado o cuando se emite el mandato de operador modify switch. El archivo de anotaciones antiguo se guarda como audit.log.aaaammdd.hhmmss, donde aaaammdd.hhmmss es la fecha/indicación de fecha y hora de cierre de las anotaciones. La fecha/indicación de fecha y hora del sistema asignada al archivo indica la creación del archivo de anotaciones. La combinación de las dos fechas muestra el período de tiempo cubierto por este archivo de anotaciones de auditoría.
Se anotan las siguientes acciones:
Cada acción anotada se almacena (con una fecha/indicación de fecha y hora) utilizando el formato CSV (valores separados por comas), que puede leerse mediante una herramienta de análisis de datos o automatización.
Los archivos de anotaciones de auditoría tienen la máscara de bit de permiso 640 (-rw-r-----), lo que significa que el propietario (uid de z/OS UNIX del daemon RSE) tiene acceso de grabación y lectura, y el grupo del propietario (predeterminado) tiene acceso de lectura. Todos los demás intentos de acceso se denegarán, a menos que los realice un superusuario (UID 0) o alguien con permiso suficiente sobre el perfil SUPERUSER.FILESYS de la clase UNIXPRIV.
Developer for System z permite a los clientes acceder al spool de JES por medio del Supervisor de trabajos JES. El servidor proporciona limitaciones básicas de acceso, que pueden ampliarse con las características estándar de protección de archivos de spool de su producto de seguridad. Las acciones del operador (Retener, Liberar, Cancelar y Depurar) en los archivos de spool se realizan por medio de la consola de EMCS, para la que deben configurarse permisos condicionales.
El supervisor de trabajos JES no proporciona a los usuarios de Developer for System z acceso de operador pleno al spool JES. Sólo están disponibles los mandatos Retener, Liberar, Cancelar y Depurar, y, por omisión, sólo para los archivos de spool propiedad del usuario. Para emitir los mandatos, se selecciona la opción pertinente en la estructura de menús del cliente (no hay indicador de mandatos). El ámbito de los mandatos puede ampliarse utilizando perfiles de seguridad para definir para qué trabajos están disponibles los mandatos.
Parecido a la acción de SDSF SJ, el Supervisor de trabajos JES también soporta el mandato Mostrar JCL para recuperar el JCL que creó la salida del trabajo seleccionado y visualizarlo en una ventana de editor. El Supervisor de trabajos JES recupera el JCL de JES y lo convierte en una función útil para los casos en que no se puede ubicar el miembro de JCL fácilmente.
Acción | JES2 | JES3 |
---|---|---|
Retener | $Hx(idtrabajo)
con x = {J, S o T} |
*F,J=idtrabajo,H |
Liberar | $Ax(idtrabajo)
con x = {J, S o T} |
*F,J=idtrabajo,R |
Cancelar | $Cx(idtrabajo)
con x = {J, S o T} |
*F,J=idtrabajo,C |
Purgar | $Cx(idtrabajo),P
con x = {J, S o T} |
*F,J=idtrabajo,C |
Mostrar JCL | no aplicable | no aplicable |
Por omisión, los mandatos de JES disponibles listados en Tabla 21 están limitados a los trabajos que son propiedad del usuario. Esto puede cambiarse mediante la directiva LIMIT_COMMANDS, como se describe en la sección FEJJCNFG, archivo de configuración del supervisor de trabajos JES.
Propietario del trabajo | ||
---|---|---|
LIMIT_COMMANDS | Usuario | Otros |
USERID (valor predeterminado) | Permitido | No permitido |
LIMITED | Permitido | Permitido sólo si lo permiten explícitamente los perfiles de seguridad |
NOLIMIT | Permitido | Permitido si lo permiten los perfiles de seguridad o cuando la clase JESSPOOL no está activa |
JES utiliza la clase JESSPOOL para proteger los conjuntos de datos SYSIN/SYSOUT. Parecido a SDSF, el Supervisor de trabajos JES amplía la utilización de la clase JESSPOOL para proteger también los recursos de trabajo.
Si LIMIT_COMMANDS no es USERID, el Supervisor de trabajos JES solicitará el permiso al perfil relacionado con la clase JESSPOOL, tal como se muestra en la tabla siguiente:
Mandato | Perfil JESSPOOL | Acceso necesario |
---|---|---|
Retener | nodeid.userid.jobname.jobid | ALTER |
Liberar | nodeid.userid.jobname.jobid | ALTER |
Cancelar | nodeid.userid.jobname.jobid | ALTER |
Purgar | nodeid.userid.jobname.jobid | ALTER |
Mostrar JCL | nodeid.userid.jobname.jobid.JCL | READ |
Utilice la siguientes sustituciones en la tabla anterior:
idnodo | ID del nodo NJE del subsistema JES destino |
idusuario | ID de usuario local del propietario del trabajo |
nombretrabajo | Nombre del trabajo |
idtrabajo | ID del trabajo JES |
Si la clase JESSPOOL no está activa, se produce un comportamiento diferente para los valores LIMITED y NOLIMIT de LIMIT_COMMANDS, como se describe en la sección Tabla 9. El comportamiento es idéntico si JESSPOOL está activa, ya que, por omisión, la clase deniega el permiso si un perfil no está definido.
La segunda fase de la seguridad de mandatos de spool JES, una vez especificados los destinos permitidos, incluye los permisos necesarios para ejecutar realmente el mandato de operador. Las comprobaciones de seguridad de JES y z/OS aplican esta autorización de ejecución.
Tenga en cuenta que Mostrar JCL no es un mandato de operador igual que el resto de mandatos del supervisor de trabajos JES (Retener, Liberar, Cancelar y Depurar), de manera que las siguientes limitaciones no son de aplicación porque no hay ninguna comprobación de seguridad más.
El Supervisor de trabajos JES emite todos los mandatos de operador de JES solicitados por un usuario por medio de una consola de EMCS ampliada (EMCS), cuyo nombre está controlado por la directiva CONSOLE_NAME, tal como se describe en FEJJCNFG, archivo de configuración del supervisor de trabajos JES.
Esta configuración permite al administrador de seguridad definir permisos de ejecución de mandatos granulares mediante las clases OPERCMDS y CONSOLE.
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.
Tenga en cuenta que el Supervisor de trabajos JES no puede crear la consola cuando debe ejecutarse un mandato si el nombre de consola ya se está utilizando. Para evitarlo, el programador de sistemas puede establecer la directiva GEN_CONSOLE_NAME=ON en el archivo de configuración del supervisor de trabajos JES o bien el administrador de seguridad puede definir perfiles de seguridad para impedir que los usuarios de TSO creen una consola. Los siguientes mandatos RACF de ejemplo impiden que nadie (excepto aquellos que lo tienen permitido) cree una consola TSO o SDSF:
Para obtener más información sobre la protección de los mandatos de operador, consulte el manual Security Server RACF Security Administrator's Guide (SA22-7683).
Por omisión, el Supervisor de trabajos JES permite acceder a todos los archivos de spool. Esto puede cambiarse mediante la directiva LIMIT_VIEW, como se describe en la sección FEJJCNFG, archivo de configuración del supervisor de trabajos JES.
Propietario del trabajo | ||
---|---|---|
LIMIT_VIEW | Usuario | Otros |
USERID | Permitido | No permitido |
NOLIMIT (valor predeterminado) | Permitido | Permitido si lo permiten los perfiles de seguridad o cuando la clase JESSPOOL no está activa |
Para limitar a los usuarios de forma que solo utilicen sus propios trabajos en el spool de JES, defina la sentencia "LIMIT_VIEW=USERID" en el archivo de configuración del supervisor de trabajos JES, FEJJCNFG. Si los usuarios necesitan acceso a un rango de trabajos más amplio, pero no a todos, utilice las características de protección de archivo de spool estándar de su producto de seguridad, como la clase JESSPOOL.
Al definir protección adicional, tenga presente que el supervisor de trabajos JES utiliza SAPI (interfaz de programación de aplicaciones SYSOUT) para acceder al spool. Ello implica que el usuario necesita como mínimo el acceso de actualización (UPDATE) a los archivos de spool, incluso para la función de examen. Este requisito no es necesario si se ejecuta z/OS 1.7 (z/OS 1.8 para JES3) o superior. En este caso, el permiso de lectura (READ) es suficiente para la función de examen.
Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de la protección de archivos de spool de JES.
La comunicación externa (cliente-host) puede cifrarse mediante SSL (Capa de sockets seguros). Esta característica está inhabilita por omisión y está controlada por los valores de ssl.properties, tal como se describe en (Opcional) Cifrado SSL de RSE.
El daemon RSE y el servidor RSE soportan distintos mecanismos para almacenar certificados debido a las diferencias de su arquitectura. Esto hace que las definiciones y certificados SSL sean necesarias tanto para el daemon RSE como para el servidor RSE. Se puede utilizar un certificado compartido si el daemon RSE y el servidor RSE utilizan el mismo método de gestión de certificados.
Almacenamiento de certificados | Creado y gestionado por | daemon RSE | servidor RSE |
---|---|---|---|
anillo de claves | producto de seguridad compatible con SAF | soportado | soportado |
base de datos de claves | gskkyman de z/OS UNIX | soportado | / |
almacén de claves | Keytool de Java | / | soportado |
Los anillos de claves compatibles con SAF puede almacenar la clave privada del certificado en la base de datos de seguridad o mediante el ICSF (recurso de servicio criptográfico integrado), la interfaz al hardware criptográfico de System z.
Se recomienda el ICSF para el almacenamiento de claves privadas relacionadas con certificados digitales, ya que es una solución más segura que la gestión de claves privadas sin ICSF. ICSF asegura que las claves privadas se cifran con la clave maestra de ICSF y que el acceso a ellas está controlado por los recursos generales de las clases de seguridad CSFKEYS y CSFSERV. Además, el rendimiento operativo mejora porque ICSF utiliza el hardware Coprocesador criptográfico.
El daemon RSE utiliza funciones de SSL del sistema para gestionar las comunicaciones cifradas con SSL. Ello implica que SYS1.SIEALNKE debe estar controlado por programa por su software de seguridad y disponible para RSE a través de la directiva LINKLIST o STEPLIB en rsed.envvars.
El ID de usuario de RSE (STCRSE en los mandatos de ejemplo siguientes) necesita una autorización para acceder a su anillo de claves y a los certificados relacionados cuando se utilizan anillos de claves compatibles con SAF ya sea para el daemon RSE o para el servidor RSE.
Consulte el Apéndice A. Configurar SSL y autenticación de X.509 para obtener más detalles acerca de la activación de SSL para Developer for System z.
El daemon RSE admite que los usuarios se autentiquen con un certificado X.509. El uso de una comunicación cifrada con SSL es un requisito previo para utilizar esta función, dado que es una extensión de la autenticación de host con un certificado utilizado en SSL.
El daemon RSE inicia el proceso de autenticación de cliente validando el certificado de cliente. Algunos de los aspectos clave que se comprueban son las fechas de validez del certificado y la fiabilidad de la autoridad certificadora (CA) utilizada para la firma del certificado. Opcionalmente, también se puede consultar una Lista de certificados revocados (CLR) (externa).
Una vez el daemon RSE ha validado el certificado, este es procesado para su autenticación. El certificado pasa a su producto de seguridad para que lo autentique, a menos que la directiva de rsed.envvars enable.certificate.mapping tenga un valor false, en cuyo caso el daemon RSE se encargará de la autenticación.
Si se realiza con éxito, el proceso de autenticación determinará el ID de usuario que deberá utilizarse para esta sesión; posteriormente, el daemon RSE lo probará para asegurar que es adecuado para el sistema host donde se está ejecutando el daemon RSE
La última comprobación (que realizar para todos los mecanismos de autenticación, no sólo para los certificados X.509) verifica que el ID de usuario puede utilizar Developer for System z.
Si está familiarizado con las clasificaciones de seguridad SSL utilizadas por TCP/IP, la combinación de estos pasos de validación coinciden con las especificaciones del "Nivel 3 de autenticación de cliente" (el nivel más alto disponible).
Parte del proceso de validación del certificado incluye la comprobación de que el certificado ha sido firmado por una autoridad certificadora (CA) de confianza. Para ello, el daemon RSE debe tener acceso a un certificado que identifique a la CA.
Al utilizar la base de datos de claves gskkyman para su conexión SSL, debe añadirse a la base de datos de claves el certificado de CA.
Al utilizar un anillo de claves de SAF (método recomendado), debe añadir el certificado de CA a su base de datos de seguridad como certificado CERTAUTH con el atributo TRUST o HIGHTRUST, tal como se muestra en este mandato RACF de ejemplo:
Tenga en cuenta que la mayor parte de productos de seguridad ya tienen los certificados de conocidas CA disponibles en sus bases de datos con estado NOTRUST. Utilice estos mandatos RACF de ejemplo para enumerar las certificados de CA existentes y marque uno de ellos como De confianza en base a la etiqueta que tiene asignada.
Una vez el certificado de CA está añadido a su base de datos de seguridad, debe conectarse al anillo de claves del RSE, tal como se muestra en el mandato RACF de ejemplo:
Consulte el manual Security Server RACF Command Language Reference (SA22-7687) para obtener más información sobre el mandato RACDCERT.
Atención: si confía más en el daemon RSE que en su software de seguridad para autenticar un usuario, debe tener cuidado de no mezclar las CA con los estados TRUST y HIGHTRUST en su anillo de claves de SAF ni en su base de datos de claves de gskkyman. El daemon RSE no los puede diferenciar, por lo que los certificados firmados por una CA con estado TRUST serán válidos para la autenticación del ID de usuario. |
Si lo desea, puede indicar al daemon RSE que compruebe una o varias Listas de certificados revocados (CRL) para hacer más seguro el proceso de validación. Para hacerlo, añada variables de entorno relacionadas con la CRL a rsed.envvars. Consulte rsed.envvars, archivo de configuración de RSE para obtener más información sobre estas variables de ejemplo:
Consulte el manual Cryptographic Services System Secure Sockets Layer Programming (SC24-5901) para obtener más información sobre estas y otras variables de entorno utilizadas por SSL del sistema de z/OS.
RACF lleva a cabo varias comprobaciones para autenticar un certificado y devolver el ID de usuario asociado. Tenga en cuenta que puede que otros productos de seguridad lo hagan de manera distinta. Consulte la documentación de su producto de seguridad para obtener información adicional sobre la función initACEE utilizada para llevar a cabo la autenticación (modalidad de consulta).
Los certificados se definen en RACF mediante el mandato RACDCERT, como en el ejemplo siguiente:
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
El par de ID de usuario y nombre de host es válido si todas estas condiciones son true:
La definición de la extensión de HostIdMappings en sintaxis ASN.1 es:
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1} HostIdMappings::= SET OF HostIdMapping HostIdMapping::= SEQUENCE{ hostName IMPLICIT[1] IA5String, subjectId IMPLICIT[2] IA5String, proofOfIdPossession IdProof OPTIONAL } IdProof::= SEQUENCE{ secret OCTET STRING, encryptionAlgorithm OBJECT IDENTIFIER }
Consulte el manual Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información sobre certificados X.509, la forma es que estos son gestionados por RACF y cómo definir filtros de nombre de certificado. Consulte el manual Security Server RACF Command Language Reference (SA22-7687) para obtener más información sobre el mandato RACDCERT.
Developer for System z puede llevar a cabo la autenticación básica de certificados X.509 sin basarse en su producto de seguridad. La autenticación llevada a cabo por el daemon RSE requiere que se definan un ID de usuario y un nombre de host en una extensión de certificado, y solamente se activa si la directiva enable.certificate.mapping de rsed.envvars tiene el valor de FALSE.
Esta función debe utilizarse cuando su producto de seguridad no admita la autenticación de un usuario en base a un certificado X.509, o bien si en el caso que su certificado fallara la(s) prueba(s) realizadas por el producto de seguridad (por ejemplo, si el certificado tiene un identificador erróneo para la extensión de HostIdMappings y no hay ninguna definición ni filtro de nombre en DIGTCERT).
El cliente consultará al usuario qué identificador de extensión (OID) utilizar, que es, de forma predeterminada, el OID de HostIdMappings {1 3 18 0 2 18 1}.
El daemon RSE le extraerá el ID de usuario y el nombre de host utilizando el formato de la ampliación de HostIdMappings. Este formato se describe en Autenticación del software de seguridad .
El par de ID de usuario y nombre de host es válido si todas estas condiciones son true:
Atención: Es decisión del administrador de seguridad asegurar que todas las CA reconocidas por el daemon RSE sean de confianza total, dado que el daemon RSE no puede comprobar si la persona que ha firmado el certificado de cliente es de confianza total o es simplemente de confianza. Consulte Validación de la autoridad certificadora (CA) para obtener más información sobre los certificados de CA accesibles. |
Developer for System z da soporte a la comprobación de puerto de entrada (POE), que permite el acceso de host sólo a las direcciones TCP/IP de confianza. Esta característica está inhabilita por omisión y requiere la definición del perfil de seguridad BPX.POE, como se muestra en los mandatos RACF de ejemplo que figuran a continuación:
Consulte la publicación Communications Server IP Configuration Guide (SC31-8775) para obtener más información acerca del control de acceso a la red mediante comprobaciones de POE.
Developer for System z permite, mediante el Gestor de despliegue de aplicaciones, que los administradores de CICS controlen qué definiciones de recursos CICS puede editar el desarrollador, sus valores predeterminados y la visualización de una definición de recurso CICS por medio del servidor CRD (definiciones de recursos CICS). Consulte la sección consideraciones de CICSTS para obtener más información acerca de las definiciones de recursos CICS TS necesarias.
El conjunto de datos VSAM del repositorio del servidor CRD contiene todas las definiciones de recurso predeterminadas y, por tanto, debe protegerse contra actualizaciones, pero los desarrolladores deben poder leer los valores almacenados en él.
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Cuando se conecta la transacción, la comprobación de la seguridad de recursos CICS, si está habilitada, se asegura de que el ID de usuario tiene autorización para ejecutar el ID de transacción.
El cliente Gestor de despliegue de aplicaciones utiliza la interfaz RESTful o los servicios Web de CICS TS para invocar el servidor CRD. La utilización de SSL para esta comunicación está controlada por la definición TCPIPSERVICE de CICS TS, tal como se describe en RACF Security Guide for CICS TS.
El servicio SCLM Developer Toolkit ofrece funciones de seguridad opcionales para las funciones de construcción, promoción y despliegue.
Si el administrador de SCLM habilita la seguridad para una función, se realizan llamadas SAF para comprobar la autorización para ejecutar la función protegida con el ID de usuario del llamante o uno subordinado.
Consulte la Guía del administrador de SCLM Developer Toolkit, SC11-3815 (SC23-9801), para obtener más información acerca de las definiciones de seguridad de SCLM necesarias.
Existen varios archivos de configuración de Developer for System z, cuyas directivas afectan a la configuración de seguridad. En base a la información de este capítulo, el administrador de seguridad y el programados de sistemas pueden decidir cuáles deberían ser los valores para las directivas siguientes.
Definir en qué trabajos pueden realizarse las acciones (excluidas las acciones examinar y someter). Para obtener más información, consulte Acciones en trabajos - limitaciones de destino.
Definir qué archivos de spool pueden examinarse. Para obtener más información, consulte Acceso a los archivos de spool.
ID de aplicación utilizado para la creación/validación de PassTicket. Para obtener más información, consulte Utilizar PassTickets.
Denegar a los usuarios que guarden la contraseña del host en el cliente. Para obtener más información, consulte Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS.
Temporizador para desconectar a los clientes desocupados. Para obtener más información, consulte Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS.
ID de aplicación utilizado para la creación/validación de PassTicket. Para obtener más información, consulte Utilizar PassTickets.
Habilitar la comprobación de puerto de entrada. Para obtener más información, consulte Comprobación de puerto de entrada (POE).
Utilizar su producto de seguridad para autenticar an los usuarios con un certificado X.509. Para obtener más información, consulte Autenticación de cliente mediante certificados X.509.
Ubicación de los archivos de anotaciones de auditoría. Para obtener más información, consulte Anotaciones de auditoría.
Ubicación del certificado del daemon RSE. Para obtener más información, consulte Comunicación cifrada con SSL.
Nombre del certificado del daemon RSE. Para obtener más información, consulte Comunicación cifrada con SSL.
Ubicación del certificado del servidor RSE. Para obtener más información, consulte Comunicación cifrada con SSL.
Nombre del certificado del servidor RSE. Para obtener más información, consulte Comunicación cifrada con SSL.
Tipo de almacén de claves utilizado (almacén de claves Java o anillo de claves de SAF). Para obtener más información, consulte Comunicación cifrada con SSL.
Personalice y someta el miembro de ejemplo FEKRACF, que contiene mandatos de ejemplo RACF y z/OS UNIX para crear las definiciones básicas de seguridad para Developer for System z.
FEKRACF se encuentra en FEK.#CUST.JCL, a menos que haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Para obtener más información sobre los mandatos RACF, consulte el manual RACF Command Language Reference (SA22-7687).
Las secciones que siguen describen los pasos necesarios, la configuración opcional y las posibles alternativas.
Para completar la configuración de seguridad, el administrador de seguridad necesita conocer los valores enumerados en Tabla 26. Estos valores se han definido durante los pasos anteriores de la instalación y personalización de Developer for System z.
Descripción |
|
Valor |
---|---|---|
Calificador de producto de alto nivel de Developer for System z |
|
|
Calificador de personalización de alto nivel de Developer for System z |
|
|
Nombre de tarea iniciada del Supervisor de trabajos JES |
|
|
Nombre de tarea iniciada del daemon RSE |
|
|
Nombre de tarea iniciada del daemon de bloqueo |
|
|
ID de aplicación |
|
La lista que sigue es una visión general de las acciones necesarias para completar la configuración de seguridad básica de Developer for System z. 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 deseado. Consulte las secciones anteriores para obtener información sobre la configuración de seguridad de los servicios de Developer for System z opcionales.
Developer for System z utiliza diversos mecanismos de seguridad para garantizar un entorno de host seguro y controlado para el cliente. Para ello deben activarse varias clases y valores de seguridad, como se muestra en los siguientes mandatos RACF de ejemplo:
SETROPTS LIST
SETROPTS GENERIC(FACILITY)
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
SETROPTS GENERIC(CONSOLE)
SETROPTS CLASSACT(CONSOLE) RACLIST(CONSOLE)
SETROPTS GENERIC(OPERCMDS)
SETROPTS CLASSACT(OPERCMDS) RACLIST(OPERCMDS)
SETROPTS GENERIC(APPL)
SETROPTS CLASSACT(APPL) RACLIST(APPL)
SETROPTS GENERIC(PTKTDATA)
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)
RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM)
Atención: Algunos productos, por ejemplo FTP, deben estar controlados por programa si "WHEN PROGRAM" está activo. Debe someter a prueba este procedimiento antes de activarlo en un sistema de producción. |
SETROPTS GENERIC(SERVAUTH)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
Debe definirse un segmento OMVS de RACF (o equivalente) que especifique un ID de usuario (UID) de z/OS UNIX válido que no sea cero, un directorio inicial y un mandato de shell para cada usuario de Developer for System z. Su grupo predeterminado también requiere un segmento OMVS con un id de grupo.
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))
Aunque no es aconsejable hacerlo, puede utilizar el segmento OMVS compartido definido en el perfil BPX.DEFAULT.USER de la clase FACILITY para satisfacer el requisito de segmento OMVS de Developer for System z.
El acceso de lectura (READ) para los usuarios y de modificación (ALTER) para los programadores de sistemas es suficiente para la mayoría de conjuntos de datos de Developer for System z. Sustituya el espacio reservado #progsis por identificadores de usuario o nombres de grupo de RACF válidos. Solicite al programador del sistema que ha instalado y configurado el producto los nombres de conjunto de datos correctos. FEK es el calificador de alto nivel predeterminado utilizado durante la instalación y FEK.#CUST es el calificador de alto nivel predeterminado para los conjuntos de datos creados durante el proceso de personalización.
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
Algunos de los componentes opcionales de Developer for System z requieren perfiles de conjunto de datos de seguridad adicionales. Sustituya los espacios reservados #progsis, #desarrollador-ram y #admincics por identificadores de usuario o nombres de grupo de RACF válidos:
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#desarrollador-ram)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#admincics)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
SETROPTS GENERIC(DATASET) REFRESH
Utilice los siguientes mandatos RACF de ejemplo para establecer una configuración más segura, en la que el acceso de lectura (READ) también esté controlado.
ADDGROUP (FEK) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB') OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#progsis)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#desarrollador-ram)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#admincics)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(#db2)
SETROPTS GENERIC(DATASET) REFRESH
Al controlar el acceso de lectura (READ) a los conjuntos de datos del sistema, debe otorgar a los servidores y usuarios de Developer for System z el permiso para leer (READ) los conjuntos de datos siguientes:
Los siguientes mandatos RACF crean las tareas iniciadas JMON, RSED y LOCKD, con ID de usuario protegidos (STCJMON, STCRSE y STCLOCK, respectivamente) y el grupo STCGROUP asignado a ellas. Sustituya los espacios reservados #id-grupo e #id-usuario-* por identificadores de OMVS válidos.
ADDGROUP STCGROUP OMVS(GID(#id-grupo)) DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCJMON DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR') OMVS(UID(#user-id-jmon) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON') OMVS(UID(#user-id-rse) HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCLOCK DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - DAEMON DE BLOQUEO') OMVS(UID(#id-usuario-bloqueo) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR') STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON') STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED LOCKD.* DATA('RDZ - DAEMON DE BLOQUEO') STDATA(USER(STCLOCK) GROUP(STCGROUP) TRUSTED(NO))
SETROPTS RACLIST(STARTED) REFRESH
Puede que desee considerar la posibilidad de que el ID de usuario STCRSE sea restringido. Los usuarios con el atributo RESTRICTED no pueden acceder a recursos protegidos (MVS) a los que no tienen autorización de acceso específica.
ALTUSER STCRSE RESTRICTED
Para asegurarse de que los usuarios restringidos no obtengan acceso a los recursos del sistema de archivos de z/OS UNIX mediante los "otros" bits de permiso, debe definir el perfil RESTRICTED.FILESYS.ACCESS en la clase UNIXPRIV con UACC(NONE). Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de los ID de usuario restringidos.
Atención: Si utiliza ID de usuario restringidos, debe añadir explícitamente el permiso
de acceso a los recursos con los mandatos PERMIT de TSO o
setfacl de
z/OS
UNIX.
Esto incluye los recursos en los que la documentación de Developer for System z utiliza UACC
(como por ejemplo el perfil ** de la clase PROGRAM) o los basados
en convenciones comunes de
z/OS
UNIX
(como por ejemplo que todos los usuarios tengan permiso de lectura y ejecución sobre las
bibliotecas de
Java).
Debe someter a prueba este procedimiento antes de
activarlo en un sistema de producción. |
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 FEJJCNFG, archivo de configuración del supervisor de trabajos JES.
Los siguientes mandatos RACF de ejemplo otorgan a los usuarios de Developer for System z acceso condicional a un conjunto limitado de mandatos JES (Retener, Liberar, Cancelar y Depurar). Los usuarios sólo tienen permiso de ejecución si emiten los mandatos por medio 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 SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Atención: El hecho de definir mandatos JES con el acceso universal
NONE en su software de seguridad puede afectar a otras operaciones y
aplicaciones. Debe someter a prueba este procedimiento antes de
activarlo en un sistema de producción. |
La Tabla 27 y la Tabla 28 muestran los mandatos de operador emitidos para JES2 y JES3 y los perfiles de seguridad específicos que pueden utilizarse para protegerlos.
Acción | Mandato | Perfil OPERCMDS | Acceso necesario |
---|---|---|---|
Retener | $Hx(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(idtrabajo),P
con x = {J, S o T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
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 |
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.
RSE requiere acceso de actualización (UPDATE) al perfil BPX.SERVER para crear/suprimir el entorno de seguridad de la hebra del cliente. Si este perfil no está definido, RSE requiere el UID(0).
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. Ello puede afectar a otras operaciones y aplicaciones de z/OS UNIX. Debe someter a prueba este procedimiento antes de
activarlo en un sistema de producción.
Consulte el manual UNIX System
Services Planning (GA22-7800) para obtener más información los distintos niveles de seguridad. |
Los servidores con autorización sobre BPX.SERVER deben ejecutarse en un entorno limpio controlado por programa. Esto implica que todos los programas a los que llama RSE también deben estar controlados por programa. Para las bibliotecas de carga MVS, el control de programa se gestiona mediante el software de seguridad.
RSE utiliza la biblioteca de carga del entorno de ejecución Language Environment (CEE.SCEERUN*) y de la Pasarela de cliente TSO/ISPF de ISPF (ISP.SISPLPA) del sistema.
Las siguientes bibliotecas adicionales (prerrequisito) deben estar controladas por programa para dar soporte a la utilización de servicios opcionales. Esta lista no incluye los conjuntos de datos específicos de un producto con el que interactúa Developer for System z, como IBM Debug Tool.
Durante el inicio de sesión de clientes, el daemon RSE verifica que un usuario pueda utilizar la aplicación.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
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.
Atención: La solicitud de conexión del cliente fallará si el perfil de la aplicación no está definido, o bien cuando el usuario no tiene acceso de lectura (READ) al perfil. |
La contraseña del cliente (u otras formas de identificación, como un certificado X.509) sólo se utiliza para verificar su identidad durante la conexión. Después de eso, se utilizan Pases (PassTickets) para mantener la seguridad de las hebras.
Los PassTickets son contraseñas generadas por el sistema con un tiempo de vida aproximado de 10 minutos. Los PassTickets generados se basan en una clave secreta. Esta clave es un número de 64 bits (16 caracteres hexadecimales). En los mandatos RACF de ejemplo que figuran a continuación, sustituya el espacio reservado key16 por una serie de 16 caracteres hexadecimales proporcionada por el usuario (caracteres 0-9 y A-F).
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16)) APPLDATA('NO REPLAY PROTECTION - DO NOT CHANGE') DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE soporta el uso de un ID de aplicación distinto de FEKAPPL. Descomente y personalice la opción "APPLID=FEKAPPL" del archivo rsed.envvars para activarla, como se indica en la sección Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS. 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 aplicaciones MVS (incluyendo trabajos por lotes de usuarios).
Atención: La solicitud de conexión del cliente fallará si los PassTickets no están configurados correctamente. |
Los servidores con autorización sobre BPX.SERVER deben ejecutarse en un entorno limpio controlado por programa. Esto implica que todos los programas a los que llama RSE también deben estar controlados por programa. Para los archivos z/OS UNIX, el control de programa se gestiona mediante 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 Java de RACF(/usr/lib/libIRRRacf.so).
$ ls -Eog /usr/lib/libIRRRacf.so -rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
Utilice los siguientes mandatos de ejemplo para visualizar los resultados de las personalizaciones relacionadas con la seguridad.
El host de Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Comprender el diseño de estos componentes puede ayudarle a tomar las decisiones de configuración correctas.
En este capítulo se tratan estos temas:
Figura 41 muestra una visión generalizada del diseño de Developer for System z en el sistema host.
La descripción del párrafo y la lista anteriores muestra el rol central asignado al RSE. Salvo algunas excepciones, toda la comunicación de cliente va a través del RSE. Ello permite una configuración de la red de seguridad sencilla, ya que únicamente se utiliza un conjunto limitado de puertos para la comunicación cliente-host.
Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente. Basándose en los valores definidos en el archivo de configuración rsed.envvars y en la cantidad de conexiones de cliente reales, el daemon puede iniciar varios espacios de direcciones de agrupaciones de hebras.
Figura 42 muestra una vista básica del uso de recursos (procesos y almacenamiento) por RSE.
RSE es una aplicación Java, lo que significa que está activo en el entorno z/OS UNIX. Ello permite establecer puertos de forma sencilla a otras plataformas de host y una comunicación directa con el cliente de Developer for System z, que también es una aplicación Java (basada en la infraestructura de Eclipse). Por ello, tener un conocimiento básico de cómo funcionan z/OS UNIX y Java es de gran ayuda para comprender Developer for System z.
En z/OS UNIX un programa se ejecuta en un proceso, identificado por un PID (ID de proceso). Cada programa está activo en su propio proceso, de manera que el hecho de invocar otro programa crea un proceso nuevo. Se hace referencia al proceso que ha iniciado un proceso con un PPID (PID padre), y el proceso nuevo se denomina proceso hijo. El proceso hijo se puede ejecutar en el mismo espacio de direcciones, o bien se puede engendrar (crear) en un espacio de direcciones nuevo. Un proceso nuevo que se ejecuta en el mismo espacio de direcciones puede compararse con la ejecución de un mandato en TSO; mientras que engendrar uno en un espacio de direcciones nuevo es similar a someter un trabajo por lotes.
Tenga un proceso puede tener una sola o varias hebras. En una aplicación de varias hebras (como RSE), las distintas hebras compiten por los recursos del sistema, como si fueran espacios de direcciones separados (con menos sobrecarga).
Al correlacionar esta información de proceso al ejemplo de RSE de Figura 42, obtenemos este flujo:
Las aplicaciones Java, tales como RSE, no asignan almacenamiento directamente, sino que utilizan los servicios de gestión de memorias de Java. Estos servicios, como la asignación de almacenamiento, la liberación de almacenamiento, y la recogida de basura, funcionan dentro de los límites del almacenamiento dinámico de Java. El tamaño mínimo y máximo del almacenamiento dinámico se define (ya sea implícita o explícitamente) durante el inicio de Java.
Ello implica que obtener el máximo del tamaño de espacio de direcciones disponible es un acto de equilibrio que consiste en definir un tamaño de almacenamiento dinámico grande y dejar suficiente espacio para que z/OS almacene una cantidad variable de bloques de control del sistema (que depende del número de hebras activas).
Figura 43 muestra una visión general básica del propietario de las credenciales de seguridad utilizadas para varias tareas de Developer for System z.
La propiedad de una tarea se puede dividir en dos secciones. Las tareas iniciadas son propiedad del ID de usuario asignado a la tarea iniciada en el software de seguridad. El resto de tareas con las agrupaciones de hebras RSE (RSEDx) como excepción son propiedad del ID de usuario del cliente.
Figura 43 muestra las tareas iniciadas de Developer for system z (LOCKD, JMON y RSED) y las tareas iniciadas de ejemplo y los servicios del sistema con los que Developer for System z se comunica. Application Deployment Manager (ADM) está activo dentro de una región CICS. FMNCAS es la tarea iniciada por el Gestor de archivos. 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, el Gestor de archivos iniciará un espacio de direcciones nuevo para cada conjunto de datos (o miembro) que debe procesar en nombre de Developer for System z. z/OS UNIX REXEC o SSH están implicados cuando se inician construcciones nuevas 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 Figura 43 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.
Figura 44 muestra una visión general esquemática de la forma en que un cliente se conecta al host mediante Developer for System z. Además, explica brevemente cómo se utilizan los PassTickets.
La descripción anterior muestra el diseño orientado a hebras de RSE. En lugar de iniciar un espacio de direcciones por usuario, un único espacio de direcciones de agrupaciones de hebras proporciona servicio a varios usuarios. Dentro de la agrupación de hebras, cada miner (un servicio específico del usuario) se activa en su propia hebra con el contexto de seguridad del usuario que tiene asignado, asegurando así una configuración segura. El diseño acomoda un mayor número de usuarios con un uso de recursos limitado, pero conlleva que cada cliente utilice varias hebras (16 o más, dependiendo de las tareas realizadas).
Desde un punto de vista de red, Developer for system z actúa de forma similar al FTP en modalidad pasiva. El cliente se conecta a un punto focal (daemon RSE), descarta la conexión y se reconecta a un número de puerto proporcionado por el punto focal. La siguiente lógica controla la selección del puerto que se utiliza para la segunda conexión:
El uso de PassTickets para todos los servicios de z/OS que requieren autenticación permite a Developer for System z invocar estos servicios cuando sea necesario sin tener que almacenar la contraseña ni solicitarle al usuario continuamente que la introduzca. El uso de PassTickets para todos los servicios de z/OS también permite métodos de autenticación alternativos durante el inicio de sesión, como las contraseñas para una sola vez y los certificados X.509.
Figura 45 muestra una visión general esquemática de la forma en que el daemon de bloqueo determina qué cliente de Developer for System z es propietario de un bloqueo de conjunto de datos.
Con una configuración de Developer for System z con un solo servidor, donde hay varios usuarios asignados a un único espacio de direcciones de agrupaciones de hebras, z/OS pierde la capacidad de rastrear quién es propietario de un bloqueo en un conjunto de daots o un miembro. Los mandatos del sistema se detienen a nivel de espacio de dirección, que es la agrupación de hebras.
Para solucionar este problema, Developer for System z proporciona el daemon de bloqueo. El daemon de bloqueo puede rastrear todos los bloqueos de conjuntos de datos/miembros realizador por los usuarios de RSE, así como los bloqueos realizados por otros productos, como ISPF.
El servidor RSE registra un usuario recién conectado con el daemon de bloqueo. La información de registro contiene el identificador de espacios de direcciones (que es el ASID de la agrupación de hebras), el ID del bloque de control de tareas (TCB) (específico del usuario), y el ID de usuario.
Tenga en cuenta que el registro se realiza únicamente en el momento de conectarse, de manera que todos los usuarios de RSE que estaban activos antes de que se iniciara (o se reiniciara) el daemon de bloqueo no quedarán registrados.
Cuando el daemon de bloqueo recibe una consulta de conjunto de datos (a través de un mandato de operador modify query o desde el cliente a través del servidor RSE), el daemon examina las colas de serialización de recursos globales (GRS) del sistema. Si el ASID y TCB coinciden con los de un usuario registrado, se devuelve el ID de usuario como propietario del bloqueo. De lo contrario, se devuelve el nombre de trabajo/ID de usuario asociado al ASID como propietario del bloqueo.
En caso de que el registro falle, aparece un mensaje de consola (FEK513W) con la información de registro. Ello permite a un operador hacer coincidir los valores con la salida de un mandato de operador DISPLAY GRS,RES=(*,dataset*) a fin de encontrar el propietario del bloqueo.
En circunstancias normales, un conjunto de datos o un miembro está bloqueado cuando un cliente lo abre en modalidad de edición, y este se libera cuando el cliente cierra la sesión de edición.
Algunas condiciones de error pueden provocar que este mecanismo no funcione tal como debe. En este caso, se puede cancelar el usuario que está manteniendo el bloqueo mediante el mandato de operador modify cancel de RSE, tal como se describe en Mandatos de operador. Los bloqueos de conjuntos de datos activos de este usuario se liberan durante el proceso.
Figura 46 muestra una visión general de los directorios de z/OS UNIX utilizados por Developer for System z. La lista siguiente describe cada directorio tocado por Developer for System z, cómo se puede cambiar la ubicación y quién mantiene los datos que contienen.
Los datos de algunos directorios, como /var/rdz/projects/, los mantienen usuarios no administradores del sistema, como gestores de proyectos, y es posible que no dispongan de demasiados privilegios de actualización en z/OS UNIX. Si sólo hay un ID de usuario que mantiene los archivos, no hay ningún problema una vez el ID de usuario se haya convertido en propietario del directorio y de todo lo que contiene.
chown -R IBMUSER /var/rdz/projects/
Cuando hay varios ID de usuario que requieren permisos de actualización para el directorio, puede trabajar con los bits de permiso de grupo.
ADDGROUP RDZPROJ OMVS(GID(1200)) CONNECT IBMUSER GROUP(RDZPROJ) ALTUSER IBMUSER DFLTGRP(RDZPROJ)
chgrp -R IBMUSER /var/rdz/projects/
chmod -R 775 /var/rdz/projects/
Al contrario que las aplicaciones z/OS tradicionales, Developer for System z no es una aplicación monolítica que se pueda identificar fácilmente para el Gestor de carga de trabajo (WLM). Developer for System z está formado por varios componentes que interactúan para proporcionar al cliente acceso a los servicios y datos del host. Tal como se describe en Qué es Developer for System z, 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:
Figura 47 muestra una visión general básica de los subsistemas a través de los cuales se presentan las cargas de trabajo de Developer for System z a WLM.
El Gestor de despliegue de aplicaciones (ADM) está activo en una región CICS y por lo tanto segirá las reglas de clasificación CICS en WLM.
Daemon RSE (RSED), daemon de bloqueo (LOCKD) y Supervisor de trabajos JES (JMON) son tareas iniciadas por Developer for System z (o trabajos por lotes de larga ejecución), cada uno con su espacio de direcciones individual.
Tal como se explica en RSE como aplicación Java, el daemon RSE genera un proceso hijo para cada servidor de agrupaciones de hebras RSE (que soporta un número variable de clientes). Cada agrupación de hebras está activo en un espacio de direcciones aparte (utilizando un iniciador z/OS UNIX, BPXAS). Como se trata de procesos generados, se clasifican mediante las reglas de clasificación WLM OMVS, no las reglas de clasificación de tareas iniciadas.
Los clientes activos en una agrupación de hebras pueden crear muchos otros espacios de direcciones, según las acciones realizadas por los usuarios. Dependiendo de la configuración de Developer for System z, algunas cargas de trabajo, como por ejemplo el servicio de mandatos TSO (TSO cmd) o CARMA, se pueden ejecutar en subsistemas diferentes.
Los espacios de direcciones que aparecen en la lista de Figura 47 siguen permaneciendo en el sistema durante tiempo suficiente para ser visibles pero debe tener en cuenta que debido al diseño de z/OS UNIX, también hay varios espacios de direcciones temporales de vida breve. Estos espacios de direcciones temporales están activos en el subsistema OMVS.
Tenga en cuenta que mientras que las agrupaciones de hebras de RSE utilizan el mismo ID de usuario y un nombre de trabajo parecido al del daemon RSE, todos los espacios de direcciones iniciados por una agrupación de hebras son propiedad del IDE de usuario del cliente que solicita la acción. El ID de usuario cliente también se utiliza como (es parte del) nombre de trabajo para todos los espacios de direcciones basados en OMVS declarados por la agrupación de hebras.
Otros servicios han creado más espacios de direcciones que Developer for System z utiliza, como por ejemplo Gestor de archivos (FMNCAS) o z/OS UNIX REXEC (construcción USS).
WLM utiliza reglas de clasificación para correlacionar el trabajo que entra en el sistema con una clase de servicio. Esta clasificación se basa en calificadores de trabajo. El primer calificador (obligatorio) es el tipo de subsistema que recibe la petición de trabajo. Tabla 29 enumera los tipos de subsistema que pueden recibir cargas de trabajo de Developer for System z.
Tipo de subsistema | Descripción de trabajo |
---|---|
ASCH | Las peticiones de trabajo incluyen todos los programas de transacción APPC planificados por el planificador de transacciones APPC/MVS proporcionados por IBM, ASCH. |
CICS | Las peticiones de trabajo incluyen todas las transacciones procesadas por CICS. |
JES | Las solicitudes de trabajo incluyen todos los trabajos iniciados por JES2 o JES3. |
OMVS | Las peticiones de trabajo incluyen el trabajo procesado en espacios de direcciones hijo bifurcados de z/OS UNIX System Services. |
STC | Las peticiones de trabajo incluyen todo el trabajo iniciado por los mandatos START y MOUNT. STC también incluye espacios de direcciones de componentes del sistema. |
Tabla 30La tabla 2 enumera calificadores adicionales que se pueden utilizar para asignar una carga de trabajo a una clase de servicio específica. Consulte la planificación de MVS: Workload Management (SA22-7602) para obtener más detalles sobre los calificadores de trabajo de la lista.
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Información de contabilidad | x | x | x | x | |
LU | Nombre de LU (*) | x | ||||
PF | Realizar (*) | x | x | |||
PRI | Prioridad | x | ||||
SE | Nombre de entorno de planificación | x | ||||
SSC | Nombre de recogida de subsistema | x | ||||
SI | Instancia de subsistema (*) | x | x | |||
SPM | Parámetro de subsistema | x | ||||
PX | Nombre de Sysplex | x | x | x | x | x |
SY | Nombre de sistema (*) | x | x | x | ||
TC | Clase de transacción/trabajo (*) | x | x | |||
TN | Nombre de transacción/trabajo (*) | x | x | x | x | x |
UI | ID de usuario (*) | x | x | x | x | x |
Tal como se explica en Clasificación de carga de trabajo, Developer for System z crea varios tipos de cargas de trabajo en el sistema. Estas diferentes tareas se comunican entre sí, lo que implica que el tiempo transcurrido real se vuelve importante para evitar los problemas de tiempo de espera para las conexiones entre las tareas. Como resultado, las tareas de Developer for System z deben colocarse en clases de servicio de alto rendimiento o en clases de servicio de rendimiento moderado con una alta prioridad.
Por lo tanto, es recomendable revisar y posiblemente actualizar sus objetivos de WLM. Esto es especialmente cierto para las tiendas MVS tradicionales sin experiencia con cargas de trabajo OMVS para las que el tiempo es muy importante.
Tabla 31 enumera los espacios de direcciones utilizados por Developer for System z. z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Supervisor de trabajos JES | JMON | STC |
Daemon de bloqueo | LOCKD | STC |
Daemon RSE | RSED | STC |
Agrupación de hebras RSE | RSEDx | OMVS |
Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <userid>x | OMVS |
Servicio de mandatos TSO (APPC) | FEKFRSRV | ASCH |
CARMA (por lotes) | CRA<port> | JES |
CARMA (crastart) | <userid>x | OMVS |
CARMA (Pasarela de cliente ISPF) | <userid> y <userid>x | OMVS |
Construcción de MVS (trabajo por lotes) | * | JES |
Construcción de z/OS UNIX (mandatos de shell) | <userid>x | OMVS |
Shell z/OS UNIX | <userid> | OMVS |
Tarea de Gestor de archivos | <userid>x | OMVS |
Gestor de despliegue de aplicaciones | CICSTS | CICS |
Las consideraciones de WLM generales siguientes le pueden ayudar a definir adecuadamente las definiciones de objetivos correctas para Developer for System z:
Cuándo utilizar los objetivos de tiempo de respuesta:
Cuándo utilizar métodos de velocidad:
Todas las tareas iniciadas por Developer for System z, daemon de RSE, daemon de bloqueo y Supervisor de trabajos JES están dando servicio en tiempo real a peticiones de cliente.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Supervisor de trabajos JES | JMON | STC |
Daemon de bloqueo | LOCKD | STC |
Daemon RSE | RSED | STC |
El Supervisor de trabajos JES proporciona todos los servcios relacionados con JES como por ejemplo el sometimiento de trabajos, el examen de archivos en spool y la ejecución de mandatos de operador JES. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea entre mínima y moderada.
El daemon de bloqueo consulta las tablas de cola GRS a petición del cliente y del operador y empareja el resultado con los usuarios de Developer for System z conocidos. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. Se espera que la utilización de recursos sea mínima.
El daemon RSE maneja el inicio de sesión y la autenticación de clientes y gestiona las diferentes agrupaciones de hebras de RSE. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. Se espera que la utilización de recursos sea moderada, con un pico al principio del día de trabajo.
Las cargas de trabajo de OMVS pueden dividirse en dos grupos, agrupaciones de hebras RSE y todo lo demás. Esto es porque todas las cargas de trabajo excepto las agrupaciones de hebras RSE utilizan el ID de usuario de cliente como base para el nombre del espacio de direcciones. (z/OS UNIX sustituirá "x" en la columna "Nombre de tarea" por un número aleatorio de 1 dígito.)
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Agrupación de hebras RSE | RSEDx | OMVS |
Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <userid>x | OMVS |
CARMA (crastart) | <userid>x | OMVS |
CARMA (Pasarela de cliente ISPF) | <userid> y <userid>x | OMVS |
Construcción de z/OS UNIX (mandatos de shell) | <userid>x | OMVS |
Shell z/OS UNIX | <userid> | OMVS |
Tarea de Gestor de archivos | <userid>x | OMVS |
Una agrupación de hebras RSE es como el corazón y el cerebro Developer for System z. Casi todos los datos fluyen por aquí, y los mineros (hebras específicas de usuario) de dentro de la agrupación de hebras controlan las acciones para la mayoría de las otras tareas relacionadas de Developer for System z. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea sustancial.
Las cargas de trabajo restantes finalizarán todas en la misma clase de servicio debido a un convenio de denominación de espacios de direcciones común. Debe especificar un objetivo de varios periodos para esta clase de servicio. Los primeros periodos deberían ser objetivos de tiempo de respuesta percentil de alto rendimiento, mientras que el último periodo debería tener un objetivo de velocidad de rendimiento moderado. Algunas cargas de trabajo como por ejemplo la Pasarela de cliente ISPF informarán de transacciones individuales a WLM, mientras que otras no lo harán.
La Pasarela de cliente ISPF es un servicio ISPF invocado por Developer for System z para ejecutar mandatos TSO y ISPF no interactivos. Esto incluye mandatos explícitos emitidos por el cliente así como mandatos implícitos emitidos por Developer for System z, como por ejemplo obtener una lista de miembros de PDS. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
CARMA es un servidor Developer for System z opcional utilizado para interactuar con Gestores de configuraciones de software (SCM), como por ejemplo CA Endevor® SCM. Developer for System z permite diferentes métodos de inicio para un servidor CARMA, algunos de los cuales se convierten en una carga de trabajo OMVS. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
Cuando un cliente inicia una construcción para un proyecto z/OS UNIX, z/OS UNIX REXEC (o SSH) iniciará una tarea que ejecuta un número de mandatos de shell z/OS UNIX para realizar la construcción. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea entre moderada y sustancial, dependiendo del tamaño del proyecto.
Esta carga de trabajo procesa mandatos shell z/OS UNIX emitidos por el cliente. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
Aunque no se trata de espacios de direcciones de Developer for System z, los procesos hijo del Gestor de archivos generados se incluyen en esta lista porque se pueden iniciar a petición de un cliente de Developer for System z y estas tareas utilizan el mismo convenio de denominación que las tareas de Developer for System z. Estas tareas de Gestor de archivos procesan acciones de conjunto de datos MVS no triviales, como por ejemplo la edición formateada de un archivo VSAM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea entre mínima y moderada.
Los procesos por lotes gestionados por JES los utiliza Developer for System z de varias maneras. La utilización más común es para construcciones MVS, donde un trabajo se somete y supervisa para determinar cuándo finaliza. Pero Developer for System z también podría iniciar un servidor CARMA por lotes y comunicarse con el mediante TCP/IP.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
CARMA (por lotes) | CRA<port> | JES |
Construcción de MVS (trabajo por lotes) | * | JES |
CARMA es un servidor Developer for System z opcional utilizado para interactuar con Gestores de configuraciones de software (SCM), como por ejemplo CA Endevor® SCM. Developer for System z permite diferentes métodos de inicio para un servidor CARMA, algunos de los cuales se convierten en una carga de trabajo JES. Debe especificar un objetivo de velocidad de un periodo y alto rendimiento porque la tarea no comunica las transacciones individuales a WLM. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
Cuando un cliente inicia una construcción para un proyecto MVS, Developer for System z 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.
En las versiones actuales Developer for System z, la Pasarela de cliente ISPF se utiliza para ejecutar mandatos TSO e ISPF no interactivos. Por razones históricas, Developer for System z también soporta la ejecución de estos mandatos a través de una transacción APPC.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Servicio de mandatos TSO (APPC) | FEKFRSRV | ASCH |
El servicio de mandatos TSO puede iniciarse como una transaccción APPC por parte de Developer for System z para ejecutar mandatos TSO e ISPF no interactivos. Esto incluye mandatos explícitos emitidos por el cliente así como mandatos implícitos emitidos por Developer for System z, como por ejemplo obtener una lista de miembros de PDS. Debe especificar un objetivo de varios periodos para esta clase de servicio. Para los primeros periodos debe especificar objetivos de tiempo de respuesta percentil de alto rendimiento. Para el último periodo debe especificar un objetivo de velocidad de rendimiento moderado. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima.
El Gestor de despliegue de aplicaciones es un servidor de Developer for System z opcional que está activo dentro de una región de CICS Transaction Server.
Descripción | Nombre de tarea | Carga de trabajo |
---|---|---|
Gestor de despliegue de aplicaciones | CICSTS | CICS |
El servidor Gestor de despliegue de aplicaciones que está activo dentro de una región CICSTS, permite descargar de forma segura las tareas de gestión CICSTS seleccionadas para los desarrolladores. La utilización de recursos depende mucho de las acciones de usuario y por lo tanto fluctuará, pero se espera que sea mínima. El tipo de clase de servicio que utilice depende del resto de transacciones activas en esta región CICS y por lo tanto no se trata en detalle.
WLM soporta varios tipos de gestión que puede utilizar para CICS:
El objeto se establece en una clase de servicio que gestiona los espacios de dirección CICS. Sólo puede utilizar un objetivo de velocidad de ejecución para esta clase de servicio. WLM utiliza las reglas de clasificación de JES o STC para los espacios de dirección pero no utiliza las reglas de clasificación de subsistemas CICS para transacciones.
Se puede establecer un objetivo de tiempo de respuesta en una clase de servicio asignada a una sola transacción o a un grupo de transacciones. WLM utiliza las reglas de clasificación JES o STC para los espacios de dirección y las reglas de clasificación de subsistema CICS para transacciones.
Tal como se explica en Qué es Developer for System z, RSE (Explorador de sistemas remotos) es el núcleo de Developer for System z. Para gestionar las conexiones y cargas de trabajo de los clientes, RSE está formado por un espacio de direcciones de daemon, que controla los espacios de direcciones de agrupaciones de hebras. El daemon actúa como punto focal a efectos de conexión y gestión, mientras que las agrupaciones de hebras procesan las cargas de trabajo del cliente.
Ello hace que RSE sea el destino principal para ajustar la configuración de Developer for System z. Sin embargo, mantener a cientos de usuarios, cada uno de los cuales utiliza 16 hebras o más, una cantidad determinada de almacenamiento y, posiblemente, 1 o más espacios de direcciones, requiere que la configuración de Developer for System z y z/OS sea la adecuada.
En este capítulo se tratan estos temas:
Utilice la información de esta sección para estimar el uso normal y máximo de recursos por parte de Developer for System z, de manera que pueda planificar acorde la configuración del sistema.
Al utilizar los números y las fórmulas presentadas en esta sección para definir los valores para los límites del sistema, tenga en cuenta que está trabajando con estimaciones bastante precisas. Deje un margen suficiente al establecer los límites del sistema para permitir el uso de recursos por las tareas temporales o por otras tareas, o por usuarios que se conecten varias veces al host simultáneamente. (Por ejemplo, a través de RSE y TN3270).
Las siguientes tablas proporcionan una visión general del número de espacios de direcciones, procesos y hebras utilizados por Developer for System z. En las siguientes secciones puede encontrar más detalles acerca de los números que se presentan aquí:
Tabla 37 proporciona una visión general de los recursos clave utilizados por las tareas iniciadas de Developer for System z. Estos recursos se asignan únicamente una vez. Todos los clientes de Developer for System z los comparten.
Tarea iniciada | Espacios de direcciones | Procesos | Hebras |
---|---|---|---|
JMON | 1 | 1 | 3 |
LOCKD | 1 | 3 | 10 |
RSED | 1 | 3 | 11 |
RSEDx | (a) | 2 | 10 |
Tabla 38 proporciona una visión general de los recursos clave utilizados por el software de seguridad. Estos recursos se asignan para cada cliente de Developer for System z que invoque la función relacionada.
Software requisito | Espacios de direcciones | Procesos | Hebras |
---|---|---|---|
Pasarela de cliente ISPF | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
Gestor de archivos | 1 | 1 | 2 |
Tabla 39 proporciona una visión general de los recursos clave utilizados por cada cliente de Developer for System z al ejecutar la función especificada. Los valores no numéricos, como ISPF, son una referencia al valor correspondiente de Tabla 38.
Acción de usuario
|
Espacios de direcciones
ID de usuario |
Procesos
ID de usuario |
Hebras ID de usuario RSEDx JMON |
||
---|---|---|---|---|---|
Inicio de sesión | - | - | - | 16 | 1 |
Temporizador para tiempo de espera desocupado | - | - | - | 1 | - |
Ampliar PDS(E) | ISPF | ISPF | ISPF | - | - |
Abrir conjunto de datos | ISPF | ISPF | ISPF | - | - |
Mandato TSO | ISPF | ISPF | ISPF | - | - |
Shell de z/OS UNIX | 1 | 1 | 1 | 6 | - |
Construcción de MVS | 1 | - | - | - | - |
Construcción de z/OS UNIX | 3 | 3 | 3 | - | - |
CARMA (por lotes) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 4 | - |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Integración del gestor de archivos | ISPF + FM | ISPF + FM | ISPF + FM | - | - |
Integración del analizador de errores | - | - | - | - | - |
Tabla 40 enumera los espacios de direcciones utilizados por Developer for System z, donde "u" de la columna "Recuento" indica que la cantidad debe multiplicarse por el número de usuarios activos simultáneamente que están utilizando la función. z/OS UNIX sustituirá "x" de la columna "Nombre de tarea" por un número de 1 dígito aleatorio.
Recuento | Descripción | Nombre de tarea | Compartido | Finaliza tras |
---|---|---|---|---|
1 | Supervisor de trabajos JES | JMON | Sí | Nunca |
1 | Daemon de bloqueo | LOCKD | Sí | Nunca |
1 | Daemon RSE | RSED | Sí | Nunca |
(a) | Agrupación de hebras RSE | RSEDx | Sí | Nunca |
lu | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <userid>x | No | 15 minutos o fin de sesión de usuario |
lu | Servicio de mandatos TSO (APPC) | FEKFRSRV | No | 60 minutos o fin de sesión de usuario |
lu | CARMA (por lotes) | CRA<port> | No | 7 minutos o fin de sesión de usuario |
lu | CARMA (crastart) | <userid>x | No | 7 minutos o fin de sesión de usuario |
4u | CARMA (ispf) | (1)<userid> o (3)<userid>x | No | 7 minutos o fin de sesión de usuario |
(b) | Uso simultáneo de la Pasarela de cliente ISPF por 1 usuario | <userid>x | No | Compleción de la tarea |
1u | Construcción de MVS (trabajo por lotes) | * | No | Compleción de la tarea |
3u | Construcción de z/OS UNIX (mandatos de shell) | <userid>x | No | Compleción de la tarea |
1u | Shell de z/OS UNIX | <userid> | No | Fin de sesión de usuario |
(c) | Gestor de archivos | <userid>x | No | Compleción de la tarea |
Utilice la fórmula de Figura 48 para estimar el número máximo de espacios de direcciones utilizados por Developer for System z.
Donde
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC |
---|---|---|---|
1 | No | No | Sí |
1 | No | Sí | No |
1 | Sí | Sí | No |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Utilice la fórmula de Figura 49 para estimar el número máximo de espacios de direcciones utilizados por un cliente de Developer for System z (sin contar los espacios de direcciones temporales no documentados).
Donde
Las definiciones de Tabla 41 pueden limitar el número real de espacios de direcciones.
Ubicación | Límite | Recursos afectados |
---|---|---|
rsed.envvars | maximum.threadpool.process | Limita el número de agrupaciones de hebras RSE |
IEASYMxx | MAXUSER | Limita el número de espacios de direcciones |
ASCHPMxx | MAX | Limita el número de iniciadores APPC para el servicio de mandatos TSO (APPC) |
Tabla 42 enumera el número de procesos por espacio de direcciones utilizados por Developer for System z. "u" de la columna "Espacios de direcciones" indica que la cantidad debe multiplicarse por el número de usuarios activos simultáneamente que están utilizando la función.
Procesos | Espacios de direcciones | Descripción | ID de usuario |
---|---|---|---|
1 | 1 | Supervisor de trabajos JES | STCJMON |
3 | 1 | Daemon de bloqueo | STCLOCK |
3 | 1 | Daemon RSE | STCRSE |
2 | (a) | Agrupación de hebras RSE | STCRSE |
2 | (b) | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) | <userid> |
1 | 1u | Servicio de mandatos TSO (APPC) | <userid> |
1 | 1u | CARMA (por lotes) | <userid> |
1 | 1u | CARMA (crastart) | <userid> |
1 | 1u | CARMA (ispf) | <userid> |
1 | 3u | Construcción de z/OS UNIX (mandatos de shell) | <userid> |
1 | 1u | Shell de z/OS UNIX | <userid> |
1 | (c) | Gestor de archivos | <userid> |
(5) | (u) | SCLM Developer Toolkit | <userid> |
Utilice la fórmula de Figura 50 para estimar el número máximo de procesos utilizados por Developer for System z.
Donde
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC |
---|---|---|---|
1 | No | No | Sí |
2 | No | Sí | No |
7 | Sí | Sí | No |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Utilice la fórmula de Figura 51 para estimar el número máximo de procesos utilizados por un cliente de Developer for System z (sin contar los espacios de direcciones temporales no documentados).
Donde
Las definiciones de Tabla 43 pueden limitar el número real de procesos.
Ubicación | Límite | Recursos afectados |
---|---|---|
BPXPRMxx | MAXPROCSYS | Limita el número total de procesos |
BPXPRMxx | MAXPROCUSER | Limita el número de procesos por UID de z/OS UNIX |
Nota:
Tabla 44 enumera el número de hebras utilizado por las funciones de Developer for System z seleccionadas. "u" de la columna "Hebras" indica que la cantidad debe multiplicarse por el número de usuarios activos simultáneamente que están utilizando la función. El recuento de hebras se enumera por proceso, puesto que los límites están establecidos a este nivel.
Hebras |
ID de usuario | Descripción | ||
---|---|---|---|---|
RSEDx | Activas | Programa de arranque | ||
- | 3 + 1u | - | STCJMON | Supervisor de trabajos JES |
- | 10 | 2 | STCLOCK | Daemon de bloqueo |
- | 11 | 2 | STCRSE | Daemon RSE |
10 (a) + 16u | - | 1 (a) | STCRSE | Agrupación de hebras RSE |
- | 4u (b) | 1u (b) | <userid> | Pasarela de cliente ISPF (Servicio de mandatos TSO y SCLMDT) |
- | 2u | - | <userid> | Servicio de mandatos TSO (APPC) |
1u | 2u | - | STCRSE y <userid> | CARMA (por lotes) |
4u | 2u | - | STCRSE y <userid> | CARMA (crastart) |
5u | 4u | 3u | STCRSE y <userid> | CARMA (ispf) |
- | 1u (d) | 2u | <userid> | Construcción de z/OS UNIX (mandatos de shell) |
6u | 1u | - | STCRSE y <userid> | Shell de z/OS UNIX |
- | 2u (c) | - | <userid> | Gestor de archivos |
- | (5) | - | <userid> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporizador para tiempo de espera desocupado |
Utilice la fórmula de Figura 52 para estimar el número máximo de hebras utilizado por una agrupación de hebras RSE. Utilice la fórmula de Figura 53 para estimar el número máximo de hebras utilizado por el Supervisor de trabajos JES.
Donde
X | SCLMDT | TSO a través de la Pasarela de cliente | TSO a través de APPC | Tiempo de espera |
---|---|---|---|---|
0 | No | No | Sí | No |
0 | No | Sí | No | No |
0 | Sí | Sí | No | No |
1 | No | No | Sí | Sí |
1 | No | Sí | No | Sí |
1 | Sí | Sí | No | Sí |
Y | |
---|---|
0 | No CARMA |
1 | CARMA (por lotes) |
4 | CARMA (crastart) |
5 | CARMA (ispf) |
Las definiciones de Tabla 45 pueden limitar el número real de hebras en un proceso, que es de suma importancia para las agrupaciones de hebras RSE.
Ubicación | Límite | Recursos afectados |
---|---|---|
BPXPRMxx | MAXTHREADS | Limita el número de hebras en un proceso |
BPXPRMxx | MAXTHREADTASKS | Limita el número de tareas de MVS en un proceso. |
BPXPRMxx | MAXASSIZE | Limita el tamaño de espacio de direcciones y, con ello, el almacenamiento disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | Xmx | Establece el tamaño del almacenamiento dinámico Java máximo. Este almacenamiento está reservado, por lo que no está disponible para los bloques de control relacionados con las hebras. |
rsed.envvars | maximum.clients | Limita el número de clientes (y sus hebras) de una agrupación de hebras RSE. |
rsed.envvars | maximum.threads | Limita el número de hebras de cliente en una agrupación de hebras RSE. |
FEJJCNFG | MAX_THREADS | Limita el número de hebras en el Supervisor de trabajos JES. |
RSE es una aplicación Java, que implica que la planificación de uso de almacenamiento (memoria) para Developer for System z debe tener en cuenta dos límites de asignación de almacenamiento, el almacenamiento dinámico Java y el tamaño de Espacio de direcciones.
Java ofrece varios servicios para facilitar los esfuerzos de codificación para las aplicaciones Java. Uno de estos servicios es la gestión de almacenamiento.
La gestión de almacenamiento de Java asigna bloques grandes de almacenamiento, y los utiliza para las solicitudes de almacenamiento de la aplicación. Este almacenamiento gestionado por Java se denomina almacenamiento dinámico Java. La recogida de basura periódica (desfragmentación) reclama el espacio no utilizado del almacenamiento dinámico y reduce su tamaño.
El tamaño máximo de almacenamiento dinámico Java se define en rsed.envvars con la directiva Xmx. Si no se especifica esta directiva, Java utiliza un tamaño predeterminado de 64 MB.
Cada agrupación de hebras RSE (que proporciona servicio a las acciones de cliente) es una aplicación Java individual, por lo que tiene un almacenamiento dinámico Java personal. Tenga en cuenta que todas las agrupaciones de hebras utilizan el mismo archivo de configuración rsed.envvars, por lo que tienen el mismo límite de tamaño de almacenamiento dinámico Java.
El uso de la agrupación de hebras del almacenamiento intermedio Java depende sobre todo de las acciones realizadas por los clientes conectados. Es necesario supervisar regularmente el uso del almacenamiento dinámico para establecer el límite de tamaño de almacenamiento dinámico óptimo. Utilice el mandato de operador modify display process para supervisar el uso del almacenamiento dinámico Java por parte de las agrupaciones de hebras RSE.
Todas las aplicaciones z/OS, incluidas las aplicaciones Java, están activas dentro de un espacio de direcciones, por lo que están limitadas por las limitaciones de tamaño del espacio de direcciones.
El tamaño de espacio de direcciones deseado se especifica durante el inicio, por ejemplo con el parámetro REGION en JCL. Sin embargo, los valores del sistema pueden limitar el tamaño de espacio de direcciones real. Consulte Tamaño del espacio de direcciones para obtener más información sobre estos límites.
Las agrupaciones de hebras RSE heredan los límites de tamaño del espacio de direcciones del daemon RSE. El tamaño del espacio de direcciones debe ser suficiente para albergar el almacenamiento dinámico Java, el propio Java, las áreas de almacenamiento comunes y todos los bloques de control que el sistema crea para soportar la actividad de las agrupaciones de hebras, por ejemplo, un TCB (bloque de control de tareas) por hebra. Tenga en cuenta que parte del uso de este almacenamiento está por debajo de la línea de 16 MB.
Debe supervisar el tamaño del espacio de direcciones real antes de cambiar ningún valor que tenga una influencia sobre el mismo, como cambiar el tamaño del almacenamiento dinámico Java o la cantidad de usuarios soportados por una única agrupación de hebras. Utilice el software de supervisión del sistema habitual para rastrear el uso del almacenamiento real por Developer for system z. Si no dispone de una herramienta de supervisión par ello, se puede reunir la información básica con herramientas como la vista SDSF DA o TASID (una herramienta de información del sistema tal cual disponible en el sitio Web de ISPF "Soporte y descargas").
Tal como se ha indicado anteriormente, el uso real que Developer for system z hace del almacenamiento está muy condicionado por la actividad del usuario. Algunas acciones utilizan una cantidad fija de almacenamiento (por ejemplo, el inicio de sesión), mientras que otras son variables (por ejemplo, enumerar conjuntos de datos con un calificador de alto nivel especificado).
Tenga en cuenta que RSE muestra el almacenamiento dinámico Java actual y el límite de tamaño del espacio de direcciones durante el inicio en el mensaje de consola FEK004I.
Utilice cualquiera de los siguientes casos de ejemplo si la supervisión muestra que el almacenamiento dinámico Java actual es insuficiente para la carga de trabajo real:
Las pantallas de las siguientes figuras muestran algunos número del uso de almacenamiento de ejemplo para una configuración de Developer for system z predeterminada con una modificación. El tamaño máximo de almacenamiento dinámico Java se establece en 10 MB, dado que un máximo pequeño resultará en un percentil de uso mayor y los límites de tamaño del almacenamiento dinámico se alcanzarán antes.
Tamaño máx. almacenamiento dinámico=10MB y Tamaño AS privado=1,959MB inicio BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(7%) Clientes(0) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.01 2740 72 LOCKD 1.60 28.7M 14183 RSED 4.47 32.8M 15910 RSED8 1.15 27.4M 12612 inicio de sesión 1 BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.01 2864 81 LOCKD 1.64 28.8M 14259 RSED 4.55 32.8M 15980 RSED8 3.72 55.9M 24128 inicio de sesión 2 BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(23%) Clientes(2) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.02 2944 86 LOCKD 1.66 28.9M 14268 RSED 4.58 32.9M 16027 RSED8 4.20 57.8M 25205 inicio de sesión 3 BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(37%) Clientes(3) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.02 3020 91 LOCKD 1.67 29.0M 14277 RSED 4.60 32.9M 16076 RSED8 4.51 59.6M 26327 inicio de sesión 4 BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(41%) Clientes(4) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.02 3108 96 LOCKD 1.68 29.0M 14286 RSED 4.61 32.9M 16125 RSED8 4.77 62.3M 27404
inició de sesión 5 BPXM023I (STCRSE) ProcessId(268 ) Uso de memoria(41%) Clientes(4) ProcessId(33554706) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.03 3184 101 LOCKD 1.69 29.1M 14295 RSED 4.64 32.9M 16229 RSED8 4.78 62.4M 27413 RSED9 4.60 56.6M 24065
Figura 54 y Figura 55 muestran un caso de ejemplo en el que 5 clientes inician sesión en un daemon RSE con un almacenamiento dinámico Java de 10 MB.
Tamaño máx. almacenamiento dinámico=10MB y Tamaño AS privado=1,959MB inicio BPXM023I (STCRSE) ProcessId(212 ) Uso de memoria(7%) Clientes(0) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.01 2736 71 LOCKD 1.73 30.5M 14179 RSED 4.35 32.9M 15117 RSED8 1.43 27.4M 12609 inicio de sesión BPXM023I (STCRSE) ProcessId(212 ) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.01 2864 80 LOCKD 1.76 30.6M 14255 RSED 4.48 33.0M 15187 RSED8 3.53 53.9M 24125 ampliar árbol de MVS grande (195 conjuntos de datos) BPXM023I (STCRSE) ProcessId(212 ) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 0.01 2864 80 LOCKD 1.78 30.6M 14255 RSED 4.58 33.1M 16094 RSED8 4.28 56.1M 24740 ampliar PDS pequeño (21 miembros) BPXM023I (STCRSE) ProcessId(212 ) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- IBMUSER2 0.22 2644 870 JMON 0.01 2864 80 LOCKD 1.78 30.6M 14255 RSED 4.61 33.1M 16108 RSED8 4.40 56.2M 24937 abrir miembro de tamaño medio (86 líneas) BPXM023I (STCRSE) ProcessId(212 ) Uso de memoria(13%) Clientes(1) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- IBMUSER2 0.22 2644 870 JMON 0.01 2864 80 RSED 4.61 33.1M 16108 RSED8 8.12 62.7M 27044
Figura 56 muestra un caso de ejemplo en el que 1 cliente inicia sesión en un daemon RSE con un almacenamiento dinámico Java de 10 MB y edita un miembro PDS.
La mayoría de datos relacionados con Developer for System z que no se escriben una una sentencia DD terminan en un archivo z/OS UNIX. El programador del sistema controla qué datos se escriben y a dónde van. Sin embargo, no controla la cantidad de datos que se escriben.
Los datos pueden agruparse en estas categorías:
Tal como se documenta en Resolución de problemas de configuración, Developer for System z escribe las anotaciones del host relacionadas con RSE en los siguientes directorios de z/OS UNIX:
De forma predeterminada, en las anotaciones sólo se escriben los mensajes de error y de aviso. De manera que, si todo sale según se prevee, estos directorios deberían contener únicamente archivos vacíos o prácticamente vacíos (sin contar las anotaciones de auditoría).
Puede habilitar las anotaciones de mensajes informativos, preferiblemente bajo la dirección del centro de soporte de IBM, cosa que aumenta significativamente el tamaño de los archivos de anotaciones.
inicio $ ls -l /var/rdz/logs total 144 -rw-rw-rw- 1 STCRSE STCGRP 33642 10 Jul 12:10 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1442 10 Jul 12:10 rseserver.log inicio de sesión $ ls -l /var/rdz/logs total 144 drwxrwxrwx 3 IBMUSER SYS1 8192 10 Jul 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 10 Jul 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1893 10 Jul 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 160 -rw-rw-rw- 1 IBMUSER SYS1 3459 10 Jul 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 303 10 Jul 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 10 Jul 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 7266 10 Jul 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 stdout.log fin de sesión $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 10 Jul 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 10 Jul 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2208 10 Jul 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 296 -rw-rw-rw- 1 IBMUSER SYS1 6393 10 Jul 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 609 10 Jul 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 10 Jul 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 45157 10 Jul 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 10 Jul 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 176 10 Jul 12:11 stdout.log detener $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 10 Jul 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 10 Jul 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2490 10 Jul 12:12 rseserver.log
Figura 57 muestra el uso de espacio mínimo del sistema de archivos de z/OS UNIX al utilizar el nivel de depuración 2 (mensajes informativos).
A excepción de las anotaciones de auditoría, los archivos de anotaciones se sobrescriben cada vez que se reinicia (para la tarea iniciada RSE) o se finaliza la sesión (para un cliente), manteniendo el tamaño total adecuado. La directiva keep.last.log de rsed.envvars cambia esto ligeramente, ya que puede hacer que RSE mantenga una copia de las anotaciones anteriores. Las copias antiguas se eliminan siempre.
Se envía un mensaje de aviso a la consola cuando el sistema de archivos que contiene los archivos de anotaciones de auditoría se está quedando sin espacio libre y la auditoría está activa. Este mensaje de consola (FEK103E) se repite regularmente hasta que se ha resuelto el problema de falta de espacio. Consulte Mensajes de consola para obtener una lista de los mensajes de consola generados por RSE.
Las definiciones de Tabla 46 controlan qué datos se graban en los directorios de anotaciones y dónde ubican los directorios.
Ubicación | Directiva | Función |
---|---|---|
resecomm.properties | debug_level | Establecer el nivel de detalle de anotaciones predeterminado |
rsed.envvars | keep.last.log | Conserva una copia de las anotaciones previas antes del inicio/inicio de sesión. |
rsed.envvars | enable.audit.log | Mantener un rastreo de auditoría de las acciones de clientes. |
rsed.envvars | enable.standard.log | Escribir las secuencias stdout y stderr de la agrupación (o agrupaciones) de hebras en un archivo de anotaciones. |
rsed.envvars | DSTORE_TRACING_ON | Habilitar anotaciones de acciones de DataStore. |
rsed.envvars | DSTORE_MEMLOGGING_ON | Habilitar anotaciones de uso de memoria de DataStore. |
Mandato de operador | modify rsecommlog <level> | Cambiar dinámicamente el nivel de detalle de anotaciones de rsecomm.log |
Mandato de operador | modify rsedaemonlog <level> | Cambiar dinámicamente el nivel de detalle de anotaciones de rsedaemon.log |
Mandato de operador | modify rseserverlog <level> | Cambiar dinámicamente el nivel de detalle de anotaciones de rseserver.log |
Mandato de operador | modify rsestandardlog {on|off} | Cambiar dinámicamente la actualización de std*.*.log |
rsed.envvars | daemon.log | Vía de acceso inicial para la tarea iniciada RSE y las anotaciones de auditoría. |
rsed.envvars | user.log | Vía de acceso inicial de las anotaciones de usuario. |
Developer for System z, junto con el software requisito, como la Pasarela de cliente ISPF, también escribe datos temporales en /tmp and /var/rdz/WORKAREA. La cantidad de datos escritos aquí como resultado de las acciones de usuario no es predecible, de manera que debe tener mucho espacio libre en los sistemas de archivos que contienen estos directorios.
Developer for system z siempre intenta limpiar estos archivos temporales, pero se puede realizar la limpieza manual, tal como se documenta en (Opcional) Limpieza de WORKAREA, en cualquier momento.
RSE, Java y z/OS UNIX utilizan las variables de entorno definidas en rsed.envvars. El archivo de ejemplo que viene con Developer for System z está destinado a instalaciones pequeñas-medias que no requieren los componentes adicionales de Developer for System z. rsed.envvars, archivo de configuración de RSE describe cada variable definida en el archivo de ejemplo, donde las siguientes variables requieren especial atención:
RSE es una aplicación Java, lo que significa que está activo en el entorno z/OS UNIX. Ello hace que BPXPRMxx se convierta en un miembro parmlib crucial, ya que contiene los parámetros que controlan el entorno z/OS UNIX y los sistemas de archivos. BPXPRMxx se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Utilice el mandato de operador SETOMVS o SET OMVS para aumentar o disminuir dinámicamente (hasta la próxima IPL) el valor de cualquiera de las variables BPXPRMxx anteriores. Para realizar un cambio permanente, edite el miembro BPXPRMxx que se utilizará para las IPL. Consulte la publicación MVS System Commands (SA22-7627) para obtener más información sobre estos mandatos de operador.
Las definiciones siguientes son subparámetros de la sentencia NETWORK.
Se recomienda añadir las siguientes definiciones a la tarjeta EXEC del JCL de los servidores de Developer for System z.
El Supervisor de trabajos JES utiliza las variables de entorno definidas en FEJJCNFG. El archivo de ejemplo que viene con Developer for System z está destinado a instalaciones pequeñas-medias. FEJJCNFG, archivo de configuración del supervisor de trabajos JES describe cada variable definida en el archivo de ejemplo, donde las siguientes variables requieren especial atención:
IEASYSxx contiene los parámetros de sistema y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
IVTPRMxx establece los parámetros para el Communication Storage Manager (CSM) y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
El miembro parmlib de ASCHPMxx contiene información de planificación para el planificador de transacciones ASCH y se describe en el manual MVS Initialization and Tuning Reference (SA22-7592). Se conoce que las siguientes directivas afectan a Developer for System z:
Dado que las cargas de trabajo pueden cambiar la necesidad de los recursos del sistema, es necesario supervisar el sistema regularmente para medir el uso de recursos, de manera que se pueda ajustar Rational Developer for System z y las configuraciones del sistema en respuesta a los requisitos de los usuarios. Los siguientes mandatos se pueden utilizar como ayuda en este proceso de supervisión.
Las agrupaciones de hebras RSE son el punto focal para la actividad de usuarios en Developer for System z y, por ello, requieren supervisión para que su uso sea el óptimo. Se puede consultar el daemon RSE para obtener información que no se puede reunir con las herramientas de supervisión de sistemas normales.
FEK004I Daemon Rse: Tamaño máx. almacenamiento dinámico=65MB y Tamaño AS privado=1,959MB
f rsed,appl=d p BPXM023I (STCRSE) ProcessId(16777456) Uso de memoria(33%) Clientes(4) Oden(1)
Cuando se utiliza la opción DETAIL del mandato de modificación DISPLAY PROCESS, se proporciona más información:
f rsed,appl=d p,detail BPXM023I (STCRSE) ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1) PROCESS LIMITS: CURRENT HIGHWATER LIMIT JAVA HEAP USAGE(%) 10 56 100 CLIENTS 0 25 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
La mayoría de límites de z/OS UNIX que afectan a Developer for System z se pueden visualizar con mandatos de operador. Algunos mandatos muestran incluso el uso simultáneo y la marca de límite superior para un límite concreto. Consulte la publicación MVS System Commands (SA22-7627) para obtener más información sobre estos mandatos.
d omvs,o BPXO043I 13.10.16 DISPLAY OMVS 066 OMVS 000D ETC/INIT WAIT OMVS=(M7) CURRENT UNIX CONFIGURATION SETTINGS: MAXPROCSYS = 256 MAXPROCUSER = 16 MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT MAXCPUTIME = 1000 MAXUIDS = 200 MAXPTYS = 256 MAXMMAPAREA = 256 MAXASSIZE = 209715200 MAXTHREADS = 200 MAXTHREADTASKS = 1000 MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096 IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000 IPCMSGNIDS = 500 IPCSEMNIDS = 500 IPCSEMNOPS = 25 IPCSEMNSEMS = 1000 IPCSHMMPAGES = 25600 IPCSHMNIDS = 500 IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144 SUPERUSER = BPXROOT FORKCOPY = COW STEPLIBLIST = USERIDALIASTABLE= SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1 SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1 PRIORITYPG VALUES: NONE PRIORITYGOAL VALUES: NONE MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864 SHRLIBMAXPAGES = 4096 VERSION = / SYSCALL COUNTS = NO TTYGROUP = TTY SYSPLEX = NO BRLM SERVER = N/A LIMMSG = NONE AUTOCVT = OFF RESOLVER PROC = DEFAULT AUTHPGMLIST = NONE SWA = BELOW
d omvs,l BPXO051I 14.05.52 DISPLAY OMVS 904 OMVS 0042 ACTIVE OMVS=(69) SYSTEM WIDE LIMITS: LIMMSG=SYSTEM CURRENT HIGHWATER SYSTEM USAGE USAGE LIMIT MAXPROCSYS 1 4 256 MAXUIDS 0 0 200 MAXPTYS 0 0 256 MAXMMAPAREA 0 0 256 MAXSHAREPAGES 0 10 4096 IPCMSGNIDS 0 0 500 IPCSEMNIDS 0 0 500 IPCSHMNIDS 0 0 500 IPCSHMSPAGES 0 0 262144 * IPCMSGQBYTES --- 0 262144 IPCMSGQMNUM --- 0 10000 IPCSHMMPAGES --- 0 256 SHRLIBRGNSIZE 0 0 67108864 SHRLIBMAXPAGES 0 0 4096
El mandato muestra las marcas de nivel superior y el uso actual de un proceso individual cuando se especifica también la palabra clave PID=processid.
d,omvs,l,pid=16777456 BPXO051I 14.06.28 DISPLAY OMVS 645 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - PROCESS LIMITS: LIMMSG=NONE CURRENT HIGHWATER PROCESS USAGE USAGE LIMIT MAXFILEPROC 83 103 256 MAXFILESIZE --- --- NOLIMIT MAXPROCUSER 97 99 200 MAXQUEUEDSIGS 0 1 1000 MAXTHREADS 9 14 200 MAXTHREADTASKS 9 14 1000 IPCSHMNSEGS 0 0 500 MAXCORESIZE --- --- 4194304 MAXMEMLIMIT 0 0 16383P
d omvs,p BPXO046I 14.35.38 DISPLAY OMVS 092 OMVS 000E ACTIVE OMVS=(33) PFS CONFIGURATION INFORMATION PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED TCP SOCKETS AF_INET EZBPFINI 50000 244 8146 UDS SOCKETS AF_UNIX BPXTUINT 64 6 10 ZFS LOCAL FILE SYSTEM IOEFSCM 14:32.00 RECYCLING HFS LOCAL FILE SYSTEM GFUAINIT BPXFTCLN CLEANUP DAEMON BPXFTCLN BPXFTSYN SYNC DAEMON BPXFTSYN BPXFPINT PIPE BPXFPINT BPXFCSIN CHAR SPECIAL BPXFCSIN NFS REMOTE FILE SYSTEM GFSCINIT PFS NAME DESCRIPTION ENTRY STATUS FLAGS TCP41 SOCKETS EZBPFINI ACT CD TCP42 SOCKETS EZBPFINI ACT TCP43 SOCKETS EZBPFINI INACT SD TCP44 SOCKETS EZBPFINI INACT PFS PARM INFORMATION HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100) CURRENT VALUES: FIXED(55) VIRTUAL(100) NFS biod(6)
d omvs,pid=16777456 BPXO040I 15.30.01 DISPLAY OMVS 637 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE 0E08A00000000000 005E6DF0 OMVS .927 RCV FU 0E08F00000000001 005E6C58 .001 PTX JYNV 0E09300000000002 005E6AC0 7.368 PTX JYNV 0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV 0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV 0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Cuando se admite que un número grande de clientes se conecten al host, no sólo Developer for System z debe ser capaz de manejar la carga de trabajo, sino que la infraestructura de red también debe serlo. La gestión de redes es un tema amplio y bien documentado que no está dentro del ámbito de la documentación de Developer for System z. Por ello, únicamente se facilitan los siguientes puntos:
Developer for System z utiliza sistemas de archivos de z/OS UNIX para almacenar varios tipos de datos, como archivos de anotaciones y temporales. Utilice el mandato de z/OS UNIX df para ver cuántos descriptores de archivos quedan disponibles, y cuánto espacio libre queda hasta que se crea la siguiente extensión del conjunto de datos HFS o zFS subyacente.
$ df Montado en Filesystem Disp/Total Archivos Estado /tmp (OMVS.TMP) 1393432/1396800 4294967248 Disponible /u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Disponible /usr/lpp/rdz (OMVS.FEK.HHOP760) 3062/43200 4294967147 Disponible /var (OMVS.VAR) 27264/31680 4294967054 Disponible
La siguiente configuración de ejemplo muestra la configuración necesaria para soportar estos requisitos:
De forma predeterminada, Developer for system z intenta añadir 60 usuarios a una única agrupación de hebras. Sin embargo, nuestros requisitos indican que el tiempo de espera de inactividad estará activo. Tabla 44 muestra que esto añadirá una hebra por cada cliente conectado. Esta hebra es una hebra temporizadora, por lo que está activa constantemente. Esto impedirá que RSE coloque a 60 usuarios en una única agrupación de hebras, dado que 60*(16+1)=1020, y maximum.threads está establecido en 1000 de forma predeterminada.
Podríamos aumentar maximum.threads, pero dado que el requisito es que la media sea 5 MB de almacenamiento dinámico Java por cada usuario, decidimos bajar maximum.clients a 50. Con esto, sigue dentro del tamaño de almacenamiento dinámico Java máximo de 256 MB predeterminado (5*50 = 250).
Con 50 clientes por agrupación de hebras y la necesidad de admitir 500 conexiones, sabemos que necesitaremos 10 espacios de direcciones de agrupaciones de hebras.
Utilizando las fórmulas mostradas anteriormente en este capítulo y los criterios indicados al principio de esta sección, podemos determinar el uso de los recursos que se deben acomodar.
3 + A + N*(x + y + z) + (2 + N*0.01)
3 + 10 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1020
x + y + z
1 + 1 + 1 = 3
7 + 2*A + N*(x + y + z) + (10 + N*0.05)
7 + 2*10 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1562
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
9 + N*(16 + x + y + z) + (20 + N*0.1)
9 + 60*(16 + 1 + 4 + 0) + (20 + 60*0.1) = 1295
3 + N
3 + 500 = 503
500 + 3 = 503
Los 3 ID de usuario extras son para STCJMON, STCLOCK y STCRSE, los ID de usuario de las tareas iniciadas de Developer for System z.
Ahora que conocemos los números del uso de recursos, podemos personalizar las directivas de limitación con los valores adecuados.
Este cambio es opcional; RSE iniciará nuevas agrupaciones de hebras según sea necesario
Después de activar los límites del sistema según se explica en Definir límites, podemos empezar a supervisar la utilización de recursos por parte de Developer for System z para ver si es necesario ajustar varias variables. Figura 58 muestra la utilización de recursos después de que 495 usuarios hayan iniciado la sesión. (El ejemplo de la figura muestra sólo el inicio de sesión. No se han indicado acciones de usuario en el ejemplo.)
BPXM023I (STCRSE) ProcessId(16779764) Uso de memoria(10%) Clientes(50) Orden(1) ProcessId(67108892) Uso de memoria(16%) Clientes(50) Orden(2) ProcessId(67108908) Uso de memoria(10%) Clientes(50) Orden(3) ProcessId(67108898) Uso de memoria(16%) Clientes(50) Orden(4) ProcessId(67108916) Uso de memoria(16%) Clientes(50) Orden(5) ProcessId(67108897) Uso de memoria(16%) Clientes(50) Orden(6) ProcessId(67108921) Uso de memoria(16%) Clientes(50) Orden(7) ProcessId(83886146) Uso de memoria(16%) Clientes(50) Orden(8) ProcessId(67108920) Uso de memoria(16%) Clientes(50) Orden(9) ProcessId(3622) Uso de memoria(8%) Clientes(45) Orden(10) Jobname Tiempo Cpu Almacenamiento EXCP -------- ----------- ------- ---------- JMON 1.74 43.0M 2753 LOCKD 10.05 31.9M 24621 RSED 6.65 40.1M 41780 RSED1 8.17 187.0M 76566 RSED2 13.04 184.9M 78946 RSED3 17.77 181.1M 76347 RSED4 11.63 174.9M 74638 RSED5 15.27 172.9M 72883 RSED6 13.85 180.8M 75031 RSED7 9.79 174.3M 76636 RSED8 21.59 176.1M 70583 RSED8 18.88 184.7M 76953 RSED9 9.52 189.8M 80490
z/OS es un sistema operativo sumamente personalizable, y los cambios de sistema (a veces pequeños) pueden afectar considerablemente al rendimiento global. En este capítulo se resaltan algunos de los cambios que se pueden hacer para mejorar el rendimiento de Developer for System z.
Consulte las publicaciones MVS Initialization and Tuning Guide (SA22-7591) y UNIX System Services Planning (GA22-7800) para obtener más información acerca del ajuste del sistema.
zFS (sistema de archivos de zSeries) y HFS (sistema de archivos jerárquico) son sistemas de archivos UNIX que pueden utilizarse en un entorno z/OS UNIX. Sin embargo, zFS proporciona las siguientes ventajas y características:
Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de zFS.
Cada proceso z/OS UNIX que tenga una STEPLIB que se propague de padre a hijo o a través de un exec consumirá unos 200 bytes de ECSA (área de almacenamiento común ampliada). Si no se define ninguna variable de entorno STEPLIB, o si se define como STEPLIB=CURRENT, z/OS UNIX propaga todas las asignaciones de TASKLIB, STEPLIB y JOBLIB actualmente activas durante una función fork(), spawn() o exec().
Developer for System z tiene el valor predeterminado STEPLIB=NONE codificado en rsed.envvars, como se describe en la sección dedicada al archivo de configuración rsed.envvars. Por los motivos mencionados más arriba, no conviene cambiar esta directiva, y en cambio es aconsejable colocar los conjuntos de datos tomados como objetivo en LINKLIST o en LPA (área de módulos residentes).
Algunas bibliotecas del sistema y algunos módulos de carga se utilizan intensivamente en z/OS UNIX y en las actividades de desarrollo de aplicaciones. El hecho de mejorar el acceso a ellas (por ejemplo, añadirlas al área de módulos residentes, LPA) puede mejorar el rendimiento del sistema. En el manual MVS Initialization and Tuning Reference (SA22-7592) hallará más información sobre cómo cambiar los miembros SYS1.PARMLIB descritos a continuación:
Los programas C (incluida la shell de z/OS UNIX), cuando se ejecutan, suelen utilizar rutinas de la biblioteca de tiempo de ejecución de Language Environment (LE). Como promedio, unos 4 MB de la biblioteca de tiempo de ejecución se cargan en memoria para cada espacio de direcciones que se ejecute en un programa habilitado para LE, y se copian en cada bifurcación.
CEE.SCEELPA
El conjunto de datos CEE.SCEELPA contiene un subconjunto de rutinas de tiempo de ejecución de LE, que se utilizan muy a menudo en z/OS UNIX. Debe añadir este conjunto de datos a SYS1.PARMLIB(LPALSTxx) para obtener el máximo rendimiento. Así, los módulos se leen del disco una sola vez y se colocan en una ubicación compartida.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Conviene asimismo colocar las bibliotecas de tiempo de ejecución de LE CEE.SCEERUN y CEE.SCEERUN2 en LINKLIST, añadiendo los conjuntos de datos a SYS1.PARMLIB(LNKLSTxx) o a SYS1.PARMLIB(PROGxx). Ello elimina la actividad adicional que supone utilizar la STEPLIB de z/OS UNIX, y se reduce la entrada/salida debido a la gestión por parte de LLA y VLF, o de productos similares.
Si decide que no quiere colocar estas bibliotecas en LINKLIST, debe configurar la sentencia STEPLIB pertinente en rsed.envvars, como se describe en la sección dedicada al archivo de configuración rsed.envvars. Aunque este método siempre utiliza almacenamiento virtual adicional, podrá mejorar el rendimiento definiendo las bibliotecas de tiempo de ejecución de LE en LLA o en un producto similar. Esto reduce la E/S necesaria para cargar los módulos.
En los sistemas cuya actividad principal es el desarrollo de aplicaciones, el rendimiento también podrá mejorar si coloca el editor de enlaces en la LPA dinámica, añadiendo las líneas siguientes a SYS1.PARMLIB(PROGxx):
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN) LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
En el caso del desarrollo C/C++, también puede añadir el conjunto de datos de compilador CBC.SCCNCMP a SYS1.PARMLIB(LPALSTxx).
Las sentencias anteriores son ejemplos de posibles candidatos a la LPA, pero las necesidades en su local puede ser distintas. Consulte la publicación Language Environment Customization (SA22-7564) para obtener más información acerca de la colocación de otros módulos de carga de LE en la LPA dinámica. Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de la colocación de módulos de carga de compilador C/C++ en la LPA dinámica.
Para mejorar el rendimiento de la comprobación de seguridad que se realiza para z/OS UNIX, defina el perfil BPX.SAFFASTPATH en la clase FACILITY del software de seguridad. Así se reduce la actividad adicional que supone realizar comprobaciones de seguridad en z/OS UNIX para una gran variedad de operaciones. Entre ellas está la comprobación de acceso a los archivos de inclusión, la comprobación de acceso a IPC y la comprobación de ser propietario del proceso. Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de este perfil.
Cada local tiene sus necesidades específicas, y puede personalizar el sistema operativo z/OS para poder sacar el mayor partido de los recursos disponibles y responder a dichas necesidades. Con la gestión de cargas de trabajo (WLM), se definen objetivos de rendimiento y se asigna una importancia de negocio a cada objetivo. Los objetivos se definen para el trabajo en términos de negocio, y el sistema decide la cantidad de recursos (por ejemplo, la cantidad de CPU y de almacenamiento) que hay que dar al trabajo para responder a su objetivo.
El rendimiento de Developer for System z se puede equilibrar estableciendo los objetivos correctos para sus procesos. A continuación figuran algunas directrices generales:
Consulte la publicación MVS Planning Workload Management (SA22-7602) para obtener más información sobre este tema.
Con una memoria dinámica de tamaño fijo, no se producen ampliaciones ni contracciones de la memoria dinámica, lo que puede aumentar notablemente el rendimiento en algunas situaciones. Sin embargo, el hecho de utilizar una memoria dinámica de tamaño fijo no suele ser una buena idea, porque retarda el inicio de la recogida de basura hasta que la memoria dinámica esté llena, y en ese momento pasará a ser una tarea importante. También aumenta el riesgo de fragmentación, lo que exige una compactación de la memoria dinámica. Por lo tanto, solo debe utilizar memorias dinámicas de tamaño fijo después de haberlas probado debidamente o cuando así lo indique el centro de soporte de IBM. Consulte la publicación Java Diagnostics Guide (SC34-6650) para obtener más información acerca de los tamaños del almacenamiento dinámico y la recogida de basura.
De forma predeterminada, el tamaño inicial del almacenamiento dinámico de una máquina virtual (JVM) en z/OS Java es de 1 megabyte. El tamaño máximo es de 64 megabytes. Los límites se pueden establecer con las opciones -Xms (inicial) y -Xmx (máximo) de la línea de mandatos Java.
En Developer for System z, las opciones de línea de mandatos Java se definen en la directiva _RSE_JAVAOPTS del archivo rsed.envvars, como se describe en: Definir parámetros de inicio Java adicionales con _RSE_JAVAOPTS.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
La opción -Xquickstart puede utilizarse para mejorar el tiempo de inicio de algunas aplicaciones Java. -Xquickstart hace que el compilador JIT (Just In Time) se ejecute con un subconjunto de optimizaciones; es decir, una compilación rápida. Esta compilación rápida permite mejorar el tiempo de inicio.
-Xquickstart es adecuada para aplicaciones de corta ejecución, especialmente para aquellas en las que el tiempo de ejecución no está concentrado en un pequeño número de métodos. -Xquickstart puede degradar el rendimiento si se utiliza en aplicaciones de larga ejecución que contienen métodos dinámicos.
Para habilitar la opción -Xquickstart para el servidor RSE, añada la directiva siguiente al final de rsed.envvars:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
La máquina virtual Java (JVM) de IBM versión 5 y posteriores permite compartir clases de aplicación y programa de arranque entre las JVM almacenándolas en una memoria caché de memoria compartida. El hecho de compartir clases reduce el consumo global de memoria virtual cuando hay más de una JVM que comparte una caché. El hecho de compartir clases también reduce el tiempo de arranque de una JVM después de haberse creado la caché.
La caché de clases compartidas es independiente de las JVM activas y persiste más allá del tiempo de vida de la JVM que creó la caché. Dado que la caché de clases compartidas persiste más allá del tiempo de vida de las JVM, la caché se actualiza dinámicamente para reflejar las modificaciones que se hayan podido hacer en los JAR o en las clases del sistema de archivos.
La actividad adicional que supone crear y poblar una caché nueva es mínima. El coste en tiempo del arranque de una sola JVM se suele situar entre 0 y el 5% más de tiempo si se compara con un sistema que no utilice clases compartidas, y depende de la cantidad de clases cargadas. La mejora del tiempo de arranque de JVM con una caché poblada se suele situar entre el 10% y el 40% menos de tiempo si se compara con un sistema que no utilice clases compartidas, y depende del sistema operativo y del número de clases que se carguen. Si hay múltiples JVM en ejecución concurrente, el tiempo de arranque global mejorará.
Consulte la publicación Java SDK and Runtime Environment User Guide para obtener más información acerca del compartimiento de clases.
Para habilitar el compartimiento de clases para el servidor RSE, añada la directiva siguiente al final de rsed.envvars. La primera sentencia define una caché llamada RSE con acceso de grupo, y permite que el servidor RSE se inicie incluso si falla la prestación de compartir clases. La segunda sentencia es opcional y establece que el tamaño de la caché sea igual a 6 megabytes (el valor predeterminado del sistema es de 16 MB). La tercera sentencia añade los parámetros de compartimiento de clases a las opciones de inicio de Java.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
El tamaño máximo de la caché teórica compartida es 2 GB. El tamaño de caché que se puede especificar está limitado por la cantidad de memoria física y de espacio de intercambio físico disponible en el sistema. Dado que el espacio de direcciones virtuales de un proceso se comparte entre la memoria caché de clases compartidas y el almacenamiento dinámico de Java, el aumento del tamaño máximo del almacenamiento dinámico de Java reducirá el tamaño de la memoria caché de clases compartidas que puede crear.
El acceso a la caché de clases compartidas está limitado por los permisos del sistema operativo y por los permisos de la seguridad Java.
Por defecto, las cachés de clases se crean con seguridad a nivel de usuario, por lo que el usuario que ha creado la caché es el único que puede acceder a ella. En z/OS UNIX, existe una opción, groupAccess, que da acceso a todos los usuarios del grupo primario del usuario que creó la caché. Sin embargo, sea cual sea el nivel de acceso que se emplee, el único que puede destruir una caché es el usuario que la ha creado o un usuario root (UID 0).
Consulte la publicación Java SDK and Runtime Environment User Guide para obtener más información acerca de las opciones de seguridad adicionales mediante un gestor de seguridad (SecurityManager) Java.
Algunos de los valores de SYS1.PARMLIB(BPXPRMxx) afectan al rendimiento de las clases compartidas. Si se emplean valores incorrectos, las clases compartidas podrían dejar de funcionar. Estos valores también podrían afectar al rendimiento. Para obtener más información acerca de las implicaciones sobre el rendimiento y la utilización de estos parámetros, consulte las publicaciones MVS Initialization and Tuning Reference (SA22-7592) y UNIX System Services Planning (GA22-7800). Los parámetros más significativos de BPXPRMxx que afectan a la operación de las clases compartidas son los siguientes:
Estos valores afectan a la cantidad de páginas de memoria compartida disponibles para la JVM. El tamaño de páginas compartidas en el caso de un servicio de sistema z/OS UNIX de 31 bites se ha fijado en 4 KB. Las clases compartidas intentan crear una caché de 16 MB por defecto. Por tanto, establezca IPCSHMMPAGES en un valor superior a 4096.
Si establece un tamaño de caché utilizando -Xscmx, la JVM redondeará el valor por exceso al megabyte más cercano. Debe tenerlo en cuenta cuando establezca IPCSHMMPAGES en su sistema.
Estos valores afectan a la cantidad de semáforos disponibles en los procesos UNIX. Las clases compartidas utilizan semáforos IPC para la comunicación entre máquinas virtuales Java (JVM).
La caché de clases compartidas necesita espacio en disco en el que almacenar información de identificación sobre las cachés que existen en el sistema. Esta información se almacena en /tmp/javasharedresources. Si el directorio de información de identificación se suprime, la JVM no puede identificar las clases compartidas en el sistema y debe volver a crear la caché.
El mandato de línea Java -Xshareclasses puede tener varias opciones, algunas de las cuales son utilidades para la gestión de cachés. Tres de ellas se muestran en el ejemplo que sigue ($ es el indicador de z/OS UNIX). Consulte la publicación Java SDK and Runtime Environment User Guide para obtener una visión general completa de las opciones de línea de mandatos soportadas.
$ java -Xshareclasses:listAllCaches Cachá compartida OS shmid en uso Hora de última desconexión RSE 401412 0 Lun Jun 18 17:23:16 2007 No se ha podido crear la máquina virtual Java (JVM). $ java -Xshareclasses:name=RSE,printStats Estadísticas actuales de la caché "RSE": dirección base = 0x0F300058 dirección final = 0x0F8FFFF8 puntero de asignación = 0x0F4D2E28 tamaño de caché = 6291368 bytes libres = 4355696 bytes de ROMClass = 1912272 bytes de metadatos = 23400 % de metadatos usados = 1% nº de ROMClasses = 475 nº de vías de acceso de clases = 4 nº de URL = 0 nº de símbolos = 0 nº de clases obsoletas = 0 % de clases obsoletas = 0% La caché está 30% llena No se ha podido crear la máquina virtual Java (JVM). $ java -Xshareclasses:name=RSE,destroy JVMSHRC010I La caché compartida "RSE" se ha destruido No se ha podido crear la máquina virtual Java (JVM).
Tradicionalmente, el papel de definir recursos en CICS ha sido competencia del administrador de CICS. Ha habido cierta renuencia en permitir que el desarrollador de aplicaciones definiera recursos CICS por diversas razones:
Developer for System z soluciona estos problemas al permitir que los administradores de CICS controlen los valores predeterminados de las definiciones de recursos CICS y las propiedades de visualización de un parámetro de definición de recurso CICS por medio del servidor CRD (definición de recurso CICS), que es parte del Gestor de despliegue de aplicaciones.
Por ejemplo, el administrador de CICS puede suministrar determinados parámetros de definición de recurso CICS que el desarrollador de aplicaciones no puede actualizar. Otros parámetros de definición de recurso CICS pueden ser actualizables, con o sin valores predeterminados suministrados, o el parámetro de definición de recurso CICS puede ocultarse para evitar una complejidad innecesaria.
Una vez que el desarrollador de aplicaciones está satisfecho con las definiciones de recurso CICS, éstas pueden instalarse de inmediato en el entorno de prueba CICS en ejecución, o pueden exportarse las definiciones en un manifiesto para que un administrador de CICS las edite y apruebe. El administrador de CICS puede utilizar el programa de utilidad administrativo (programa de utilidad de proceso por lotes) o la herramienta de Proceso de manifiestos para implementar cambios de definición de recurso.
Consulte la sección (Opcional) Gestor de despliegue de aplicaciones (ADM) para obtener más información acerca de las tareas necesarias para configurar el Gestor de despliegue de aplicaciones en el sistema host.
La personalización del Gestor de despliegue de aplicaciones añade los siguientes servicios a Developer for System z:
El servidor CRD (definición de recurso CICS) del Gestor de despliegue de aplicaciones consta del propio servidor CRD, un repositorio CRD, las definiciones de recursos CICS asociadas y, al utilizar la interfaz de servicios Web, archivos de enlace de servicio Web y un manejador de mensajes de conducto de ejemplo. El servidor CRD debe ejecutarse en una WOR (Web Owning Region), a la que se hace referencia en la documentación de Developer for System z como región de conexión primaria CICS.
Consulte el Information Center de Developer for System z Information Center (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para obtener más información sobre los servicios del Gestor de despliegue de aplicaciones disponibles en el release actual de Developer for System z.
CICS Transaction Server proporciona en la versión 4.1 y superior soporte para una interfaz HTTP diseñada utilizando los principios de la transferencia de estado representativo (RESTful). Esta interfaz RESTful es ahora la interfaz CICSTS estratégica para las aplicaciones de cliente. La interfaz de servicio web anterior se ha estabilizado, y las mejoras serán únicamente para la interfaz RESTful.
El Gestor de despliegue de aplicaciones sigue esta sentencia de dirección y necesita el servidor CRD de RESTful para todos los servicios que son nuevos Developer for System versión 7.6 o superior.
Las interfaces RESTful y de servicio Web puede estar activas simultáneamente en una única región CICS, si lo desea. En este caso, habrá dos servidores CRD activos en la región. Ambos servidores compartirán el mismo repositorio CRD. Tenga en cuenta que CICS emitirá algunos avisos sobre definiciones duplicadas cuando se defina la segunda interfaz en la región.
Un entorno de prueba CICS puede constar de varias regiones MRO (Opción multirregión) conectadas. Con el tiempo, se han utilizado denominaciones no oficiales para categorizar estas regiones. Son designaciones típicas TOR (región propietaria de terminal, WOR (región propietaria Web), AOR (región propietaria de aplicación) y DOR (región propietaria de datos).
Una WOR (región propietaria Web) se utiliza para implementar el soporte de servicios Web de CICS, y el servidor CRD (definición de recurso CICS) del Gestor de despliegue de aplicaciones debe ejecutarse en esta región. Esta región se conoce en el gestor de despliegue de aplicaciones como la región de conexión primaria CICS. El cliente CRD implementa una conexión de servicio Web con la región de conexión primaria CICS.
Las regiones de conexión no primaria CICS son todas las demás regiones a las que el servidor CRD puede dar servicio. Este servicio incluye la visualización de recursos mediante IBM CICS Explorer y la definición de recursos mediante el editor de definiciones de recurso CICS.
Si se utiliza BAS (Business Application Services) de CICSPlex SM para gestionar las definiciones de recursos CICS de la región de conexión primaria CICS, el servidor CRD puede dar servicio a todas las demás regiones CICS gestionadas por BAS.
Las regiones CICS no gestionadas por BAS requieren cambios adicionales para que el servidor CRD pueda darles servicio.
Las acciones realizadas por el servidor CRD en los recursos CICS se anotan en la cola TD CSDL de CICS, que generalmente señala hacia a la DD MSGUSR de la región CICS.
Si se utiliza Business Application Services (BAS) de CICSPlex SM para gestionar las definiciones de recurso CICS, la directiva de CICSPlex SM EYUPARM BASLOGMSG debe establecerse en (YES) para poder crear las anotaciones.
El conjunto de datos VSAM del repositorio del servidor CRD contiene todas las definiciones de recurso predeterminadas y, por tanto, debe protegerse contra actualizaciones, pero los desarrolladores deben poder leer los valores almacenados en él. Consulte Definir perfiles de conjunto de datos para obtener mandatos RACF de ejemplo para proteger el repositorio de CRD.
Cuando CICS recibe un mensaje SOAP a través de la interfaz de servicios Web, un conducto lo procesa. Un conducto es un conjunto de manejadores de mensajes que se ejecutan por orden. CICS lee el archivo de configuración del conducto para determinar qué manejadores de mensajes deben invocarse en el conducto. Un manejador de mensajes es un programa en el que pueden realizarse procesos especiales de solicitudes y respuestas de servicios Web.
El Gestor de despliegue de aplicaciones suministra un archivo de configuración de conducto de ejemplo que especifica la invocación de un manejador de mensajes y un programa de proceso de cabeceras SOAP.
El manejador de mensajes de conducto (ADNTMSGH) se utiliza para la seguridad, mediante el proceso del ID de usuario y la contraseña de la cabecera SOAP. El archivo de configuración de conducto de ejemplo hace referencia a ADNTMSGH, que, por lo tanto, se debe colocar en la concatenación RPL de CICS.
CPIH es el ID de transacción predeterminado bajo el que se ejecutará una aplicación invocada por un conducto. Generalmente, CPIH se establece para un nivel de autorización mínimo.
Developer for System z suministra varias transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Estos ID de transacción se establecen mediante el servidor CRD, dependiendo de la operación solicitada. Hallará más información sobre la personalización de ID de transacción en la sección (Opcional) Gestor de despliegue de aplicaciones (ADM).
Transacción | Descripción |
---|---|
ADMS | Para las solicitudes de la herramienta de Proceso de manifiestos para cambiar recursos CICS. Normalmente, está destinado a los administradores de CICS. Esta transacción requiere un alto nivel de autorización. |
ADMI | Para las peticiones que definen, instalan o desinstalan recursos CICS. Esta transacción puede requerir un nivel de autorización medio, dependiendo de las políticas establecidas en la ubicación. |
ADMR | Para todas las demás peticiones que recuperan información de recursos o de entorno de CICS. Esta transacción puede requerir un nivel de autorización mínimo, dependiendo de las políticas establecidas en la ubicación. |
Algunas de las solicitudes de definiciones de recurso realizadas por las transacciones del servidor CRD, o todas ellas, deben protegerse. Como mínimo, los mandatos de actualización (actualizar parámetros de servicio Web predeterminados, parámetros de descriptor predeterminados y enlace de nombre de archivo a nombre de conjunto de datos) deben protegerse para impedir nadie, excepto los administradores de CICS, emita estos mandatos utilizados para establecer valores predeterminados de recursos globales.
Cuando se conecta la transacción, la comprobación de la seguridad de recursos CICS, si está habilitada, se asegura de que el ID de usuario tiene autorización para ejecutar el ID de transacción.
La comprobación de recursos está controlada por la opción RESSEC en la transacción que se ejecuta, por el parámetro de inicialización del sistema RESSEC y, para el servidor CRD, por el parámetro de inicialización del sistema XPCT.
La comprobación de recursos sólo tiene lugar si el parámetro de inicialización del sistema XPCT tiene un valor que no es NO y la opción RESSEC de la definición de TRANSACTION es YES o el valor del parámetro de inicialización del sistema RESSEC es ALWAYS.
Los siguientes mandatos de RACF ofrecen un ejemplo de cómo pueden protegerse las transacciones del servidor CRD. Consulte la publicación RACF Security Guide for CICSTS para obtener más información acerca de la definición de la seguridad de CICS.
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#admincics)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#desarrolladorcics)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
El cifrado SSL de la secuencia de datos está soportada cuando el cliente Gestor de despliegue de aplicaciones utiliza la interfaz de servicios Web para invocar el servidor CRD. La utilización de SSL para esta comunicación está controlada por la palabra clave SSL(YES) en la definición de CICSTS TCPIPSERVICE, tal como se documenta en RACF Security Guide for CICSTS.
CICSTS proporciona la capacidad de proteger recursos, además de los mandatos para manipularlos. Algunas acciones del Gestor de despliegue de aplicaciones pueden fallar si la seguridad está activada pero no está completamente configurada (por ejemplo, otorgar permisos para la manipulación de tipos de recursos nuevos).
Cuando falle una función en el Gestor de despliegue de aplicaciones, examine las anotaciones de CICS para buscar mensajes similares al siguiente, y realice la acción correctiva, tal como se documenta en RACF Security Guide for CICSTS.
DFHXS1111 %fecha %hora %id_de_aplicación %id_de_transición Violación de la seguridad por el usuario %id_de_usuario en la red %nombre_de_puerto del recurso %recurso de la clase %nombre_de_clase. Los códigos SAF son (X'safresp',X'safreas'). Los códigos ESM son (X'esmresp',X'esmreas').
Developer for System z suministra el programa de utilidad administrativo que permite a los administradores de CICS proporcionar los valores predeterminados para las definiciones de recursos CICS. Estos valores predeterminados pueden ser de sólo lectura o pueden ser editables para los desarrolladores de aplicaciones.
El programa de utilidad administrativo ofrece las funciones siguientes:
El programa de utilidad administrativo se invoca mediante el trabajo de ejemplo ADNJSPAU del conjunto de datos FEK.#CUST.JCL. La utilización de este programa de utilidad requiere acceso de actualización (UPDATE) al repositorio de CRD.
ADNJSPAU se encuentra en FEK.#CUST.JCL, a menos que el programador de sistemas z/OS haya especificado otra ubicación al personalizar y someter el trabajo FEK.SFEKSAMP(FEKSETUP). Encontrará más detalles en: Configuración de la personalización.
Se utilizan sentencias de control de entrada para actualizar el repositorio del CRD para un entorno de prueba CICS, para las que se aplican las siguientes normas generales de sintaxis:
Las siguientes definiciones de ejemplo siguen la estructura de los mandatos DFHCSDUP, tal como se define en CICS Resource Definition Guide for CICSTS. La única diferencia es la inserción de las siguientes palabras clave de permiso de visualización utilizadas para agrupar los valores de atributo en tres conjuntos de permisos:
UPDATE | Un desarrollador de aplicaciones podrá actualizar los atributos situados a continuación de esta palabra clave mediante Developer for System z. Este es también el valor predeterminado para los atributos omitidos. |
PROTECT | Los atributos situados a continuación de esta palabra clave se visualizarán, pero el desarrollador de aplicaciones no podrá actualizarlos mediante Developer for System z. |
HIDDEN | Los atributos situados a continuación de esta palabra clave no se visualizarán, y el desarrollador de aplicaciones no podrá actualizarlos mediante Developer for System z. |
Consulte el siguiente ejemplo de código de ADNJSPAU.
//TRABAJO ADNJSPAU <PARÁMETROS TRABAJO> //* //ADNSPAU EXEC PGM=ADNSPAU,REGION=1M //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0 //SYSPRINT DD SYSOUT=* //SYSIN DD * * * Parámetros de CICSPlex SM * DEFINE CPSMNAME( ) *DEFINE STAGINGGROUPNAME(ADMSTAGE) * * Regla de exportación de manifiestos * DEFINE MANIFESTEXPORTRULE(installOnly) * * Valores predeterminados de definición de recurso CICS * Los atributos omitidos toman por omisión el valor UPDATE. * * Atributos predeterminados de DB2TRAN * DEFINE DB2TRAN() UPDATE DESCRIPTION() ENTRY() TRANSID() * * Atributos predeterminados de DOCTEMPLATE * DEFINE DOCTEMPLATE() UPDATE DESCRIPTION() TEMPLATENAME() FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM() DDNAME(DFHHTML) MEMBERNAME() HFSFILE() APPENDCRLF(YES) TYPE(EBCDIC) * * Atributos predeterminados de File * DEFINE FILE() UPDATE DESCRIPTION() RECORDSIZE() KEYLENGTH() RECORDFORMAT(V) ADD(NO) BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO) REMOTESYSTEM() REMOTENAME() PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1) STATUS(ENABLED) OPENTIME(FIRSTREF) DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1) TABLE(NO) MAXNUMRECS(NOLIMIT) READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS) UPDATEMODEL(LOCKING) LOAD(NO) JNLREAD(NONE) JOURNAL(NO) JNLSYNCREAD(NO) JNLUPDATE(NO) JNLADD(NONE) JNLSYNCWRITE(YES) RECOVERY(NONE) FWDRECOVLOG(NO) BACKUPTYPE(STATIC) PASSWORD() NSRGROUP() CFDTPOOL() TABLENAME()
* * Atributos predeterminados de Mapset * DEFINE MAPSET() UPDATE DESCRIPTION() PROTECT RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) ** Atributos predeterminados de Processtype * DEFINE PROCESSTYPE() UPDATE DESCRIPTION() FILE(BTS) PROTECT STATUS(ENABLED) AUDITLOG() AUDITLEVEL(OFF) * * Atributos predeterminados de Program * DEFINE PROGRAM() UPDATE DESCRIPTION() CEDF(YES) LANGUAGE(LE370) REMOTESYSTEM() REMOTENAME() TRANSID() PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT) DATALOCATION(ANY) DYNAMIC(NO) EXECKEY(USER) EXECUTIONSET(FULLAPI) RELOAD(NO) RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR) * * Atributos predeterminados de TDQueue * DEFINE TDQUEUE() UPDATE DESCRIPTION() TYPE(INTRA) * Parámetros extra-partición DDNAME() DSNAME() REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1) RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED) BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR) * Parámetros intra-partición FACILITYID() TRANSID() TRIGERRLEVEL(1) USERID() * Parámetros indirectos INDIRECTNAME() PROTECT WAIT(YES) WAITACTION(REJECT) * Parámetros extra-partición DATABUFFERS(1) SYSOUTCLASS() ERROROPTION(IGNORE) OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT) * Parámetros intra-partición ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Atributos predeterminados de Transaction
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* Atributos de URDIMAP
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Enlace opcionales de nombre de archivo con nombre de conjunto de datos VSAM
*
*DEFINE DSBINDING() DSNAME()
/*
Developer for System z versión 7.6.1 añadió soporte de URIMAP al programa de utilidad administrativo. Para poder utilizar el soporte URIMAP, el conjunto de datos de repositorio CRD VSAM debe estar asignado con un tamaño de registro máximo de 3000. Hasta Developer for System z Versión 7.6.1, el trabajo de asignación de repositorio CRD de ejemplo utiliza un tamaño de registro máximo de 2000.
Siga estos pasos para habilitar el soporte de URIMAP si está utilizando un repositorio CRD más antiguo:
El programa de utilidad administrativo emite los mensajes siguientes para la DD SYSPRINT. Los mensajes CRAZ1803E, CRAZ1891E, CRAZ1892E y CRAZ1893E contienen códigos de estado de archivo, retorno VSAM, función VSAM e información de retorno VSAM. Los códigos de retorno, función e información de retorno de VSAM se describen en la publicación DFSMS Macro Instructions for Data Sets (SC26-7408). Los códigos de estado de archivo se describen en la publicación Enterprise COBOL for z/OS Language Reference (SC27-1408).
Descripción: El programa de utilidad administrativo del programador del sistema se ha completado satisfactoriamente.
Respuesta del usuario: Ninguna.
Descripción: El programa de utilidad administrativo del programador del sistema se ha completado con uno o varios avisos encontrados al procesar las sentencias de control.
Respuesta del usuario: Compruebe si hay otros mensajes de aviso.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave.
Respuesta del usuario: Compruebe si hay otros mensajes de aviso.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al abrir el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado una sentencia de control de entrada no reconocida.
Respuesta del usuario: Compruebe que un mandato DEFINE vaya seguido de un solo espacio y de la palabra clave CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING,DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE o TRANSACTION.
Descripción: El programa de utilidad administrativo del programador del sistema está procesando la sentencia de control de entrada de la palabra clave DEFINE.
Respuesta del usuario: Ninguna.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado una regla de exportación de manifiestos no válida.
Respuesta del usuario: Compruebe que el valor de la palabra clave MANIFESTEXPORTRULE sea "installOnly", "exportOnly" o "both".
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE DSBINDING a la que le falta la palabra clave DSNAME.
Respuesta del usuario: Compruebe que la sentencia de control DEFINE DSBINDING contenga la palabra clave DSNAME.
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE y ha encontrado un valor no válido para la palabra clave indicada.
Respuesta del usuario: Compruebe que la longitud y el valor de la palabra clave indicada sean correctos.
Descripción: El programa de utilidad administrativo del programador del sistema estaba procesando una sentencia de control DEFINE y ha encontrado un error de sintaxis en una palabra clave o en un valor de palabra clave.
Respuesta del usuario: Compruebe que el valor de palabra clave se haya especificado entre paréntesis y se encuentre inmediatamente a continuación de la palabra clave. La palabra clave y su valor deben encontrarse en la misma línea.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error de clave duplicada al grabar en el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al grabar en el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Descripción: El programa de utilidad administrativo del programador del sistema ha encontrado un error grave al leer el repositorio de CRD.
Respuesta del usuario: Compruebe los códigos de estado, de retorno, de función y de información de retorno de VSAM.
Este apéndice está destinado a servir de ayuda para emular un procedimiento de inicio de sesión TSO añadiendo sentencias DD y conjuntos de datos al entorno TSO en Developer for System z.
El servicio de mandatos TSO es el componente de Developer for System z que ejecuta mandatos TSO e ISPF (por lotes) y devuelve el resultado al cliente solicitante. Estos mandatos puede solicitarlos implícitamente el producto o explícitamente el usuario.
Los miembros de ejemplo suministrados con Developer for System z crean un entorno TSO/ISPF mínimo. Si los desarrolladores de su establecimiento necesitan acceso a bibliotecas personalizadas o de terceros, el programador del sistema z/OS debe añadir las sentencias DD y bibliotecas necesarias al entorno de servicio de mandatos TSO. Aunque la implementación es diferente en Developer for System z, la lógica subyacente es idéntica al procedimiento de inicio de sesión de TSO.
Desde la versión 7.1, Developer for System z ofrece una opción relativa a cómo acceder al servicio de mandatos TSO.
Compruebe rsed.envvars para determinar el método de acceso utilizado para hosts de la versión 7.1 y posteriores. Si se han utilizado los valores predeterminados durante el proceso de configuración, rsed.envvars reside en /etc/rdz/.
El archivo de configuración ISPF.conf (por omisión ubicado en /etc/rdz/) define el entorno TSO/ISPF utilizado por Developer for System z. Sólo existe un archivo de configuración ISPF.conf activo, que utilizan todos los usuarios de Developer for System z.
La sección principal del archivo de configuración define los nombres de DD y las concatenaciones de conjuntos de datos relacionados, como en el ejemplo siguiente:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=ISP.SISPLOAD myDD=HLQ1.LLQ1,HLQ2.LLQ2
Por omisión, La Pasarela de cliente TSO/ISPF crea un perfil ISPF temporal para el servicio de mandatos TSO. Sin embargo, puede indicar a la Pasarela de cliente z TSO/ISPF que utilice una copia de un perfil ISPF existente. La clave es aquí la sentencia _RSE_CMDSERV_OPTS de rsed.envvars.
#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF"
Descomente la sentencia (elimine el carácter de almohadilla (#) inicial) y especifique el nombre totalmente calificado del conjunto de datos del perfil ISPF existente para utilizar este recurso.
Pueden utilizarse las variables siguientes en el nombre del conjunto de datos:
La sentencia allocjob de ISPF.conf (que está comentada por omisión) señala a un exec que puede utilizarse para suministrar más asignaciones de conjunto de datos por ID de usuario.
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
Descomente la sentencia (elimine el carácter de asterisco (*) inicial) y especifique la referencia totalmente calificada al exec de asignación para utilizar este recurso.
Aunque ISPF.conf sólo da soporte a la llamada a un exec de asignación, no hay límite para que ese exec llame a otro exec. Y el ID de usuario del cliente que se pasa como parámetro abre la posibilidad de llamar a execs de asignación personalizados. Por ejemplo, puede comprobar si el miembro USERID'.EXEC(ALLOC)' existe y ejecutarlo.
Una variante elaborada de este tema permite utilizar los procedimientos de inicio de sesión TSO existentes, del siguiente modo:
Si los escenarios de exec de asignación descritos anteriormente no pueden manejar sus necesidades específicas, puede crear instancias diferentes del servidor de comunicaciones RSE de Developer for System z, cada una de ellas con su propio archivo ISPF.conf. El principal inconveniente del método descrito más abajo es que los usuarios de Developer for System z deben conectarse a servidores diferentes del mismo host para obtener el entorno TSO deseado.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ cp ISPF.conf /etc/rdz/tso2 $ ls /etc/rdz/tso2 ISPF.conf rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> cambiar: _CMDSERV_CONF_HOME=/etc/rdz/tso2 -> descomentar y cambiar: -Ddaemon.log=/var/rdz/logs/tso2 -> añadir al final (END): # -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/tso2/ISPF.conf -> cambiar: cambiar según sea necesario
Los mandatos del ejemplo anterior copian los archivos de configuración de Developer for System z que necesitan cambios en un directorio tso2 de reciente creación. La variable _CMDSERV_CONF_HOME de rsed.envvars debe actualizarse para definir el nuevo directorio inicial de ISPF.conf y daemon.log debe actualizarse para definir una ubicación de anotaciones nueva (que se crea automáticamente en caso de que no exista). La actualización de CLASSPATH garantiza que RSE pueda encontrar los archivos de configuración que no se han copiado en tso2. El propio archivo ISPF.conf puede actualizarse para ajustarlo a las necesidades. Tenga en cuenta que el área de trabajo de ISPF (variable _CMDSERV_WORK_HOME de rsed.envvars) puede compartirse entre ambas instancias.
La tarea restante consiste en crear una tarea iniciada para RSE que utilice un número de puerto nuevo y los nuevos archivos de configuración /etc/rdz/tso2.
Consulte las secciones relacionadas de esta publicación para obtener más información acerca de las acciones mostradas anteriormente.
La definición de una transacción APPC consta de parámetros APPC y un JCL de transacción. El JCL de ejemplo destinado a crear una transacción APPC de Developer for System z, FEK.#CUST.JCL(FEKAPPCC), contiene dos opciones para definir el JCL de transacción, con y sin soporte para ISPF.
//SYSIN DD DDNAME=SYSINISP * utilizar SYSINTSO o SYSINISP
El cliente obtiene el entorno TSO/ISPF definido en el JCL de transacción, por lo que personalizando esta sección y siguiendo las normas habituales de DD puede personalizar el entorno para el cliente.
... //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2
Si se selecciona el soporte ISPF, Developer for System z crea por omisión un perfil ISPF temporal para el servicio de mandatos TSO. Sin embargo, puede indicar a Developer for System z que utilice una copia de un perfil ISPF existente. Como se describe en el trabajo de ejemplo FEK.SFEKSAMP(FEKAPPCC), debe hacer lo siguiente:
...
//COPY EXEC PGM=IEBCOPY * (opcional) clonar el perfil ISPF existente
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&SYSUID..ISPROF
//SYSUT2 DD DISP=(MOD,PASS),DSN=&&PROF,
// UNIT=SYSALLDA,
// LIKE=&SYSUID..ISPROF
//*
//CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50,
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//*ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//* SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//ISPPROF DD DISP=(OLD,DELETE,DELETE),DSN=&&PROF
El JCL de transacción de ejemplo llama directamente al servicio de mandatos TSO pasando su nombre (FEKFRSRV) como parámetro al programa IKJEFT01. Puede cambiar este procedimiento para que llame a otro exec. Este exec puede realizar asignaciones basadas en el ID de usuario actual y luego llamar al servicio de mandatos TSO.
Al contrario que en el método de acceso de la Pasarela de cliente TSO/ISPF, este exec puede utilizar las variables almacenadas en el perfil ISPF del usuario para facilitar la personalización del entorno. Sin embargo, recuerde que las actualizaciones del perfil se perderán al final de la sesión, ya que está utilizando una copia temporal, no el perfil real.
Sin embargo, tenga en cuenta que la utilización de un exec de asignación en la transacción APPC no está soportada y la descripción anterior es tal cual.
Si necesita varios entornos TSO exclusivos, puede crear instancias diferentes del servidor de comunicaciones RSE de Developer for System z, cada una de ellas con su propia transacción APPC. El principal inconveniente del método descrito más abajo es que los usuarios de Developer for System z deben conectarse a servidores diferentes del mismo host para obtener el entorno TSO deseado.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ ls /etc/rdz/tso2/ rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> descomentar y cambiar: _FEKFSCMD_TP_NAME_=FEKFTSO2 -> descomentar y cambiar: -Ddaemon.log=/var/rdz/logs/tso2 -> añadir al final (END): # -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Los mandatos anteriores crean un directorio tso2 y copian los archivos de configuración de Developer for System z que necesitan cambios en la nueva ubicación. La variable _ FEKFSCMD_TP_NAME_ de rsed.envvars debe actualizarse para definir el nombre de la transacción APPC nuevo y daemon.log deben actualizarse para definir una ubicación de anotaciones de daemon nueva (que se crea automáticamente en caso de que no exista). La actualización de CLASSPATH garantiza que RSE pueda encontrar los archivos de configuración que no se han copiado en tso2.
//FEKAPPCC JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID //* //TPADD EXEC PGM=ATBSDFMU //SYSSDLIB DD DISP=SHR,DSN=SYS1.APPCTP //SYSSDOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSIN DD DDNAME=SYSINISP * utilizar SYSINTSO o SYSINISP //SYSINISP DD DATA,DLM='QT' TPADD TPNAME(FEKFTSO2) ACTIVE(YES) TPSCHED_DELIMITER(DLM1) KEEP_MESSAGE_LOG(ERROR) MESSAGE_DATA_SET(&SYSUID..FEKFTSO2.&TPDATE..&TPTIME..LOG) DATASET_STATUS(MOD) CLASS(A) JCL_DELIMITER(DLM2) //FEKFTSO2 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //* //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2 DLM2 DLM1 QT
A continuación, cree una transacción APPC personalizando y sometiendo el trabajo de ejemplo FEK.#CUST.JCL(FEKAPPCC), tal como se muestra en el ejemplo anterior. Encima de la personalización normal (descrita en el JCL), debe cambiar también TPNAME por TPNAME(FEKFTSO2) para que coincida con la definición de _FEKFSCMD_TP_NAME_ del nuevo archivo rsed.envvars. Debe cambiar también el nombre en la variable MESSAGE_DATA_SET y el nombre del trabajo (JOB) del JCL de transacción.
La tarea restante consiste en crear una tarea iniciada para RSE que utilice un número de puerto nuevo y los nuevos archivos de configuración /etc/rdz/tso2.
Consulte las secciones relacionadas de esta publicación para obtener más información acerca de las acciones mostradas anteriormente.
En algunas ocasiones le interesará tener múltiples instancias de Developer for System z activas en el mismo sistema; por ejemplo, al probar una ampliación. Sin embargo, algunos recursos como los puertos TCP/IP no se pueden compartir, por lo que los valores predeterminados no siempre son aplicables. Utilice la información de este apéndice para planificar la coexistencia de distintas instancias de Developer for System z, y después podrá usar esta guía de configuración para personalizarlas.
Aunque es posible compartir algunos componentes de Developer for System z entre dos (o más) instancias, es mejor que NO lo haga, a menos que los correspondientes niveles de software sean idénticos y que los únicos cambios estén en los miembros de configuración. Developer for System z deja suficiente margen de personalización para crear múltiples instancias que no se solapen, y le aconsejamos encarecidamente que utilice estas características.
Consulte la publicación UNIX System Services Command Reference (SA22-7802) para obtener más información acerca de los siguientes mandatos de ejemplo para archivar y restaurar el directorio de instalación de Developer for System z.
Los archivos de configuración de Developer for System z (y el código) se pueden compartir entre los distintos sistemas de un sysplex (cada sistema ejecuta su propia copia idéntica de Developer for System z), si se siguen algunas directrices.
En un conjunto de circunstancias limitado, puede compartir todo salvo (algunos de) los componentes personalizables. Por ejemplo, proporcionar acceso no SSL para la utilización en el local y comunicación codificada por SSL para la utilización fuera del local.
Atención: La configuración compartida NO se puede utilizar de manera segura
para
probar el mantenimiento, un avance tecnológico o un nuevo release. |
Para configurar otra instancia de una instalación activa de Developer for System z, rehaga los pasos de personalización para los componentes que sean distintos, utilizando diferentes conjuntos de datos, directorios y puertos para evitar que se solape con la instalación actual.
En el ejemplo SSL mencionado más arriba, la configuración del daemon RSE actual se puede clonar y, después, la configuración clonada se puede actualizar. A continuación, el JCL de inicio del daemon RSE puede clonarse y personalizarse con un nuevo puerto TCP/IP y la ubicación de los archivos de configuración actualizados. Las personalizaciones de MVS (supervisor de trabajos JES, etc.) se pueden compartir entre las instancias SSL y las no SSL. Ello daría como resultado las siguientes acciones:
$ cd /etc/rdz $ mkdir /etc/rdz/ssl $ cp rsed.envvars /etc/rdz/ssl $ cp ssl.properties /etc/rdz/ssl $ ls /etc/rdz/ssl/ rsed.envvars ssl.properties $ oedit /etc/rdz/ssl/rsed.envvars -> descomentar y cambiar: -Ddaemon.log=/var/rdz/logs/ssl -> añadir al final (END): # -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/ssl/ssl.properties -> cambiar: cambiar según sea necesario
Los mandatos anteriores copian los archivos de configuración de Developer for System z que necesitan cambios en un directorio ssl de reciente creación. La variable daemon.log de rsed.envvars debe actualizarse para definir una ubicación de anotaciones nueva (que se crea automáticamente en caso de que no exista). La actualización de CLASSPATH garantiza que RSE pueda encontrar los archivos de configuración que no se han copiado en ssl. El propio archivo ssl.properties puede actualizarse para ajustarlo a las necesidades.
La tarea restante consiste en crear una tarea iniciada para RSE que utilice un número de puerto nuevo y los nuevos archivos de configuración /etc/rdz/ssl.
Consulte las secciones relacionadas de esta publicación para obtener más información acerca de las acciones mostradas anteriormente.
Cuando hay cambios de código implicados (de mantenimiento, avances tecnológicos, nuevo release), o cuando los cambios son bastante complejos, debe hacer otra instalación de Developer for System z. En este apartado se describen los posibles puntos de conflicto entre distintas instalaciones.
La siguiente lista es una visión general resumida de los elementos que deben ser distintos (o conviene que lo sean) entre las instancias de Developer for System z:
A continuación se proporciona una visión general más detallada:
//SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMRXX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC ... , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMRXX COLLID DSNREXCS WLM ENVIRONMENT ELAXMWDZ PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMRXX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMRXX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMRXX TO PUBLIC; //
En este apartado se resaltan los cambios de instalación y configuración comparados con los releases anteriores del producto. También se ofrecen algunas directrices generales para la migración a este release. Para obtener más información, consulte las secciones relacionadas de este manual.
Si es usted un usuario anterior de Developer for System z, le recomendamos que guarde los archivos personalizados relacionados antes de instalar esta versión de IBM Developer for System z.
Puede encontrar archivos personalizables de Developer for system z en las ubicaciones siguientes:
Las configuraciones anteriores de Developer for system z también describen los cambios en los archivos de configuración propiedad de otros productos.
definir una clase de transacción APPC para el servicio de mandatos TSO
establecer los valores predeterminados del sistema z/OS UNIX
iniciar los servidores en tiempo de IPL
añadir FEK.SFEKLPA a LPA
FEK.SFEKAUTH autorizada por APF
añadir FEK.SFEKAUTH y FEK.SFEKLOAD a LINKLIST
definir una transacción APPC para el servicio de mandatos TSO
asociar el programa de transacción APPC a un grupo de rendimiento TSO
asignar un entorno de aplicaciones para un procedimiento almacenado de DB2
definir una clase de transacción APPC para el servicio de mandatos TSO
establecer los valores predeterminados del sistema z/OS UNIX
FEK.SFEKLOAD autorizada por APF
definir el puerto del daemon RSE
definir el servicio del daemon RSE
definir ubicación del servidor de mandatos TSO
definir una transacción APPC para el servicio de mandatos TSO
asociar el programa de transacción APPC a un grupo de rendimiento TSO
asignar un entorno de aplicaciones para un procedimiento almacenado de DB2
definir una clase de transacción APPC para el servicio de mandatos TSO
establecer los valores predeterminados del sistema z/OS UNIX
FEK.SFEKLOAD autorizada por APF
definir el puerto del daemon RSE
definir el servicio del daemon RSE
definir una transacción APPC para el servicio de mandatos TSO
asociar el programa de transacción APPC a un grupo de rendimiento TSO
asignar un entorno de aplicaciones para un procedimiento almacenado de DB2
Las notas de migración siguientes son específicas de la version 7.6.1. Son válidas para migrar de la version 7.6 o son añadidos a las notas de migración de la versión 7.6 existentes.
Tabla 47 ofrece una visión general de los archivos personalizados en la versión 7.6. Tenga en cuenta que las bibliotecas de ejemplo de Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV y /usr/lpp/rdz/samples/, se suministran con más miembros personalizables que los indicados aquí, como el código fuente de ejemplo de CARMA y los trabajos para compilarlo.
Miembro/Archivo | Ubicación predeterminada | Finalidad | Notas de migración |
---|---|---|---|
FEKSETUP |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear conjuntos de datos y directorios y llenarlos con archivos personalizables | Actualizado para incluir nuevos miembros personalizables |
JMON |
FEK.SFEKSAMP(FEJJJCL) [FEK.#CUST.PROCLIB] |
JCL del supervisor de trabajos JES | Opción añadida para cambiar las opciones de LE |
FEJJJCL |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(JMON)] |
Nombre suministrado para el miembro JMON | Consulte el miembro JMON |
RSED |
FEK.SFEKSAMP(FEKRSED) [FEK.#CUST.PROCLIB] |
JCL para el daemon RSE | none |
FEKRSED |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(RSED)] |
Nombre suministrado para el miembro RSED | Consulte el miembro RSED |
LOCKD |
FEK.SFEKSAMP(FEKLOCKD) [FEK.#CUST.PROCLIB] |
JCL para el daemon de bloqueo | NUEVO, es necesaria personalización |
FEKLOCKD |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(LOCKD)] |
Nombre suministrado para el miembro LOCKD | Consulte el miembro LOCKD |
ELAXF* |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
JCL para construcciones de proyectos remotos, etc. | none |
FEKRACF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definiciones de seguridad | Actualizaciones menores |
FEJJCNFG |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Archivo de configuración del supervisor de trabajos JES | Se han añadido nuevas directivas opcionales |
FEJTSO |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
JCL de sometimientos TSO | none |
CRA$VMSG |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de mensajes de CARMA | none |
CRA$VDEF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de configuraciones de CARMA | none |
CRA$VSTR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de información personalizada de CARMA | none |
CRASUBMT |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST de inicio de proceso por lotes de CARMA | none |
CRASUBCA |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST de inicio por lotes de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRASHOW |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuración de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRATMAP |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuración de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRANDVRA | FEK.SFEKPROC | REXX de asignación de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRAISPRX |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Exec de asignación de DD de ejemplo para CARMA utilizando la Pasarela de cliente TSO/ISPF | none |
CRA#VSLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de mensajes de RAM de SCLM | none |
CRA#ASLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear los conjuntos de datos de RAM SCLM | none |
CRA#VPDS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de mensajes de RAM de PDS | none |
CRA#CRAM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar el RAM de esqueleto | none |
CRA#VCAD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de configuración de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRA#VCAS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el VSAM de información personalizada de CARMA para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
CRA#UADD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para fusionar definiciones del RAM | NUEVO, la personalización es opcional |
CRA#UQRY |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para extraer definiciones del RAM | NUEVO, la personalización es opcional |
CRAXJCL |
FEK.SFEKSAMP [FEK.#CUST.ASM] |
Código fuente de ejemplo para sustitución de IRXJCL | none |
CRA#CIRX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar CRAXJCL | none |
ADNCSDRS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir el servidor CRD de RESTful en la región primaria CICS | NUEVO, la personalización es opcional |
ADNCSDTX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir los ID de transacción alternativos en la región CICS | NUEVO, la personalización es opcional |
ADNTXNC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear ID de transacción alternativos | NUEVO, la personalización es opcional |
ADNMSGHC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar ADNMSGHS | Renombrado, era ADNCMSGH |
ADNMSGHS |
FEK.SFEKSAMP [FEK.#CUST.COBOL] |
Código fuente de ejemplo para el manejador de mensajes de conducto | Renombrado, era ADNSMSGH |
ADNVCRD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear el repositorio del CRD | Renombrado, era ADNVSAM |
ADNCSDWS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir el servidor CRD del Servicio Web en la región primaria CICS | Renombrado, era ADNPCCSD |
ADNCSDAR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir el servidor CRD en regiones no primarias CICS | Renombrado, era ADNARCSD |
ADNJSPAU |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para actualizar los valores predeterminados del CRD | Se añaden definiciones para el servicio RESTful. Es necesario rehacer las personalizaciones |
ADNVMFST |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear y definir el repositorio de manifiestos | Renombrado, era ADNMFEST |
ELAXMSAM |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
Procedimiento JCL del espacio de direcciones WLM para el constructor de procedimientos almacenados PL/I y COBOL | none |
ELAXMJCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir el constructor de procedimientos almacenados PL/I y COBOL en DB2 | none |
FEKAPPCC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para crear una transacción APPC | none |
FEKAPPCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para visualizar una transacción APPC | none |
FEKAPPCX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para suprimir una transacción APPC | none |
FEKLOGS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para recoger los archivo de anotaciones | NUEVO, la personalización es opcional |
rsed.envvars |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Variables de entorno RSE | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones). |
ISPF.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
archivo de configuración de la Pasarela de cliente TSO/ISPF | ISP.SISPCLIB añadido a SYSPROC para SCLMDT |
CRASRV.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de CARMA | none |
crastart.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de CARMA para la utilización de CRASTART | none |
crastart.endevor.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de CARMA para utilización de CRASTART para CA Endevor® SCM RAM | NUEVO, la personalización es opcional |
ssl.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración SSL de RSE | Se han añadido nuevas directivas opcionales |
rsecomm.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de rastreo de RSE | none |
propertiescfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de grupos de propiedades basadas en host | none |
projectcfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de proyectos basados en host | none |
FMIEXT.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de Integración del gestor de archivos | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones). |
uchars.settings |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Archivo de configuración de caracteres no editables | none |
Tabla 48 ofrece una visión general de los archivos personalizados en la versión 7.5. Tenga en cuenta que las bibliotecas de ejemplo de Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV y /usr/lpp/rdz/samples/, se suministran con más miembros personalizables que los indicados aquí, como el código fuente de ejemplo de CARMA y los trabajos para compilarlo.
Miembro/Archivo | Ubicación predeterminada | Finalidad | Notas de migración |
---|---|---|---|
FEKSETUP | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para crear conjuntos de datos y directorios y llenarlos con archivos personalizables | NUEVO, es necesaria personalización |
JMON | FEK.SFEKSAMP(FEJJJCL)
[FEK.#CUST.PROCLIB] |
JCL del supervisor de trabajos JES | STEPLIB cambiado por SFEKAUTH |
RSED | FEK.SFEKSAMP(FEKRSED)
[FEK.#CUST.PROCLIB] |
JCL para el daemon RSE | NUEVO, es necesaria personalización |
ELAXF* | FEK.SFEKSAMP
[FEK.#CUST.PROCLIB] |
JCL para construcciones de proyectos remotos, etc. | ELAXFTSO, ELAXFCP1 y ELAXFPP1 son nuevos |
FEKRACF | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para definiciones de seguridad | NUEVO, personalización obligatoria |
FEJJCNFG | FEK.SFEKSAMP
[FEK.#CUST.PARMLIB] |
Archivo de configuración del supervisor de trabajos JES |
|
FEJTSO | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
JCL de sometimientos TSO | El nombre de trabajo puede ser ahora una variable |
CRAISPRX | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
Exec de asignación de DD de ejemplo para CARMA utilizando la Pasarela de cliente TSO/ISPF | NUEVO, la personalización es opcional |
CRAXJCL | FEK.SFEKSAMP
[FEK.#CUST.ASM] |
Código fuente de ejemplo para sustitución de IRXJCL | NUEVO, la personalización es opcional |
CRA#CIRX | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para compilar CRAXJCL | NUEVO, la personalización es opcional |
ADNSMSGH | FEK.SFEKSAMP
[FEK.#CUST.COBOL] |
Código fuente de ejemplo para el manejador de mensajes de conducto | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones) |
ADNPCCSD | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para definir el servidor CRD en la región primaria CICS | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones) |
ADNJSPAU | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para actualizar los valores predeterminados del CRD | NUEVO, la personalización es opcional |
ADNMFEST | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para crear y definir el repositorio de manifiestos | NUEVO, la personalización es opcional |
rsed.envvars | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Variables de entorno RSE | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones) |
ISPF.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
archivo de configuración de la Pasarela de cliente TSO/ISPF | Idéntico al archivo ISPF.conf suministrado con SCLMDT en v7.1 |
CRASRV.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Archivo de configuración de CARMA |
|
crastart.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Archivo de configuración de CARMA para la utilización de CRASTART | NUEVO, la personalización es opcional |
FMIEXT.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Archivo de configuración de Integración del gestor de archivos |
|
uchars.settings | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Archivo de configuración de caracteres no editables | NUEVO, la personalización es opcional |
La tabla 23 ofrece una visión general de los archivos personalizados en la versión 7.1. Tenga en cuenta que las bibliotecas de ejemplo de CARMA y Developer for System z, CRA.SCRASAMP, FEK.SFEKSAMP y /usr/lpp/wd4z/rse/lib/, se suministran con más miembros personalizables que los indicados aquí, como el código fuente de ejemplo de CARMA y los trabajos para compilarlo.
Miembro/Archivo | Ubicación predeterminada | Finalidad | Notas de migración |
---|---|---|---|
ELAXF* | FEK.SFEKSAMP | JCL para construcciones de proyectos remotos y otros trabajos | ELAXFADT es nuevo |
CRA$VMSG | CRA.SCRASAMP | JCL para crear el VSAM de mensajes de CARMA |
|
CRA$VDEF | CRA.SCRASAMP | JCL para crear el VSAM de configuraciones de CARMA |
|
CRA$VSTR | CRA.SCRASAMP | JCL para crear el VSAM de información personalizada de CARMA | renombrado, era CRASREPR |
CRASUBMT | CRA.SCRASAMP | CLIST de inicio de proceso por lotes de CARMA | añadir DD CARMALOG |
CRA#VSLM | CRA.SCRASAMP | JCL para crear el VSAM de mensajes de RAM de SCLM | renombrado, era CRALREPR |
CRA#ASLM | CRA.SCRASAMP | JCL para crear los conjuntos de datos de RAM SCLM | renombrado, era CRASALX |
CRA#VPDS | CRA.SCRASAMP | JCL para crear el VSAM de mensajes de RAM de PDS | renombrado, era CRATREPR |
CRA#CRAM | CRA.SCRASAMP | JCL para compilar el RAM de esqueleto | renombrado, era CRARAMCM |
FEKAPPCC | FEK.SFEKSAMP | JCL para crear una transacción APPC | aprovechar soporte NEST de ISPF |
rsed.envvars |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Variables de entorno RSE | Las copias más antiguas deben sustituirse por esta (deben volver a realizarse personalizaciones) |
FMIEXT.properties |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Archivo de configuración de Integración del gestor de archivos | NUEVO, es necesaria personalización cuando se utiliza |
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar la capa de sockets segura (SSL), o durante la tarea de comprobar y/o modificar una configuración existente. Este apéndice también facilita una configuración de ejemplo para admitir que los usuarios se autentiquen con un certificado X.509.
Que una comunicación sea segura implica asegurarse de que su interlocutor sea la persona que afirma ser y transmitir información de tal manera que a las otras personas les resulte difícil interceptar los datos y leerlos. SSL proporciona capacidad para ello en una red TCP/IP. Funciona utilizando certificados digitales para identificarse a sí mismo, y un protocolo de claves públicas para cifrar la comunicación. Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de los certificados digitales y el protocolo de claves públicas utilizado por SSL.
Las acciones necesarias para configurar las comunicaciones SSL para Developer for System z variarán según el local, en función de las necesidades exactas, del método de comunicación RSE empleado y de lo que ya esté disponible en el local.
En ese apéndice clonaremos las definiciones actuales de RSE para poder tener una segunda conexión del daemon RSE que utilice SSL. También crearemos nuestros propios certificados de seguridad para que los utilicen diferentes componentes de la conexión RSE.
A lo largo de este apéndice se utiliza un convenio de denominación uniforme:
Algunas tareas que se describen a continuación, se espera que esté activo en z/OS UNIX. Para ello, emita el mandato TSO OMVS. Utilice el mandato exit para volver a TSO.
Los certificados de identidad y las claves de cifrado/descrifrado que SSL emplea se almacenan en un archivo de claves. Existen distintas implementaciones de este archivo de claves, en función del tipo de aplicación.
sin embargo, todas las implementaciones siguen el mismo principio. Un mandato genera un par de claves (una clave pública y una clave privada asociada). Este envuelve luego la clave pública en un certificado X.509 autofirmado, que se almacena como cadena de certificados de un solo elemento. Esta cadena de certificados y la clave privada se almacenen como una entrada (identificado por un alias) en un archivo de claves.
El daemon RSE es una aplicación SSL del sistema y utiliza un archivo de base de datos de claves. Esta base de datos de claves puede ser un archivo físico creado por gskkyman o un anillo de claves gestionado por el software de seguridad compatible con SAF (por ejemplo, por RACF). El servidor RSE (que se inicia mediante el daemon) es una aplicación SSL Java y utiliza un archivo de almacén de claves creado por keytool o bien un anillo de claves gestionado por su software de seguridad.
Almacenamiento de certificados | Creado y gestionado por | Daemon RSE | servidor RSE |
---|---|---|---|
anillo de claves | producto de seguridad compatible con SAF | soportado | soportado |
base de datos de claves | gskkyman de z/OS UNIX | soportado | / |
almacén de claves | Keytool de Java | / | soportado |
Para establecer la conexión por medio de SSL, necesitamos tanto el almacén de claves como la base de datos de claves, ya sea como un archivo de z/OS UNIX o como un anillo de claves compatible con SAF:
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Sin embargo, tenga en cuenta lo siguiente:
Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de RACF y los certificados digitales. La documentación relativa a gskkyman se encuentra en la publicación System SSL Programming (SC24-5901) y la documentación de keytool está disponible en el sitio http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
No realice este paso si utiliza gskkyman para crear la base de datos de claves del daemon RSE y keytool para crear el almacén de claves del servidor RSE.
El mandato RACDCERT instala y mantiene claves privadas y certificados en RACF. RACF permite gestionar múltiples claves privadas y certificados en forma de grupo. Estos grupos se llaman anillos de claves.
Consulte la publicación Security Server RACF Command Language Reference (SA22-7687) para obtener detalles acerca del mandato RACDCERT.
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE) RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') + OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(stcrse) ADDRING(rdzssl.racf) RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) + DEFAULT USAGE(PERSONAL))
En el ejemplo anterior se empieza por crear los perfiles necesarios y permitir que el ID de usuario STCRSE tenga acceso a los anillos de claves y a los certificados propiedad de ese ID de usuario. El ID de usuario que se utilice debe coincidir con el ID de usuario utilizado para ejecutar para el daemon RSE SSL. El próximo paso consiste en crear un certificado autofirmado con la etiqueta rdzrse . No se necesita ninguna contraseña. Luego, este certificado se añade a un anillo de claves recién creado (rdzssl.racf). Igual que con el certificado, tampoco se necesita una contraseña para el anillo de claves.
El resultado se puede verificar con la opción list siguiente:
RACDCERT ID(stcrse) LIST Información de certificado digital para el usuario STCRSE: Etiqueta: rdzrse ID de certificado: 2QjW1OXi0sXZ1aaEqZmihUBA Estado: TRUST Fecha inicial: 2007/05/24 00:00:00 Fecha final: 2017/05/21 23:59:59 Número de serie: >00< Nombre del emisor: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Nombre del sujeto: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Tipo de clave privada: Non-ICSF Tamaño de clave privada: 1024 Asociaciones de anillo: Propietario de anillo: STCRSE Anillo: >rdzssl.racf<
Los certificados pueden ser autofirmados o estar firmados por una autoridad certificadora (CA). Un certificado firmado por una CA implica que la CA garantiza que el propietario del certificado es quién dice ser. El proceso de firma añade las credenciales de la CA (otro certificado) al certificado, constituyendo una cadena de certificados de varios elementos.
Al utilizar un certificado firmado por una CA puede evitar las preguntas de validación de la confianza realizadas por el cliente de Developer for System z, si para el cliente la CA ya es de confianza.
Siga estos pasos para crear y utilizar un certificado firmado por una CA:
RACDCERT ID(stcrse) GENCERT WITHLABEL('rdzrse') . . .
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
RACDCERT CERTAUTH LIST
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
O añada el certificado de CA a la base de datos.
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(ID(stcrse) LABEL('rdzrse') RING(rdzssl.racf))
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') RING(rdzssl.racf))
En este paso se crea una nueva instancia de los archivos de configuración de RSE para que la configuración de SSL pueda ejecutarse en paralelo con las existentes. En los mandatos que siguen se presupone que los archivos de configuración se encuentran en /etc/rdz/, que es la ubicación predeterminada utilizada en Configuración de la personalización.
$ cd /etc/rdz $ mkdir ssl $ cp rsed.envvars ssl $ cp ssl.properties ssl $ ls ssl rsed.envvars ssl.properties
Los mandatos z/OS UNIX que figuran más arriba crean un subdirectorio llamado ssl y lo llenan con los archivos de configuración que requieren cambios. Podemos compartir el resto de archivos de configuración, el directorio de instalación y los componentes de MVS, puesto que no son específicos de la SSL.
Reutilizando la mayor parte de los archivos de configuración existente, podemos centrarnos en los cambios que son realmente necesarios para la configuración de la SSL y evitar tener que volver a realizar la configuración de RSE completa. (Por ejemplo, podemos ahorrarnos definir una nueva ubicación para ISPF.conf.)
Hasta el momento, las definiciones son una copia exacta de la configuración actual, lo que implica que las anotaciones del daemon RSE nuevo se superponen a los archivos de anotaciones del servidor actual. RSE también necesita saber dónde encontrar los archivos de configuración que no se han copiado en el directorio ssl. Ambas emisiones pueden direccionarse por cambios sin importancia a rsed.envvars.
$ oedit /etc/rdz/ssl/rsed.envvars -> descomentar y cambiar: -Ddaemon.log=/var/rdz/logs/ssl -> añadir al final (END): # -- NECESARIO PARA ENCONTRAR LOS ARCHIVOS DE CONFIGURACIÓN RESTANTES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Los cambios anteriores definen una nueva ubicación de anotaciones (que el daemon RSE creará en caso que la ubicación de anotaciones no exista). Los cambios también actualizan la CLASSPATH de manera que los procesos RSE de la SSL buscarán los archivos de configuración primero en el directorio actual (/etc/rdz/ssl) y luego en el directorio original (/etc/rdz).
Actualizando ssl.properties el RSE sigue instrucciones para empezar a utilizar la comunicación cifrada de la SSL.
$ oedit /etc/rdz/ssl/ssl.properties -> cambiar: enable_ssl=true -> descomentar y cambiar: daemon_keydb_file=rdzssl.racf -> descomentar y cambiar: daemon_key_label=rdzrse -> descomentar y cambiar: server_keystore_file=rdzssl.racf -> descomentar y cambiar: server_keystore_label=rdzrse -> descomentar y cambiar: server_keystore_type=JCERACFKS
Los cambios anteriores habilitan la SSL e indican al daemon RSE y al servidor RSE que el certificado (compartido) está almacenado bajo la etiqueta rdzrse en el anillo de claves rdzssl.racf. La palabra clave JCERACFKS indica al servidor RSE que se está utilizando un anillo de claves compatible con SAF como almacén de claves.
Como se ha indicado anteriormente, vamos a crear una segunda conexión que utilizará SSL, lo que implica crear un daemon RSE. El daemon RSE puede ser una tarea iniciada o un trabajo de usuario. Utilizaremos el método del trabajo de usuario para la configuración inicial (prueba). En las instrucciones que siguen se presupone que el JCL de ejemplo se encuentra en FEK.#CUST.PROCLIB(RSED) , que es la ubicación predeterminada utilizada en Configuración de la personalización:
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE //* //* RSE DAEMON - SSL //* //RSED PROC IVP='', * 'IVP' para realizar una prueba IVP // PORT=4047, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz/ssl' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME./bin/rsed.sh &IVP &PORT &CNFG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //PEND //* //RSED EXEC RSED //*
La configuración del host de SSL está completa y el daemon RSE para SSL puede iniciarse sometiendo el trabajo FEK.#CUST.PROCLIB(RSEDSSL) creado anteriormente.
Ahora, puede probarse la configuración nueva conectándose con el cliente de Developer for System z. Dado que hemos creado una nueva configuración (clonando la existente) para que SSL la utilice, hay que definir una nueva conexión en el cliente utilizando el puerto 4047 para el daemon RSE.
Al conectarse, el host y el cliente se iniciarán con algún establecimiento de enlace para poder configurar una vía de acceso segura. Parte del establecimiento de enlace es el intercambio de certificados. El cliente Developer for System z, si no reconoce el certificado del host o la CA que lo ha firmado, el cliente de Developer for System z preguntará al usuario si el certificado es de confianza.
Con el botón Finalizar, el usuario puede aceptar este certificado como de confianza, después de lo cual continuará la inicialización de la conexión.
Una vez reconocido el certificado ante el cliente, este diálogo ya no vuelve a aparecer. La lista de certificados de confianza se puede gestionar seleccionando Ventana > Preferencias... > Sistemas Remotos > SSL, con lo cual aparece el diálogo:
Si la comunicación SSL falla, el cliente devolverá un mensaje de error. Hay más información en los distintos archivos de anotaciones del usuario y del servidor, como se describe en: Daemon RSE y anotaciones de la agrupaciones de hebras y Anotaciones de usuario de RSE.
El daemon RSE admite que los usuarios se autentiquen con un certificado X.509. El uso de una comunicación cifrada con SSL es un requisito previo para utilizar esta función, dado que es una extensión de la autenticación de host con un certificado utilizado en SSL.
Hay varias formas de realizar la autorización de certificados para un usuario, tal como se describe en Autenticación de cliente mediante certificados X.509. Los siguientes pasos describen la configuración necesaria para soportar el método por el cual su software de seguridad autentica el certificado mediante la ampliación de certificado HostIdMappings.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') + RING(rdzssl.racf))
Esta acción concluye la configuración del software de seguridad para el certificado de CA.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) + ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH) o bien SETROPTS RACLIST(SERVAUTH) REFRESH
Esta acción concluye la configuración del software de seguridad para ampliación de HostIdMappings.
No realice este paso si utiliza un anillo de claves compatible con SAF para la base de datos de claves del daemon RSE.
gskkyman es un programa dirigido por menú y basado en la shell z/OS UNIX que crea, puebla y gestiona un archivo z/OS UNIX que contiene claves privadas, peticiones de certificado y certificados. Este archivo z/OS UNIX se llama base de datos de claves.
PATH=$PATH:/usr/lpp/gskssl/bin export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl $ gskkyman Menú de base de datos 1 - Crear base de datos nueva Entre el número de opción: 1 Especifique el nombre de la base de datos de claves (pulse Intro para volver al menú): rdzssl.kdb Entre la contraseña de la base de datos (pulse Intro para volver al menú): rsessl Vuelva a entrar la contraseña de la base de datos: rsessl Entre el tiempo de caducidad de la contraseña en días (pulse Intro si no caduca): Entre la longitud de registro de la base de datos (pulse Intro para utilizar 2500): Se ha creado la base de datos de claves /etc/rdz/ssl/rdzssl.kdb. Pulse Intro para continuar. Menú de gestión de claves 6 - Crear un certificado autofirmado Entre el número de opción (pulse Intro para volver al menú anterior): 6 Tipo de certificado 5 - Certificado de usuario o servidor con clave RSA de 1024 bites Seleccione el tipo de certificado (pulse Intro para volver al menú): 5 Entre la etiqueta (pulse Intro para volver al menú): rdzrse Entre el nombre de sujeto del certificado Nombre común (necesario): rdz rse ssl Unidad de organización (OU, opcional): rdz Organización (necesario): IBM Ciudad/Localidad (opcional): Raleigh Estado/Provincia (opcional): NC País/Región (2 caracteres - necesario): US Entre el número de días durante los que el certificado será válido (valor predeterminado, 365): 3650 Entre 1 para especificar nombres de sujetos alternativos o entre 0 para continuar: 0 Espere por favor ..... El certificado se ha creado. Pulse Intro para continuar. Menú de gestión de claves 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 0 $ ls -l rdzssl.* total 152 -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb $ chmod 644 rdzssl.* $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
En el ejemplo anterior se empieza por crear una base de datos de claves llamada rdzssl.kdb con la contraseña rsessl. Una vez creada la base de datos, ésta se llena creando un certificado autofirmado, válido durante 10 años (sin contar los días bisiestos). El certificado se almacena bajo la etiqueta rdzrse y que tiene la misma contraseña (rsessl) que la que se empleó para la base de datos de claves (este es un requisito de RSE).
gskkyman asigna la base de datos de claves con una máscara de bit de permiso 600 (muy seguro, el único que tiene acceso es el propietario). Los permisos se tienen que establecer para que sean menos restrictivos, a menos que el daemon utilice el mismo ID de usuario que el creador de la base de datos de claves. 644 (el propietario tiene acceso de lectura/escritura y los demás tienen acceso de lectura) es una máscara que se puede usar para el mandato chmod.
El resultado se puede verificar seleccionando la opción Mostrar información de certificado, en el submenú Gestionar claves y certificados, del siguiente modo:
$ gskkyman Menú de base de datos 2 - Abrir base de datos Entre el número de opción: 2 Especifique el nombre de la base de datos de claves (pulse Intro para volver al menú): rdzssl.kdb Entre la contraseña de la base de datos (pulse Intro para volver al menú): rsessl Menú de gestión de claves 1 - Gestionar claves y certificados Entre el número de opción (pulse Intro para volver al menú anterior): 1 Lista de claves y certificados 1 - rdzrse Entre el número de etiqueta (Intro para volver al menú de selección, p para lista anterior): 1 Menú de claves y certificados 1 - Mostrar información de certificado Entre el número de opción (pulse Intro para volver al menú anterior): 1 Información de certificado Etiqueta: rdzrse ID de registro: 14 ID de registro del emisor: 14 De confianza: Sí Versión: 3 Número de serie: 45356379000ac997 Nombre del emisor: rdz rse ssl rdz IBM Raleigh NC US Nombre de sujeto: rdz rse ssl rdz IBM Raleigh NC US Fecha de efectividad: 2007/05/24 Fecha de caducidad: 2017/05/21 Algoritmo de clave pública: rsaEncryption Tamaño de clave pública: 1024 Algoritmo de signatura: sha1WithRsaEncryption ID exclusivo del emisor: Ninguno ID exclusivo del sujeto: Ninguno Número de extensiones: 3 Entre 1 para visualizar las extensiones, entre 0 para volver al menú: 0 Menú de claves y certificados 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 0
El siguiente ejemplo de ssl.properties muestra que las directivas de daemon_* difieren del ejemplo de anillo de claves de SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties -> cambiar: enable_ssl=true -> descomentar y cambiar: daemon_keydb_file=rdzssl.kdb -> descomentar y cambiar: daemon_keydb_password=rsessl -> descomentar y cambiar: daemon_key_label=rdzrse -> descomentar y cambiar: server_keystore_file=rdzssl.racf -> descomentar y cambiar: server_keystore_label=rdzrse -> descomentar y cambiar: server_keystore_type=JCERACFKS
Los cambios anteriores habilitan la SSL e indican al daemon RSE que el certificado está almacenado bajo la etiqueta rdzrse en la base de datos de claves rdzssl.kdb con la contraseña rsessl. El servidor RSE sigue utilizando un anillo de claves compatible con SAF.
No realice este paso si utiliza un anillo de claves compatible con SAF para el almacén de claves del servidor RSE.
"keytool -genkey" genera un par de claves privadas y un certificado autofirmado coincidente, que está almacenado como una entrada (identificado por un alias) en un archivo de almacén de claves (nuevo).
Toda la información se puede pasar como un parámetro, pero debido a las limitaciones de longitud que tiene la línea de mandatos, se necesita algo de interactividad, del siguiente modo:
$ cd /etc/rdz/ssl $ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass rsessl -keypass rsessl ¿Cuál es su nombre y su apellido? [Desconocido]: rdz rse ssl ¿Cuál es el nombre de su unidad de organización (OU)? [Desconocido]: rdz ¿Cuál es el nombre de su organización? [Desconocido]: IBM ¿Cuál es el nombre de su ciudad o localidad? [Desconocido]: Raleigh ¿Cuál es el nombre de su estado o provincia? [Desconocido]: NC ¿Cuál es el código de dos letras de esta unidad? [Desconocido]: US ¿Es correcto CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US? (escriba "yes" o "no") [no]: yes $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
El certificado autofirmado creado más arriba es válido durante 10 años (sin contar los días bisiestos). Se almacena en /etc/rdz/ssl/rdzssl.jks utilizando el alias rdzrse. Su contraseña (rsessl) es idéntica a la contraseña del almacén de claves, que es un requisito para RSE.
El resultado se puede verificar con la opción -list, del siguiente modo:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v Nombre de alias: rdzrse Fecha de creación: May 24, 2007 Tipo de entrada: keyEntry Longitud de la cadena de certificados: 1 Certificado 1¨: Propietario: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Emisor: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Número de serie: 46562b2b Válido desde: 5/24/07 2:17 PM hasta: 5/21/17 2:17 PM Huellas digitales del certificado MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80 SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
El siguiente ejemplo de ssl.properties muestra que las directivas de server_* difieren del ejemplo de anillo de claves de SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties -> cambiar: enable_ssl=true -> descomentar y cambiar: daemon_keydb_file=rdzssl.racf -> descomentar y cambiar: daemon_key_label=rdzrse -> descomentar y cambiar: server_keystore_file=rdzssl.jks -> descomentar y cambiar: server_keystore_password=rsessl -> descomentar y cambiar: server_keystore_label=rdzrse -> descomentar y cambiar (opcional): server_keystore_type=JKS
Los cambios anteriores habilitan la SSL e indican al servidor RSE que el certificado está almacenado bajo la etiqueta rdzrse en el almacén de claves rdzssl.jks con la contraseña rsessl. El daemon RSE sigue utilizando un anillo de claves compatible con SAF.
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar TCP/IP, o durante la tarea de comprobar o modificar una configuración existente.
Consulte las publicaciones Communications Server: IP Configuration Guide (SC31-8775) y Communications Server: IP Configuration Reference (SC31-8776) para obtener más información acerca de la configuración de TCP/IP.
Al utilizar APPC para el servicio de mandatos TSO, Developer for System z depende de que TCP/IP tenga el nombre de host correcto cuando se inicializa. Ello implica que los distintos archivos de configuración de TCP/IP y del resolviente estén configurados correctamente.
Puede probar la configuración de TCP/IP con IVP (programa de verificación de la instalación) fekfivpt. El mandato debe devolver datos de salida parecidos a los de este ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpt Wed Jul 2 13:11:54 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars ------------------------------------------------------------- configuración del resolviente TCP/IP (orden de búsqueda de z/OS UNIX): ------------------------------------------------------------- Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964 Valores de resolviente res_init: Conjunto de datos Tcp/Ip global = Ninguno Conjunto de datos Tcp/Ip predeterminado = Ninguno Conjunto de datos Tcp/Ip local = /etc/resolv.conf Tabla de conversión = Predeterminada IDusuario/NombreTrabajo = USERID API llamante = LE C Sockets Modalidad llamante = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Satisfactoria res_init Iniciada: 2008/07/02 13:11:54.755363 res_init Finalizada: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 Nombre TCPIP: TCPIP 13:11:54 Tcpip iniciado a las 01:28:36 el 06/23/2008 con IPv6 habilitado ------------------------------------------------------------- dirección IP del host: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Satisfactorio, coincidencia de direcciones
El resolviente funciona en nombre de los programas como un cliente que accede a los servidores de nombres para obtener una resolución de nombre en dirección o una resolución de dirección en nombre. Para resolver la consulta del programa peticionario, el resolviente puede acceder a los servidores de nombres disponibles, utilizar definiciones locales (por ejemplo, /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO o ETC.IPNODES), o utilizar una combinación de ambos.
El resolviente, al iniciarse su espacio de direcciones, lee un conjunto de datos de instalación opcional del resolviente hacia el que señala la tarjeta DD SETUP en el procedimiento del JCL del resolviente. Si no se proporciona información de instalación, el resolviente utiliza el orden de búsqueda nativo de MVS o z/OS UNIX aplicable sin ninguna información de GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES o COMMONSEARCH.
Es importante comprender el orden de búsqueda de archivos de configuración que las funciones de TCP/IP utilizan, y conviene saber cuándo se puede alterar temporalmente el orden de búsqueda predeterminado con las variables de entorno, con el JCL o con otras variables que proporcione. Este conocimiento le permite acomodar sus estándares de denominación de los conjuntos de datos y archivos de HFS locales, y también le resultará de utilidad conocer el conjunto de datos o archivo de HFS de configuración al diagnosticar problemas.
Otro punto importante a tener en cuenta es que cuando se aplica un orden de búsqueda para cualquier archivo de configuración, la búsqueda finaliza con el primer archivo que se encuentre. Por lo tanto, es posible obtener resultados inesperados si coloca información de configuración en un archivo que nunca se va a encontrar, ya sea porque existen otros archivos antes según el orden de la búsqueda, o porque el archivo no está incluido en el orden de búsqueda elegido por la aplicación.
Al buscar archivos de configuración, puede indicar explícitamente a TCP/IP dónde está la mayoría de los archivos de configuración, utilizando para ello sentencias DD en los procedimientos del JCL o estableciendo variables de entorno. Por otro lado, puede dejar que sea TCP/IP el que determine dinámicamente la ubicación de los archivos de configuración, basándose en el orden de búsqueda documentado en la publicación Communications Server: IP Configuration Guide (SC31-8775).
El componente de configuración de la pila de TCP/IP utiliza TCPIP.DATA durante la inicialización de la pila de TCP/IP para determinar el nombre de host (HOSTNAME) de la pila. Para obtener este valor, se utiliza el orden de búsqueda del entorno z/OS UNIX.
El archivo o tabla concreto que se busca puede ser un conjunto de datos MVS o un archivo HFS, en función de los valores de configuración del resolviente y de la presencia de determinados archivos en el sistema.
El archivo de configuración de resolviente base contiene sentencias TCPIP.DATA. Además de las directivas del resolviente, se le hace referencia para determinar, entre otras cosas, el prefijo de conjunto de datos (valor de la sentencia DATASETPREFIX) que hay que utilizar al intentar acceder a algunos de los archivos de configuración especificados en esta sección.
El orden de búsqueda empleado para acceder al archivo de configuración resolviente base es el siguiente:
Si está definido, se utiliza el valor de la sentencia de configuración GLOBALTCPIPDATA del resolviente (vea también: Qué son los resolvientes). La búsqueda continúa hasta encontrar un archivo de configuración adicional. La búsqueda finaliza con el próximo archivo encontrado.
Se utiliza el valor de la variable de entorno. Esta búsqueda fallará si el archivo no existe o si se ha asignado de manera exclusiva en otra parte.
Se utiliza el conjunto de datos asignado a la DD de nombre SYSTCPD. En el entorno z/OS UNIX, un proceso hijo no tiene acceso a la DD SYSTCPD. Ello se debe a que la asignación de SYSTCPD no se hereda del proceso padre por las llamadas a fork() o a la función exec.
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones, tarea o hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
Si está definido, se utiliza el valor de la sentencia de configuración DEFAULTTCPIPDATA del resolviente (vea también: Qué son los resolvientes).
A las tablas de conversión (de EBCDIC a ASCII y de ASCII a EBCDIC) se les hace referencia para determinar los conjuntos de datos de conversión que hay que utilizar. El orden de búsqueda empleado para acceder a este archivo de configuración es el siguiente. La búsqueda finaliza en el primer archivo encontrado:
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones o tarea/hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
Por defecto, en primer lugar el resolviente intenta utilizar los servidores de nombres de dominio que estén configurados para las peticiones de resolución. Si la petición de resolución no se puede satisfacer, se emplean las tablas de hosts locales. El comportamiento del resolviente se controla mediante las sentencias TCPIP.DATA.
Las sentencias TCPIP.DATA del resolviente definen si hay que utilizar los servidores de nombres de dominio y cómo hay que hacerlo. La sentencia LOOKUP TCPIP.DATA también puede servir para controlar cómo se utilizan los servidores de nombres de dominio y las tablas de hosts locales. Para obtener más información sobre las sentencias TCPIP.DATA, consulte la publicación Communications Server: IP Configuration Reference (SC31-8776).
El resolviente emplea el orden de búsqueda exclusivo de Ipv4 para obtener información de nombres de locales incondicionalmente para las llamadas a la API getnetbyname. El orden de búsqueda exclusivo de Ipv4 para obtener información de nombres de locales es el siguiente. La búsqueda finaliza en el primer archivo encontrado:
El valor de la variable de entorno es el nombre del archivo de información HOSTS.SITEINFO creado por el mandato TSO MAKESITE.
El valor de la variable de entorno es el nombre del archivo de información HOSTS.ADDRINFO creado por el mandato TSO MAKESITE.
userid es el ID de usuario asociado al entorno de seguridad actual (espacio de direcciones o tarea/hebra).
jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado.
hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
Tal como se ha indicado antes, Developer for System z depende de que TCP/IP tenga el nombre de host correcto en el momento de la inicialización cuando se está utilizando APPC. Ello implica que los distintos archivos de configuración de TCP/IP y del resolviente estén configurados correctamente.
En el ejemplo que sigue, nos centraremos en algunas tareas de configuración de TCP/IP y del resolviente. Tenga en cuenta que no se trata de describir una configuración completa de TCP/IP o del resolviente, sino tan solo de resaltar algunos aspectos clave que podrían ser válidos para su local:
//TCPIP PROC PARMS='CTRACE(CTIEZB00)',PROF=TCPPROF,DATA=TCPDATA //* //* RED TCP/IP //* //TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS //PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF) //SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA) //SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSERROR DD SYSOUT=*
; HOSTNAME especifica el nombre de host TCP de este sistema. Si no ; se especifica, el HOSTNAME predeterminado será el nombre de nodo especificado ; en el miembro IEFSSNxx PARMLIB. ; ; HOSTNAME ; ; DOMAINORIGIN especifica el origen de dominio que se añadirá ; a los nombres de host que se pasen al resolviente. Si un nombre de host contiene ; puntos, el DOMAINORIGIN no se añadirá al final del ; nombre de host. ; DOMAINORIGIN RALEIGH.IBM.COM ; ; NSINTERADDR especifica la dirección IP del servidor de nombres. ; LOOPBACK (14.0.0.0) especifica el servidor de nombres local. Si ; no se va a emplear un servidor de nombres, no codifique una sentencia NSINTERADDR. ; (Descomente la siguiente línea NSINTERADDR). Esto hará que todos los nombres ; se resuelvan por medio de la búsqueda de la tabla de locales. ; ; NSINTERADDR 14.0.0.0 ; ; TRACE RESOLVER provocará un rastreo completo de todas las consultas y ; respuestas del servidor de nombres o de las tablas de locales, que se escribirá en ; la consola del usuario. Este mandato solo tiene como finalidad la depuración. ; ; TRACE RESOLVER
//RESOLVER PROC PARMS='CTRACE(CTIRES00)' //* //* IP NAME RESOLVER - START WITH SUB=MSTR //* //RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS //*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP DomainOrigin RALEIGH.IBM.COM HostName CDFMVS08
Como ya se ha mencionado en: Orden de búsqueda utilizado en el entorno z/OS UNIX, el archivo de configuración base contiene sentencias TCPIP.DATA. Si el nombre del sistema es CDFMVS08 (TCPDATA indicaba que se utiliza el nombre del sistema como nombre de host), podemos ver que /etc/resolv.conf está en sincronización con SYS1.TCPPARMS(TCPDATA). No hay definiciones de DNS y, por lo tanto, se utilizará la búsqueda de la tabla de locales.
# Resolviente /etc/hosts file cdfmvs08 9.42.112.75 cdfmvs08 # Host CDFMVS08 9.42.112.75 cdfmvs08.raleigh.ibm.com # Host CDFMVS08 127.0.0.1 localhost
El contenido mínimo de este archivo es información sobre el sistema actual. En el ejemplo anterior definimos cdfmvs08 y cdfmvs08.raleigh.ibm.com como un nombre válido de una dirección IP de nuestro sistema z/OS.
Si utilizásemos un servidor de nombres de dominio (DNS), el DNS contendría la información de /etc/hosts, y /etc/resolv.conf y SYS1.TCPPARMS(TCPDATA) tendrían sentencias que identificarían el DNS ante nuestro sistema.
Para evitar confusiones, debe mantener los archivos de configuración de TCP/IP y del resolviente sincronizados entre sí.
Descripción de tipo de archivo | Interfaces API afectadas | Archivos candidatos |
---|---|---|
Archivos de configuración de resolviente base | Todas las API |
|
Tablas de conversión | Todas las API |
|
Tablas de hosts locales |
endhostent endnetent getaddrinfo gethostbyaddr gethostbyname gethostent GetHostNumber GetHostResol GetHostString getnameinfo getnetbyaddr getnetbyname getnetent IsLocalHost Resolve sethostent setnetent |
IPv4
IPv6
|
Cuando encuentre problemas relacionados con que el Resolviente de TCP/IP no pueda resolver la dirección de host correctamente, probablemente se deba a un archivo de configuración resolviente faltante o incompleto. Una indicación clara de este problema es el mensaje siguiente en lock.log:
clientip(0.0.0.0) <> callerip(<dirección IP host>)
Para verificarlo, ejecute el IVP de TCP/IP fekfivpt, como se describe en Verificación de la instalación. La sección de configuración del resolviente de la salida será como la del ejemplo siguiente:
Inicialización de rastreo de resolviente completada -> 2008/07/02 13:11:54.745964 Valores de resolviente res_init: Conjunto de datos Tcp/Ip global = Ninguno Conjunto de datos Tcp/Ip predeterminado = Ninguno Conjunto de datos Tcp/Ip local = /etc/resolv.conf Tabla de conversión = Predeterminada IDusuario/NombreTrabajo = USERID API llamante = LE C Sockets Modalidad llamante = EBCDIC
Asegúrese de que las definiciones del archivo (o del conjunto de datos) a las que hace referencia "Conjunto de datos Tcp/Ip local" sean correctas.
Este campo estará en blanco si no utiliza un nombre predeterminado para el archivo resolviente de IP (utilizando el orden de búsqueda de z/OS UNIX). Si es así, añada la sentencia siguiente al archivo rsed.envvars, donde <archivo resolviente> o <datos resolvientes> representa el nombre del archivo resolviente de IP:
RESOLVER_CONFIG=<archivo resolviente>
o bien
RESOLVER_CONFIG='<conjunto de datos resolvientes>'
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar INETD, o durante la tarea de comprobar o modificar una configuración existente. Developer for System z utiliza INETD para la función REXEC/SSH.
El daemon INETD proporciona gestión de servicio para una red IP. Reduce la carga del sistema invocando otros daemons solo cuando se necesiten y proporcionando varios servicios simples de Internet (como el de echo) internamente. INETD lee el archivo de configuración inetd.conf para determinar qué servicios adicionales hay que proporcionar. ETC.SERVICES se emplea para enlazar los servicios a los puertos.
Los servicios que se basan en INETD se definen en inetd.conf, que INETD lee en el momento del arranque. La ubicación y el nombre predeterminados de inetd.conf es /etc/inetd.conf. Encontrará un archivo inetd.conf de ejemplo en /samples/inetd.conf.
Las reglas de sintaxis válidas para las entradas de inetd.conf son las siguientes:
Cada entrada consta de 7 campos posicionales, correspondientes al formato:
nombre_servicio tipo_socket protocolo distintivo_espera id_usuario programa_servidor server_program_arguments
protocolo puede ser tcp[4|6] o udp[4|6], y sirve para calificar adicionalmente el nombre del servicio. El nombre del servicio y también el protocolo deben coincidir con una entrada de ETC.SERVICES, salvo que el "4" o el "6" no se deben incluir en la entrada ETC.SERVICES.
sndbuf y rcvbuf especifican el tamaño de las memorias intermedias de envío y recepción. El tamaño, representado por n, debe estar expresado en bytes, pero también se puede añadir una "k" o una "m" para indicar kilobytes o megabytes, respectivamente. sndbug y rcvbuf se pueden usar en cualquier orden.
wait o nowait.wait indica que el daemon es de una sola hebra y no se servirá otra petición hasta que se complete la primera. Si se especifica nowait, INETD emite una aceptación cuando se recibe una petición de conexión en un socket de modalidad continua. Si se especifica wait, el servidor es el encargado de emitir la aceptación si este es un socket de modalidad continua.
max es el número máximo de usuarios permitidos para solicitar servicio en un intervalo de 60 segundos. El valor predeterminado es 40. Si se sobrepasa, el puerto del servicio de cierra.
userid es el ID de usuario bajo el que se debe ejecutar el daemon bifurcado. Este ID de usuario puede ser diferente del ID de usuario de INETD. Los permisos asignados a este ID de usuario dependen de las necesidades del servicio. El ID de usuario de INETD necesita el permiso BPX.DAEMON para conmutar el proceso bifurcado a este ID de usuario.
El valor group opcional, separado del ID de usuario por un punto (.), permite que el servidor se ejecute con un ID de grupo distinto del predeterminado para este ID de usuario.
INETD utiliza ETC.SERVICES para correlacionar números de puertos y protocolos con los servicios a los que debe dar soporte. Puede ser un conjunto de datos MVS o un archivo z/OS UNIX. Hay un ejemplo que viene en SEZAINST(SERVICES) y que también puede estar disponible como /usr/lpp/tcpip/samples/services. El orden de búsqueda de ETC.SERVICES depende del método de arranque de INETD; z/OS UNIX o MVS nativo.
Las reglas de sintaxis válidas para la especificación de información de servicio son las siguientes:
Cada entrada consta de cuatro campos posicionales, correspondientes al formato:
nombre_servicio número_puerto/protocolo alias
El orden de búsqueda empleado para acceder a ETC.SERVICES en z/OS UNIX es el siguiente. La búsqueda finaliza en el primer archivo encontrado:
userid es el ID de usuario empleado para iniciar INETD
.hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
El orden de búsqueda empleado para acceder a ETC.SERVICES en MVS es el siguiente. La búsqueda finaliza en el primer conjunto de datos encontrado:
Se utiliza el conjunto de datos asignado a la sentencia DD SERVICES
userid es el ID de usuario empleado para iniciar INETD
.jobname es el nombre especificado en la sentencia JCL de JOB para los trabajos por lotes o el nombre de un procedimiento iniciado
hlq representa el valor de la sentencia DATASETPREFIX especificada en el archivo de configuración de resolviente base (si se da con él); en caso contrario, hlq es TCPIP por defecto.
No hay que confundir las definiciones de PORT (o PORTRANGE) en PROFILE.TCPIP con los puertos definidos en ETC.SERVICES, ya que estas definiciones tienen distintas finalidades. Los puertos definidos en PROFILE.TCPIP se utilizan en TCPIP para ver si el puerto está reservado para un determinado servicio. ETC.SERVICES se utiliza en INETD para correlacionar un puerto con un servicio.
INETD, cuando recibe una petición en un puerto supervisado, bifurca un proceso hijo (con el servicio solicitado) que se llama inetdx, donde inetd es el nombre de trabajo de INETD (depende del método de arranque) y x es un número de un solo dígito.
Esto complica la reserva de puertos, ya que si un puerto supervisado por INETD está reservado en PROFILE.TCPIP, debe utilizar el nombre del procedimiento JCL iniciado para el espacio de direcciones de kernel z/OS UNIX para permitir que casi cualquier proceso se enlace con el puerto. Este nombre suele ser OMVS, a menos que se especifique explícitamente un nombre distinto en el parámetro STARTUP_PROC del miembro parmlib BPXPRMxx.
En la lista que sigue se explica cómo determinar el nombre del trabajo, dado el entorno en el que se ejecuta la aplicación:
El proceso INETD crea un archivo temporal, /etc/inetd.pid, que contiene el PID (ID de proceso) del daemon INETD que se ejecuta en este momento. Este valor de PID se emplea para identificar los registros de syslog que se originaron a partir del proceso INETD, y para proporcionar el valor de PID para los mandatos que lo necesiten, como el mandato kill. También se utiliza como mecanismo de bloqueo para impedir que haya más de un proceso INETD activo.
La implementación de INETD en z/OS UNIX se encuentra por defecto en /usr/sbin/inetd y admite dos parámetros de arranque opcionales que no dependen de la posición:
/usr/sbin/inetd [-d] [inetd.conf]
Debe iniciar INETD en tiempo de IPL. La manera más corriente de hacerlo es iniciarlo desde /etc/rc o /etc/inittab (solo en z/OS 1.8 o superior). También se puede iniciar desde un trabajo o una tarea iniciada mediante BPXBATCH o desde una sesión de shell de un usuario que posea la autorización pertinente.
Cuando se inicia desde el script de shell de inicialización de z/OS UNIX, /etc/rc, INETD emplea el orden de búsqueda de z/OS UNIX para localizar ETC.SERVICES. Se suministra un archivo /etc/rc de ejemplo como /samples/rc. Los mandatos de ejemplo que se pueden usar para iniciar INETD son los siguientes:
# Iniciar INETD _BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & sleep 5
z/OS 1.8 o superior proporciona un método alternativo, /etc/inittab, para emitir mandatos durante la inicialización de z/OS UNIX. /etc/inittab permite definir el parámetro respawn, que reinicia el proceso automáticamente cuando finaliza (se envía un WTOR al operador para un segundo reinicio al cabo de 15 minutos). Cuando se inicia desde /etc/inittab, INETD emplea el orden de búsqueda de z/OS UNIX para localizar ETC.SERVICES. Se suministra un /etc/inittab de ejemplo como /samples/inittab. El mandato de ejemplo que se puede usar para iniciar INETD es el siguiente:
# Iniciar INETD inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf
El método de inicio BPXBATCH funciona para las tareas iniciadas y trabajos de usuario. Observe que INETD es un proceso en segundo plano, por lo que el paso BPXBATCH para iniciar INETD finalizará unos segundos después del arranque. Cuando se inicia con BPXBATCH, INETD emplea el orden de búsqueda de z/OS UNIX para localizar ETC.SERVICES. El JCL que figura en el ejemplo de código siguiente es un procedimiento de ejemplo para iniciar INETD (el paso KILL elimina un proceso INETD activo, si lo hay):
//INETD PROC PRM= //* //KILL EXEC PGM=BPXBATCH,REGION=0M, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD SYSOUT=* //* STDIN, STDOUT y STDENV toman por defecto el valor /dev/null //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Cuando se inicia desde una sesión de shell, INETD emplea el orden de búsqueda de z/OS UNIX para localizar ETC.SERVICES. Los siguientes mandatos de ejemplo se pueden utilizar (si el usuario que los emite tiene autorización suficiente) para detener e iniciar INETD (# es el indicador de z/OS UNIX):
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd &
INETD es un proceso z/OS UNIX y, por lo tanto, exige definiciones de OMVS válidas en el software de seguridad para el ID de usuario asociado a INETD. Hay que establecer UID, HOME y PROGRAM para el ID de usuario, junto con el GID para el grupo predeterminado del usuario. Si INETD se inicia mediante /etc/rc o /etc/inittab, el ID de usuario se hereda del kernel z/OS UNIX, y su valor predeterminado es OMVSKERN.
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD + OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
INETD es un daemon que necesita acceso a funciones como setuid(). Por lo tanto, el ID de usuario empleado para iniciar INETD debe tener acceso de lectura (READ) al perfil BPX.DAEMON, en la clase FACILITY. Si este perfil no está definido, el UID 0 es obligatorio.
PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)
El ID de usuario de INETD también debe tener permiso de ejecución (EXECUTE) para el programa inetd (/usr/sbin/inetd), acceso de lectura (READ) a sus archivos inetd.conf y ETC.SERVICES, y acceso de escritura (WRITE) a /etc/inetd.pid. Si desea ejecutar INETD sin el UID 0, puede otorgar acceso de control (CONTROL) al perfil SUPERUSER.FILESYS, en la clase UNIXPRIV, para proporcionar los permisos necesarios sobre los archivos z/OS UNIX.
Los programas que necesiten autorización de daemon deben estar controlados por programa si BPX.DAEMON está definido en la clase FACILITY. Esto ya se hace para el programa INETD predeterminado (/usr/sbin/inetd), pero se debe establecer manualmente si se propone utilizar una copia o una versión personalizada. Utilice el mandato extattr +p para hacer que un archivo z/OS UNIX esté controlado por programa. Utilice la clase PROGRAM de RACF para hacer que un módulo de carga MVS esté controlado por programa.
Los programadores del sistema que tengan que reiniciar INETD desde dentro de su sesión de shell iniciarán INETD utilizando sus permisos. Por lo tanto, deben tener la misma lista de permisos que el ID de usuario normal de INETD. Además, también necesitan permisos para listar y detener el proceso INETD. Esto se puede lograr de muchas maneras.
Esta configuración no está recomendada para los ID de usuario "humanos", porque no hay restricciones relacionadas con z/OS UNIX.
Permite que el usuario se convierta en UID 0 con el mandato su. Esta es la configuración recomendada.
Consulte la publicación UNIX System Services Command Reference (SA22-7802) para obtener más información acerca de los mandatos extattr y su. Consulte la publicación UNIX System Services Planning (GA22-7800) para obtener más información acerca de la clase UNIXPRIV y los perfiles BPX.* de la clase FACILITY. Consulte la publicación Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información acerca de las definiciones de segmento OMVS y la clase PROGRAM.
Developer for System z depende de INETD para la gestión de REXEC y/o SSH. También puede imponer requisitos adicionales sobre la configuración de INETD descrita anteriormente.
REXEC (o SSH) se utiliza para las dos finalidades siguientes, descritas en la sección (Opcional) Utilizar REXEC (o SSH).
Las acciones remotas de subproyectos z/OS UNIX no requieren valores especiales. Sin embargo, el método de inicio de RSE alternativo no requiere valores especiales.
Los valores del entorno INETD, que se pasan al iniciar un proceso, y los permisos del ID de usuario de INETD deben estar debidamente establecidos para que INETD inicie el servidor RSE.
El daemon REXEC (o SSH) que se inicia mediante INETD cuando un cliente se conecta al puerto 512 (o 22, respectivamente) se utiliza para la autenticación, para iniciar el servidor RSE y para devolver el número de puerto de nuevo al cliente para una comunicación ulterior. Para poder hacerlo, el ID de usuario asignado al daemon REXEC (o SSH) (en inetd.conf) necesita tener los siguientes permisos:
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar APPC (comunicaciones avanzadas programa a programa) o durante la tarea de comprobar o modificar una configuración existente.
Consulte las publicaciones MVS Planning: APPC/MVS Management (SA22-7599) y MVS Initialization and Tuning Reference (SA22-7592) para obtener información adicional acerca de la gestión de APPC y los miembros parmlib descritos más adelante.
Tenga en cuenta que no se trata de describir una configuración completa de APPC, sino tan solo de resaltar algunos aspectos clave que podrían ser válidos para su local.
El miembro SYS1.SAMPLIB(ATBALL) contiene una lista (con sus descripciones) de todos los miembros (de ejemplo) relacionados con APPC en SYS1.SAMPLIB.
APPC/MVS almacena sus datos de configuración en los siguientes miembros SYS1.PARMLIB y en dos conjuntos de datos VSAM:
El TP es un programa de aplicación que emplea APPC para comunicarse con un TP en el mismo sistema o en otro con el fin de acceder a recursos. La configuración APPC de Developer for System z activa un nuevo TP que se llama FEKFRSRV, y al que nos referimos como servicio de mandatos TSO.
El trabajo siguiente es una concatenación de miembros de ejemplo SYS1.SAMPLIB(ATBTPVSM) y SYS1.SAMPLIB(ATBSIVSM), y se puede usar para definir los VSAM de APPC.
//APPCVSAM JOB <parámetros del trabajo> //* //* PRECAUCIÓN: esto no es un procedimiento JCL ni un trabajo completo. //* Antes de usar este ejemplo, tendrá que hacer las siguientes //* modificaciones: //* 1. Cambie los parámetros de trabajo para que respondan a los requisitos de su sistema. //* 2. En lugar de ******, escriba el volumen en el que se pondrán los VSAM de APPC. //* //TP EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7024) - KEYS(112 0) - RECORDS(300 150)) - DATA (NAME(SYS1.APPCTP.DATA)) - INDEX (NAME(SYS1.APPCTP.INDEX)) //* //SI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCSI) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(248 248) - KEYS(112 0) - RECORDS(50 25)) - DATA (NAME(SYS1.APPCSI.DATA)) - INDEX (NAME(SYS1.APPCSI.INDEX)) //*
APPC es una implementación del protocolo LU 6.2 de la arquitectura de red de sistemas (SNA). SNA proporciona formatos y protocolos que definen una gran variedad de componentes SNA físicos y lógicos, como la unidad lógica (LU). LU 6.2 es un tipo de unidad lógica que se ha diseñado específicamente para manejar las comunicaciones entre programas de aplicación.
Para poder usar SNA en MVS, debe instalar y configurar VTAM (método de acceso de telecomunicaciones virtuales). Para poder utilizar las tareas del sistema APPC, primero hay que activar VTAM.
La parte específica de APPC de la configuración de VTAM consta de tres pasos:
El nombre-acb (ACBNAME) de MVSLU01 empleado en el miembro de ejemplo SYS1.SAMPLIB(ATBAPPL) se puede cambiar para que coincida con los estándares del local, pero debe coincidir con las definiciones existentes en el miembro SYS1.PARMLIB(APPCPMxx).
MVSLU01 APPL ACBNAME=MVSLU01, C APPC=YES, C AUTOSES=0, C DDRAINL=NALLOW, C DLOGMOD=APPCHOST, C DMINWNL=5, C DMINWNR=5, C DRESPL=NALLOW, C DSESLIM=10, C LMDENT=19, C MODETAB=LOGMODES, C PARSESS=YES, C SECACPT=CONV, C SRBEXIT=YES, C VPACING=1
Consulte la publicación Communications Server IP SNA Network Implementation Guide (SC31-8777) para obtener más información acerca de la configuración de VTAM.
Para habilitar y hacer posible el flujo de conversaciones entre sistemas, los locales deben definir unidades lógicas (LU) entre las que poder enlazar sesiones. Cada local debe definir como mínimo una LU para que pueda tener lugar el proceso de APPC/MVS, aun cuando el proceso de APPC permanezca en un solo sistema. Las LU son parte de las definiciones que se realizan en SYS1.PARMLIB(APPCPMxx).
El servicio de mandatos TSO exige que APPC esté configurado de tal manera que tenga un LU base que pueda manejar las peticiones de entrada y las de salida.
La definición de LU se tiene que añadir al miembro SYS1.PARMLIB(APPCPMxx) y debe incluir los parámetros BASE y SCHED(ASCH). El miembro APPCPMxx también especifica qué conjuntos de datos VSAM de perfil de transacción (TP) y de información complementaria (SI) se emplearán.
El ejemplo de código que sigue es un miembro SYS1.PARMLIB(APPCPMxx) que puede utilizarse para el servicio de mandatos TSO.
LUADD ACBNAME(MVSLU01) BASE SCHED(ASCH) TPDATA(SYS1.APPCTP) SIDEINFO DATASET(SYS1.APPCSI)
Cuando un sistema tiene múltiples nombres de LU, habrá que hacer algunos cambios en función de qué LU seleccione el sistema para que sea la LU BASE. La LU BASE del sistema se determina mediante lo siguiente:
Si su sistema tiene una LU con los parámetros BASE y NOSCHED, esta LU se emplearía como LU BASE, pero el servicio de mandatos TSO no funcionaría, porque esta LU no tiene un planificador de transacciones que maneje las peticiones a la transacción FEKFRSRV. Si no se puede cambiar esta LU con el fin de eliminar el parámetro NOSCHED, se puede establecer que la variable de entorno _FEKFSCMD_PARTNER_LU de rsed.envvars sea la LU que tenga BASE y SCHED(ASCH), como en:
_FEKFSCMD_PARTNER_LU=MVSLU01
Para obtener más información sobre rsed.envvars, vea: rsed.envvars, archivo de configuración de RSE.
El planificador de transacciones APPC/MVS (cuyo nombre predeterminado es ASCH) inicia y planifica los programas de transacciones como respuesta a las peticiones de entrada que solicitan conversaciones. El miembro SYS1.PARMLIB(ASCHPMxx) controla su funcionamiento, por ejemplo, con definiciones de clase de transacción.
La clase de transacción APPC que se utilice para el servicio de mandatos TSO debe tener suficientes iniciadores APPC para permitir un iniciador para cada usuario de Developer for System z.
Para el servicio de mandatos TSO, también hay que especificar las especificaciones predeterminadas en las secciones OPTIONS y TPDEFAULT.
El ejemplo de código que sigue es un miembro SYS1.PARMLIB(ASCHPMxx) que puede utilizarse para el servicio de mandatos TSO.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200) OPTIONS DEFAULT(A) TPDEFAULT REGION(2M) TIME(5) MSGLEVEL(1,1) OUTCLASS(X)
Ahora se pueden activar los cambios de configuración documentados en los pasos anteriores. Hay distintas maneras de hacerlo, en función de las circunstancias:
Añada estos mandatos a SYS1.PARMLIB(COMMNDxx) para que se inicien en el momento del arranque del sistema.
Para verificar la configuración de APPC, se pueden usar los mandatos de consola D APPC y D ASCH. Consulte la publicación MVS System Commands (GC28-1781) para obtener más información acerca de los mandatos de consola mencionados.
Una vez que APPC/MVS esté activo, se puede definir el servicio de mandatos TSO de Developer for System z, como se describe en: (Opcional) Transacción APPC para el servicio de mandatos TSO.
La manera documentada de definir la transacción APPC consiste en personalizar y someter FEK.#CUST.JCL(FEKAPPCC).
La transacción APPC también se puede definir en modalidad interactiva mediante la interfaz ISPF de APPC, que viene documentada en un libro blanco. En este libro blanco también se describe cómo configurar la transacción APPC para que recoja información de contabilidad específica del usuario.
El documento APPC and WebSphere Developer for System z (SC23-5885-00) está disponible en la biblioteca internet de Developer for System z, en el sitio http://www-306.ibm.com/software/awdtools/rdz/library/.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Developer for System z da soporte a opciones de configuración alternativas de APPC y VTAM, algunas de las cuales se describen en esta sección.
El nombre de transacción alternativo para el servicios de mandatos TSO es FEKFRSRV, como se describe en la sección (Opcional) Transacción APPC para el servicio de mandatos TSO. Como se describe en la misma sección, este nombre puede cambiarse al definir la transacción en APPC.
Tenga en cuenta que cambiar el nombre de transacción en APPC implica asignar el nuevo nombre a _FEKFSCMD_TP_NAME_ en rsed.envvars, como se describe en la sección rsed.envvars, archivo de configuración de RSE.
APPC es un protocolo de comunicaciones que permite que un programa (el nodo asociado) interactúe con un programa del host (el nodo local). Con Developer for System z, tanto el nodo asociado (servidor de mandatos TSO) como el nodo local (servidor RSE) están activos en el mismo sistema z/OS. Y, por omisión, ambos utilizan la misma definición de LU (BASE) para comunicarse entre sí.
Puede especificar un nombre de LU asociada alternativo para el servicio de mandatos TSO en la directiva _FEKFSCMD_PARTNER_LU_ de rsed.envvars, como se describe en la sección rsed.envvars, archivo de configuración de RSE. Tenga en cuenta que no puede cambiar la LU local, que debe ser siempre una LU BASE válida (tener las palabras clave BASE y SCHED).
VTAM da soporte a un configuración de APPC segura, en la que la comunicación entre la LU asociada y la local debe definirse para el software de seguridad.
Estos e activa añadiendo VERIFY=REQUIRED a la definición VTAM de la LU local (BASE). Las definiciones de seguridad deben realizarse en la clase APPCLU, como se describe en la publicación MVS Planning: APPC/MVS Management (SA22-7599).
Tenga en cuenta que, si esta configuración está activa en VTAM y la configuración del software de seguridad no está completa, la comunicación con el servicio de mandatos TSO no podrá inicializarse sin mensajes en las anotaciones del sistema que indiquen que VTAM ha rehusado configurar la conexión. La prueba de IVP de APPC (fekfivpa) fallará con el mensaje "Código de retorno 1 - Anomalía de asignación sin reintento".
Este apéndice enumera los prerrequisitos y correquisitos del host para esta versión de Developer for System z.
Consulte el manual Rational Developer for System z Prerequisites (SC23-7659) en la biblioteca en línea del Developer for System z en http://www-01.ibm.com/software/awdtools/rdz/library/ si desea obtener una lista actualizada de los requisitos necesarios y opcionales.
Los productos enumerados en esta sección están todos disponibles en el momento de publicación de este manual. Consulte el sitio web IBM Software Support Lifecycle http://www.ibm.com/software/support/lifecycle/, para ver si un producto seleccionado está todavía disponible cuando desee utilizar la función de Developer for System z relacionada.
Para utilizar Developer for System z debe tener el entorno siguiente con los prerrequisitos adecuados:
Uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5694-A01 | z/OS v 1.11 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.10 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.9 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.8 |
ISPF:
TCP/IP:
|
El sitio web correspondiente al producto es:
A fin de instalar Developer for System z, uno de los niveles siguientes debe estar instalado:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-G44 | IBM System Modification Program Extended (SMP/E) for z/OS v 3.5 | No se necesitan arreglos PTF ni niveles de servicio |
5655-G44 | IBM System Modification Program Extended (SMP/E) for z/OS v 3.4 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
A fin de soportar aplicaciones que utilizan el Explorador de sistemas remotos (RSE), uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-R32 | IBM 64-bit SDK for z/OS, Java 2 Technology Edition, v 6.0 | release de servicio 7 |
5655-R31 | IBM 31-bit SDK for z/OS, Java 2 Technology Edition, v 6.0 | release de servicio 7 |
5655-N99 | IBM 64-bit SDK for z/OS, Java 2 Technology Edition, v 5.0 | release de servicio 11 |
5655-N98 | IBM 31-bit SDK for z/OS, Java 2 Technology Edition, v 5.0 | release de servicio 11 |
El sitio web correspondiente al producto es:
Para soportar características específicas de Developer for System z, se necesitan los productos enumerados en esta sección y el software adicional indicado. El cliente de estación de trabajo de Developer for System z se puede instalar satisfactoriamente sin estos requisitos. Sin embargo, los requisitos de host indicados deben estar instalados y ser operativos en tiempo de ejecución para que la característica correspondiente funcione como es debido.
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5694-A01 | z/OS v 1.11 |
HLASM No se necesitan arreglos PTF ni niveles de servicio
XL C/C++ No se necesitan arreglos PTF ni niveles de servicio
SCLM No se necesitan arreglos PTF ni niveles de servicio
LE (PL/I) No se necesitan arreglos PTF ni niveles de servicio
TN3270 No se necesitan arreglos PTF ni niveles de servicio |
5694-A01 | z/OS v 1.10 |
HLASM No se necesitan arreglos PTF ni niveles de servicio
XL C/C++ No se necesitan arreglos PTF ni niveles de servicio
SCLM No se necesitan arreglos PTF ni niveles de servicio
LE (PL/I) No se necesitan arreglos PTF ni niveles de servicio
TN3270 No se necesitan arreglos PTF ni niveles de servicio |
5694-A01 | z/OS v 1.9 |
HLASM No se necesitan arreglos PTF ni niveles de servicio
XL C/C++ No se necesitan arreglos PTF ni niveles de servicio
SCLM
LE (PL/I) No se necesitan arreglos PTF ni niveles de servicio
TN3270 No se necesitan arreglos PTF ni niveles de servicio |
5694-A01 | z/OS v 1.8 |
HLASM No se necesitan arreglos PTF ni niveles de servicio
XL C/C++ No se necesitan arreglos PTF ni niveles de servicio
SCLM
LE (PL/I)
TN3270 No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
El sitio web correspondiente al producto es:
El sitio web correspondiente al producto es:
El sitio web correspondiente al producto es:
El sitio web correspondiente al producto es:
El sitio web correspondiente al producto es:
Para compilar los programas COBOL desarrollados o editados en Developer for System z, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-S71 | IBM Enterprise COBOL for z/OS v 4.2 | No se necesitan arreglos PTF ni niveles de servicio |
5655-S71 | IBM Enterprise COBOL for z/OS v 4.1 | No se necesitan arreglos PTF ni niveles de servicio |
5535-G53 | IBM Enterprise COBOL for z/OS v 3.4 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
Para compilar los programas PL/I desarrollados o editados en Developer for System z, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-H31 | IBM Enterprise PL/I for z/OS v 3.9 | No se necesitan arreglos PTF ni niveles de servicio |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.8 | No se necesitan arreglos PTF ni niveles de servicio |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.7 | No se necesitan arreglos PTF ni niveles de servicio |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.6 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
Para soportar la depuración remota desde Developer for System z, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Lenguaje de programación | Informes APAR, arreglos PTF o niveles de servicio necesarios |
---|---|---|---|
5655-V50 | IBM Debug Tool for z/OS V10.1 | COBOL, PL/I, C/C++, assembler y características adicionales | Todo el mantenimiento disponible |
5655-U27 | IBM Debug Tool for z/OS V9.1 | COBOL, PL/I, C/C++, assembler y características adicionales | Todo el mantenimiento disponible |
5655-S16 | IBM Debug Tool Utilities and Advanced Functions for z/OS V8.1.0 | COBOL, PL/I, C/C++, assembler y características adicionales | Todo el mantenimiento disponible |
5655-S17 | IBM Debug Tool for z/OS V8.1.0 | COBOL, PL/I, Assembler, C/C++ | Todo el mantenimiento disponible |
El sitio web correspondiente al producto es:
Iniciando la versión 9, Debug Tool para z/OS y Debug Tool Utilities y funciones avanzadas se han fusionado en una única oferta.
Para soportar aplicaciones con sentencias CICS incluidas, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-S97 | IBM CICS Transaction Server for z/OS v 4.1 | No se necesitan arreglos PTF ni niveles de servicio |
5697-E93 | IBM CICS Transaction Server for z/OS v 3.2 | UK34221 |
5697-E93 | IBM CICS Transaction Server for z/OS v 3.1 | UK15767, UK15764, UK11782, UK11294, UK12233, UK12521, UK15261, UK15271, UK34221, UK34078 |
El sitio web correspondiente al producto es:
Para obtener una lista completa de los requisitos específicos en tiempo de ejecución, consulte la documentación de las herramientas de servicio de empresa (EST) en el Information Center de IBM Rational Developer for System z en http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/.
Para soportar aplicaciones que utilizan las comunicaciones de datos y la base de datos de IMS, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5635-A02 | IBM IMS v 11.1 | No se necesitan arreglos PTF ni niveles de servicio |
5635-A01 | IBM IMS v 10.1 | No se necesitan arreglos PTF ni niveles de servicio |
5655-J38 | IBM IMS v 9.1 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
Para soportar DB2, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5635-DB2 | IBM DB2 for z/OS v 9.1 | No se necesitan arreglos PTF ni niveles de servicio |
5625-DB2 | IBM DB2 Universal Database for z/OS v 8.1 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web correspondiente al producto es:
Para el control de fuente basadas Jazz mediante proyectos remotos de Developer for System z, debe estar instalado el siguiente nivel.
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5724-V82 | Rational Team Concert para System z Server v 2.0 |
FMID HAHA200 - Team Server
FMID HAHB200 - Kit de herramientas
FMID HAHC200 - Supervisor de trabajos
FMID HAHD200 - Agente BuildForge
|
El sitio web correspondiente al producto es:
Para soportar la integración del Gestor de archivos, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-U29 | IBM File Manager para z/OS v 10.1 |
|
El sitio web correspondiente al producto es:
Para soportar la integración del Analizador de errores, los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5655-V51 | IBM Fault Analyzer v 10.1 | No se necesitan arreglos PTF ni niveles de servicio |
5655-U28 | IBM Fault Analyzer v 9.1 | No se necesitan arreglos PTF ni niveles de servicio |
5655-S15 | IBM Fault Analyzer v 8.1 | No se necesitan arreglos PTF ni niveles de servicio |
El sitio web del producto relacionado es el siguiente:
Para utilizar SCLM Developer Toolkit, uno de los niveles siguientes debe estar instalado en el host:
Número de programa | Nombre de producto | Arreglos PTF o niveles de servicio necesarios |
---|---|---|
5695-014 | IBM Library for REXX on zSeries v 1.4 | No se necesitan arreglos PTF ni niveles de servicio |
5695-014 | IBM Library for REXX on zSeries Alternate Library v 1.4.0 (FMIDs HWJ9143, JWJ9144) | No se necesitan arreglos PTF ni niveles de servicio |
Una versión de REXX/370 Alternate Library está disponible en el sitio web del producto, en
IBM Ported Tools for z/OS debe estar instalado (en z/OS UNIX) para utilizar sftp o scp para realizar un despliegue seguro en SCLM Developer Toolkit.
En el sitio web del producto hay una versión de IBM Ported Tools for z/OS disponible:
Apache Ant debe estar instalado (en z/OS UNIX) para hacer construcciones JAVA/J2EE en SCLM Developer Toolkit.
Apache Ant es una herramienta de construcción basada en Java, de código fuente abierto que puede descargar desde el sitio web del producto:
CA Endevor® Software Change Manager Release 12 debe estar instalado para poder utilizar Developer for System z Interface for CA Endevor® SCM.
CA Endevor® SCM es un producto de CA. El sitio web del producto relacionado es:
http://www.ca.com/us/products/product.aspx?ID=259
Las publicaciones a las que se hace referencia en este documento son:
Título de la publicación | Número de pedido | Referencia | Sitio Web de referencia |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 5.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Directorio de programa para IBM Rational Developer for System z | GI11-8627 (GI11-8298) | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Requisitos previos | SC23-7659 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Inicio rápido de configuración de host | GI11-8628 (GI11-9201) | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Guía de planificación de host | GI11-7839 (GI11-8296) | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Guía del administrador de SCLM Developer Toolkit | SC11-3815-00 (SC23-9801) | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
APPC and WebSphere Developer for System z | SC23-5885 | Documento | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Language Reference | SC27-1408 | Enterprise COBOL para z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
En este documento se hace referencia a los siguientes sitios Web:
Descripción | Sitio Web de referencia |
---|---|
Information Center de Developer for System z | http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp |
Soporte de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/support/ |
Biblioteca de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Página inicial de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/ |
Servicio recomendado de Developer for System z | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Solicitud de mejoras de Developer for System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
Biblioteca internet de z/OS | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Information Center de CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
Descargar Apache Ant | http://ant.apache.org/ |
Documentación de keytool de Java | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Página inicial de soporte de CA | https://support.ca.com/ |
Las publicaciones siguientes pueden serle de utilidad para entender aspectos de configuración de los componentes de host obligatorios:
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/ |
© Copyright IBM Corporation - 2010
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.
Para consultas sobre licencias relativas a la información 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:
El párrafo siguiente no se aplica en el Reino Unido ni en ningún otro país en el que tales disposiciones sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS O CONDICIONES IMPLÍCITAS DE NO VULNERACIÓN, DE COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la declaración de limitación de responsabilidad, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso.
Esta información puede contener imprecisiones técnicas o errores tipográficos. La información incluida en este documento está sujeta a cambios periódicos; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento y sin previo aviso.
Cualquier referencia 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 estos sitios Web no forman parte de los materiales de IBM para este producto, y el usuario será responsable del uso que se haga de estos sitios Web.
IBM puede utilizar o distribuir la información que usted le suministre del modo que IBM considere conveniente sin incurrir por ello en ninguna obligación para con usted.
Los licenciatarios de este programa que deseen obtener información acerca de él con el fin de: (i) intercambiar la información entre los programas creados independientemente y otros programas (incluido este) y (ii) utilizar mutuamente la información que se ha intercambiado, deben ponerse en contacto con:
Dicha información puede estar disponible, sujeta a los términos y condiciones apropiados, incluyendo en algunos casos el pago de una cantidad.
IBM proporciona el programa bajo licencia descrito en este documento, así como todo el material bajo licencia disponible, según los términos del Acuerdo de Cliente de IBM, del Acuerdo Internacional de Programas bajo Licencia de IBM o de cualquier otro acuerdo equivalente entre ambas partes.
Los datos de rendimiento que se indican en este documento se han obtenido en un entorno controlado. Por consiguiente, es posible que los resultados que se obtengan en otros entornos operativos sean notablemente distintos. Es posible que algunas mediciones se hayan tomado en sistemas de nivel de desarrollo y no existe ningún tipo de garantía de que dichas mediciones sean las mismas en sistemas disponibles para el público en general. Además, es posible que algunas mediciones se hayan estimado mediante extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deberán verificar los datos aplicables para su entorno específico.
La información concerniente a productos no IBM se ha obtenido de los suministradores de dichos productos, de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no ha comprobado dichos productos y no puede afirmar la exactitud en cuanto a rendimiento, compatibilidad u otras características relativas a productos no IBM. Las consultas acerca de las posibilidades de los productos que no son de IBM deben dirigirse a las personas que los suministran.
Todas las declaraciones relacionadas con la dirección o intención futuras de IBM están sujetas a cambio o retirada sin previo aviso, y únicamente representan objetivos.
Esta información contiene ejemplos de datos e informes utilizados en operaciones comerciales diarias. Para ilustrarlos de la forma más completa posible, los ejemplos incluyen nombres de personas, empresas, marcas y productos. Todos estos nombres son ficticios y cualquier parecido con los nombres y direcciones utilizados por una empresa real es mera coincidencia.
Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que ilustran las técnicas de programación en diversas plataformas operativas. Puede copiar, modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar a IBM, con intención de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con la interfaz de programación de aplicaciones (API) de la plataforma operativa para la que están escritos los programas de ejemplo. Los ejemplos no se han probado minuciosamente bajo todas las condiciones. Por lo tanto, IBM no puede garantizar ni dar por sentada la fiabilidad, la facilidad de mantenimiento ni el funcionamiento de los programas. Los programas de ejemplo se proporcionan "TAL CUAL", sin ningún tipo de garantía. IBM no se hace responsable de los daños que se hayan podido causar debido al uso de los programas de ejemplo.
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
Rational es una marca registrada de International Business Machines Corporation y Rational Software Corporation en Estados Unidos y/o en otros países.
Intel® y Pentium® son marcas registradas de Intel Corporation en los Etados Unidos y/o en otros pasíses.
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 y logotipos basados en Java son marcas registradas de Sun Microsystems, Inc., en 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.