 |
| Bellacosa Mainframe na aventura onde o codigo nunca foi o misterio |
☕ Um Café no Bellacosa Mainframe
O Código Nunca Foi o Mistério
Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema
"Arqueologia não é procurar coisas velhas. É descobrir a história escondida por trás delas."
Se Indiana Jones tivesse escolhido Ciência da Computação em vez de Arqueologia, provavelmente terminaria trabalhando em um grande banco desenvolvendo COBOL.
Pode parecer exagero.
Mas pense comigo.
Indiana nunca encontrava o artefato logo na primeira sala.
Primeiro havia um mapa incompleto.
Depois uma caverna.
Uma armadilha.
Um diário escrito há cinquenta anos.
Um símbolo perdido.
Um templo subterrâneo.
Uma pedra falsa.
Uma ponte quebrada.
E somente depois de horas de investigação ele finalmente colocava as mãos no objeto que havia saído para procurar.
No Mainframe acontece exatamente a mesma coisa.
O gerente chega à sua mesa.
— "É só alterar umas dez linhas."
Você sorri.
Respira.
Abre o ISPF.
E cinco minutos depois percebe que acaba de entrar no equivalente computacional do Templo da Perdição.
Bem-vindo ao verdadeiro trabalho de um desenvolvedor COBOL.
Capítulo 1 — O Mapa Perdido
Todo aventureiro começa com um mapa.
O problema é que, no mundo corporativo, esse mapa quase nunca existe.
Ou pior.
Existe.
Mas foi escrito em 1994.
Em WordPerfect.
Impresso.
Escaneado.
Convertido para PDF.
E armazenado numa pasta chamada:
Documentacao_Final_Versao_Final_2_AgoraVai.pdf
Que obviamente está desatualizada desde 1998.
É nesse momento que o jovem programador descobre uma das maiores verdades da profissão.
O COBOL não é o sistema.
O programa é apenas uma pequena pedra dentro de uma pirâmide construída durante décadas.
Capítulo 2 — O Chicote Não é o COBOL
Muita gente acredita que dominar COBOL significa dominar Mainframe.
É o mesmo que dizer:
"Indiana Jones venceu porque sabia usar um chicote."
Não.
O chicote era apenas uma ferramenta.
O verdadeiro diferencial era compreender:
história
culturas
idiomas
símbolos
armadilhas
comportamento humano
Com COBOL acontece exatamente igual.
Conhecer:
MOVE
ADD
PERFORM
IF
READ
WRITE
é apenas aprender a usar o chicote.
O arqueólogo ainda nem entrou no templo.
Capítulo 3 — A Primeira Porta
Chega o chamado.
Modificar o programa FAT001.
Perfeito.
Onde ele está?
Ninguém sabe.
Começa então a expedição.
Primeira parada:
PDS COBOL
Nada.
Segunda parada.
LIBLOAD
Nada.
Terceira.
JCLLIB
Quarta.
PROCLIB
Quinta.
Scheduler
Somente depois de muito procurar você descobre:
JOBFIN01
↓
PROCFAT
↓
STEP040
↓
PGM=FAT001
Parabéns.
Você encontrou a porta do templo.
Agora começa a aventura.
Capítulo 4 — O Diário do Professor Ravenwood
Indiana Jones sempre encontrava um velho diário.
No Mainframe ele possui outro nome.
JCL.
O JCL é praticamente um diário de viagem.
Ele conta:
quem chamou o programa;
quais arquivos entram;
quais arquivos saem;
qual biblioteca foi usada;
quais parâmetros chegaram;
qual região executa;
qual ambiente está sendo utilizado.
Um simples trecho como:
//EXEC PGM=FAT001
parece insignificante.
Mas atrás dele existem dezenas de decisões arquitetônicas tomadas durante décadas.
O JCL responde perguntas que o próprio programa COBOL jamais responderá.
Capítulo 5 — As Pegadas na Poeira
Indiana observava pegadas.
Você observa datasets.
Imagine encontrar:
CLIENTE.GDG(+1)
Quem criou?
Quando?
Qual layout?
Possui compressão?
É VB?
FB?
RECFM?
LRECL?
Existe SORT anterior?
Existe IDCAMS?
Existe IEBGENER?
Cada dataset é uma pegada deixada por alguém que passou antes.
E cada pegada pode revelar uma história completamente diferente.
Capítulo 6 — O Labirinto dos Processamentos
Na imagem analisada, uma das partes mais brilhantes é justamente a existência de dois mundos:
Traitements Amont
e
Traitements Aval.
Pouca gente percebe a importância disso.
Imagine uma corrente.
Sistema A
↓
Sistema B
↓
Sistema C
↓
Sistema D
↓
Seu programa
O problema talvez tenha começado cinco programas antes.
Agora imagine o contrário.
Seu programa
↓
Financeiro
↓
PIX
↓
SPED
↓
Data Warehouse
↓
BI
↓
IA
Alterar um campo pode quebrar seis departamentos.
É como retirar uma pedra da parede de um templo maia.
Talvez nada aconteça.
Ou talvez toda a construção desabe.
Capítulo 7 — A Câmara das Armadilhas
Nos filmes existe sempre uma sala cheia de mecanismos mortais.
No Mainframe essa sala chama-se:
Regras de Negócio
Elas raramente aparecem documentadas.
Você encontra coisas como:
IF UF = "AM"
Por quê?
Silêncio.
Outro exemplo.
IF CODIGO = 37
Por quê?
Ninguém sabe.
Até que um veterano lembra.
— Em 1996 surgiu uma legislação especial.
Pronto.
Você acaba de resolver um mistério de trinta anos.
Curiosidade Bellacosa nº 1
Existe uma frase muito conhecida entre desenvolvedores experientes:
"Todo IF estranho possui uma história triste."
E normalmente ela envolve:
imposto;
banco central;
auditoria;
legislação;
cliente VIP;
bug ocorrido numa madrugada de domingo.
Capítulo 8 — O Cálice Sagrado Chama-se DB2
Muitos iniciantes acreditam que alterar uma tabela significa apenas executar:
ALTER TABLE
Longe disso.
Uma coluna nova pode afetar:
índices;
packages;
plans;
RUNSTATS;
REORG;
BIND;
stored procedures;
triggers;
views;
aplicações Java;
aplicações .NET;
relatórios;
APIs REST.
No filme, Indiana precisava escolher o cálice correto.
No Mainframe você precisa alterar a coluna correta.
Escolher errado custa muito mais caro que um filme de Hollywood.
Capítulo 9 — O Reino Invisível do CICS
Durante o dia:
Cliente consulta saldo.
À noite:
Batch recalcula saldo.
São dois mundos completamente diferentes.
Mas compartilham os mesmos dados.
É como duas expedições arqueológicas explorando entradas diferentes do mesmo templo.
Se um explorador mover uma pedra...
O teto pode cair sobre o outro.
Capítulo 10 — O Calendário Maia do Scheduler
Existe uma entidade misteriosa.
Poucos iniciantes lhe dão atenção.
Scheduler.
Ele sabe exatamente:
que horas tudo começa;
quanto cada JOB demora;
quem depende de quem;
qual janela operacional existe;
qual SLA precisa ser cumprido.
Imagine:
22:00 Recepção
22:30 Validação
23:10 DB2
00:20 COBOL
01:30 SPED
03:40 Banco Central
Você aumenta cinco minutos no processamento.
Agora tudo termina quinze minutos depois.
Às vezes isso significa apenas atraso.
Às vezes significa multa milionária.
Easter Egg nº 1 — A Pedra Rolante
Todo programador COBOL já viveu algo parecido.
Você altera uma linha.
Executa o teste.
Tudo funciona.
Vai para homologação.
Tudo funciona.
Vai para produção.
Então aparece uma "pedra rolante" gigantesca.
Não era seu programa.
Era um JOB executado apenas no último dia útil do mês, usando um parâmetro que ninguém lembrava existir.
A pedra não persegue Indiana Jones apenas no cinema.
Ela também aparece às 02h47 da manhã, durante o fechamento contábil.
Capítulo 11 — A Arqueologia Digital
Talvez a maior habilidade de um desenvolvedor Mainframe não seja programar.
Seja investigar.
Você vira uma mistura de:
arqueólogo;
historiador;
investigador;
detetive;
matemático;
contador;
psicólogo;
engenheiro.
Cada programa é uma civilização antiga.
Cada comentário:
* NÃO ALTERAR
é uma inscrição hieroglífica.
Cada COPYBOOK é um pergaminho.
Cada PDS é uma biblioteca de Alexandria.
Cada JOB é uma rota comercial entre impérios.
Passo a Passo — Como um Desenvolvedor Experiente Investiga uma Alteração
Antes de escrever qualquer linha de código, siga uma metodologia quase arqueológica:
Etapa 1 — Entenda o requisito
Não aceite frases como:
"É só mudar um IF."
Pergunte:
Qual problema de negócio será resolvido?
Existe documentação?
Quem é o usuário afetado?
Etapa 2 — Localize o programa
PDS fonte
Load Library
Histórico de versões
Chamadores
Programas chamados
Etapa 3 — Analise o JCL
Verifique:
EXEC PGM
DD Statements
GDGs
SYSIN
SYSOUT
PROCs
PARM
Etapa 4 — Descubra os arquivos
Para cada dataset pergunte:
Quem gera?
Quem consome?
Qual layout?
Existe versionamento?
Etapa 5 — Analise o banco
Tabelas
Índices
Views
Packages
Plans
Estatísticas
SQLs afetados
Etapa 6 — Verifique integrações
Existe:
CICS?
MQ?
Web Services?
z/OS Connect?
APIs?
Batch paralelo?
Etapa 7 — Procure regras escondidas
Nunca confie apenas na documentação.
Leia o código.
Leia comentários antigos.
Converse com analistas.
Converse com usuários.
Muitas regras vivem apenas na memória das pessoas.
Etapa 8 — Teste impacto
Pergunte sempre:
Quem depende disso?
Quem será afetado?
Quem vai perceber?
Curiosidade Bellacosa nº 2
Em muitos bancos existem programas COBOL executando diariamente há mais de quarenta anos.
Alguns foram escritos antes mesmo do nascimento dos desenvolvedores que hoje fazem sua manutenção.
É como entrar em uma tumba egípcia sabendo que o arquiteto original nunca imaginou que alguém, quatro décadas depois, ainda pisaria naquele corredor para instalar uma nova "porta secreta".
Easter Egg nº 2 — O "X" Nunca Marca o Lugar
Nos filmes, o mapa sempre mostra um enorme X indicando o tesouro.
No desenvolvimento corporativo acontece exatamente o contrário.
O chamado diz:
"Alterar o programa FAT001."
Você passa dois dias investigando e descobre que o problema verdadeiro está em:
um parâmetro no Scheduler;
um SORT que remove registros;
um COPYBOOK compartilhado;
uma VIEW DB2;
um arquivo recebido de outro sistema.
O X nunca marca o lugar certo. A jornada até ele é que revela onde o verdadeiro problema estava escondido.
Conclusão — O Tesouro Não é o Código
Quando iniciamos nossa jornada em COBOL, acreditamos que aprenderemos uma linguagem de programação.
Com o tempo percebemos que aprendemos algo muito maior.
Aprendemos engenharia de sistemas.
O programa COBOL é apenas a ponta visível de um enorme continente tecnológico formado por JCLs, PROCs, Scheduler, Db2, CICS, VSAM, arquivos, integrações, calendários operacionais e regras de negócio acumuladas ao longo de décadas.
É por isso que dois profissionais com o mesmo domínio da sintaxe podem ter desempenhos completamente diferentes. Um conhece os verbos da linguagem; o outro conhece a história do templo, onde estão as armadilhas, quais corredores desabam, onde ficam as passagens secretas e qual pedra jamais deve ser removida.
No universo Bellacosa Mainframe, o verdadeiro desenvolvedor COBOL não é apenas um programador. Ele é um explorador da computação corporativa, alguém que entra diariamente em ruínas digitais construídas por gerações de engenheiros e retorna trazendo o artefato mais valioso de todos: uma alteração segura, compreendida e confiável, capaz de preservar sistemas que movimentam bancos, governos, seguradoras e a economia mundial sem que milhões de usuários sequer percebam que uma aventura aconteceu durante a madrugada.
E, como diria um certo arqueólogo de chapéu e chicote, ao fechar mais um chamado aparentemente simples:
"O código pertence ao sistema... mas o conhecimento pertence a quem teve coragem de explorar o templo inteiro antes de alterar uma única linha."
Sem comentários:
Enviar um comentário