O que temos para esta semana?
Outro patrocinador. Confira clicando em um dos links acima.
Na seção Dicas, o que fazer depois da IPWIZARD.

Se você já instalou ou reconfigurou o TCP/IP no z/VM, provavelmente conhece a IPWIZARD.

Ela é aquela ferramenta prática que acompanha o sistema operacional e acelera a configuração inicial da pilha TCP/IP do z/VM. Com alguns comandos e respostas a perguntas objetivas, é possível obter um stack funcional em poucos minutos. É quase obrigatória durante a instalação do z/VM.

Mas é importante entender o que a IPWIZARD realmente entrega.

Ela cria uma configuração inicial, mínima e funcional. O objetivo é permitir o primeiro acesso, validar a conectividade básica e colocar o ambiente de pé.

Ela não substitui a revisão técnica posterior.

Depois da execução da ferramenta, continuam sob responsabilidade do administrador os ajustes de desempenho, a revisão dos serviços ativados, os limites de conexão, os timeouts, os parâmetros específicos do ambiente e a documentação final da configuração.

E é exatamente aí que mora o perigo.

Porque a configuração funciona.

E, quando funciona, muita gente deixa como está.

Quando a pilha TCP/IP do z/VM é ativada, ela procura seu arquivo de configuração inicial seguindo uma ordem de precedência.

De forma simplificada, a busca ocorre nesta sequência:

O primeiro arquivo encontrado é usado.

Se nenhum deles existir, a pilha TCP/IP não ativa normalmente e encerra com mensagem de erro.

A IPWIZARD cria justamente a terceira opção: o PROFILE TCPIP.

Ele é o arquivo genérico, funcional e conveniente. Mínimo.

E essa conveniência pode virar armadilha.

Porque o ambiente sobe, o ping responde, o primeiro acesso funciona e a configuração “temporária” começa a ganhar aparência de definitiva.

Em um ambiente bem cuidado, o ideal é que cada pilha TCP/IP tenha uma configuração identificável, específica para sua função, sua carga e suas políticas operacionais.

Em vez de depender indefinidamente do PROFILE TCPIP genérico, é recomendável criar um arquivo de configuração associado ao nome correto da máquina virtual ou, de preferência, ao nome do sistema.

É ali que o administrador deve ajustar os parâmetros, por exemplo, de ASSORTEDPARMS, revisar limites de conexão, definir timeouts coerentes, controlar serviços, documentar particularidades e registrar as decisões tomadas para aquele ambiente específico.

A configuração inicial permite sair do chão.

A configuração revisada permite voar com segurança.

Todo mundo já viu esse filme.

A IPWIZARD resolve o problema imediato.

E a configuração provisória vira configuração permanente.

O manual de instalação do z/VM orienta que, depois da execução da IPWIZARD, a configuração gerada seja revisada e ajustada para a realidade do ambiente. Os arquivos sample fornecidos pela IBM, como o PROFILE STCPIP, existem justamente para apoiar essa revisão.

Mas quantas vezes isso acontece de fato?

Na prática, o analista disponível naquele momento muitas vezes está concentrado em cumprir a tarefa para a qual foi escalado: executar o procedimento, seguir o script e entregar o acesso inicial.

Revisar parâmetros default?

“Depois a gente vê.”

E o depois raramente chega. Já me deparei com esse cenário muitas vezes.

Meses ou anos depois, o TCP/IP começa a apresentar comportamentos difíceis de diagnosticar: conexões lentas, timeouts inesperados, serviços expostos sem necessidade, consumo anormal de recursos ou diferenças inexplicáveis entre ambientes que deveriam se comportar da mesma forma.

Quando se investiga a origem, lá está ele: o PROFILE TCPIP genérico, criado na instalação inicial e mantido porque “funcionava” no dia da ativação.

A IPWIZARD é uma aliada no início. Mas não pode ser usada como desculpa no post-mortem.

Ela entrega um ponto de partida. Transformar esse ponto de partida em uma configuração otimizada, segura e documentada é responsabilidade do administrador.

Depois de executar a IPWIZARD, não considere o trabalho concluído antes de revisar pelo menos estes pontos:

1. Troque o perfil genérico por uma configuração específica

Evite depender indefinidamente do PROFILE TCPIP.

Crie um arquivo de configuração associado ao nome correto da máquina virtual TCP/IP ou ao nome do sistema, conforme a arquitetura do seu ambiente.

Isso facilita manutenção, auditoria, comparação entre ambientes e resolução de problemas futuros.

2. Compare a configuração gerada com os samples da IBM

Use os arquivos sample, como o PROFILE STCPIP, como referência técnica. Cada versão do z/VM traz um novo arquivo com as possíveis melhorias aplicadas no TCP/IP daquela versão.

Eles ajudam a identificar parâmetros omitidos, opções esquecidas e ajustes que a configuração inicial da IPWIZARD não contempla.

3. Revise os parâmetros em uso

Analise os parâmetros de TCP de acordo com a carga real do ambiente.

Itens como timeouts, buffers, limites e comportamento de conexões não devem permanecer no default apenas porque o sistema subiu.

Defaults são pontos de partida, não projeto final.

4. Revise serviços, portas e exposição

Confirme quais servidores e serviços realmente precisam estar ativos. Você realmente usa RSCSDNS?

Nem tudo que pode subir automaticamente deve subir automaticamente.

Verifique também comandos START, arquivos OBEYFILE, servidores auxiliares e qualquer definição que exponha serviços sem necessidade operacional.

5. Valide AUTOLOG e inicialização

Revise quais máquinas virtuais e serviços são iniciados automaticamente.

Um ambiente bem documentado precisa deixar claro o que sobe no IPL, o que depende da pilha TCP/IP, o que depende de outros serviços e qual é a sequência correta de ativação.

6. Documente cada decisão

A configuração final é sua, não da ferramenta.

Registre o motivo de cada alteração, especialmente quando houver ajuste de timeout, buffer, serviço, rota, dispositivo ou limite operacional.

A documentação que você escreve hoje pode ser a diferença entre resolver um incidente em quinze minutos ou passar uma madrugada inteira procurando a causa.

7. Teste com tráfego representativo

Não valide apenas com PING.

Teste acesso real, carga compatível com o uso esperado, comportamento de aplicações, resolução de nomes, conexões simultâneas, reinicialização da pilha e recuperação após falhas planejadas.

Conectividade básica não é homologação.

Quem chega antes escolhe os melhores lugares.

Mas quem não volta para revisar o que instalou acaba tropeçando nos próprios defaults.

A IPWIZARD é excelente para começar. Só não deve ser o ponto final.

E o assunto não se encerra aqui. Em uma das próximas edições, vou comentar outro tema importante:

O que fazer quando o TCP/IP não ativa? Existe uma porta dos fundos?

E não esqueça: se isto parece complicado, me chame e eu faço para você, pessoalmente. Um especialista em Communication Server, do z/OS, pode fazer isto? Claro que sim. Com dificuldade? Claro que sim. Demorando mais tempo que o necessário? Claro que sim. Apenas porque z/OS e z/VM são plataformas diferentes e distintas? Claro que sim.