Translate

terça-feira, 3 de maio de 2022

Genjitsu Shugi Yuusha no Oukoku Saikenki – Segunda Temporada Quando Reconstruir um Reino é Apenas o Primeiro Passo. Agora é Hora de Mantê-lo Funcionando.

 

Bellacosa Mainframe e a segunda temporada de genitsu shugi yuusga

☕ Um Café no Bellacosa Mainframe

Genjitsu Shugi Yuusha no Oukoku Saikenki – Segunda Temporada

Quando Reconstruir um Reino é Apenas o Primeiro Passo. Agora é Hora de Mantê-lo Funcionando.

"Construir um sistema é difícil. Mantê-lo disponível 24 horas por dia, durante décadas, é o verdadeiro desafio. A segunda temporada mostra exatamente essa diferença."


Ficha Técnica

ItemInformação
Título Original現実主義勇者の王国再建記 第二部 (Genjitsu Shugi Yuusha no Oukoku Saikenki Daini-bu)
Título InternacionalHow a Realist Hero Rebuilt the Kingdom – Part 2
Obra OriginalLight Novel de Dojyomaru
IlustraçõesFuyuyuki
EstúdioJ.C.Staff
DiretorTakashi Watanabe
ExibiçãoJaneiro a abril de 2022
Episódios13
Total da série26 episódios
DuraçãoAproximadamente 24 minutos por episódio
GêneroIsekai, Fantasia, Política, Administração, Romance, Estratégia, Aventura
Classificação Indicativa14 anos

Introdução

A primeira temporada mostrou como recuperar um reino em crise.

A segunda responde uma pergunta muito mais interessante:

Como manter um governo funcionando quando todos esperam resultados?

Agora Souma não é mais um administrador improvisado.

Ele é oficialmente o rei.

Isso muda tudo.

Os problemas deixam de ser internos.

Agora surgem conflitos internacionais, diplomacia, espionagem, alianças militares e equilíbrio econômico entre nações.

É exatamente a diferença entre implantar um novo sistema e administrar um ambiente IBM Z em produção.


Sinopse

Após estabilizar Elfrieden, Kazuya Souma precisa consolidar suas reformas enquanto enfrenta ameaças externas, negociações diplomáticas e disputas entre reinos. Ao mesmo tempo, fortalece alianças, amplia sua equipe e conduz mudanças capazes de transformar o equilíbrio político do continente.


Resumo

A segunda temporada amplia o mundo.

Enquanto a primeira era quase totalmente administrativa, esta passa a explorar:

  • relações internacionais;

  • economia continental;

  • inteligência militar;

  • sucessão política;

  • comércio;

  • casamentos diplomáticos;

  • alianças estratégicas;

  • expansão territorial.

O reino cresce.

E seus problemas também.


A História

Governar nunca foi apenas administrar dinheiro.

É administrar pessoas.

Na segunda temporada aparecem desafios como:

  • negociar sem demonstrar fraqueza;

  • evitar guerras desnecessárias;

  • proteger fronteiras;

  • integrar novos territórios;

  • administrar culturas diferentes;

  • preparar sucessores.

O foco deixa de ser "salvar um reino".

Agora é construir uma potência estável.


O Estúdio J.C.Staff

A J.C.Staff manteve a identidade da primeira temporada.

Não houve mudança significativa no estilo artístico.

O ritmo continua baseado em:

  • diálogos;

  • planejamento;

  • política;

  • desenvolvimento de personagens.

As batalhas continuam existindo.

Mas nunca são o centro da narrativa.


Os Personagens

Kazuya Souma

Evolui de administrador para estadista.

Aprende que liderar significa equilibrar interesses conflitantes.


Liscia Elfrieden

Assume papel muito mais ativo.

Participa das decisões de governo.

Mostra crescimento político.


Hakuya Kwonmin

Continua sendo o cérebro estratégico.

Praticamente um Primeiro-Ministro.

Sua capacidade analítica cresce ainda mais.


Aisha Udgard

Permanece como principal força militar.

Sua lealdade representa estabilidade institucional.


Juna Doma

Sua influência diplomática aumenta.

Atua em inteligência e comunicação.


Roroa Amidonia

Rouba diversas cenas.

Sua visão econômica demonstra que mercados podem ser tão importantes quanto exércitos.


Novos líderes e diplomatas

A segunda temporada amplia o elenco.

Cada governante representa um modelo diferente de liderança.


O Grande Diferencial

Na maioria dos isekais:

vencer o inimigo encerra a história.

Aqui...

É apenas o começo.

O foco está em:

  • consolidar instituições;

  • fortalecer economia;

  • administrar alianças;

  • evitar guerras;

  • desenvolver infraestrutura;

  • manter estabilidade.

É uma abordagem extremamente rara.


As Aventuras

Embora existam conflitos militares, o verdadeiro desafio acontece nas mesas de negociação.

Souma enfrenta:

  • conflitos diplomáticos;

  • casamentos políticos;

  • rebeliões;

  • anexações;

  • espionagem;

  • comércio internacional;

  • reformas administrativas;

  • planejamento militar.

Cada decisão produz consequências de longo prazo.


Temática

A segunda temporada trata principalmente de:

Governança

Não basta conquistar.

É preciso administrar.


Liderança

Grandes líderes desenvolvem novos líderes.


Economia

Dinheiro movimenta impérios.


Diplomacia

Uma guerra evitada vale mais que uma guerra vencida.


Planejamento

Toda decisão produz efeitos futuros.


Instituições

Pessoas passam.

As instituições permanecem.


As Mensagens Ocultas

1. Bons líderes formam sucessores

O protagonista distribui responsabilidades.

Não centraliza poder.


2. Especialistas fazem diferença

Cada ministro domina sua área.

Nenhum tenta saber tudo.


3. Informação reduz riscos

Espionagem.

Inteligência.

Análise.

Tudo baseado em dados.


4. Prosperidade reduz conflitos

Quanto melhor a economia...

Menor a necessidade de guerra.


5. Cooperação vence competição

Alianças duram mais do que conquistas militares.


6. A estabilidade é invisível

Quando tudo funciona...

Poucos percebem o esforço necessário.

Quem trabalha com sistemas críticos conhece bem essa realidade.


O Paralelo com IBM Mainframe

Na primeira temporada, Souma era como uma equipe assumindo um ambiente legado e iniciando um programa de modernização.

Na segunda temporada, ele se parece com um CIO responsável por uma plataforma IBM Z em plena produção.

Os desafios agora incluem:

  • alta disponibilidade;

  • continuidade do negócio;

  • integração entre sistemas;

  • governança;

  • segurança;

  • expansão controlada;

  • escalabilidade;

  • planejamento de capacidade.

Trocar tudo por algo "mais moderno" deixaria o reino vulnerável. Em vez disso, Souma fortalece processos, integra novos recursos e evolui gradualmente — exatamente como ocorre em programas bem-sucedidos de modernização de mainframe.


O Que Existe de Diferente?

Poucos animes dedicam tanto tempo às consequências das decisões.

Nesta temporada:

  • não existem soluções mágicas;

  • política importa;

  • economia importa;

  • logística importa;

  • diplomacia importa;

  • planejamento importa.

É um anime onde inteligência supera força bruta.


Impacto Cultural

A segunda parte consolidou a reputação da série como uma das principais referências do subgênero "kingdom building" ou "nation building", voltado à construção e administração de reinos. Embora tenha recebido críticas pelo ritmo mais lento e pelo grande volume de diálogos políticos, foi elogiada por mostrar liderança, economia e administração pública como elementos centrais da narrativa, algo incomum entre os isekais contemporâneos.


O Que Pode Ensinar para Profissionais de Tecnologia

Para quem trabalha com IBM Mainframe, DevOps ou arquitetura corporativa, a segunda temporada apresenta lições valiosas:

  • Modernização é contínua.

  • Governança evita o caos.

  • Especialistas são ativos estratégicos.

  • Documentação reduz riscos.

  • Processos são tão importantes quanto tecnologia.

  • Escalabilidade exige planejamento.

  • Disponibilidade nasce da disciplina operacional.

  • Liderança é coordenar talentos, não centralizar decisões.


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ (9,6/10)
Construção do Mundo⭐⭐⭐⭐⭐ (9,8/10)
Estratégia⭐⭐⭐⭐⭐ (10/10)
Política⭐⭐⭐⭐⭐ (10/10)
Economia⭐⭐⭐⭐⭐ (10/10)
Desenvolvimento dos Personagens⭐⭐⭐⭐☆ (9,0/10)
Ação⭐⭐⭐☆☆ (7,5/10)
Gestão e Liderança⭐⭐⭐⭐⭐ (10/10)
Reassistir⭐⭐⭐⭐⭐ (9,5/10)

Nota Final Bellacosa Mainframe: 9,6/10


Conclusão

Se a primeira temporada ensina como recuperar um sistema legado, a segunda mostra como operar uma plataforma crítica em escala nacional.

A maior batalha de Kazuya Souma não é contra monstros, mas contra a complexidade inerente à gestão de pessoas, instituições e recursos. É uma metáfora poderosa para qualquer profissional de tecnologia que já precisou manter um ambiente crítico funcionando sem interrupções.

No universo Bellacosa Mainframe, a mensagem é clara: construir é um projeto; sustentar é uma disciplina. Assim como no IBM Z, o verdadeiro sucesso não está em mudanças espetaculares, mas na capacidade de evoluir continuamente sem comprometer a estabilidade. É essa visão de longo prazo que faz de Genjitsu Shugi Yuusha no Oukoku Saikenki um dos isekais mais singulares e intelectualmente estimulantes da última década.


segunda-feira, 2 de maio de 2022

Auditoria de Software em Mainframe Muito Além do Código: Como Descobrir a Saúde de um Sistema que Movimenta Bancos, Seguradoras e Governos

 

Bellacosa Mainframe e a auditoria de software

☕ Um Café no Bellacosa Mainframe

Auditoria de Software em Mainframe

Muito Além do Código: Como Descobrir a Saúde de um Sistema que Movimenta Bancos, Seguradoras e Governos

"O bom desenvolvedor faz o programa funcionar. O excelente desenvolvedor faz o programa continuar funcionando durante décadas. A auditoria existe justamente para descobrir a diferença."


Introdução

Quando alguém ouve a palavra auditoria, normalmente imagina alguém procurando erros, apontando culpados ou produzindo relatórios intermináveis.

No universo do IBM Mainframe, a realidade é completamente diferente.

A auditoria de software é uma disciplina de engenharia.

Ela mede qualidade.

Mede risco.

Mede maturidade.

Mede sustentabilidade.

Principalmente, mede algo extremamente valioso:

a capacidade de um sistema continuar funcionando daqui a vinte anos.

Poucas plataformas do mundo possuem aplicações executando continuamente há 30, 40 ou até 60 anos.

Isso muda completamente a forma de avaliar software.

Enquanto no mundo web normalmente pergunta-se:

"Está funcionando?"

No IBM Z pergunta-se:

"Continuará funcionando depois das próximas mil mudanças?"

Essa pequena diferença muda toda a filosofia de auditoria.


A origem da auditoria de software

Curiosamente, a auditoria de software nasceu praticamente junto com os primeiros computadores comerciais.

Na década de 1960, grandes bancos perceberam um problema.

Era impossível validar manualmente milhões de transações.

Foi necessário criar processos para responder perguntas como:

  • Quem alterou este programa?

  • Quando?

  • Por quê?

  • Quem autorizou?

  • Existe documentação?

  • Existe teste?

  • Existe rollback?

Foi aí que nasceram conceitos que hoje chamamos de:

  • Governança

  • Compliance

  • Rastreabilidade

  • Gestão de Configuração

  • Segregação de Funções

Muito antes de DevOps existir.


Auditoria não procura bugs

Esse talvez seja o maior mito.

Uma auditoria séria quase nunca começa olhando código.

Ela começa olhando processos.

Porque processos ruins inevitavelmente geram software ruim.


O grande tripé

Toda auditoria madura observa três pilares.

Pessoas

Quem desenvolve?

Quem revisa?

Quem aprova?

Existe segregação?

Existe treinamento?

Existe documentação?


Processo

Como mudanças acontecem?

Existe fluxo formal?

Existe versionamento?

Existe rollback?

Existe aprovação?


Produto

Como está o software?

É complexo?

É duplicado?

É documentado?

É testado?

É sustentável?


O que normalmente é auditado

Uma auditoria completa pode analisar dezenas de aspectos.

Entre eles:

Código-fonte

  • COBOL

  • PL/I

  • Assembler

  • JCL

  • REXX

  • Easytrieve


Banco de Dados

  • DB2

  • IMS DB

  • VSAM


Processamento Batch

  • Dependências

  • Restart

  • Checkpoint

  • Performance


Online

  • CICS

  • IMS DC

  • MQ

  • APIs


Segurança

  • RACF

  • Permissões

  • Criptografia

  • Auditoria


Operação

  • JES2

  • WLM

  • RMF

  • SMF


Indicadores clássicos

Uma auditoria profissional mede indicadores.

Não opiniões.


1. Complexidade Ciclomática

Criada por Thomas McCabe em 1976.

Ela mede quantos caminhos independentes existem no programa.

Quanto maior o número...

Maior o risco.

Exemplo

IF

ELSE

END-IF

Possui baixa complexidade.

Agora imagine dezenas de:

IF

EVALUATE

PERFORM

GO TO

ALTER

A complexidade explode.


Valores típicos

Até 10 → Excelente

10–20 → Bom

20–40 → Atenção

Acima de 50 → Alto risco


2. Tamanho do Programa

Nem sempre maior significa pior.

Mas programas enormes costumam esconder problemas.

Exemplo

COBOL com

40.000 linhas

é muito diferente de

40 módulos com 1.000 linhas.


3. Acoplamento

Quanto um programa depende dos outros.

Alto acoplamento significa:

qualquer mudança provoca efeito dominó.


4. Coesão

Quanto um módulo faz apenas uma responsabilidade.

Alta coesão

é excelente.

Baixa coesão

indica "programa faz tudo".


5. Duplicação

Quanto código repetido existe.

Ferramentas modernas conseguem localizar blocos duplicados automaticamente.


6. Cobertura de Testes

Quantos caminhos realmente foram testados.

No Mainframe isso inclui:

Batch

Online

Abends

Rollback

Recovery

Restart


7. Taxa de Mudanças

Quantas alterações um programa recebe por ano.

Programas alterados constantemente merecem atenção especial.


8. Taxa de Defeitos

Quantos defeitos aparecem após produção.

Pode ser medida por:

1000 linhas

100 mudanças

Sprint

Release

Aplicação


9. Tempo Médio para Correção

MTTR

Quanto tempo demora para corrigir um incidente.


10. Disponibilidade

Quanto tempo o sistema permanece disponível.

No IBM Z frequentemente encontramos:

99,99%

99,999%

ou superior.


Rácios importantes

Uma auditoria raramente olha números isolados.

Ela cruza informações.


Defeitos por KLOC

Quantidade de defeitos

/

1000 linhas


Alterações por Programa

Mudanças

/

Quantidade de módulos


Incidentes por Release

Muito usado em bancos.


Percentual de Reprocessamentos

Quanto batch precisou ser executado novamente.


Percentual de Abends

Número de abends

/

Número total de Jobs


Percentual de Rollback

Importante para CICS.


Percentual de Mudanças Emergenciais

Mudanças urgentes

/

Mudanças totais

Quanto maior esse índice...

Menor costuma ser a maturidade.


Indicadores específicos de COBOL

Existem métricas interessantes.

Número médio de:

IF

EVALUATE

PERFORM THRU

GO TO

COPYBOOKS

DECLARATIVES

SQL EMBEDDED

CALL

Dynamic CALL

Static CALL


Indicadores de JCL

Quantidade média de:

STEP

COND

IF/THEN

RESTART

GDG

Temporary Dataset

SORT

IDCAMS

IEFBR14

Quanto maior a padronização...

Melhor.


Indicadores de DB2

Número de:

Tablespaces

Indexes

Packages

RUNSTATS vencidos

REORG pendentes

Locks

Deadlocks

Escalation

Access Path alterado


Indicadores CICS

Número médio de

Transações

Abends

Pseudo-Conversational

Syncpoint

Threadsafe

Storage Violations

Temporary Storage

Transient Data


Indicadores Operacionais

SMF

CPU

MSU

zIIP

Tempo Batch

Janela Batch

Fila JES

Espera em Dataset

Tempo em DB2

Tempo em MQ

Tempo em VSAM


O que um auditor experiente enxerga rapidamente

Ele procura padrões.

Por exemplo.

Programa de 60 mil linhas.

Pouquíssimos comentários.

Mais de 200 GO TO.

Sem testes.

Última documentação em 1998.

Esse programa funciona?

Provavelmente.

É saudável?

Talvez não.


As melhores práticas do mercado

1. Revisão por pares

Nenhum código importante deve entrar em produção sem revisão.


2. Versionamento

Hoje Git já faz parte do universo IBM Z.


3. Integração Contínua

Build automático.

Testes automáticos.

Deploy controlado.


4. Padronização

Naming.

Layout.

Comentários.

Copybooks.

Macros.


5. Código pequeno

Programas menores.

Mais simples.

Mais reutilizáveis.


6. Automatização

Quanto menos atividade manual...

Menor chance de erro.


7. Documentação viva

Nunca documente apenas uma vez.

Documentação envelhece.


8. Métricas contínuas

Não espere auditoria anual.

Métricas devem ser diárias.


Ferramentas frequentemente utilizadas

No ecossistema IBM Z encontramos soluções como:

  • IBM Application Discovery and Delivery Intelligence (ADDI)

  • IBM Developer for z/OS (IDz)

  • IBM Debug for z/OS

  • IBM File Manager

  • IBM Fault Analyzer

  • IBM Application Performance Analyzer

  • IBM z/OS Debugger

  • IBM Z IntelliMagic Vision

  • SonarQube (com plugins específicos para COBOL)

  • Micro Focus Enterprise Analyzer

  • BMC AMI DevX

  • Broadcom Endevor

  • IBM Engineering Workflow Management

Cada uma observa um aspecto diferente do ciclo de vida.


O que diferencia uma auditoria madura

Ela não gera apenas números.

Ela responde perguntas.

Como:

Onde está o maior risco?

Qual aplicação envelheceu?

Qual equipe produz menos defeitos?

Qual módulo merece refatoração?

Qual banco precisa reorganização?

Onde investir primeiro?


Um erro muito comum

Medir produtividade por linhas de código.

Isso é péssimo.

Um excelente desenvolvedor frequentemente reduz milhares de linhas.

Menos código.

Menos defeitos.

Menos manutenção.

Mais qualidade.


Outro erro clássico

Medir apenas velocidade.

Velocidade sem qualidade gera retrabalho.

Retrabalho custa caro.

Muito caro.


Curiosidade

Muitos bancos utilizam indicadores internos que jamais são divulgados.

Alguns acompanham centenas de métricas diariamente.

Não apenas software.

Também:

CPU

Storage

I/O

MSU

Licenciamento

Tempo de resposta

Custo por transação

Consumo energético

Capacidade futura


Easter Egg

Você sabia que um dos primeiros conceitos de métricas estruturadas para software surgiu antes mesmo da popularização da Engenharia de Software como disciplina?

Na década de 1970, organizações financeiras perceberam que um programa COBOL "que nunca dava problema" geralmente compartilhava características curiosas:

  • poucos desvios incondicionais (GO TO);

  • lógica de negócio bem dividida em parágrafos;

  • convenções de nomenclatura consistentes;

  • alterações pequenas e frequentes, em vez de grandes reescritas.

Décadas depois, muitos desses princípios foram formalizados em métricas de qualidade e continuam válidos até hoje.


Pontos de atenção

Nem toda dívida técnica aparece no código. Muitas vezes ela está na documentação ausente, nos processos informais ou na dependência de um único especialista.

Indicadores isolados enganam. Um programa grande pode ser excelente, enquanto um programa pequeno pode concentrar enorme risco. Sempre correlacione métricas.

Mudanças emergenciais recorrentes são um sinal de alerta. Se a exceção virou rotina, há problemas no planejamento, nos testes ou na governança.

Softwares críticos exigem histórico. Uma boa auditoria valoriza rastreabilidade: requisito, alteração, teste, aprovação e implantação devem formar uma cadeia verificável.

Ferramentas ajudam, mas não substituem experiência. Um relatório automatizado aponta sintomas; um auditor experiente identifica causas.


Como evoluir na carreira de Auditor de Software Mainframe

Se você deseja atuar nessa área, desenvolva competências em camadas:

Nível 1 — Fundamentos

  • COBOL

  • JCL

  • TSO/ISPF

  • SDSF

  • VSAM

  • DB2

  • CICS

Nível 2 — Operação

  • JES2

  • WLM

  • RMF

  • SMF

  • RACF

  • Catálogos

  • Performance

Nível 3 — Engenharia

  • Métricas de software

  • Refatoração

  • Arquitetura

  • Design de sistemas

  • Gestão de configuração

  • CI/CD para IBM Z

Nível 4 — Governança

  • ITIL

  • COBIT

  • ISO/IEC 25010 (qualidade de software)

  • ISO/IEC 12207 (ciclo de vida)

  • NIST Cybersecurity Framework

  • Auditoria baseada em risco

Nível 5 — Visão Estratégica

O diferencial dos grandes auditores não é conhecer todas as instruções do COBOL ou todos os parâmetros do JCL.

É conseguir responder perguntas como:

  • Onde estão os maiores riscos para o negócio?

  • Qual aplicação merece modernização primeiro?

  • Quanto custa manter esse sistema?

  • O risco de uma alteração é aceitável?

  • A arquitetura atual suporta o crescimento esperado?

Quando você conecta métricas técnicas aos objetivos do negócio, deixa de ser apenas um especialista em tecnologia e passa a atuar como um consultor estratégico.


Conclusão

A auditoria de software em Mainframe não é uma caça aos erros nem uma atividade burocrática. Ela é um processo contínuo de medição, análise e melhoria que transforma dados em decisões. Organizações que monitoram indicadores de qualidade, complexidade, desempenho, segurança e manutenção conseguem reduzir riscos, aumentar a estabilidade e prolongar a vida útil de aplicações que sustentam operações críticas há décadas.

No estilo Bellacosa Mainframe, vale lembrar uma última lição:

"Software não envelhece porque foi escrito em COBOL. Ele envelhece quando ninguém mais consegue entendê-lo, medi-lo ou evoluí-lo. A melhor auditoria não é a que encontra problemas; é a que cria um ambiente onde eles deixam de nascer."

Porque, no fim das contas, um sistema crítico não é aquele que nunca muda. É aquele que consegue mudar continuamente sem perder a confiança de milhões de usuários. Essa é a verdadeira medida de excelência em engenharia de software no IBM Z.

domingo, 1 de maio de 2022

De Go ao COBOL no IBM Z : Você Não Está Saindo da Programação Moderna. Está Descobrindo Onde Ela Aprendeu a Ser Confiável.

Bellacosa Mainframe do go ao cobol no zos

☕ Um Café no Bellacosa Mainframe

De Go ao COBOL no IBM Z

Você Não Está Saindo da Programação Moderna. Está Descobrindo Onde Ela Aprendeu a Ser Confiável.

"A velocidade impressiona. A estabilidade conquista. O IBM Z existe porque algumas aplicações simplesmente não podem parar."

Se você programa em Go (Golang), provavelmente já desenvolveu APIs REST, microsserviços, aplicações concorrentes, ferramentas de linha de comando, sistemas distribuídos ou soluções em nuvem.

Você conhece conceitos como:

  • goroutines

  • channels

  • interfaces

  • JSON

  • HTTP

  • testes automatizados

  • concorrência

  • Docker

  • Git

  • CI/CD

À primeira vista, aprender COBOL em IBM Z pode parecer um retorno aos anos 70.

Na realidade, acontece exatamente o contrário.

Você descobrirá uma plataforma que há décadas executa alguns dos sistemas mais críticos do planeta com níveis de disponibilidade, consistência e confiabilidade que poucas arquiteturas distribuídas conseguem igualar.

Não é trocar tecnologia.

É ampliar repertório.


A maior surpresa

Quem vem do universo Go normalmente acredita que COBOL seja apenas uma linguagem antiga.

Mas COBOL é apenas uma pequena parte do ecossistema.

Na prática você aprenderá uma arquitetura inteira composta por:

  • z/OS

  • JES2

  • TSO/ISPF

  • SDSF

  • JCL

  • VSAM

  • Db2

  • CICS

  • RACF

  • SMF

  • DFSMS

  • WLM

É parecido com alguém que conhece Go e pensa que Kubernetes é apenas um editor de YAML.

Não é.

Existe todo um ecossistema por trás.


Bellacosa Mainframe go versus cobol no zos

O que Go e COBOL têm em comum?

Muito mais do que parece.

Ambos valorizam simplicidade

Go ficou famoso por eliminar complexidade desnecessária.

COBOL nasceu com a mesma filosofia.

Um programa COBOL costuma ser extremamente legível.

Exemplo em Go

if saldo >= valor {
    saldo -= valor
}

COBOL

IF SALDO >= VALOR
    SUBTRACT VALOR FROM SALDO
END-IF

A sintaxe muda.

A lógica não.


Os dois gostam de código explícito

Go evita "mágicas".

COBOL também.

Você sempre sabe:

  • onde os dados estão

  • quem alterou

  • quando alterou

Essa previsibilidade explica por que bancos gostam tanto de COBOL.


Os dois valorizam estabilidade

Go prioriza compatibilidade.

IBM faz praticamente o mesmo.

Existe código COBOL escrito décadas atrás que continua compilando.

Poucas plataformas conseguem oferecer isso.


Ambos tratam processamento intensivo

Go costuma aparecer em:

  • gateways

  • APIs

  • proxies

  • observabilidade

  • streaming

COBOL aparece em:

  • compensação bancária

  • cartões

  • folha de pagamento

  • seguros

  • previdência

  • governo

Nos dois casos estamos falando de sistemas críticos.


Ambos processam grandes volumes

Go trabalha muito bem com milhares de conexões.

COBOL trabalha muito bem com bilhões de registros.

São desafios diferentes.

Mas ambos exigem eficiência.


Onde começam as diferenças?

Aqui começa a mudança de mentalidade.


Go nasceu na Internet

Go nasceu para:

  • cloud

  • containers

  • microsserviços

  • APIs

  • concorrência

O IBM Z nasceu décadas antes.

Seu foco sempre foi:

  • processamento massivo

  • consistência

  • segurança

  • disponibilidade

Isso muda completamente o modo de pensar.


Concorrência

Em Go você escreve:

go processar()

E cria uma goroutine.

No Mainframe a concorrência existe em outro nível.

Ela é administrada pelo sistema operacional.

Você aprenderá conceitos como:

  • Address Spaces

  • Dispatching

  • SRB

  • TCB

  • WLM

  • CICS Tasks

Ou seja:

menos código concorrente.

Mais gerenciamento sistêmico.


Persistência

Go normalmente conversa com:

  • PostgreSQL

  • MySQL

  • Redis

  • MongoDB

No Mainframe você encontrará:

  • Db2

  • VSAM

  • IMS

São tecnologias extremamente maduras.


Deploy

No Go:

go build

No IBM Z:

  • compilação

  • link-edit

  • geração de load module

  • execução via JCL

  • promoção entre ambientes

Existe um pipeline muito mais estruturado.


Arquitetura

Em Go:

API

Service

Repository

Banco

No Mainframe:

Tela CICS

Programa COBOL

Db2

VSAM

Mensageria

Batch

Relatórios

É outra arquitetura.


O que um programador Go já leva pronto?

Muito mais do que imagina.

Você já sabe:

Resolver problemas

Esta continua sendo a habilidade principal.


Estruturas de dados

Você entende:

  • registros

  • arrays

  • mapas

  • strings

COBOL apenas usa outra sintaxe.


Modularização

Você já separa responsabilidades.

COBOL também possui:

  • COPYBOOKS

  • SUBPROGRAMS

  • CALL


Testes

Go incentiva testes.

Hoje o Mainframe também.

Ferramentas modernas incluem:

  • zUnit

  • IBM Test Accelerator

  • COBOL Check


Git

Cada vez mais empresas utilizam:

  • GitHub

  • GitLab

  • Azure DevOps

inclusive para COBOL.


O que precisa aprender do zero?

Agora começa a verdadeira jornada.


1. COBOL

Primeiro aprenda apenas:

  • DATA DIVISION

  • PROCEDURE DIVISION

  • WORKING-STORAGE

  • PIC

  • MOVE

  • COMPUTE

  • IF

  • PERFORM

  • EVALUATE

  • FILE SECTION

Sem pressa.


2. Arquivos

Aprenda:

  • Sequential

  • VSAM KSDS

  • ESDS

  • RRDS

Entenda por que arquivos ainda são importantes.


3. JCL

Aqui muitos iniciantes desistem.

Não desista.

JCL é apenas uma forma de dizer ao z/OS:

"Execute este programa usando estes arquivos."

Pense nele como um YAML extremamente poderoso.


4. TSO/ISPF

Você aprenderá:

  • editar

  • copiar datasets

  • compilar

  • navegar

É seu novo ambiente de desenvolvimento.


5. SDSF

Imagine um painel onde você acompanha:

  • jobs

  • logs

  • spool

  • mensagens

É isso.


6. JES2

Depois descubra quem realmente executa tudo.

Esse é o papel do JES2.


7. Db2

Depois do COBOL, estude SQL embarcado.

Você verá:

EXEC SQL

END-EXEC

Não é muito diferente de usar database/sql em Go.


8. CICS

Aqui o Mainframe ganha vida.

Você aprenderá:

  • transações

  • telas

  • COMMAREA

  • CHANNEL

  • CONTAINER

É como desenvolver um servidor de aplicações extremamente otimizado.


9. RACF

Segurança.

Autorização.

Perfis.

Permissões.

O equivalente ao IAM do mundo IBM Z.


10. Monitoramento

Aprenda a ler:

  • mensagens

  • ABENDs

  • dumps

  • logs

Essa habilidade vale ouro.


O que deve praticar?

Não apenas estudar.

Praticar.

Muito.


Semana 1

Escrever pequenos programas COBOL.

Somar.

Subtrair.

Calcular médias.

Ler teclado.

Formatar saída.


Semana 2

Arquivos.

Criar.

Ler.

Atualizar.

Excluir.


Semana 3

JCL.

Executar programas.

Ler SYSOUT.

Entender retorno.


Semana 4

VSAM.

Inserções.

Pesquisa.

Atualizações.


Semana 5

Db2.

CRUD.

Cursores.

SQLCODE.


Semana 6

CICS.

Primeira tela.

Primeira transação.

Primeiro programa online.


Semana 7

Debug.

ABEND.

S0C7.

S806.

S222.

S322.

Aprenda a gostar deles.

Eles serão seus professores.


Semana 8

Projeto completo.

Cadastro.

Consulta.

Alteração.

Relatório Batch.

Tela CICS.

Db2.

JCL.

Git.

Você finalmente entenderá como um sistema corporativo funciona.


A mudança de mentalidade

Quem vem do Go normalmente pensa:

"Como faço isso rapidamente?"

No Mainframe a pergunta costuma ser:

"Como faço isso para funcionar pelos próximos vinte anos?"

Essa diferença muda tudo.


O que estudar paralelamente?

Enquanto aprende COBOL, mantenha seus conhecimentos modernos.

Estude:

  • REST

  • JSON

  • XML

  • APIs

  • OpenAPI

  • Git

  • GitHub

  • Zowe

  • VS Code

  • DevOps

  • Jenkins

  • GitHub Actions

  • Docker

  • Kubernetes

  • OpenShift

O profissional mais valorizado hoje é aquele que conecta esses dois mundos.


Um roteiro de seis meses

Mês 1: Lógica em COBOL, DATA DIVISION, arquivos sequenciais, TSO/ISPF.

Mês 2: JCL, utilitários, SORT, IDCAMS, VSAM, SDSF.

Mês 3: Db2 para z/OS, SQL embarcado, cursores, tratamento de erros.

Mês 4: CICS, transações, BMS, COMMAREA, canais e containers.

Mês 5: Arquitetura IBM Z, RACF, desempenho, debugging, análise de ABENDs, Git, Zowe e VS Code.

Mês 6: Modernização: APIs REST, z/OS Connect, integração com aplicações Go, mensageria (IBM MQ), testes automatizados e DevOps para Mainframe.

Ao final desse período, desenvolva um projeto integrando uma API escrita em Go com um programa COBOL em CICS consumido via z/OS Connect. Essa experiência mostrará, na prática, que linguagens modernas e Mainframe não competem: elas cooperam.


O maior erro de quem vem do Go

Querer comparar cada comando.

Não faça isso.

COBOL não tenta ser Go.

Go não tenta ser COBOL.

Cada um resolve problemas diferentes.

Aprenda primeiro a pensar como um desenvolvedor Mainframe.

Depois faça as comparações.

Você compreenderá muito mais.


A maior vantagem competitiva

Existem milhares de excelentes desenvolvedores Go.

Mas poucos dominam Go e IBM Z.

Esse profissional consegue conversar com equipes de cloud, APIs, microsserviços e, ao mesmo tempo, entender os sistemas responsáveis por bilhões de transações financeiras diárias.

É justamente essa combinação que muitas organizações procuram em projetos de modernização.


Um conselho do Bellacosa

Não entre no universo Mainframe tentando provar que a tecnologia moderna é melhor.

Entre querendo entender por que tantas instituições continuam confiando nela depois de mais de seis décadas.

Você encontrará soluções elegantes para problemas complexos, uma disciplina de engenharia admirável e uma cultura de qualidade construída ao longo de gerações.

Depois de aprender COBOL, você continuará sendo um programador Go.

Mas será um programador Go que entende sistemas críticos, processamento em larga escala, arquitetura corporativa e confiabilidade de missão crítica.

E essa combinação abre portas que poucos profissionais conseguem atravessar.

Porque, no fim das contas, aprender Mainframe não é voltar ao passado.

É descobrir como o futuro continua sendo construído sobre uma base extremamente sólida.

Nos vemos no próximo café.