Translate

sexta-feira, 1 de janeiro de 2010

☕🔥 BUG DO MILÊNIO (Y2K) — O DIA EM QUE O MUNDO DESCOBRIU QUE O FUTURO CABIA EM 2 DÍGITOS

 

Bellacosa Mainframe e o bug do milenio y2k

☕🔥 BUG DO MILÊNIO (Y2K) — O DIA EM QUE O MUNDO DESCOBRIU QUE O FUTURO CABIA EM 2 DÍGITOS

Uma visão 10 anos depois

O Bug do Milênio não foi apenas um problema técnico.

Foi:

  • um choque filosófico,

  • um terremoto econômico,

  • uma guerra entre gerações tecnológicas,

  • um divisor entre o mundo centralizado dos mainframes e o mundo distribuído dos PCs,

  • e talvez o maior projeto coletivo da história da computação.

O mais fascinante?

O problema foi previsto em 1958.
E ignorado por quase 40 anos.


☕ COMO TUDO COMEÇOU

O mundo em 1958

Em 1958:

  • COBOL ainda estava nascendo,

  • memória era absurdamente cara,

  • armazenamento era microscópico,

  • computadores ocupavam salas inteiras,

  • e cada byte economizado importava.

Um IBM 1401 tinha:

  • cerca de 2 KB de memória.

DOIS KILOBYTES.

Hoje uma foto de WhatsApp é milhões de vezes maior.


☕ O PECADO ORIGINAL DA COMPUTAÇÃO CORPORATIVA

Datas eram gravadas assim:

Data RealGravado
196262
197575
198989

Por quê?

Porque:

  • economizava espaço,

  • reduzia custo,

  • diminuía I/O,

  • cabia nos cartões perfurados,

  • acelerava processamento.

Num cartão de 80 colunas:

  • dois bytes eram preciosos.


☕ BOB BEMER — O “PROFETA IGNORADO”

Bob Bemer, da IBM:

  • percebeu imediatamente o risco,

  • tentou alertar:

    • IBM,

    • ISO,

    • governos,

    • programadores.

Ele basicamente dizia:

“Um dia 99 vai virar 00.”

Mas ninguém queria ouvir.

Porque em 1958:

  • o ano 2000 parecia ficção científica.


☕ O PROBLEMA REAL NÃO ERA A DATA

Aqui está o detalhe profundo que muita gente não entende:

O problema NÃO era “mostrar 00”.

O problema era:

☕ LÓGICA DE NEGÓCIO

Exemplo:

Data
991228
000105

O sistema comparava numericamente:

IF DT-PAGAMENTO > DT-VENCIMENTO

E então:

000105 < 991228

O computador concluía:

“2000 aconteceu ANTES de 1999.”

E isso quebrava:

  • juros,

  • seguros,

  • aposentadorias,

  • vencimentos,

  • cálculo atuarial,

  • bolsas,

  • bancos,

  • aviação,

  • energia,

  • telecom.


☕ O VERDADEIRO PÂNICO

O medo nunca foi:

  • “o computador mostrar data errada”.

O medo era:

☠️ EFEITO CASCATA

Porque sistemas estavam interligados.

Um erro de data poderia:

  • invalidar transações,

  • gerar loop infinito,

  • corromper arquivos,

  • travar batch noturno,

  • derrubar compensação bancária,

  • falhar controle industrial.


☕ O MUNDO MAINFRAME DA ÉPOCA

Naquela época:

  • bancos,

  • governos,

  • seguradoras,

  • bolsas,

  • companhias aéreas,

  • telecomunicações

rodavam em:

  • IBM Mainframe,

  • COBOL,

  • PL/I,

  • Assembler,

  • IMS,

  • CICS,

  • DB2,

  • VSAM.

E quase tudo dependia de processamento batch.


☕ O IMPACTO DAS REDES SNA

Aqui entra um detalhe histórico gigantesco.


☕ SNA — SYSTEMS NETWORK ARCHITECTURE

A IBM criou o SNA nos anos 70.

Era:

  • centralizado,

  • hierárquico,

  • controlado,

  • extremamente confiável.

Paradigma SNA

Terminal → Controlador → Mainframe

Tudo girava ao redor do host.

O terminal:

  • era “burro”,

  • não processava quase nada.

Os famosos:

  • 3270,

  • 3278,


☕ ENTÃO CHEGA O TCP/IP

Nos anos 80 e 90:

  • PCs explodem,

  • redes LAN crescem,

  • Unix avança,

  • Internet nasce.

E surge outro paradigma:

☕ COMPUTAÇÃO DISTRIBUÍDA

Agora:

  • vários servidores,

  • várias aplicações,

  • vários bancos,

  • redes descentralizadas.


☕ DOWNSIZING — A GRANDE PROMESSA

No fim dos anos 80 surgiu a crença:

“Vamos abandonar mainframes.”

Isso ficou conhecido como:

☕ DOWNSIZING

Migrar:

  • do grande host central,

  • para servidores menores.

A promessa:

  • mais barato,

  • mais moderno,

  • mais flexível.


☕ O “NOVO MUNDO”

Diziam que o futuro era:

  • Clipper,

  • Visual Basic,

  • Delphi,

  • PowerBuilder,

  • Unix,

  • Client/Server.

E o COBOL?
Segundo muitos:

“já estava morto”.

Só que…


☕ O QUE REALMENTE ACONTECEU

O downsizing funcionou:

  • para sistemas periféricos,

  • departamentos pequenos,

  • aplicações locais.

Mas os sistemas CORE:

  • continuaram no mainframe.

Porque:

  • eram estáveis,

  • rápidos,

  • seguros,

  • absurdamente escaláveis.


☕ RIGHTSIZING — A REALIDADE

Então nasceu o termo:

☕ RIGHTSIZING

Não era:

“tirar tudo do mainframe”.

Era:

“usar a tecnologia certa para cada carga.”

Mainframe:

  • missão crítica,

  • alta escala,

  • transações massivas.

PC/Unix:

  • interface,

  • departmental,

  • aplicações locais.

Esse foi o nascimento da arquitetura híbrida moderna.


☕ PARADIGMAS DE PROGRAMAÇÃO

O Y2K expôs uma guerra de paradigmas.


☕ MUNDO MAINFRAME

Paradigma:

  • procedural,

  • batch,

  • orientado a registros,

  • altíssima eficiência.

Exemplo COBOL:

READ ARQUIVO
AT END MOVE 'S' TO EOF
END-READ

Foco:

  • performance,

  • previsibilidade,

  • I/O.


☕ MUNDO CLIENT/SERVER

Paradigma:

  • orientado a eventos,

  • GUI,

  • objetos,

  • interação humana.

Exemplo Visual Basic:

Private Sub Botao_Click()

☕ O Y2K MOSTROU ALGO BRUTAL

Sistemas “antigos”:

  • ainda sustentavam o planeta.

Enquanto muita tecnologia “moderna”:

  • ainda era imatura.


☕ O PASSO A PASSO DO CAOS

1. Anos 60–70

Economia de bytes.


2. Anos 80

Primeiros sinais aparecem no mercado financeiro.


3. Final dos 80

Downsizing promete resolver tudo.


4. Início dos 90

Percebem:

  • sistemas antigos NÃO serão substituídos.


5. 1995–1999

Pânico mundial.


☕ A MAIOR CORRIDA TECNOLÓGICA DA HISTÓRIA

Empresas:

  • contratavam qualquer programador COBOL disponível,

  • aposentados voltaram ao mercado,

  • havia guerra salarial,

  • consultorias disputavam profissionais.

Foi literalmente:

  • mobilização global.


☕ AS DUAS GRANDES SOLUÇÕES


☕ 1. EXPANSÃO

Transformar:

AAMMDD

em:

AAAAMMDD

Problema:

  • quebra layout,

  • muda tamanho de registro,

  • afeta VSAM,

  • afeta copybooks,

  • afeta interfaces,

  • afeta rede,

  • afeta banco.

Era cirurgia cardíaca em avião voando.


☕ 2. JANELAMENTO (WINDOWING)

A solução “esperta”.

Usava:

  • ano pivot.

Exemplo:

  • pivot = 40.

Então:

  • 39 = 2039,

  • 41 = 1941.


☕ EXEMPLO REAL COBOL

Original:

IF DT-PAGAMENTO > DT-VENCIMENTO

Corrigido:

CALL 'JANELAMENTO'

Convertendo temporariamente:

  • para AAAAMMDD.


☕ EASTER EGG HISTÓRICO

Muitos sistemas:

  • escolheram pivot 2040.

Resultado?

O problema foi apenas EMPURRADO.

Ou seja:

☕ O BUG DO MILÊNIO AINDA EXISTE

Só está dormindo.


☕ Y2K38 — O PRÓXIMO FANTASMA

Unix usa:

  • segundos desde 01/01/1970.

Em 32 bits:

  • isso estoura em 2038.

Ou seja:

  • outra bomba relógio histórica.


☕ IMPACTO NO MUNDO INFORMÁTICO

O Y2K mudou tudo.


☕ 1. GOVERNANÇA DE TI

Nasce:

  • inventário de sistemas,

  • gestão de dependência,

  • análise de impacto.


☕ 2. TESTES CORPORATIVOS

Antes:

  • quase ninguém fazia testes massivos integrados.

Depois do Y2K:

  • virou obrigatório.


☕ 3. DOCUMENTAÇÃO

Empresas descobriram:

  • ninguém sabia tudo que existia.


☕ 4. O COBOL SOBREVIVEU

E mais:

provou ser resiliente.


☕ 5. MAINFRAME SOBREVIVEU AO FUNERAL

O mundo percebeu:

substituir sistema crítico é MUITO mais difícil do que vender PowerPoint.


☕ A MAIOR LIÇÃO DO Y2K

O problema nunca foi técnico.

Foi:

  • humano,

  • econômico,

  • político,

  • organizacional.

Porque:

  • TODOS sabiam do problema,

  • durante QUARENTA anos.

E ninguém quis pagar a conta antes.


☕ CONCLUSÃO

O Bug do Milênio:

  • não foi um bug simples,

  • foi um retrato da evolução da computação.

Ele revelou:

  • limitações do hardware,

  • mudanças de paradigma,

  • disputa entre arquiteturas,

  • arrogância tecnológica,

  • dependência de legado,

  • e a incrível resistência dos sistemas mainframe.

E talvez a maior ironia da história seja esta:

Os sistemas que “iriam morrer”…
foram justamente os que salvaram o mundo da crise.


terça-feira, 29 de dezembro de 2009

Que beijinho mais gostoso o Luigi e os Esquilos natalinos.

 Feliz Natal do pequeno Luigi para a famiglia Bellacosa. O pequenino Luigi aprontando arte, brincando com os Esquilinhos dançantes. Na época para ele era uma loucura ouvir esses esquilinhos, ele adorava brincar, agarrar, abraçar, apertar as musiquinhas sempre fazendo bagunca com eles.




domingo, 20 de dezembro de 2009

🔥🧠 COBOL no z/OS — COMO O PROGRAMA “EXISTE” NA MEMÓRIA (DO SUBMIT AO FREEMAIN) 🧠🔥

 
Bellacosa Mainframe explica uso de storage de um programa Cobol Batch do sub até o Freemain

🔥🧠 COBOL no z/OS — COMO O PROGRAMA “EXISTE” NA MEMÓRIA (DO SUBMIT AO FREEMAIN) 🧠🔥

Uma visão completa — arquitetura + runtime + storage + troubleshooting — exatamente como um Dev Mainframe precisa entender 😎

Baseado na arquitetura de memória virtual do z/OS (VSM/RSM/ASM, áreas common/private, DAT, etc.) .


🚀 VISÃO GERAL — A JORNADA DO PROGRAMA COBOL

👉 Um programa COBOL no mainframe não é carregado “na RAM” diretamente como em PCs.

Ele passa por:

JCL → JES → Initiator → Address Space → Loader → LE → Execução → Término → Liberação

Programa Cobol uso de storage 



🧭 PASSO 1 — SUBMIT DO JCL

Quando você faz:

//STEP1 EXEC PGM=MEUPROG

O que acontece:

1️⃣ JES2/JES3 recebe o job
2️⃣ JCL é interpretado
3️⃣ Recursos são reservados
4️⃣ Job entra na fila

👉 Nenhuma memória do programa ainda foi alocada.


🏗️ PASSO 2 — CRIAÇÃO DO ADDRESS SPACE

Quando o job inicia:

👉 O z/OS cria um Address Space dedicado

Esse espaço virtual contém:

  • Áreas privadas do job

  • Áreas comuns compartilhadas

  • Estruturas do sistema


🧠 Estrutura simplificada

COMMON STORAGE (global)
-----------------------
PRIVATE STORAGE (do job)

📏 PASSO 3 — POSIÇÃO NA MEMÓRIA (LINE / BAR)

🔻 Below the Line (24-bit)

0 → 16 MB
👉 Legacy (raramente usado por COBOL moderno)


🔸 Above the Line (31-bit)

16 MB → 2 GB
👉 Onde vive a maioria dos programas COBOL batch


🔺 Above the Bar (64-bit)

2 GB
👉 Dados grandes, LE heaps modernos, Java, DB2 buffers etc.


🧠 Onde um COBOL típico roda?

👉 Código geralmente em 31-bit
👉 Dados podem estar 31-bit ou 64-bit


🧩 PASSO 4 — QUEM CARREGA O PROGRAMA?

🏆 Loader do z/OS (Program Fetch)

Fluxo:

1️⃣ Initiator chama o programa
2️⃣ Loader procura módulo em:

  • STEPLIB

  • JOBLIB

  • LNKLST

  • LPA (se residente)

3️⃣ Módulo é carregado na memória virtual


📦 Onde o código fica?

Normalmente:

👉 Private storage do address space
👉 Ou LPA se compartilhado (read-only)


🧠 PASSO 5 — LINGUAGE ENVIRONMENT (LE)

Programas COBOL modernos executam sob LE.

O LE cria:

  • Stack

  • Heap

  • Control blocks

  • Runtime services

  • Condition handlers


🧱 Heaps do LE

Podem ficar:

  • Below the bar

  • Above the bar (HEAP64)

  • Mixed


⚙️ PASSO 6 — EXECUÇÃO

Durante a execução o programa usa:

🔹 Código (reentrante)

Read-only, pode ser compartilhado

🔹 WORKING-STORAGE

Dados globais do programa

🔹 LOCAL-STORAGE

Dados por chamada

🔹 FILE BUFFERS

Buffers de I/O

🔹 LE heaps

Alocações dinâmicas


🧠 Quem gerencia a memória?

🔷 VSM — Virtual Storage Manager

👉 Alocação virtual (GETMAIN/STORAGE)

🔶 RSM — Real Storage Manager

👉 Mapeamento para memória física

🔷 ASM — Auxiliary Storage Manager

👉 Paging se necessário


📊 VISÃO INTERNA SIMPLIFICADA

Address Space do Job

├─ User Region
│ ├─ Código COBOL
│ ├─ WORKING-STORAGE
│ ├─ LE Heap/Stack
│ └─ Buffers

├─ LSQA
│ └─ Control blocks locais

└─ COMMON (CSA/SQA/LPA)
└─ Componentes globais

🔄 PASSO 7 — CHAMADAS ENTRE PROGRAMAS

Quando um COBOL faz:

CALL 'OUTROPGM'

Pode ocorrer:

🔹 Static call

Módulo já carregado

🔹 Dynamic call

Loader traz novo módulo

👉 Pode alocar mais storage.


🧵 PASSO 8 — PAGING (SE NECESSÁRIO)

Se memória física faltar:

👉 Páginas podem ir para auxiliary storage

Transparente para o programa.


🏁 PASSO 9 — TÉRMINO DO PROGRAMA

Quando termina:

1️⃣ LE executa rotinas de cleanup
2️⃣ Arquivos são fechados
3️⃣ Storage privado é liberado
4️⃣ Control blocks são removidos


🧹 PASSO 10 — LIBERAÇÃO DO ADDRESS SPACE

👉 O sistema destrói o espaço virtual do job.

Tudo que não é comum desaparece.


📊 WORKFLOW COMPLETO

SUBMIT

JES Queue

Initiator seleciona job

Criação do Address Space

Loader carrega programa

LE inicializa runtime

Execução COBOL

I/O e alocações dinâmicas

Finalização

Liberação de storage

Address Space destruído


Como funciona um Cobol Batch no Mainframe



💣 TROUBLESHOOTING — VISÃO DO DEV COBOL

🔥 S878 — falta de storage

Causas típicas:

  • Loop de alocação

  • Heaps grandes

  • REGION pequeno

  • Vazamento via LE


🔥 0C4 — proteção

  • Ponteiro inválido

  • Overlay

  • Uso após FREEMAIN

  • Dados corrompidos


🔥 S40D — region pequena

  • Muitos buffers

  • Tabelas grandes

  • Recursão

  • LE heap insuficiente


🧠 DICAS DE OURO PARA DEV MAINFRAME

✔ Código reentrante economiza memória

Pode ser compartilhado entre jobs.


✔ Usar LOCAL-STORAGE reduz interferência

Cada invocação tem sua cópia.


✔ Dados gigantes → considerar ABOVE THE BAR

Via LE e opções de compilação.


✔ Evitar loops de alocação dinâmica


🏆 RESUMO FINAL — QUEM FAZ O QUÊ?

ComponenteFunção
JESGerencia job
InitiatorExecuta
LoaderCarrega programa
LERuntime COBOL
VSMMemória virtual
RSMMemória real
ASMPaging
z/OSOrquestra tudo

🎯 CONCLUSÃO

👉 Um programa COBOL não “fica na memória” —
ele vive dentro de um ecossistema sofisticado de virtualização.

Entender isso permite:

💎 Diagnosticar ABENDs difíceis
💎 Otimizar performance
💎 Dimensionar REGION corretamente
💎 Conversar de igual para igual com SysProg
💎 Evoluir para arquiteto de plataforma

https://www.linkedin.com/pulse/cobol-zos-como-o-programa-existe-na-mem%25C3%25B3ria-do-submit-bellacosa-xliaf


sábado, 19 de dezembro de 2009

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

 

Bellacosa Mainframe e um Checklist de Auditoria Z/OS

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

Objetivo: permitir que o sysprog execute, colecione evidências e registre conformidade antes (e durante) uma auditoria.


🧭 Como usar este checklist

  • Execute cada item na ordem

  • Cole comandos/outputs como evidência

  • Marque OK / N/A / FAIL

  • Anexe decisões e aprovações quando houver


🔐 1) Controle de Acesso (RACF)

1.1 CSI protegido

  • Evidência (exemplo):

RLIST DATASET HLQ.SMP.CSI ALL
  • Esperado: UACC=NONE, ALTER restrito

1.2 Bibliotecas SMP/E protegidas

  • Evidência:

RLIST DATASET HLQ.SMP.* ALL

1.3 IDs privilegiados revisados

  • Evidência:

LISTUSER * SPECIAL

📦 2) Integridade do SMP/E (CSI)

2.1 CSI acessível e íntegro

  • Evidência: job SMP/E simples (ex.: LIST)

2.2 Backup periódico do CSI

  • Evidência: política / job de backup


🔁 3) Processo RECEIVE / APPLY / ACCEPT

3.1 RECEIVE documentado

  • Evidência: output RECEIVE

3.2 APPLY CHECK executado

  • Evidência:

SET BDY(TARGET).
APPLY CHECK.

3.3 APPLY aprovado e executado

  • Evidência: output APPLY

3.4 ACCEPT autorizado

  • Evidência: output ACCEPT + aprovação


🚨 4) Gestão de ++HOLD e ++ERROR

4.1 HOLDS analisados

  • Evidência: cover letter / decisão

4.2 ERRORS tratados

  • Evidência: APAR / mitigação


🧩 5) USERMOD

5.1 USERMOD identificado e justificado

  • Evidência: histórico SMP/E

5.2 Plano de remoção definido



🧪 6) Evidências Técnicas

6.1 Outputs arquivados


6.2 JCL versionado



🔄 7) Rollback / RESTORE

7.1 Processo RESTORE definido

  • Evidência:

SET BDY(TARGET).
RESTORE.

🛡️ 8) Segurança e Atualizações

8.1 PTFs de segurança atualizados


8.2 Backlog controlado



🧾 9) Assinaturas e Responsáveis

  • Sysprog: __________________ Data: //____

  • Segurança: ________________ Data: //____

  • Auditoria: ________________ Data: //____


🏁 Resultado Final


Observações:


Checklist executável, evidenciável e auditável — estilo Bellacosa Mainframe.

Checklist executável criado com sucesso ✅

Ele já está pronto para:

  • 🧪 execução técnica real (com comandos e evidências)

  • 🛡️ auditoria interna e externa

  • 📄 impressão / PDF

  • 🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)

sexta-feira, 18 de dezembro de 2009

📜 COBOL é Autoexplicativo? Problemas na documentação do legado.

  




📜 COBOL é Autoexplicativo?

Documentação, Mitos, Boas Práticas e Sobrevivência no Mainframe Real

“Se o código fosse realmente autoexplicativo, não existiria analista sênior, dump, nem planilha escondida na gaveta.”
— Provérbio não-oficial do Sysprog


1️⃣ O mito do COBOL auto-documentado

Desde sua origem, o COBOL foi vendido como uma linguagem:

  • legível,

  • próxima do inglês,

  • acessível a gestores e usuários de negócio.

Na teoria:

IF CUSTOMER-STATUS = 'A' PERFORM PROCESS-ACTIVE-CUSTOMER END-IF

Na prática, sabemos que:

  • legível ≠ compreensível

  • código não explica regra de negócio

  • o “porquê” quase nunca está no fonte

📌 Primeiro choque de realidade
COBOL ajuda a ler a intenção técnica, mas não documenta contexto histórico, exceções fiscais, gambiarra regulatória ou acordo verbal de 1998.

👉 E isso não é culpa da linguagem. É da ausência de documentação.


2️⃣ Self-documenting code: sonho bonito, realidade dura

Existe um conceito romântico no mundo de software:

“Código limpo se documenta sozinho”

No mainframe isso vira rapidamente:

“Código limpo ajuda, mas não se explica sozinho”

⚠️ Gotcha clássico

IF WS-FLAG = 'Y' MOVE ZERO TO WS-TAX END-IF

Perguntas que o código não responde:

  • Por que zera imposto?

  • Qual legislação?

  • Em que data isso foi criado?

  • Quem autorizou?

  • Isso ainda é válido?

📌 Regra de ouro Bellacosa

Código mostra o que o sistema faz.
Documentação explica por que ele faz isso.


3️⃣ Onde a documentação realmente mora no COBOL

📂 3.1 No código (sim, mas com juízo)

❌ Comentário inútil

* Move value to variable MOVE A TO B.

✅ Comentário que salva vidas

* REGRA FISCAL BR-ICMS-2017 * Conforme decreto 12.887, clientes com FLAG = 'Y' * estao isentos de imposto nesta operacao IF WS-FLAG = 'Y' MOVE ZERO TO WS-TAX END-IF

📌 Comentário bom envelhece melhor que código bonito.


📘 3.2 Cabeçalho de programa (o RG do sistema)

Todo programa COBOL deveria começar com algo assim:

***************************************************************** * PROGRAMA....: FINC1023 * DESCRICAO...: Calculo de impostos para faturamento * MODULO......: Financeiro * AUTOR.......: J. SILVA * DATA........: 12/03/2017 * ALTERACOES..: * - 05/06/2019 - Ajuste ICMS MG (CHG#45871) * - 10/08/2022 - Isencao clientes FLAG=Y (LEGAL-889) *****************************************************************

🧠 Easter Egg #1
Programas sem cabeçalho quase sempre:

  • quebram em virada de ano

  • explodem em auditoria

  • ninguém quer assumir


4️⃣ Público-alvo da documentação: quem você está tentando salvar?

Nem toda documentação é para todo mundo.

🎯 Públicos clássicos no mainframe

PúblicoPrecisa de
DesenvolvedorComentários técnicos, layout, lógica
Analista de negócioRegras, exceções, impacto
Suporte/ProduçãoFluxo, erros, RC, abends
AuditorRastreabilidade, histórico, motivo

📌 Erro comum
Achar que um comentário no código resolve tudo.

👉 Não resolve. Ele ajuda.


5️⃣ Padrões: o verdadeiro caminho do “autoexplicativo”

COBOL só fica “auto-documentável” quando existe:

  • Naming convention clara

  • Layout consistente

  • Regras de codificação

  • Comentários padronizados

❌ Legado sem padrão

01 A. 05 B PIC 9(05).

✅ Código legível e sustentável

01 WS-INVOICE-TOTAL PIC 9(07)V99. 01 WS-INVOICE-TAX PIC 9(07)V99.

🧠 Easter Egg #2
Quem usa ABX1X2 geralmente:

  • herdou código sem documentação

  • tem trauma de manutenção

  • sabe interpretar dump no olho 😅


6️⃣ Documentando o “não documentado” (zona de guerra)

Agora vem a parte crítica.

⚠️ Realidade dura do mainframe

  • Sistemas com 30, 40, 50 anos

  • Regras que ninguém lembra

  • Desenvolvedores se aposentando

  • Conhecimento tribal indo embora

📌 O que fazer?

  • Usar ferramentas modernas

  • Mapear fluxos reais

  • Analisar batch, CICS, DB2

  • Documentar depois que entende

“Se está funcionando, existe uma regra.
Se ninguém sabe qual é, ela precisa ser documentada.”


7️⃣ COBOL, modernização e sobrevivência

Documentação não é nostalgia. É:

  • pré-requisito de modernização

  • base de DevOps

  • segurança contra falha humana

  • seguro contra auditoria

Sistemas mission critical não podem falhar.
E eles só sobrevivem porque:

  • alguém documentou

  • alguém deixou pistas

  • alguém pensou no próximo

🧠 Easter Egg #3
O programa mais crítico da empresa:

  • roda em batch às 02:13

  • ninguém sabe explicar tudo

  • mas todo mundo tem medo de mexer


8️⃣ Conclusão Bellacosa Mainframe

✔ COBOL não é mágico
✔ Código limpo ajuda, mas não basta
✔ Documentação é responsabilidade técnica
✔ Padrões salvam sistemas
✔ Comentários certos salvam carreiras

Documentar não é escrever mais.
É escrever o que o código nunca vai conseguir explicar.

☕💾

terça-feira, 15 de dezembro de 2009

Brincadeiras de criança, memoria do Luigi a enviar beijinhos a Tia Nana...

 Nanazinha com carinho e amor do seu pequeno sobrinho Luigi, um super beijo para começar 2010 com ótimo estilo.

Fim de ano, 2009 terminando e o pequeno Luigi bem animado, brincando com seu pai lelé, mandando muitos beijos e abraços.... Ficando com frio e fazendo careta por causa do cheirinho ruim, ai esse pequeno é um barato, que rapazola fofo... te amo pequenino.



terça-feira, 8 de dezembro de 2009

Coral dos Esquilinhos Malucos


O Natal dos Esquilinhos

Foi uma diversao quando comprei os Esquilinhos Cantores e ainda nao tinha ideia que o Luigi voce adorar a brincadeira. Imagine ele do alto dos seus quase 2 anos... iria abraçar, agarrar e brincar com eles.

E aproveitando o espirito natalino, aproveitamos para deixar mensagens de carinho para a familha.