☕ 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

Mostrar mensagens com a etiqueta Grafos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Grafos. Mostrar todas as mensagens

quinta-feira, 22 de maio de 2025

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Bellacosa Mainframe e o scheduler da curiosidade 

☕ Um Café no Bellacosa Mainframe

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Por Vagner Bellacosa

Existe um problema novo acontecendo na minha mesa.

Não é falta de documentação.

Não é falta de livros.

Não é falta de cursos.

Não é falta de acesso à informação.

Também não é exatamente falta de tempo — embora os boletos continuem insistindo que o dia tenha apenas 24 horas.

O problema é quase o contrário.

Há conhecimento demais ao alcance das mãos.

E então chegou a Inteligência Artificial.

Agora existe uma criatura disponível praticamente a qualquer momento que aceita perguntas sobre COBOL, filosofia, economia, anime, história, mainframe, arqueologia, inteligência artificial, acidentes aéreos, linguística, segurança, psicologia, grafos, bancos, YAML, XML, Atari e aquela dúvida completamente absurda que apareceu às duas da manhã e que você jamais perguntaria numa reunião de trabalho.

Você pergunta.

Ela responde.

A resposta produz outra pergunta.

Essa produz três.

Uma delas parece muito mais interessante do que a pergunta original.

Você segue por ali.

Duas horas depois está lendo sobre uma tabuinha de argila babilônica de milhares de anos atrás e já não consegue explicar exatamente como uma conversa sobre COBOL terminou na Mesopotâmia.

Bem-vindo ao problema.

Ou talvez...

bem-vindo à solução.

Coloque café na xícara.

Hoje não vamos falar exatamente sobre COBOL.

Vamos falar sobre o programa mais complexo que provavelmente executaremos durante toda a nossa vida:

a nossa própria curiosidade.

E aparentemente o scheduler está tendo problemas.


$HASP100: JOB CURIOSIDADE ON READER

Outro dia olhei para minha lista de conversas fixadas no ChatGPT.

Ali estavam coisas como:

Anime Another Resumo
Memórias Vagnerianas
JSON no COBOL Mainframe
Manias Econômicas Históricas
Curso Lógica Programação
YAML para Programadores
Inuyasha Anime e Legado
Impacto de Conan no Anime
Análise de Erros XML
Homenagem ao Atari

Olhei aquilo e comecei a rir.

Não porque fossem assuntos ruins.

Justamente o contrário.

Todos eram interessantes.

Esse era o problema.

Cada conversa havia começado por alguma razão perfeitamente legítima. Algumas estavam virando artigos. Outras eram investigações técnicas. Algumas eram memórias. Outras tinham começado simplesmente porque alguma coisa despertara curiosidade.

Nenhuma havia realmente terminado.

E então percebi algo.

Minha lista de conversas estava começando a parecer:

SDSF STATUS DISPLAY

Só que em vez de JOBs havia ideias.

JOBNAME     STATUS
COBOLJSON   ACTIVE
YAML001     HELD
ATARI001    WAITING
INUYASHA    ACTIVE
MEMORIA     ACTIVE
ECONHIST    HELD
XMLERROR    ACTIVE
CONAN001    WAITING
LOGICA15    ACTIVE

E em algum lugar do sistema:

30 JOBS ACTIVE
47 JOBS WAITING
123 JOBS DISCOVERED

Nenhum querendo emitir:

$HASP395 JOB ENDED

Foi quando percebi que talvez tivéssemos inventado acidentalmente uma espécie de JES2 da curiosidade intelectual.

E o ChatGPT estava funcionando como uma mistura perigosa de READER, CONVERTER, EXECUTOR e operador da console.


A escola ensinou conhecimento como uma fila

Durante muito tempo fomos educados segundo uma estrutura predominantemente linear.

Capítulo 1.

Depois capítulo 2.

Depois capítulo 3.

Prova.

Próxima matéria.

A própria estrutura física dos livros reforçava isso.

Página 1 → página 2 → página 3.

Claro que sempre existiram notas de rodapé, referências e bibliografias. Mas havia um custo para abandonar a estrada principal.

Imagine estudar alguma coisa em 1985.

Você encontra uma referência interessante:

"Esse conceito deriva dos trabalhos de Fulano publicados em 1967."

Interessante.

Mas você não possui o livro de Fulano.

Talvez exista na biblioteca.

Talvez precise pedir emprestado.

Talvez nem esteja traduzido.

Então você faz uma anotação:

Pesquisar Fulano depois.

E continua lendo.

A escassez de informação produzia involuntariamente uma coisa extremamente valiosa:

foco.

Não porque as pessoas fossem necessariamente mais disciplinadas.

Mas porque perseguir cada ramificação era caro.

Hoje o custo marginal de abrir outra porta intelectual aproxima-se perigosamente de zero.

Estou lendo sobre COBOL.

Encontro "JSON GENERATE".

Pesquiso.

Descubro JSON PARSE.

Pergunto ao ChatGPT.

Aparece uma discussão sobre interoperabilidade.

Interoperabilidade lembra APIs.

APIs levam ao z/OS Connect.

z/OS Connect leva a REST.

REST leva a OpenAPI.

OpenAPI leva a YAML.

YAML lembra pipelines.

Pipelines levam a Jenkins.

Jenkins leva a DevOps.

DevOps leva a agentes de IA.

Agentes levam a sistemas autônomos.

Sistemas autônomos levam a governança.

Governança leva a acidentes.

Acidentes levam à aviação.

Aviação leva a Crew Resource Management.

CRM leva a psicologia organizacional.

Psicologia leva a vieses cognitivos.

E de repente...

onde está o JSON?

Ele continua lá.

Cinco níveis acima no stack trace da curiosidade.


Talvez estejamos pensando errado sobre conhecimento

Aqui aparece algo fascinante.

Talvez o problema seja esperar que conhecimento verdadeiro tenha estrutura linear.

Porque ele não tem.

Conhecimento parece muito mais um grafo.

Para quem passou recentemente pelo Neo4j, a analogia é irresistível.

Imagine:

(:Pessoa)-[:ESTUDA]->(:COBOL)

(:COBOL)-[:EXECUTA_EM]->(:Mainframe)

(:Mainframe)-[:UTILIZA]->(:zOS)

(:zOS)-[:POSSUI]->(:JES2)

(:JES2)-[:GERENCIA]->(:Jobs)

(:Jobs)-[:PODEM_FALHAR_COM]->(:ABEND)

(:ABEND)-[:EXIGE]->(:Diagnostico)

(:Diagnostico)-[:USA]->(:Raciocinio)

(:Raciocinio)-[:SOFRE_COM]->(:ViesCognitivo)

(:ViesCognitivo)-[:APARECE_EM]->(:Aviacao)

(:ViesCognitivo)-[:APARECE_EM]->(:Medicina)

(:ViesCognitivo)-[:APARECE_EM]->(:MercadoFinanceiro)

Agora faça uma pergunta aparentemente inocente:

"Como diagnosticar melhor um problema em produção?"

Podemos começar no COBOL e terminar estudando Sherlock Holmes, House, Patrick Jane, Kahneman, acidentes aéreos e medicina diagnóstica.

E isso não é necessariamente desvio.

Pode ser travessia do grafo.


O ChatGPT virou uma máquina de criar arestas

Essa talvez seja uma das transformações intelectuais mais interessantes provocadas pelos grandes modelos de linguagem.

Google tradicionalmente é extraordinário para encontrar nós.

Você pergunta:

IBM COBOL JSON GENERATE

e recebe documentos relacionados ao assunto.

Mas numa conversa podemos fazer algo diferente:

"Isso me lembrou o problema de comunicação entre pilotos em acidentes aéreos. Existe alguma relação conceitual?"

Agora estamos procurando uma aresta.

COBOL → operação → incidente → comunicação → aviação

Ou:

"Essa arquitetura de agentes lembra CICS?"

Outra aresta.

"O problema de memória de agentes lembra checkpoint/restart?"

Outra.

"Essa ideia econômica existia na Roma antiga?"

Outra.

"Esse comportamento de IA lembra alguma coisa da psicologia cognitiva?"

Outra.

É como se tivéssemos colocado diante do grafo uma máquina especializada em sugerir:

MATCH (ideia)-[r:?]->(outra_ideia)
RETURN outra_ideia

Só existe um pequeno problema.

O MATCH não termina.


O Rabbit Hole virou feature

Existe uma expressão inglesa maravilhosa:

rabbit hole.

A toca do coelho.

Alice vê o coelho, entra atrás dele e descobre que aquilo era apenas a entrada para um universo inteiro.

A Internet já havia industrializado rabbit holes.

A IA generativa colocou elevadores dentro deles.

Você pergunta:

"Por que isso acontece?"

Recebe resposta.

Pergunta:

"Mas de onde veio?"

Resposta.

"Existe precedente histórico?"

Resposta.

"Quem discordava?"

Resposta.

"Isso ainda é válido?"

Resposta.

"E se aplicarmos ao mainframe?"

Resposta.

"E ao mercado financeiro?"

Resposta.

"E aos agentes de IA?"

Resposta.

Às 03:17 da manhã:

"Então precisamos voltar aos babilônios."

Parabéns.

Você começou querendo entender um parâmetro do JCL.


A diferença entre distração e exploração

Mas precisamos tomar cuidado para não diagnosticar toda ramificação como déficit de atenção.

Há uma diferença enorme entre:

COBOL
 ↓
Instagram
 ↓
meme
 ↓
vídeo
 ↓
notícia
 ↓
WhatsApp
 ↓
esqueci o COBOL

e:

COBOL
 ↓
Mainframe
 ↓
Sistemas críticos
 ↓
Resiliência
 ↓
Falhas
 ↓
Fator humano
 ↓
Psicologia cognitiva
 ↓
Gestão de incidentes

O primeiro fluxo provavelmente representa distração.

O segundo pode representar exploração intelectual.

Existe coerência semântica.

O problema é que ambos consomem o mesmo recurso físico:

tempo.

Seu cérebro pode ter descoberto a conexão intelectual mais extraordinária da semana.

O relógio continuará dizendo:

03:42.


O verdadeiro recurso escasso mudou

Durante séculos o recurso escasso foi informação.

Hoje, para grande parte de nós, não é mais.

Temos Wikipedia.

Livros digitais.

Papers.

Vídeos.

Cursos.

Podcasts.

Blogs.

GitHub.

Documentação.

Fóruns.

Reddit.

Stack Overflow.

ChatGPT.

Outras IAs.

E bilhões de páginas indexadas.

O recurso escasso passou a ser:

atenção.

E logo atrás:

capacidade de seleção.

A pergunta intelectual moderna não é apenas:

"O que devo aprender?"

É também:

"O que deliberadamente não vou aprender agora?"

Essa segunda pergunta é muito mais cruel.

Porque dizer "não" para algo desinteressante é fácil.

O verdadeiro problema é dizer:

"Isso é fascinante. Mas ficará para depois."


Surge o backlog intelectual

É exatamente aí que nasce nossa lista.

JSON no COBOL
YAML
XML
Atari
Anime
Economia
Memórias
IA
Segurança
História

Ela não é necessariamente um cemitério de projetos abandonados.

Talvez seja algo mais interessante:

um buffer intelectual.

Uma área de spool.

A ideia chegou.

Foi registrada.

Ainda não existem recursos disponíveis para executá-la.

Então:

JOB STATUS = HELD

Isso é infinitamente melhor do que perder a ideia.

O problema começa quando confundimos:

HELD

com:

FAILED

Uma investigação estacionada não fracassou.

Ela apenas perdeu prioridade para outra.


Precisamos de WLM para a cabeça

Quem trabalha com mainframe imediatamente perceberá o próximo problema.

Se existem dezenas de workloads competindo pelos mesmos recursos, alguém precisa estabelecer prioridades.

No z/OS temos Workload Manager.

Na cabeça temos...

Bem...

Café.

Talvez seja justamente aí que precisamos melhorar.

Imagine um WLM intelectual:

SERVICE CLASS: PRODUCAO
-----------------------
Curso atual
Trabalho
Artigo com prazo
Aula da semana

SERVICE CLASS: ALTA
-------------------
Pesquisa diretamente relacionada
Projeto em andamento

SERVICE CLASS: DISCRETIONARY
----------------------------
Anime obscuro de 1987
História do Atari
Origem de palavra suméria
Tecnologia soviética esquecida

SERVICE CLASS: SYSOTHER
-----------------------
"Por que os romanos não inventaram..."

😂

O objetivo não seria matar SYSOTHER.

Aliás, algumas das descobertas mais deliciosas provavelmente estão lá.

O objetivo seria impedir SYSOTHER de consumir toda a capacidade enquanto PRODUCAO está atrasada.


A IA não eliminou a necessidade de disciplina

Esse é um ponto importante.

Existe uma fantasia contemporânea segundo a qual IA permitirá aprender tudo.

Não permitirá.

Pode reduzir brutalmente o custo de explicação.

Pode resumir.

Pode traduzir.

Pode comparar.

Pode produzir exemplos.

Pode adaptar a linguagem.

Pode ajudar a encontrar relações.

Pode responder perguntas imediatamente.

Mas existe uma coisa que ela ainda não consegue aumentar:

24 horas = 24 horas

Podemos aumentar nossa eficiência.

Não podemos aumentar indefinidamente nosso throughput humano.

E pior:

compreender continua custando tempo.

Ler uma explicação não significa incorporá-la.

Reconhecer um conceito não significa dominá-lo.

Assistir a uma demonstração não significa conseguir reproduzi-la.

Receber código funcionando não significa compreender sua arquitetura.

Esse talvez seja um dos perigos da aprendizagem com IA:

confundir velocidade de obtenção da resposta com velocidade de aquisição do conhecimento.

São coisas diferentes.

Muito diferentes.


Conhecimento não é download

Se conhecimento fosse simplesmente transferência de bytes, poderíamos fazer:

//LEARN EXEC PGM=UPLOAD
//SYSIN DD *
  COBOL
  NEO4J
  PYTHON
  QUANTUM
  JAPANESE
/*

Resultado:

IEC999I KNOWLEDGE SUCCESSFULLY INSTALLED

Infelizmente não funciona.

Aprendizagem exige reconstrução interna.

Você precisa errar.

Relacionar.

Esquecer.

Relembrar.

Aplicar.

Comparar.

Explicar para outra pessoa.

Encontrar contradições.

Reformular.

Voltar meses depois e perceber que aquilo que parecia óbvio não era.

A IA pode acompanhar todo esse processo.

Mas não pode simplesmente substituir o processo.


Talvez nossa aparente desorganização esconda alguma coisa valiosa

Aqui entra uma hipótese que me fascina.

E se parte dessas ramificações não for desperdício?

E se estivermos construindo uma espécie de Knowledge Graph pessoal?

Durante décadas de trabalho uma pessoa acumula experiências.

Banco.

Mainframe.

Incidentes.

Programação.

Gestão.

Pessoas.

Viagens.

Livros.

Filmes.

Histórias.

Tecnologias.

Fracassos.

Acertos.

Essas coisas ficam armazenadas como nós aparentemente desconectados.

Então surge uma conversa.

Um assunto ativa outro.

Uma memória conecta-se a um conceito novo.

Uma história profissional antiga encontra uma teoria publicada décadas depois.

De repente:

(:Experiencia1989)
      |
      | [:EXPLICA]
      v
(:Conceito2026)

A experiência sempre esteve lá.

Faltava a aresta.

Talvez uma das funções mais poderosas da IA para alguém que acumulou décadas de experiência não seja simplesmente ensinar fatos novos.

Talvez seja ajudar a indexar intelectualmente a própria vida.

Isso é enorme.


Curiosidade como algoritmo de busca

Uma pessoa curiosa executa continuamente algo parecido com:

while alive:
    observe()
    question()
    connect()
    investigate()
    update_model()

Só existe um pequeno bug:

while alive:

não possui END-IF.

E aparentemente tampouco possui MAX-DEPTH.

😂

Por isso precisamos talvez acrescentar:

IF DEPTH > ACCEPTABLE-LIMIT
   MOVE CURRENT-TOPIC TO BACKLOG
   PERFORM RETURN-TO-MAIN-QUEST
END-IF

Esse talvez seja o algoritmo intelectual necessário para a era da IA.

Não bloquear rabbit holes.

Controlar profundidade.


O conceito de estacionamento intelectual

Imagine que estamos estudando agentes de IA.

Durante a conversa surgem:

[ ] memória vetorial
[ ] MCP
[ ] sistemas multiagentes
[ ] segurança
[ ] prompt injection
[ ] teoria de jogos
[ ] swarm intelligence
[ ] governança
[ ] custos de inferência
[ ] mainframe integration

Não precisamos abrir dez frentes.

Podemos dizer:

CURRENT:
Agentes e memória

PARKED:
MCP
Segurança
Swarm
Governança
Mainframe integration

A curiosidade continua viva.

Mas o scheduler recupera o controle.

Essa simples mudança psicológica é poderosa porque reduz aquela sensação:

"Estou deixando algo importante para trás."

Não.

Você colocou no spool.


O perigo oposto: nunca terminar nada

Agora precisamos tomar a red pill.

Existe uma versão romântica da curiosidade que pode virar desculpa.

"Sou explorador."

"Tenho muitos interesses."

"Estou conectando conhecimentos."

Tudo verdadeiro.

Mas existe um teste brutal:

o que foi concluído?

Porque conhecimento também precisa produzir $HASP395.

Artigo publicado.

Programa funcionando.

Curso concluído.

Experimento documentado.

Livro lido.

Hipótese descartada.

Aula preparada.

Problema resolvido.

Sem isso podemos passar anos em:

$HASP373 JOB STARTED

sem jamais chegar a:

$HASP395 JOB ENDED

E então o backlog não é biblioteca.

É dívida.


Talvez terminar seja uma tecnologia

Essa é outra ideia que merece reflexão.

Somos treinados para começar.

Cursos vendem começos.

Tutoriais ensinam começos.

Plataformas recomendam novos começos.

Algoritmos apresentam novidades.

IA responde imediatamente à próxima curiosidade.

Pouquíssimos sistemas são economicamente incentivados a dizer:

"Não abra nada novo. Termine aquilo."

Porque novidade gera clique.

Descoberta gera dopamina.

Conclusão frequentemente exige a parte menos glamourosa:

revisar.

corrigir.

testar.

reescrever.

organizar.

publicar.

documentar.

É muito mais divertido descobrir outro rabbit hole.

Talvez finalização tenha se tornado uma competência intelectual própria.


O Scheduler da Curiosidade

Chegamos então ao nosso pequeno sistema operacional mental.

Eu o imaginaria assim:

                 ┌───────────────┐
                 │ CURIOSIDADE   │
                 └───────┬───────┘
                         │
                         ▼
                  NOVA PERGUNTA
                         │
               ┌─────────┴─────────┐
               │                   │
         RELEVANTE AGORA?          NÃO
               │                   │
              SIM                  ▼
               │               BACKLOG
               ▼
           EXECUTAR
               │
         ┌─────┴─────┐
         │           │
   NOVO RAMO?       NÃO
         │           │
        SIM          ▼
         │       CONCLUIR
         ▼           │
    REGISTRAR        ▼
         │       $HASP395
         │
         └──────► VOLTAR

Parece trivial.

Mas pense na diferença.

Não estamos dizendo:

"Pare de ser curioso."

Estamos dizendo:

"Faça scheduling da curiosidade."


E onde vamos parar?

Essa talvez seja a pergunta mais divertida.

Provavelmente em lugar nenhum.

E isso não é necessariamente ruim.

Porque conhecimento não possui tela final.

Não existe:

CONGRATULATIONS
YOU HAVE COMPLETED KNOWLEDGE
100%

Quanto mais aprendemos, maior parece o mapa.

É quase cruel.

Quando sabemos pouco, o mundo parece relativamente simples.

Quando aprendemos mais, começamos a enxergar as dependências.

Depois enxergamos as exceções.

Depois as controvérsias.

Depois a história.

Depois as escolas rivais.

Depois descobrimos que algumas certezas eram aproximações.

O mapa aumenta justamente porque aprendemos a enxergá-lo.

Talvez seja esse o paradoxo definitivo da curiosidade:

cada resposta aumenta o território das perguntas.


A IA tornou o universo intelectual navegável — não finito

Esse ponto é fundamental.

ChatGPT e outras ferramentas não transformaram conhecimento em algo que podemos terminar.

Transformaram conhecimento em algo que podemos percorrer com muito menos atrito.

Antes havia oceanos entre os continentes intelectuais.

Agora construímos pontes.

Isso muda completamente a viagem.

Mas não reduz o tamanho do planeta.

Talvez até faça o contrário.

Quando percebemos que COBOL pode conversar com IA, que mainframe pode conversar com cloud, que psicologia pode conversar com segurança, que história pode explicar tecnologia e que experiências de décadas atrás podem iluminar problemas atuais...

o mundo fica intelectualmente maior.

Não menor.


O profissional em T

Durante muito tempo falou-se no profissional em T.

Conhecimento amplo horizontalmente.

Especialização profunda verticalmente.

Talvez a IA esteja favorecendo outro formato.

Algo parecido com um grafo.

Você possui alguns nós extremamente profundos.

Mainframe.

COBOL.

Sistemas financeiros.

E centenas de conexões menos profundas:

        História
           |
Economia--Mainframe--IA
           |
      Segurança
       /      \
 Psicologia  Aviação
      |
  Gestão

O valor não está necessariamente em dominar todos esses campos.

Está também em conseguir perceber:

"Eu já vi esse padrão em outro lugar."

Essa capacidade é extraordinariamente poderosa.

Porque inovação muitas vezes nasce justamente da transferência de modelos entre domínios.


Easter egg: talvez o cérebro seja um mainframe ruim

Antes que algum neurocientista jogue café em mim:

é uma metáfora.

Mas divertida.

Temos memória.

Temos processamento.

Temos prioridades.

Temos interrupções.

Temos cache.

Temos processos esquecidos.

Temos informações que sabemos que estão armazenadas em algum lugar, mas cujo endereço aparentemente foi perdido.

Temos:

"Eu conheço essa pessoa..."

seguido de:

SEARCHING...
SEARCHING...
SEARCHING...

Três horas depois, tomando banho:

HIT!

😂

Temos também algo equivalente a storage leak:

uma música ruim de 1987 permanece perfeitamente armazenada enquanto esquecemos por que entramos na cozinha.

O hardware humano definitivamente possui algumas decisões arquitetônicas curiosas.


O grande desafio não será saber mais

Será governar o que queremos saber.

Isso talvez seja uma das grandes competências da próxima década.

Não apenas prompt engineering.

Não apenas saber perguntar.

Mas saber decidir:

qual pergunta merece continuação?

qual merece estacionamento?

qual merece profundidade?

qual merece abandono?

qual precisa virar projeto?

qual deve permanecer apenas como curiosidade?

Porque podemos perguntar praticamente indefinidamente.

Mas não podemos viver indefinidamente.

Existe aí uma dimensão profundamente humana que nenhuma otimização elimina.

Escolher aprender alguma coisa significa escolher não aprender outras naquele momento.

Escolher escrever um artigo significa deixar três esperando.

Escolher terminar um curso significa ignorar temporariamente cinco tecnologias novas.

Escolher profundidade significa renunciar momentaneamente à novidade.

Esse é o verdadeiro scheduler.


Blue Pill ou Red Pill?

A Blue Pill é confortável:

"Com IA finalmente conseguirei aprender tudo."

Não.

Provavelmente acontecerá exatamente o contrário.

A IA mostrará quanto existe para aprender.

A Red Pill é mais interessante:

"Nunca aprenderei tudo. Então preciso escolher melhor minhas viagens."

Isso muda completamente nossa relação com conhecimento.

Não precisamos conquistar todo o mapa.

Podemos explorá-lo.

Construir caminhos.

Registrar descobertas.

Voltar.

Conectar regiões.

E ocasionalmente colocar uma placa:

TODO:
RETORNAR AQUI

$HASP395: ou talvez não

Chegamos ao fim deste artigo falando sobre...

Deixe-me conferir.

Começamos com conversas abertas no ChatGPT.

Passamos por JES2.

Grafos.

Neo4j.

Rabbit holes.

Psicologia.

WLM.

Aprendizagem.

Gestão de atenção.

IA.

Knowledge Graph.

E terminamos discutindo finitude humana.

Nada mal para uma conversa que começou olhando uma barra lateral cheia de chats inacabados.

Talvez seja exatamente esse o ponto.

A curiosidade intelectual não é uma estrada.

É uma rede.

Cada pergunta é um nó.

Cada associação cria uma aresta.

Cada experiência antiga pode ganhar significado novo quando conectada a alguma coisa aprendida hoje.

ChatGPT não inventou esse comportamento.

Nós sempre fizemos isso.

A diferença é que agora existe uma ferramenta capaz de acompanhar nossa corrida pelo grafo quase na velocidade em que surgem as perguntas.

E isso é maravilhoso.

Também é perigoso.

Porque sempre haverá outra aresta.

Sempre haverá outro nó.

Sempre haverá:

"Só mais uma pergunta..."

O verdadeiro desafio intelectual da era da IA talvez não seja descobrir como começar uma investigação.

Isso ficou absurdamente fácil.

Será aprender quando continuar, quando estacionar e quando terminar.

Precisamos ser simultaneamente exploradores e operadores.

Curiosos e schedulers.

Alice e JES2.

Precisamos permitir:

$HASP373 CURIOSITY STARTED

Mas de vez em quando precisamos olhar para o backlog, escolher alguma coisa e exigir:

$HASP395 CURIOSITY ENDED

Mesmo sabendo que aquilo nunca terminou completamente.

Porque uma boa resposta deixa uma pergunta.

Uma boa pergunta encontra outra área.

Uma experiência encontra uma teoria.

Uma memória encontra significado.

Um artigo encontra outro artigo.

E talvez seja justamente por isso que continuamos estudando depois de décadas.

Não porque estejamos chegando ao fim.

Mas porque finalmente começamos a enxergar o tamanho do grafo.

Então onde vamos parar?

Não faço a menor ideia.

Provavelmente começaremos falando sobre o scheduler da curiosidade, alguém mencionará teoria dos grafos, daí surgirá a história dos sete graus de separação, que levará a redes sociais, que levará a algoritmos de recomendação, que levará a manipulação comportamental, que levará a Skinner, que levará a psicologia, que lembrará inteligência artificial...

...e daqui a pouco estaremos novamente discutindo COBOL.

Talvez exista uma explicação técnica para isso.

Ou talvez seja simplesmente:

//CURIOS EXEC PGM=LIFE
//PARM DD *
   MAXDEPTH=UNLIMITED
   CURIOSITY=YES
   COFFEE=STRONG
   RETURN=OPTIONAL
/*

IEFBR14 provavelmente não resolverá.

☕ Café terminado.

Artigo terminado.

JOB terminado.

Finalmente:

$HASP395 CURIOSITY ENDED

...

Espera.

Se conhecimento funciona como grafo, será que nosso backlog de conversas poderia ser automaticamente transformado em um grafo visual de interesses, mostrando quais assuntos deram origem a quais outros?

Droga.

$HASP100 NEWJOB ON READER

E lá vamos nós outra vez. ☕🖥️

quinta-feira, 5 de maio de 2022

DSA para Programadores COBOL Padawan

 

Bellacosa Mainframe apresenta DSA para programadores

☕ Um Café no Bellacosa Mainframe

DSA para Programadores COBOL Padawan

Você Não Precisa Decorar 500 Problemas do LeetCode. Precisa Aprender a Reconhecer Padrões.

"Todo programador iniciante acredita que grandes desenvolvedores conhecem milhares de algoritmos. Depois de alguns anos de experiência, descobre que eles conhecem apenas algumas dezenas de padrões... e sabem exatamente quando utilizá-los."


Existe uma pergunta que aparece frequentemente entre jovens programadores COBOL que desejam migrar para o universo moderno da Engenharia de Software:

"Preciso aprender LeetCode para conseguir boas oportunidades?"

Minha resposta normalmente surpreende.

Não.

Você precisa aprender como pensar.

LeetCode é uma academia.

DSA (Data Structures and Algorithms) é aprender anatomia.

Um fisiculturista pode decorar todos os exercícios da academia.

Um médico entende músculos, ossos, tendões e articulações.

Quem entende anatomia consegue criar novos exercícios.

Quem entende DSA consegue resolver problemas que nunca viu antes.

Essa é exatamente a diferença entre decorar soluções e compreender padrões.

E essa diferença vale tanto para um desenvolvedor Java quanto para um veterano de COBOL com trinta anos de experiência em sistemas bancários.


O Programador COBOL Já Conhece DSA (Mesmo Sem Saber)

Essa talvez seja a maior surpresa.

Muitos profissionais de Mainframe acreditam que DSA é uma invenção recente.

Não é.

Na verdade, você trabalha com isso há décadas.

Veja alguns exemplos.

Quando você faz uma leitura sequencial de um arquivo VSAM...

...está explorando uma estrutura de dados.

Quando faz um SEARCH ALL...

...está utilizando Binary Search.

Quando usa tabelas OCCURS...

...está manipulando Arrays.

Quando organiza registros por chave...

...está trabalhando com algoritmos de ordenação.

Quando utiliza um índice alternativo no VSAM...

...está explorando conceitos semelhantes às árvores de busca.

O que mudou foi apenas a nomenclatura.


O Grande Erro de Quem Estuda LeetCode

Imagine que alguém queira aprender COBOL.

Então começa resolvendo programas aleatórios.

Um dia faz folha de pagamento.

No outro faz cálculo de imposto.

Depois processamento de boletos.

Na semana seguinte faz conciliação bancária.

Será que ele aprenderá COBOL?

Provavelmente não.

Porque cada programa utiliza conceitos diferentes.

Com DSA acontece exatamente o mesmo.

Resolver problemas aleatórios é uma forma extremamente lenta de aprender.

Muito melhor é dominar um padrão de cada vez.

Quando você aprende Sliding Window...

...de repente resolve cinquenta problemas diferentes.

Quando entende HashMap...

...mais cinquenta deixam de parecer difíceis.

É um efeito multiplicador.


Pensando Como um Analista de Sistemas

Um analista experiente nunca começa programando.

Ele começa fazendo perguntas.

Da mesma forma, um bom solucionador de problemas faz um diagnóstico antes de escrever uma linha de código.

Seu raciocínio deveria seguir algo parecido com isto:

Que tipo de dado eu possuo?

↓

Qual estrutura representa melhor esses dados?

↓

Existe um padrão conhecido?

↓

Qual algoritmo resolve isso?

↓

Quanto custa em tempo?

↓

Quanto custa em memória?

Perceba que programação é apenas o último passo.

O verdadeiro trabalho acontece antes.


Arrays: O Arquivo Sequencial da Programação

Se existe uma estrutura que todo programador COBOL domina intuitivamente, é o Array.

Em COBOL:

01 CLIENTES.
   05 CLIENTE OCCURS 1000 TIMES.
      10 NOME PIC X(30).

Isso é um Array.

Na maioria das linguagens modernas:

clientes[1000]

É exatamente o mesmo conceito.

O interessante é que vários algoritmos famosos trabalham exclusivamente sobre Arrays.

Entre eles:

  • Prefix Sum

  • Sliding Window

  • Kadane

  • Binary Search

Cada um resolve um tipo específico de problema.


Prefix Sum: Quando Somar Milhões de Registros Precisa Ser Rápido

Imagine um banco.

Existe um histórico diário de saldo.

O gerente pergunta:

"Qual foi a movimentação entre os dias 500 e 1800?"

A solução ingênua seria somar tudo novamente.

Mas isso custa:

O(n)

Prefix Sum cria uma tabela acumulada.

Depois disso qualquer consulta vira praticamente instantânea.

Essa ideia aparece em:

  • Data Warehouses

  • BI

  • Analytics

  • Processamento Financeiro

  • Mainframe Batch

Embora muitos profissionais não percebam, diversas rotinas históricas de fechamento utilizam exatamente esse princípio.


Sliding Window: Não Recalcule o Que Você Já Sabe

Imagine um programa que precisa descobrir os três maiores dias consecutivos de vendas.

Um iniciante faz isto:

Soma dia 1

Soma dia 2

Soma dia 3

Depois recomeça tudo.

Um desenvolvedor experiente pensa diferente.

"Já conheço dois dos três valores."

Então remove apenas o elemento que saiu da janela e adiciona o próximo.

É como acompanhar uma esteira rolante.

Você não desmonta a esteira inteira para observar o próximo objeto.

Apenas acompanha seu movimento.

Esse padrão reduz muitos problemas de O(n²) para O(n).


Binary Search: Muito Além de Procurar

Todo mundo conhece Binary Search como uma busca em listas ordenadas.

Mas existe um detalhe interessante.

Hoje ele é muito mais utilizado para responder perguntas como:

"Qual é o menor valor possível?"

"Qual é a menor capacidade de armazenamento?"

"Qual é a menor velocidade aceitável?"

Sempre que existe uma resposta monotônica, Binary Search pode aparecer.

É por isso que ele continua sendo um dos algoritmos preferidos em entrevistas.


Strings: O Mundo dos Textos

Mainframes trabalham intensamente com texto.

CPF.

Nome.

Código de Agência.

Número da Conta.

Mensagens.

Arquivos CNAB.

Tudo isso são Strings.

Existem alguns padrões clássicos.

Two Pointers

Muito útil para:

  • remover espaços

  • comparar extremos

  • detectar palíndromos

É simples.

Dois ponteiros caminham em velocidades diferentes ou em sentidos opostos.


KMP

Imagine procurar uma palavra dentro de um documento de centenas de megabytes.

Sem estratégia...

...você volta inúmeras vezes ao início.

KMP evita repetir trabalho.

Ele aprende durante a própria busca.

É um excelente exemplo de algoritmo inteligente.


HashMap: A Memória Instantânea

HashMap talvez seja a estrutura que mais transforma problemas difíceis em problemas simples.

Imagine a pergunta:

"Este CPF já apareceu?"

Sem HashMap:

Procure tudo novamente.

Com HashMap:

Consulte diretamente.

É praticamente um índice em memória.

Quem trabalhou com índices DB2 entende rapidamente essa ideia.

Não percorremos a tabela inteira.

Consultamos uma estrutura otimizada.


Pilhas (Stacks): A Forma Natural de Resolver Alguns Problemas

Uma Stack segue a regra:

Last In

First Out

Ou seja:

O último que entra é o primeiro que sai.

Pense numa pilha de JCLs impressos.

O último colocado em cima será retirado primeiro.

Stacks aparecem em:

  • compiladores

  • interpretadores

  • validação de parênteses

  • chamadas de funções

  • expressões matemáticas

Sempre que existir necessidade de "voltar" ao estado anterior, existe uma boa chance de uma Stack resolver o problema.


Filas: O Modelo Natural do Batch

Se existe uma estrutura familiar ao mundo Mainframe é a Queue.

Os Jobs entram.

Esperam.

São executados.

Saem.

JES2 e JES3 vivem exatamente desse conceito.

Fila.

Primeiro que entra.

Primeiro que sai.

O mesmo vale para sistemas de mensagens como IBM MQ.


Linked Lists: Quando a Ordem Importa Mais que a Posição

Em um Array sabemos exatamente onde cada elemento está.

Em uma Linked List sabemos apenas quem é o próximo.

Isso muda completamente a forma de navegar pelos dados.

Um algoritmo famoso utiliza dois ponteiros.

Um anda normalmente.

Outro corre duas posições.

É o famoso algoritmo da Tartaruga e da Lebre.

Ele consegue descobrir ciclos sem utilizar memória adicional.

Uma verdadeira obra de elegância.


Árvores: Muito Mais Presentes do Que Você Imagina

Quando pensamos em árvores normalmente lembramos da faculdade.

Mas elas aparecem diariamente.

Diretórios.

Menus.

JSON.

XML.

LDAP.

Catálogos.

Organogramas.

Até um Plano de Contas contábil é uma árvore.

Quando aprendemos percursos como:

  • Preorder

  • Inorder

  • Postorder

  • Level Order

Estamos aprendendo maneiras diferentes de visitar essa hierarquia.


Grafos: O Modelo Universal

Existe uma frase famosa na Ciência da Computação:

"Tudo pode ser modelado como um grafo."

Internet.

Rotas.

Redes sociais.

Dependências.

Fluxos.

Microserviços.

Tudo isso pode ser representado por nós ligados entre si.

Os principais algoritmos são:

  • BFS

  • DFS

  • Dijkstra

  • Topological Sort

Se você entende esses quatro...

...já resolve uma enorme quantidade de problemas reais.


Programação Dinâmica: A Arte de Não Fazer o Mesmo Trabalho Duas Vezes

Esse talvez seja o assunto que mais assusta iniciantes.

Mas a ideia é incrivelmente simples.

Imagine calcular Fibonacci.

Sem memória:

Fib(40)

↓

Fib(39)

↓

Fib(38)

↓

...

Os mesmos cálculos aparecem centenas de milhares de vezes.

Programação Dinâmica guarda os resultados.

Quando precisar novamente...

...apenas consulta.

No Mainframe fazemos isso frequentemente.

Tabelas em memória.

Caches.

Arquivos temporários.

Tudo isso segue exatamente essa filosofia.


Greedy: A Melhor Decisão Agora

Alguns problemas permitem escolher sempre a melhor opção local.

Quando isso acontece...

...Greedy produz soluções extremamente rápidas.

Mas cuidado.

Nem todo problema aceita essa abordagem.

Saber reconhecer quando Greedy funciona é tão importante quanto conhecer o algoritmo.


Manipulação de Bits: O Poder Escondido do Hardware

Bits ainda são fundamentais.

Operações como:

AND

OR

XOR

SHIFT

São extremamente rápidas.

Mainframes utilizam instruções de hardware especializadas justamente para explorar esse tipo de operação.

Muitos algoritmos de criptografia, compressão e otimização dependem delas.


Estruturas Avançadas

Quando os problemas ficam maiores surgem novas ferramentas.

Segment Trees.

Fenwick Trees.

Sweep Line.

Meet in the Middle.

Essas técnicas aparecem menos no dia a dia, mas são muito comuns em competições de programação e entrevistas de empresas de tecnologia.

Elas demonstram que um mesmo problema pode ser atacado por diferentes estratégias, cada uma adequada a um cenário específico.


O Que Realmente Avaliam em uma Entrevista Técnica?

Muitos imaginam que a empresa quer saber se você decorou o algoritmo de Dijkstra.

Na realidade ela observa outra coisa.

Seu raciocínio.

Ela quer entender se você consegue:

  • Identificar a estrutura de dados correta.

  • Escolher o algoritmo adequado.

  • Explicar por que essa escolha é eficiente.

  • Comparar alternativas.

  • Analisar complexidade de tempo e memória.

  • Escrever um código claro e correto.

A implementação é importante, mas a capacidade de justificar as decisões costuma pesar ainda mais.


O Caminho de Estudos para um COBOL Padawan

Se eu estivesse orientando um jovem programador COBOL hoje, seguiria esta ordem:

  1. Arrays e Strings.

  2. Hash Maps.

  3. Stacks e Queues.

  4. Linked Lists.

  5. Árvores.

  6. Grafos.

  7. Recursão.

  8. Heaps.

  9. Programação Dinâmica.

  10. Técnicas avançadas.

Depois disso, sim, começaria a resolver problemas no LeetCode, HackerRank ou plataformas semelhantes.

Porque, nesse momento, cada exercício deixaria de ser um enigma e passaria a ser um reconhecimento de padrões.


Conclusão: O Verdadeiro Poder Está na Forma de Pensar

Existe um mito de que grandes programadores possuem uma memória extraordinária e conhecem milhares de algoritmos. A realidade é bem diferente. Eles desenvolveram um repertório de padrões e sabem identificar rapidamente qual deles se aplica a um problema.

O programador COBOL possui uma vantagem importante nessa jornada. Décadas trabalhando com arquivos sequenciais, VSAM, DB2, índices, tabelas OCCURS, processamento batch e transações CICS desenvolveram uma disciplina de raciocínio que continua extremamente valiosa. O desafio não é abandonar esse conhecimento, mas traduzi-lo para a linguagem moderna das Estruturas de Dados e Algoritmos.

Quando você perceber que um SEARCH ALL é uma busca binária, que uma tabela OCCURS é um array, que uma fila JES2 segue o princípio de uma queue, ou que um índice DB2 representa uma estrutura otimizada para acesso eficiente, verá que DSA não é um universo distante do Mainframe. É a formalização de conceitos que sempre estiveram presentes.

No fim das contas, programar bem nunca foi sobre decorar centenas de soluções. Sempre foi sobre observar, modelar e resolver problemas da forma mais elegante possível. É essa mentalidade que transforma um Padawan COBOL em um verdadeiro Arquiteto de Software, capaz de navegar tanto pelos sistemas legados que movem bancos e governos quanto pelas tecnologias modernas que definem o futuro da computação.


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...