Antes de utilizar este documento, lea la información general que figura en el apartado Avisos.
Esta edición atañe a IBM Rational Developer para System z Versión 7.1.1 (programa número 5724-T07) y a todos los releases y modificaciones ulteriores hasta que se indique lo contrario en nuevas ediciones.
Puede pedir las publicaciones por teléfono o por fax. IBM Software Manufacturing Solutions acepta los pedidos de publicaciones entre las 8:30 de la mañana y las 7:00 de la tarde, hora estándar del este (EST). El número de teléfono es (800) 879-2755. El número de fax es (800) 445-9269. Los faxes deben enviarse a Attn: Publications, 3rd floor.
También puede pedir publicaciones a través de su representante de IBM o de la sucursal de IBM que presta servicio en su localidad. En la dirección que figura más abajo no hay publicaciones almacenadas.
IBM agradece sus comentarios. Puede enviar sus comentarios por correo a la siguiente dirección:
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 reproducción o la divulgación están sujetos a las restricciones establecidas en el contrato GSA ADP Schedule Contract con IBM Corp.
En esta publicación se estudia la configuración de las funciones de IBM Rational Developer para System z. Incluye instrucciones que explican cómo configurar servidores IBM Rational Developer para System z 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 para System z, IBM WebSphere Developer para zSeries y 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.
Esta publicación está destinada a los programadores de sistemas que instalan y configuran IBM Rational Developer para System z Versión 7.1.1 en su sistema de hospedaje z/OS. Para utilizar esta publicación, debe estar familiarizado con los sistemas de hospedaje z/OS UNIX y MVS.
Las publicaciones a las que se hace referencia en este documento son:
Título de la publicación | Número de pedido | Referencia | Enlace de referencia |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/index.html |
Java SDK and Runtime Environment User Guide | Java 5.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ | |
Program Directory for IBM Rational Developer for System z | GI11-8298-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Rational Developer for System z Common Access Repository Manager | GI11-8299-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Software Configuration and Library Manager (SCLM) Developer Toolkit | GI11-8306-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Application Deployment Manger User's Guide | SC23-7661 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer para System z Guía de configuración de host | SC11-3660 (SC23-7658) | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer para System z Guía de planificación de host | GI11-7839-00 (GI11-8296-00) | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
SCLM Developer Toolkit Installation and Customization Guide | SC23-8504 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
ABCs of z/OS System Programming Volume 9 | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
APPC and WebSphere Developer for System z | SC23-5885 | Libro blanco | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Host Based Projects in WebSphere Developer for System z version 7.0 | Libro blanco | http://www-306.ibm.com/software/awdtools/rdz/library/index.html | |
Setting up SSL for RSE Communication | SC23-5816 | Libro blanco | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Manual de servidor de comunicaciones | F1A1BK61 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Manual de MVS | IEA2BK60 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services File System Interface Reference | SA22-7808 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Para cada una de las siguientes funciones, instale los FMID necesarios. Para obtener información de instalación sobre los diversos FMID, consulte el directorio de programas correspondiente al FMID que se propone instalar.
Si necesita esta función de IBM Rational Developer para System z | Debe instalar estos FMID | Y aquí encontrará información de instalación y configuración |
---|---|---|
|
HHOP710, HSD3310* |
opcional
|
|
HCMA710, HHOP710** |
opcional
|
|
HSD3310 |
|
(*) Para Developer para System z se necesita una conexión con el servicio de mandatos TSO en z/OS. Esta conexión se proporciona mediante uno de estos procedimientos:
(**) Para CARMA se necesita una interfaz basada en host. Esta función se proporciona mediante HHOP710, pero también se puede utilizar una interfaz basada en host de construcción personalizada y omitir la instalación de HHOP710.
Hay que realizar los siguientes pasos de personalización de SCLMDT, pasos que se describen en el manual SCLM Developer Toolkit Installation and Customization Guide (SC23-8504):
Para obtener instrucciones detalladas de la instalación de SMP/E para cada uno de los FMID, consulte el directorio de programas pertinente, cuya lista encontrará en la Tabla 2.
Developer para System z tiene una lista del software prerrequisito que hay que instalar y debe estar operativo para que el producto funcione. También hay una lista del software correquisito para poder utilizar las características específicas de Developer para 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 el manual Rational Developer para System z Guía de planificación del host, GI11-7839-00 (GI11-8296-00) si desea obtener una lista de los prerrequisitos y correquisitos para su versión de Developer para System z.
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.
Hay que realizar los siguientes pasos de personalización de SCLMDT, pasos que se describen en el manual SCLM Developer Toolkit Installation and Customization Guide (SC23-8504):
Puede probar la configuración de TCP/IP con el mandato TSO HOMETEST. Consulte el apartado de mandatos TSO, en el manual Communications Server IP System Administrator's Commands (SC31-8781) para obtener más información sobre este mandato.
Salida de ejemplo del mandato HOMETEST:
Ejecutar IBM MVS TCP/IP CS V1R7 TCP/IP Configuration Tester El archivo de parámetros de configuración de FTP utilizado será "SYS1.TCPPARMS(FTPDATA)" El nombre de host TCP es: CDFMVS08 Utilizar el servidor de nombres para resolver CDFMVS08 Las siguientes direcciones IP corresponden al nombre de host TCP: CDFMVS08 9.42.112.75 Las siguientes direcciones IP son las direcciones IP HOME definidas en PROFILE.TCPIP: 9.42.112.75 127.0.0.1 ¡Todas las direcciones IP de CDFMVS08 están en la lista HOME! La prueba de Home ha sido satisfactoria - ¡Se han superado todas las pruebas!
El ID de un usuario de Developer para 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
Los siguientes 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 para System z tienen tráfico solo de host. Es decir, para Developer para System z, los puertos enumerados son los únicos que se deben definir ante el cortafuegos que protege el host.
INETD es un proceso servidor z/OS UNIX que se necesita para configurar las conexiones entre cliente y host de Developer para System z. 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.
Para obtener más información sobre los permisos de INETD, vea: Apéndice D. Configurar INETD.
El Explorador de Sistemas Remotos (RSE) es el componente de Developer para System z que proporciona servicios centrales como los de conectar el cliente al host.
Para la configuración de Developer para System z se necesita más que los permisos típicos del programador de sistemas, porque cabe esperar una mínima ayuda por parte de otras personas. En la siguiente lista se resaltan las áreas más importantes:
Developer para System z y el gestor de repositorios de acceso común (CARMA) permiten 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 para la personalización, ese archivo debe sustituir a su equivalente en las listas que figuran más abajo.
En este apartado se resaltan los cambios de instalación y configuración comparados con los releases anteriores del producto. Para obtener más información, consulte las secciones relacionadas de este manual.
Antes de instalar Developer para System z versión 7.1.1, si es usted un usuario anterior de Developer para System z, le recomendamos que guarde los archivos personalizados relacionados. Si piensa ejecutar múltiples instancias de Developer para System z, antes de empezar la personalización, lea: Apéndice A. Ejecutar múltiples instancias de Developer para System z.
Tabla 3 y Tabla 4 proporcionan una visión general de los archivos que se pueden haber personalizado para Developer para System z y CARMA versión 6.0.1 o superior. Tabla 5 proporciona una lista de las personalizaciones de conjuntos de datos, productos y software prerrequisito y correquisito que se producen durante una instalación de Developer para System z y CARMA versión 6.0.1 (o superior).
Miembro | Ubicación predeterminada v6.0.1 | Ubicación predeterminada v7.0/v7.1 | Finalidad |
---|---|---|---|
FEJJCNFG |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
Archivo de configuración del supervisor de trabajos JES |
FEJJJCL |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
JCL del supervisor de trabajos JES |
FEJTSO |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
JCL de sometimientos TSO |
FEKAPPCC | no existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para crear una transacción APPC |
FEKAPPCL | no existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para visualizar una transacción APPC |
FEKAPPCX | no existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para suprimir una transacción APPC |
FEKFRTAD |
hlq.SFEKSAMP (hlq = FEK) |
(nombre de miembro nuevo FEKAPPCC) | JCL para crear una transacción APPC |
FEKFRDIS |
hlq.SFEKSAMP (hlq = FEK) |
(nombre de miembro nuevo FEKAPPCL) | JCL para visualizar una transacción APPC |
FEKFRDEL |
hlq.SFEKSAMP (hlq =FEK) |
(nombre de miembro nuevo FEKAPPLX) | JCL para suprimir una transacción APPC |
ELAXF* |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para construcciones de proyectos remotos, etc. |
ELAXMSAM |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
Procedimiento JCL del espacio de direcciones WLM para el constructor de procedimientos almacenados PL/I y COBOL |
ELAXMJCL |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para definir el constructor de procedimientos almacenados PL/I y COBOL ante DB2 |
ADNVSAM | no existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para definir el repositorio CRD de ADM |
ADNPCCSD | no existe
|
hlq.SFEKSAMP (hlq = FEK) |
JCL para activar el servidor CRD en la región CICS primaria |
ADNCMSGH | no existe |
hlq.SFEKSAMP (hlq = FEK) (no existe en la versión 7.0) |
JCL para compilar el manejador de mensajes de conducto |
ADNSMSGH | no existe |
hlq.SFEKSAMP (hlq = FEK) |
Código fuente de ejemplo para el manejador de mensajes de conducto |
ADNARCSD | no existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para activar el servidor CRD en regiones CICS no primarias |
CRASUBMT |
hlq.SCRACLST (hlq = CRA) |
hlq.SCRACLST (help = CRA) |
CLIST para someter JCL de un servidor CARMA |
CRAMREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA$VMSG)(hlq = CRA) |
JCL para crear el VSAM de mensajes de CARMA |
CRAREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA$VDEF)(hlq = CRA) |
JCL para crear el VSAM de configuraciones de CARMA |
CRASREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA$VSTR)(hlq = CRA) |
JCL para crear el VSAM de información personalizada de CARMA |
CRALREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA#VSLM)(hlq = CRA) |
JCL para crear el VSAM de mensajes de RAM SCLM |
CRASALX |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA#ASLM)(hlq = CRA) |
JCL para crear los conjuntos de datos de RAM SCLM |
CRATREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (nombre de miembro nuevo en la versión 7.1 CRA#VPDS)(hlq = CRA) |
JCL para crear el VSAM de mensajes de RAM PDS |
Archivo | Ubicación predeterminada v6.0.1 | Ubicación predeterminada versión 7.0/versión 7.1 | Finalidad |
---|---|---|---|
rsed.envvars | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Archivo de configuración de RSE |
rsecomm.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Archivo de configuración de rastreo de RSE |
ssl.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Archivo de configuración SSL de RSE |
setup.env.zseries | /usr/lpp/wd4z/rse/lib/ | (ya no está personalizado) | Exportar variables de entorno RSE |
projectcfg.properties | (no existe) | /usr/lpp/wd4z/rse/lib/ | Archivo de configuración de proyectos de host |
FMIEXT.properties | (no existe) | /usr/lpp/wd4z/rse/lib/ (no existe en la versión 7.0) | Archivo de configuración del gestor de archivos |
CRASRV.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Archivo de configuración de CARMA |
rexxsub | /usr/lpp/wd4z/rse/lib/ | (ya no está personalizado) | REXX de CARMA z/OS UNIX para ejecutar MVS CRASUBMT CLIST |
Miembro/Archivo | Ubicación predeterminada | Personalización necesaria |
---|---|---|
BPXPRMxx | SYS1.PARMLIB | Establecer que MAXASSIZE sea igual o mayor que 2147483647 |
PROGxx | SYS1.PARMLIB | hlq.SFEKLOAD autorizada por APF |
ASCHPMxx | SYS1.PARMLIB | Definir una clase de transacción APPC para el servicio de mandatos TSO |
services | /etc/ | Definir daemon RSE |
inetd.conf | /etc/ | Definir daemon RSE |
ISPF.conf | /etc/SCLMDT/CONFIG/ | Definir ubicación del servidor de mandatos TSO |
/ | APPC | Definir una transacción APPC para el servicio de mandatos TSO |
/ | WLM | Asociar el programa de transacción APPC a un grupo de rendimiento TSO |
/ | WLM | Asignar un entorno de aplicaciones para el procedimiento almacenado de DB2 |
Antes de instalar la versión 7.1.1, si es usted un usuario anterior de Developer para System z, le recomendamos que guarde la personalización relacionada, como se describe en: Hacer copia de seguridad de archivos configurados con anterioridad.
En este capítulo, todas las referencias a hlq se refieren al calificador de alto nivel empleado durante la instalación de Developer para System z. El valor predeterminado de la instalación es FEK, pero quizá no sea válido para su local.
El requisito LINKLIST se puede dejar de lado si se añade una sentencia STEPLIB a rsed.envvars; vea: Personalizar rsed.envvars, el archivo de configuración de RSE.
MAXASSIZE define el tamaño de la región del espacio de direcciones (proceso). Establezca que MAXASSIZE, en SYS1.PARMLIB(BPXPRMxx), sea igual o mayor que 2147483647.
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 (SA22-7627).
1. DISPLAY OMVS,O 2. SETOMVS MAXASSIZE=2147483647
Para obtener más información sobre otras ubicaciones en las que se puede establecer o limitar el tamaño de los espacios de direcciones, consulte: Tamaño del espacio de direcciones.
Para que el supervisor de trabajos JES pueda acceder a los archivos de spool JES, el módulo FEJJMON de la biblioteca de carga hlq.SFEKLOAD debe estar autorizada por APF.
Las autorizaciones de APF se definen en SYS1.PARMLIB(PROGxx), si su local siguió las recomendaciones de IBM. Consulte el manual MVS Initialization and Tuning Reference (SA22-7592) si desea más información sobre cómo definir autorizaciones de APF.
Cuando la finalidad es someter a prueba, las autorizaciones de APF también se pueden otorgar dinámicamente. Durarán hasta la próxima IPL del sistema. El mandato de consola que se necesita sería como este:
SETPROG APF,ADD,DSN=hlq.SFEKLOAD,SMS
Consulte el manual MVS System Commands (SA22-7627) si desea obtener más información sobre el mandato SETPROG.
El supervisor de trabajos JES es el componente de Developer para System z que maneja toda la conectividad de JES. Se utiliza un archivo de configuración para personalizar determinados aspectos de acuerdo con los estándares de su local.
El archivo de configuración de ejemplo se encuentra en:
hlq.SFEKSAMP(FEJJCNFG)
El archivo consta de un conjunto de definiciones de variables de entorno. Las líneas de comentarios empiezan por el signo de almohadilla (#). El archivo de configuración de ejemplo figura en: Figura 1.
SERV_PORT=6715 CODEPAGE=UTF-8 HOST_CODEPAGE=IBM-1047 TZ=EST5EDT #LIMIT_VIEW=USERID LISTEN_QUEUE_LENGTH=5 MAX_DATASETS=32 MAX_THREADS=200 TIMEOUT_INTERVAL=1200 TIMEOUT=3600 AUTHMETHOD=RACF #_BPXK_SETIBMOPT_TRANSPORT=<nombre pila tcpip>
Las definiciones que se necesitan son las siguientes:
Las definiciones que figuran a continuación son opcionales. Si se omiten, se emplearán los valores predeterminados que se especifican más abajo:
El supervisor de trabajos JES es el componente de Developer para System z que maneja toda la conectividad de JES. Para ello, el servidor debe estar activo en el sistema (ya sea como trabajo de usuario o como STC). Siga los pasos de personalización del JCL que se encuentran en hlq.SFEKSAMP(FEJJJCL) para crear el servidor del supervisor de trabajos JES según los estándares de su local.
Debe activar el rastreo del supervisor de trabajos JES por motivos de diagnóstico, añadiendo "-TV" a la línea de PARM. El rastreo afectará negativamente al rendimiento y solo se debe activar cuando así lo indique el centro de soporte de IBM.
//JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/ -TV')
El rastreo también se puede controlar con los mandatos de la consola. Suponiendo que se utilice el nombre de trabajo JMON, el primer mandato de consola que figura más abajo activará el rastreo, y el segundo lo desactivará.
1. F JMON,APPL=-TV 2. F JMON,APPL=-TN
El supervisor de trabajos JES se puede ejecutar como trabajo de usuario o como tarea iniciada (STC). Para definir que JMON sea una STC, hay que implementar las siguientes tareas:
//JMON PROC HLQ=FEK, // PRM= //* //* RD/Z JES JOB MONITOR //* //JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/&PRM') //STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKLOAD //ENVIRON DD DISP=SHR,DSN=&HLQ..SFEKSAMP(FEJJCNFG) //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSIN DD DUMMY //*SYSTCPD DD DISP=SHR,DSN=SYS1.TCPIP.DATA
Para que resulte fácil hacerle referencia, conviene que el nombre del miembro coincida con el nombre del procedimiento (JMON en el ejemplo anterior).
Utilice el siguiente mandato de ejemplo para crear un ID de usuario de ese tipo, donde userid es el ID de usuario en cuestión, groupid es el grupo predeterminado y uid es el ID de UNIX.
ADDUSER userid DFLTGRP(groupid) NOPASSWORD OMVS(UID(uid) HOME(/tmp) PROGRAM(/bin/sh))
a. SETROPTS GENERIC(STARTED) b. RDEFINE STARTED ** STDATA(USER(=MEMBER)) c. SETROPTS CLASSACT(STARTED) d. SETROPTS RACLIST(STARTED)
Para añadir un supervisor de trabajos JES como tarea iniciada (STC), se necesitan los siguientes mandatos RACF, donde jmon es el nombre del miembro JCL y userid es el ID de usuario cuyas autorizaciones se tienen que utilizar.
a. RDEFINE STARTED jmon.* STDATA(USER(userid)) b. SETROPTS RACLIST(STARTED) REFRESH
Consulte el manual Security Server RACF Security Administrator's Guide (SA22-7683) para obtener más información sobre las tareas iniciadas y sobre la seguridad.
El operador del sistema puede emitir los siguientes mandatos en la consola (siendo JMON el nombre de la STC del supervisor de trabajos JES):
a. Start JMON b. stoP JMON c. Display A,JMON
Si posee la debida autorización, puede proporcionar estos mandatos desde dentro de SDSF, pero entonces hay que colocar una barra inclinada ('/') antes de los mandatos. Consulte el manual MVS System Commands (SA22-7627) para obtener más información sobre los mandatos de la consola.
Para el ID de usuario asignado al servidor del supervisor de trabajos JES se necesita el acceso de lectura (READ) a la biblioteca de carga de Developer para System z, hlq.SFEKLOAD.
Inicie el trabajo de usuario o la STC definidos en los pasos anteriores. Si el trabajo finaliza con el código de retorno 66, sabrá que hlq.SFEKLOAD no está autorizada por APF.
Para que los usuarios puedan ejecutar operaciones por medio del supervisor de trabajos JES, hay que otorgarles autorización de acceso a la clase OPERCMDS. Esto se puede hacer condicionalmente, de manera que los derechos de acceso de los usuarios solo estén en vigor cuando utilicen el supervisor de trabajos JES. Para utilizar esta comprobación de acceso condicional, debe tener activa la clase CONSOLE y haber definido una consola llamada JMON (el nombre JMON es el único válido).
Por ejemplo, el administrador de seguridad emitiría los siguientes mandatos de RACF:
1. SETROPTS CLASSACT(CONSOLE) 2. RDEFINE CONSOLE JMON UACC(READ) 3. SETROPTS RACLIST(CONSOLE) REFRESH
Utilice los siguientes mandatos de RACF para permitir a los usuarios emitir mandatos JES2 solo a través del supervisor de trabajos JES, siendo id el ID de usuario o el ID de grupo de los usuarios de Developer para System z:
1. RDEFINE OPERCMDS JES2.** UACC(NONE) 2. PERMIT JES2.** CLASS(OPERCMDS) ID(id) ACCESS(CONTROL) WHEN(CONSOLE(JMON)) 3. SETROPTS RACLIST(OPERCMDS) REFRESH 4. SETROPTS GENERIC(OPERCMDS) REFRESH
El supervisor de trabajos JES no proporciona a los usuarios de Developer para System z acceso pleno al spool JES. Los únicos mandatos disponibles son los que figuran en: Tabla 6. 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 está limitado adicionalmente por las técnicas descritas a continuación.
Mandato | JES2 | JES3 |
---|---|---|
Retener | $Hjobid | *F,J=jobid,H |
Liberar | $Ajobid | *F,J=jobid,R |
Cancelar | $Cjobid | *F,J=jobid,C |
Purgar | $Cjobid,P | *F,J=jobid,C |
Aunque no posean autorización sobre estos mandatos de la consola, los usuarios todavía pueden someter trabajos y leer datos de salida de los trabajos, si se les otorga autorización de acceso a los archivos de spool.
Para limitar a los usuarios de forma que solo utilicen sus propios trabajos en el spool JES, defina la sentencia "LIMIT_VIEW=USERID" en el archivo de configuración del supervisor de trabajos JES (FEJJCNFG). Si 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, en RACF.
Al definir protección adicional, tenga presente que el supervisor de trabajos JES utiliza la 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 o navegación. Este requisito no es necesario si se ejecuta z/OS v1.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 o navegación.
En el manual Security Server RACF Security Administrator's Guide (SA22-7683) hallará más información sobre la protección de archivos de spool JES.
Developer para 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 que las instalaciones apliquen estándares propios. Ello también garantizará que los desarrolladores utilicen los mismos procedimientos con las mismas opciones de compilador y los mismos niveles de compilador.
SMP/E instala los procedimientos JCL de ejemplo en hlq.SFEKSAMP. Si piensa utilizar estos procedimientos, debe:
Los procedimientos de ejemplo que hay que copiar y personalizar figuran 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 ejemplo para hacer preproceso DB2 de sentencias SQL EXEC embebidas en programas COBOL. |
ELAXFCOT | Procedimiento de ejemplo para hacer conversión CICS de sentencias CICS EXEC embebidas en programas COBOL. |
ELAXFCPC | Procedimiento de ejemplo para hacer compilaciones C. |
ELAXFCPP | Procedimiento de ejemplo para hacer compilaciones C++. |
ELAXFGO | Procedimiento de ejemplo para el paso GO. |
ELAXFLNK | Procedimiento de ejemplo para enlazar programas C/C++, COBOL, PLI y del ensamblador de alto nivel (HLASM). |
ELAXFMFS | Procedimiento de ejemplo para crear pantallas MFS IMS. |
ELAXFPLP | Procedimiento de ejemplo para hacer preproceso DB2 de sentencias SQL EXEC embebidas 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. |
ELAXFUOP | Procedimiento de ejemplo para generar el paso UOPT al construir programas que se ejecutan en subsistemas CICS o IMS. |
Tabla 8 contiene una lista de comprobación para los distintos calificadores de producto de alto nivel empleados en los procedimientos ELAXF*.
Producto | HLQ predeterminado | Valor |
---|---|---|
RD/z | FEK | |
CICS | CICSTS31.CICS | |
DB2 | DSN810 | |
IMS | IMS | |
COBOL | IGY.V3R4M0 | |
PL/I | IBMZ.V3R6M0 | |
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, cópielos en una biblioteca privada y pida a los usuarios de Developer para System z que añadan una tarjeta JCLLIB (justo después de la tarjeta JOB) a las propiedades del trabajo en el cliente. No personalice el JCL de ejemplo en el conjunto de datos de instalación, porque el mantenimiento podría sustituir estos miembros y deshacer las personalizaciones que haya hecho.
//MYJOB JOB <parámetros del trabajo> //PROCS JCLLIB ORDER=(hlq.SFEKSAMP)
Los nombres de los procedimientos y los nombres de los pasos de cada procedimiento coinciden con las propiedades predeterminadas que vienen con el cliente. Si decide cambiar el nombre del procedimiento o el nombre de un paso del procedimiento, también hay que actualizar el correspondiente archivo de propiedades en el cliente. Le recomendamos que no cambie el nombre de los procedimientos ni de los pasos.
En la versión 7.1, la tarea de definir la transacción APPC ha pasado a ser opcional. Por defecto, ahora el producto Developer para System z utiliza SCLM Developer Toolkit para proporcionar el servicio de mandatos TSO. La correspondiente configuración se realiza en rsed.envvars, que se describe en: Personalizar rsed.envvars, el archivo de configuración de RSE.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
El servicio de mandatos TSO se implementa como un programa de transacción APPC, FEKFRSRV, y debe estar activo para que las conexiones de Developer para System z se establezcan entre el host y el cliente. FEKFRSRV funciona a modo de servidor de hospedaje para ejecutar los mandatos TSO que se emiten desde la estación de trabajo por TCP/IP. No se necesita APPC en la estación de trabajo, porque esta se comunica con FEKFRSRV por TCP/IP. Cada estación de trabajo 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 para System z tiene acceso a un segmento OMVS
(es necesario)
|
|
RACF | Cada usuario de Developer para System z debe tener acceso de lectura (READ) a hlq.SFEKPROC(FEKFRSRV)
|
En el manual MVS Planning Workload Management (SA22-7602) hallará más información sobre 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 sobre los segmentos OMVS y los perfiles de protección de conjuntos de datos.
El programador del sistema o el administrador de APPC debe llevar a cabo los siguientes pasos para configurar el servicio de mandatos:
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
Se necesita la siguiente personalización para incorporar el procedimiento almacenado DB2 de ejemplo (constructor de procedimientos almacenados PL/I y COBOL) en su sistema. Para realizar estas tareas, necesitará ayuda de un administrador de WLM y un administrador de DB2.
Después de la aplicación de SMP/E, la biblioteca de ejemplos hlq.SFEKSAMP y la biblioteca de procedimientos hlq.SFEKPROC contienen los miembros de procedimientos almacenados DB2 que figuran en: Tabla 10.
Miembro | Finalidad |
---|---|
hlq.SFEKSAMP(ELAXMJCL) | JCL de ejemplo para definir el constructor de procedimientos almacenados PL/I y COBOL ante DB2. |
hlq.SFEKSAMP(ELAXMSAM) | Procedimiento JCL de ejemplo del espacio de direcciones WLM para el constructor de procedimientos almacenados PL/I y COBOL. |
hlq.SFEKPROC(ELAXMREX) | Código REXX para el constructor de procedimientos almacenados PL/I y COBOL. |
El componente Herramientas de servicio de empresa (EST) de Developer para 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:
Necesitará ayuda del administrador de CICS para realizar las siguientes tareas:
Las transformaciones bidireccionales de EST las realiza el módulo FEJBDTRX en el entorno de tiempo de ejecución de flujo de servicios (SFR) CICS. Se llama al módulo FEJBDTRX cuando hay que hacer conversiones bidireccionales en el código generado por EST (cuando se generan correlaciones entre campos de mensajes que tienen atributos bidireccionales distintos).
Si autoinstall tiene el valor autoINactive, defina el programa FEJBDTRX en CICS utilizando el mandato CEDA; por ejemplo:
CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Además, el código generado por EST puede soportar la transformación bidi en entornos distintos de SFR de CICS (por ejemplo, en 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, hlq.SFEKLOAD.
El gestor de despliegue de aplicaciones (ADM) proporciona un enfoque de despliegue común y una API de despliegue para todos los componentes de Developer para System z.
Además, el ADM proporciona un cliente y un servidor (basado en el host) de definición de recursos CICS (CRD), que aporta las siguientes funciones:
Developer para System z suministra tres transacciones que el servidor CRD utiliza al definir y consultar recursos CICS. Se proporciona código fuente COBOL para permitir personalizaciones específicas del local.
En el manual Rational Developer para System z Application Deployment Manager User's Guide (SC23-7661) encontrará más información sobre ADM.
Para activar el servidor CRD, hay que realizar los siguientes pasos de personalización.
Antes de instalar la versión 7.1.1, si es usted un usuario anterior del servidor CRD, le recomendamos que guarde la personalización relacionada, como se describe en: Hacer copia de seguridad de archivos configurados con anterioridad.
Copie los miembros que hay que personalizar del directorio de instalación en una biblioteca personal y personalice esas copias, para evitar que se sobrescriban al aplicar el mantenimiento:
opcional (manejador de mensajes de conducto)
opcional (actualización de CSD para regiones no primarias)
Personalice y someta el trabajo ADNVSAM para asignar e inicializar el archivo VSAM del repositorio del servidor CRD. Las instrucciones de personalización están en la documentación de ADNVSAM.
Le aconsejamos que cree 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, y que múltiples espacios de direcciones se escribirán en el VSAM, que se debe configurar correctamente para poder manejarlos.
El servidor CRD debe estar definido en la región de conexión primaria. Es la región que procesará las peticiones de servicios Web procedentes de Developer para System z.
CEDA INSTALL GROUP(ADNPCRGP)
El manejador de mensajes de conducto (ADNSMSGH) se utiliza para la seguridad, procesando el ID de usuario y la contraseña en la cabecera SOAP. El archivo de configuración del conducto hace referencia al ADNSMSGH, que, por lo tanto, se debe colocar en la concatenación RPL de CICS. El ADNSMSGH también se utiliza para establecer que el ID de transacción sea igual a ADMD, ADMR o ADMI, en función de la operación solicitada. Es posible que le interese personalizar el ADNSMSGH para que utilice distintos ID de transacción.
Utilizando el valor predeterminado:
Personalizando el ADNSMSGH:
El servidor CRD también se puede usar con una o más regiones de conexión no primarias, que suelen ser regiones propietarias de aplicación (AOR).
CEDA INSTALL GROUP(ADNARRGP)
Antes de instalar la versión 7.1.1, si es usted un usuario anterior de Developer para System z, le recomendamos que guarde la personalización relacionada descrita en: Hacer copia de seguridad de archivos configurados con anterioridad.
Si no está familiarizado con z/OS UNIX, le aconsejamos que pida ayuda a un administrador de z/OS UNIX con experiencia o a otro administrador de UNIX para realizar las tareas que figuran en este capítulo.
Los mandatos de z/OS UNIX necesarios para realizar las tareas enumeradas se describen de manera resumida para su comodidad. A menos que se le indique lo contrario, consulte el manual UNIX System Services Command Reference (SA22-7802) para obtener más información sobre estos mandatos.
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.
MVS proporciona la posibilidad de editar archivos de z/OS UNIX utilizando ISPF mediante el mandato OEDIT. Este mandato se puede usar en TSO y también en OMVS.
La mayoría de los archivos de z/OS UNIX tienen el permiso de escritura restringido al propietario del archivo. Esta restricción se puede eludir de muchas maneras.
Esta configuración no está recomendada para los ID de usuario "human", 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.
Permite que el usuario lea/escriba cualquier archivo, y también que lea o busque en cualquier directorio. El acceso de CONTROL (o superior) a este perfil de seguridad añade el permiso de escritura en cualquier directorio a la lista de permisos.
Consulte el manual UNIX System Services Planning (GA22-7800) para obtener más información sobre la seguridad en z/OS UNIX.
En este capítulo, todas las sentencias que incluyen la vía de acceso /usr/lpp/wd4z/ hacen referencia a la vía de acceso que se utilizó durante la instalación de Developer para System z. El valor predeterminado es /usr/lpp/wd4z/, pero quizá no sea válido para su local.
Puede probar la configuración de TCP/IP con el mandato TSO HOMETEST. En el manual Communications Server IP System Administrator's Commands (SC31-8781) hallará más información sobre este mandato.
Las publicaciones que le pueden ayudar a comprender z/OS UNIX son las siguientes:
Le recomendamos que copie el archivo /usr/lpp/wd4z/rse/lib/rsed.envvars en un nuevo directorio (como /etc/wd4z/) y que personalice la copia para evitar que se sobrescriba al aplicar el mantenimiento. Sin embargo, si lo hace así, debe copiar asimismo los siguientes archivos del directorio de instalación (el valor predeterminado es /usr/lpp/wd4z/rse/lib/) en la nueva ubicación:
También tendrá que copiar los archivos enumerados en: Tabla 11, si piensa utilizar las características opcionales que forman parte de ellos:
archivo | función |
---|---|
projectcfg.properties | Proyectos basados en host
Vea: (Opcional) Personalizar la configuración de proyectos de host, projectcfg.properties |
FMIEXT.properties | Integración del gestor de archivos
Vea: (Opcional) Personalizar la integración del gestor de archivos, FMIEXT.properties |
CRASRV.properties | CARMA
Vea: (Opcional) Activar el gestor de repositorios de acceso común (CARMA) de IBM |
Los siguientes mandatos de ejemplo,
crean un directorio llamado /etc/rd4z y copian rsed.envvars del directorio actual en /etc/rd4z. Repita el mandato de copiar para los archivos restantes.
El resultado de la copia se puede verificar con el mandato ls /etc/wd4z, cuya salida debe ser parecida a esta ($ es el indicador de z/OS UNIX):
$ ls /etc/wd4z /etc/wd4z rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries
1. mkdir /usr/lpp/wd4z/rse/lib/cust 2. ln -s /usr/lpp/wd4z/rse/lib/cust /etc/wd4z
Todos los métodos de conexión de cliente de Developer para System z utilizan las variables establecidas en el archivo rsed.envvars, situado por defecto en el directorio de instalación, /usr/lpp/wd4z/rse/lib/, pero se podrían copiar en otro directorio en el paso anterior. El archivo de ejemplo proporcionado tiene las sentencias enumeradas en: Figura 4, donde las líneas de comentarios empiezan por un signo de almohadilla (#).
#============================================================= # (1) personalizaciones necesarias JAVA_HOME=/usr/lpp/java/J1.4 RSE_HOME=/usr/lpp/wd4z TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin:. _RSE_CLASS_OPTS="" _RSE_JAVAOPTS="" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) personalizaciones necesarias si se utiliza SCLMDT _CMDSERV_BASE_HOME=/usr/lpp/SCLMDT _CMDSERV_BASE_LOAD=BWB.SBWBLOAD _CMDSERV_CONF_HOME=/etc/SCLMDT _CMDSERV_WORK_HOME=/var/SCLMDT STEPLIB=NONE #STEPLIB=$_CMDSERV_BASE_LOAD _RSE_CMDSERV_OPTS="" #============================================================= # (3) personalizaciones opcionales #_RSE_PORTRANGE=8108-8118 #_FEKFLOCK_USERID_=id_usuario #_FEKFLOCK_JOBNAME_=nombre_trabajo #_FEKFSCMD_TP_NAME_=nombre_tp #_FEKFSCMD_PARTNER_LU_=nombre_lu #============================================================= # (4) no lo cambie a menos que así se lo indique el centro de soporte de IBM RSE_LIB=$RSE_HOME/rse/lib ICU_LIB=$RSE_HOME/icuc/lib _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CEE_DMPTARG=$HOME/.eclipse/RSE/$RSE_USER_ID _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES PATH=$JAVA_HOME/bin:$RSE_LIB:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$ICU_LIB:$RSE_LIB:. CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.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-1.4.3.jar:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSCLMDT_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 -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS" _RSE_SERVER_CLASS=com.ibm.etools.systems.dstore.core.server.Server _RSE_SERVER_TIMEOUT=120000 #============================================================= # (5) Variables de entorno adicionales
Las definiciones que se necesitan son las siguientes:
Developer para System z utiliza SCLM Developer Toolkit por defecto para el servicio de mandatos TSO. Se utiliza APPC cuando la siguiente opción _RSE_JAVAOPTS no está comentada:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
A continuación se indican las definiciones que se necesitan si se utiliza SCLM Developer Toolkit, ya sea para el servicio de mandatos TSO o al instalar el plug-in SCLMDT en el cliente Developer para System z.
Por defecto, Developer para System z utiliza la LINKLIST para acceder a la biblioteca de carga de SCLM Developer Toolkit. Se utiliza STEPLIB cuando la siguiente directiva STEPLIB no está comentada:
STEPLIB=$_CMDSERV_BASE_LOAD
Las definiciones que figuran a continuación son opcionales. Si se omiten, se emplearán los valores predeterminados.
Las siguientes definiciones son necesarias y no se deben cambiar, a menos que así lo indique el centro de soporte de IBM.
STEPLIB=CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
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 los puertos REXEC/SSH o 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 cambie la siguiente línea del archivo rsed.envvars:
#_RSE_PORTRANGE=8108-8118
El formato de PORTRANGE es: _RSE_PORTRANGE=min-max (el máximo 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 el servidor RSE.
Las opciones de ejemplo incluidas en el archivo rsed.envvars se pueden activar a base de quitarles el carácter de comentario.
Developer para System z se basa en el servicio INETD para iniciar el servidor del Explorador de Sistemas Remotos cuando un cliente solicita una conexión. INETD es un daemon estándar de z/OS UNIX que gestiona otros daemons que realizan el trabajo real (en este caso, iniciar el servidor RSE). La configuración de INETD no forma parte de la personalización de Developer para System z, pero podrá hallar información valiosa en: Apéndice D. Configurar INETD.
Developer para System z permite utilizar múltiples maneras de iniciar el servidor RSE.
Tendrá que personalizar como mínimo una manera, en función de cómo vayan a operar sus usuarios.
Puede verificar que INETD está activo con el mandato ps -e (proporcionado por un usuario autorizado). La salida debe contener una referencia a INETD; por ejemplo (# es el indicador de z/OS UNIX):
# ps -e PID TTY TIME CMD 7 ? 0:00 /usr/sbin/inetd
rse 4035/tcp #Developer para System z RSE
El puerto utilizado debe coincidir con el definido en el cliente, que se establece durante la creación de una nueva conexión z/OS.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /usr/lpp/wd4z/rse/lib -t 60
Todo lo que hay después del argumento INETD son argumentos de servidor, empezando por el nombre del servidor.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z
Las definiciones que figuran a continuación son opcionales. Si se omiten, se emplearán los valores predeterminados.
a. # ps -e | grep inetd 50331687 ? 0:00 /usr/sbin/inetd b. # kill 50331687 c. # _BPX_JOBNAME='INETD' /usr/sbin/inetd d. # netstat | grep 4035 INETD4 00000B6A 0.0.0.0..4035 0.0.0.0..0 Escucha
ICH408I USER(IBMUSER ) GROUP(SYS1 ) NAME(IBMUSER ) BPX.DAEMON CL(FACILITY) INSUFFICIENT ACCESS AUTHORITY ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
No hay ninguna configuración específica de Developer para System z para utilizar el servidor de mandatos REXEC (o SSH) de INETD. Sin embargo, el cliente debe conocer 2 valores para poder iniciar una conexión RSE a través de REXEC/SSH:
Por defecto, es el directorio de instalación (/usr/lpp/wd4z/rse/lib/). Sin embargo, server.zseries es uno de los archivos que también se deben copiar si rsed.envvars se copia en un directorio distinto, como /etc/wd4z/.
Un puerto común utilizado por REXEC es el 512. Una manera rápida de comprobarlo es con el mandato NETSTAT, como se ve en el siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ netstat | grep 512 INETD4 0000002E 0.0.0.0..512 0.0.0.0..0 Escucha
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. El puerto común es el 22, y el nombre de servicio es sshd.
Este paso solo es necesario cuando se utiliza SCLM Developer Toolkit para el servicio de mandatos TSO (este es el valor predeterminado). No se necesita al utilizar APPC para el servicio de mandatos TSO.
Para SCLM Developer Toolkit se necesitan las definiciones de ISPF.conf para crear un entorno válido que ejecute los servicios ISPF. El servicio de mandatos TSO se tiene que añadir a este entorno ISPF.
ISPF.conf se crea durante la personalización de SCLM Developer Toolkit, descrita en el manual SCLM Developer Toolkit Installation and Customization Guide (SC23-8504). La ubicación predeterminada es /etc/SCLMDT/CONFIG, pero quizá no sea válida para su local.
Añada las siguientes líneas a ISPF.conf, siendo hlq el calificador de alto nivel empleado para instalar Developer para System z (el valor predeterminado es FEK).
********************************************** * Developer para System z - Servidor de mandatos TSO ********************************************** sysexec=hlq.SFEKPROC
El resultado debe tener un aspecto igual al del ejemplo de la Figura 5.
sysproc=ISP.SISPCLIB ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=BWB.SBWBLOAD ********************************************** * Developer para System z - Servidor de mandatos TSO ********************************************** sysexec=FEK.SFEKPROC
La instalación de Developer para System z proporciona varios programas de verificación de instalación (IVP) para el servidor RSE. Los scripts de los IVP se encuentran en el directorio de instalación, que es /usr/lpp/wd4z/rse/lib/ por defecto.
Para todos los mandatos de ejemplo de este apartado se espera que las variables de entorno de RSE estén establecidas. De esta manera, los scripts del IVP están disponibles mediante la sentencia PATH, y se conoce la ubicación de rsed.envvars. Utilice los mandatos pwd y cd para verificar y cambiar el directorio actual para pasar al directorio que tiene el archivo rsed.envvars personalizado. Luego se puede usar el script de shell setup.env.zseries para establecer las variables de entorno de RSE, como en el ejemplo que sigue ($ es el indicador de z/OS UNIX):
$ pwd /etc $ cd /etc/wd4z $ . ./setup.env.zseries
El script de shell . ./setup.env.zseries, que reside en el mismo directorio que rsed.envvars, exporta las variables de entorno para que otros procesos puedan utilizarlas. El primer punto "." de . ./setup.env.zseries 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/wd4z/rse/lib/fekfivpr 512 USERIDAsimismo, la mayoría de los scripts fekfivp* pedirán la ubicación del archivo rsed.envvars personalizado si no se ejecuta . ./setup.env.zseries en primer lugar.
$ echo $STEPLIB none $ STEPLIB=TCPIP.SEZALOAD
o bien
$ echo $STEPLIB SOME.STEPLIB.DATASET $ STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Para obtener información sobre cómo diagnosticar los problemas de conexión del RSE, vea: Apéndice B. Resolución de problemas de configuración, o consulte las fichas técnicas de la página de soporte de Developer para System z, http://www-306.ibm.com/software/awdtools/devzseries/support/.
La disponibilidad de los puertos del supervisor de trabajos JES, de REXEC y SSH y del daemon RSE 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 V1R7 Nombre de TCPIP: TCPIP 13:57:36 ID us. Conexión Socket Local Socket Foráneo Estado ------- ---- ------------ -------------- ----- INETD4 00000014 0.0.0.0..22 0.0.0.0..0 Escucha INETD4 00000030 0.0.0.0..512 0.0.0.0..0 Escucha INETD4 0000004B 0.0.0.0..4035 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 V1R7 Nombre de TCPIP: TCPIP 14:03:35 ID usuario Conexión Estado ---------- -------- ----- INETD4 00000018 Escucha Socket local: 0.0.0.0..22 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 INETD4 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
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: $ EZYRC01I Llamando a la función rexec_af con: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/wd4z;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Socket de datos = 4, Socket de control = 6. se esperan mensajes de tiempo de espera tras una prueba de IVP satisfactoria 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 El servidor se ha iniciado satisfactoriamente 1272 El servidor se ejecuta en: CDFMVS08
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server.ConnectionEstablisher. ...
Es posible saltarse esta prueba de IVP si la prueba anterior (descrita someramente en: Conexión REXEC) se llevó a cabo satisfactoriamente.
Verifique el script de shell utilizado por la conexión REXEC y SSH, ejecutando el mandato:
fekfivps
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):
$ fekfivps $ java version "1.5.0" se esperan mensajes de tiempo de espera tras una prueba de IVP satisfactoria 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 El servidor se ha iniciado satisfactoriamente 1751 El servidor se ejecuta en: CDFMVS08$
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server.ConnectionEstablisher. ...
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 parecidos a los de este ejemplo ($ es el indicador de z/OS UNIX):
$ fekfivpd 4035 USERID 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 En espera de una respuesta del supervisor de trabajos JES... ACKNOWLEDGE01v03 Éxito
Esta prueba de IVP solo se necesita si utiliza SCLM Developer Toolkit, ya sea para el servicio de mandatos TSO o para el plug-in de cliente.
Verifique la conexión establecida con el servidor de mandatos TSO utilizando SCLM Developer Toolkit, emitiendo el mandato:
fekfivpc
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):
$ fekfivpc ------------------------------------------------------------- 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/wd4z/rse/lib:/usr/lpp/SCLM DT/bin:/bin:/usr/sbin:. STEPLIB = BWB.SBWBLOAD _CMDSERV_BASE_HOME = /usr/lpp/SCLMDT _CMDSERV_CONF_HOME = /etc/SCLMDT _CMDSERV_WORK_HOME = /var/SCLMDT ------------------------------------------------------------- *** COMPROBACIÓN : MÓDULOS HFS Comprobando directorio de instalación : /usr/lpp/SCLMDT Comprobando módulos BWB en directorio /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 -------------------------------------------------------------
fekfivpc tiene varios parámetros opcionales que no dependen de la posición:
No ejecute este procedimiento si no ha instalado APPC para el servicio de mandatos TSO.
Verifique la conexión establecida con el servidor de mandatos TSO (utilizando APPC), emitiendo el siguiente mandato. Donde pone USERID, escriba 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: 20070607 13:57:18.584060 /usr/lpp/wd4z/rse/lib/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.585132 TP_name set via envvar: FEKFRSRV 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
Para obtener información sobre cómo diagnosticar los problemas de conexión del RSE, vea: Apéndice B. Resolución de problemas de configuración, o consulte las fichas técnicas de la página de soporte de Developer para System z, http://www-306.ibm.com/software/awdtools/devzseries/support/.
Todos los métodos de conexión de cliente de Developer para System z utilizan las variables de capa de sockets segura (SSL) establecidas en el archivo ssl.properties, situado por defecto en el directorio de instalación, /usr/lpp/wd4z/rse/lib/. Sin embargo, ssl.properties es uno de los archivos que también se deben copiar si rsed.envvars se copia en un directorio distinto, como /etc/wd4z/. El archivo de ejemplo proporcionado tiene las sentencias enumeradas en: Figura 6, donde las líneas de comentarios empiezan por un signo de almohadilla (#).
# Especifique esta propiedad como true para habilitar SSL enable_ssl=false ################################### # Propiedades del daemon # Hay que especificar el archivo de base de datos de claves y la contraseña para # el daemon. # Hay que especificar la etiqueta de clave si no es la clave predeterminada. #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= ################################### # Propiedades del servidor # Hay que especificar el archivo de almacén de claves y la contraseña para # el servidor. #server_keystore_file= #server_keystore_password=
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 E. Configurar SSL.
Todos los métodos de conexión de cliente de Developer para System z utilizan las variables establecidas en el archivo rsecomm.properties, situado por defecto en el directorio de instalación, /usr/lpp/wd4z/rse/lib/. Sin embargo, rsecomm.properties es uno de los archivos que también se deben copiar si rsed.envvars se copia en un directorio distinto, como /etc/wd4z/. El archivo de ejemplo proporcionado tiene las sentencias enumeradas en: Figura 7, donde las líneas de comentarios empiezan por un signo de almohadilla (#).
# 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 # 3 - Mensajes de depuración, 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
Al seleccionar log_location=Log_To_File (que es el valor predeterminado), las anotaciones se escriben en home/.eclipse/RSE/USERID/rsecomm.log, donde home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
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 el archivo projectcfg.properties, situado por defecto en el directorio de instalación, /usr/lpp/wd4z/rse/lib/. Sin embargo, projectcfg.properties es uno de los archivos que también se deben copiar si el archivo rsed.envvars se copia en un directorio distinto, como /etc/wd4z/.
El archivo de ejemplo proporcionado tiene las sentencias enumeradas en: Figura 8, donde las líneas de comentarios empiezan por un signo de almohadilla (#).
# # 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/wd4z/projects
La única variable que hay que cambiar es PROJECT-HOME. Su valor, que por defecto es /var/wd4z/projects, es el directorio base de las definiciones de proyecto.
Para obtener más información sobre los proyectos basados en host, lea el libro blanco Host Based Projects in WebSphere Developer para System z version 7.0, en la biblioteca de Developer para System z en Internet, http://www-306.ibm.com/software/awdtools/devzseries/library/.
Developer para 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 las conocidas utilidades para examinar, editar, copiar e imprimir existentes en ISPF y mejoradas para responder a las necesidades de los desarrolladores de aplicaciones. En la versión actual de Developer para System z, solo está permitido examinar/editar conjuntos de datos MVS (incluidos los KSDS y ESDS de VSAM).
Tenga en cuenta que el producto IBM File Manager para z/OS se debe pedir, instalar y configurar por separado. Consulte el manual Rational Developer para System z Guía de planificación de host, GI11-7839-00 (GI11-8296-00) para saber qué nivel del gestor de archivos se necesita para su versión de Developer para System z. La instalación y la personalización de este producto no se describe en este manual.
Las definiciones del gestor de archivos que se necesitan para Developer para System z están almacenadas en el archivo FMIEXT.properties, situado por defecto en el directorio de instalación, /usr/lpp/wd4z/rse/lib/. Sin embargo, FMIEXT.properties es uno de los archivos que también se deben copiar si rsed.envvars se copia en un directorio distinto, como /etc/wd4z/.
El archivo de ejemplo proporcionado tiene las sentencias enumeradas en: Figura 9, donde las líneas de comentarios empiezan por un signo de almohadilla (#).
# Propiedades de la extensión Integración del gestor de archivos (FMI) # startup.script=/usr/lpp/wd4z/rse/lib/fmiSub startup.port=1957 startup.range=100 startup.fmload=FMN.SFMNMOD1 startup.jobcard1=//JOBCARD JOB <parámetros del trabajo> startup.jobcard2=//* startup.jobcard3=//* startup.sysout=*
El gestor de repositorios de acceso común (CARMA, FMID: HCMA710) es una ayuda de productividad para los desarrolladores que se proponen crear interfaces API para los gestores de configuración de software (SCM). A su vez, las aplicaciones (por ejemplo, Developer para System z) pueden utilizar estas API para acceder a los SCM.
Antes de instalar la versión 7.1.1, si es usted un usuario anterior de CARMA, le recomendamos que guarde la personalización relacionada, como se describe en: Hacer copia de seguridad de archivos configurados con anterioridad.
Después de la instalación, debe configurar CARMA siguiendo estos pasos:
En la Tabla 2 encontrará una lista de los manuales que proporcionan más información sobre CARMA y su utilización.
El usuario puede controlar la cantidad de información de rastreo generada por CARMA, estableciendo el Nivel de rastreo en la pestaña Propiedades de la conexión CARMA en el cliente. Las opciones de nivel de rastreo son:
El valor predeterminado es
Anotaciones de error
Para obtener más información sobre la ubicación de los archivos de anotaciones, consulte: Ubicación de los archivos de anotaciones.
En este apartado, todas las referencias a hlq se refieren al calificador de alto nivel empleado durante la instalación de CARMA. El valor predeterminado de la instalación es CRA, pero quizá no sea válido para su local.
Para configurar el host MVS, siga estos pasos:
Si no está familiarizado con z/OS UNIX, conviene que pida ayuda a un administrador de z/OS UNIX con experiencia o a otro administrador de UNIX para realizar las tareas que figuran en este apartado.
Los mandatos de z/OS UNIX necesarios para realizar las tareas enumeradas se describen de manera resumida para su comodidad. A menos que se le indique lo contrario, consulte el manual UNIX System Services Command Reference (SA22-7802) para obtener más información sobre estos mandatos.
En esta sección, todas las sentencias que incluyen la vía de acceso /usr/lpp/wd4z/ hacen referencia a la vía de acceso que se utilizó durante la instalación de Developer para System z, no de CARMA. El valor predeterminado es /usr/lpp/wd4z/, pero quizá no sea válido para su local.
Para configurar los componentes z/OS UNIX de CARMA, que se instalan durante el proceso de instalación de IBM Rational Developer para System z (FMID: HHOP710), siga estos pasos:
cp /usr/lpp/wd4z/rse/lib/CRASRV.properties /etc/wd4z
# Opción de configuración de CARMA # port.start=5227 port.range=100 startup.script.name=/usr/lpp/wd4z/rse/lib/rexxsub clist.dsname='hlq.SCRACLST(CRASUBMT)'
Los gestores de acceso a repositorios (RAM) son API escritas por el usuario para intercambiar información con los gestores de configuraciones de software (SCM) de z/OS. Siga las instrucciones de los apartados que figuran más abajo para los RAM de ejemplo que desea activar.
Para obtener más información sobre los RAM de ejemplo y el código fuente de ejemplo proporcionados, consulte el manual Rational Developer para System z Common Access Repository Manager Developer's Guide (SC23-7660).
IBM Software Configuration and Library Manager (SCLM) Developer Toolkit (FMID: HSD3310) proporciona las herramientas necesarias para ampliar las prestaciones de SCLM para el cliente. El propio SCLM es un gestor de código fuente basado en host que viene como parte de ISPF.
El SCLM Developer Toolkit, que viene junto con el producto Developer para System z, es un plug-in basado en Eclipse 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 SCLM en el sistema central, incluidas las tareas de construir, ensamblar y desplegar el código J2EE desde el sistema central.
En la Tabla 2 encontrará una lista de los manuales que proporcionan más información sobre SCLM Developers Toolkit y su instalación, personalización y utilización.
Los usuarios del cliente Developer para 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 la lista de comprobación de la Tabla 12 para reunir la información que necesite.
Personalización | Valor |
---|---|
Número de puerto del servidor del supervisor de
trabajos JES (el valor predeterminado es 6715 ):
Vea SERV_PORT en: Personalizar el archivo de configuración del supervisor de trabajos JES, FEJJCNFG . |
|
Ubicación de los procedimientos
ELAXF* si no están en la biblioteca de procedimientos del
sistema:
Vea la nota de JCLLIB en: Personalizar procedimientos de construcción remota ELAXF*. |
|
Nombres de procedimiento y/o paso de los procedimientos ELAXF*,
si se han cambiado
Vea la nota que indica cómo cambiarlos, en: Personalizar 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: Apéndice A. Ejecutar múltiples instancias de Developer para System z. |
|
Ubicación del procedimiento almacenado DB2 si no está en una biblioteca de procedimientos del sistema:
Vea: (Opcional) Personalizar miembros de procedimientos almacenados DB2 ELAXM*. |
|
Utilizar el método de conexión DAEMON, REXEC o SSH para RSE: | |
Número de puerto TCP/IP del daemon RSE (el valor predeterminado es 4035): | |
Vía de acceso al script de shell server.zseries para REXEC/SSH (el valor predeterminado es /usr/lpp/wd4z/rse/lib, el valor aconsejado es /etc/wd4z): | |
Número de puerto de REXEC o SSH (el valor predeterminado es 512
ó 22, respectivamente):
Vea: Configuración de REXEC (o SSH) de INETD. Nota:
Para las acciones remotas (basadas en host) de los subproyectos z/OS UNIX, es necesario que REXEC o
SSH esté activo en el host. |
|
Ubicación del JCL de CRA#ASLM para
las asignaciones de conjuntos de datos RAM de SCLM de CARMA:
Vea la nota de CRA#ASLM, en: Activar el RAM de SCLM. |
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 para System z.
En los manuales MVS Initialization and Tuning Guide (SA22-7591) y UNIX System Services Planning (GA22-7800) hallará más información sobre cómo ajustar el sistema.
zFS (sistema de archivos de zSeries) y HFS (sistema de archivos jerárquico) son sistemas de archivos UNIX que se pueden usar en un entorno UNIX de z/OS. Sin embargo, zFS proporciona las siguientes ventajas y características:
En el manual UNIX System Services Planning (GA22-7800) encontrará más información sobre 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 área de almacenamiento común ampliada (ECSA). 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(). El servidor RSE inicia varios procesos, y cada conexión de cliente tiene un servidor RSE privado. Esto puede hacer que las cifras aumenten con rapidez.
Developer para System z tiene el valor predeterminado STEPLIB=NONE codificado en rsed.envvars, como se describe en: Personalizar rsed.envvars, el archivo de configuración de RSE. 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).
Si no utiliza la directiva STEPLIB, debe verificar el contenido de rsed.envvars para ver si la sentencia STEPLIB es la primera o no.
STEPLIB=first.steplib.dataset:second.steplib.dataset
STEPLIB=$STEPLIB:first.steplib.dataset:second.steplib.dataset
Algunas bibliotecas del sistema y algunos módulos de carga se utilizan muy a menudo 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.
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. Conviene 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 poner estas bibliotecas en LINKLIST, debe configurar la sentencia STEPLIB pertinente en rsed.envvars, como se describe en: Personalizar rsed.envvars, el archivo de configuración de RSE. 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 primaria es el desarrollo de aplicaciones, el rendimiento también podrá mejorar si pone el editor de enlazamiento en la LPA dinámica, añadiendo estas líneas 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. En el manual Language Environment Customization (SA22-7564) hallará información sobre cómo poner otros módulos de carga de LE en la LPA dinámica. Consulte el manual UNIX System Services Planning (GA22-7800) para obtener más información sobre cómo poner 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. En el manual UNIX System Services Planning (GA22-7800) hallará más información sobre este perfil.
La máquina virtual Java (JVM) de IBM, versión 5 o superior, le permite compartir clases de rutina de carga y de aplicación entre las JVM, almacenándolas en una 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á.
En el manual Java SDK and Runtime Environment User Guide obtendrá más información sobre clases compartidas.
Para habilitar la prestación de compartir clases en el servidor RSE, descomente la siguiente directiva en rsed.envvars, como se describe en: (Opcional) Definir parámetros de arranque Java adicionales con _RSE_*OPTS. 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).
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
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 caché de clases compartidas y la memoria dinámica Java, si se aumenta el tamaño máximo de la memoria dinámica Java, disminuye el tamaño de la caché de clases compartidas que se 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).
En el manual Java SDK and Runtime Environment User Guide obtendrá más información sobre las opciones de seguridad adicionales al utilizar un gestor de seguridad 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 sobre cómo se utilizan estos parámetros y sobre cómo afectan al rendimiento, consulte los manuales MVS Initialization and Tuning Reference (SA22-7592) y UNIX System Services Planning (GA22-7800). Los parámetros BPXPRMxx más significativos que afectan al funcionamiento de las clases compartidas son:
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 lo tanto, establezca que IPCSHMMPAGES sea mayor que 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). En el manual Java SDK and Runtime Environment User Guide encontrará 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).
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. En el manual Java Diagnostics Guide (SC34-6650) hallará más información sobre los tamaños de la memoria dinámica y sobre la recogida de basura.
Por defecto, el tamaño de la memoria dinámica inicial de una máquina virtual Java (JVM) en z/OS 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 para 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: (Opcional) Definir parámetros de arranque Java adicionales con _RSE_*OPTS.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
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 para System z se puede equilibrar estableciendo los objetivos correctos para sus procesos. A continuación figuran algunas directrices generales.
Consulte el manual MVS Planning Workload Management (SA22-7602) para obtener más información al respecto.
En algunas ocasiones le interesará tener múltiples instancias de Developer para 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 para System z, y después podrá usar esta guía de configuración para personalizarlas.
Aunque es posible compartir algunas partes de Developer para System z entre 2 (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 para System z deja suficiente margen de personalización para crear múltiples instancias que no se solapen, y le aconsejamos encarecidamente que utilice estas características.
En un conjunto de circunstancias limitado, puede compartir todo salvo (algunos de) los componentes personalizables. Por ejemplo, proporcionar acceso no SSL para la utilización en el local y comunicación codificada por SSL para la utilización fuera del local.
Para configurar otra instancia de una instalación activa de Developer para System z, rehaga los pasos de personalización para los componentes que sean distintos, utilizando diferentes conjuntos de datos/directorios/puertos para evitar que se solape con la instalación actual.
En el ejemplo SSL mencionado más arriba, las personalizaciones del servidor RSE actual se pueden clonar y, después, el archivo ssl.properties clonado se puede actualizar. 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:
Cuando hay cambios de código implicados (de mantenimiento, avances tecnológicos, nuevo release), o cuando los cambios son bastante complejos, lo mejor es hacer otra instalación de Developer para 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 para 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; //
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir durante la configuración de Developer para System z.
Encontrará más información en la sección de soporte del sitio Web de Developer para System z (http://www-306.ibm.com/software/awdtools/devzseries/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 también hallará la versión más reciente de la documentación de Developer para System z, incluidos los libros blancos.
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/
Developer para 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. 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:
La mayoría de los archivos de anotaciones se encuentran en home/.eclipse/RSE/USERID/, donde home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado, si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
En /tmp/ están los archivos de anotaciones creados antes de haberse verificado el ID de usuario.
Anotaciones de las operaciones normales. El valor predeterminado del JCL de ejemplo hlq.SFEKSAMP(FEJJJCL) es SYSOUT=*.
Anotaciones de rastreo. El valor predeterminado del JCL de ejemplo hlq.SFEKSAMP(FEJJJCL) es SYSOUT=*. El rastreo se activa con el parámetro -TV; hallará más detalles en: Personalizar el JCL de arranque del supervisor de trabajos JES.
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 hlq.SFEKSAMP(FEKAPPCC) es SYSOUT=*. Vea el manual MVS Planning APPC/MVS Management (SA22-7599) si desea 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 hlq.SFEKSAMP(FEKAPPCC) es &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Vea el manual MVS Planning APPC/MVS Management (SA22-7599) si desea obtener más detalles.
Los componentes relacionados con RSE crean varios archivos de anotaciones, la mayoría de los cuales se encuentran en home/.eclipse/RSE/USERID/, donde home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado, si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
La cantidad de datos escritos en ffs*.log, lock.log y rsecomm.log se controla mediante el valor debug_level existente en rsecomm.properties. Encontrará más detalles en: (Opcional) Personalizar la configuración del rastreo RSE, rsecomm.properties.
Este archivo contiene anotaciones del daemon antes del inicio de sesión.
Salida del mandato fekfivpc -file (prueba del IVP relacionada con SCLM Developer Toolkit), donde home es la vía de acceso del directorio inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
Encontrará más detalles en: Conexión del servicio de mandatos TSO (utilizando SCLMDT).
Anotaciones de la integración del analizador de faltas, donde home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado, si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
Al abrir una conexión con el gestor de archivos, se iniciará un trabajo servidor cuyo propietario será el ID del usuario. Su nombre es FEKpuerto, siendo puerto el número de puerto TCP/IP que se utiliza.
El SYSPRINT del trabajo servidor contiene las anotaciones del servidor FMI.
Anotaciones de comunicación de la FMI, donde home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado, si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
La cantidad de datos escritos en este archivo se controla mediante el valor debug_level existente en rsecomm.properties. Encontrará más detalles en: (Opcional) Personalizar la configuración del rastreo RSE, rsecomm.properties.
Al abrir una conexión con CARMA, hlq.SCRACLST(SCRASUBMT) 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 hlq.SCRACLST(SCRASUBMT), las anotaciones de CARMA se redirigen a esta sentencia DD en el trabajo servidor; de lo contrario, van a SYSPRINT.
La cantidad de anotaciones viene controlada por el valor Nivel de rastreo en el cliente. Para obtener más detalles sobre el valor Nivel de rastreo, vea: (Opcional) Activar el gestor de repositorios de acceso común (CARMA) de IBM.
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 home es la vía de acceso inicial definida en el segmento OMVS del usuario (o en el segmento OMVS predeterminado, si el usuario no tiene un segmento OMVS) y USERID es el ID de usuario de inicio de sesión (en mayúsculas).
La cantidad de datos escritos en este archivo se controla mediante el valor debug_level existente en rsecomm.properties. Encontrará más detalles en: (Opcional) Personalizar la configuración del rastreo RSE, rsecomm.properties.
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 los manuales MVS JCL Reference (SA22-7597) y Language Environment Debugging Guide (GA22-7560) para obtener más información sobre estas sentencias DD.
En z/OS UNIX, los vuelcos de Developer para 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:
El vuelco se escribe en un conjunto de datos MVS secuencial, utilizando un nombre predeterminado con el formato &idusuario.JVM.TDUMP.&nombretrabajo.D&fecha.T&hora, 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.
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: Ubicación de los vuelcos en 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: Ubicación de los vuelcos en 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: Ubicación de los vuelcos en z/OS UNIX.
Consulte el manual Java Diagnostics Guide (SC34-6650) si desea obtener más información sobre los vuelcos de la JVM, y el manual Language Environment Debugging Guide (GA22-7560) para obtener información específica 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 Explorador de Sistemas Remotos (RSE) es el componente de Developer para 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 se establece durante la instalación de SMP/E, cuando sea necesario.
Este resultado se puede verificar con el mandato ls -lE fekf*, que proporciona datos de salida como los del siguiente ejemplo ($ es el indicador de z/OS UNIX):
$ ls -lE /usr/lpp/wd4z/rse/lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfdir.dll -rwxr-xr-x -ps- 2 user group 143360 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfdivp -rwxr-xr-x --s- 2 user group 480 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpa -rwxr-xr-x --s- 2 user group 342 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpc -rwxr-xr-x --s- 2 user group 445 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpd -rwxr-xr-x --s- 2 user group 1491 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpj -rwxr-xr-x --s- 2 user group 883 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpr -rwxr-xr-x --s- 2 user group 307 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivps -rwxr-xr-x -ps- 2 user group 139264 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekflock -rwxr-xr-x -ps- 2 user group 196608 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfrsed -rwxr-xr-x --s- 2 user group 42443 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfscmd
Emita los siguientes mandatos si el bit de control de programa se tiene que establecer manualmente, suponiendo que se utiliza el directorio de instalación predeterminado (/usr/lpp/wd4z/rse/lib/):
1. cd /usr/lpp/wd4z/rse/lib 2. extattr +p fekfdir.dll fekfivp fekflock fekfrsed
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 de uno de los ejemplos que siguen. Los puertos utilizados son el último número (a continuación de '..') de la columna/fila "Socket Local". Como estos puertos ya se están utilizando, no se pueden utilizar para la configuración de Developer para System z.
IPv4
MVS TCP/IP NETSTAT CS V1R7 Nombre de 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 INETD4 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 V1R7 Nombre de 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 INETD4 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).
Para obtener más información sobre estas sentencias, consulte el manual Communications Server IP Configuration Guide (SC31-8775).
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 de este ejemplo:
MVS TCP/IP NETSTAT CS V1R7 Nombre de 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
En el manual Communications Server IP System Administrator's Commands (SC31-8781) hallará más información sobre el mandato NETSTAT.
Para el servidor RSE, que es un proceso Java UNIX, 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.
INETD inicia un servidor RSE cuando un cliente se conecta al puerto del daemon RSE o cuando el cliente emite el script de arranque utilizando REXEC/SSH. Esto se hace empleando los límites de almacenamiento de INETD, por lo que estos se tienen que establecer con el suficiente tamaño.
Establezca que MAXASSIZE, en SYS1.PARMLIB(BPXPRMxx) (que define el tamaño de región (proceso) de espacio de direcciones OMVS predeterminado), sea igual o mayor que 2147483647.
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 (SA22-7627):
Compruebe ASSIZEMAX, en el segmento OMVS del ID de usuario del cliente, y establezca que sea igual a 2147483647 o, preferiblemente, igual a 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 (SA22-7627):
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 para 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.SF1.Z682746.XML 23 //COBOL.WSEDSF2 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF1.Z682747.XML
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 proporcionado en (Opcional) Definir una 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 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/devzseries/support/). Si desea información adicional, la encontrará en 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 para System z activos. La mayoría de los valores BPXPRMxx se pueden cambiar dinámicamente con los mandatos de consola SETOMVS y SET OMVS.
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.
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(200) TYPE(UDS)
Cuando se utiliza VIPA (dirección IP virtual) dinámica a través de múltiples pilas de TCPIP, se necesita una coordinación a escala del sistema de los puertos efímeros, para que la tupla 4 (combinación de direcciones IP y puertos origen y destino) de cada conexión permanezca exclusiva. Esto se puede hacer añadiendo el parámetro SYSPLEXPORTS opcional a la primera sentencia VIPADISTRIBUTE, como se describe en el manual Communications Server IP Configuration Guide (SC31-8775).
Cuando utilice esta técnica, asegúrese de que se ha definido la estructura del recurso de acoplamiento EZBEPORT (que contiene información de asignación de puertos sysplex. En el manual Communications Server SNA Network Implementation Guide (SC31-8777) encontrará información sobre cómo llevarlo a la práctica.
Después de haber leído este manual y de consultar el sitio Web de soporte (http://www-306.ibm.com/software/awdtools/devzseries/support/), si todavía tiene dificultades y necesita ayuda del personal de soporte de IBM, reúna los siguientes datos y abra un registro de problemas con IBM:
La siguiente información le ayudará a resolver los problemas de conexión
Si utiliza SCLM Developer Toolkit para el servicio de mandatos TSO (método predeterminado)
Si utiliza APPC para el servicio de mandatos TSO
Proporcione toda la información que parezca relevante para los problemas funcionales, como
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar TCP/IP, o durante la tarea de comprobar y/o modificar una configuración existente.
Consulte los manuales Communications Server: IP Configuration Guide (SC31-8775) y Communications Server IP Configuration Reference (SC31-8776) para obtener información adicional sobre la configuración de TCP/IP.
Developer para System z depende de que TCP/IP tenga el nombre de host correcto en el momento de la inicialización. 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 el mandato TSO HOMETEST. En el manual Communications Server IP System Administrator's Commands (SC31-8781) hallará más información sobre el mandato HOMETEST.
Salida de ejemplo del mandato HOMETEST:
Ejecutar IBM MVS TCP/IP CS V1R7 TCP/IP Configuration Tester El archivo de parámetros de configuración de FTP utilizado será "SYS1.TCPPARMS(FTPDATA)" El nombre de host TCP es: CDFMVS08 Utilizar servidor de nombres para resolver CDFMVS08 Las siguientes direcciones IP corresponden al nombre de host TCP: CDFMVS08 9.42.112.75 Las siguientes direcciones IP son las direcciones IP HOME definidas en PROFILE.TCPIP: 9.42.112.75 127.0.0.1 ¡Todas las direcciones IP de CDFMVS08 están en la lista HOME! La prueba de Home ha sido satisfactoria - ¡Se han superado todas las pruebas!
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 el manual 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 de 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 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.
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 el manual 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 para System z depende de que TCP/IP tenga el nombre de host correcto en el momento de la inicialización. 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. Fíjese en 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, conviene 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
|
Este apéndice se propone ayudarle a resolver algunos problemas comunes que pueden surgir al configurar INETD, o durante la tarea de comprobar y/o modificar una configuración existente.
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 argumentos_programa_servidor
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 4 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, conviene 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]
Conviene 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 arranque BPXBATCH funciona para los trabajos de STC y 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: Figura 11 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, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD PATH='/tmp/bpxbatch.start.inetd.stderr', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //* STDIN, STDOUT y STDENV toman por defecto el valor /dev/null //* La salida del daemon INETD se puede controlar mediante los valores de syslogd //*
// 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 usar (si la persona que los emite tiene autorización suficiente) para detener e iniciar INETD (# es el indicador de z/OS UNIX):
1. # ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd 2. # kill 7 3. # _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 "human", 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.
En el manual UNIX System Services Command Reference (SA22-7802) obtendrá más información sobre los mandatos extattr y su. Consulte el manual UNIX System Services Planning (GA22-7800) para obtener más información sobre la clase UNIXPRIV y los perfiles BPX.* de la clase FACILITY. En el manual Security Server RACF Security Administrator's Guide (SA22-7683) hallará más información sobre las definiciones del segmento OMVS y la clase PROGRAM.
Developer para System z depende de INETD a la hora de poner a punto la conexión entre cliente y host. También impone requisitos adicionales sobre la configuración de INETD descrita más arriba.
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 RSE que se inicia mediante INETD cuando un cliente se conecta al puerto 4035 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 RSE (en inetd.conf) necesita tener los siguientes permisos:
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.
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. La capa de sockets segura (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. En el manual Security Server RACF Security Administrator's Guide (SA22-7683) hallará más información sobre los certificados digitales y el protocolo de claves públicas empleado por SSL.
Las acciones necesarias para configurar las comunicaciones SSL para Developer para 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 que utilice SSL. Ambos métodos de conexión, el de REXEC y el de daemon, se configurarán para SSL. También crearemos nuestros propios certificados de seguridad para que los utilicen diferentes componentes de la conexión RSE. Todo ello se realizará siguiendo estos pasos:
A lo largo de este apéndice se utiliza un convenio de denominación uniforme:
En la mayoría de 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.
En este paso se crea una nueva instancia del servidor RSE y del daemon RSE para ejecutarse en paralelo con la(s) existente(s). De este modo, la prueba SSL no entorpecerá las operaciones normales. Como ya se aconsejó en: Guardar el archivo de configuración rsed.envvars en otro directorio, en los siguientes mandatos de ejemplo se espera que los archivos de configuración estén en /etc/wd4z/.
$ cd /etc/wd4z $ mkdir ssl $ cp * ssl cp: FSUM6254 "ssl" es un directorio (no copiado) $ ls ssl rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries $ cd ssl $ su # oedit /etc/services rsessl 4047/tcp #Developer para System z RSE using SSL
añadir servicio rsessl, utilizando el puerto 4047
# oedit /etc/inetd.conf rsessl stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z/ssl
añadir el daemon rsessl, utilizando el directorio de configuración /etc/wd4z/ssl
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd # exit $ netstat | grep 4047 INETD4 00016619 0.0.0.0..4047 0.0.0.0..0 Escucha
Los mandatos que figuran más arriba crean un subdirectorio llamado ssl y los pueblan con los archivos de configuración obligatorios. No hace falta hacer cambios de configuración (todavía). Podemos compartir el directorio de instalación y los componentes MVS, ya que no son específicos de SSL. Sin embargo, hay que definir un nuevo daemon (rsessl) que utiliza los nuevos archivos de configuración. El puerto que se asigna al nuevo daemon es el 4047.
Para obtener más información sobre las acciones anteriores, consulte: Activar componentes z/OS UNIX de Developer para System z.
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.
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 (por ejemplo, por RACF). El servidor RSE (que se inicia mediante el daemon o REXEC) es una aplicación SSL Java y utiliza un archivo de almacén de claves creado por keytool. Actualmente, RACF no tiene ningún soporte inmediato para SSL Java.
Así que, para conectar por medio de REXEC, todo lo que necesitamos es el archivo de almacén de claves:
Para conectar por medio del daemon, necesitamos ambas archivos, el de almacén de claves y el de base de datos de claves:
En el manual Security Server RACF Security Administrator's Guide (SA22-7683) encontrará información sobre RACF y los certificados digitales. La documentación de gskkyman se encuentra en Cryptographic Services System SSL Programming (SC24-5901). La documentación de keytool está disponible en http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html.
"keytool -genkey" genera un par de claves (una clave pública y una clave privada asociada). Luego envuelve la clave pública en un certificado X.509 v1 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 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.
$ keytool -genkey -alias wd4zrse -validity 3650 -keystore wd4zssl.jks -storepass rsessl -keypass rsessl ¿Cuál es su nombre y su apellido? [Desconocido]: wd4z rse ssl ¿Cuál es el nombre de su unidad de organización (OU)? [Desconocido]: wd4z ¿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=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=USt? (teclee "yes" o "no") [no]: yes $ ls rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries wd4zssl.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/wd4z/ssl/wd4zssl.jks utilizando el alias wd4zrse. 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:
$ keytool -list -alias wd4zrse -keystore wd4zssl.jks -storepass rsessl -v Nombre de alias: wd4zrse Fecha de creación: May 24, 2007 Tipo de entrada: keyEntry Longitud de la cadena de certificados: 1 Certificado 1¨: Propietario: CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US Emisor: CN=wd4z rse ssl, OU=wd4z, 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
Como ya se ha mencionado, el daemon es una aplicación SSL del sistema que utiliza una base de datos de claves. Esta puede ser un archivo físico creado por gskkyman o bien un anillo de claves RACF. Los anillos de claves RACF son el método preferido para gestionar claves privadas y certificados de SSL del sistema.
No realice este paso si utiliza gskkyman para SSL del sistema.
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.
En el manual Security Server RACF Command Language Reference (SA22-7687) encontrará los detalles 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(omvskern) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(omvskern) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(omvskern) GENCERT SUBJECTSDN(CN('wd4z rse ssl') + OU('wd4z') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('wd4zrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(omvskern) ADDRING(wd4zssl.racf) RACDCERT ID(omvskern) CONNECT(LABEL('wd4zrse') RING(wd4zssl.racf) + DEFAULT USAGE(PERSONAL))
En el ejemplo anterior se empieza por crear los perfiles necesarios y permitir que el ID de usuario OMVSKERN tenga acceso a los anillos de claves. El ID de usuario que se utilice debe coincidir con el ID de usuario codificado en /etc/inetd.conf para el daemon RSE SSL. El próximo paso consiste en crear un nuevo certificado autofirmado con la etiqueta wd4zrse . No se necesita ninguna contraseña. Luego este certificado se añade a un anillo de claves recién creado (wd4zssl.racf). Igual que con el certificado, tampoco se necesita una contraseña para el anillo de claves. El tiempo de vigencia del certificado coincide con el del creado con keytool.
El resultado se puede verificar con la opción list:
RACDCERT ID(omvskern) LIST Información de certificado para el usuario OMVSKERN: Etiqueta: wd4zrse 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=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Nombre del sujeto: >CN=wd4z rse ssl.OU=wd4z.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: OMVSKERN Anillo: >wd4zssl.racf<
No realice este paso si utiliza RACF para SSL del sistema.
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
$ gskkyman Menú de base de datos 1 - Crear base de datos nueva 2 - Abrir base de datos 3 - Cambiar contraseña de base de datos 4 - Cambiar longitud de registro de base de datos 5 - Suprimir base de datos 6 - Crear archivo de parámetros de clave 0 - Salir del programa Entre el número de opción: 1 Entre el nombre de la base de datos de claves (pulse Intro para volver al menú): wd4zssl.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/wd4z/ssl/wd4zssl.kdb. Pulse Intro para continuar. Menú de gestión de claves Base de datos: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gestionar claves y certificados 2 - Gestionar certificados 3 - Gestionar peticiones de certificado 4 - Crear petición de certificado nueva 5 - Recibir certificado solicitado o un certificado de renovación 6 - Crear un certificado autofirmado 7 - Importar un certificado 8 - Importar un certificado y una clave privada 9 - Mostrar la clave predeterminada 10 - Almacenar contraseña de base de datos 11 - Mostrar longitud de registro de base de datos 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 6 Tipo de certificado 1 - Certificado de CA con clave RSA de 1024 bites 2 - Certificado de CA con clave RSA de 2048 bites 3 - Certificado de CA con clave RSA de 4096 bites 4 - Certificado de CA con clave DSA de 1024 bites 5 - Certificado de usuario o servidor con clave RSA de 1024 bites 6 - Certificado de usuario o servidor con clave RSA de 2048 bites 7 - Certificado de usuario o servidor con clave RSA de 4096 bites 8 - Certificado de usuario o servidor con clave DSA de 1024 bites Seleccione el tipo de certificado (pulse Intro para volver al menú): 5 Entre la etiqueta (pulse Intro para volver al menú): wd4zrse Entre el nombre de sujeto del certificado Nombre común (necesario): wd4z rse ssl Unidad de organización (OU, opcional): wd4z 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 Base de datos: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gestionar claves y certificados 2 - Gestionar certificados 3 - Gestionar peticiones de certificado 4 - Crear petición de certificado nueva 5 - Recibir certificado solicitado o un certificado de renovación 6 - Crear un certificado autofirmado 7 - Importar un certificado 8 - Importar un certificado y una clave privada 9 - Mostrar la clave predeterminada 10 - Almacenar contraseña de base de datos 11 - Mostrar longitud de registro de base de datos 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 0 $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb $ chmod 644 wd4zssl.kdb $ chmod 644 wd4zssl.rdb $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb
En el ejemplo anterior se empieza por crear una base de datos de claves llamada wd4zssl.kdb con la contraseña rsessl. Una vez creada, la base de datos se puebla creando un nuevo certificado autofirmado que se almacena bajo la etiqueta wd4zrse 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. Las máscaras que se pueden usar para el mandato chmod son 640 (el propietario tiene acceso de lectura/escritura y el grupo del propietario tiene acceso de lectura) o 644 (el propietario tiene acceso de lectura/escritura y los demás tienen acceso de lectura).
El resultado se puede verificar seleccionando la opción Mostrar información de certificado, en el submenú Gestionar claves y certificados:
$ gskkyman Menú de base de datos 1 - Crear base de datos nueva 2 - Abrir base de datos 3 - Cambiar contraseña de base de datos 4 - Cambiar longitud de registro de base de datos 5 - Suprimir base de datos 6 - Crear archivo de parámetros de clave 0 - Salir del programa Entre el número de opción: 2 Entre el nombre de la base de datos de claves (pulse Intro para volver al menú): wd4zssl.kdb Entre la contraseña de la base de datos (pulse Intro para volver al menú): rsessl Menú de gestión de claves Base de datos: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gestionar claves y certificados 2 - Gestionar certificados 3 - Gestionar peticiones de certificado 4 - Crear petición de certificado nueva 5 - Recibir certificado solicitado o un certificado de renovación 6 - Crear un certificado autofirmado 7 - Importar un certificado 8 - Importar un certificado y una clave privada 9 - Mostrar la clave predeterminada 10 - Almacenar contraseña de base de datos 11 - Mostrar longitud de registro de base de datos 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 1 Lista de claves y certificados Base de datos: /etc/wd4z/ssl/wd4zssl.kdb 1 - wd4zrse 0 - Volver al menú de selección Entre el número de etiqueta (Intro para volver al menú de selección, p para lista anterior): 1 Menú de claves y certificados Etiqueta: wd4zrse 1 - Mostrar información de certificado 2 - Mostrar información de clave 3 - Establecer clave como valor predeterminado 4 - Establecer estado de confianza de certificado 5 - Copiar certificado y clave en otra base de datos 6 - Exportar certificado a un archivo 7 - Exportar certificado y clave a un archivo 8 - Suprimir certificado y clave 9 - Cambiar etiqueta 10 - Crear un certificado firmado y una clave 11 - Crear una petición de renovación de certificado 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 1 Información de certificado Etiqueta: wd4zrse ID de registro: 14 ID de registro del emisor: 14 De confianza: Sí Versión: 3 Número de serie: 45356379000ac997 Nombre del emisor: wd4z rse ssl wd4z IBM Raleigh NC US Nombre de sujeto: wd4z rse ssl wd4z 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 Etiqueta: wd4zrse 1 - Mostrar información de certificado 2 - Mostrar información de clave 3 - Establecer clave como valor predeterminado 4 - Establecer estado de confianza de certificado 5 - Copiar certificado y clave en otra base de datos 6 - Exportar certificado a un archivo 7 - Exportar certificado y clave a un archivo 8 - Suprimir certificado y clave 9 - Cambiar etiqueta 10 - Crear un certificado firmado y una clave 11 - Crear una petición de renovación de certificado 0 - Salir del programa Entre el número de opción (pulse Intro para volver al menú anterior): 0
Ahora que los certificados ya están a punto, RSE se puede iniciar utilizando SSL. En función de las definiciones que se hayan elegido en los pasos anteriores, habrá que proporcionar distintos valores en ssl.properties.
$ oedit ssl.properties
Ahora, la configuración de host SSL ya se ha realizado y se puede probar conectando con el cliente Developer para 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 mediante estas características:
STEPLIB=SYS1.SIEALNKE
STEPLIB=$STEPLIB:SYS1.SIEALNKE
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 para System z, si no reconoce el certificado del host, 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 (home/.eclipse/RSE/USERID/* y /tmp/rsedaemon.log), como se describe en: Anotaciones de RSE.
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 y/o modificar una configuración existente.
En los manuales MVS Planning APPC/MVS Management (SA22-7599) y MVS Initialization and Tuning Reference (SA22-7592) encontrará información adicional sobre la gestión de APPC y sobre los miembros parmlib que figuran a continuación.
Fíjese en 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 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 para System z activa un nuevo TP que se llama FEKFRSRV, y al que nos referimos como servicio de mandatos TSO.
El trabajo de ejemplo que aparece en la figura 14 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 el manual Communications Server bookshelf (F1A1BK61 for z/OS 1.7) para obtener más información sobre cómo configurar 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.
Figura 16 es un miembro SYS1.PARMLIB(APPCPMxx) de ejemplo que se puede usar 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 estos factores:
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: Personalizar rsed.envvars, el 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 para System z.
Para el servicio de mandatos TSO, también hay que especificar las especificaciones predeterminadas en las secciones OPTIONS y TPDEFAULT.
Figura 17 es un miembro SYS1.PARMLIB(ASCHPMxx) de ejemplo que se puede usar 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. En el manual MVS System Commands (SA22-7627) hallará más información sobre los mandatos de consola mencionados.
Una vez que APPC/MVS esté activo, se puede definir el servicio de mandatos TSO de Developer para System z, como se describe en: (Opcional) Definir una transacción APPC para el servicio de mandatos TSO.
La manera documentada de definir la transacción APPC consiste en personalizar y someter hlq.SFEKSAMP(FEKAPPCC), siendo hlq el calificador de alto nivel empleado durante la instalación de Developer para System z (el valor predeterminado es FEK).
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 libro blanco APPC and WebSphere Developer para System z (SC23-5885) está disponible en la biblioteca de Developer para System z en Internet, http://www-306.ibm.com/software/awdtools/devzseries/library/
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Esta información se ha desarrollado para los productos y los servicios que se ofrecen en Estados Unidos.
Es posible que IBM no ofrezca en otros países los productos, servicios o características que se describen en este documento. El representante local de IBM le puede informar acerca de los productos y servicios que actualmente están disponibles en su localidad. Las referencias hechas a productos, programas o servicios de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios de IBM. Puede utilizarse en su lugar cualquier otro producto, programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedad intelectual de IBM. No obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.
IBM puede tener patentes o solicitudes de patente pendientes de aprobación que cubran alguno de los temas tratados en este documento. La posesión de este documento no le confiere ninguna licencia sobre dichas patentes. Puede enviar consultas sobre licencias por escrito a:
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 que sigue no se aplica al Reino Unido ni a ningún otro país en el que tales disposiciones sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL", SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, DE COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la declaración de limitación de responsabilidad, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso.
Esta información puede contener imprecisiones técnicas o errores tipográficos. La información incluida en este documento está sujeta a cambios periódicos; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento y sin previo aviso.
Cualquier referencia 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 por 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.
LICENCIA DE COPYRIGHT:
Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que ilustra 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. Usted puede copiar, modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar a IBM, con el fin de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con las interfaces de programación de aplicaciones (API) de IBM.
Cada copia o cada parte de los programas de ejemplo o de los trabajos que se deriven de ellos debe incluir un aviso de copyright como se indica a continuación:
(C) (nombre de la empresa) (año). Algunas partes de este código procede de los programas de ejemplo de IBM Corp. (C) Copyright IBM Corp. _escriba el año o los años_. Reservados todos los derechos.
Los siguientes términos son marcas registradas de International Business Machines Corporation en 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.
Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas de Microsoft Corporation en Estados Unidos y/o en otros países.
UNIX es una marca registrada de The Open Group.
Los nombres de otras empresas, productos y servicios que se hayan señalado con dos asteriscos (**) pueden ser marcas registradas o marcas de servicio de terceros.