 |
| Bellacosa Mainframe apresenta o IBM SMP/E |
☕
Um Café no Bellacosa MainframeO Mentalista Entra no CPD — O Dia em que Patrick Jane Olhou para um APPLY CHECK e Descobriu Quem Estava Mentindo sobre a PTF
Ou: como CSI, Global Zone, Target Zone, Distribution Zone, SYSMOD, FMID, HOLDDATA, HIPER, FIXCAT, RECEIVE, APPLY, ACCEPT, RESTORE e um programador COBOL iniciante descobriram que o SMP/E não lê pensamentos — ele apenas guarda evidências melhor do que todo mundo
São 03:17 da manhã.
Porque, evidentemente, todo problema realmente educativo em mainframe começa às 03:17.
O telefone toca.
Produção está funcionando.
Isso normalmente seria uma boa notícia.
Mas alguém resolve acrescentar:
— Precisamos instalar uma correção urgente.
Na tela aparece uma PTF.
O programador COBOL iniciante olha para aquilo com a mesma expressão de alguém que acabou de descobrir uma porta secreta atrás do PROCEDURE DIVISION.
O System Programmer pergunta:
— Você verificou a HOLDDATA?
Silêncio.
— Executou APPLY CHECK?
Mais silêncio.
— Conhece os requisites?
O silêncio agora já adquiriu status de documentação oficial.
Nesse instante, um homem entra no CPD carregando uma xícara de chá.
Não parece particularmente impressionado com o IBM Z, os monitores, os alertas nem com o fato de metade da equipe estar discutindo se deve ou não aplicar uma manutenção em produção.
Ele olha para a tela durante alguns segundos.
Depois olha para o programador.
— Você não sabe exatamente o que essa PTF faz.
— Como sabe?
— Porque você está olhando para o número dela esperando que ele lhe conte alguma coisa.
Patrick Jane sorri.
O operador franze a testa.
— E você entende de SMP/E?
— Não.
Ele toma um gole do chá.
— Mas entendo quando alguém está tentando tomar uma decisão sem observar as evidências.
Bem-vindo ao SMP/E.
E talvez essa seja uma das melhores maneiras de aprendê-lo.
Porque SMP/E não é essencialmente uma coleção de comandos.
É um sistema construído ao redor de uma obsessão muito parecida com a de um investigador:
nunca confie apenas no que alguém diz que aconteceu; descubra o que realmente aconteceu.
1. A primeira pista: SMP/E não é um instalador de PTF
O iniciante normalmente encontra SMP/E através de frases como:
“Usamos SMP/E para instalar manutenção no z/OS.”
A frase não está propriamente errada.
O problema é que ela é perigosamente incompleta.
Seria como dizer:
“Db2 serve para guardar dados.”
Ou:
“CICS serve para executar COBOL.”
Tecnicamente verdade.
Conceitualmente pobre.
SMP/E significa:
System Modification Program/Extended.
Sua função é administrar software e suas modificações dentro do ambiente z/OS.
Isso significa controlar coisas como:
o que está instalado;
quais modificações chegaram;
quais modificações foram aplicadas;
quais foram aceitas;
quais componentes foram alterados;
quais dependências existem;
quais correções substituem outras;
quais problemas conhecidos acompanham determinada manutenção;
quais alterações locais precisam ser preservadas.
Patrick Jane provavelmente resumiria assim:
“Você pensa que está investigando uma PTF. Na verdade está investigando a história dela.”
E essa história é justamente o que o SMP/E tenta preservar.
2. A cena do crime: software corporativo não permanece parado
Imagine instalar um produto IBM hoje.
Versão limpa.
Tudo documentado.
Tudo lindo.
Agora avance cinco anos.
Centenas de PTFs foram instaladas.
Algumas corrigiram APARs.
Outras foram substituídas posteriormente.
Uma equipe criou USERMODs.
Algumas correções possuem prerequisites.
Outras possuem coexistence requirements.
Uma manutenção crítica chegou depois.
Certos módulos foram modificados várias vezes.
Um novo release entrou no ambiente.
Agora alguém pergunta:
“Qual é exatamente o estado desse software?”
Sem um mecanismo estruturado para responder isso, você teria algo parecido com:
PROD_FINAL
PROD_FINAL2
PROD_FINAL_OK
PROD_FINAL_OK_MESMO
PROD_NAO_MEXER
PROD_ANTES_DA_CORRECAO
Patrick Jane olha para os nomes.
— Quem criou isso?
Ninguém responde.
Ele aponta para PROD_FINAL_OK_MESMO.
— O culpado está aqui.
O velho System Programmer suspira.
— Foi por isso que inventaram SMP/E.
3. CSI — a memória do investigador
Um dos conceitos mais importantes de SMP/E é o:
CSI — Consolidated Software Inventory.
Para o programador COBOL iniciante, vale pensar nele como a memória estruturada do SMP/E.
Não é simplesmente uma biblioteca contendo programas.
É um conjunto de informações que permite ao SMP/E conhecer o estado dos componentes e modificações que administra.
Dentro dessa arquitetura aparecem três conceitos fundamentais:
GLOBAL ZONE
TARGET ZONE
DISTRIBUTION ZONE
E aqui surge um erro comum.
Não pense:
GLOBAL = desenvolvimento
TARGET = homologação
DISTRIBUTION = produção
Não.
Essas zonas têm outra função.
Patrick Jane pega três cartões e coloca sobre uma mesa.
No primeiro escreve:
GLOBAL
No segundo:
TARGET
No terceiro:
DISTRIBUTION
— Não são lugares — diz ele. — São perspectivas diferentes sobre o mesmo caso.
É uma excelente maneira de pensar.
4. Global Zone — o arquivo geral do caso
A Global Zone contém informações administrativas de alcance global dentro daquele ambiente SMP/E.
É onde o SMP/E mantém conhecimento importante sobre material recebido e sobre as zonas que administra.
Podemos simplificar:
GLOBAL
|
+---------+---------+
| |
TARGET DISTRIBUTION
A Global Zone funciona como uma espécie de índice administrativo da investigação.
Ela sabe que determinadas coisas existem.
Mas isso ainda não significa que estejam executando.
Essa diferença será fundamental quando chegarmos ao RECEIVE.
5. Target Zone — onde a modificação entra em jogo
A Target Zone representa informações relacionadas ao software instalado nas Target Libraries.
Esse é o ambiente utilizado para execução.
Quando determinada manutenção é aplicada, é ali que encontramos o estado correspondente ao software modificado para utilização.
Uma representação didática:
TARGET ZONE
|
v
TARGET LIBRARIES
|
v
SOFTWARE UTILIZADO
O iniciante normalmente chega aqui e pensa:
“Então APPLY coloca a correção no sistema?”
De maneira simplificada, sim.
Mas existe um mundo inteiro entre receber uma PTF e chegar a esse ponto.
E é exatamente aí que mora a diferença entre um profissional cuidadoso e alguém que acredita que manutenção consiste em copiar arquivos.
6. Distribution Zone — a referência controlada
A Distribution Zone representa as informações relacionadas às Distribution Libraries.
Essas bibliotecas funcionam como uma referência de distribuição controlada pelo SMP/E.
Quando ocorre ACCEPT, a manutenção correspondente é incorporada nesse universo.
Portanto temos uma ideia importante:
TARGET
!=
DISTRIBUTION
E essa diferença explica por que:
APPLY
não significa a mesma coisa que:
ACCEPT
Voltaremos a isso.
Patrick Jane observa o programador anotando.
— Está começando a perceber.
— O quê?
— Que SMP/E não pensa em “arquivo novo” e “arquivo velho”. Ele pensa em estado.
Exatamente.
7. SYSMOD — o suspeito finalmente tem nome
No universo SMP/E encontramos SYSMODs.
System Modifications.
Eles representam modificações administradas pelo SMP/E.
Entre as categorias fundamentais encontramos:
FUNCTION
PTF
APAR
USERMOD
Aqui existe uma distinção importante.
O infográfico que originou nossa investigação apresentava também FMID próximo desses conceitos.
Mas FMID não deve ser entendido simplesmente como uma quinta categoria equivalente.
FMID — Function Modification Identifier identifica uma função/produto dentro desse ecossistema.
Enquanto FUNCTION, PTF, APAR e USERMOD descrevem tipos fundamentais de SYSMOD, FMID ajuda a estabelecer a qual função determinada manutenção está relacionada.
Parece detalhe.
Não é.
Mainframe é uma plataforma na qual detalhes aparentemente burocráticos frequentemente determinam se você sabe o que está modificando.
8. FUNCTION — quando uma função entra no universo SMP/E
Uma FUNCTION SYSMOD introduz uma função no ambiente controlado pelo SMP/E.
Pode representar a base de determinado produto ou funcionalidade.
Pense nisso como o primeiro capítulo do prontuário.
Depois dela chegam modificações.
9. APAR e PTF — problema e solução não são exatamente a mesma coisa
Outro erro comum é usar APAR e PTF como sinônimos.
APAR significa:
Authorized Program Analysis Report.
Ele está relacionado à identificação e tratamento formal de um problema.
A correção correspondente pode posteriormente ser disponibilizada como uma PTF — Program Temporary Fix.
Didaticamente:
problema identificado
|
v
APAR
|
v
solução distribuída
|
v
PTF
A realidade pode envolver nuances adicionais, mas para o iniciante essa separação já evita muita confusão.
Patrick Jane ergue a sobrancelha.
— Então APAR é o crime e PTF é o policial?
O System Programmer pensa alguns segundos.
— Não exatamente.
— Melhor ainda. Significa que você está aprendendo.
10. USERMOD — quando sua própria empresa entra na história
Agora temos algo particularmente interessante:
USERMOD.
Imagine que a instalação precise modificar um elemento fornecido pelo produto.
Poderia simplesmente alterar uma library diretamente.
Funcionaria.
Por algum tempo.
Até chegar uma PTF que modifica exatamente o mesmo elemento.
Agora você possui:
IBM modification
+
local modification
+
nova manutenção
Quem vence?
Quem sabe o que aconteceu?
Quem preservou documentação?
SMP/E permite registrar modificações locais através de USERMODs.
Isso transforma uma alteração invisível em algo administrável.
É uma mudança filosófica enorme.
Não é:
“Mexemos no módulo.”
É:
“Existe uma modificação local formalmente conhecida pelo sistema de gerenciamento.”
Patrick Jane sorri.
— Finalmente alguém deixou impressões digitais.
11. Dependências — ninguém trabalha sozinho
Aqui SMP/E começa a ficar realmente fascinante.
Imagine:
PTF A
|
+---- requires PTF B
|
+---- requires PTF C
|
+---- requires PTF D
Agora imagine centenas disso.
Uma PTF pode depender de outra.
Uma correção pode superseder outra.
Uma USERMOD pode entrar em conflito com manutenção nova.
Determinados requisites precisam ser satisfeitos antes que uma alteração possa ser instalada corretamente.
Isso transforma o conjunto de manutenção em um verdadeiro grafo de dependências.
Se você conhece:
npm;
Maven;
Gradle;
pip;
apt;
dnf;
o problema conceitual deveria parecer familiar.
O mainframe já enfrentava isso muito antes de dependency management virar assunto cotidiano no desenvolvimento moderno.
12. RECEIVE — a evidência chegou à delegacia
Agora chegamos ao primeiro dos comandos famosos.
RECEIVE
O iniciante costuma pensar:
“RECEIVE instala a PTF.”
Não.
RECEIVE significa que o material entra formalmente no domínio controlado pelo SMP/E.
Imagine uma delegacia recebendo uma caixa de evidências.
A caixa chegou.
Foi registrada.
Foi identificada.
Foi armazenada.
Mas ninguém apresentou aquilo ao tribunal ainda.
Isso é RECEIVE.
Podemos usar uma analogia simples:
RECEIVE = chegou ao almoxarifado
APPLY = foi instalado
ACCEPT = virou parte consolidada da referência
Essa analogia é imperfeita.
Mas é excelente pedagogicamente.
13. O MCS — a ficha que acompanha a modificação
Agora surge um elemento delicioso para quem gosta da arqueologia elegante do mainframe:
Modification Control Statements — MCS.
Você pode encontrar estruturas com elementos como:
++PTF(...)
++VER(...)
++MOD(...)
Os dois sinais de mais parecem ter sido projetados deliberadamente para assustar programadores Java.
Mas eles têm função.
Essas statements descrevem ao SMP/E informações necessárias para compreender aquela modificação.
Qual é?
A qual função pertence?
O que modifica?
Quais elementos estão envolvidos?
Quais relações existem?
Em outras palavras:
o código é o corpo da evidência; MCS é a documentação forense.
14. HOLDDATA — Patrick Jane encontra a informação que todos ignoraram
Voltamos ao incidente das 03:17.
Existe uma PTF.
Alguém diz:
— Precisamos instalar imediatamente.
Jane pergunta:
— Existe HOLDDATA?
Silêncio.
Aqui está um dos conceitos mais importantes da trilha inteira.
HOLDDATA contém informações que podem indicar que determinado SYSMOD possui condições que precisam ser conhecidas antes de seu processamento.
Isto pode significar:
“Há um problema conhecido.”
“Existe uma ação necessária.”
“Leia antes de continuar.”
O programador iniciante pergunta:
— Então é como um alerta?
Sim.
Mas é melhor pensar como inteligência operacional associada à manutenção.
A PTF diz:
“Eu existo.”
A HOLDDATA pergunta:
“Você sabe no que está se metendo?”
15. ERROR HOLD — existe problema conhecido aqui
Uma categoria importante envolve ERROR HOLD.
Ela pode indicar problema conhecido relacionado àquela manutenção.
Isso é extraordinariamente importante.
Imagine instalar uma correção destinada a resolver um problema e introduzir outro já conhecido.
Sem informação adequada:
surpresa.
Com HOLDDATA:
decisão consciente.
Existe uma diferença imensa entre as duas coisas.
16. HIPER — quando nem toda PTF merece a mesma prioridade
Outro conceito importantíssimo é:
HIPER — High Impact or PERvasive.
Certos problemas possuem impacto suficientemente importante para receber classificação especial.
E aqui SMP/E passa de simples instalação para gestão de risco.
Imagine 800 PTFs disponíveis.
O administrador não precisa apenas perguntar:
“Quais existem?”
Ele precisa perguntar:
“Quais realmente importam para o meu ambiente?”
É aí que metadata de manutenção torna-se extremamente valiosa.
17. FIXCAT — manutenção com contexto
Outro recurso importante é FIXCAT.
Fix Categories.
A ideia é associar determinadas correções a categorias relevantes.
Isso ajuda a responder perguntas muito melhores.
Em vez de:
“Quais PTFs ainda não instalei?”
podemos nos aproximar de:
“Quais correções estão relacionadas àquilo que estou tentando fazer?”
Essa mudança parece pequena.
Mas representa a transição de inventário para inteligência de manutenção.
18. APPLY CHECK — o momento Mentalista do SMP/E
Chegamos ao meu comando favorito para ensinar a iniciantes:
APPLY CHECK
Por quê?
Porque ele contém praticamente toda uma filosofia operacional.
Você está dizendo:
“SMP/E, diga-me o que aconteceria se eu executasse esta instalação.”
Mas ainda não está efetivamente aplicando aquela manutenção.
No universo moderno chamaríamos isso facilmente de:
dry-run
Patrick Jane apontaria para a tela:
— Está vendo?
— O quê?
— Você não precisa esperar o crime acontecer para procurar pistas.
É exatamente isso.
Antes de APPLY, você pode analisar.
Dependências.
HOLDs.
Requisites.
Condições.
Mensagens.
Resultados.
E somente depois tomar a decisão.
19. Nunca ignore as mensagens
O iniciante frequentemente procura apenas:
RC=00
Se recebeu zero, comemora.
Se recebeu oito, entra em pânico.
Esse comportamento precisa morrer cedo.
Troubleshooting de SMP/E exige observar:
mensagens;
sequence of events;
SYSMODs envolvidos;
requisites;
HOLDs;
zonas;
bibliotecas;
return codes;
relatórios.
Mensagens começando por:
GIM...
fazem parte do idioma operacional do SMP/E.
O System Programmer experiente não pergunta apenas:
“Qual foi o RC?”
Pergunta:
“O que o job realmente informou?”
Patrick Jane aprovaria.
Porque investigadores ruins procuram confissões.
Investigadores bons procuram contexto.
20. APPLY — agora sim mexemos no ambiente
Depois de receber, analisar HOLDDATA, verificar dependências e executar CHECK, chegamos a:
APPLY
Agora a manutenção é instalada em relação ao Target.
Aqui o nível de responsabilidade muda.
Antes estávamos preparando evidência.
Agora estamos alterando o estado do software utilizado.
Por isso o processo deveria parecer algo como:
RECEIVE
|
v
HOLDDATA
|
v
APPLY CHECK
|
v
ANALYSIS
|
v
APPLY
Nunca:
baixou
|
v
APPLY
|
v
rezar
Embora algumas empresas aparentemente tenham adotado o segundo método durante certas décadas.
21. Testar é parte da manutenção
Após APPLY existe uma janela preciosa.
APPLY
|
v
TARGET
|
v
TEST
Isso deveria fazer parte explicitamente da mentalidade do iniciante.
Software alterado precisa ser validado.
O fato de SMP/E concluir uma operação não significa automaticamente:
“Sua aplicação de negócio está perfeita.”
SMP/E administra manutenção.
Seu ambiente precisa verificar comportamento.
Testes técnicos.
Testes funcionais.
Smoke tests.
Validações específicas.
Dependendo do componente:
IPL.
Restart.
CICS recycle.
Db2 considerations.
Subsystem actions.
Tudo depende do software e da mudança.
22. ACCEPT — o erro clássico é pensar que é APPLY 2.0
Depois de testar e validar, chegamos ao:
ACCEPT
Esse comando possui significado diferente.
Ele consolida a manutenção correspondente no universo das Distribution Libraries.
Por isso APPLY e ACCEPT representam momentos distintos.
Didaticamente:
RECEIVE
|
v
APPLY
|
v
TEST
|
+---- PROBLEM ---> RECOVERY
|
v
ACCEPT
O intervalo entre APPLY e ACCEPT possui importância operacional.
Não trate ACCEPT como simplesmente:
“Agora aperto o segundo botão.”
Ele representa outra decisão.
23. ACCEPT CHECK — sim, investigue de novo
Se APPLY CHECK é importante, ACCEPT CHECK segue a mesma filosofia:
“Antes de consolidar, quero entender o que acontecerá.”
É uma mentalidade que deveria acompanhar qualquer profissional de infraestrutura:
simule
analise
execute
valide
consolide
Essa sequência não pertence apenas ao SMP/E.
Pertence à engenharia madura.
24. RESTORE — todo bom plano precisa saber voltar
Agora imagine que algo deu errado depois do APPLY.
Dependendo do estado e das condições da manutenção, RESTORE entra como parte das capacidades de recuperação.
Esse é outro conceito gigantesco para um iniciante:
Uma mudança não está completamente planejada enquanto o caminho de retorno não foi entendido.
Antes de executar:
APPLY
a pergunta não deve ser apenas:
“Como instalo?”
Também precisa existir:
“Como me recupero?”
Essa pergunta distingue laboratório de produção.
25. REJECT — removendo aquilo que ainda não deveria permanecer
Dentro da administração SMP/E também encontramos REJECT, associado à remoção/rejeição de determinados SYSMODs recebidos conforme contexto apropriado.
Mais uma vez aparece a ideia de estado.
Material pode:
chegar;
ser conhecido;
ser aplicado;
ser removido;
ser aceito;
ser rejeitado.
SMP/E não está apenas manipulando bytes.
Ele está administrando transições de estado.
26. LIST e REPORT — o investigador começa a fazer perguntas
Um curso que ensine apenas:
RECEIVE
APPLY
ACCEPT
ensina SMP/E como alguém ensinaria SQL apenas com:
INSERT
UPDATE
DELETE
e esquecesse:
SELECT
Você precisa ser capaz de perguntar ao sistema:
“O que você sabe?”
É aí que LIST, REPORT e outras formas de consulta tornam-se extremamente importantes.
Um administrador precisa investigar.
Quais SYSMODs existem?
Qual é o estado?
Quais problemas estão registrados?
Qual manutenção falta?
Que relações estão presentes?
SMP/E também é uma ferramenta de interrogação do inventário de software.
27. REPORT ERRSYSMODS — procurando suspeitos perigosos
Um dos exemplos interessantes de análise é:
REPORT ERRSYSMODS
Utilizado juntamente com informações relevantes de HOLDDATA, ajuda a analisar situações relacionadas a SYSMODs problemáticos e manutenção correspondente.
Isso representa novamente aquela filosofia:
Não espere descobrir o problema depois de tropeçar nele.
Procure informações sobre problemas conhecidos.
Patrick Jane fecha os olhos.
— O criminoso cometeu um erro.
— Qual?
— Ele achou que ninguém consultaria o relatório.
28. RECEIVE ORDER — o SMP/E descobriu a Internet
Muita gente imagina SMP/E como uma espécie de ritual envolvendo fitas magnéticas trazidas por uma van da IBM.
A realidade moderna é diferente.
Existe:
RECEIVE ORDER
que permite aquisição eletrônica de manutenção e informações associadas através dos mecanismos correspondentes de service delivery.
Isso pode inclusive fazer parte de processos automatizados.
Então temos algo como:
IBM SERVICE
|
v
RECEIVE ORDER
|
+---- PTF
|
+---- HOLDDATA
|
v
SMP/E
O dinossauro está online.
E, ao contrário de alguns sistemas modernos, ainda lembra perfeitamente o que instalou vinte anos atrás.
29. SMP/E e automação — não confunda antigo com manual
Um erro recorrente na tecnologia é:
antigo = manual.
Não necessariamente.
Processos de obtenção de manutenção podem ser automatizados.
Jobs podem ser estruturados.
Relatórios podem ser analisados.
Rotinas de manutenção podem ser padronizadas.
O verdadeiro objetivo da automação não é transformar SMP/E em:
AUTOAPPLY EVERYTHING
Pelo amor do Sysplex, não.
É automatizar tarefas repetitivas enquanto preserva:
controle + análise + aprovação + auditabilidade.
30. O fluxo completo do caso
Patrick Jane caminha até o quadro branco.
Apaga tudo.
E escreve:
SERVICE / SYSMOD
|
v
RECEIVE
|
v
HOLDDATA
|
v
APPLY CHECK
|
+------+------+
| |
REQUISITES HOLDS
| |
+------+------+
|
v
ANALYSIS
|
v
APPLY
|
v
TARGET LIBRARIES
|
v
TEST / VALIDATION
/ \
FAIL OK
| |
v v
RESTORE ACCEPT CHECK
|
v
ACCEPT
|
v
DISTRIBUTION LIBRARIES
|
v
REPORT / AUDIT
O programador COBOL olha para o desenho.
— Agora entendi.
Jane sorri.
— Não. Agora você sabe quais perguntas fazer.
Essa provavelmente é a melhor definição de aprendizagem técnica que existe.
31. Exercício prático — o caso da PTF desaparecida
Se eu montasse essa trilha para um iniciante, o projeto final não teria vinte perguntas de múltipla escolha.
Eu entregaria um caso.
Missão
Uma nova manutenção precisa ser instalada.
O aluno deverá:
identificar a função correspondente;
localizar o FMID;
analisar o SYSMOD;
executar RECEIVE;
examinar HOLDDATA;
identificar requisitos;
executar APPLY CHECK;
interpretar mensagens SMP/E;
resolver um prerequisite propositalmente ausente;
executar APPLY;
validar Target Libraries;
executar testes;
simular um problema;
determinar estratégia de recovery;
utilizar RESTORE quando apropriado;
reaplicar corretamente;
executar ACCEPT CHECK;
executar ACCEPT;
gerar REPORT;
documentar todo o procedimento.
Agora sim temos treinamento.
O aluno não decorou comandos.
Ele administrou uma mudança.
32. Dica Bellacosa para quem vem de COBOL
Programadores COBOL frequentemente ficam assustados com SMP/E porque ele parece pertencer a outro universo.
Mas você já possui boa parte da mentalidade necessária.
COBOL ensina disciplina.
Mainframe ensina estado.
JCL ensina dependência entre etapas.
Db2 ensina integridade.
CICS ensina contexto transacional.
RACF ensina que nada deveria acontecer sem autorização adequada.
SMP/E acrescenta:
mudança controlada.
Você pode imaginar o ecossistema como uma cidade:
COBOL = trabalhadores
CICS = central de atendimento
Db2 = cartório
RACF = polícia
JES2 = logística
WLM = controle de tráfego
SMF = câmeras de segurança
SMP/E = departamento que sabe exatamente
quais peças da cidade foram substituídas
E quando Patrick Jane chega?
Ele simplesmente lê o SMF enquanto toma chá.
33. Easter egg — Red John instalou uma USERMOD
Às 04:42, toda a manutenção finalmente funciona.
O programador prepara-se para sair.
Patrick Jane continua olhando para uma saída do SMP/E.
— Temos outro problema.
Todos congelam.
— O quê?
Ele aponta.
Existe uma USERMOD antiga.
Sem documentação atual.
Modifica exatamente o mesmo elemento envolvido na manutenção.
No comentário existe apenas:
/* DO NOT REMOVE - IMPORTANT */
Jane sorri.
— Encontramos nosso Red John.
O System Programmer começa a rir.
O programador COBOL não entende.
Ainda.
Daqui a quinze anos entenderá perfeitamente.
34. A verdadeira lição do SMP/E
Depois de muitas páginas, dezenas de conceitos e uma quantidade ligeiramente irresponsável de café, podemos finalmente responder:
Para que serve SMP/E?
Uma resposta superficial:
Para instalar manutenção no z/OS.
Uma resposta melhor:
Para controlar instalação e manutenção de software.
Uma resposta ainda melhor:
Para manter conhecimento estruturado sobre componentes, modificações, dependências e níveis de software administrados dentro do z/OS.
Mas existe uma resposta Bellacosa:
SMP/E existe para impedir que o futuro precise adivinhar o que o passado fez.
Isso é tremendamente importante.
Sistemas críticos vivem décadas.
Equipes mudam.
Funcionários se aposentam.
Fornecedores atualizam produtos.
Arquiteturas evoluem.
Documentações desaparecem.
Memórias humanas falham.
Mas alguém precisa continuar sabendo:
o que foi instalado?
quando?
sobre qual produto?
qual dependência existia?
qual correção substituiu qual?
qual modificação local estava presente?
qual problema conhecido existia?
qual é o estado atual?
Essa é a inteligência que SMP/E tenta preservar.
35. Patrick Jane fecha o caso
São 05:03.
Produção está estável.
A PTF foi aplicada.
Os testes passaram.
A equipe documentou a mudança.
HOLDDATA foi analisada.
Requisites foram satisfeitos.
Ninguém executou comandos no escuro.
O programador COBOL, que algumas horas antes achava que SMP/E era apenas “aquela coisa que instala PTF”, olha novamente para o CSI.
Agora ele enxerga outra coisa.
História.
Relações.
Estado.
Evidências.
Patrick Jane termina o chá.
— Então você realmente não lê pensamentos? — pergunta o programador.
Jane sorri.
— Quase nunca é necessário.
Ele aponta para o spool.
— As pessoas deixam pistas por toda parte.
O velho System Programmer concorda.
— Principalmente quando esquecem de olhar a HOLDDATA.
Jane caminha para a saída.
Antes de atravessar a porta, vira-se uma última vez.
— E execute CHECK primeiro.
O programador ri.
— Sempre?
Patrick Jane olha para ele.
— Você pretende descobrir em produção que estava errado?
Silêncio.
Ele desaparece pelo corredor.
No monitor permanece:
RECEIVE
↓
ANALYZE
↓
APPLY CHECK
↓
APPLY
↓
TEST
↓
ACCEPT
E talvez seja esse o verdadeiro segredo do SMP/E.
Ele não prevê o futuro.
Ele faz algo muito mais útil:
obriga você a investigar o presente antes de modificá-lo.
☕🦖
E, no mainframe, prevenção continua sendo uma habilidade quase sobrenatural.
