☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sexta-feira, 3 de abril de 2020

CICS BMS para Desenvolvedores COBOL – Parte 1

 

Bellacosa Mainframe mini curso de cics bms

☕ Um Café no Bellacosa Mainframe

CICS BMS para Desenvolvedores COBOL – Parte 1

Do Terminal 3270 ao Primeiro Hello World

Salve, jovem Padawan!

Se você está começando sua jornada no universo IBM Z e já ouviu alguém falar frases misteriosas como:

"Precisamos alterar o MAPSET."

"O cursor está parando no campo errado."

"O MDT não está ligado."

"Faz um SEND MAP DATAONLY."

E ficou pensando:

"Que feitiçaria mainframe é essa?"

Pode ficar tranquilo.

Neste artigo vamos iniciar uma jornada pelo BMS (Basic Mapping Support) do CICS. O objetivo é apresentar o assunto pensando em um desenvolvedor COBOL Júnior, explicando desde a origem do BMS até a construção do primeiro mapa funcionando em uma aplicação CICS.

Pegue seu café, abra seu ISPF, reserve uma aba do SDSF e venha comigo.


Um pouco de história

Voltemos algumas décadas.

Estamos nos anos 70.

Não existia navegador.

Não existia JavaScript.

Não existia React.

Não existia Angular.

Nem mesmo Windows.

O usuário corporativo acessava aplicações utilizando terminais burros conectados ao mainframe.

Entre eles destacavam-se:

  • IBM 3270

  • IBM 3278

  • IBM 3279

  • IBM 3287

A tela típica possuía:

24 linhas

80 colunas

Algo parecido com isto:

----------------------------------------
 SISTEMA DE CLIENTES

 Codigo....: _____

 Nome......: _____________________

 Cidade....: _____________________

 PF3=Sair    PF5=Atualizar

----------------------------------------

A grande questão era:

Como desenhar telas sem colocar coordenadas dentro do programa COBOL?

A IBM criou então o BMS.

Basic Mapping Support.


O nascimento do CICS

CICS significa:

Customer Information Control System

O projeto surgiu em 1968.

Originalmente desenvolvido pela IBM para atender grandes empresas que precisavam de processamento transacional online.

Enquanto o Batch processava milhares de registros durante a madrugada...

O CICS permitia:

  • consultar saldo;

  • emitir passagens;

  • cadastrar clientes;

  • aprovar empréstimos;

  • consultar apólices;

  • efetuar reservas.

Tudo em tempo real.

Hoje ainda existem milhões de transações CICS sendo executadas diariamente.


O que é BMS ?

BMS significa:

Basic Mapping Support

Ele é uma camada intermediária entre:

Programa COBOL

e

Terminal 3270.

Ele esconde detalhes do dispositivo.

O desenvolvedor não precisa conhecer:

Posição física do cursor

Bytes de atributo

Intensidade

Cor

Protocolo 3270

Ele apenas manipula variáveis COBOL.


Arquitetura do BMS

Programa COBOL
        │
        │
        ▼
+----------------+
| Symbolic Map   |
+----------------+
        │
        ▼
+----------------+
|      BMS       |
+----------------+
        │
        ▼
+----------------+
| Physical Map   |
+----------------+
        │
        ▼
Terminal 3270

Uma analogia moderna

Imagine:

HTML

CSS

JavaScript

O BMS faz papel semelhante.

Mundo WebMundo CICS
HTMLPhysical Map
JavascriptCOBOL
BrowserTerminal 3270
DOMSymbolic Map
FrameworkBMS

O que é um MAP ?

MAP é uma tela.

Exemplo:

Tela Login

Tela Consulta

Tela Menu

Tela Inclusão

Cada tela é um MAP.


Exemplo

LOGIN

Usuário:


Senha:


ENTER=Entrar
PF3=Sair

Outro MAP

MENU

1 Consultar

2 Alterar

3 Incluir


PF3 Sair

O que é um MAPSET ?

Mapset é um conjunto de mapas.

Pode possuir:

LOGIN

MENU

CONSULTA

ALTERAÇÃO

INCLUSÃO

CONFIRMAÇÃO

Tudo agrupado.

Exemplo:

SISTCLI DFHMSD

Dentro dele

LOGIN DFHMDI


MENU DFHMDI


CONSUL DFHMDI


ALTERA DFHMDI

Physical Map

É um módulo executável.

Gerado pelo assembler.

Fica em:

DFHRPL

Exemplo

CLIENTES

O CICS carrega automaticamente.


Symbolic Map

Copybook COBOL.

Vai para:

COPYLIB

SYSLIB

Exemplo

CLIENTEM

As três macros do BMS

Existem apenas três macros principais.

DFHMSD

Mapset

DFHMDI

Mapa

DFHMDF

Campo


DFHMSD

É o cabeçalho.

Exemplo

CLIENTE DFHMSD TYPE=&SYSPARM,
                 LANG=COBOL,
                 MODE=INOUT,
                 STORAGE=AUTO,
                 TIOAPFX=YES,
                 CTRL=(FREEKB)

TYPE

MAP

DSECT

FINAL


LANG

COBOL

PLI

ASM


MODE

IN

OUT

INOUT


STORAGE

AUTO

BASE=MAP-IOAREA


TIOAPFX

Recomendado:

TIOAPFX=YES

Reserva 12 bytes para BMS.


DFHMDI

Define uma tela.

Exemplo

HELLOMAP DFHMDI
         SIZE=(24,80)

DFHMDF

Define campo.

Exemplo

MSG DFHMDF POS=(5,10),
            LENGTH=20,
            ATTRB=PROT,
            INITIAL='HELLO WORLD'

Nosso primeiro Hello World

Chegou a hora.

Fonte BMS


HELLO    DFHMSD TYPE=&SYSPARM,
                LANG=COBOL,
                MODE=OUT,
                TIOAPFX=YES


TELA1    DFHMDI SIZE=(24,80)


         DFHMDF POS=(1,25),
                 LENGTH=30,
                 ATTRB=(PROT,BRT),
                 INITIAL='HELLO WORLD BMS'


         DFHMDF POS=(22,2),
                 LENGTH=40,
                 ATTRB=(ASKIP),
                 INITIAL='PF3 SAIR'


         DFHMSD TYPE=FINAL


END




O que este mapa faz?

Exibe:



            HELLO WORLD BMS




PF3 SAIR



Usuário não consegue alterar nada.

Todos campos são protegidos.


Geração do Symbolic Map

O assembler cria um copybook.

Exemplo

01 TELA1O.



05 FILLER PIC X(30).




01 TELA1I.



05 FILLER PIC X(30).


Programa COBOL

Nosso primeiro programa.


IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.


DATA DIVISION.


WORKING-STORAGE SECTION.


COPY HELLO.



PROCEDURE DIVISION.



EXEC CICS SEND

MAP('TELA1')

MAPSET('HELLO')

ERASE

FREEKB

END-EXEC.



EXEC CICS RETURN
END-EXEC.




O que acontece internamente?

Fluxo:



COBOL


SEND MAP


↓

BMS


↓

Physical Map


↓

Terminal


↓

Usuário visualiza


HELLO WORLD




A magia do BMS

Observe.

No COBOL não existe:

Linha 1

Coluna 25

Brilho

Atributo

3270

Bytes hexadecimais

Tudo está encapsulado.

O desenvolvedor apenas escreve:

SEND MAP

E o CICS faz o restante.


Curiosidade Bellacosa Mainframe

Muitos sistemas bancários escritos entre 1980 e 1995 continuam utilizando exatamente a mesma tecnologia apresentada neste artigo.

Alguns processam milhões de transações por dia.

Muitos deles executam em máquinas IBM z16 e z17, utilizando telas BMS desenvolvidas há mais de 30 anos.

É bastante comum encontrar mapas criados em 1987, recompilados diversas vezes ao longo das décadas, ainda em plena operação em seguradoras, bancos, empresas aéreas e grandes varejistas.

E isso talvez seja uma das maiores demonstrações da longevidade e da estabilidade da plataforma IBM Z.


Continua...

Na Parte 2 veremos:

✓ Compilação passo a passo do BMS

✓ JCL de Assembly

✓ Geração do Physical Map

✓ Geração do Symbolic Map

✓ Linkedit

✓ Cadastro via CEDA

✓ Uso do INSTALL

✓ Comandos CEMT

✓ SEND MAP

✓ RECEIVE MAP

✓ DFHEIBLK

✓ DFHAID

✓ Primeira pseudo-conversação CICS

quarta-feira, 18 de março de 2020

DotCom : Capítulo III — A Economia do "Queime Caixa": Quando Gastar Milhões Virou Sinônimo de Sucesso

 

Bellacosa Mainframe o estouro da bolha do dotcom capitulo III


Capítulo III — A Economia do "Queime Caixa": Quando Gastar Milhões Virou Sinônimo de Sucesso

Como a obsessão pelo crescimento criou uma das maiores ilusões financeiras da história da tecnologia

"Uma nave pode acelerar até a velocidade de dobra. Mas, se o reator de antimatéria acabar antes do destino, toda a velocidade do universo será inútil."

Chegamos agora ao coração da bolha da Internet.

Se existe um conceito que todo Padawan COBOL precisa compreender para entender por que milhares de empresas desapareceram no início dos anos 2000, esse conceito é conhecido como Burn Rate, ou, em tradução livre, taxa de consumo de caixa.

Parece um termo moderno.

Mas sua lógica é antiga.

Muito antiga.

Imagine que você recebe um salário de R$ 10.000 por mês.

No primeiro mês, você resolve gastar R$ 30.000.

No segundo, mais R$ 30.000.

No terceiro, novamente R$ 30.000.

Enquanto houver alguém disposto a emprestar dinheiro, você continua vivendo como um milionário.

Mas chega um momento em que alguém faz a pergunta inevitável:

"Quando você pretende começar a ganhar mais do que gasta?"

Foi exatamente essa pergunta que destruiu milhares de empresas da era das Dot-Com.


O Que é Burn Rate?

De maneira simples, Burn Rate representa a velocidade com que uma empresa consome seu dinheiro disponível.

Imagine uma fogueira.

Quanto maior a chama...

Mais rapidamente a lenha desaparece.

Nas startups ocorre algo semelhante.

O dinheiro dos investidores é a lenha.

As despesas são o fogo.

Enquanto houver madeira...

O fogo continua bonito.

Quando acaba...

Não importa o tamanho da chama.

Tudo termina.

Esse conceito parece óbvio hoje.

Mas, durante alguns anos, parecia quase irrelevante.


Crescer Primeiro. Lucrar Depois.

A filosofia dominante entre 1997 e 2000 era extremamente sedutora.

Primeiro conquistaríamos milhões de usuários.

Depois descobriríamos como ganhar dinheiro.

A lógica parecia razoável.

Quanto maior a base de clientes, maior seria o potencial de receita futura.

O problema estava na palavra futuro.

Esse futuro nunca tinha data para chegar.

Enquanto isso, as contas continuavam vencendo.

Salários.

Aluguel.

Servidores.

Publicidade.

Marketing.

Infraestrutura.

Consultorias.

Viagens.

Eventos.

O dinheiro saía diariamente.

Mas quase não entrava.


A Corrida pela Escala

Outro conceito que ganhou enorme importância foi a escalabilidade.

Uma empresa tradicional precisava abrir novas lojas para crescer.

Cada nova unidade significava:

  • aluguel;

  • funcionários;

  • estoque;

  • energia;

  • manutenção.

Na Internet parecia diferente.

Criava-se um site.

Depois mais servidores.

Depois mais usuários.

O crescimento parecia infinito.

Esse raciocínio estava correto.

Mas escondia um detalhe gigantesco.

Servidores também custam dinheiro.

Desenvolvedores custam dinheiro.

Data centers custam dinheiro.

Links de Internet custam dinheiro.

Suporte custa dinheiro.

Escalar não era gratuito.

Apenas era diferente.


O Dinheiro Parecia Infinito

Durante a bolha, fundos de investimento competiam entre si para financiar startups.

Era comum uma empresa levantar dezenas ou centenas de milhões de dólares antes mesmo de apresentar lucro.

Algumas sequer possuíam um produto finalizado.

Bastava convencer investidores de que estavam construindo "o futuro".

Em poucos anos, uma cultura extremamente perigosa começou a surgir.

Gastar muito passou a ser interpretado como sinal de crescimento.

Quanto maior o prejuízo...

Maior parecia ser o potencial da empresa.

Hoje isso soa absurdo.

Na época parecia perfeitamente lógico.


O Marketing Virou um Buraco Negro

Talvez nenhum setor tenha consumido tanto dinheiro quanto o marketing.

Empresas compravam espaços durante o Super Bowl.

Patrocinavam eventos.

Espalhavam outdoors por grandes cidades.

Contratavam celebridades.

Produziam comerciais milionários.

O objetivo era simples.

Ficar conhecido antes dos concorrentes.

Muitas acreditavam que bastava dominar a mente do consumidor para garantir o sucesso futuro.

Mas havia um problema.

Publicidade gera visibilidade.

Não gera automaticamente receita.


O CAC Começou a Explodir

Hoje existe um indicador bastante conhecido chamado CAC.

Customer Acquisition Cost.

Ou custo para adquirir um cliente.

Imagine vender um produto de R$ 50.

Se você gastar R$ 500 em publicidade para conquistar esse cliente...

Seu negócio está perdendo dinheiro.

Durante a bolha da Internet isso acontecia frequentemente.

Empresas gastavam centenas de dólares para conquistar consumidores que compravam apenas uma única vez.

Enquanto investidores financiavam essa diferença...

Parecia funcionar.

Quando os investimentos diminuíram...

O modelo inteiro desmoronou.


O LTV Era Apenas uma Esperança

Outro conceito bastante utilizado atualmente é o Lifetime Value (LTV).

Representa quanto um cliente gera de receita ao longo de todo o relacionamento com a empresa.

Muitas startups justificavam enormes prejuízos dizendo:

"Hoje estamos perdendo dinheiro com este cliente.

Mas durante os próximos dez anos teremos lucro."

A teoria era excelente.

Na prática...

Grande parte desses clientes simplesmente nunca voltou.

As projeções eram otimistas demais.


O Escritório Também Virou Produto

Curiosamente, muitas startups passaram a competir também pela aparência.

Escritórios enormes.

Salas coloridas.

Escorregadores.

Mesas de pingue-pongue.

Videogames.

Cafés gourmet.

Frutas à vontade.

Massagem.

Academias.

Na época parecia representar uma nova cultura corporativa.

Em muitos casos representava apenas uma enorme despesa adicional.

Ambientes agradáveis são importantes.

Mas eles não substituem um modelo de negócios sustentável.


Contratar Também Virou Competição

Outro fenômeno curioso ocorreu com o mercado de trabalho.

Empresas contratavam centenas de profissionais muito antes de realmente precisarem deles.

A lógica era impedir que concorrentes encontrassem talentos disponíveis.

Desenvolvedores recebiam salários impressionantes.

Mudavam de empresa diversas vezes por ano.

Stock options tornaram-se extremamente populares.

Todos acreditavam que ficariam milionários quando a empresa abrisse capital.

Em alguns casos isso aconteceu.

Na maioria...

As ações tornaram-se praticamente sem valor.


Quando Crescimento Virou Vaidade

Durante aquele período surgiu uma obsessão por métricas que pouco diziam sobre a saúde financeira das empresas.

Número de visitantes.

Número de acessos.

Quantidade de páginas vistas.

Downloads.

Cadastros.

Cliques.

Esses números apareciam em todas as apresentações para investidores.

Quase ninguém perguntava algo muito mais importante.

Quantos clientes realmente pagam?

Essa diferença continua extremamente atual.

Uma aplicação pode possuir milhões de usuários.

Se ninguém pagar por ela...

O problema permanece.


O Dia em que Lucro Virou Palavra Proibida

Existe uma frase atribuída a diversos investidores daquela época.

"Lucro é para empresas velhas."

Essa mentalidade tornou-se tão forte que algumas companhias praticamente evitavam discutir resultados financeiros.

O foco era apenas crescimento.

A crença era simples.

Quando dominarmos o mercado...

O lucro aparecerá naturalmente.

Algumas empresas conseguiram isso.

Amazon é um exemplo.

A maioria não.

Porque dominar mercado também exige sobreviver tempo suficiente para alcançá-lo.


Enquanto Isso... Nos Mainframes

Agora imagine um gerente de processamento de dados em um grande banco brasileiro em 1999.

Toda manhã ele recebia indicadores como:

  • disponibilidade do sistema;

  • tempo médio de resposta;

  • volume de transações;

  • utilização de CPU;

  • consumo de disco;

  • filas de processamento;

  • integridade dos dados.

Nenhum diretor perguntava:

"Quantos milhões de acessos tivemos hoje?"

A pergunta era muito mais simples.

"O sistema funcionou?"

Esse contraste é fascinante.

Enquanto startups celebravam visitantes.

Mainframes celebravam transações concluídas com sucesso.

Enquanto empresas de Internet comemoravam páginas visualizadas.

Centros de processamento comemoravam disponibilidade de 99,999%.

Era uma diferença de mentalidade.

Uma focava expectativa.

Outra focava execução.


A Matemática Sempre Cobra

Existe uma característica curiosa da matemática.

Ela não possui opinião.

Não participa de reuniões.

Não lê reportagens.

Não acompanha tendências.

Ela simplesmente funciona.

Se uma empresa gasta continuamente mais do que arrecada...

Em algum momento o dinheiro termina.

Pode demorar meses.

Pode demorar anos.

Mas acontecerá.

Foi exatamente isso que ocorreu com centenas de startups.

Elas não quebraram porque a Internet era ruim.

Quebraram porque suas despesas cresceram mais rapidamente do que suas receitas.


A Armadilha do "Depois a Gente Resolve"

Talvez o maior erro estratégico daquele período tenha sido transformar problemas fundamentais em preocupações futuras.

Logística?

Depois resolvemos.

Rentabilidade?

Depois resolvemos.

Segurança?

Depois resolvemos.

Infraestrutura?

Depois resolvemos.

Atendimento?

Depois resolvemos.

Governança?

Depois resolvemos.

O problema é que empresas crescem.

Problemas também.

E quanto maior a empresa...

Mais caro se torna corrigir decisões equivocadas tomadas no início.

Essa continua sendo uma das maiores lições para startups atuais.


O Paralelo com a Inteligência Artificial

Olhando para 2026, encontramos algumas semelhanças interessantes.

Diversas empresas de IA recebem investimentos bilionários.

Muitas ainda operam com prejuízo.

Algumas apostam que receitas futuras compensarão os custos atuais.

A diferença é que boa parte dessas empresas já entrega valor concreto.

Modelos de IA realmente aumentam produtividade.

Automatizam tarefas.

Auxiliam desenvolvedores.

Transformam atendimento ao cliente.

Ou seja...

A tecnologia é real.

O desafio continua sendo construir modelos econômicos sustentáveis.

A história das Dot-Com não ensina que devemos desconfiar da inovação.

Ela ensina que inovação e sustentabilidade precisam caminhar juntas.


Lições para o Padawan COBOL

Todo programador COBOL aprende cedo que um sistema não pode depender apenas de condições ideais.

É preciso prever exceções.

Tratar erros.

Garantir recuperação.

Controlar recursos.

Planejar capacidade.

Empresas funcionam exatamente da mesma maneira.

Caixa é como memória disponível.

Se acabar...

O programa termina.

Receita é semelhante ao processamento de entrada.

Sem novos dados...

Não existe trabalho.

Lucro pode ser comparado ao espaço livre em disco.

Ele garante que o sistema continue crescendo sem entrar em colapso.

No universo da Frota Estelar, seria impensável iniciar uma missão interestelar sem calcular cuidadosamente o combustível, as reservas de energia e os recursos necessários para retornar à Terra. No entanto, foi exatamente isso que inúmeras empresas fizeram durante a bolha da Internet: aceleraram ao máximo, fascinadas pela velocidade, sem verificar se havia energia suficiente para completar a viagem.

No próximo capítulo veremos como essa cultura de crescimento a qualquer custo contaminou investidores, analistas e a mídia, criando um ambiente de euforia coletiva em que qualquer empresa ligada à Internet parecia destinada ao sucesso. Era o início do auge da bolha — justamente o momento em que ela começava, silenciosamente, a preparar seu inevitável colapso.

Boy Scout Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Mantida por Heróis… Mas por Pequenas Melhorias Feitas Todos os Dias

 

Bellacosa Mainframe apresenta boy scout rules

☕ Um Café no Bellacosa Mainframe

Boy Scout Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Mantida por Heróis… Mas por Pequenas Melhorias Feitas Todos os Dias

"Você não precisa reescrever a Matrix inteira. Basta deixá-la um pouco melhor cada vez que passar por ela."


Prólogo — A Sala Esquecida da Matrix

Após anos atravessando corredores infinitos da Matrix, Neo começou a notar algo estranho.

Algumas partes pareciam modernas.

Outras lembravam sistemas criados décadas antes.

Havia corredores impecáveis.

Outros estavam escuros.

Cabos pendurados.

Portas enferrujadas.

Painéis quebrados.

Neo perguntou ao Arquiteto:

— Quem deixou isso assim?

O Arquiteto respondeu:

— Ninguém.

Neo estranhou.

— Como assim ninguém?

O Oráculo apareceu carregando uma velha lanterna.

Caminhou lentamente por um corredor abandonado.

Pegou um cabo solto.

Prendeu-o corretamente.

Apagou uma mensagem de erro antiga.

Organizou alguns arquivos.

Depois continuou andando.

Neo perguntou:

— Isso resolve o problema da Matrix?

Ela respondeu:

— Não.

Resolve apenas este corredor.

Neo insistiu:

— Então por que perder tempo?

Ela sorriu.

— Porque milhares de pessoas fizeram exatamente isso durante muitos anos.

É por isso que a Matrix ainda funciona.

Naquele instante Neo compreendeu a Boy Scout Rule.


O que é a Boy Scout Rule?

A regra é extremamente simples.

"Always leave the campground cleaner than you found it."

Em português.

"Sempre deixe o acampamento mais limpo do que você encontrou."

Na Engenharia de Software ela foi adaptada para:

"Deixe o código um pouco melhor do que encontrou."

Não significa reescrever tudo.

Significa realizar pequenas melhorias sempre que tocar em um trecho de código.


A origem da regra

A inspiração vem do movimento dos Escoteiros (Boy Scouts of America).

Existe uma orientação tradicional ensinada aos jovens escoteiros:

Quando abandonar um acampamento.

Deixe-o melhor do que estava.

Mesmo que isso signifique apenas:

  • recolher um papel;

  • apagar uma fogueira;

  • organizar algumas pedras.

Na Engenharia de Software, Robert C. Martin (Uncle Bob) popularizou essa ideia como um hábito de desenvolvimento.


Matrix explica perfeitamente

Imagine que milhões de pessoas percorrem diariamente os corredores da Matrix.

Cada uma realiza apenas uma pequena melhoria.

No fim do ano.

Toda a Matrix está melhor.

Agora imagine o contrário.

Todos dizem:

"Não fui eu quem bagunçou."

Resultado.

O sistema envelhece rapidamente.


O COBOL vive exatamente esse cenário

Existem aplicações bancárias com:

  • trinta;

  • quarenta;

  • cinquenta anos.

Nenhuma equipe consegue parar tudo para reescrever esses sistemas.

Mas milhares de pequenas melhorias acumuladas durante décadas fazem enorme diferença.


O efeito da melhoria contínua

Imagine um programa COBOL.

Você entra apenas para alterar uma regra tributária.

Durante a alteração percebe:

  • variável mal nomeada;

  • comentário desatualizado;

  • código morto;

  • PERFORM desnecessário;

  • IF duplicado.

Você corrige.

Leva cinco minutos.

O próximo programador agradecerá.


Matrix Reloaded

Neo observa Zion sendo mantida.

Não existem apenas engenheiros brilhantes.

Existem centenas de pessoas realizando pequenas manutenções diariamente.

É isso que mantém a cidade viva.


O efeito psicológico

Existe um pensamento perigoso.

"Isso não é problema meu."

A Boy Scout Rule combate exatamente essa mentalidade.

Ela transforma todos em responsáveis pela qualidade coletiva.


O Programador COBOL Padawan

Você abre um programa.

Encontra:

MOVE ZERO TO WS-X.
MOVE ZERO TO WS-Y.
MOVE ZERO TO WS-Z.

Poderia deixar.

Mas decide organizar.

Talvez usar inicialização mais clara.

Talvez melhorar nomes.

Talvez remover duplicações.

Nenhuma dessas mudanças altera o negócio.

Mas todas melhoram a manutenção.


O Agente Smith adora abandono

Smith não destrói sistemas apenas criando bugs.

Ele espera.

Espera que pequenas sujeiras se acumulem.

Comentários antigos.

Variáveis confusas.

Código morto.

Layouts duplicados.

Depois de alguns anos.

A manutenção torna-se um pesadelo.


Um exemplo inspirado na Matrix

Imagine uma escada.

Cada pessoa deixa uma pequena pedra sobre um degrau.

Nenhuma pedra parece importante.

Anos depois.

A escada torna-se intransitável.

Agora imagine o contrário.

Cada pessoa remove uma pedra.

A escada permanece limpa para sempre.


Pequenas melhorias fazem enorme diferença

Você pode:

  • alinhar código;

  • renomear variáveis;

  • remover comentários incorretos;

  • apagar código morto;

  • dividir um PERFORM enorme;

  • atualizar documentação;

  • melhorar mensagens de erro.

Nada disso muda o negócio.

Mas muda profundamente a qualidade.


O impacto no Mainframe

No ambiente IBM Z encontramos frequentemente:

  • programas COBOL escritos por dezenas de equipes ao longo de décadas;

  • COPYBOOKs antigos;

  • comentários que não correspondem mais ao código;

  • JCLs com parâmetros obsoletos;

  • procedimentos duplicados.

Esperar uma reescrita completa é, muitas vezes, inviável.

A Boy Scout Rule oferece um caminho realista: evoluir continuamente.


Curiosidade

Muitas empresas perceberam que a maior parte da dívida técnica não nasce de grandes erros arquiteturais.

Ela surge de pequenas negligências repetidas diariamente.

Uma variável mal nomeada hoje.

Um comentário errado amanhã.

Uma duplicação na semana seguinte.

Meses depois.

Temos um sistema difícil de manter.


Atenção!

Boy Scout Rule não significa:

Refatorar o sistema inteiro enquanto corrige um pequeno bug.

Esse é um erro bastante comum.


A diferença

Boa prática

Corrigir um pequeno problema relacionado ao trecho alterado.


Exagero

Transformar uma correção simples em um projeto de seis meses.


Matrix e o Oráculo

O Oráculo nunca tenta reconstruir toda a Matrix.

Ela influencia pequenas decisões.

Uma conversa.

Uma escolha.

Uma melhoria.

No final.

Essas pequenas ações mudam toda a história.


Um exemplo COBOL

Antes.

IF WS-A = "S"
    MOVE "A" TO WS-X
ELSE
    MOVE "B" TO WS-X
END-IF

Você percebe que o comentário acima diz:

Calcula imposto.

Mas o código não calcula imposto algum.

Atualiza o comentário.

Parece pequeno.

Mas evita confusão futura.


Outro exemplo

Você encontra:

WS-TEMP1
WS-TEMP2
WS-TEMP3

Durante a manutenção.

Renomeia para:

WS-SALDO-ATUAL
WS-LIMITE-CREDITO
WS-VALOR-PARCELA

Nenhuma regra mudou.

Mas a legibilidade aumentou enormemente.


Ferramentas ajudam

Hoje possuímos excelentes ferramentas para apoiar pequenas melhorias contínuas.

Entre elas:

  • IBM ADDI.

  • SonarQube.

  • COBOL Check.

  • IBM Developer for z/OS.

  • IBM Z Open Editor.

  • Git.

  • Pull Requests.

  • Code Review.

  • IA Generativa.

Elas ajudam a identificar pontos simples que podem ser aprimorados sem grandes impactos.


O papel da IA

A Inteligência Artificial tornou-se uma excelente parceira da Boy Scout Rule.

Ela consegue sugerir:

  • nomes melhores;

  • simplificação de IFs;

  • remoção de código morto;

  • reorganização de PERFORMs;

  • comentários mais claros;

  • duplicações.

Mas a decisão continua sendo humana.

Nem toda sugestão melhora o sistema.


Os riscos

Ignorar pequenas melhorias produz:

  • crescimento da dívida técnica;

  • manutenção lenta;

  • onboarding difícil;

  • maior número de bugs;

  • baixa produtividade.


Erros clássicos

  • "Depois alguém arruma."

  • "Sempre foi assim."

  • "Não vale a pena."

  • "Não é minha responsabilidade."

  • "Funciona, então deixa."

Essas frases envelhecem sistemas muito rapidamente.


Boas práticas

  • Corrigir pequenos problemas ao modificar um módulo.

  • Atualizar comentários inconsistentes.

  • Remover código morto.

  • Melhorar nomes de variáveis.

  • Eliminar duplicações simples.

  • Organizar PERFORMs.

  • Registrar decisões importantes.


Boy Scout Rule conversa com toda esta série

Esse princípio é praticamente um elo entre todos os conceitos estudados até aqui.

Ele ajuda a combater:

  • Technical Debt, reduzindo o acúmulo de dívida técnica.

  • Lava Flow, removendo pequenos trechos abandonados.

  • Spaghetti Code, reorganizando gradualmente o código.

  • Big Ball of Mud, promovendo pequenas melhorias estruturais.

  • DRY, eliminando duplicações encontradas durante a manutenção.

  • KISS, simplificando trechos excessivamente complexos.

  • YAGNI, removendo funcionalidades desnecessárias.

  • Murphy's Law, fortalecendo validações e tratamentos de erro.

  • SOLID, aproximando o código de responsabilidades mais claras.

Em vez de esperar um grande projeto de modernização, a qualidade cresce continuamente.


Aplicabilidade

A Boy Scout Rule pode ser aplicada em praticamente qualquer área da engenharia:

  • COBOL.

  • CICS.

  • Db2.

  • JCL.

  • REXX.

  • Java.

  • Python.

  • APIs.

  • DevOps.

  • Infraestrutura como Código.

  • Documentação.

  • Pipelines CI/CD.

  • Playbooks Ansible.

Ela não depende de tecnologia.

Depende de cultura.


O ensinamento do Oráculo

O Oráculo leva Neo até um velho jardim dentro da Matrix.

O chão está coberto por folhas.

Ela entrega uma pequena vassoura.

Neo pergunta:

— Vamos limpar tudo?

Ela responde:

— Não.

Limpe apenas o caminho por onde passaremos hoje.

Horas depois.

Outras pessoas fazem o mesmo em outros caminhos.

Dias depois.

O jardim inteiro está limpo.

Sem que ninguém tenha realizado uma grande reforma.

Ela olha para Neo e diz:

"Quem espera pela grande transformação normalmente não muda nada. Quem melhora um pequeno detalhe todos os dias acaba transformando o mundo inteiro."


Lições para um Programador COBOL Padawan

Durante sua carreira você herdará programas escritos por profissionais que talvez nunca conheça.

Alguns serão excelentes.

Outros nem tanto.

Resista à tentação de criticar quem veio antes.

Lembre-se de que aqueles sistemas sobreviveram porque alguém os manteve funcionando.

Sua missão agora é continuar essa história.

Sempre que modificar um programa, pergunte:

  • Posso melhorar o nome desta variável?

  • Posso remover este trecho morto?

  • Este comentário ainda faz sentido?

  • Posso reduzir esta duplicação?

  • Posso tornar este IF mais legível?

  • Posso registrar melhor esta decisão?

Se a resposta for "sim" e o risco for baixo, faça a melhoria.

A próxima pessoa que abrir esse código talvez seja você mesmo daqui a cinco anos.


Curiosidades

A Boy Scout Rule influenciou fortemente práticas modernas como:

  • Clean Code, de Robert C. Martin.

  • Refatoração Contínua, popularizada por Martin Fowler.

  • Trunk-Based Development, incentivando pequenas mudanças frequentes.

  • Continuous Integration, reduzindo grandes refatorações.

  • Code Review, estimulando melhorias incrementais.

  • InnerSource, promovendo responsabilidade coletiva sobre o código.

Todas compartilham uma mesma visão:

qualidade é construída diariamente, não apenas em grandes projetos de modernização.


Conclusão — A Matrix Não Foi Salva em um Único Dia

Neo derrotou Smith em uma batalha decisiva.

Mas a Matrix não permaneceu estável por causa daquele único momento.

Ela continuou existindo porque milhares de pequenas correções, ajustes e melhorias foram realizadas continuamente ao longo do tempo.

Na Engenharia de Software acontece exatamente o mesmo.

A Boy Scout Rule nos ensina que grandes sistemas não envelhecem bem por acaso. Eles envelhecem bem porque cada desenvolvedor deixa uma pequena contribuição positiva sempre que toca no código.

Para um Programador COBOL trabalhando em IBM Z, essa filosofia é especialmente poderosa. Não é necessário esperar um projeto milionário de modernização para melhorar um sistema legado. Pequenas melhorias consistentes, feitas com responsabilidade e baixo risco, acumulam um enorme ganho de qualidade ao longo dos anos.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na entrada da oficina de manutenção da Matrix:

"Você talvez não tenha tempo para reconstruir toda a Matrix hoje. Mas sempre terá tempo para deixar um único corredor melhor do que o encontrou. E quando milhares de engenheiros fizerem o mesmo, a própria Matrix parecerá nova sem jamais ter sido reconstruída."

Porque o verdadeiro legado de um engenheiro não é apenas o código que ele escreve.

É o código que ele entrega em condições melhores para a próxima geração de Padawans.

terça-feira, 17 de março de 2020

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

 

Bellacosa Mainframe entenda os ranks das guildas em anime e alem

☕ Um Café no Bellacosa Mainframe

Ranks dos Animes sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

Existe uma cena que praticamente todo fã de anime, mangá, light novel ou RPG já viu dezenas de vezes.

O protagonista chega até uma Guilda dos Aventureiros.

Uma esfera mágica mede suas habilidades.

Uma placa luminosa aparece.

Todos prendem a respiração.

Então surge uma única letra.

E.

Os aventureiros riem.

O recepcionista faz uma cara de pena.

Os veteranos comentam:

— "Só um Rank E..."

Mas, algumas temporadas depois, aquele mesmo personagem derrota um dragão ancestral, salva o reino inteiro e recebe o título de Rank S.

Se você está começando agora no mundo dos animes, talvez pense que essas letras foram inventadas apenas para deixar a história mais emocionante.

Na verdade, elas representam um sistema extremamente inteligente de progressão que mistura psicologia, teoria dos jogos, design de RPG, estatística, administração e até conceitos utilizados em grandes empresas.

Curiosamente, esse sistema também pode explicar perfeitamente como evolui um programador COBOL dentro de um ambiente IBM Z.

Pegue sua caneca de café.

Hoje vamos descobrir que essa pequena letra ao lado do nome de um aventureiro diz muito mais do que parece.


Antes de tudo: o que é um Rank?

Rank significa simplesmente:

posição dentro de uma hierarquia.

É uma maneira rápida de responder perguntas como:

  • Quão experiente essa pessoa é?

  • Em quem podemos confiar?

  • Que tipo de missão ela consegue realizar?

  • Quanto perigo ela suporta?

  • Quanto ela já provou seu valor?

É exatamente igual ao mundo profissional.

Imagine um hospital.

Existem:

  • Estagiários

  • Residentes

  • Médicos

  • Especialistas

  • Chefes de equipe

Todos são médicos.

Mas possuem níveis diferentes de experiência.

Nos animes acontece exatamente a mesma coisa.


A pirâmide do poder

A maioria dos animes representa os ranks como uma pirâmide.

           S
         A
       B
     C
   D
 E

Observe uma curiosidade.

Quanto maior o rank...

menor o espaço.

Isso representa uma verdade estatística.

Pouquíssimas pessoas chegam ao topo.

Essa ideia aparece em praticamente tudo na vida.

Por exemplo:

  • Faixas do Karatê

  • Graduação Militar

  • IBM Fellow

  • Doutorado

  • Certificações técnicas

  • Cargos executivos

Sempre existe uma base enorme.

E um topo extremamente pequeno.


Rank E — O Começo da Jornada

O Rank E costuma ser o menor nível oficial.

Muita gente interpreta isso como:

"Esse personagem é fraco."

Na verdade, não.

Ele apenas ainda não teve oportunidade de provar seu potencial.

O Rank E representa:

  • iniciante

  • novato

  • aprendiz

  • aventureiro recém-registrado

Ele conhece pouco sobre:

  • monstros

  • estratégia

  • sobrevivência

  • trabalho em equipe

É o equivalente ao famoso Padawan.

No mundo COBOL seria alguém que acabou de aprender:

  • TSO

  • ISPF

  • JCL

  • Compilar um programa

Ainda não significa que seja ruim.

Significa apenas que está começando.


Rank D — O Sobrevivente

Agora o aventureiro já saiu da teoria.

Ele enfrentou monstros reais.

Já conhece armadilhas.

Aprendeu que uma espada bonita não vence batalhas.

Experiência vence.

No mercado de trabalho seria o profissional júnior.

Ele ainda pergunta bastante.

Mas já consegue executar tarefas sozinho.


Rank C — O Profissional

Aqui começa a diferença.

O aventureiro deixa de ser apenas alguém que acompanha grupos.

Agora ele passa a ser alguém confiável.

Recebe missões importantes.

Pode liderar pequenas equipes.

É respeitado.

Em empresas seria o profissional pleno.

No Mainframe:

  • desenvolve COBOL

  • conhece VSAM

  • entende Db2

  • sabe trabalhar com CICS

Ainda consulta documentação.

Mas já entrega produção.


Rank B — O Especialista

Pouca gente chega aqui.

Agora o aventureiro possui:

  • reputação

  • fama

  • dinheiro

  • respeito

As pessoas conhecem seu nome.

É chamado para missões perigosas.

Pode ensinar iniciantes.

Em tecnologia seria:

Especialista.

É aquele profissional que todos procuram quando aparece um problema complicado.


Rank A — A Elite

Agora estamos falando de aventureiros que mudam guerras.

Eles enfrentam:

  • dragões

  • reis demônios

  • calamidades

  • monstros lendários

Governos pedem sua ajuda.

Reinos oferecem recompensas.

São poucos.

Muito poucos.

Na IBM seria alguém reconhecido internacionalmente.


Rank S — A Lenda

Esse é o rank mais famoso.

O curioso é que...

ele nem faz parte do alfabeto.

Depois do A...

vem o S.

Por quê?

Existem diversas teorias.

As mais conhecidas dizem que significa:

Special

Superior

Supreme

Super

Independentemente da origem, o Japão adotou o Rank S como:

"Acima do excelente."

São pessoas praticamente únicas.


Por que quase todos os animes usam letras?

Porque o cérebro entende letras instantaneamente.

Imagine duas situações.

Situação 1

Nível de combate:
785

Situação 2

Rank A

Qual delas comunica melhor?

A segunda.

Em menos de um segundo.

Isso é linguagem visual.

Os japoneses dominam isso como poucos.


A importância da Guilda

Outro detalhe importante.

Os ranks normalmente pertencem à Guilda.

Não ao personagem.

Isso significa que existe uma instituição responsável por avaliar todos.

É como:

OAB

CRM

IBM Certification

AWS

Microsoft

Cisco

A Guilda certifica.

O aventureiro representa.


Como alguém sobe de Rank?

Não basta dizer:

"Agora sou Rank A."

É preciso provar.

Normalmente envolve:

  • quantidade de missões

  • taxa de sucesso

  • monstros derrotados

  • comportamento

  • liderança

  • experiência

Perceba.

Força é apenas um dos critérios.


A psicologia da evolução

Existe um motivo pelo qual adoramos histórias assim.

Nosso cérebro ama progresso.

Toda vez que vemos:

Rank D

↓

Rank C

Sentimos satisfação.

Isso acontece porque percebemos evolução.

Os videogames exploram exatamente esse mecanismo.

XP.

Level.

Badges.

Achievements.

Tudo gira em torno da mesma ideia.


Quando aparecem os Ranks SS, SSS e EX

Muitos animes modernos resolveram exagerar.

Então surgiram:

SS

SSS

EX

Legend

Myth

God

Divine

Isso serve para mostrar personagens que estão muito acima da média.

Às vezes existe apenas uma pessoa no mundo inteiro com aquele título.


Existem animes sem ranks?

Sim.

E isso é interessante.

Obras como:

  • Berserk

  • Vinland Saga

  • Monster

Não utilizam letras.

Mesmo assim existe hierarquia.

Ela apenas é construída pela narrativa.

Já nos isekais e RPGs, usar letras acelera a compreensão do espectador.


Alguns dos animes mais famosos que utilizam esse sistema

Praticamente virou um padrão do gênero.

Entre eles:

  • Solo Leveling

  • Overlord

  • Goblin Slayer

  • DanMachi

  • Tsukimichi

  • Arifureta

  • The Rising of the Shield Hero

  • Black Summoner

  • Failure Frame

  • I Parry Everything

  • The Unwanted Undead Adventurer

  • Infinite Dendrogram

  • The Great Cleric

  • Bofuri (para habilidades)

  • Kuma Kuma Kuma Bear

  • Boukensha ni Naritai

Cada um adapta o sistema às regras do seu universo, mas a lógica permanece a mesma.


A grande metáfora escondida

Na verdade...

esses ranks nunca falaram apenas de poder.

Eles falam sobre confiança.

Um aventureiro Rank A recebe missões importantes porque milhares de pessoas acreditam que ele será capaz de concluí-las.

No mundo corporativo acontece o mesmo.

Você não lidera um projeto crítico apenas porque sabe programar.

Você lidera porque demonstrou, ao longo do tempo, capacidade técnica, responsabilidade e maturidade.


O que isso ensina para um Programador COBOL Padawan?

Agora vem a parte mais divertida.

Imagine que o IBM Z também tivesse ranks oficiais.

🟢 Rank F — O recém-chegado

O Rank F costuma representar o nível mais baixo em alguns animes, mangás e RPGs, embora nem todos os universos o utilizem. Geralmente identifica aventureiros recém-registrados, sem experiência prática, equipamentos adequados ou feitos reconhecidos. 

Personagens nesse nível recebem missões simples, como coleta de ervas, entrega de itens ou eliminação de pequenos monstros. O objetivo é adquirir experiência, aprender trabalho em equipe e desenvolver habilidades básicas. 

Em muitos isekais, o protagonista começa no Rank F para evidenciar sua evolução ao longo da história. É a fase do aprendizado, onde persistência, disciplina e coragem valem mais do que força bruta.


🟢 Rank E — O Padawan

Você aprendeu:

  • O que é um Mainframe

  • Login no TSO

  • Navegação no ISPF

  • Criar um PDS

  • Executar um JCL simples

Você ainda pergunta muito.

E isso é ótimo.


🔵 Rank D — O Desenvolvedor Júnior

Agora você:

  • programa COBOL básico;

  • entende COPYBOOKs;

  • faz manutenção simples;

  • lê mensagens do JES2;

  • começa a entender ABENDs.

Já consegue contribuir em produção com supervisão.


🟡 Rank C — O Profissional Pleno

Neste ponto você domina:

  • COBOL estruturado;

  • JCL avançado;

  • VSAM;

  • Db2;

  • CICS;

  • SQL;

  • controle de versões.

Você entrega funcionalidades completas e entende as regras de negócio.


🟠 Rank B — O Especialista

Agora você resolve problemas que poucos conseguem.

Conhece:

  • IMS;

  • MQ;

  • RACF;

  • SMF;

  • RMF;

  • Performance;

  • tuning de SQL;

  • integração com APIs;

  • automação com Zowe e Ansible.

Quando ocorre um incidente crítico, seu telefone toca.


🔴 Rank A — O Arquiteto

Você não pensa apenas em programas.

Pensa em sistemas inteiros.

Decide arquiteturas.

Define padrões.

Mentora equipes.

Participa de modernizações e integrações com nuvem, DevOps e IA.


⭐ Rank S — A Lenda da Guilda

O Rank S não é apenas quem sabe mais comandos.

É quem inspira outros profissionais.

É o especialista que:

  • resolve incidentes aparentemente impossíveis;

  • conhece décadas de história do ambiente;

  • entende profundamente regras de negócio;

  • forma novos talentos;

  • mantém sistemas que processam milhões de transações diárias sem falhas.

É o profissional cuja maior conquista não é um certificado, mas o respeito conquistado ao longo dos anos.



O verdadeiro significado da pirâmide

Quando olhamos novamente para aquela simples imagem de um anime, percebemos que ela representa muito mais do que níveis de força.

Ela fala sobre aprendizado contínuo, confiança, responsabilidade e evolução.

Nenhum protagonista começa no topo. Os heróis mais memoráveis tropeçam, erram, treinam e acumulam experiência antes de alcançar os maiores desafios. O mesmo vale para quem escolhe uma carreira em tecnologia.

No universo IBM Z, não existe magia que transforme um iniciante em especialista da noite para o dia. Cada programa compilado, cada ABEND investigado, cada JCL corrigido, cada consulta SQL otimizada e cada madrugada de suporte em produção acrescentam um pouco mais de experiência à sua jornada.

Essa talvez seja a maior lição escondida por trás dos ranks dos animes: o verdadeiro poder não está na letra que aparece ao lado do seu nome, mas na quantidade de conhecimento, disciplina e perseverança que foi necessária para conquistá-la.

Assim como os grandes protagonistas dos isekais, todo Programador COBOL Padawan começa no Rank E. E, com estudo constante, curiosidade e prática, pode um dia tornar-se uma verdadeira lenda da sua própria guilda tecnológica.


segunda-feira, 16 de março de 2020

Teoria dos Jogos no Mainframe : Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

 

Bellacosa Mainframe e a teoria dos jogos no mainframe

☕ Um Café no Bellacosa Mainframe

Teoria dos Jogos no Mainframe

Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

"No mainframe, quase nenhum problema é apenas técnico. Quase todos envolvem pessoas tomando decisões."

Quando um desenvolvedor COBOL imagina Matemática aplicada ao desenvolvimento, normalmente pensa em algoritmos, estruturas de dados ou otimização.

Mas existe uma disciplina que explica boa parte dos conflitos encontrados diariamente dentro de um grande ambiente IBM Z:

A Teoria dos Jogos.

Não é sobre videogames.

É sobre entender como pessoas, equipes, empresas e até sistemas inteiros tomam decisões quando seus interesses dependem das escolhas dos outros.

E surpreendentemente...

Ela explica muito do que acontece dentro de um banco.


O que é Teoria dos Jogos?

A Teoria dos Jogos é um ramo da matemática aplicada que estuda situações onde vários participantes (chamados jogadores) precisam tomar decisões.

Cada decisão altera o resultado dos demais.

Ou seja...

Meu resultado depende da sua decisão.

E o seu depende da minha.

No mundo corporativo isso acontece o tempo inteiro.

No mainframe também.


Onde nasceu?

A origem moderna começa em 1944.

Dois pesquisadores publicaram um livro que mudou completamente Economia, Estratégia Militar e Ciência da Computação.

John von Neumann

Matemático brilhante.

Pai da arquitetura dos computadores modernos.

Participou do Projeto Manhattan.

Criou a primeira formulação matemática da Teoria dos Jogos.


Oskar Morgenstern

Economista.

Percebeu que economia não podia ser explicada apenas por oferta e demanda.

Era preciso considerar comportamento estratégico.


O livro histórico

Theory of Games and Economic Behavior (1944)

Foi um divisor de águas.

Mostrou que decisões racionais podem ser modeladas matematicamente.

Até hoje é considerado um dos livros mais importantes do século XX.


Depois veio John Nash

Se você assistiu ao filme Uma Mente Brilhante, conhece sua história.

John Nash revolucionou a área criando o conceito de:

Equilíbrio de Nash

É uma situação onde ninguém ganha mudando sua estratégia sozinho.

Todos ficam "presos" em uma decisão estável.

Isso acontece diariamente em TI.


Um exemplo no banco

Imagine duas equipes.

Equipe A deseja atualizar o sistema.

Equipe B deseja estabilidade.

Se A atualiza sem avisar...

B sofre.

Se B bloqueia todas as mudanças...

A nunca entrega inovação.

Ambas precisam cooperar.

Este é um jogo estratégico.


O famoso Dilema do Prisioneiro

É provavelmente o exemplo mais conhecido.

Dois suspeitos são presos.

Cada um pode:

  • colaborar

  • trair

O resultado depende da decisão dos dois.

Curiosamente...

Quando ambos tentam maximizar seu ganho individual...

Os dois acabam pior.


Isso acontece no Mainframe?

O tempo inteiro.

Exemplos:

  • desenvolvimento versus operações

  • aplicações versus infraestrutura

  • segurança versus produtividade

  • negócio versus tecnologia

  • performance versus custo

  • estabilidade versus inovação

Cada decisão influencia outra equipe.


Um Programador COBOL joga sem perceber

Imagine:

Você recebe uma alteração urgente.

Tem duas opções.

Estratégia A

Entregar rápido.

Maior risco.


Estratégia B

Testar corretamente.

Entrega mais lenta.


Agora imagine que o gestor mede apenas velocidade.

Naturalmente todos passam a entregar rápido.

Depois aparecem:

  • incidentes

  • rollback

  • retrabalho

O sistema inteiro piora.

Foi um jogo mal desenhado.


Sistemas também jogam

Não apenas pessoas.

Diversos componentes competem por recursos.

Exemplos:

  • CPU

  • memória

  • canais

  • discos

  • locks

  • threads

  • Db2

  • CICS

  • MQ

Todos disputam recursos limitados.

Isso lembra um enorme jogo cooperativo.


WLM é Teoria dos Jogos em ação

O Workload Manager não distribui CPU aleatoriamente.

Ele resolve conflitos.

Pergunta continuamente:

Quem precisa de mais recursos?

Quem pode esperar?

Quem possui maior prioridade?

É praticamente um árbitro estratégico.


Lock no Db2

Imagine dois programas.

Programa A bloqueia uma tabela.

Programa B espera.

Agora ambos aguardam recursos diferentes.

Nasce um deadlock.

O Db2 precisa decidir.

Quem perde?

Quem continua?

Existe estratégia envolvida.


Escalonamento Batch

No JES2 e nos schedulers acontece exatamente o mesmo.

Centenas de jobs.

Recursos limitados.

Dependências.

Janela batch.

Prioridades.

Cada decisão muda o resultado das demais.


Balanceamento de carga

No Sysplex:

várias LPARs compartilham carga.

Mover uma workload melhora um sistema...

mas pode piorar outro.

É otimização estratégica.


Segurança

Até segurança pode ser analisada pela Teoria dos Jogos.

O atacante escolhe:

  • onde atacar

  • quando atacar

  • quanto investir

O defensor escolhe:

  • onde proteger

  • quanto monitorar

  • quanto gastar

É um jogo contínuo.


IA também usa Teoria dos Jogos

Modelos modernos de IA utilizam conceitos relacionados em:

  • aprendizado por reforço

  • sistemas multiagentes

  • negociação entre agentes

  • coordenação

  • planejamento estratégico

Cada agente toma decisões considerando os demais.


Grandes autores que vale conhecer

John von Neumann

Fundador da área.


Oskar Morgenstern

Aplicação econômica.


John Nash

Equilíbrio de Nash.


Thomas Schelling

Estratégia militar.

Conflitos.

Negociação.

Recebeu Nobel.


Robert Aumann

Jogos repetidos.

Cooperação.

Muito útil para organizações.


John Harsanyi

Jogos com informação incompleta.

Muito importante para segurança.


Lloyd Shapley

Valor de Shapley.

Como dividir benefícios em sistemas cooperativos.

Muito usado hoje em Inteligência Artificial.


Elinor Ostrom

Estudou cooperação em recursos compartilhados.

Suas ideias aparecem em computação distribuída.


Conceitos fundamentais

Todo Padawan deveria conhecer:

  • jogadores

  • estratégias

  • payoff

  • utilidade

  • equilíbrio de Nash

  • jogos cooperativos

  • jogos não cooperativos

  • jogos repetidos

  • jogos simultâneos

  • informação perfeita

  • informação imperfeita

  • dominância

  • estratégia mista

  • minimax

  • soma zero

  • soma não zero

Não precisa decorar fórmulas.

Entenda primeiro as ideias.


Como isso aparece no COBOL?

Mais do que parece.

Modelagem de regras

Quem ganha prioridade?

Quem espera?

Quem pode cancelar?

Tudo isso são decisões estratégicas.


Sistemas bancários

Fila de pagamentos.

Pix.

TED.

Cartões.

Empréstimos.

Todos possuem regras para resolver conflitos.


Controle de concorrência

Locks.

Timeout.

Retry.

Commit.

Rollback.

Tudo depende da estratégia adotada.


Escalabilidade

Quando dividir processamento?

Quando serializar?

Quando paralelizar?

Novamente...

Teoria dos Jogos.


Evolução da área

1944

Nascimento formal.

1950

Equilíbrio de Nash.

1970

Jogos evolucionários.

1980

Aplicações em Computação.

1990

Internet.

Redes.

Protocolos.

2000

Segurança.

Mercados eletrônicos.

Cloud.

2015+

Machine Learning.

IA.

Multiagentes.

Blockchain.

Robótica.


Como estudar?

Nível 1

Entenda lógica matemática.

Não precisa cálculo avançado.


Nível 2

Leia sobre:

  • Dilema do Prisioneiro

  • Equilíbrio de Nash

  • Minimax


Nível 3

Estude algoritmos.

Pesquisa Operacional.

Otimização.


Nível 4

Veja aplicações em:

  • IA

  • Redes

  • Segurança

  • Economia

  • Cloud


Nível 5

Passe a observar seu próprio ambiente de trabalho.

Você descobrirá jogos estratégicos em toda reunião.


Livros recomendados

Para iniciantes

  • The Art of Strategy — Avinash Dixit e Barry Nalebuff.

  • Thinking Strategically — Avinash Dixit e Barry Nalebuff.

Intermediário

  • Game Theory: A Very Short Introduction — Ken Binmore.

Clássicos

  • Theory of Games and Economic Behavior — John von Neumann e Oskar Morgenstern.

  • Non-Cooperative Games — John Nash.

Aplicações

  • The Evolution of Cooperation — Robert Axelrod.

  • Micromotives and Macrobehavior — Thomas Schelling.


Aplicações diretas no IBM Z

Um profissional de Mainframe pode usar Teoria dos Jogos para:

  • projetar regras de negócio mais robustas;

  • definir prioridades no IBM Workload Manager (WLM);

  • reduzir contenção de locks no Db2;

  • modelar filas no IBM MQ;

  • melhorar políticas de escalonamento em JES2 e schedulers;

  • analisar conflitos entre aplicações Batch e Online (CICS);

  • criar estratégias de segurança com RACF e gestão de privilégios;

  • otimizar uso de CPU, memória e I/O entre LPARs;

  • apoiar decisões de capacidade (Capacity Planning);

  • compreender negociações entre equipes de desenvolvimento, operações e negócio.

O resultado é menos decisões baseadas em intuição e mais decisões baseadas em incentivos, equilíbrio e cooperação.


A Trilha Bellacosa para um Padawan COBOL

Uma boa jornada de estudos pode seguir esta sequência:

  1. Lógica e Matemática Discreta.

  2. Probabilidade e Estatística.

  3. Teoria dos Jogos.

  4. Pesquisa Operacional.

  5. Algoritmos e Estruturas de Dados.

  6. Sistemas Distribuídos.

  7. Concorrência e Paralelismo.

  8. WLM, JES2 e escalonamento no z/OS.

  9. Db2: locking, isolamento e concorrência.

  10. Inteligência Artificial, aprendizado por reforço e sistemas multiagentes.

Cada etapa amplia sua capacidade de entender não apenas como o sistema funciona, mas por que ele toma determinadas decisões.


Conclusão

Muitos acreditam que um excelente programador conhece apenas COBOL, JCL, CICS ou Db2.

Os grandes profissionais vão além.

Eles entendem comportamento.

Entendem incentivos.

Entendem conflitos.

Entendem cooperação.

No fim das contas, um sistema corporativo não é apenas código executando em um IBM Z.

É um enorme conjunto de pessoas, aplicações, recursos e decisões estratégicas interagindo o tempo todo.

Quem aprende Teoria dos Jogos deixa de enxergar apenas programas.

Passa a enxergar sistemas.

E esse é um dos maiores saltos que um Padawan pode dar rumo ao caminho de um verdadeiro Mestre Mainframe.

"No IBM Z, vencer não significa consumir toda a CPU. Significa encontrar o equilíbrio onde aplicações, equipes e negócios prosperam juntos. Essa é a verdadeira estratégia — e talvez o maior jogo de todos."

 

Teoria dos Jogos no Mainframe: O Guia para Programadores COBOL

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade : Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

 

Bellacosa Mainframe e a sociedade do mainframe rumo a alta disponibilidade

☕ Um Café no Bellacosa Mainframe

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade

Quando um Programador COBOL Padawan Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

"Nem todos os sistemas que caem estão perdidos. Alguns apenas aguardam que outra região assuma sua missão."


Introdução

Existe um momento na carreira de todo programador COBOL em que ele deixa de pensar apenas no programa que escreveu.

Até então, seu universo era relativamente pequeno.

Recebia uma especificação.

Criava um programa COBOL.

Compilava.

Executava.

Corrigia alguns ABENDs.

Consultava um VSAM.

Executava um SQL.

Colocava em produção.

Fim da história.

Mas então surge uma pergunta aparentemente simples.

"O que acontece quando o programa está funcionando e o servidor onde ele está executando simplesmente desaparece?"

Silêncio.

Essa pergunta muda completamente a forma de enxergar um sistema corporativo.

É exatamente neste ponto que começa nossa jornada.

Como em O Senhor dos Anéis – A Sociedade do Anel, descobrimos que existe um mundo muito maior além do Condado.

O COBOL é apenas Frodo.

O CICS é Rivendell.

O z/OS é a Terra Média.

E a Alta Disponibilidade é a Sociedade que mantém o Um Anel longe das forças do caos.

Hoje atravessaremos essa Terra Média tecnológica.

Pegue seu café.

Afivele o cinto do terminal 3270.

Nossa aventura apenas começou.


Capítulo I

O Condado: Onde Todo Programador COBOL Começa

Todo iniciante acredita que um sistema funciona assim:

Cliente

↓

Programa COBOL

↓

Banco de Dados

↓

Resposta

Simples.

Bonito.

Organizado.

Funciona perfeitamente...

até acontecer a primeira falha.

Imagine um banco.

São nove horas da manhã.

Milhares de pessoas fazem PIX.

Empresas pagam fornecedores.

Cartões de crédito autorizam compras.

Caixas eletrônicos funcionam.

Aplicativos móveis recebem milhões de acessos.

De repente...

A máquina que executa aquele programa simplesmente para.

Não trava.

Não fica lenta.

Ela desaparece.

Agora faça uma pergunta.

Quanto dinheiro um banco perde por minuto parado?

Algumas instituições estimam milhões de reais por hora.

Em bolsas de valores...

alguns segundos podem representar perdas gigantescas.

Foi por isso que nasceu um dos conceitos mais importantes da computação corporativa:

High Availability.


Capítulo II

Mordor Existe

No universo da fantasia existe Sauron.

No Mainframe existem as falhas.

Elas sempre existirão.

Não importa a qualidade do hardware.

Não importa quanto custa o servidor.

Tudo pode falhar.

Discos quebram.

Fontes queimam.

Cabos são desconectados.

Switches morrem.

Processadores apresentam defeitos.

LPARs reiniciam.

Operadores cometem erros.

Programadores também.

O objetivo nunca foi impedir isso.

O objetivo sempre foi impedir que o cliente perceba.

Essa mudança de mentalidade separa iniciantes dos arquitetos de sistemas.


Capítulo III

A Sociedade do Mainframe

Assim como Frodo jamais chegaria sozinho a Mordor, um ambiente CICS nunca depende de um único componente.

A Sociedade é formada por personagens extraordinários.

Frodo — O Programa COBOL

É quem realmente executa a missão.

Ele processa contas.

Calcula juros.

Autoriza cartões.

Move dinheiro.

Mas sozinho ele não sobreviveria.


Gandalf — O WLM

O Workload Manager é um verdadeiro mago.

Ele conhece toda a Terra Média do z/OS.

Sabe onde há CPU disponível.

Onde existe memória.

Onde há menos filas.

Onde o tempo de resposta está melhor.

Enquanto os usuários apenas enviam solicitações...

Gandalf decide para onde cada missão será enviada.

Sem ele...

o reino mergulharia no caos.


Aragorn — O CICS

O verdadeiro líder da batalha.

Cada Região CICS representa um comandante.

Ela recebe transações.

Executa programas.

Coordena recursos.

Mantém a ordem.

Mas, assim como Aragorn, nenhuma região governa sozinha.

Existem várias espalhadas pelo reino.


Legolas — O Monitoramento

Legolas enxerga longe.

Muito longe.

Ele percebe um problema antes dos outros.

O monitoramento faz exatamente isso.

Analisa:

  • CPU

  • Storage

  • SOS

  • Locks

  • SQL lento

  • Esperas

  • MQ

  • Threads

  • Tempo de resposta

Antes mesmo dos usuários reclamarem.


Gimli — O Hardware IBM Z

Robusto.

Pesado.

Quase indestrutível.

Mas nem Gimli é imortal.

Até o melhor hardware pode falhar.

Por isso existem outros anões prontos para assumir.


Sam — O Db2

Frodo jamais teria chegado ao fim sem Sam.

O COBOL também não.

O Db2 acompanha todas as transações.

Protege os dados.

Mantém consistência.

Recupera informações.

Suporta milhões de acessos simultâneos.


Capítulo IV

O Portal de Rivendell

Observe o caminho percorrido por uma simples transação.

Usuário

↓

Aplicativo

↓

Rede

↓

Load Balancer

↓

WLM

↓

Região CICS

↓

COBOL

↓

DB2

↓

Resposta

O usuário nunca conversa diretamente com o COBOL.

Há diversos guardiões protegendo o caminho.

Isso é proposital.

Cada camada adiciona inteligência.

Cada camada aumenta a disponibilidade.

Cada camada reduz riscos.


Capítulo V

O Conselho de Elrond

Imagine que existem quatro Regiões CICS.

CICSA

CICSB

CICSC

CICSD

Durante um dia comum...

todas trabalham juntas.

Cada uma atende milhares de usuários.

Agora imagine que CICSB falhou.

O que acontece?

Nada.

Ou melhor...

quase nada.

O WLM simplesmente deixa de enviar novas transações para ela.

As demais assumem a carga.

Os clientes continuam utilizando o sistema.

É exatamente como retirar Boromir da Sociedade.

A missão continua.


Capítulo VI

O Um Anel da Alta Disponibilidade

Existe um erro comum entre iniciantes.

Pensar que redundância significa desperdício.

Não.

Redundância significa sobrevivência.

Ter apenas uma região é barato.

Mas extremamente perigoso.

Ter quatro regiões parece mais caro.

Até o dia da primeira falha.

Nesse instante...

descobre-se que o investimento pagou décadas de tranquilidade.


Capítulo VII

O Caminho para Mordor

Toda transação percorre diversos desafios.

Primeiro o balanceamento.

Depois o processamento.

Depois acesso ao banco.

Depois gravação em logs.

Depois confirmação.

Se qualquer etapa falhar...

existem mecanismos de recuperação.

Algumas transações reiniciam.

Outras utilizam Syncpoint.

Outras fazem rollback.

Outras repetem a operação.

Tudo pensado para preservar integridade.


Capítulo VIII

O Olho de Sauron Nunca Dorme

Monitoramento contínuo.

Esse é um conceito que muitos desenvolvedores ignoram.

Eles imaginam que basta a região responder.

Mas responder não significa estar saudável.

Uma região pode:

  • consumir 100% da CPU;

  • estar sem armazenamento (SOS);

  • aguardar locks;

  • enfrentar lentidão no Db2;

  • acumular filas no MQ.

Ela ainda responde.

Mas lentamente.

O monitoramento detecta esses sinais antes que o usuário perceba.

Ferramentas como OMEGAMON, RMF, SMF, CICS Explorer e soluções de observabilidade modernas funcionam como os sentinelas de Gondor: vigiam continuamente o horizonte em busca de qualquer ameaça.


Capítulo IX

A Fortaleza Invisível: Shared Db2 e VSAM

Uma pergunta importante surge.

Se existem várias regiões...

como todas enxergam os mesmos dados?

A resposta está no compartilhamento.

O Db2, utilizando Data Sharing, permite que diferentes regiões CICS acessem o mesmo conjunto de informações com consistência.

O VSAM, quando configurado com Record Level Sharing (RLS), também possibilita acesso concorrente seguro.

Imagine uma conta bancária.

Saldo:

R$ 1.000

Se uma região enxergasse R$ 1.000 e outra R$ 950, o caos seria inevitável.

É por isso que a consistência dos dados é tão importante quanto a disponibilidade da aplicação.


Capítulo X

O Reino Além do Reino: Parallel Sysplex

Aqui chegamos ao verdadeiro ápice da engenharia IBM.

O Parallel Sysplex.

Imagine várias fortalezas espalhadas pela Terra Média.

Cada uma possui seus soldados.

Cada uma possui seus recursos.

Entretanto...

todas trabalham como se fossem uma única cidade.

É exatamente isso que acontece.

Diversos sistemas IBM Z compartilham recursos através do Coupling Facility, coordenando locks, caches e estruturas compartilhadas.

O resultado?

Escalabilidade quase linear.

Disponibilidade extraordinária.

Capacidade de crescimento contínuo.

É uma das arquiteturas mais elegantes já construídas na história da computação.


Capítulo XI

Alta Disponibilidade não é Disaster Recovery

Esse tema costuma aparecer em entrevistas técnicas.

E muitos candidatos confundem os conceitos.

High Availability (HA) trata de falhas locais.

Uma região caiu?

Outra assume.

Um processador apresentou defeito?

Outro continua executando.

Disaster Recovery (DR) lida com eventos muito maiores.

Incêndios.

Enchentes.

Falhas elétricas generalizadas.

Ataques físicos.

Perda completa de um Data Center.

Nesses casos, outro ambiente — muitas vezes localizado em outra cidade ou país — assume as operações.

Uma boa analogia é imaginar um castelo.

Se uma torre desmorona, os soldados continuam defendendo a fortaleza.

Isso é HA.

Mas se o castelo inteiro é destruído por um dragão...

é necessário recuar para outra fortaleza.

Isso é DR.


Curiosidades que Pouca Gente Conhece

🏰 Curiosidade 1

Grandes bancos frequentemente operam com dezenas de Regiões CICS simultaneamente.


🏰 Curiosidade 2

Alguns ambientes processam dezenas de milhares de transações por segundo.


🏰 Curiosidade 3

É comum realizar manutenção em hardware IBM Z sem desligar aplicações críticas.


🏰 Curiosidade 4

Muitos clientes nunca percebem que uma região inteira foi reiniciada durante o expediente.


🏰 Curiosidade 5

Grande parte da confiabilidade do Mainframe vem da combinação entre hardware, sistema operacional, middleware e processos operacionais — não de um único componente.


Passo a Passo para o Padawan COBOL Entender HA

Se você está começando agora, siga esta trilha de estudos:

  1. Aprenda a arquitetura básica do z/OS.

  2. Entenda o papel do CICS.

  3. Estude a diferença entre TOR, AOR e FOR.

  4. Aprenda como funciona o WLM.

  5. Conheça o Db2 Data Sharing.

  6. Estude VSAM RLS.

  7. Entenda Syncpoint e Commit.

  8. Aprenda conceitos de rollback e recuperação.

  9. Descubra como funciona o Parallel Sysplex.

  10. Explore ferramentas de monitoramento como RMF, SMF e OMEGAMON.

Essa sequência fará muito mais sentido do que tentar estudar todos os componentes isoladamente.


Easter Egg Bellacosa Mainframe ☕

Existe uma antiga lenda entre os Sysprogs.

Ela diz que, em algum lugar escondido dentro do Coupling Facility, existe um Palantír Digital.

Apenas os arquitetos mais experientes conseguem enxergar através dele o fluxo de todas as transações da Terra Média do Mainframe. Enquanto um programador iniciante vê apenas um programa COBOL executando um EXEC CICS LINK, o velho mago observa regiões inteiras assumindo cargas, WLM redistribuindo trabalho, Db2 sincronizando dados e o Sysplex mantendo o reino unido.

Dizem ainda que Gandalf jamais utilizou magia para derrotar Sauron.

Na verdade...

ele apenas configurou corretamente o WLM, distribuiu as transações entre múltiplas regiões CICS e deixou que a Alta Disponibilidade fizesse o restante.

Claro... nenhum manual da IBM confirma essa história.

Mas todo bom Sysprog sorri discretamente quando alguém menciona que "o sistema simplesmente não pode parar".


Conclusão

Assim como A Sociedade do Anel não era formada por heróis isolados, a Alta Disponibilidade em um ambiente CICS também é resultado da cooperação entre diversos componentes. O COBOL executa a lógica de negócio, o CICS coordena as transações, o WLM distribui inteligentemente a carga, o Db2 e o VSAM garantem a consistência dos dados, o monitoramento identifica problemas antes que eles afetem os usuários e o Parallel Sysplex transforma múltiplos sistemas em uma infraestrutura única e resiliente.

Para o programador COBOL iniciante, compreender esses conceitos representa uma mudança profunda de perspectiva. Você deixa de enxergar apenas linhas de código e passa a entender o ecossistema que mantém bancos, companhias aéreas, seguradoras, bolsas de valores e governos funcionando ininterruptamente.

No fim da jornada, a maior lição não é aprender a escrever um programa perfeito, mas compreender que, em computação corporativa, a verdadeira excelência está em construir sistemas capazes de continuar servindo milhões de pessoas mesmo quando partes da infraestrutura falham. Esse é o espírito do Mainframe: transformar redundância em confiança, engenharia em continuidade de negócios e tecnologia em um serviço tão confiável que a maioria das pessoas sequer percebe que ele existe.

Porque, como diria um velho mago da Terra Média adaptado ao universo IBM Z:

"Um grande sistema não é aquele que nunca enfrenta falhas. É aquele cuja missão continua, mesmo quando uma parte da Sociedade precisa ficar para trás."

domingo, 15 de março de 2020

☕💥 Fluxogramas no Mundo Mainframe

 

Bellacosa Mainframe e o fluxograma no mundo mainframe

☕💥 Fluxogramas no Mundo Mainframe

Ou como um Padawan COBOL descobre que antes do IF WS-SALDO > ZERO, existia um desenhinho que salvava projetos milionários

"Um programa COBOL sem fluxograma é como um JCL sem JOB CARD. Talvez execute. Talvez funcione. Mas ninguém vai entender daqui seis meses."

— Mestre Bellacosa Mainframe


Introdução

Uma das maiores diferenças entre um desenvolvedor COBOL júnior de hoje e um analista de sistemas da década de 1970, 1980 ou 1990 não está na linguagem.

Não está no z/OS.

Não está no DB2.

Não está no CICS.

Está na forma de pensar software.

Hoje aprendemos:

  • Fazer código

  • Testar

  • Commitar

  • Fazer Pull Request

Antigamente aprendíamos:

  • Analisar

  • Modelar

  • Desenhar

  • Revisar

  • Aprovar

  • Codificar

E neste mundo existia um personagem muito poderoso.

O Fluxograma.


O nascimento dos fluxogramas

A ideia é muito antiga.

Vem dos trabalhos de engenharia industrial.

Frank Gilbreth

Henry Gantt

Por volta de 1921 começaram a desenhar processos industriais.

Exemplo:

Receber matéria-prima

Produzir

Inspecionar

Embalar

Enviar

Décadas depois os computadores apareceram.

E alguém percebeu:

"Programas são processos."

Logo...

Processos industriais

viraram

Processos computacionais.


O modelo Waterfall

Se você trabalha em Mainframe bancário provavelmente ainda verá isso.

Waterfall.

As fases clássicas:

Requisitos

Análise

Fluxogramas

Especificação Técnica

Codificação

Teste

Implantação


Documentos clássicos do Waterfall

Documento Funcional

O que o sistema faz.

Exemplo:

Pagamento de boleto

Regra:

Se vencido

cobrar multa

Se pago em dia

valor normal


Documento Técnico

Como será implementado.

Exemplo:

Programa:

PAGBOL01

Tabela:

TB_BOLETO

Transação:

PB01

Copybooks

CPBOLETO


Fluxograma

É a ponte entre os dois.

Negócio

Fluxograma

COBOL


Bellacosa Mainframe e os simbolos de fluxograma

O que é um Fluxograma?

É uma representação gráfica de um algoritmo.

Ao invés de escrever:

IF SALDO > ZERO
   DISPLAY "OK"
ELSE
   DISPLAY "NEGADO"
END-IF

Desenhamos.

        ◇
SALDO > 0 ?
   /    \
 SIM    NÃO
 ↓       ↓
OK    NEGADO

Nosso cérebro entende imagens mais rapidamente.

Por isso funcionam.


Símbolos principais

Oval

Significado:

Início

Fim

Exemplo

 _______
(START )
 -------

ou

 _______
( END  )
 -------

Retângulo

Processamento.

Fazer algo.

Exemplo:

Calcular juros

Atualizar cadastro

Mover campos


Exemplo COBOL

COMPUTE JUROS =
SALDO * 0.05

Fluxograma

□ Calcular juros


Losango

Decisão.

Pergunta.

Tem duas saídas.

SIM

NÃO

Exemplo

Cliente VIP?


COBOL

IF CLIENTE-VIP='S'

Paralelogramo

Entrada e saída.

DISPLAY

ACCEPT

RECEIVE

SEND


Batch

Ler arquivo

Online

Receber PFKEY


Seta

Fluxo.

Indica sequência.

Sem seta.

Existe caos.

Com seta.

Existe entendimento.


Círculo

Conector.

Liga páginas.

Muito usado em especificações gigantes.

Página 1

○A

Página 10

○A

continuação


Bellacosa Mainframe e um fluxograma cobol batch

Fluxograma de Batch COBOL

Imagine:

Pagar folha salarial.


Desenho

START

Abrir arquivo

Ler funcionário

Fim Arquivo?

Sim

Gerar relatório

END

Não

Calcular salário

Gravar saída

Ler próximo


COBOL

OPEN INPUT FUNCIONARIO

PERFORM UNTIL EOF='S'

 READ FUNCIONARIO

   AT END
      MOVE 'S' TO EOF

   NOT AT END

      PERFORM CALCULA

      WRITE REG-SAIDA

 END-READ

END-PERFORM

Bellacosa Mainframe exemplo de fluxograma cobol vsam


Fluxograma para VSAM

Abrir KSDS

READ

FOUND?

SIM

UPDATE

REWRITE

NÃO

WRITE

END


Bellacosa Mainframe exemplo de fluxograma online cics

Fluxograma Online CICS

Exemplo.

Consulta saldo.


START

Receber tela

ENTER?

SIM

Validar conta

Conta existe?

SIM

Ler DB2

Enviar tela

NÃO

Mensagem erro

END


COBOL

EXEC CICS RECEIVE MAP


EXEC SQL

SELECT SALDO

INTO :WS-SALDO

FROM CONTA


END-EXEC


EXEC CICS SEND MAP


END-EXEC

Bellacosa Mainframe exemplo de fluxograma db2

Fluxograma com DB2

Exemplo.

Transferência bancária.


START

Receber origem

Receber destino

Valor válido?

SIM

BEGIN UNIT OF WORK

SELECT

UPDATE

UPDATE

COMMIT

NÃO

ROLLBACK

END


Fluxograma das tabelas DB2

Tabela

CLIENTE

Tabela

CONTA

Tabela

MOVIMENTO

Fluxo

CLIENTE

CONTA

MOVIMENTO


Exemplo SQL

SELECT
C.NOME,
M.VALOR

FROM CLIENTE C

JOIN CONTA CT

ON...

JOIN MOVIMENTO M

Fluxograma ajuda a enxergar joins.


Workflow

Muitos confundem.

Fluxograma

não é

Workflow

Mas workflow pode usar fluxograma.


Exemplo

Solicitação crédito

Cliente

Análise

Aprovação gerente

Compliance

Liberação


Hoje isso está em:

IBM BPM

Camunda

ServiceNow

Power Automate


Fluxos de diálogo

Muito usado em CICS.

Tela login

Senha válida?

Sim

Menu

Não

Mensagem erro


Chatbots fazem isso.

ChatGPT faz isso.

URA faz isso.

PIX faz isso.


Boas práticas

1 Não cruzar linhas

Errado

Linhas embaralhadas.

Causa dor psicológica.


2 Usar nomes claros

Errado

Processo 1

Correto

Calcular IOF


3 Uma decisão por vez

Evita confusão.


4 Modularizar

Subfluxos.

Exemplo

Pagamento

Calcular imposto

Fluxograma separado


Curiosidades

Easter Egg 1

COBOL nasceu em 1959.

Fluxogramas já eram padrão.


Easter Egg 2

Muitos programadores COBOL dos anos 80 codificavam olhando apenas para fluxogramas.

Nem tinham acesso ao usuário.


Easter Egg 3

Ferramentas CASE prometiam gerar COBOL automaticamente.

Excelerator

ADW

CoolGen

IEF

Pacbase

A ideia era:

Desenhar

Gerar programa

Compilar


Easter Egg 4

IBM usou fluxogramas extensivamente na documentação do OS/360.

Centenas de páginas.


Easter Egg 5

DFSORT pode ser representado perfeitamente por fluxograma.

INPUT

SORT

SUM

OUTREC

OUTPUT


Por que ainda usamos em Mainframe?

Porque sistemas bancários possuem:

Centenas de regras

Milhares de IFs

Milhões de contas

Um código COBOL pode ter:

30000 linhas

500 parágrafos

200 IFs

Ler isso é cansativo.

Ver um desenho leva segundos.


O Fluxograma como ferramenta de sobrevivência do Padawan COBOL

Imagine receber:

Programa:

FINA0345

38 mil linhas.

Criado em 1994.

Sem documentação.

Sem analista.

Sem usuário.

Sem autor.

Você abre.

Encontra:

PERFORM P1120

PERFORM P1130

PERFORM P1140

PERFORM P1150

O que fazem?

Ninguém sabe.

Mas após desenhar:

START

↓

Validar Cliente

↓

Consultar DB2

↓

Calcular Limite

↓

Atualizar Histórico

↓

Gerar Extrato

↓

END

Tudo fica claro.

É por isso que arquitetos, analistas de sistemas, especialistas em CICS, DB2, IMS, MQ, BPM e até equipes DevOps continuam utilizando fluxogramas.

Eles não substituem COBOL.

Não substituem UML.

Não substituem documentação funcional.

Mas fazem algo extremamente valioso: transformam milhares de linhas de código em uma história visual que qualquer pessoa consegue seguir.

E, no universo Bellacosa Mainframe, talvez esta seja a melhor definição possível:

Fluxograma é o mapa da dungeon. COBOL é a espada. DB2 é o tesouro. CICS é o portal de entrada. E o programador júnior que aprende a desenhar processos deixa de ser apenas um codificador e começa a pensar como um verdadeiro Analista de Sistemas do Reino IBM Z. ☕🚀

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...