Antes de utilizar este documento, leia as informações gerais em Avisos.
Esta edição se aplica ao IBM Rational Developer para System z Versão 7.1 (número de programa 5724-T07) e a todos os releases e modificações subseqüentes até que o contrário seja indicado em novas edições.
Solicite as publicações pelo telefone ou fax. O IBM Software Manufacturing Solutions recebe os pedidos de publicações entre 8h30 e 19h, horário padrão na costa leste dos EUA. O número de telefone é (800) 879-2755. O número de fax é (800) 445-9269. O fax deve ser enviado para: Publications, 3rd floor.
Você também pode solicitar as publicações através de um representante IBM ou da filial da IBM que atende em sua região. As publicações não são guardadas no endereço abaixo.
A IBM agradece pelo seu comentário. Você pode enviar os comentários pelo correio ao seguinte endereço:
Ao enviar informações à IBM, você concede à IBM o direito não-exclusivo de utilizar ou distribuir as informações da forma que julgar apropriada, sem incorrer em qualquer obrigação para com o Cliente.
Nota para Usuários do Governo dos Estados Unidos - Uso, duplicação ou divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Este manual discute a configuração das funções do IBM Rational Developer para System z. Ele inclui instruções sobre como configurar os servidores IBM Rational Developer para System z no sistema de host z/OS.
De agora em diante, os seguintes nomes serão utilizados neste manual:
Para o IBM WebSphere Developer for System z, o IBM WebSphere Developer for zSeries e o WebSphere Studio Enterprise Developer, utilize as informações de configuração encontradas no Guia de Configuração do Host e Diretórios do Programa desses releases.
Este manual se destina a programadores de sistema instalando e configurando o IBM Rational Developer para System z Versão 7.1 no sistema de host z/OS. Para utilizar este manual, você deve estar familiarizado com os sistemas host z/OS UNIX e MVS.
Para cada uma das seguintes funções, instale os FMIDs necessários. Para obter informações de instalação sobre os vários FMIDs, consulte o diretório de programa correspondente ao FMID que você está instalando.
Se você necessitar desta função do IBM Rational Developer para System z | Deverá instalar estes FMIDs | E encontrará aqui, informações de instalação e configuração |
---|---|---|
|
HHOP710, HSD3310* |
opcional
|
|
HCMA710, HHOP710** |
opcional
|
|
HSD3310 |
|
(*) O Developer for System z requer uma conexão com o serviço Comandos do TSO no z/OS. Essa conexão é fornecida por um dos seguintes:
(**) CARMA requer uma interface baseada em host. O HHOP710 oferece essa função ou você pode utilizar uma interface baseada em host integrada customizada e omitir a instalação do HHOP710
As etapas de customização SCLMDT a seguir devem ser desempenhadas e estão descritas no SCLM Developer Toolkit Installation and Customization Guide (SC23-8504):
Para obter instruções detalhadas sobre a instalação do SMP/E para cada um dos FMIDs, consulte o diretório de programas apropriado, conforme listado em Tabela 1.
O Developer for System z possui uma lista de softwares obrigatórios que devem ser instalados e estar em funcionamento para que o produto funcione. Há também uma lista de software de co-requisito para suportar recursos específicos do Developer for System z. Esses requisitos devem ser instalados e estar em funcionamento no tempo de execução para que o recurso correspondente funcione conforme projetado.
Consulte o IBM Rational Developer para System z Host Planning Guide (GI11-8296-00) para obter uma lista de pré-requisitos e co-requisitos para a sua versão do Developer for System z.
Consulte o programador de sistemas do MVS, o administrador de segurança e o administrador TCP/IP para verificar se os produtos e o software de requisito estão instalados, testados e funcionando.
As etapas de customização SCLMDT a seguir devem ser desempenhadas e estão descritas no Guia de Instalação e Customização do SCLM Developer Toolkit (SC23-8504):
Você pode testar sua configuração TCP/IP com o comando HOMETEST do TSO. Consulte "TSO Commands" no Communications Server: IP System Administrator's Commands (SC31-8781) para obter mais informações sobre este comando.
Saída de exemplo do comando HOMETEST:
Executando o Testador de Configuração TCP/IP IBM MVS TCP/IP CS V1R7 O arquivo de parâmetros de configuração de FTP utilizado será "SYS1.TCPPARMS(FTPDATA)" O Nome do Host TCP é: CDFMVS08 Utilizando o Servidor de Nomes para Resolver CDFMVS08 Os endereços IP a seguir correspondem ao Nome do Host TCP: CDFMVS08 9.42.112.75 Os endereços IP a seguir são os endereços IP HOME definidos no PROFILE.TCPIP: 9.42.112.75 127.0.0.1 Todos os endereços IP do CDFMVS08 estão na lista HOME! O Hometest foi bem-sucedido - todos os Testes Passaram!
O ID do usuário de um usuário do Developer for System z deve ter, pelo menos, os seguintes atributos:
Exemplo (comando LISTUSER userid NORACF OMVS):
USER=userid OMVS INFORMATION ---------------- UID= 0000003200 HOME= /u/userid PROGRAM= /bin/sh CPUTIMEMAX= NONE ASSIZEMAX= NONE FILEPROCMAX= NONE PROCUSERMAX= NONE THREADSMAX= NONE MMAPAREAMAX= NONE
Exemplo (comando LISTGRP group NORACF OMVS):
GROUP group OMVS INFORMATION ---------------- GID= 0000003243
Os serviços de host a seguir, e, portanto, suas portas, devem estar disponíveis para conexão do cliente. Todas as outras portas utilizadas pelo Developer for System z possuem tráfego apenas do host. Isso significa que, para o Developer for System z, apenas as portas listadas devem estar definidas para o firewall que está protegendo o host.
INETD é um processo do servidor z/OS UNIX necessário para configurar conexões de host do cliente do Developer for System z. As configurações ambientais do INETD, informadas ao iniciar um processo, e as permissões para o ID do usuário do INETD, devem ser definidas adequadamente para que o INETD inicie o servidor RSE.
Consulte Apêndice D. Configurando o INETD para obter mais informações sobre permissões do INETD.
O RSE (Remote Systems Explorer) é o componente do Developer for System z que fornece os principais serviços, como de conexão do cliente ao host.
A configuração do Developer for System z requer mais do que as permissões típicas do programador de sistemas, portanto é esperada uma necessidade mínima de assistência. A lista a seguir destaca as áreas mais importantes:
O Developer for System z e o CARMA (Common Access Repository Manager) suportam clonagem e instalação em um sistema diferente, evitando a necessidade de uma instalação SMP/E em cada sistema.
Os seguintes conjuntos de dados, diretórios e arquivos são obrigatórios para implementação em outros sistemas. Se você copiou um arquivo em um local diferente para customização, então esse arquivo deve substituir sua contraparte nas listas a seguir.
Esta seção destaca as alterações na instalação e na configuração de releases anteriores do produto.
/usr/lpp/wd4z/rse/lib/setup.env.zseries
Antes de instalar o Developer for System z versão 7.1, se você for um usuário anterior do Developer for System z, é recomendável salvar os arquivos customizados relacionados. Leia o Apêndice A. Executando Várias Instâncias do Developer for System z antes de iniciar a customização se você planeja executar várias instâncias do Developer for System z.
A Tabela 2 e a Tabela 3 fornecem uma visão geral dos arquivos que podem ter sido customizados para o Developer for System z e CARMA versão 6.0.1 e posterior. A Tabela 4 lista as customizações de conjuntos de dados e produtos e software obrigatórios e de co-requisito que ocorrem durante a instalação de um Developer for System z e CARMA versão 6.0.1 (e posterior).
Membro | Local padrão v6.0.1 | Local padrão v7.0/v7.1 | Objetivo |
---|---|---|---|
FEJJCNFG |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
Arquivo de configuração para JES Job Monitor |
FEJJJCL |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para JES Job Monitor |
FEJTSO |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para emissões TSO |
FEKAPPCC | não existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para criação de uma transação APPC |
FEKAPPCL | não existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para exibição de uma transação APPC |
FEKAPPCX | não existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para exclusão de uma transação APPC |
FEKFRTAD |
hlq.SFEKSAMP (hlq = FEK) |
(novo nome de membro FEKAPPCC) | JCL para criação de uma transação APPC |
FEKFRDIS |
hlq.SFEKSAMP (hlq = FEK) |
(novo nome de membro FEKAPPCL) | JCL para exibição de uma transação APPC |
FEKFRDEL |
hlq.SFEKSAMP (hlq =FEK) |
(novo nome de membro FEKAPPLX) | JCL para exclusão de uma transação APPC |
ELAXF* |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para construções de projetos remotos, etc. |
ELAXMSAM |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
Procedimento JCL do espaço de endereços WLM para o Stored Procedure Builder para PL/I e COBOL |
ELAXMJCL |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
JCL para definição do Stored Procedure Builder para PL/I e COBOL para o DB2 |
ADNVSAM | não existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para definir o repositório ADM CRD |
ADNPCCSD | não existe
|
hlq.SFEKSAMP (hlq = FEK) |
JCL para ativação do servidor CRD na região CICS primária |
ADNCMSGH | não existe |
hlq.SFEKSAMP (hlq = FEK) (não existe na versão 7.0) |
JCL para compilar o Manipulador de Mensagem de Pipeline |
ADNTMSGH | não existe |
hlq.SFEKSAMP (hlq = FEK) |
Código-fonte de amostra para o Manipulador de Mensagem de Pipeline |
ADNARCSD | não existe |
hlq.SFEKSAMP (hlq = FEK) |
JCL para ativação do servidor CRD em regiões CICS não-primárias |
CRASUBMT |
hlq.SCRACLST (hlq = CRA) |
hlq.SCRACLST (help = CRA) |
CLIST para emissão do JCL para um servidor CARMA |
CRAMREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA$VMSG)(hlq = CRA) |
JCL para criação do VSAM de mensagens do CARMA |
CRAREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA$VDEF)(hlq = CRA) |
JCL para criação do VSAM de configuração do CARMA |
CRASREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA$VSTR)(hlq = CRA) |
JCL para criação do VSAM de informações customizadas do CARMA |
CRALREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA#VSLM)(hlq = CRA) |
JCL para criação do VSAM de mensagens de RAM do SCLM |
CRASALX |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA#ASLM)(hlq = CRA) |
JCL para criação dos conjuntos de dados de RAM do SCLM |
CRATREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (novo nome de membro na versão 7.1 CRA#VPDS)(hlq = CRA) |
JCL para criação do VSAM de mensagens de RAM do PDS |
Arquiovo | Local padrão v6.0.1 | Local padrão versão 7.0/versão 7.1 | Objetivo |
---|---|---|---|
rsed.envvars | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Arquivo de configuração RSE |
rsecomm.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Arquivo de configuração de rastreio RSE |
ssl.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Arquivo de configuração SSL RSE |
setup.env.zseries | /usr/lpp/wd4z/rse/lib/ | (não mais customizado) | Exportar variáveis de ambiente RSE |
projectcfg.properties | (não existe) | /usr/lpp/wd4z/rse/lib/ | Arquivo de configuração de projetos do host |
FMIEXT.properties | (não existe) | /usr/lpp/wd4z/rse/lib/ (não existe na versão 7.0) | Arquivo de configuração do File Manager |
CRASRV.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Arquivo de configuração CARMA |
rexxsub | /usr/lpp/wd4z/rse/lib/ | (não mais customizado) | REXX do z/OS UNIX do CARMA para execução do MVS CRASUBMT CLIST |
Membro/Arquivo | Local padrão | Customização necessária |
---|---|---|
BPXPRMxx | SYS1.PARMLIB | Configure MAXASSIZE como 2147483647 ou maior |
PROGxx | SYS1.PARMLIB | hlq.SFEKLOAD autorizado por APF |
ASCHPMxx | SYS1.PARMLIB | Definir uma classe de transação APPC para o serviço de comandos do TSO |
services | /etc/ | Definir daemon RSE |
inetd.conf | /etc/ | Definir daemon RSE |
ISPF.conf | /etc/SCLMDT/CONFIG/ | Defina o local do Servidor de Comandos do TSO |
/ | APPC | Definir uma transação APPC para o serviço de comandos do TSO |
/ | WLM | Associar o programa de transação APPC a um grupo de desempenho do TSO |
/ | WLM | Designar um ambiente de aplicativos para o procedimento armazenado do DB2 |
Antes de instalar a versão 7.1, se você for um usuário anterior do WebSphere Developer for System z (FMID: HHOP700), é recomendável salvar a customização relacionada, conforme descrito em Fazendo Backup de Arquivos Configurados Anteriormente.
Todas as referências a hlq neste capítulo se referem ao qualificador de alto nível utilizado durante a instalação do Developer for System z. O padrão da instalação é FEK, mas isto talvez não se aplique ao seu site.
O requisito de LINKLIST pode ser ignorado incluindo-se uma instrução STEPLIB em rsed.envvars; consulte Customizar rsed.envvars, o Arquivo de Configuração para RSE.
MAXASSIZE define o tamanho da região do espaço (processo) de endereços. Configure MAXASSIZE em SYS1.PARMLIB(BPXPRMxx) como 2147483647 ou maior.
Este valor pode ser verificado e configurado dinamicamente (até o próximo IPL) com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781).
1. DISPLAY OMVS,O 2. SETOMVS MAXASSIZE=2147483647
Consulte Tamanho do Espaço de Endereço para obter mais informações sobre outros locais em que tamanhos de espaço do endereço possam ser definidos ou limitados.
Para que o JES Job Monitor acesse os arquivos do spool do JES, a biblioteca de carregamento hlq.SFEKLOAD deve ser autorizada por APF.
As autorizações APF são definidas em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM. Consulte MVS Initialization and Tuning Reference (SC28-1752) para obter informações adicionais sobre a definição de autorizações APF.
Para finalidades de testes, as autorizações APF também podem ser fornecidas dinamicamente. Estas autorizações durarão até o próximo IPL do sistema. O comando do console necessário se parecerá com este:
SETPROG APF,ADD,DSN=hlq.SFEKLOAD,SMS
Consulte MVS System Commands (GC28-1781) para obter informações adicionais sobre o comando SETPROG.
O JES Job Monitor é o componente do Developer for System z que administra toda a conectividade do JES. Um arquivo de configuração é utilizado para customizar determinados aspectos para atender os padrões do seu site.
O arquivo de configuração sample está localizado em:
hlq.SFEKSAMP(FEJJCNFG)
O arquivo consiste de um conjunto de definições de variáveis de ambiente. Linhas de comentários iniciam com o sinal de libras (#). O arquivo de configuração de amostra está listado em 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
As seguintes definições são requeridas:
As definições a seguir são opcionais. Se omitidas, valores padrão serão utilizados conforme especificados abaixo:
O JES Job Monitor é o componente do Developer for System z que administra toda a conectividade do JES. Para fazer isto, um servidor deve estar ativo no sistema (como job do usuário ou STC). Siga as etapas de customização do JCL localizadas em hlq.SFEKSAMP(FEJJJCL) para criar o servidor JES Job Monitor de acordo com os padrões do seu site.
Se for necessário ativar o rastreio do JES Job Monitor para diagnóstico, inclua "-TV" na linha PARM. O rastreio causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center.
//JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/ -TV')
O rastreio também poderá ser controlado por comandos do console. Assumindo que JMON é o nome de tarefa utilizado, o primeiro comando de console listado a seguir ativará o rastreio e o segundo o desativará.
1. F JMON,APPL=-TV 2. F JMON,APPL=-TN
O JES Job Monitor pode ser executado como um job de usuário ou como tarefa iniciada (STC). As tarefas a seguir precisam ser implementadas para definir JMON como uma STC:
//JMON PROC HLQ=FEK, // PRM= //* //* WD/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 uma fácil referência, é recomendável que o nome do membro corresponda ao nome do procedimento (JMON na amostra acima).
Utilize o seguinte comando de amostra para criar tal ID do usuário, em que userid é o ID do usuário em questão, groupid é o grupo padrão e uid é o ID do 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 incluir o JES Job Monitor como uma STC, a seguir você possui os comandos RACF necessários, em que jmon é o nome do membro JCL e userid é o ID de usuário cujas as autoridades devem ser utilizadas.
a. RDEFINE STARTED jmon.* STDATA(USER(userid)) b. SETROPTS RACLIST(STARTED) REFRESH
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter mais informações sobre tarefas iniciadas e segurança.
O operador do sistema pode emitir os seguintes comandos no console (em que JMON é o nome da STC do JES Job Monitor):
a. Start JMON b. stoP JMON c. Display A,JMON
Se você possuir a autoridade adequada, você poderá emitir estes comandos a partir do SDSF, entretanto, os comandos deverão ser precedidos por uma barra ('/'). Consulte MVS System Commands (SA22-7627) para obter informações adicionais sobre os comandos do console.
O ID do usuário designado ao servidor do JES Job Monitor precisa de acesso de LEITURA à biblioteca de carregamento do Developer for System z: hlq.SFEKLOAD.
Inicie o job ou a STC do usuário definida nas etapas acima. Se a tarefa terminar com o código de retorno 66, então hlq.SFEKLOAD não será autorizado por APF.
Para permitir que os usuários executem operações por meio do JES Job Monitor, é necessário conceder a eles autoridade de acesso à classe OPERCMDS. Isto pode ser realizado condicionalmente, para que os direitos de acesso dos usuários tenham efeito somente quando eles estiverem utilizando o JES Job Monitor. Para utilizar esta verificação de acesso condicional, você deve ter a classe CONSOLE ativa e um console definido chamado JMON (JMON é o único nome válido).
Por exemplo, o administrador de segurança emitiria os seguintes comandos RACF:
1. SETROPTS CLASSACT(CONSOLE) 2. RDEFINE CONSOLE JMON UACC(READ) 3. SETROPTS RACLIST(CONSOLE) REFRESH
Utilize os seguintes comandos RACF para permitir que os usuários emitam comandos do JES2 somente por meio do JES Job Monitor, em que id é o ID do usuário ou ID do grupo de usuários do Developer for 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
O JES Job Monitor não oferece aos usuários do Developer for System z acesso total ao spool do JES. Apenas os comandos listados em Tabela 5 estão disponíveis. Os comandos são emitidos selecionando a opção apropriado na estrutura de menus do cliente (sem prompt de comandos). O escopo dos comandos é limitado pelas técnicas descritas a seguir.
Comando | JES2 | JES3 |
---|---|---|
Suspender | $Hjobid | *F,J=jobid,H |
Liberação | $Ajobid | *F,J=jobid,R |
Cancelar | $Cjobid | *F,J=jobid,C |
Limpar | $Cjobid,P | *F,J=jobid,C |
Sem autorização para esses comandos do console, os usuários ainda poderão enviar tarefas e ler a saída da tarefa, se tiverem recebido autorização de acesso aos arquivos do spool.
Para limitar os usuários aos seus próprios jobs no spool do JES, defina a instrução "LIMIT_VIEW=USERID" no arquivo de configuração JES Job Monitor (FEJJCNFG). Se precisarem de acesso a uma maior quantidade de jobs, mas não todos, utilize os recursos padrão de proteção de arquivos do spool do produto de segurança, como a classe JESSPOOL no RACF.
Ao definir a proteção adicional, tenha em mente que o JES Job Monitor utiliza a SAPI (SYSOUT application program interface) para acessar o spool. Isto significa que o usuário precisa, pelo menos, do acesso UPDATE aos arquivos do spool, mesmo para a funcionalidade de procura. Este requisito não é aplicado se você executa o z/OS v1.7 (z/OS 1.8 para JES3) ou posterior. Aqui, a permissão de LEITURA é suficiente para a funcionalidade de procura.
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre a proteção de arquivos do spool do JES.
O Developer for System z fornece procedimentos JCL de amostra que podem ser utilizados para a geração do JCL, construções remotas de projetos e recursos de verificação de sintaxe remota dos mapas BMS do CICS, telas IMS MFS e programas COBOL, PL/I, Assembler, C e C/C++.
Estes procedimentos permitem que as instalações apliquem seus próprios padrões. Isto também assegurará que os desenvolvedores utilizem os mesmos procedimentos com as mesmas opções e níveis do compilador.
O SMP/E instala estes procedimentos JCL de amostra no hlq.SFEKSAMP. Se planeja utilizar esses procedimentos, você deve:
Os procedimentos de amostra a serem copiados e customizados estão listados na Tabela 6.
Se os procedimentos ELAXF* não puderem ser copiados para uma biblioteca de procedimentos de sistema, copie-os para uma biblioteca privada e solicite aos usuários do Developer for System z a inclusão de uma placa JCLLIB (logo após a placa JOB) nas propriedades da tarefa no cliente. Não customize o JCL de amostra no conjunto de dados de instalação, uma vez que a manutenção pode substituir esses membros e desfazer as customizações.
//MYJOB JOB <parâmetros_da_tarefa> //PROCS JCLLIB ORDER=(hlq.SFEKSAMP)
Os nomes dos procedimentos e os nomes das etapas nos procedimentos correspondem às propriedades padrão que são enviadas com o cliente. Se você decidir alterar o nome do procedimento ou o nome de uma etapa em um procedimento, o arquivo de propriedades correspondente no cliente também deverá ser atualizado. É recomendável que você não altere os nomes dos procedimentos e das etapas.
Membro | Objetivo |
---|---|
ELAXFADT | Procedimento de amostra para montagem e depuração de programas assembler de Alto Nível. |
ELAXFASM | Procedimento de amostra para montagem de programas assembler de alto nível. |
ELAXFBMS | Procedimento de amostra para criação do objeto BMS do CICS e a cópia correspondente, dsect, ou incluir membro. |
ELAXFCOC | Procedimento de amostra para realizar compilações COBOL, conversão do CICS integrado e conversão do DB2 integrado. |
ELAXFCOP | Procedimento de amostra para realizar o pré-processamento DB2 das instruções EXEC de SQL incorporadas em programas COBOL. |
ELAXFCOT | Procedimento de amostra para realizar a conversão do CICS de instruções EXEC CICS incorporadas nos programas COBOL. |
ELAXFCPC | Procedimento de amostra para realizar compilações C. |
ELAXFCPP | Procedimento de amostra para realizar compilações C++. |
ELAXFGO | Procedimento de amostra para a etapa IR. |
ELAXFLNK | Procedimento de amostra para vincular os programas assembler C/C++, COBOL, PLI e de Alto Nível. |
ELAXFMFS | Procedimento de amostra para criar telas IMS MFS. |
ELAXFPLP | Procedimento de amostra para realizar o pré-processamento DB2 de instruções EXEC de SQL incorporadas nos programas PLI. |
ELAXFPLT | Procedimento de amostra para realizar a conversão do CICS das instruções EXEC CICS incorporadas nos programas PLI. |
ELAXFPL1 | Procedimento de amostra para realizar compilações PL/I, conversão do CICS integrado e conversão do DB2 integrado. |
ELAXFUOP | Procedimento de amostra para a geração da etapa UOPT ao construir programas que executam nos subsistemas CICS ou IMS. |
A definição da transação APPC tornou-se opcional na versão 7.1. Por padrão, o Developer for System z agora utiliza o SCLM Developer Toolkit para fornecer o serviço Comandos do TSO. A configuração disso é feita em rsed.envvars, descrita em Customizar rsed.envvars, o Arquivo de Configuração para RSE.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
O serviço Comandos do TSO é implementado como um programa de transações APPC, FEKFRSRV e deve ser ativado para que as conexões do Developer for System z sejam bem-sucedidas entre o host e o cliente. O FEKFRSRV atua como um servidor host para a execução de comandos do TSO que são emitidos a partir da estação de trabalho via TCP/IP. A APPC não é requerida na estação de trabalho porque a estação de trabalho se comunica com o FEKFRSRV via TCP/IP. Cada estação de trabalho pode ter uma conexão ativa para vários hosts ao mesmo tempo.
/* REXX -- administração APPC utilizando painéis 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
Experiência | Informações necessárias:
|
Valor |
---|---|---|
APPC | Nome do conjunto de dados de TPDATA
|
|
APPC | Nome da transação a ser utilizada (talvez não exista)
|
|
APPC | Classe de transação APPC a ser utilizada
|
|
WLM/SRM | Grupo e domínio de desempenho do TSO
|
|
RACF | Cada usuário do Developer for System z possui acesso a um
segmento OMVS (isto é necessário)
|
|
RACF | Cada usuário do Developer for System z deve ter acesso de LEITURA ao hlq.SFEKPROC(FEKFRSRV)
|
Consulte MVS Planning: Workload Management (SA22-7602) para obter informações adicionais sobre o gerenciamento do WLM/SRM. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter mais informações sobre segmentos OMVS e perfis de proteção de conjuntos de dados.
O programador do sistema ou administrador APPC precisa executar as seguintes etapas para configurar o recurso de comando:
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
A customização a seguir é necessária para incorporar a amostra do procedimento armazenado do DB2 (Stored Procedure Builder para PL/I e COBOL) em seu sistema. Você necessitará da assistência de um administrador WLM e um administrador DB2 para realizar estas tarefas.
Após a aplicação de SMP/E, a biblioteca de amostra hlq.SFEKSAMP e a biblioteca de procedimentos hlq.SFEKPROC contêm os membros do procedimento armazenado do DB2 listados na Tabela 8.
Membro | Objetivo |
---|---|
hlq.SFEKSAMP(ELAXMJCL) | JCL de amostra para definição do Stored Procedure Builder para PL/I e COBOL para DB2. |
hlq.SFEKSAMP(ELAXMSAM) | Procedimento JCL de amostra do espaço de endereços WLM para o Stored Procedure Builder para PL/I e COBOL. |
hlq.SFEKPROC(ELAXMREX) | Código REXX para o Stored Procedure Builder para PL/I e COBOL. |
O componente EST (Enterprise Service Tools) do Developer for System z suporta formatos diferentes das mensagens de interface em árabe e hebraico, assim como a apresentação de dados bidirecionais e a edição em todos os editores e visualizações. Em aplicativos terminais, telas da esquerda para a direita e da direita para a esquerda são suportadas, assim como campos numéricos e campos com orientação oposta à tela.
A funcionalidade e os recursos bidirecionais adicionais incluem:
Você precisará de assistência do administrador CICS para realizar as seguintes tarefas:
As transformações bidirecionais do EST são realizadas no ambiente CICS SFR (Service Flow Runtime) pelo módulo FEJBDTRX. O módulo FEJBDTRX é chamado quando são necessárias conversões bidirecionais no código gerado pelo EST (quando mapeado, é gerado entre os campos nas mensagens que possuem atributos bidirecionais diferentes.)
Se a instalação automática estiver configurada como autoINactive, defina o programa FEJBDTRX como CICS, utilizando o comando CEDA, por exemplo:
CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Além disso, o código gerado pelo EST pode suportar a transformação bidi em ambientes diferentes do CICS SFR (por exemplo, aplicativos em lote). Você pode fazer com que os geradores EST incluam chamadas nas rotinas de conversão bidirecional especificando as opções de transformação bidi apropriadas nos assistentes de geração EST e vinculando os programas gerados com a biblioteca de conversão bidirecional apropriada, hlq.SFEKLOAD.
O ADM (Application Deployment Manager) fornece uma abordagem de implementação comum e API de implementação para todos os componentes do Developer for System z.
Além disso, o ADM fornece um cliente e servidor (baseado em host) do CRD (CICS Resource Definition), que fornece as seguintes funções:
O Developer for System z fornece três transações que são utilizadas pelo servidor CRD ao definir e consultar recursos do CICS. O código-fonte COBOL de amostra é fornecido para permitir customizações específicas do site.
Consulte o IBM Rational Developer para System z Application Deployment Manager User's Guide (SC31-6972) para obter mais informações sobre o ADM.
As etapas de customização a seguir são necessárias para ativar o servidor CRD.
Antes de instalar a versão 7.1, se você for um usuário anterior do servidor CRD, é recomendável salvar a customização relacionada, conforme descrito em Fazendo Backup de Arquivos Configurados Anteriormente.
Copie os membros a serem customizados do diretório de instalação para uma biblioteca pessoal e customize estas cópias para evitar que sejam sobrescritas ao realizar manutenção:
opcional (Manipulador de Mensagem de Pipeline)
opcional (atualização CSD para regiões não-primárias)
Customize e envie a tarefa ADNVSAM para alocar e inicializar o arquivo VSAM do repositório do servidor CRD. Consulte a documentação em ADNVSAM para obter instruções de customização.
É aconselhável criar um repositório separado para cada região de conexão primária do CICS. O compartilhamento do repositório implica que todas as regiões relacionadas ao CICS utilizarão os mesmos valores armazenados no repositório e que vários espaços de endereço serão gravados no VSAM, que deve ser configurado corretamente para isso.
O servidor CRD deve ser definido para a região de conexão primária. Essa é a região que processará pedidos de Serviço da Web do Developer for System z.
CEDA INSTALL GROUP(ADNPCRGP)
O manipulador de mensagem de pipeline (ADNTMSGH) é utilizado para processamento do ID do usuário e senha no cabeçalho SOAP. ADNTMSGH é mencionado no arquivo de configuração de pipeline e, portanto, deve ser colocado na concatenação RPL do CICS. ADNTMSGH também é utilizado para definir o ID da transação como ADMD, ADMR ou ADMI, dependendo da operação solicitada. É possível customizar ADNTMSGH para utilizar IDs de transação diferentes.
Utilizando o padrão:
Customizando ADNTMSGH:
O servidor CRD também pode ser utilizado com uma ou mais regiões de conexão não-primárias, que geralmente são AORs (Application Owning Regions).
CEDA INSTALL GROUP(ADNARRGP)
Antes de instalar a versão 7.1, se você for um usuário anterior do WebSphere Developer for System z (FMID: HHOP700), é recomendável salvar a customização relacionada, descrita e Fazendo Backup de Arquivos Configurados Anteriormente.
Se não estiver familiarizado com o z/OS UNIX, é aconselhável solicitar assistência de um administrador z/OS UNIX ou outro administrador UNIX experiente para desempenhar as tarefas listadas neste capítulo.
Os comandos z/OS UNIX necessários para desempenhar as tarefas listadas são brevemente descritos para sua conveniência. A menos que observado de outra forma, consulte UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre estes comandos.
As tarefas descritas abaixo esperam que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Utilize o comando exit para retornar ao TSO.
O MVS fornece a possibilidade de editar arquivos z/OS UNIX utilizando o ISPF por meio do comando OEDIT. Este comando pode ser utilizado no TSO e no OMVS.
A maioria dos arquivos z/OS UNIX possui a permissão de gravação restrita ao proprietário do arquivo. Essa restrição pode ser ignorada de várias maneiras.
Isso não é recomendado para IDs de usuário "humanos", pois não há restrições relacionadas ao z/OS UNIX.
Permite que o usuário se torne o UID 0 por meio do comando su. Essa é a configuração recomendada.
Permite que o usuário leia/grave qualquer arquivo e leia ou procure qualquer diretório. O acesso de CONTROLE (ou superior) a esse perfil de segurança inclui gravação em qualquer diretório à lista de permissões
.Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre a segurança do z/OS UNIX.
Todas as instruções de caminho /usr/lpp/wd4z/ neste capítulo se referem ao caminho utilizado durante a instalação do Developer for System z. O padrão é /usr/lpp/wd4z/, mas isto pode não se aplicar ao seu site.
Você pode testar sua configuração TCP/IP com o comando HOMETEST do TSO. Communications Server: IP System Administrator's Commands (SC31-8781) para obter mais informações sobre esse comando.
Você pode localizar as seguintes publicações úteis sobre noções do z/OS UNIX:
É recomendável copiar o arquivo /usr/lpp/wd4z/rse/lib/rsed.envvars para um novo diretório (tal como o /etc/wd4z/) e customizar a cópia para evitar sobrescrever sua customização ao aplicar a manutenção. Porém, ao fazer isto, você também deve copiar os seguintes arquivos do diretório de instalação (o padrão é /usr/lpp/wd4z/rse/lib/) para o novo local:
Os arquivos listados em Tabela 8 devem ser copiados também se você planeja utilizar os recursos opcionais que fazem parte de:
arquivo | definição |
---|---|
projectcfg.properties | Projetos Baseados em Host
Consulte (Opcional) Customizar projectcfg.properties, Configuração de Projetos do Host |
FMIEXT.properties | Integração do File Manager
Consulte (Opcional) Customizar FMIEXT.properties, Integração do File Manager |
CRASRV.properties | CARMA
Consulte (Opcional) Ativando o IBM CARMA |
Os seguintes comandos de amostra,
crie um diretório chamado /etc/rd4z e copie rsed.envvars do diretório atual para /etc/rd4z. Repita o comando de cópia para os arquivos restantes.
O resultado da cópia pode ser verificado com o comando ls /etc/wd4z, que deve apresentar uma saída semelhante a esta ($ é o prompt do 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 os métodos de conexão do cliente do Developer for System z utilizam as variáveis configuradas no arquivo rsed.envvars, localizado por padrão no diretório de instalação /usr/lpp/wd4z/rse/lib/, mas poderia ser copiado para outro diretório na etapa anterior. O arquivo de amostra fornecido possui as instruções listadas em Figura 4, nas quais as linhas de comentário iniciam com um sinal de libras (#).
#============================================================= # (1) customizações necessárias 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) customizações necessárias se SCLMDT for utilizado _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) customizações opcionais #_RSE_PORTRANGE=8108-8118 #_FEKFLOCK_USERID_=user_id #_FEKFLOCK_JOBNAME_=job_name #_FEKFSCMD_TP_NAME_=tp_name #_FEKFSCMD_PARTNER_LU_=lu_name #============================================================= # (4) não altere, a menos que orientado pelo IBM Support Center 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) variáveis de ambiente adicionais
As seguintes definições são requeridas:
Por padrão, o Developer for System z utiliza o SCLM Developer Toolkit para o serviço Comandos do TSO. O APPC é utilizado quando a seguinte opção _RSE_JAVAOPTS está sem comentários:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
As seguintes definições são necessárias se o SCLM Developer Toolkit for utilizado, para o serviço Comandos do TSO ou quando o plug-in SCLMDT é instalado no cliente do Developer for System z.
O Developer for System z utiliza o LINKLIST por padrão para acessar a biblioteca de carregamento do SCLM Developer Toolkit. O STEPLIB é utilizado quando a seguinte diretiva STEPLIB está sem comentários:
STEPLIB=$_CMDSERV_BASE_LOAD
As definições a seguir são opcionais. Se omitido, os valores padrão serão utilizados.
As seguintes definições são necessárias e não devem ser alteradas, a menos que orientado pelo IBM Support Center.
STEPLIB=CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
Essa é uma parte da customização de rsed.envvars que especifica as portas nas quais o servidor RSE pode se comunicar com o cliente. Este intervalo de portas não possui nenhuma conexão com o daemon RSE ou portas REXEC/SSH.
Para ajudar a compreender o uso da porta, segue uma breve descrição do processo de conexão do RSE:
Para especificar o intervalo de portas, para o cliente se comunicar com o z/OS, remova o comentário e altere a seguinte linha no rsed.envvars:
#_RSE_PORTRANGE=8108-8118
O formato de PORTRANGE é: _RSE_PORTRANGE=min-max (max não está incluso; por ex., _RSE_PORTRANGE=8108-8118 significa que os números de portas de 8108 até 8117 são utilizáveis). O número da porta utilizado pelo servidor RSE é determinado na seguinte ordem:
Com as diferentes diretivas _RSE_*OPTS, rsed.envvars oferece a possibilidade de fornecer parâmetros adicionais para Java quando ele inicia o servidor RSE.
As opções de amostra incluídas em rsed.envvars podem ser ativadas pela remoção dos comentários.
O Developer for System z depende do serviço do INETD para iniciar o Servidor do RSE (Remote Systems Explorer) quando um cliente solicita uma conexão. O INETD é um daemon z/OS UNIX padrão, que gerencia outros daemons que realizam o trabalho real (nesse caso, começando com o servidor RSE). A configuração do INETD não faz parte da customização do Developer for System z, mas informações importantes podem ser encontradas em Apêndice D. Configurando o INETD.
O Developer for System z suporta várias formas de iniciar o servidor RSE.
É necessário customizar pelo menos uma forma, dependendo de como os usuários planejam operar.
Você pode verificar que o INETD está ativo com o comando ps -e (fornecido por um usuário autorizado). A saída deve conter uma referência ao INETD, por exemplo (# é o prompt do z/OS UNIX):
# ps -e PID TTY TIME CMD 7 ? 0:00 /usr/sbin/inetd
rse 4035/tcp #Developer for System z RSE
A porta utilizada deve corresponder com a porta definida no cliente, a qual é configurada durante a criação de uma nova conexão do z/OS.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /usr/lpp/wd4z/rse/lib -t 60
Tudo após este argumento INETD são argumentos do servidor, iniciando com o nome do servidor.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z
As definições a seguir são opcionais. Se omitido, os valores padrão serão utilizados.
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 Listen
ICH408I USER(IBMUSER ) GROUP(SYS1 ) NAME(IBMUSER ) BPX.DAEMON CL(FACILITY) INSUFFICIENT ACCESS AUTHORITY ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
Não existe nenhuma configuração específica do Developer for System z para utilização do servidor de Comandos INETD REXEC (ou SSH). Entretanto, o cliente precisa conhecer 2 valores para iniciar uma conexão RSE por meio do REXEC/SSH:
Por padrão, esse é o diretório de instalação (/usr/lpp/wd4z/rse/lib/). Entretanto, server.zseries é um dos arquivos que também devem ser copiados se rsed.envvars for copiado para um diretório diferente, como /etc/wd4z/.
Uma porta comum utilizada pelo REXEC é 512. Uma forma rápida de verificar que esse é o comando NETSTAT, conforme mostrado na amostra a seguir ($ é o prompt do z/OS UNIX):
$ netstat | grep 512 INETD4 0000002E 0.0.0.0..512 0.0.0.0..0 Listen
Para verificar isso, você pode verificar os serviços /etc/inetd.conf e /etc/services para localizar o número de porta utilizado.
exec stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV
exec 512/tcp #REXEC Command Server
O mesmo princípio aplica-se ao SSH. Sua porta comum é 22, e o nome do servidor é sshd.
Essa etapa é necessária apenas ao utilizar o SCLM Developer Toolkit para o serviço Comandos do TSO (esse é o padrão). Não é necessária ao utilizar o APPC para o serviço Comandos do TSO.
O SCLM Developer Toolkit requer as definições em ISPF.conf para criar um ambiente válido para execução de serviços do ISPF. O serviço Comandos do TSO deve ser incluído para esse ambiente do ISPF.
ISPF.conf é criado durante a customização do SCLM Developer Toolkit, descrita no SCLM Developer Toolkit Installation and Customization Guide (SC23-8504). O local padrão é /etc/SCLMDT/CONFIG, mas isso pode não se aplicar ao seu site.
Inclua as seguintes linhas em ISPF.conf, em que hlq é igual ao qualificador de alto nível utilizado para instalar o Developer for System z (FEK padrão).
********************************************** * Servidor de Comandos do TSO do Developer for System z - ********************************************** sysexec=hlq.SFEKPROC
O resultado deve ser semelhante à amostra em Figura 5.
sysproc=ISP.SISPCLIB ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=BWB.SBWBLOAD ********************************************** * Servidor de Comandos do TSO do Developer for System z - ********************************************** sysexec=FEK.SFEKPROC
A instalação do Developer for System z oferece diversos IVPs (Installation Verification Programs) para o servidor RSE. Os scripts do IVP estão localizados no diretório de instalação padrão /usr/lpp/wd4z/rse/lib/.
Todos os comandos de amostra nesta seção esperam que as variáveis de ambiente do RSE estejam configuradas. Dessa forma, os scripts do IVP estão disponíveis por meio da instrução PATH e o local de rsed.envvars é conhecido. Utilize os comandos pwd e cd para verificar e alterar o diretório atual para o diretório com o rsed.envvars customizado. O script de shell setup.env.zseries pode, então, ser utilizado para definir as variáveis de ambiente do RSE, como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ pwd /etc $ cd /etc/wd4z $ . ./setup.env.zseries
O script de shell ../setup.env.zseries, que reside no mesmo diretório que rsed.envvars, exporta as variáveis de ambiente para que outros processos possam utilizá-las. O primeiro "." (ponto) em . ./setup.env.zseries é um comando z/OS UNIX para executar o shell no ambiente atual, para que as variáveis de ambiente configuradas no shell sejam efetivas mesmo após a saída do shell. O segundo ponto está relacionado ao diretório atual.
/usr/lpp/wd4z/rse/lib/fekfivpr 512 USERID
$ echo $STEPLIB none $ STEPLIB=TCPIP.SEZALOAD
ou
$ echo $STEPLIB SOME.STEPLIB.DATASET 1$ STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Para obter informações sobre o diagnóstico de problemas de conexão do RSE, consulte Apêndice B. Resolvendo Problemas de Configuração ou as notas técnicas sobre a Página de Suporte do Developer for System z em http://www-306.ibm.com/software/awdtools/devzseries/support/.
A disponibilidade da porta daemon do JES Job Monitor, REXEC, SSH e do RSE pode ser verificada emitindo o comando netstat. O resultado deve mostrar as portas utilizadas por esses serviços, como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ netstat MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 13:57:36 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- INETD4 00000030 0.0.0.0..22 0.0.0.0..0 Listen INETD4 00000030 0.0.0.0..512 0.0.0.0..0 Listen INETD4 00000030 0.0.0.0..4035 0.0.0.0..0 Listen JMON 00000030 0.0.0.0..6715 0.0.0.0..0 Listen
Para verificar a conexão REXEC, execute o seguinte comando. Substitua 512 pela porta utilizada pelo REXEC e USERID por um ID de usuário válido.
fekfivpr 512 USERID
Depois de solicitar uma senha, o comando deve retornar o rastreio REXEC, um aviso de tempo limite, a versão Java e a mensagem do servidor RSE, como na amostra a seguir, ($ é o prompt do z/OS UNIX):
$ fekfivpr 512 USERID Digite a Senha: $ EZYRC01I Chamando a função rexec_af com o seguinte: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/wd4z;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Data socket = 4, Control socket = 6. espera ver mensagens de tempo limite após um teste de IVP bem-sucedido 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 ativado) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Servidor Iniciado com Êxito 1272 Servidor executando em: 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. ...
Esse teste de IVP pode ser ignorado se o teste anterior, descrito em Conexão REXEC, for concluído com êxito.
Verifique se o script de shell utilizado pela conexão REXEC e SSH, executando o seguinte comando:
fekfivps
O comando deve retornar um aviso de tempo limite, a versão Java e a mensagem do servidor RSE, como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ fekfivps $ java version "1.5.0" espera ver mensagens de tempo limite após um teste de IVP bem-sucedido 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 ativado) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Servidor Iniciado com Êxito 1751 Servidor executando em: 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. ...
Para verificar a conexão do daemon RSE, execute o seguinte comando. Substitua 4035 pela porta utilizada pelo daemon RSE e USERID por um ID de usuário válido.
fekfivpd 4035 USERID
Depois de solicitar uma senha, o comando deve retornar uma saída como nesta amostra ($ é o prompt do z/OS UNIX):
$ fekfivpd 4035 USERID Senha: SSL está desativado conectado 8108 570655399 Bem-sucedido
Para verificar a conexão do JES Job Monitor, execute o seguinte comando. Substitua 6715 pelo número da porta do JES Job Monitor.
fekfivpj 6715
O comando deve retornar a mensagem de confirmação do JES Job Monitor, como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ fekfivpj 6715 Aguardando resposta do JES Job Monitor... ACKNOWLEDGE01v03 Bem-sucedido
Este teste de IVP só é necessário se você utilizar o SCLM Developer Toolkit, para o serviço Comandos do TSO ou para o plug-in do cliente.
Verifique a conexão com o servidor de Comandos do TSO, utilizando o SCLM Developer, executando o comando a seguir.
fekfivpc
O comando deve retornar o resultado de verificações relacionadas ao SCLM Developer Toolkit (variáveis, módulos HFS, tempo de execução REXX, iniciando e parando a sessão do TSO/ISPF), como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ fekfivpc ------------------------------------------------------------- Verificação de instalação do host para o RSE Verifique as mensagens de log do IVP do HOST a seguir: ------------------------------------------------------------- Conexão RSE e verificação apenas de inicialização da sessão TSO/ISPF base *** VERIFICAR: VARIÁVEIS DE AMBIENTE - variável de ambiente exibidas a seguir: PATH do Servidor = /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 ------------------------------------------------------------- *** CHECK : HFS MODULES Verificando o diretório de instalação: /usr/lpp/SCLMDT Verificando os módulos BWB no diretório /bin RC=0 MSG: BEM-SUCEDIDO ------------------------------------------------------------- *** VERIFICAR: AMBIENTE DE TEMPO DE EXECUÇÃO DO REXX RC=0 MSG: BEM-SUCEDIDO ------------------------------------------------------------- *** VERIFICAR: INICIALIZAÇÃO DO TSO/ISPF (A sessão do TSO/ISPF será inicializada) RC=0 MSG: BEM-SUCEDIDO ------------------------------------------------------------- *** VERIFICAR: Encerrando a sessão IVP do TSO/ISPF RC=0 MSG: BEM-SUCEDIDO ------------------------------------------------------------- Verificação da instalação do host concluída com êxito -------------------------------------------------------------
fekfivpc possui muitos parâmetros opcionais e não-posicionais:
Não execute este procedimento se não tiver configurado o APPC para o serviço Comandos do TSO.
Verifique a conexão com o servidor de Comandos do TSO (utilizando o APPC), executando o comando a seguir. Substitua USERID por um ID de usuário válido.
./fekfivpa USERID
Depois de solicitar uma senha, o comando deve retornar a conversação do APPC, como na amostra a seguir ($ é o prompt do z/OS UNIX):
$ fekfivpa USERID Digite a Senha: 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 obter informações sobre o diagnóstico de problemas de conexão do RSE, consulte Apêndice B. Resolvendo Problemas de Configuração ou as notas técnicas sobre a Página de Suporte do Developer for System z, em http://www-306.ibm.com/software/awdtools/devzseries/support/.
Todos os métodos de conexão do cliente do Developer for System z utilizam as variáveis do SSL configuradas no arquivo ssl.properties, localizado por padrão no diretório de instalação /usr/lpp/wd4z/rse/lib/. No entanto, ssl.properties é um dos arquivos que também devem ser copiados se rsed.envvars for copiado para um diretório diferente, como /etc/wd4z/. O arquivo de amostra fornecido possui as instruções listadas em Figura 6, nas quais as linhas de comentário iniciam com um sinal de libras (#).
# Specify this property as true to enable SSL enable_ssl=false ################################### # Daemon Properties # The key database file and password need to be specified for # daemon to use. # The key label need to be specified if not default key. #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= ################################### # Server Properties # The keystore file and password need to be specified for the # server to use. #server_keystore_file= #server_keystore_password=
As propriedades do daemon e do servidor precisarão ser configuradas somente se você ativar o SSL. Consulte Apêndice E. Configurando o SSL para obter mais informações sobre a configuração do SSL.
Todos os métodos de conexão do cliente do Developer for System z utilizam as variáveis configuradas no arquivo rsecomm.properties localizado por padrão no diretório de instalação /usr/lpp/wd4z/rse/lib/. No entanto, rsecomm.properties é um dos arquivos que também devem ser copiados se rsed.envvars for copiado para um diretório diferente, como /etc/wd4z/. O arquivo de amostra fornecido possui as instruções listadas em Figura 7, nas quais as linhas de comentário iniciam com um sinal de libras (#).
# server.version - DO NOT MODIFY! server.version=5.0.0 # Logging level # 0 - Log error messages # 1 - Log error and warning messages # 2 - Log error, warning and info messages # 3 - Log error, warning, info and debug messages debug_level=1 # Log location # Log_To_StdOut # Log_To_File log_location=Log_To_File
Ao selecionar log_location=Log_To_File (o padrão), a criação de log é gravada em home/.eclipse/RSE/USERID/rsecomm.log, em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não tiver um segmento OMVS) e USERID é o ID de usuário de logon (maiúsculas).
Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente ou podem ser definidos centralmente no host e propagados para o cliente com base no usuário. Esses "projetos baseados no host" parecem e funcionam exatamente como os projetos definidos no cliente, exceto pelo fato de suas estruturas, membros e propriedades não poderem ser modificadas pelo cliente e serem acessíveis apenas quando conectados ao host.
O local das definições do projeto é definido em projectcfg.properties, localizado por padrão no diretório de instalação /usr/lpp/wd4z/rse/lib/. No entanto, projectcfg.properties é um dos arquivos que também devem ser copiados se rsed.envvars for copiado para um diretório diferente, como /etc/wd4z/.
O arquivo de amostra fornecido possui as instruções listadas em Figura 8, nas quais as linhas de comentário iniciam com um sinal de libras (#).
# # Projetos baseados em host - arquivo de configuração raiz # # WSED-VERSION - não modifique! WSED-VERSION=7.0.0.0 # especifique o local dos arquivos de definição do projeto baseado em host PROJECT-HOME=/var/wd4z/projects
A única variável a ser alterada é PROJECT-HOME. Seu valor padrão /var/wd4z/projects é o diretório de base para as definições de projetos.
Para obter mais informações sobre projetos baseados em host, consulte o white paper Host Based Projects in WebSphere Developer for System z version 7.0 na biblioteca da Internet do Developer for System z http://www-306.ibm.com/software/awdtools/devzseries/library/
O Developer for System z suporta acesso direto do cliente a um conjunto limitado de funções do IBM File Manager para z/OS. O IBM File Manager para z/OS oferece ferramentas abrangentes para trabalhar com conjuntos de dados do MVS, arquivos z/OS UNIX, dados do DB2, IMS e CICS. Essas ferramentas incluem os utilitários familiares de procura, edição, cópia e impressão localizados no ISPF, aprimoradas para atender às necessidades de desenvolvedores de aplicativos. Na versão atual do Developer for System z, apenas a procura/edição de conjuntos de dados do MVS (incluindo VSAM KSDS e ESDS) é suportada.
Observe que o produto IBM File Manager para z/OS deve ser solicitado, instalado e configurado separadamente. Consulte IBM Rational Developer para System z Host Planning Guide (GI11-8296-00) para saber qual nível do File Manager é necessário para sua versão do Developer for System z. A instalação e customização deste produto não está descrita neste manual.
As definições do File Manager necessárias pelo Developer for System z são armazenadas em FMIEXT.properties, localizado por padrão no diretório de instalação /usr/lpp/wd4z/rse/lib/. No entanto, FMIEXT.properties é um dos arquivos que também devem ser copiados se rsed.envvars for copiado para um diretório diferente, como /etc/wd4z/.
O arquivo de amostra fornecido possui as instruções listadas em Figura 9, nas quais as linhas de comentário iniciam com um sinal de libras (#).
# Propriedades de Extensão do FMI (File Manager Integration) # startup.script=/usr/lpp/wd4z/rse/lib/fmiSub startup.port=1957 startup.range=100 startup.fmload=FMN.SFMNMOD1 startup.jobcard1=//JOBCARD JOB <parâmetros da tarefa> startup.jobcard2=//* startup.jobcard3=//* startup.sysout=*
O CARMA (FMID: HCMA710) é um auxílio de produtividade para desenvolvedores criando APIs para SCMs (Software Configuration Managers). Por sua vez, essas APIs podem ser utilizadas por aplicativos (por exemplo, Developer for System z) para acessar os SCMs.
Antes de instalar a versão 7.1, se você for um usuário anterior do CARMA, é recomendável salvar a customização relacionada, conforme descrito em Fazendo Backup de Arquivos Configurados Anteriormente.
Após a instalação, você deve configurar o CARMA seguindo estas etapas:
Consulte Tabela 1 para obter uma lista de manuais que oferecem mais informações sobre o CARMA e como utilizá-lo.
O usuário pode controlar a quantidade de informações de rastreio que o CARMA gera, configurando o Nível de Rastreio na guia de propriedades da conexão CARMA no cliente. As opções para o Nível de Rastreio são:
O valor padrão é
Log de Erros
. Consulte Localização dos Arquivos de Log para obter informações adicionais sobre as localizações do arquivo de log.
Todas as referências a hlq nesta seção referem-se ao qualificador de alto nível utilizado durante a instalação do CARMA. O padrão da instalação é CRA, mas isto pode não se aplicar ao seu site.
Siga estas etapas para configurar o host MVS:
Se não estiver familiarizado com o z/OS UNIX, é aconselhável solicitar assistência de um administrador z/OS UNIX ou outro administrador UNIX experiente para desempenhar as tarefas listadas nesta seção.
Os comandos z/OS UNIX necessários para desempenhar as tarefas listadas são brevemente descritos para sua conveniência. A menos que observado de outra forma, consulte UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre estes comandos.
Todas as instruções de caminho /usr/lpp/wd4z/ neste capítulo se referem ao caminho utilizado durante a instalação do Developer for System z, não ao CARMA. O padrão é /usr/lpp/wd4z/, mas isto pode não se aplicar ao seu site.
Siga estas etapas para configurar os componentes do z/OS UNIX CARMA, que são instalados durante a instalação do IBM Rational Developer para System z (FMID: HHOP710):
cp /usr/lpp/wd4z/rse/lib/CRASRV.properties /etc/wd4z
# Opção de configuração CARMA # port.start=5227 port.range=100 startup.script.name=/usr/lpp/wd4z/rse/lib/rexxsub clist.dsname='hlq.SCRACLST(CRASUBMT)'
Os RAMs (Repository Access Managers) são APIs escritas pelo usuário para fazer interface com os z/OS SCMs (Software Configuration Managers). Siga as instruções nas seções abaixo para as RAMs de amostra que você deseja ativar.
Consulte o IBM Rational Developer para System z Common Access Repository Manager Developer's Guide (SC23-7660-00) para obter mais informações sobre RAMs de amostra e sobre o código-fonte de amostra fornecido.
O IBM SCLM (Software Configuration and Library Manager) (FMID: HSD3310) Developer Toolkit fornece as ferramentas necessárias para estender as capacidades do SCLM para o cliente. O SCLM por si só é um gerenciador de código-fonte com base no host enviado como parte do ISPF.
O SCLM Developer Toolkit, fornecido junto com o Developer for System z, é um plug-in com base no Eclipse que faz a interface com o SCLM e fornece acesso a todos os processos SCLM para o desenvolvimento de códigos antigos, assim como o suporte para implementação completa do Java e do J2EE na estação de trabalho com sincronização com o SCLM no mainframe, incluindo construção, montagem e implementação do código J2EE do mainframe.
Consulte Tabela 1 para obter uma lista de manuais que oferecem mais informações sobre o SCLM Developers Toolkit e como utilizá-lo.
Os usuários do cliente do Developer for System z devem conhecer o resultado de determinadas customizações do host, como os números de portas TCP/IP, para que o cliente funcione corretamente. Utilize a lista de verificação na Tabela 10 para coletar as informações necessárias.
Customização | Valor |
---|---|
Número da porta do servidor do JES Job Monitor (padrão 6715):
Consulte SERV_PORT em Customizar o FEJJCNFG, o Arquivo de Configuração do JES Job Monitor . |
|
Local dos procedimentos de ELAXF* se não estiverem em uma
biblioteca de procedimentos do sistema:
Consulte a nota sobre JCLLIB em Customizar ELAXF*, Procedimentos de Construção Remota. |
|
Nomes de procedimentos e/ou de etapas de procedimentos de ELAXF*,
se tiverem sido alterados:
Consulte a nota sobre a alteração deles em Customizar ELAXF*, Procedimentos de Construção Remota. |
|
Nome do procedimento armazenado do DB2 (padrão ELAXMSAM):
Consulte informações sobre procedimentos armazenados do DB2 no Apêndice A. Executando Várias Instâncias do Developer for System z. |
|
Local do procedimento armazenado do DB2, se não estiver em uma biblioteca de
procedimentos do sistema:
Consulte o (Opcional) Customizar ELAXM*, Membros do Procedimento Armazenado do DB2. |
|
Utilize o método de conexão DAEMON, REXEC ou SSH para RSE: | |
Número da porta TCP/IP do daemon RSE (padrão 4035):
Consulte o Configuração do Daemon INETD RSE. |
|
Caminho para o script de shell server.zseries para
REXEC/SSH (padrão /usr/lpp/wd4z/rse/lib, recomendável /etc/wd4z):
Consulte o Configuração do INETD REXEC (ou SSH). |
|
Número da porta REXEC ou SSH (padrão 512 ou 22, respectivamente):
Consulte o Configuração do INETD REXEC (ou SSH). Nota:
Ações remotas (baseadas em host) para subprojetos do z/OS UNIX requerem que o REXEC ou o
SSH esteja ativo no host. |
|
Local do JCL CRA#ASLM para alocações do conjunto de dados
CARMA SCLM RAM:
Consulte a nota sobre CRA#ASLM em Ativando o RAM do SCLM. |
O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas alterações que podem ser feitas para aprimorar o desempenho do Developer for System z.
Consulte o MVS Initialization and Tuning Guide (SA22-7591) e UNIX System Services Planning (GA22-7800) para obter mais informações sobre o ajuste do sistema.
Cada processo do z/OS UNIX que possui um STEPLIB que é propagado do pai para o filho ou em um executável consumirá aproximadamente 200 bytes de ECSA (Extended Common Storage Area). Se nenhuma variável de ambiente STEPLIB estiver definida ou quando for definida como STEPLIB=CURRENT, o z/OS UNIX propaga todas as alocações TASKLIB, STEPLIB e JOBLIB ativas atualmente durante uma função fork(), spawn() ou exec(). O servidor RSE inicia diversos processos, e cada conexão do cliente possui um servidor RSE privado. Por isso, os números podem aumentar rapidamente.
O Developer for System z possui um padrão de STEPLIB=NONE codificado em rsed.envvars, conforme descrito em Customizar rsed.envvars, o Arquivo de Configuração para RSE. Pelos motivos mencionados acima, é aconselhável não alterar essa diretiva e colocar os conjuntos de dados de destino em LINKLIST ou LPA (Link Pack Area).
Se você utilizar a diretiva STEPLIB, deve verificar o conteúdo de rsed.envvars para saber se a instrução STEPLIB é a primeira ou não.
STEPLIB=NONE STEPLIB=first.steplib.dataset:second.steplib.dataset
STEPLIB=NONE STEPLIB=$STEPLIB:first.steplib.dataset:second.steplib.dataset
Determinadas bibliotecas do sistema e módulos de carregamento são intensamente utilizadas pelo z/OS UNIX e pelas atividades de desenvolvimento do aplicativo. O aprimoramento do acesso, como a inclusão na LPA, pode aprimorar o desempenho do sistema. Consulte a MVS Initialization and Tuning Reference (SC28-1752) para obter mais informações sobre a alteração de membros SYS1.PARMLIB descritos a seguir.
Quando programas C (incluindo o shell do z/OS UNIX) são executados, freqüentemente utilizam rotinas da biblioteca de tempo de execução do LE (Language Environment). Em média, aproximadamente 4 MB da biblioteca de tempo de execução são carregados na memória para cada espaço de endereço executando um programa ativado para LE e copiados em cada fork.
O conjunto de dados CEE.SCEELPA contém um subconjunto das rotinas de tempo de execução do LE, intensamente utilizadas pelo z/OS UNIX. É aconselhável incluir esse desempenho no SYS1.PARMLIB(LPALSTxx) para ganho máximo de desempenho. Fazendo isso, os módulos são lidos do disco apenas uma vez e são armazenados em um local compartilhado.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Também é aconselhável colocar as bibliotecas de tempo de execução do LE CEE.SCEERUN e CEE.SCEERUN2 em LINKLIST, incluindo os conjuntos de dados em SYS1.PARMLIB(LNKLSTxx) ou SYS1.PARMLIB(PROGxx). Isso elimina o código extra STEPLIB do z/OS UNIX e há uma redução de entrada/saída devido ao gerenciamento pelo LLA e VLF, ou produtos semelhantes.
Se você decidir não colocar essas bibliotecas em LINKLIST, então deve definir a instrução STEPLIB apropriada em rsed.envvars, conforme descrito em Customizar rsed.envvars, o Arquivo de Configuração para RSE. Embora esse método sempre utilize armazenamento virtual adicional, pode aprimorar o desempenho definindo as bibliotecas de tempo de execução do LE para o LLA ou um produto semelhante. Isso reduz a E/S necessária para carregar os módulos.
Em sistemas em que o desenvolvimento do aplicativo seja a atividade principal, o desempenho também pode ser aprimorado se você colocar o editor de vínculo na LPA dinâmica, incluindo essas linhas em SYS1.PARMLIB(PROGxx):
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN) LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
Para desenvolvimento do C/C++, você também pode incluir o conjunto de dados do compilador CBC.SCCNCMP em SYS1.PARMLIB(LPALSTxx).
As instruções acima são amostras de possíveis candidatas de LPA, mas as necessidades no seu site podem variar. Consulte a Language Environment Customization (SA22-7564) para obter informações sobre como colocar outros módulos de carregamento do LE na LPA dinâmica. Consulte UNIX System Services Planning (GA22-7800) para obter mais informações sobre a colocação de módulos de carregamento do compilador C/C++ na LPA dinâmica.
Para aprimorar o desempenho da verificação de segurança realizada para o z/OS UNIX, defina o perfil BPX.SAFFASTPATH na classe FACILITY do software de segurança. Isso reduz o código extra ao realizar verificações de segurança do z/OS UNIX para uma ampla variedade de operações, incluindo verificação de acesso ao arquivo, verificação de acesso ao IPC e verificação de propriedade do processo. Consulte UNIX System Services Planning (GA22-7800) para obter mais informações sobre esse perfil.
A JVM Java Virtual Machine IBM versão 5 e posterior permite compartilhar a auto-inicialização e classes de aplicativo entre JVMs, armazenando-as em um cache na memória compartilhada. O compartilhamento de classe reduz o consumo geral de memória virtual quando mais de uma JVM compartilha um cache. O compartilhamento de classe também reduz o tempo de inicialização para uma JVM após a criação do cache.
O cache da classe compartilhada é independente de qualquer JVM ativa e persiste além da vida útil da JVM que criou o cache. Como o cache da classe compartilhada persiste além da vida útil da JVM, o cache é atualizado dinamicamente para refletir as modificações que podem ter sido feitas nas JARs ou classes no sistema de arquivo.
O código extra para criar e preencher um novo cache é mínimo. O custo de inicialização da JVM em tempo para uma única JVM geralmente é entre 0 e 5% menor, em comparação com um sistema não utilizando o compartilhamento de classe, dependendo de quantas classes são carregadas. O aprimoramento do tempo de inicialização da JVM com um cache preenchido geralmente é entre 10% e 40% mais rápido, em comparação com um sistema não utilizando o compartilhamento de classe, dependendo do sistema operacional e do número de classes carregadas. Várias JVMs em execução simultânea mostrarão benefícios gerais de tempo de inicialização maiores.
Consulte o SDK and Runtime Environment User Guide para aprender mais sobre o compartilhamento de classe.
Para permitir o compartilhamento de classe para o servidor RSE, remova o comentário da diretiva a seguir em rsed.envvars, conforme descrito em (Opcional) Definindo Parâmetros Adicionais de Inicialização Java com _RSE_*OPTS. A primeira instrução define um cache chamado RSE com acesso ao grupo e permite que o servidor RSE seja iniciado, mesmo se o compartilhamento de classe falhar. A segunda instrução é opcional e define o tamanho do cache como 6 megabytes (o padrão do sistema é 16 MB).
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
O tamanho máximo do cache compartilhado teórico é 2 GB. O tamanho do cache que você pode especificar é limitado pela quantidade de memória física e espaço de troca disponível ao sistema. Como o espaço de endereço virtual de um processo é compartilhado entre o cache da classe compartilhada e o heap Java, o aumento do tamanho máximo do heap Java reduzirá o tamanho do cache da classe compartilhada que você pode criar.
O acesso ao cache da classe compartilhada é limitado pelas permissões do sistema operacional e pelas permissões de segurança Java.
Por padrão, os caches de classe são criados com segurança em nível de usuário, portanto só o usuário que criou o cache pode acessá-lo. No z/OS UNIX, há uma opção, groupAccess, que oferece acesso a todos os usuários no grupo principal do usuário que criou o cache. No entanto, independente do nível de acesso utilizado, um cache só pode ser destruído pelo usuário que o criou ou por um usuário root (UID 0).
Consulte o SDK and Runtime Environment User Guide para aprender mais sobre opções adicionais de segurança ao utilizar um Java SecurityManager.
Algumas configurações de SYS1.PARMLIB(BPXPRMxx) afetam o desempenho de classes compartilhadas. A utilização das configurações incorretas pode impedir o funcionamento das classes compartilhadas. Essas configurações também podem ter implicações de desempenho. Para obter mais informações sobre implicações do desempenho e o uso desses parâmetros, consulte MVS Initialization and Tuning Reference (SC28-1752) e UNIX System Services Planning (GA22-7800). Os parâmetros BPXPRMxx mais significantes que afetam a operação de classes compartilhadas são:
Essas configurações afetam a quantidade de páginas da memória compartilhada disponíveis para a JVM. O tamanho da página compartilhada para um serviço do sistema z/OS UNIX é fixado em 4 KB. As classes compartilhadas tentam criar um cache de 16 MB, por padrão. Portanto, defina IPCSHMMPAGES como mais de 4096.
Se você definir um tamanho de cache utilizando -Xscmx, a JVM arredondará o valor para o megabyte mais próximo. Você deve levar isso em consideração ao definir IPCSHMMPAGES no sistema.
Essas configurações afetam a quantidade de semáforos disponíveis aos processos UNIX. As classes compartilhadas utilizam semáforos IPC para comunicação entre as JVMs.
O cache da classe compartilhada requer espaço em disco para armazenar informações de identificação sobre os caches existentes no sistema. Essas informações são armazenadas em /tmp/javasharedresources. Se o diretório de informações de identificação for excluído, a JVM não poderá identificar as classes compartilhadas no sistema e deverá recriar o cache.
O comando da linha Java -Xshareclasses pode utilizar diversas opções, sendo alguns utilitários de gerenciamento do cache. Três deles são mostrados na amostra a seguir ($ é o prompt do z/OS UNIX). Consulte o SDK and Runtime Environment User Guide para obter uma visão geral completa das opções de linha de comandos suportadas.
$ java -Xshareclasses:listAllCaches Cache Compartilhado OS shmid em uso Hora da última desconexão RSE 401412 0 Seg 18 Jun 2007 17h23min16s Não foi possível criar a Java virtual machine. $ java -Xshareclasses:name=RSE,printStats Estatísticas atuais para o cache "RSE": endereço base = 0x0F300058 endereço final = 0x0F8FFFF8 ponteiro de alocação = 0x0F4D2E28 tamanho do cache = 6291368 bytes livres = 4355696 bytes ROMClass = 1912272 bytes de metadados = 23400 % de metadados utilizados = 1% # ROMClasses = 475 # Caminhos de classe = 4 # URLs = 0 # Tokens = 0 # Classes antigas = 0 % Classes antigas = 0% O cache está 30% cheio Não foi possível criar a Java virtual machine. $ java -Xshareclasses:name=RSE,destroy JVMSHRC010I O Cache Compartilhado "RSE" foi destruído Não foi possível criar a Java virtual machine.
Com um heap de tamanho fixo, nenhuma expansão ou contração de heap ocorre e isso pode ocasionar significantes ganhos de desempenho em algumas situações. No entanto, a utilização de um heap de tamanho fixo geralmente não é uma boa idéia, porque atrasa o início de uma coleta de lixo até que o heap esteja cheio, momento em que será uma tarefa principal. Também aumenta o risco de fragmentação, o que requer uma compactação de heap. Portanto, utilize heaps de tamanho fixo só depois de desempenhar teste adequado ou quando orientado pelo IBM Support Center. Consulte o Diagnostics Guide (SC34-6358) para obter mais informações sobre tamanhos de heap e coleta de lixo.
Por padrão, o tamanho de heap inicial de uma JVM (Java Virtual Machine) do z/OS é 1 megabyte. O tamanho máximo é de 64 megabytes. Os limites podem ser definidos com as opções da linha de comandos -Xms (inicial) e -Xmx (máximo) Java.
No Developer for System z, as opções da linha de comandos Java são definidos na diretiva _RSE_JAVAOPTS de rsed.envvars, conforme descrito em (Opcional) Definindo Parâmetros Adicionais de Inicialização Java com _RSE_*OPTS.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
Cada site possui necessidades específicas e é possível customizar o sistema operacional z/OS para aproveitar ao máximo os recursos disponíveis de acordo com essas necessidades. Com gerenciamento de carga de trabalho, você define suas metas de desempenho e designa uma importância de negócios a cada meta. Você define as metas para o trabalho em termos de negócios e o sistema decide quantos recursos, como CPU e armazenamento, devem ser fornecidos para o trabalho, de acordo com a meta.
O desempenho do Developer for System z pode ser equilibrado pela configuração das metas corretas para os processos. Algumas orientações gerais estão listadas a seguir.
Consulte MVS Planning: Workload Management (SA22-7602) para obter mais informações sobre isso.
Há situações em que você deseja várias instâncias do Developer for System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. No entanto, alguns recursos como portas TCP/IP não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Utilize as informações neste apêndice para planejar a coexistência de instâncias diferentes do Developer for System z, após as quais você pode utilizar este guia de configuração para customizá-las.
Embora seja possível compartilhar determinadas partes do Developer for System z entre 2 (ou mais) instâncias, é aconselhável NÃO fazê-lo, a menos que seus níveis de software sejam idênticos e as únicas alterações sejam nos membros da configuração. O Developer for System z deixa espaço de customização suficiente para criar várias instâncias que não se sobrepõem, e recomendamos a utilização destes recursos.
Em algum conjunto limitado de circunstâncias, é possível compartilhar tudo, menos (algumas das) as partes customizáveis. Um exemplo é fornecer acesso não-SSL para uso no site e comunicação codificada por SSL para uso externo.
Para configurar outra instância de uma instalação ativa do Developer for System z, refaça as etapas de customização para as partes que são diferentes, utilizando conjuntos de dados/diretórios/portas diferentes para evitar sobrepor a configuração atual.
Na amostra SSL mencionada acima, as customizações atuais do servidor RSE podem ser clonadas, e depois as ssl.properties clonadas podem ser atualizadas. As customizações MVS (JES Job Monitor, etc.) podem ser compartilhadas entre as instâncias SSL e não-SSL. Isso resultaria nas seguintes ações:
Quando alterações de código estiverem envolvidas (manutenção, visualizações técnicas, novo release) ou quando as alterações forem razoavelmente complexas, é aconselhável fazer outra instalação do Developer for System z. Esta seção descreve os possíveis pontos de conflito entre as diferentes instalações.
A lista a seguir é uma breve visão geral dos itens que devem ser ou são altamente aconselhados a serem diferentes entre as instâncias do Developer for System z:
Uma visão geral mais detalhada é listada abaixo.
//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 é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar durante a configuração do Developer for System z.
Mais informações estão disponíveis por meio da seção Support do Web site do Developer for System z (http://www-306.ibm.com/software/awdtools/devzseries/support/) no qual você poderá encontrar notas técnicas que fornecem as informações mais recentes de nossa equipe de suporte.
Na seção Library do Web site, você também pode encontrar a versão mais recente da documentação do Developer for System z, inclusive whitepapers.
As valiosas informações também podem ser encontradas na biblioteca do z/OS na Internet, disponível em http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
O Developer for System z cria arquivos de log que podem auxiliar você e o centro de suporte da IBM na identificação e solução de problemas. A lista a seguir é uma visão geral dos arquivos de log que podem ser criados. Próximo a estes logs específicos do produto, certifique-se de verificar o SYSLOG em busca de alguma mensagem relacionada.
Os logs baseados no MVS podem ser localizados na instrução DD apropriada. Arquivos de log baseados no z/OS UNIX estão localizados nos seguintes diretórios:
A maioria dos arquivos de log está localizada em home/.eclipse/RSE/USERID/, em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possui um segmento OMVS) e USERID é o ID de usuário do logon (maiúsculas).
/tmp/ mantém os arquivos de log criados antes que o ID do usuário seja verificado.
Criação de logs de operações normais. O valor padrão no JCL de amostra hlq.SFEKSAMP(FEJJJCL) é SYSOUT=*.
Criação de logs de rastreio. O valor padrão no JCL de amostra hlq.SFEKSAMP(FEJJJCL) é SYSOUT=*. O rastreio é ativado com o parâmetro -TV; consulte Customizar o JCL de Inicialização do JES Job Monitor para obter mais detalhes.
Quando o utilitário de administração APPC inclui e modifica um perfil de programa de transação (TP), ele verifica o perfil TP e seu JCL em busca de erros de sintaxe. A saída desta fase consiste de mensagens de erro de sintaxe do perfil TP, mensagens do processamento do utilitário e instruções de conversão do JCL. A criação de logs para mensagens desta fase é controlada pela instrução SYSPRINT DD para o utilitário ATBSDFMU. O valor padrão no JCL de amostra hlq.SFEKSAMP(FEKAPPCC) é SYSOUT=*. Consulte MVS Planning: APPC/MVS Management (SA22-7599) para obter mais detalhes.
Quando um TP é executado, as mensagens de tempo de execução do TP, tais como mensagens de alocação e finalização, vão para um log nomeado pela palavra-chave MESSAGE_DATA_SET em seu perfil TP. O valor padrão no JCL de amostra hlq.SFEKSAMP(FEKAPPCC) é &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Consulte MVS Planning: APPC/MVS Management (SA22-7599) para obter mais detalhes.
Existem diversos arquivos de log criados pelos componentes relacionados ao RSE, e a maioria deles está localizada em home/.eclipse/RSE/USERID/, em que home é o caminho definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possui um segmento OMVS) e USERID é o ID de usuário do logon (maiúsculo).
A quantidade de dados gravados em ffs*.log, lock.log e em rsecomm.log é controlada pela configuração debug_level em rsecomm.properties. Consulte (Opcional) Customizar rsecomm.properties, Configuração do Rastreio RSE para obter mais detalhes.
Este arquivo contém um log do daemon antes de efetuar login.
A saída do comando fekfivpc -file (teste IVP relacionado ao SCLM Developer Toolkit), em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possui um segmento OMVS) e USERID é o ID de usuário do logon (maiúsculas).
Consulte Conexão do Serviço Comandos do TSO (Utilizando SCLMDT) para obter mais detalhes.
A criação de log do Fault Analyzer, em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possuir um segmento OMVS) e USERID é o ID do usuário de logon (maiúsculas).
Ao estabelecer uma conexão com o File Manager, uma tarefa do servidor será iniciada, com o ID do usuário como proprietário. Seu nome é FEKport, em que port é a porta TCP/IP utilizada.
O SYSPRINT da tarefa do servidor mantém a criação de log do servidor FMI.
A criação de log de comunicação do FMI, em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possuir um segmento OMVS) e USERID é o ID do usuário de logon (maiúsculas).
A quantidade de dados gravados neste arquivo é controlada pela configuração debug_level em rsecomm.properties. Consulte (Opcional) Customizar rsecomm.properties, Configuração do Rastreio RSE para obter mais detalhes.
Ao estabelecer uma conexão com o CARMA, hlq.SCRACLST(SCRASUBMT) iniciará uma tarefa do servidor (com o ID do usuário como proprietário) chamada CRAport, em que port é a porta TCP/IP utilizada.
Se o CARMALOG da instrução DD for especificado em hlq.SCRACLST(SCRASUBMT), a criação de log do CARMA será redirecionada para esta instrução DD na tarefa do servidor; caso contrário, vai para SYSPRINT.
A quantidade de criação de log é controlada pela configuração do Nível de Rastreio no cliente. Consulte (Opcional) Ativando o IBM CARMA para obter mais detalhes sobre a configuração do Nível de Rastreio.
O SYSPRINT da tarefa do servidor mantém a criação de log do CARMA, se o CARMALOG da instrução DD não estiver definido.
A criação de log de comunicação do CARMA, em que home é o caminho inicial definido no segmento OMVS do usuário (ou o segmento OMVS padrão se o usuário não possuir um segmento OMVS) e USERID é o ID do usuário de logon (maiúsculas).
A quantidade de dados gravados neste arquivo é controlada pela configuração debug_level em rsecomm.properties. Consulte (Opcional) Customizar rsecomm.properties, Configuração do Rastreio RSE para obter mais detalhes.
Quando um produto é finalizado de forma anormal, um dump de armazenamento é criado para auxiliar na determinação do problema. A disponibilidade e localização destes dumps depende quase que totalmente das configurações específicas do site. Portanto, pode ser que eles não sejam criados, ou criados em localizações diferentes da mencionada abaixo.
Quando um programa está em execução no MVS, verifique os arquivos de dump do sistema e verifique o JCL em busca das seguintes instruções DD (dependendo do produto):
Consulte a MVS JCL Reference (SA22-7597) e o Language Environment Debugging Guide (GA22-7560) para obter mais informações sobre estas instruções DD.
No z/OS UNIX, os dumps do Developer for System z são controlados pela JVM (Java Virtual Machine).
A JVM cria um conjunto de agentes de dump por padrão, durante a inicialização (SYSTDUMP e JAVADUMP). Você pode sobrepor este conjunto de agentes de dump utilizando a variável de ambiente JAVA_DUMP_OPTS e sobrepor o conjunto pelo uso de -Xdump na linha de comandos. As opções da linha de comandos da JVM são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars. Não altere nenhuma configuração de dump, a menos que tenha sido solicitado pelo IBM Support Center.
Os tipos de dump que podem ser produzidos são:
O dump é gravado em um conjunto de dados MVS seqüencial, utilizando o nome padrão do formulário &userid.JVM.TDUMP.&jobname.D&date.T&time ou como determinado pela configuração da variável de ambiente JAVA_DUMP_TDUMP_PATTERN. Se você não deseja que dumps de transação sejam criados, inclua a variável de ambiente IBM_JAVA_ZOS_TDUMP=NO em rsed.envvars.
O dump é gravado em um arquivo z/OS UNIX chamado CEEDUMP.aaaammdd.hhmmss.pid, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.
O dump é gravado em um arquivo z/OS UNIX chamado HEAPDUMP.aaaammdd.hhmmss.pid.TXT, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.
O dump é gravado em um arquivo z/OS UNIX chamado JAVADUMP.aaaammdd.hhmmss.pid.TXT, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.
Consulte o Java Diagnostic Guide (SC34-6358) para obter mais informações sobre dumps JVM e o Language Environment Debugging Guide (GA22-7560) para informações específicas do LE
A JVM verifica cada um dos seguintes locais quanto à existência e permissão de gravação, e armazena os arquivos CEEDUMP, HEAPDUMP e JAVADUMP no primeiro disponível. Observe que você deve possuir espaço em disco livre suficiente para que o arquivo de dump seja gravado corretamente.
O RSE (Remote Systems Explorer) é o componente do Developer for System z que fornece os principais serviços, como de conexão do cliente ao host. Ele deve executar o programa controlado para desempenhar tarefas como a comutação para o ID de usuário do cliente.
O bit de controle de programa é configurado durante a instalação do SMP/E, onde necessário.
Esse resultado pode ser verificado com o comando ls -lE fekf*, que fornece uma saída como a seguinte amostra ($ é o prompt 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 os seguintes comandos se o bit de controle de programa precisar ser configurado manualmente, considerando que o diretório de instalação padrão (/usr/lpp/wd4z/rse/lib/) é utilizado:
1. cd /usr/lpp/wd4z/rse/lib 2. extattr +p fekfdir.dll fekfivp fekflock fekfrsed
Com o comando NETSTAT (TSO ou z/OS UNIX), você pode obter uma visão geral das portas atualmente em uso. A saída deste comando será semelhante ao exemplo abaixo. As portas utilizadas são os últimos números (atrás de '..') na coluna "Soquete Local". Como estas portas já estão em uso, elas não podem ser utilizadas para a configuração do Developer for System z.
MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 16:36:42 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen INETD4 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
Outra limitação que pode existir são as portas TCP/IP reservadas. Existem 2 locais comuns para reservar portas TCP/IP:
Este é o conjunto de dados consultado pela instrução PROFILE DD da tarefa iniciada do TCP/IP, chamada geralmente de SYS1.TCPPARMS(TCPPROF)
Consulte o Communications Server: IP Configuration Guide (SC31-8775) para obter mais informações sobre estas instruções.
Estas portas reservadas podem ser listadas com o comando NETSTAT PORTL (TSO ou z/OS UNIX), que cria uma saída como no exemplo abaixo:
MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 17:08:32 Port# Prot User Flags Range IP Address ----- ---- ---- ----- ----- ---------- 00007 TCP MISCSERV DA 00009 TCP MISCSERV DA 00019 TCP MISCSERV DA 00020 TCP OMVS D 00021 TCP FTPD1 DA 00025 TCP SMTP DA 00053 TCP NAMESRV DA 00080 TCP OMVS DA 03500 TCP OMVS DAR 03500-03519 03501 TCP OMVS DAR 03500-03519
Consulte Communications Server: IP System Administrator's Commands (SC31-8781) para obter mais informações sobre o comando NETSTAT.
O servidor RSE, que é um processo Java UNIX, requer um tamanho de região grande para desempenhar essas funções. Portanto, é importante definir limites de armazenamento grandes para espaços de endereço do OMVS.
Um servidor RSE é iniciado pelo INETD quando um cliente se conecta à porta do daemon RSE ou quando o cliente emite o script de inicialização utilizando REXEC/SSH. Isso é feito utilizando os limites de armazenamento do INETD, portanto devem ser definidos suficientemente altos.
Configure MAXASSIZE em SYS1.PARMLIB(BPXPRMxx), que define o tamanho da região do espaço de endereço do OMVS (processo) como 2147483647 ou maior.
Esse valor pode ser verificado e configurado dinamicamente (até o próximo IPL) com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):
Verifique ASSIZEMAX no segmento OMVS do ID do usuário do cliente e defina-o como 2147483647 ou, preferencialmente, como NONE para utilizar o valor de SYS1.PARMLIB(BPXPRMxx).
Utilizando o RACF, esse valor pode ser verificado e configurado com os seguintes comandos do TSO, conforme descrito em Security Server RACF Command Language Reference (SA22-7687):
Certifique-se de não estar permitindo que saídas do sistema IEFUSI ou IEALIMIT controlem tamanhos de região do espaço de endereço do OMVS. Uma forma possível de fazer isso é pela codificação de SUBSYS(OMVS,NOEXITS) em SYS1.PARMLIB(SMFPRMxx).
Os valores de SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):
O procedimento a seguir permite reunir informações necessárias para diagnosticar problemas de feedback de erro com procedimentos de construção remota. Esse rastreio causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center. Todas as referências a hlq nesta seção referem-se ao qualificador de alto nível utilizado durante a instalação do Developer for System z. O padrão da instalação é FEK, mas isto talvez não se aplique ao seu site.
//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
Se não puder utilizar a versão APPC do serviço Comandos do TSO, haverá duas áreas nas quais os problemas poderão surgir: iniciando a transação do servidor APPC e conectando ao RSE.
O REXX fornecido em (Opcional) Definir uma Transação APPC para o Serviço de Comandos do TSO pode ajudar com a solução de problemas APPC desde que ele forneça a possibilidade de gerenciar o APPC de forma interativa por meio dos painéis do ISPF. Esteja ciente, entretanto, de que é possível desativar a transação com esta ferramenta; a transação ainda está lá, mas não aceitará nenhuma conexão.
A lista a seguir é uma seleção de notas técnicas atualmente disponíveis no Web site de suporte (http://www-306.ibm.com/software/awdtools/devzseries/support/). Consulte o Web site de suporte para obter informações adicionais:
SYS1.PARMLIB(BPXPRMxx) define muitas limitações relacionadas ao z/OS UNIX, que pode ser acessado quando muitos clientes do Developer for System z estão ativos. A maioria dos valores de BPXPRMxx pode ser alterada dinamicamente com os comandos do console SETOMVS e SET OMVS.
Cada conexão RSE inicia diversos processos que são permanentemente ativos. Novas conexões podem ser recusadas devido ao limite definido em SYS1.PARMLIB(BPXPRMxx) na quantidade de processos, especialmente quando os usuários compartilham o mesmo UID (como na utilização do segmento OMVS padrão).
Outra origem de conexões recusadas é o limite da quantidade de espaços de endereço do z/OS e de usuários do z/OS UNIX ativos.
A leitura e gravação de um conjunto de dados MVS requer o uso de um domínio do sistema de arquivo físico do soquete. Se o sistema de arquivo não estiver definido adequadamente ou não tiver soquetes suficientes, o gerenciador de bloqueio (FFS) poderá falhar nos pedidos de leitura/gravação. Os arquivos ffs*.log mostrarão mensagens como a seguinte:
Verifique se o membro SYS1.PARMLIB(BPXPRMxx) contém as seguintes instruções:
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(200) TYPE(UDS)
Ao utilizar VIPA (Virtual IP Address) dinâmico em várias pilhas TCPIP, é necessária coordenação no sysplex da designação de portas transitórias para que o 4-tuple (combinação de endereços e portas IP de origem e de destino) para cada conexão permaneça exclusivo. Isso pode ser feito incluindo o parâmetro SYSPLEXPORTS opcional na primeira instrução VIPADISTRIBUTE, conforme descrito no IP Configuration Guide (SC31-8775).
Ao utilizar essa técnica, certifique-se de que a estrutura do recurso de acoplamento EZBEPORT (contendo informações de designação de porta sysplex) tenha sido definida. Consulte o SNA Network Implementation Guide (SC31-8777) para obter informações sobre como fazer isso.
Se você ainda estiver com dificuldades depois de ler este manual e consultar o Web site de suporte (http://www-306.ibm.com/software/awdtools/devzseries/support/) e for necessária assistência do suporte da IBM, reúna as seguintes informações e abra um registro de problema com a IBM:
As seguintes informações são úteis para resolver problemas de conexão
Se você utilizar o SCLM Developer Toolkit para o serviço Comandos do TSO (método padrão)
Se você utilizar o APPC para o serviço Comandos do TSO
Forneça todas as informações que pareçam relevantes para problemas funcionais, como
Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o TCP/IP, ou durante a verificação e/ou modificação de uma configuração existente.
Consulte Communications Server: IP Configuration Guide (SC31-8775) e Communications Server: IP Configuration Reference (SC31-8776) para obter informações adicionais sobre a configuração do TCP/IP.
O Developer for System z depende de o TCP/IP ter o nome do host correto quando for inicializado. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
Você pode testar sua configuração TCP/IP com o comando HOMETEST do TSO. Consulte Communications Server: IP System Administrator's Commands (SC31-8781) para obter informações adicionais sobre o comando HOMETEST.
Saída de exemplo do comando HOMETEST:
Executando o Testador de Configuração TCP/IP IBM MVS TCP/IP CS V1R7 O arquivo de parâmetros de configuração de FTP utilizado será "SYS1.TCPPARMS(FTPDATA)" O Nome do Host TCP é: CDFMVS08 Utilizando o Servidor de Nomes para Resolver CDFMVS08 Os endereços IP a seguir correspondem ao Nome do Host TCP: CDFMVS08 9.42.112.75 Os endereços IP a seguir são os endereços IP HOME definidos no PROFILE.TCPIP: 9.42.112.75 127.0.0.1 Todos os endereços IP do CDFMVS08 estão na lista HOME! O Hometest foi bem-sucedido - todos os Testes Passaram!
O resolvedor atua em nome de programas como um cliente que acessa servidores de nomes para resolução de nome para endereço e de endereço para nome. Para resolver a consulta do programa solicitante, o resolvedor pode acessar os servidores de nomes disponíveis, utilize definições locais (por exemplo, /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO ou ETC.IPNODES) ou utilize uma combinação delas.
Quando o espaço de endereços do resolvedor é iniciado, ele lê um conjunto de dados de configuração do resolvedor opcional apontado pelo cartão SETUP DD no procedimento JCL do resolvedor. Se as informações de configuração não forem fornecidas, o resolvedor utiliza a ordem de procura nativa aplicável do MVS ou do z/OS UNIX sem qualquer informação de GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES ou COMMONSEARCH.
É importante compreender o ordem de procura dos arquivos de configuração utilizados pelas funções TCP/IP, e quando você pode sobrescrever a ordem de procura padrão com variáveis de ambiente, JCL ou outras variáveis fornecidas. Este conhecimento permite acomodar o conjunto de dados local e padrões de nomenclatura de arquivos HFS, e é útil conhecer o conjunto de dados da configuração ou o arquivo HFS em uso ao diagnosticar problemas.
Um outro ponto importante a ser observado é que quando uma ordem de procura é aplicada para qualquer arquivo de configuração, a procura finaliza com o primeiro arquivo localizado. Portanto, podem ocorrer resultados inesperados se você colocar informações de configuração em um arquivo que nunca é encontrado, pois outros arquivos aparecem antes na ordem de procura, ou porque o arquivo não está incluído na ordem de procura escolhida pelo aplicativo.
Ao procurar por arquivos de configuração, você pode informar explicitamente ao TCP/IP onde estão a maioria dos arquivos de configuração utilizando instruções DD nos procedimentos JCL ou configurando variáveis de ambiente. Caso contrário, você pode permitir que o TCP/IP determine dinamicamente a localização dos arquivos de configuração, com base nas ordens de procura documentadas no Communications Server: IP Configuration Guide (SC31-8775).
O componente de configuração da pilha do TCP/IP utiliza o TCPIP.DATA durante a inicialização da pilha do TCP/IP para determinar o HOSTNAME da pilha. Para obter seu valor, a ordem de procura do ambiente do z/OS UNIX é utilizada.
O arquivo ou tabela específico que é procurado pode ser um conjunto de dados MVS ou um arquivo HFS, dependendo das definições de configuração do resolvedor e da presença de determinados arquivos no sistema.
O arquivo de base da configuração do resolvedor contém instruções TCPIP.DATA. Além das diretivas do resolvedor, ele é referido para determinar, entre outras coisas, o prefixo do conjunto de dados (valor da instrução DATASETPREFIX) a ser utilizado ao tentar acessar alguns arquivos de configuração especificados nesta seção.
A ordem de procura utilizada para acessar o arquivo de base da configuração do resolvedor é conforme a seguir:
Se definido, o valor da instrução de configuração GLOBALTCPIPDATA do resolvedor é utilizado (consulte também Compreendendo os Resolvedores). A procura continua por um arquivo de configuração adicional. A procura finaliza com o próximo arquivo localizado.
O valor da variável de ambiente é utilizado. Esta procura falhará se o arquivo não existir ou estiver alocado exclusivamente em outro lugar.
O conjunto de dados alocado para o SYSTCPD de nome DD é utilizado. No ambiente z/OS UNIX, um processo-filho não possui acesso ao DD SYSTCPD. Isto porque a alocação de SYSTCPD não é herdada do processo-pai por meio das chamadas de função fork() ou exec.
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).
jobname é o nome especificado na instrução JOB do JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
Se definido, o valor da instrução de configuração DEFAULTTCPIPDATA do resolvedor é utilizado (consulte também Compreendendo os Resolvedores).
As tabelas de conversão (EBCDIC-to-ASCII e ASCII-to-EBCDIC) são consultadas para determinar os conjuntos de dados de conversão a serem utilizados. A ordem de procura utilizada para acessar este arquivo de configuração é conforme a seguir. A ordem de procura finaliza no primeiro arquivo localizado:
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).
jobname é o nome especificado na instrução JOB do JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Por padrão, o resolvedor primeiro tenta utilizar qualquer servidor de nomes de domínios configurado para pedidos de resolução. Se o pedido de resolução não puder ser satisfeito, as tabelas do host local são utilizadas. O comportamento do resolvedor é controlado pelas instruções TCPIP.DATA.
As instruções do resolvedor TCPIP.DATA definem se e como os servidores de nomes de domínios devem ser utilizados. A instrução LOOKUP TCPIP.DATA também pode ser utilizada para controlar como os servidores de nomes de domínios e as tabelas do host local são utilizadas. Para obter informações adicionais sobre as instruções TCPIP.DATA, consulte Communications Server: IP Configuration Reference (SC31-8776).
O resolvedor utiliza a ordem de procura exclusiva Ipv4 para obter informações de nomes de sites incondicionalmente para chamadas de API getnetbyname. A ordem de procura exclusiva Ipv4 para obter informações de nome do site é conforme a seguir. A procura finaliza no primeiro arquivo localizado:
O valor da variável de ambiente é o nome do arquivo de informações HOSTS.SITEINFO criado pelo comando MAKESITE do TSO.
O valor da variável de ambiente é o nome do arquivo de informações HOSTS.ADDRINFO criado pelo comando MAKESITE do TSO.
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).
jobname é o nome especificado na instrução JOB do JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Conforme informado anteriormente, o Developer for System z depende de o TCP/IP ter o nome do host correto quando for inicializado. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
No exemplo abaixo teremos como foco algumas tarefas de configuração para TCP/IP e Resolver. Observe que isto não abrange uma configuração completa de TCP/IP ou Resolver, ela destaca alguns aspectos principais que podem ser aplicáveis no seu site.
//TCPIP PROC PARMS='CTRACE(CTIEZB00)',PROF=TCPPROF,DATA=TCPDATA //* //* TCP/IP NETWORK //* //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 o nome do host TCP deste sistema. Se não ; especificado, o HOSTNAME padrão será o nome do nó especificado ; no membro IEFSSNxx PARMLIB. ; ; HOSTNAME ; ; DOMAINORIGIN especifica a origem do domínio que será anexado ; nos nomes dos hosts transmitidos para o resolvedor. Se um nome ; de host contiver algum ponto, então DOMAINORIGIN não será anexado ; ao nome do host. ; DOMAINORIGIN RALEIGH.IBM.COM ; ; NSINTERADDR especifica o endereço IP do servidor de nomes. ; LOOPBACK (14.0.0.0) especifica o servidor de nomes local. Se um servidor ; de nomes não será utilizado, então não codifique uma instrução NSINTERADDR. ; (Comente a linha NSINTERADDR abaixo). Isto fará com que todos os nomes ; sejam resolvidos por meio de consulta na tabela de sites. ; ; NSINTERADDR 14.0.0.0 ; ; TRACE RESOLVER realizará um rastreio completo de todas as consultas e ; fará com que as respostas do servidor de nomes ou tabelas de sites sejam ; gravadas no console do usuário. Este comando é destinado somente para ; finalidades de depuração. ; ; 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
Conforme mencionado em Ordens de Procura Utilizadas no Ambiente z/OS UNIX, o arquivo de base da configuração contém instruções TCPIP.DATA. Se o nome do sistema for CDFMVS08 (TCPDATA informou que o nome do sistema é utilizado como nome do host) podemos ver que /etc/resolv.conf está em sincronismo com SYS1.TCPPARMS(TCPDATA). Não há definições DNS, portanto a consulta à tabela de sites será utilizada.
# Resolver /etc/hosts file cdfmvs08 9.42.112.75 cdfmvs08 # CDFMVS08 Host 9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host 127.0.0.1 localhost
O conteúdo mínimo deste arquivo é a informação sobre o sistema atual. Na amostra acima, definimos cdfmvs08 e cdfmvs08.raleigh.ibm.com como um nome válido para o endereço IP do nosso sistema z/OS.
Se estivéssemos utilizando um DNS (servidor de nomes de domínios), o DNS conteria as informações de /etc/hosts e /etc/resolv.conf e SYS1.TCPPARMS(TCPDATA) teriam instruções que identificam o DNS em nosso sistema.
Para evitar confusão, é aconselhável manter os arquivos de configuração do TCP/IP e do Resolver em sincronismo um com o outro.
Descrição do Tipo do Arquivo | APIs afetadas | Arquivos do Candidato |
---|---|---|
Arquivos de Base da Configuração do Resolvedor | Todas as APIs |
|
Tabelas de Conversão | Todas as APIs |
|
Tabelas do Host Local |
endhostent endnetent getaddrinfo gethostbyaddr gethostbyname gethostent GetHostNumber GetHostResol GetHostString getnameinfo getnetbyaddr getnetbyname getnetent IsLocalHost Resolve sethostent setnetent |
IPv4
IPv6
|
Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o INETD ou durante a verificação e/ou modificação de uma configuração existente.
O daemon do INETD fornece gerenciamento de serviço para uma rede IP. Reduz a carga do sistema, invocando outros daemons apenas quando forem necessários e fornecendo vários serviços de Internet simples (como echo) internamente. O INETD lê o arquivo de configuração inetd.conf para determinar quais serviços adicionais fornecer. ETC.SERVICES é utilizado para vincular os serviços a portas.
Os serviços que dependem do INETD são definidos em inetd.conf, lido pelo INETD no momento da inicialização. O local padrão e o nome de inetd.conf é /etc/inetd.conf. Um arquivo inetd.conf de amostra pode ser encontrado em /samples/inetd.conf.
As seguintes regras de sintaxe se aplicam às entradas de inetd.conf:
Cada entrada consiste em 7 campos posicionais, correspondendo ao formato:
service_name socket_type protocol wait_flag userid server_program server_program_arguments
protocol pode ser tcp[4|6] ou udp[4|6], e é utilizado para qualificar o nome do serviço. O nome do serviço e o protocolo devem corresponder a uma entrada em ETC.SERVICES, exceto que "4" ou "6" não deve ser incluído na entrada ETC.SERVICES.
sndbuf e rcvbuf especificam o tamanho dos buffers de envio e recebimento. O tamanho, representado por n, pode estar em bytes, ou um "k" ou "m" pode ser incluído para indicar kilobytes ou megabytes respectivamente. sndbug e rcvbuf pode ser utilizado na ordem.
wait ou nowait.wait indica que o daemon é de encadeamento único e outro pedido não será submetido a manutenção até que o primeiro seja concluído. Se nowait for especificado, o INETD emitirá uma aceitação quando um pedido de conexão for recebido no soquete de fluxo. Se a espera for especificada, será responsabilidade do servidor emitir a aceitação, se este for um soquete de fluxo.
max é o número máximo de usuários permitidos para solicitar manutenção em um intervalo de 60 segundos. O padrão é 40. Se for excedido, a porta do serviço será encerrada.
userid é o ID do usuário em que o daemon bifurcado deve ser executado. Esse ID do usuário pode ser diferente do ID do usuário do INETD. As permissões designadas a este ID do usuário depenem das necessidades do serviço. O ID do usuário do INETD precisa da permissão BPX.DAEMON para alternar o processo bifurcado para este ID do usuário.
O valor group opcional, separado do ID do usuário por um ponto (.), permite que o servidor seja executado com um ID de grupo diferente do padrão para este ID do usuário.
O INETD utiliza ETC.SERVICES para mapear números de porta e protocolos para os serviços que deve suportar. Pode ser um conjunto de dados do MVS ou um arquivo z/OS UNIX. Uma amostra é fornecida em SEZAINST(SERVICES), que também está disponível como /usr/lpp/tcpip/samples/services. A ordem de procura para ETC.SERVICES depende do método de inicialização do INETD; z/OS UNIX ou MVS nativo.
As seguintes regras de sintaxe se aplicam à especificação de informações de serviços:
Cada entrada consiste em 4 campos posicionais, correspondendo ao formato:
service_name port_number/protocol aliases
A ordem de procura utilizada para acessar ETC.SERVICES em z/OS UNIX é conforme a seguir. A procura finaliza no primeiro arquivo localizado:
userid é o ID do usuário utilizado para iniciar INETD
.hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
A ordem de procura utilizada para acessar ETC.SERVICES no MVS nativo é conforme a seguir. A procura termina no primeiro conjunto de dados encontrado:
O conjunto de dados alocado para a instrução DD SERVICES é utilizado.
userid é o ID do usuário utilizado para iniciar INETD
.jobname é o nome especificado na instrução JOB do JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Não confunda as definições PORT (ou PORTRANGE) em PROFILE.TCPIP com as portas definidas em ETC.SERVICES, pois essas definições têm finalidades diferentes. As portas definidas em PROFILE.TCPIP são utilizadas pelo TCPIP para ver se a porta está reservada para um determinado serviço. ETC.SERVICES é utilizado pelo INETD para mapear uma porta para um serviço.
Quando o INETD recebe um pedido em uma porta monitorada, bifurca um processo-filho (com o serviço solicitado) chamado inetdx, em que inetd é o nome da tarefa do INETD (depende do método de inicialização) e x é um número de dígito único.
Isso complica a reserva de porta, portanto, se uma porta monitorada do INETD for reservada em PROFILE.TCPIP, é aconselhável utilizar o nome do procedimento JCL iniciado para o Espaço de Endereço de Kernel do z/OS UNIX, a fim de permitir que quase todos os processos sejam ligados à porta. Esse nome é geralmente OMVS, a menos que um nome diferente seja especificado explicitamente no parâmetro STARTUP_PROC do membro parmlib BPXPRMxx.
A lista a seguir explica como determinar o nome da tarefa, de acordo com o ambiente em que o aplicativo é executado:
O processo do INETD cria um arquivo temporário, /etc/inetd.pid, que contém o PID (ID do processo) do daemon INETD em execução no momento. Esse valor de PID é utilizado para identificar registros syslog originados do processo INETD e para fornecer o valor PID para comandos que requerem um, como kill. Também é utilizado como um mecanismo de bloqueio para impedir que mais de um 1 processo INETD esteja ativo.
A implementação do z/OS UNIX do INETD está localizada, por padrão, em /usr/sbin/inetd e suporta 2 parâmetros de inicialização opcionais e não-posicionais:
/usr/sbin/inetd [-d] [inetd.conf]
É aconselhável iniciar o INETD no momento do IPL. A forma mais comum de fazer isso é iniciá-lo no /etc/rc ou /etc/inittab (z/OS 1.8 e posterior apenas). Pode ser iniciado de uma tarefa ou uma tarefa iniciada utilizando BPXBATCH ou de uma sessão de shell de um usuário com autoridade apropriada.
Quando iniciado a partir do script do shell de inicialização do z/OS UNIX, /etc/rc, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um arquivo /etc/rc de amostra é fornecido como /samples/rc. Os seguintes comandos de amostra podem ser utilizados para iniciar o INETD:
# Start INETD _BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & sleep 5
O z/OS 1.8 e superior oferecem um método alternativo, /etc/inittab, para emissão de comandos durante a inicialização do z/OS UNIX. /etc/inittab permite a definição do parâmetro respawn, que reinicia o processo automaticamente quando é encerrado (um WTOR é enviado para o operador, para um segundo reinício, em 15 minutos). Quando iniciado a partir de /etc/inittab, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um /etc/inittab de amostra é fornecido como /samples/inittab. O seguinte comando de amostra pode ser utilizado para iniciar o INETD:
# Start INETD inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf
O método de inicialização BPXBATCH trabalha para STCs e tarefas do usuário. Observe que o INETD é um processo em segundo plano, portanto a etapa BPXBATCH iniciando o INETD será encerrada em segundos após a inicialização. Quando iniciado pelo BPXBATCH, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. O JCL listado em Figura 11 é um procedimento de amostra para iniciar o INETD (a etapa KILL remove um processo INETD ativo, se houver):
//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 e STDENV são padronizados como /dev/null //* A saída do daemon INETD pode ser controlada pelas configurações de syslogd //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Quando iniciado a partir de uma sessão de shell, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Os seguintes comandos de amostra podem ser utilizados (por uma pessoa com autoridade suficiente) para parar e iniciar o INETD (# é o prompt do z/OS UNIX):
1. # ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd 2. # kill 7 3. # _BPX_JOBNAME='INETD' /usr/sbin/inetd
O INETD é um processo do z/OS UNIX e, portanto, requer definições OMVS válidas no software de segurança para o ID do usuário associado ao INETD. UID, HOME e PROGRAM devem ser definidos para o ID do usuário, juntamente com o GID para o grupo padrão do usuário. Se o INETD for iniciado pelo /etc/rc ou pelo /etc/inittab, o ID do usuário será herdado do kernel z/OS UNIX, padrão OMVSKERN.
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD + OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
O INETD é um daemon que requer acesso a funções como setuid(). Portanto, o ID do usuário utilizado para iniciar o INETD requer acesso de LEITURA ao perfil BPX.DAEMON na classe FACILITY. Se esse perfil não estiver definido, UID 0 será obrigatório.
PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)
O ID do usuário do INETD requer permissão de EXECUÇÃO para o programa inetd (/usr/sbin/inetd), acesso de LEITURA para os arquivos inetd.conf e ETC.SERVICES e acesso de GRAVAÇÃO para /etc/inetd.pid. Se você deseja executar o INETD sem o UID 0, pode conceder acesso de CONTROLE ao perfil SUPERUSER.FILESYS na classe UNIXPRIV para fornecer as permissões necessárias para os arquivos z/OS UNIX.
Os programas que requerem autoridade de daemon devem ser controlados por programa, se BPX.DAEMON estiver definido na classe FACILITY. Isso já é feito para o programa INETD padrão (/usr/sbin/inetd), mas deve ser definido manualmente se você utilizar uma cópia ou uma versão customizada. Utilize o comando extattr +p para tornar um arquivo z/OS UNIX controlado por programa. Utilize a classe RACF PROGRAM para tornar um módulo de carregamento MVS controlado por programa.
Os programadores de sistema que precisam reiniciar o INETD em sua sessão de shell iniciarão o INETD utilizando suas permissões. Portanto, devem ter a mesma lista de permissões que o ID do usuário do INETD regular. Além disso, também precisam de permissões para listar e parar o processo do INETD. Isso pode ser feito de várias maneiras.
Isso não é recomendado para IDs de usuário "humanos", pois não há restrições relacionadas ao z/OS UNIX.
Permite que o usuário se torne o UID 0 por meio do comando su. Essa é a configuração recomendada.
Consulte a UNIX System Services Command Reference (SA22-7802) para aprender mais sobre os comandos extattr e su. Consulte UNIX System Services Planning (GA22-7800) para aprender mais sobre a classe UNIXPRIV e os perfis BPX.* na classe FACILITY. Consulte o Security Server RACF Security Administrator's Guide (SA22-7683) para obter mais informações sobre as definições do segmento OMVS e a classe PROGRAM.
O Developer for System z depende de INETD para configuração da conexão de host do cliente. Também impõe requisitos adicionais além da configuração do INETD descrita acima.
As configurações ambientais do INETD, informadas ao iniciar um processo, e as permissões para o ID do usuário do INETD, devem ser definidas adequadamente para que o INETD inicie o servidor RSE.
O daemon RSE que é iniciado pelo INETD quando um cliente se conecta à porta 4035 é utilizado para desempenhar autenticação, iniciar o servidor RSE e retornar o número da porta para comunicação com o cliente. Para fazer isso, o ID do usuário designado ao daemon RSE (em inetd.conf) requer a seguintes permissões:
Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o SSL (Secure Socket Layer) ou durante a verificação e/ou modificação de uma configuração existente.
Comunicação segura significa garantir que seu parceiro de comunicação seja o que alega ser e transmitir informações de forma que dificulte a interceptação e leitura dos dados por terceiros. SSL (Secure Sockets Layer) oferece essa capacidade em uma rede TCP/IP. Funciona utilizando certificados digitais para se identificar e um protocolo de chave pública para criptografar a comunicação. Consulte o Security Server RACF Security Administrator's Guide (SA22-7683) para obter mais informações sobre certificados digitais e sobre o protocolo de chave pública utilizado pelo SSL.
As ações necessárias para configurar as comunicações SSL para o Developer for System z variam de site para site, dependendo das necessidades exatas, do método de comunicação RSE utilizado e do que já está disponível no site.
Neste apêndice, clonaremos as definições RSE atuais, para que tenhamos uma 2ª conexão que utilizará SSL. O método de comunicação de REXEC e de daemon será configurado para o SSL. Também criaremos nossos próprios certificados de segurança a serem utilizados pelas diferentes partes da conexão RSE. Tudo isso será feito nas seguintes etapas:
Todo este apêndice apresenta uma convenção de nomenclatura uniforme:
A maioria das tarefas descritas abaixo espera que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Utilize o comando exit para retornar ao TSO.
Nesta etapa, uma nova instância do servidor RSE e daemon RSE é criada para execução paralela com a(s) existente(s). Dessa forma, o teste do SSL não impedirá operações normais. Conforme aconselhável em Salvando o Arquivo de Configuração rsed.envvars em um Outro Diretório, os comandos de amostra a seguir esperam que os arquivos de configuração estejam em /etc/wd4z/
$ cd /etc/wd4z $ mkdir ssl $ cp * ssl cp: FSUM6254 "ssl" é um diretório (não copiado) $ ls ssl rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries $ cd ssl $ su # oedit /etc/services rsessl 4047/tcp #Developer for System z RSE utilizando SSL
incluir o serviço rsessl, utilizando a porta 4047
# oedit /etc/inetd.conf rsessl stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z/ssl
incluir o daemon rsessl, utilizando o diretório de configuração /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 Listen
Os comandos listados acima criam um subdiretório chamado ssl e o preenchem com os arquivos de configuração obrigatórios. Nenhuma alteração na configuração precisa ser feita (ainda). Podemos compartilhar o diretório de instalação e os componentes do MVS, pois não são específicos ao SSL. No entanto, um novo daemon (rsessl) deve ser definido utilizando os novos arquivos de configuração. A porta 4047 é designada ao novo daemon.
Consulte Ativando Componentes do z/OS UNIX para o Developer for System z para obter mais informações sobre as ações mostradas acima.
Os certificados de identidade e as chaves de criptografia/descriptografia utilizadas pelo SSL são armazenados em um arquivo de chaves. Existem diferentes implementações deste arquivo de chaves, dependendo do tipo de aplicativo.
O daemon RSE é um aplicativo SSL do Sistema e utiliza um arquivo de banco de dados de chaves. Esse arquivo de banco de dados de chaves pode ser um arquivo físico criado por gskkyman ou um anel de chave gerenciado pelo software de segurança (por exemplo, RACF). O servidor RSE (iniciado pelo daemon ou REXEC) é um aplicativo SSL Java e utiliza um arquivo de armazenamento de chaves criado pelo keytool. Atualmente, o RACF não tem suporte out-of-the-box para o SSL Java.
Assim, para se conectar via REXEC, tudo o que é necessário é o arquivo de armazenamento de chaves:
Para se conectar pelo daemon, precisamos do armazenamento de chaves e do arquivo do banco de dados de chaves:
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações sobre o RACF e certificados digitais. A documentação do gskkyman pode ser encontrada em System SSL Programming (SC24-5901). A documentação do keytool está disponível no endereço http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html.
"keytool -genkey" Gera um par de chaves (uma chave pública e chave privada associada). Então, agrupa a chave pública em um certificado auto-assinado X.509 v1, armazenado como uma cadeia de certificados de elemento único. Essa cadeia de certificados e a chave privada são armazenadas como uma entrada (identificada por um alias) em um arquivo de armazenamento de chaves (novo).
Todas as informações podem ser transmitidas como um parâmetro, mas, devido ao comprimento da linha de comandos, é necessária alguma interatividade.
$ keytool -genkey -alias wd4zrse -validity 3650 -keystore wd4zssl.jks -storepass rsessl -keypass rsessl Qual é o seu nome e sobrenome? [Desconhecido]: wd4z rse ssl Qual é o nome de sua unidade organizacional? [Desconhecido]: wd4z Qual é o nome de sua organização? [Desconhecido]: IBM Qual é o nome de sua cidade ou localidade? [Desconhecido]: Raleigh Qual é o nome de seu estado ou província? [Desconhecido]: NC Qual é o código do país de duas letras para esta unidade? [Desconhecido]: US É CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US correto? (digite "sim" ou "não") [não]: sim $ ls rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries wd4zssl.jks
O certificado auto-assinado criado acima é válido durante aproximadamente 10 anos (não contando o dia 29 de fevereiro). É armazenado em /etc/wd4z/ssl/wd4zssl.jks, utilizando wd4zrse. Sua senha (rsessl) é idêntica à senha do armazenamento de chaves, que é um requisito para o RSE.
O resultado pode ser verificado com a opção -list:
$ keytool -list -alias wd4zrse -keystore wd4zssl.jks -storepass rsessl -v Nome do alias: wd4zrse Data de criação: 24 de maio de 2007 Tipo de entrada: keyEntry Comprimento da cadeia de certificados: 1 Certificado 1¨: Proprietário: CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US Emissor: CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US Número serial: 46562b2b Válido de: 24/5/07 14h17 até: 21/5/17 14h17 Impressões digitais do 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
Conforme mencionado anteriormente, o daemon é um aplicativo SSL do Sistema e utiliza um banco de dados de chaves. Pode ser um arquivo físico criado por gskkyman ou um anel de chave do RACF. Os anéis de chave do RACF são o método preferencial para o gerenciamento de chaves privadas e certificados para o SSL do Sistema.
Não execute esta etapa se utilizar o gskkyman para SSL do Sistema.
O comando RACDCERT instala e mantém chaves privadas e certificados no RACF. O RACF suporta várias chaves privadas e certificados para serem gerenciados como um grupo. Esses grupos são chamados anéis de chave.
Consulte Security Server RACF Command Language Reference (SA22-7687) para obter detalhes sobre o comando 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))
A amostra acima começa criando os perfis necessários e permitindo que o ID do usuário OMVSKERN acesse os anéis de chave. O ID do usuário utilizado deve corresponder ao ID do usuário codificado em /etc/inetd.conf para o daemon SSL RSE. A próxima etapa é criar um novo certificado auto-assinado com a etiqueta wd4zrse. Não é necessária senha. Esse certificado é, então, incluído em um anel de chave recém-criado (wd4zssl.racf). Assim como com o certificado, não é necessária senha para o anel de chave. A vida útil do certificado corresponde a um criado com keytool.
O resultado pode ser verificado com a opção list:
RACDCERT ID(omvskern) LIST Informações do certificado digital para o usuário OMVSKERN: Etiqueta: wd4zrse ID do Certificado: 2QjW1OXi0sXZ1aaEqZmihUBA Status: TRUST Data de Início: 24/05/2007 0h Data de Encerramento: 21/05/2017 23h59min59s Número de Série: >00< Nome do Emissor: >CN=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Nome do Assunto: >CN=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Tipo de Chave Privada: Não-ICSF Tamanho da Chave Privada: 1024 Associações de Anel: Proprietário do Anel: OMVSKERN Anel: >wd4zssl.racf<
Não execute esta etapa se utilizar o RACF para SSL do Sistema.
gskkyman é um programa z/OS UNIX baseado em shell e orientado por menus, que cria, preenche e gerencia um arquivo z/OS UNIX que contém chaves privadas, pedidos de certificado e certificados. Esse arquivo z/OS UNIX é chamado de banco de dados de chaves.
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 Menu do Banco de Dados 1 - Criar novo banco de dados 2 - Abrir banco de dados 3 - Alterar senha do banco de dados 4 - Alterar comprimento do registro do banco de dados 5 - Excluir banco de dados 6 - Criar arquivo de parâmetro-chave 0 - Sair do programa Digite o número da opção: 1 Digite o nome do banco de dados-chave (pressione ENTER para retornar ao menu): wd4zssl.kdb Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl Digite novamente a senha do banco de dados: rsessl Digite a expiração da senha em dias (pressione ENTER para nenhuma expiração): Digite o comprimento do registro do banco de dados (pressione ENTER para utilizar 2500): Banco de dados-chave /etc/wd4z/ssl/wd4zssl.kdb criado. Pressione ENTER para continuar. Menu do Key Management Banco de dados: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gerenciar chaves e certificados 2 - Gerenciar certificados 3 - Gerenciar pedidos de certificado 4 - Criar novo pedido de certificado 5 - Receber certificado solicitado ou um certificado de renovação 6 - Criar um certificado auto-assinado 7 - Importar um certificado 8 - Importar um certificado e uma chave privada 9 - Mostrar a chave padrão 10 - Armazenar senha do banco de dados 11 - Mostrar comprimento do registro do banco de dados 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 6 Tipo de Certificado 1 - Certificado CA com chave RSA de 1024 bits 2 - Certificado CA com chave RSA de 2048 bits 3 - Certificado CA com chave RSA de 4096 bits 4 - Certificado CA com chave DSA de 1024 bits 5 - Certificado do usuário ou do servidor com chave RSA de 1024 bits 6 - Certificado do usuário ou do servidor com chave RSA de 2048 bits 7 - Certificado do usuário ou do servidor com chave RSA de 4096 bits 8 - Certificado do usuário ou do servidor com chave DSA de 1024 bits Selecione o tipo de certificado (pressione ENTER para retornar ao menu): 5 Digite a etiqueta (pressione ENTER para retornar ao menu): wd4zrse Digite o nome do assunto para o certificado Nome comum (necessário): wd4z rse ssl Unidade organizacional (opcional): wd4z Organização (necessário): IBM Cidade/Localidade (opcional): Raleigh Estado/Província (opcional): NC País/Região (2 caracteres - necessário): EUA Digite o número de dias que o certificado permanecerá válido (padrão 365): 3650 Digite 1 para especificar nomes alternativos de assunto ou 0 para continuar: 0 Aguarde ..... Certificado criado. Pressione ENTER para continuar. Menu do Key Management Banco de dados: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gerenciar chaves e certificados 2 - Gerenciar certificados 3 - Gerenciar pedidos de certificado 4 - Criar novo pedido de certificado 5 - Receber certificado solicitado ou um certificado de renovação 6 - Criar um certificado auto-assinado 7 - Importar um certificado 8 - Importar um certificado e uma chave privada 9 - Mostrar a chave padrão 10 - Armazenar senha do banco de dados 11 - Mostrar comprimento do registro do banco de dados 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu 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
A amostra acima inicia criando um banco de dados de chaves chamado wd4zssl.kdb com a senha rsessl. Quando o banco de dados existe, é preenchido criando um novo certificado auto-assinado armazenado com a etiqueta wd4zrse e com a mesma senha (rsessl) que a utilizada para o banco de dados de chaves (esse é um requisito do RSE).
gskkyman aloca o banco de dados de chaves com uma máscara de bits de permissão 600 (muito segura) (só o proprietário tem acesso). A menos que o daemon utilize o mesmo ID do usuário que o criador do banco de dados de chaves, as permissões devem ser configuradas menos restritivas. 640 (o proprietário tem leitura/gravação, o grupo do proprietário tem leitura) ou 644 (o proprietário tem leitura/gravação, todos têm leitura) são máscaras úteis para o comando chmod.
O resultado pode ser verificado selecionando a opção Mostrar informações do certificado no submenu Gerenciar chaves e certificados:
$ gskkyman Menu do Banco de Dados 1 - Criar novo banco de dados 2 - Abrir banco de dados 3 - Alterar senha do banco de dados 4 - Alterar comprimento do registro do banco de dados 5 - Excluir banco de dados 6 - Criar arquivo de parâmetro-chave 0 - Sair do programa Digite o número da opção: 2 Digite o nome do banco de dados-chave (pressione ENTER para retornar ao menu): wd4zssl.kdb Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl Menu do Key Management Banco de dados: /etc/wd4z/ssl/wd4zssl.kdb 1 - Gerenciar chaves e certificados 2 - Gerenciar certificados 3 - Gerenciar pedidos de certificado 4 - Criar novo pedido de certificado 5 - Receber certificado solicitado ou um certificado de renovação 6 - Criar um certificado auto-assinado 7 - Importar um certificado 8 - Importar um certificado e uma chave privada 9 - Mostrar a chave padrão 10 - Armazenar senha do banco de dados 11 - Mostrar comprimento do registro do banco de dados 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1 Lista de Chaves e Certificados Banco de dados: /etc/wd4z/ssl/wd4zssl.kdb 1 - wd4zrse 0 - Retornar ao menu de seleção Digite o número da etiqueta (ENTER para retornar ao menu de seleção, p para lista anterior: 1 Menu Chave e Certificado Etiqueta: wd4zrse 1 - Mostrar informações do certificado 2 - Mostrar informações chave 3 - Definir chave como padrão 4 - Definir status de confiança do certificado 5 - Copiar certificado e chave para outro banco de dados 6 - Exportar certificado para um arquivo 7 - Exportar certificado e chave para um arquivo 8 - Excluir certificado e chave 9 - Alterar etiqueta 10 - Criar um certificado assinado e uma chave 11 - Criar um pedido de renovação do certificado 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1 Informações do Certificado Etiqueta: wd4zrse ID do Registro: 14 ID do Registro do Emissor: 14 Confiável: Sim Versão: 3 Número serial: 45356379000ac997 Nome do emissor: wd4z rse ssl wd4z O IBM Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NCUS Nome do assunto: wd4z rse ssl wd4z O IBM Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NCUS Data de efetivação: 24/05/2007 Data de expiração: 21/05/2017 Algoritmo de chave pública: rsaEncryption Tamanho da chave pública: 1024 Algoritmo de assinatura: sha1WithRsaEncryption ID exclusivo do emissor: Nenhum ID exclusivo do assunto: Nenhum Número de extensões: 3 Digite 1 para exibir extensões, 0 para retornar ao menu: 0 Menu Chave e Certificado Etiqueta: wd4zrse 1 - Mostrar informações do certificado 2 - Mostrar informações chave 3 - Definir chave como padrão 4 - Definir status de confiança do certificado 5 - Copiar certificado e chave para outro banco de dados 6 - Exportar certificado para um arquivo 7 - Exportar certificado e chave para um arquivo 8 - Excluir certificado e chave 9 - Alterar etiqueta 10 - Criar um certificado assinado e uma chave 11 - Criar um pedido de renovação do certificado 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0
Observe que os certificados existem, então o RSE pode começar a utilizar o SSL. Dependendo das definições escolhidas nas etapas acima, diferentes valores devem ser fornecidos em ssl.properties.
$ oedit ssl.properties
A configuração do host SSL agora está concluída e pode ser testada conectando-se ao cliente do Developer for System z. Como criamos uma nova configuração para uso pelo SSL (clonando a existente), uma nova conexão deve ser definida, utilizando as seguintes características:
STEPLIB=SYS1.SIEALNKE
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Na conexão, o host e o cliente começarão com alguma troca para configurar um caminho seguro. Parte dessa troca é o intercâmbio de certificados. Se o cliente do Developer for System z não reconhecer o certificado do host, perguntará ao usuário se esse certificado pode ser confiável.
Clicando no botão Concluir, o usuário pode aceitar esse certificado como confiável; depois disso, a inicialização da conexão continuará.
Quando um certificado é conhecido do cliente, esse diálogo não é mostrado novamente. A lista de certificados confiáveis pode ser gerenciada selecionando Janela > Preferências... > Sistemas Remotos > SSL, que mostra o seguinte diálogo:
Se a comunicação SSL falhar, o cliente retornará uma mensagem de erro. Mais informações estão disponíveis em arquivos de log diferentes (home/.eclipse/RSE/USERID/* e /tmp/rsedaemon.log), conforme descrito em Criação de Logs do RSE.
Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o APPC (Advanced Program-to-Program Communication) ou durante a verificação e/ou modificação de uma configuração existente.
Consulte MVS Planning: APPC/MVS Management (SA22-7599) e MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre o gerenciamento do APPC e os membros parmlib discutidos abaixo.
Observe que isso não abrange uma configuração completa do APPC, apenas destaca alguns aspectos principais que podem ser aplicáveis a seu site.
O membro SYS1.SAMPLIB(ATBALL) contém uma lista e descrições de todos os membros relacionados ao APPC (amostra) em SYS1.SAMPLIB.
O APPC/MVS armazena os dados de configuração nos membros SYS1.PARMLIB e em dois conjuntos de dados VSAM:
Um TP é um programa aplicativo que utiliza o APPC para se comunicar com um TP no mesmo sistema, ou em outro, para acessar recursos. A configuração do APPC para o Developer for System z ativa um novo TP chamado FEKFRSRV, mencionado como o serviço Comandos do TSO.
A tarefa de amostra listada na figura 14 é uma concatenação dos membros de amostra SYS1.SAMPLIB(ATBTPVSM) e SYS1.SAMPLIB(ATBSIVSM) e pode ser utilizada para definir os VSAMs do APPC.
//APPCVSAM JOB <parâmetros da tarefa> //* //* CUIDADO: Isso não é um procedimento JCL nem uma tarefa completa. //* Antes de utilizar esta amostra, você deverá fazer as seguintes //* modificações: //* 1. Altere os parâmetros da tarefa de acordo com os requisitos do sistema. //* 2. Altere ****** para o volume que conterá os VSAMs do 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)) //*
O APPC é uma implementação do protocolo SNA (Systems Network Architecture) LU 6.2. O SNA oferece formatos e protocolos que definem uma variedade de componentes SNA físicos e lógicos, como a LU (Logical Unit). A LU 6.2 é um tipo de unidade lógica desenvolvida especificamente para controlar a comunicação entre os programas aplicativos.
Para utilizar SNA no MVS, você precisa instalar e configurar o VTAM (Virtual Telecommunications Access Method). O VTAM deve estar ativo antes que as tarefas do sistema APPC possam ser utilizadas.
A parte específica APPC da configuração VTAM consiste em três etapas:
O ACBNAME de MVSLU01 utilizado no membro de amostra SYS1.SAMPLIB(ATBAPPL) pode ser utilizado para corresponder aos padrões do site, mas deve corresponder às definições no membro 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 o Communications Server bookshelf (F1A1BK61 para z/OS 1.7) para obter mais informações sobre a configuração do VTAM.
Para ativar e suportar o fluxo de conversações entre sistemas, os sites devem definir LUs entre quais sessões podem fazer ligação. Um site precisa definir, pelo menos, uma LU antes que o processamento de APPC/MVS possa ocorrer, mesmo quando o processamento APPC permanecer em um sistema único. As LUs são algumas das definições realizadas em SYS1.PARMLIB(APPCPMxx).
O serviço de comandos do TSO requer que o APPC seja configurado para ter uma LU de base que possa administrar pedidos de entrada e saída.
A definição da LU deve ser incluída no membro SYS1.PARMLIB(APPCPMxx) e precisa incluir os parâmetros BASE e SCHED(ASCH). O membro APPCPMxx também especifica quais conjuntos de dados VSAM de TP e de SI VSAM serão utilizados.
Figura 16 é um membro SYS1.PARMLIB(APPCPMxx) de amostra que pode ser utilizado para o serviço Comandos do TSO.
LUADD ACBNAME(MVSLU01) BASE SCHED(ASCH) TPDATA(SYS1.APPCTP) SIDEINFO DATASET(SYS1.APPCSI)
Quando um sistema possui vários nomes de LU, pode ser necessário fazer alterações, dependendo de qual LU o sistema seleciona como LU BASE. A LU BASE para o sistema é determinada por:
Se seu sistema possui uma LU com parâmetros BASE e NOSCHED, esta LU seria utilizada como a LU BASE mas o serviço de comandos do TSO não funcionará porque esta LU não possui um planejador de transações para administrar pedidos para a transação FEKFRSRV. Se esta LU não puder ser alterada para remoção do parâmetro NOSCHED, a variável de ambiente rsed.envvars (_FEKFSCMD_PARTNER_LU) pode ser configurada para a LU que possui BASE e SCHED(ASCH), tal como:
_FEKFSCMD_PARTNER_LU=MVSLU01
Consulte Customizar rsed.envvars, o Arquivo de Configuração para RSE para obter mais informações sobre rsed.envvars.
O planejador de transações APPC/MVS (nome padrão é ASCH) inicia e planeja programas de transações em resposta aos pedidos de entrada para conversões. O membro SYS1.PARMLIB(ASCHPMxx) controla seu funcionamento, por exemplo, com definições de classe da transação.
A classe de transação APPC utilizada para o serviço de comandos do TSO deve ter iniciadores APPC suficientes para permitir um iniciador para cada usuário da função Remote Edit-Compile-Debug.
O serviço de comandos do TSO também precisa das especificações padrão para ser especificado nas seções OPTIONS e TPDEFAULT.
Figura 17 é um membro SYS1.PARMLIB(ASCHPMxx) de amostra que pode ser utilizado para o serviço Comandos do TSO.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200) OPTIONS DEFAULT(A) TPDEFAULT REGION(2M) TIME(5) MSGLEVEL(1,1) OUTCLASS(X)
As alterações na configuração documentadas nas etapas acima agora podem ser ativadas. Isso pode ser feito de diversas maneiras, dependendo das circunstâncias:
Inclua esses comandos em SYS1.PARMLIB(COMMNDxx) para iniciá-los na inicialização do sistema.
Os comandos de console D APPC e D ASCH podem ser utilizados para verificar a configuração do APPC. Consulte MVS System Commands (GC28-1781) para obter mais informações sobre os comandos de console mencionados.
Quando o APPC/MVS está ativo, o serviço Comandos do TSO do Developer for System z pode ser definido, conforme descrito em (Opcional) Definir uma Transação APPC para o Serviço de Comandos do TSO.
A maneira documentada de definir a transação APPC é customizando e enviando hlq.SFEKSAMP(FEKAPPCC), em que hlq é igual ao qualificador de alto nível utilizado durante a instalação do Developer for System z (padrão FEK).
A transação APPC também pode ser definida interativamente por meio da interface ISPF do APPC, documentada em um white paper. Esse white paper também descreve como configurar a transação APPC a fim de coletar informações de contabilidade específicas ao usuário.
O white paper APPC and WebSphere Developer for System z (SC23-5885-00) está disponível na biblioteca na Internet do Developer for System z, http://www-306.ibm.com/software/awdtools/devzseries/library/
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos.
É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos neste documento em outros países. Consulte o representante IBM local para obter informações sobre os produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possa ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM, poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença podem ser enviados, por escrito, para:
Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
O parágrafo a seguir não se aplica ao Reino Unido ou a qualquer outro país no qual tais provisões sejam inconsistentes com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE MERCADO OU DE ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias explícitas ou implícitas em determinadas transações; portanto, esta disposição pode não se aplicar ao Cliente.
Essas informações podem conter imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso prévio.
Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de inteira responsabilidade do Cliente.
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença de Programa Internacional IBM ou de qualquer outro contrato equivalente.
Quaisquer dados de desempenho contidos aqui foram determinados em ambientes controlados. Portanto, os resultados obtidos em outros ambientes operacionais poderão variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em fase de desenvolvimento e não há garantia de que tais medidas sejam as mesmas nos sistemas normalmente disponíveis. Além do mais, algumas medidas podem ter sido estimadas por meio da extrapolação. Os resultados reais podem ser diferentes. Os usuários deste documento devem verificar os dados aplicáveis para seu ambiente específico.
As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade ou qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser dirigidas aos fornecedores destes produtos.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas e objetivos.
Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança a esses nomes e endereços utilizados por uma empresa comercial real é mera coincidência.
LICENÇA DE DIREITOS AUTORAIS:
Estas informações contêm programas de aplicativos de exemplos na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. Você pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram completamente testados em todas as condições. Portanto, a IBM não pode garantir ou implicar confiabilidade, manutenção, ou função destes programas. Você pode copiar, modificar e distribuir estes programas de exemplo de qualquer maneira sem pagamento à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com interfaces de programação de aplicativos da IBM.
Cada cópia ou parte desses programas de exemplo ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:
(C) (nome da sua empresa) (ano). Partes deste código são derivadas dos Programas de Exemplo da IBM Corp. (C) Copyright IBM Corp. _digite o ano ou anos_. Todos os direitos reservados.
Os termos a seguir são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países:
Java e todas as marcas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.
Microsoft, Windows, Windows NT e o logotipo Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada da The Open Group.
Outros nomes de empresas, produtos ou serviços, que podem estar indicados por asteriscos duplos (**), podem ser marcas registradas ou marcas de serviço de terceiros.