Let the insurance companies come to you
Compare multiple car insurance quotes and find your best with LendingTree.
O que temos para esta semana?
Temos um patrocinador. Clique no anuncio acima para saber detalhes.
Na seção Institucional, Copa do Mundo e z/VM. Qual o problema comum aos dois.
Na seção História: como sobrevivi ao Bug do Milênio.
Na seção Dicas, comandos EXECIO/PIPE e SET VTOD.
Institucional

Copa do Mundo e z/VM
⚽ Onde estão os “Técnicos” do Mainframe?
A ausência de um técnico brasileiro no comando da Seleção chamou minha atenção e a de muitos nesta Copa do Mundo. Mas esse não foi o único fator que contribuiu para a eliminação do Brasil.
Durante os últimos quatro anos, falamos muito sobre formar e preparar novos técnicos. Em alguns casos, porém, profissionais brasileiros permaneceram em posições secundárias, enquanto se buscava no exterior quem assumiria efetivamente a função. A estratégia falhou pois não houve nenhum treinador brasileiro entre as 48 seleções classificadas.
Ao mesmo tempo, um outro aspecto importante parece não ter recebido a atenção necessária: a finalização.
Faltou transformar oportunidades em gols — por deficiência técnica, decisões equivocadas ou falta de preparação específica para os momentos decisivos.
E, sim, você já adivinhou: algo semelhante acontece no ecossistema do z/VM.
Para quem trabalha com Mainframe, essa escassez de profissionais capazes de “decidir o jogo” não é novidade. Ela reflete um fenômeno que enfrentamos diariamente: a crise de sucessão.
Assim como no futebol, onde a formação de base muitas vezes é sacrificada em nome de resultados imediatos, uma parte da nova geração de TI tem sido direcionada para ferramentas de abstração, low-code e nuvens públicas, sem necessariamente conhecer as camadas de infraestrutura que sustentam operações críticas.
O problema não está nessas tecnologias. Elas são importantes e têm seu espaço. O risco surge quando o profissional conhece apenas a superfície e nunca entra em contato com os fundamentos dos ambientes que mantêm empresas inteiras funcionando.
Quando aparece uma oportunidade de preparar novos especialistas, o profissional sênior muitas vezes é mantido em uma posição meramente consultiva, enquanto se procura uma solução externa que ainda desconhece as particularidades do ambiente.
O resultado é uma escassez crescente de analistas de Mainframe experientes não apenas em manter o jogo em andamento, mas em fazer o gol quando a situação exige.
No nosso ecossistema, as consequências são bastante concretas:
Dependência de equipes externas: empresas recorrem a profissionais que dominam procedimentos padronizados, mas ainda precisam conhecer as integrações, decisões históricas e características específicas de cada ambiente.
Risco de continuidade: sistemas críticos podem ficar desassistidos ou ser conduzidos por profissionais sem a experiência necessária para tomar decisões importantes às três da manhã.
Velocidade versus estratégia: enquanto a empresa aguarda a disponibilidade do fornecedor ou a formação de uma equipe, o negócio continua exigindo respostas imediatas.
Na Clovis Consulting, o diferencial é a execução direta.
O trabalho não é delegado a uma equipe júnior nem repassado sucessivamente entre profissionais. A execução é conduzida pelo especialista contratado, do planejamento à conclusão.
Já participei de muitas finais, desde a era do IBM 3090 até a atual geração z17.
Não é discurso de arquibancada. Estou em Data Centers desde 1984.
Também assisti a todos os jogos da Copa de 1970 — a primeira transmitida ao vivo e em cores, embora poucos brasileiros tivessem televisores coloridos — e acompanhei todas as edições desde então.
Experiência não se automatiza; acumula-se.
E aparece quando o jogo precisa ser decidido.
História

Os minutos finais
🕰️ 31/12/1999 — Entre o Bug do Milênio, barris de combustível e uma chuva de fogos
Hoje, muitas pessoas olham para o Bug do Milênio como uma lenda urbana, um exagero ou uma ameaça que nunca existiu.
Para quem estava na linha de frente, a realidade era muito diferente.
Eu trabalhava na IBM e me lembro da ansiedade nos Data Centers enquanto os últimos minutos de 1999 se esgotavam.
Passamos meses em uma jornada intensa de inventário, análise de impacto, correção de código, aplicação de patches e testes de virada.
O desafio não estava apenas no sistema operacional. Estava principalmente nas aplicações, bancos de dados, arquivos, interfaces e rotinas que armazenavam o ano com apenas dois dígitos.
Em cada uma delas, o “00” poderia significar 1900 ou 2000.
No ambiente VM/ESA — antecessor direto do atual z/VM — também era necessário verificar produtos, ferramentas, sistemas convidados e integrações que dependiam dessas datas.
A virada foi um sucesso não por sorte, mas por uma mobilização técnica sem precedentes.
Foi naquele período que ficou ainda mais claro que continuidade, integridade e responsabilidade operacional não são opcionais. Sistemas críticos não podem ser entregues a quem desconhece as consequências de cada decisão.
Naquela noite, ficou evidente que o Mainframe era — e continua sendo — parte do coração de muitas operações essenciais.
E corações não podem parar.
Eu estava alocado no projeto Follow the Sun, acompanhando a chegada do ano 2000 desde o Japão até a meia-noite no Brasil.
Nossa equipe observava o avanço dos fusos horários, verificando se surgiam ocorrências relacionadas a datas em cada região.
O Data Center também funcionava como retaguarda para qualquer cliente que enfrentasse problemas naquela noite.
Estávamos cercados por equipamentos atualizados, com patches recém-instalados, procedimentos documentados e planos de contingência preparados para diferentes cenários.
A infraestrutura havia sido planejada para manter a operação ininterrupta por até uma semana, se necessário.
Isso incluía três geradores a diesel de grande porte, equipados com motores de especificação naval, além de um caminhão-tanque carregado de combustível, estacionado a poucos metros do prédio.
Em outras palavras, estávamos literalmente cercados por barris de pólvora.
Mas o que não previmos foi a atuação da Lei de Murphy.
Faltavam aproximadamente cinco minutos para a virada quando o hotel vizinho iniciou sua queima de fogos do Réveillon.
Fomos surpreendidos pela vibração dos vidros das janelas internas, que reverberavam com os estouros dos fogos e rojões explodindo sobre nossas cabeças.
Parecia que estávamos no epicentro de um terremoto ou dentro de um vulcão em atividade.
A sessão de terror durou cerca de vinte minutos.
Pareceu uma eternidade.
Depois, a calmaria voltou.
Sobrevivemos — nós, o Data Center e o caminhão-tanque — ao terremoto artificial e ao Bug do Milênio.
Encerramos o plantão por volta das cinco horas da madrugada, sem ocorrências catastróficas, e seguimos para nossas comemorações domésticas.
O novo milênio havia começado.
E o mundo continuava funcionando.
Dicas

EXECIO, PIPE e SET VTOD
💡 Do EXECIO ao poder do PIPE — e o Bug de 2038
Nesta edição, temos duas dicas que se complementam: uma sobre eficiência no CMS e outra sobre preparação para o futuro.
A primeira é para quem ainda manipula arquivos no CMS exclusivamente por meio do comando EXECIO.
O EXECIO é robusto e continua adequado para muitas tarefas. Entretanto, em fluxos que exigem leitura, filtragem, transformação e gravação de grandes volumes de registros, ele pode obrigar o programador a controlar manualmente variáveis STEM, program stack e diversas etapas intermediárias.
É nesse tipo de cenário que o CMS Pipelines pode fazer diferença.
Com o comando PIPE, as operações podem ser organizadas em etapas modulares, ou stages, encadeadas em um único fluxo de processamento.
Em muitos casos, isso permite:
reduzir código REXX intermediário;
simplificar a movimentação dos dados;
tornar o processamento mais legível;
facilitar a manutenção;
reduzir o consumo de recursos.
Naturalmente, o ganho real depende do volume de dados, das stages utilizadas e do desenho da solução. Não existe uma regra segundo a qual PIPE sempre será superior ao EXECIO.
Existe, porém, uma boa prática: conhecer as duas alternativas e escolher a mais adequada para cada situação.
Quem aprende antes escolhe as melhores soluções — e quem testa antes evita as piores surpresas.
💰 A segunda dica é técnica e estratégica
Você já ouviu falar do Bug de 2038, também conhecido como Y2K38?
Em 19 de janeiro de 2038, às 03:14:07 UTC, sistemas que ainda representarem o Unix time em um inteiro assinado de 32 bits alcançarão o maior valor possível.
No segundo seguinte, aplicações não corrigidas poderão sofrer um overflow e interpretar a data de maneira incorreta, eventualmente retornando ao ano de 1901.
Parece distante?
Para o ciclo de vida de um Mainframe, é praticamente amanhã.
A arquitetura atual do z/VM não deve ser confundida com as limitações clássicas do Unix time de 32 bits. Isso, porém, não torna automaticamente imunes os sistemas convidados, bibliotecas, bancos de dados e aplicações executados sob seu controle.
Cada guest e cada aplicação que manipule datas precisa ser inventariado e testado de acordo com sua própria implementação.
E aqui surge uma das grandes vantagens do z/VM: a capacidade de criar verdadeiros laboratórios temporais.
É possível configurar máquinas virtuais isoladas com datas futuras ou passadas e observar como sistemas e aplicações reagem, sem alterar o relógio da LPAR real.
Um dos recursos disponíveis para isso é o comando:
SET VTOD
Ele permite ajustar o relógio TOD de uma máquina virtual, criando um ambiente controlado para testes de datas futuras.
Esse tipo de teste, entretanto, exige planejamento.
A alteração do relógio pode afetar:
certificados digitais;
logs;
sistemas de autenticação;
bancos de dados;
schedulers;
aplicações sincronizadas;
comunicações com ambientes externos.
Também é necessário verificar as autorizações e as opções de diretório aplicáveis em cada versão e configuração do z/VM.
Por isso, os testes devem ser realizados em ambientes isolados, com dependências conhecidas e critérios claros de validação.
Nós utilizamos extensivamente esse tipo de recurso durante os testes relacionados ao Bug do Milênio.
A estratégia poderá voltar a ser muito útil na preparação para 2038.
⏰ Quando começar?
Agora.
Iniciar hoje o inventário e os testes dos sistemas críticos aumenta a possibilidade de que, em 2038, sua equipe esteja apenas observando a calmaria — como fizemos em 1999 — enquanto outros ainda tentam descobrir onde está o problema.
Onze anos e meio passam muito rápido, especialmente quando as equipes já estão ocupadas com demandas que sempre parecem mais urgentes.
Para onde ir daqui? Fale comigo!


