Engenharia Militar : Capítulo IX — Inovação, Evolução e o Futuro: Quando a Engenharia Militar Encontra a Inteligência Artificial

Bellacosa Mainframe e a engenharia militar parte ix

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Capítulo IX — Inovação, Evolução e o Futuro: Quando a Engenharia Militar Encontra a Inteligência Artificial

Quando um Programador COBOL Descobre que o Futuro Nunca Substitui a Fortaleza... Apenas Constrói Novas Muralhas Sobre Alicerces Antigos

O castelo permanecia de pé havia mais de quatrocentos anos.

Suas muralhas resistiram a guerras.

Incêndios.

Terremotos.

Tempestades.

Mudanças de governo.

Mudanças de imperadores.

Mudanças de armas.

O jovem comandante observava os canhões recém-instalados.

Depois olhou para as antigas muralhas de pedra.

Perguntou ao velho engenheiro:

— Mestre...

se agora temos canhões...

por que ainda conservamos estas velhas muralhas?

O velho sorriu.

— Porque os canhões mudaram.

A guerra mudou.

Mas a Física continua sendo a mesma.

O silêncio tomou conta do pátio.

— Toda inovação inteligente respeita aquilo que continua verdadeiro.

Séculos depois...

09h42.

Uma reunião discutia Inteligência Artificial.

Cloud.

APIs.

Containers.

Quantum Computing.

Agentes Autônomos.

O recém-contratado comentou entusiasmado:

— O COBOL acabou.

O arquiteto veterano apenas perguntou:

— Quem processará o pagamento do salário da sua empresa amanhã às oito da manhã?

A sala ficou silenciosa.

Pegue seu café.

Hoje falaremos sobre inovação.

Mas não da inovação que destrói.

Da inovação que aprende primeiro por que algo sobreviveu durante sessenta anos.

---

1. O erro de confundir novidade com evolução

Existe uma armadilha comum.

Imaginar que tudo o que é novo automaticamente substitui o antigo.

A História demonstra exatamente o contrário.

A espada não desapareceu imediatamente com a pólvora.

O cavalo continuou sendo utilizado durante décadas.

Fortalezas continuaram existindo mesmo após o surgimento dos canhões.

Navios à vela coexistiram com navios a vapor.

A engenharia raramente evolui por substituição instantânea.

Ela evolui por integração.

---

2. O Castelo Aprende

Imagine um castelo construído em 1400.

Ao longo dos séculos ele recebe:

novos portões;

novas torres;

canhões;

depósitos;

observatórios;

sistemas hidráulicos.

Ele muda continuamente.

Mas permanece sendo o mesmo castelo.

O IBM Z evolui exatamente assim.

Cada geração incorpora:

novos processadores.

mais criptografia.

IA embarcada.

virtualização.

aceleradores.

novos compiladores COBOL.

integração com Linux.

OpenShift.

APIs.

Cloud.

Sem abandonar décadas de conhecimento acumulado.

---

3. O Maior Patrimônio Nunca Foi o Código

Quando observamos um sistema COBOL antigo costumamos enxergar milhões de linhas.

Na realidade...

essas linhas representam décadas de decisões de negócio.

Cada IF.

Cada EVALUATE.

Cada regra tributária.

Cada cálculo atuarial.

Cada validação.

É conhecimento empresarial transformado em software.

Reescrever tudo do zero significa correr o risco de esquecer parte desse conhecimento.

---

4. O Valor da Evolução Incremental

Na engenharia militar raramente se derruba um castelo inteiro para construir outro.

Reforça-se uma torre.

Amplia-se um depósito.

Melhora-se uma muralha.

Substitui-se um portão.

Na arquitetura de software chamamos isso de evolução incremental.

Pequenas melhorias constantes costumam produzir resultados mais seguros do que grandes revoluções.

---

5. A Inteligência Artificial Como Conselheira

Existe muito entusiasmo em torno da IA.

E com razão.

Ela pode:

analisar documentação;

explicar código COBOL;

identificar padrões;

sugerir testes;

propor refatorações;

traduzir regras de negócio;

gerar documentação inicial.

Mas existe uma diferença importante.

Ela auxilia.

Quem responde pela decisão continua sendo o engenheiro.

Assim como um excelente mapa não substitui o comandante.

---

6. O Perigo da Automação Sem Compreensão

Imagine uma enorme catapulta automática.

Ela dispara perfeitamente.

Mas ninguém verifica para onde está apontando.

Automação sem entendimento apenas acelera erros.

Em tecnologia isso ocorre quando:

scripts são executados sem revisão;

deploys são aprovados automaticamente;

agentes recebem permissões excessivas;

decisões críticas deixam de ser auditadas.

Velocidade nunca deve substituir responsabilidade.

---

7. APIs — As Novas Estradas do Reino

Nos capítulos anteriores falamos sobre estradas romanas e rotas de suprimentos.

Hoje essas estradas também são digitais.

As APIs conectam:

mainframe;

mobile;

cloud;

ERP;

portais;

Inteligência Artificial;

microsserviços.

Elas permitem que sistemas escritos em épocas diferentes trabalhem juntos.

Não substituem o castelo.

Constroem novas estradas até ele.

---

8. O COBOL Conversa com o Mundo

Durante muitos anos existiu um mito.

"O mainframe é isolado."

Na realidade moderna encontramos:

REST.

JSON.

MQ.

Kafka.

gRPC.

OpenAPI.

z/OS Connect.

OpenShift.

Linux on IBM Z.

Python.

Java.

Node.js.

Todos convivendo com COBOL.

A fortaleza abriu novos portões.

Mas continua protegendo o tesouro.

---

9. A Engenharia da Confiança

Imagine um banco.

Você deposita dinheiro hoje.

Volta daqui a vinte anos.

Espera encontrá-lo corretamente registrado.

Essa confiança não nasce da moda tecnológica.

Nasce da engenharia.

Por isso sistemas críticos valorizam tanto:

consistência;

auditabilidade;

integridade;

rastreabilidade;

continuidade.

Esses princípios continuarão importantes mesmo daqui a cinquenta anos.

---

10. Computação Quântica

Muito se fala sobre computadores quânticos.

Eles representam uma enorme oportunidade.

Mas também enormes desafios.

Especialmente para criptografia.

Assim como a pólvora obrigou castelos a evoluírem...

novas tecnologias obrigarão arquiteturas digitais a evoluírem.

A resposta continuará sendo engenharia.

Não pânico.

---

11. Observabilidade — As Torres do Século XXI

Antigamente existiam vigias observando o horizonte.

Hoje observamos:

logs.

métricas.

traces.

eventos.

telemetria.

painéis.

alertas.

A observabilidade moderna funciona como milhares de sentinelas distribuídos por toda a fortaleza.

Quanto mais cedo percebemos mudanças...

mais cedo reagimos.

---

12. Zero Trust Continua Atual

Mesmo utilizando IA.

Cloud.

Containers.

Quantum.

O princípio permanece.

Nunca confiar automaticamente.

Verificar sempre.

A tecnologia muda.

Os fundamentos permanecem.

---

13. O Futuro do Profissional COBOL

Existe uma pergunta recorrente.

"O que devo estudar?"

A resposta mudou.

Não basta conhecer apenas COBOL.

Também é importante compreender:

APIs.

Segurança.

DevOps.

Git.

Cloud.

Automação.

Containers.

Observabilidade.

IA.

Mas sem abandonar os fundamentos.

A árvore cresce.

Porque suas raízes permanecem fortes.

---

14. Goblin Slayer e a Evolução

Ao longo da obra, Goblin Slayer melhora seus equipamentos.

Aprende novas estratégias.

Utiliza novas ferramentas.

Mas nunca abandona aquilo que funciona.

Ele evolui sem perder sua essência.

Essa talvez seja uma excelente definição para qualquer engenheiro.

Aprender continuamente.

Sem esquecer por que chegou até aqui.

---

15. Shogun e o Choque Tecnológico

Em Shogun, o contato entre culturas apresenta novas armas, novas embarcações, novos conhecimentos e novas formas de organização.

Os líderes que prosperam não são os que rejeitam toda novidade.

Nem os que abandonam imediatamente suas tradições.

São aqueles que sabem combinar inovação e experiência.

Essa mesma postura explica por que tantas organizações modernizam seus sistemas IBM Z em vez de simplesmente descartá-los.

---

16. A IA Não Elimina Engenheiros

Existe outro mito.

"A Inteligência Artificial substituirá todos."

Historicamente, grandes inovações modificam profissões, automatizam tarefas repetitivas e criam novas especializações.

Engenharia, arquitetura, pensamento crítico, ética, validação, responsabilidade e compreensão do negócio continuam sendo atividades essencialmente humanas.

A IA amplia capacidades.

Não elimina a necessidade de profissionais preparados.

---

17. Curiosidade Histórica

Ao longo da História, fortalezas bem-sucedidas foram aquelas que souberam incorporar novas tecnologias sem abandonar seus princípios estruturais. Castelos passaram a utilizar canhões, novas técnicas de construção, sistemas hidráulicos mais eficientes e melhores formas de comunicação, mantendo, porém, a lógica de defesa em profundidade, abastecimento, observação e comando.

Os ambientes IBM Z seguiram trajetória semelhante. Processadores mais rápidos, criptografia por hardware, virtualização, integração com Linux, APIs, contêineres e Inteligência Artificial foram incorporados preservando compatibilidade, disponibilidade e confiabilidade, características que continuam sustentando aplicações críticas em diversos setores.

---

18. Easter Egg — O Programa Mais Moderno do Banco

Conta-se que uma equipe resolveu identificar o software "mais moderno" da empresa.

Todos imaginavam encontrar um microsserviço recém-criado.

Uma API.

Um agente de IA.

Depois de semanas de investigação descobriram algo curioso.

O componente mais acessado de toda a arquitetura era um programa COBOL escrito décadas antes.

Mas ele havia recebido centenas de pequenas melhorias ao longo dos anos.

No cabeçalho existia uma anotação feita por dezenas de desenvolvedores.

A última dizia:

Não somos antigos.

Somos continuamente atualizados.

O arquiteto sorriu.

A inovação verdadeira não depende da data de nascimento.

Depende da capacidade de continuar evoluindo.

---

19. Checklist do Engenheiro do Futuro

Antes de afirmar que um sistema está preparado para os próximos anos, pergunte:

✔ Os fundamentos continuam sólidos?

✔ O conhecimento do negócio está documentado?

✔ As integrações utilizam padrões abertos quando apropriado?

✔ Existe observabilidade adequada?

✔ A segurança acompanha a evolução tecnológica?

✔ As equipes estudam continuamente?

✔ A IA é utilizada com supervisão humana?

✔ Há automação responsável?

✔ Os sistemas antigos conversam com os novos?

✔ Existe estratégia de modernização incremental?

✔ As decisões permanecem auditáveis?

✔ O foco continua sendo entregar valor ao negócio?

---

Conclusão — A Fortaleza do Amanhã

O jovem comandante caminhava pela muralha recém-ampliada.

Agora havia telescópios.

Canhões.

Novos depósitos.

Pontes reforçadas.

Mensageiros mais rápidos.

Nada daquilo existia quando o castelo fora construído.

Mesmo assim...

a fortaleza permanecia reconhecível.

O velho engenheiro aproximou-se.

— O que aprendeu?

O rapaz respondeu olhando para o horizonte.

— Achei que modernizar significasse substituir tudo.

Hoje compreendo que significa preservar aquilo que merece continuar existindo e melhorar aquilo que pode evoluir.

O mestre sorriu.

— Agora você pensa como um engenheiro.

Na sala de arquitetura, o jovem programador observava um ambiente onde COBOL, APIs, Linux, OpenShift, IA e serviços em nuvem trabalhavam juntos.

Nenhuma tecnologia tentava apagar a outra.

Cada uma resolvia o problema para o qual havia sido concebida.

Naquele momento ele compreendeu a maior lição de toda a jornada.

A engenharia nunca foi uma disputa entre passado e futuro.

Sempre foi uma conversa entre experiência e inovação.

Os maiores castelos da História não sobreviveram porque permaneceram imutáveis.

Sobreviveram porque souberam mudar sem destruir seus alicerces.

Da mesma forma, os grandes sistemas IBM Z continuarão relevantes enquanto houver engenheiros capazes de unir tradição, conhecimento de negócio, disciplina operacional e novas tecnologias.

Porque, no fim, a missão continua exatamente a mesma desde o primeiro capítulo desta jornada:

proteger aquilo que é essencial.

Garantir que a operação nunca pare.

E construir, geração após geração, uma fortaleza cada vez mais inteligente, resiliente e preparada para o futuro.

A tecnologia continuará mudando.

Os princípios da boa engenharia... esses permanecerão.

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Ordem de operações

1. Reconhecer o ambiente
2. Mapear as dependências
3. Proteger os recursos
4. Planejar a contingência
5. Garantir a continuidade

A vitória pertence a quem mantém o sistema funcionando.

Arquivo estratégico

Um Data Center analisado como uma fortaleza em guerra

A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.

Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.

Sala de operações

Índice da campanha

25 documentos localizados

Pesquisar no arquivo Categoria Todos os documentos Abertura Capítulos Referências Animes Especiais Ordenação Ordem da campanha Mais recentes primeiro Ordem alfabética

Índice permanente

Links completos da série Engenharia Militar

Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.

1. Engenharia Militar sem Mistérios para Programadores COBOL
2. Prólogo — O Chamado do Guardião
3. Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
4. Capítulo II — Estratégia, Operação e Tática
5. Capítulo III — A Cadeia de Comando
6. Capítulo IV — Logística
7. Capítulo V — As Muralhas Invisíveis
8. Capítulo VI — Inteligência, Reconhecimento e Espionagem
9. Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
10. Capítulo VIII — Liderança, Moral e Disciplina
11. Capítulo IX — Inovação, Evolução e o Futuro
12. Capítulo X — O Legado do Engenheiro
13. Capítulo XI — O Guardião Invisível
14. Capítulo XII — A Fortaleza Invisível
15. Capítulo XIII — Os Sentinelas da Madrugada
16. Capítulo XIV — A Civilização Invisível
17. Capítulo XV — Engenharia de Cerco
18. Glossário IBM Z + Engenharia Militar
19. Apêndice A — Correspondências Históricas e Técnicas
20. Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
21. Os 10 Animes Mais Emblemáticos Sobre Logística Militar
22. Os 10 Animes Mais Emblemáticos Sobre Tática Militar
23. Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
24. Especial — Guerrilha Urbana
25. Especial — Guerrilha no Campo e na Floresta

★

Bellacosa Mainframe — Arquivo de Engenharia Militar

Estratégia, disciplina, conhecimento, resiliência e continuidade aplicados aos sistemas que não podem parar.

📼 El Jefe Midnight Lunch — Release 1970: ABEND Susto RC=911 🔥💾

 

📼 El Jefe Midnight Lunch — Release 1970: ABEND Susto RC=911 🔥💾
Logs de um sobrevivente do botijão 13kg – Versão Bellacosa Mainframe

---

Ainda estamos nos anos 1970.
Uma década granulada, cor sépia Kodak, som de Chacrinha ecoando longe e cheiro de Kibon Chicabon derretendo no papel. Eu, pequeno Bellacosa, arquivo vivo em fita magnética, presente naquele sábado na casa de Douglas e sua esposa — amigos dos meus pais, gente boa, riso largo, casa cheia do tipo JES2 lotado em horário de pico.

Homens na mesa com cerveja gelada, mulheres no CICS da cozinha montando o jantar — transação constante, sem timeout.
E nós, as crianças, orbitando como tape drives inquietos, buscando petiscos, travessuras e qualquer oportunidade de rodar um job proibido.

Nada muito incomum.
Seria só mais um encontro normal, desses que o storage da memória arquiva e depois descarta por falta de espaço.

Mas aí aconteceu o evento PQP – Panic Queue Protocol.
E este sim ficou gravado com retenção permanente em HD emocional.

---

No auge do preparo da janta, o gás do botijão acabou.
Douglas — root user da residência — foi trocar o cilindro. Só que anos 1970 eram um sistema operacional sem patch de segurança, sem ITIL, sem NR nenhuma. Era plug and pray.

E no swap do botijão, a válvula de contenção falhou.

De repente:
gás pressurizado jorrando como um dump em tela verde.
Gritos. Correria. Jobs cancelados. Checkpoints ignorados.
O ambiente virou um SDSF com ABEND em massa.

Meu pai, por instinto, agarrou Vivi e correu para o quintal.
Minha mãe, movida pelo mesmo desespero mas outro raciocínio, me puxou e correu para dentro da casa. Sim, para dentro.

E aqui entra o detalhe arquitetônico brasileiro:
Casa brasileira é máquina de segurança física nível RACF ultra restritivo.
Grades, fechaduras, ferrolhos, trancas.
Tudo pensado para impedir entrada — e sem rollback para saída.

Minha mãe me levou, na melhor das intenções, para uma armadilha perfeita.
Se o gás acendesse… nós dois viraríamos job zombie, sem saída, presos atrás de barras de aço. Um "halt and catch fire" literal.

Mas como você percebe — console ainda online, sessão ativa — o pior não aconteceu.
O botijão era pequeno, 13kg, liberou o inferno por uns 10 minutos, talvez menos, talvez mais — criança conta tempo como CPU sem relógio.
Quando a pressão diminuiu e o risco passou, meu pai entrou, nos resgatou do quarto como herói com override de segurança.

E como era 1970 —
não teve psicólogo, não teve auditoria de segurança, não teve SMS de incidente crítico.

Pegaram outro botijão. Continuaram a cozinhar.
E no final, jantamos todos juntos, rindo, reconstruindo o dump daquele quase-desastre.
Uma história que quase se perdeu no spool da vida, se não fosse pelo evento P-Q-P estampado na memória ROM da infância.

E cá estou.
Bit sobrevivente, bloco íntegro, registro ativo.

Vivo para contar.
E jantar outra vez.

🔥🐇💾
Bellacosa — log registrado, commit efetuado, RC=0 (por milímetros).

Shimoneta (下ネタという概念が存在しない退屈な世界)

 

Bellacosa Mainframe apresenta shimoneta

☕ Um Café no Bellacosa Mainframe

Shimoneta (下ネタという概念が存在しない退屈な世界)

Quando um Programador COBOL Descobre que um Sistema Pode Ser Tão Seguro que Elimina a Própria Liberdade

"A maior ameaça a um sistema não é a liberdade. É acreditar que apenas uma forma de pensar pode existir."

---

Ficha Técnica

Item	Informação
Título original	下ネタという概念が存在しない退屈な世界
Título internacional	SHIMONETA: A Boring World Where the Concept of Dirty Jokes Doesn't Exist
Abreviação	Shimoseka
Autor	Hirotaka Akagi
Ilustrações	Eito Shimotsuki
Origem	Light Novel
Estúdio	J.C.Staff
Diretor	Yōhei Suzuki
Roteiro	Masahiro Yokotani
Música	Akiyuki Tateyama
Exibição	4 de julho a 19 de setembro de 2015
Episódios	12
Duração	aproximadamente 24 minutos
Classificação	+16 (varia conforme o país)
Gênero	Comédia, Ecchi, Escolar, Ficção Científica, Sátira, Distopia

---

Sinopse

Imagine um Japão onde qualquer palavra considerada obscena seja proibida por lei.

Não existem piadas de duplo sentido.

Não existe educação sexual.

Não existe pornografia.

Não existe sequer vocabulário para falar naturalmente sobre o corpo humano.

Todos os cidadãos utilizam um dispositivo eletrônico preso ao pescoço que monitora constantemente sua linguagem e comportamento.

É nesse mundo artificialmente "puro" que vive Tanukichi Okuma.

Sua vida muda quando conhece Ayame Kajou, líder secreta da organização terrorista SOX, cuja missão é devolver às pessoas aquilo que lhes foi roubado:

a liberdade de expressão.

---

Resumo da História

O governo japonês criou um sistema de controle moral absoluto.

Tudo que possa ser considerado obsceno desapareceu da sociedade.

As novas gerações sequer compreendem conceitos básicos sobre sexualidade.

Enquanto todos aceitam essa realidade como perfeita, Ayame Kajou inicia uma verdadeira guerra cultural.

Utilizando humor, provocações e ações de guerrilha, ela tenta mostrar que esconder um problema não significa resolvê-lo.

Tanukichi acaba sendo arrastado para essa revolução completamente maluca.

O resultado é uma sucessão de episódios absurdos, hilários e surpreendentemente inteligentes.

---

O Estúdio J.C.Staff

O J.C.Staff é um dos estúdios mais tradicionais do Japão.

Também produziu:

• Toradora!

• Food Wars!

• One Punch Man (2ª temporada)

• The Familiar of Zero

• DanMachi

• Railgun

• Index

A animação de Shimoneta não impressiona pelo orçamento.

O destaque está na direção de humor.

Expressões exageradas.

Timing perfeito.

Cortes rápidos.

Dublagem extremamente energética.

Grande parte da graça nasce justamente da atuação dos personagens.

---

Personagens

Tanukichi Okuma

O protagonista.

Filho de um famoso "terrorista moral", tenta levar uma vida comum.

É o elo entre o público e o caos criado por Ayame.

---

Ayame Kajou (Blue Snow)

A presidente do conselho estudantil.

Na verdade, é a líder revolucionária da organização SOX.

Carismática.

Corajosa.

Brilhante.

É uma das personagens mais memoráveis da década de 2010.

---

Anna Nishikinomiya

A garota perfeita.

Educada.

Gentil.

Símbolo da moralidade.

Porém, ao descobrir emoções reprimidas, transforma-se em uma das figuras mais imprevisíveis do anime.

---

Kosuri Onigashira

A cientista da equipe.

Constrói equipamentos completamente absurdos.

É responsável por boa parte das situações mais caóticas.

---

Otome Saotome

Representa a autoridade.

É a personificação do Estado controlador.

---

Temática

Apesar da aparência de simples ecchi, Shimoneta aborda temas surpreendentemente profundos:

• censura;

• autoritarismo;

• liberdade individual;

• controle estatal;

• manipulação social;

• educação;

• ignorância programada;

• moralidade artificial;

• propaganda;

• pensamento crítico.

---

O que tem de diferente?

É aqui que Shimoneta se destaca.

Enquanto outros animes ecchi utilizam fanservice como objetivo principal...

Shimoneta utiliza o ecchi como instrumento de crítica social.

O humor exagerado serve para ridicularizar regimes extremamente controladores.

Não é um anime sobre vulgaridade.

É um anime sobre o perigo da censura absoluta.

---

As Aventuras

Cada episódio apresenta uma nova missão da SOX.

Entre elas:

• infiltrações na escola;

• sabotagens contra órgãos de censura;

• distribuição clandestina de material proibido;

• enfrentamentos contra agentes da moralidade;

• invenções completamente malucas;

• perseguições;

• estratégias de guerrilha.

Tudo sempre exagerado de propósito.

O absurdo faz parte da sátira.

---

As Mensagens Ocultas

1. Censura nunca resolve um problema

Proibir palavras não elimina pensamentos.

Da mesma forma que apagar mensagens de erro não elimina bugs.

---

2. Informação é poder

Uma população sem conhecimento torna-se fácil de controlar.

Exatamente como usuários que dependem apenas de interfaces e nunca entendem o sistema.

---

3. O excesso de regras cria sistemas frágeis

Quanto mais exceções surgem...

Mais difícil fica manter a ordem.

É exatamente o problema de muitos sistemas legados.

---

4. Educação é melhor que proibição

O anime mostra que esconder assuntos importantes apenas aumenta a curiosidade e a desinformação.

---

5. Fanatismo existe dos dois lados

Embora critique o governo, Shimoneta também satiriza o extremismo revolucionário.

Ninguém escapa do humor.

---

Bellacosa Mainframe

Para um programador COBOL, Shimoneta lembra um ambiente corporativo onde a governança foi levada ao extremo.

Imagine um ambiente em que:

• nenhuma alteração pode ser feita;

• nenhum comando pode ser executado;

• nenhum log pode ser consultado;

• nenhum usuário pode aprender além do manual;

• qualquer tentativa de inovação gera punição.

Resultado?

O sistema continua funcionando...

Mas ninguém entende mais como ele funciona.

É exatamente isso que acontece com a sociedade do anime.

Ela continua operacional.

Porém perde sua capacidade de evoluir.

---

Curiosidades

• "Shimoseka" é a abreviação oficial usada no Japão.

• A abertura B-Chiku Sentai SOX tornou-se uma das mais marcantes do gênero.

• O anime ficou conhecido pela criatividade dos diálogos e da dublagem.

• A adaptação cobre apenas parte da história das light novels, que possuem 11 volumes principais e um volume extra. (Wikipédia)

---

Impacto Cultural

Shimoneta dividiu opiniões desde o lançamento.

Para alguns, era apenas um anime ecchi.

Para outros, uma das sátiras mais inteligentes da década.

Com o passar dos anos, tornou-se uma obra cult entre fãs de comédia absurda e frequentemente é citado em discussões sobre censura, liberdade de expressão e humor. Cenas de Ayame Kajou e Anna Nishikinomiya também renderam inúmeros memes e GIFs compartilhados pela comunidade de anime. (Reddit)

---

Classificação Bellacosa Mainframe

Categoria	Nota
História	⭐⭐⭐⭐⭐
Humor	⭐⭐⭐⭐⭐
Originalidade	⭐⭐⭐⭐⭐
Personagens	⭐⭐⭐⭐⭐
Ecchi	⭐⭐⭐⭐⭐
Fanservice	⭐⭐⭐⭐☆
Ação	⭐⭐⭐☆☆
Reflexão filosófica	⭐⭐⭐⭐⭐

---

Conclusão

À primeira vista, Shimoneta parece apenas uma comédia ecchi repleta de exageros. No entanto, por trás do humor está uma crítica consistente aos perigos do controle absoluto da informação e da moralidade.

No universo Bellacosa Mainframe, a maior lição é clara: um sistema precisa de regras, mas regras sem espaço para questionamento transformam tecnologia em burocracia e sociedades em ambientes estagnados. Assim como um bom sistema legado sobrevive porque evolui com responsabilidade, uma sociedade saudável depende do equilíbrio entre ordem, conhecimento e liberdade. É essa combinação de irreverência, sátira e reflexão que faz de Shimoneta uma obra singular dentro do gênero.

 

Bellacosa Mainframe coloque a prova seu conhecimento em REXX

🚀 🧪 LAB 1 — REXX + SDSF (MONITORAMENTO DE JOBS)

🎯 Objetivo

Listar jobs ativos e analisar status

---

💻 Código

/* REXX */
address sdsf

"ISFEXEC ST"

if rc <> 0 then do
   say "Erro ao acessar SDSF"
   exit
end

do i = 1 to isfrows
   say isfjobname.i isfowner.i isfstatus.i
end

---

🧠 Explicação

• address sdsf → muda ambiente
• ISFEXEC ST → consulta status de jobs
• isfrows → quantidade de jobs

---

💣 Insight

👉 Você acabou de acessar o spool do sistema
👉 Isso é praticamente um mini-monitor de produção

---

🚀 🧪 LAB 2 — FILTRANDO JOBS (PRODUÇÃO REAL)

🎯 Objetivo

Mostrar apenas jobs ativos do seu usuário

---

/* REXX */
address sdsf
"ISFEXEC ST"

do i = 1 to isfrows
   if isfowner.i = userid() then
      say isfjobname.i isfstatus.i
end

---

💣 Insight

👉 Isso é base para:

• dashboards
• monitoramento automático
• alertas

---

🚀 🧪 LAB 3 — CANCELAR JOB (OPERAÇÃO REAL)

⚠️ cuidado: ambiente permite ou não dependendo do RACF

/* REXX */
address sdsf
"ISFEXEC ST"

do i = 1 to isfrows
   if isfjobname.i = "JOBTEST" then do
      "CANCEL " isfjobid.i
      say "Job cancelado:" isfjobid.i
   end
end

---

💣 Insight

👉 Isso é poder de operador
👉 Em produção → altamente controlado

---

🚀 🧪 LAB 4 — LER OUTPUT DE JOB (LOG ANALYSIS)

/* REXX */
address sdsf
"ISFEXEC ST"

do i = 1 to isfrows
   if isfjobname.i = "JOBTEST" then do
      "ISFACT ST TOKEN('"isftoken.i"') PARM(NP SA)"
   end
end

---

🧠 Explicação

👉 você está acessando spool
👉 lendo logs de execução

---

💣 Uso real

• detectar abend
• analisar erro batch
• auditoria

---

🚀 🧪 LAB 5 — JES2 COMMAND (OPERAÇÃO SISTEMA)

/* REXX */
address tso
"STATUS"

ou

address tso
"$D JOBQ"

---

💣 Insight

👉 $D JOBQ = comando JES2
👉 lista fila de jobs

---

🚀 🧪 LAB 6 — RACF CHECK (SEGURANÇA)

/* REXX */
address tso
"LU " userid()

---

🧠 Explicação

• mostra info do usuário
• grupos
• permissões básicas

---

🚀 🧪 LAB 7 — VALIDAR ACESSO

/* REXX */
parse arg dsname

address tso
"LISTDS '"dsname"'"

if rc = 0 then
   say "Acesso OK"
else
   say "Sem acesso"

---

💣 Insight

👉 simula controle de segurança
👉 útil para auditoria

---

🚀 🧪 LAB 8 — MONITOR DE ERRO AUTOMÁTICO

/* REXX */
address sdsf
"ISFEXEC ST"

do i = 1 to isfrows
   if isfstatus.i = "OUTPUT" then do
      if pos("ABEND", isfjobname.i) > 0 then
         say "Possível erro:" isfjobname.i
   end
end

---

🚀 🧠 VISÃO NÍVEL BELLACOSA

Esses labs parecem simples…

👉 mas representam o que acontece em produção:

---

🔥 1. SDSF = Observabilidade

• monitora jobs
• lê logs
• controla execução

---

🔥 2. JES2 = Orquestrador

• fila de jobs
• execução batch
• scheduling

---

🔥 3. RACF = Segurança

• autenticação
• autorização
• auditoria

---

💣 TRADUÇÃO BRUTAL

Tecnologia	Papel
SDSF	observabilidade
JES2	engine batch
RACF	segurança

---

🚀 🧪 DESAFIO (NÍVEL AVANÇADO)

Crie um script que:

👉 lista jobs
👉 identifica erro
👉 grava relatório em dataset

Como Programar sem Violar a Fortaleza do z/OS ☕🔐

 

Bellacosa Mainframe comenta sobre os risco e perigos e elogia o guardião RACF

🔥 Manual de Segurança RACF para Desenvolvedores

Como Programar sem Violar a Fortaleza do z/OS ☕🔐

No Mainframe, segurança não é um módulo.
É uma camada estrutural invisível que permeia tudo.

E no coração dessa segurança está o RACF (Resource Access Control Facility).

Para o desenvolvedor, RACF pode parecer apenas “aquele erro de autorização”.
Na realidade, ele é o guardião de:

🏦 dados bancários
🪪 informações pessoais
📊 bases governamentais
🧾 registros legais
💰 trilhões em transações

Entender RACF não é opcional — é requisito profissional.

---

🧠 1) Você não “bypass” RACF — você trabalha com ele

Não existe atalho legítimo.

Se o acesso foi negado, é porque:

👉 Você não precisa dele
👉 Falta autorização formal
👉 O recurso é sensível
👉 Há segregação de funções

Profissionais maduros não pedem acesso amplo — pedem acesso correto.

---

🔒 2) Princípio do Menor Privilégio

Regra fundamental:

Tenha apenas o acesso necessário para sua função.

Isso reduz:

✔ Risco de erro humano
✔ Possibilidade de abuso
✔ Impacto de incidentes
✔ Superfície de ataque

Se você tem acesso demais, algo está errado.

---

📁 3) Dataset é recurso protegido

Cada dataset pode ter regras específicas.

Níveis comuns de acesso:

• READ — leitura

• UPDATE — alteração

• CONTROL — manipulação avançada

• ALTER — controle total

Nunca assuma que READ permite processamento completo.

---

🏦 4) Bibliotecas de produção são zonas críticas

Load libraries e datasets de produção são altamente protegidos.

Desenvolvedores normalmente:

❌ Não podem alterar diretamente
✔ Devem promover via processos formais
✔ Passam por change management
✔ São auditados

Isso garante integridade operacional.

---

🧾 5) Logs existem — e são analisados

Cada tentativa de acesso pode ser registrada.

Auditores conseguem ver:

📅 Quem acessou
🕒 Quando acessou
📦 Qual recurso
❌ Tentativas negadas
⚠ Padrões suspeitos

Transparência é total.

---

🧠 6) IDs pessoais são responsabilidade individual

Nunca compartilhe sua credencial.

Seu ID representa você legal e operacionalmente.

Tudo feito com ele é atribuído a você.

---

🛑 7) Hardcode de credenciais é proibido

Código não deve conter:

❌ Senhas
❌ IDs de usuário
❌ Tokens
❌ Dados sensíveis

Além de inseguro, viola normas de auditoria.

---

🔐 8) RACF também protege programas

Não apenas dados.

Pode controlar execução de:

• Programas autorizados

• Transações CICS

• Comandos do sistema

• Recursos UNIX

• Serviços especiais

Isso evita uso indevido de funções críticas.

---

🔁 9) Ambientes são segregados

Desenvolvimento, teste e produção possuem regras diferentes.

Mover código entre ambientes requer:

✔ Aprovação formal
✔ Procedimentos controlados
✔ Registro da mudança

Acesso direto à produção é raro e justificado.

---

📊 10) Segurança influencia o design do software

Aplicações devem considerar:

✔ Controle de acesso
✔ Proteção de dados sensíveis
✔ Logs apropriados
✔ Não exposição de informações confidenciais

Segurança não é “camada externa”.

---

🧯 11) Violação pode gerar consequências sérias

Dependendo do ambiente:

⚠ Investigação interna
⚠ Revogação de acessos
⚠ Medidas disciplinares
⚠ Implicações legais

Mainframe é ambiente regulado.

---

🧩 12) Peça ajuda ao time de segurança

Não tente “descobrir sozinho”.

Equipes RACF existem para:

✔ Conceder acessos corretos
✔ Explicar políticas
✔ Garantir conformidade
✔ Evitar incidentes

Colaboração é parte do processo.

---

🏛️ 13) Segurança é base da confiança no Mainframe

O motivo de bancos e governos confiarem no z/OS é simples:

🔒 Controle rigoroso
📜 Auditoria forte
🧱 Arquitetura segura
⏳ Estabilidade comprovada

Sem RACF (ou equivalente), esse nível de confiança não existiria.

---

☕ Filosofia Bellacosa Mainframe

Desenvolvedor maduro não luta contra a segurança.

Ele entende que:

“Se o sistema financeiro mundial confia nessa plataforma, a segurança precisa ser implacável.”

---

⭐ Conclusão

RACF não é obstáculo.
É proteção — inclusive para você.

Quando usado corretamente:

✔ Evita erros catastróficos
✔ Garante conformidade regulatória
✔ Protege dados sensíveis
✔ Sustenta operações críticas

“No Mainframe, segurança não é feature. É fundação.”

 

🌸 Japão em Anime: Do Futuro à Rebeldia, da Juventude à Alma Urbana

Por ElJefe / Bellacosa Mainframe – Cultura Pop e Sociedade Japonesa

---

🤖 Astro Boy – O Menino Robô que Moldou a Sociedade

Criador: Osamu Tezuka
Ano: 1952 (mangá), 1963 (anime TV)
Sinopse: Em um Japão pós-guerra, o cientista Tenma cria um robô com aparência humana, chamado Atom, para substituir seu filho falecido. Atom tem inteligência, sentimentos e senso de justiça.

Impacto social:

• Inspirou jovens a se interessarem por ciência, engenharia e robótica.

• Introduziu temas de ética e responsabilidade social, debatendo direitos, tecnologia e coexistência.

• Popularizou o estilo visual de grandes olhos no anime e consolidou o mangá/anime como cultura mainstream.

Legado:

• Pavimentou o caminho para personagens de influência cultural como Doraemon, Sailor Moon e Naruto.

• Tornou-se um ícone internacional, representando tecnologia, moral e esperança japonesa.

Curiosidade Bellacosa:
O mangá original abordava temas pesados como discriminação e corrupção corporativa, décadas antes de tais debates se tornarem globais.

---

🔥 Yankii – Os Delinquentes de Coração Nobre

O que é:

• “Yankii” designa o delinquente escolar ou urbano com estilo próprio, atitude rebelde e código de honra.

• Surgiu nas décadas de 70-80, como reação à rigidez social e urbanização acelerada.

Estética:

• Cabelo descolorido, uniformes alterados, jaquetas longas, postura desafiadora, motos barulhentas.

• Mais que moda: protesto silencioso contra conformismo.

Espírito Yankii:

• Violência com honra: luta por justiça, protege amigos, segue códigos próprios.

Exemplos em anime:

• Yu Yu Hakusho – Yusuke Urameshi

• Tokyo Revengers – Takemichi Hanagaki

• Great Teacher Onizuka – Eikichi Onizuka

• Slam Dunk – Hanamichi Sakuragi

Curiosidades Bellacosa:

• Inspirados nos bōsōzoku (gangues de motoqueiros).

• Fala rude, gírias e sotaque diferenciam o Yankii do japonês educado (keigo).

Reflexão:
O Yankii é a válvula de escape da alma japonesa: desafia regras, mas mantém honra e moral — símbolo do espírito humano em meio ao conformismo.

---

🌸 Nana – Juventude, Moda e Emoção Urbana

Criadora: Ai Yazawa
Ano: 2000 (mangá), 2006 (anime)
Gênero: Drama, romance, slice-of-life, música

Sinopse sem spoiler:
Dois jovens mulheres chamadas Nana se cruzam em Tóquio, buscando independência, amor e realização pessoal, enfrentando os desafios da vida urbana e das relações humanas.

Contexto social:

• Reflete jovens adultas migrando para grandes cidades, equilibrando carreira, amizade e amor.

• Explora a mudança dos papéis femininos e a busca por independência no Japão moderno.

• Mostra pressões sociais e desafios emocionais da vida urbana.

Impacto cultural:

• Moda: inspirou tendências de cabelo, roupas e estilo punk chic.

• Música: trilha sonora e bandas fictícias influenciaram gosto musical jovem.

• Identificação emocional: debate sobre independência feminina, amizades e escolhas de vida.

Curiosidades Bellacosa:

• Considerado marco do gênero josei, voltado a mulheres jovens adultas.

• Influenciou comportamento urbano e tendências culturais no Japão dos anos 2000.

---

🧩 Conexão Entre os Três Fenômenos

Tema	Astro Boy	Yankii	Nana
Contexto	Pós-guerra, reconstrução	Urbanização, rebeldia juvenil	Vida urbana, independência feminina
Símbolo	Tecnologia e ética	Liberdade com honra	Juventude, amizade e estilo
Impacto social	Inspiração científica e ética	Expressão cultural e contestação social	Moda, música e reflexão emocional
Legado cultural	Base do anime moderno	Estilo e comportamento juvenil	Identificação feminina e urbanismo emocional

Reflexão Bellacosa:
O Japão em anime não é apenas fantasia. É um espelho histórico e social:

• Do futurismo e ética tecnológica de Atom,

• À rebeldia e liberdade do Yankii,

• À introspecção urbana e emocional de Nana.

Cada personagem e movimento reflete, critica e inspira a sociedade japonesa em diferentes épocas, mostrando que o anime é mais que entretenimento: é cultura viva.

 

Bellacosa Mainframe e o primeiro programa cobol

🌌 O Primeiro Programa no Mainframe: A Jornada do Padawan na Galáxia do COBOL

Por Vagner Bellacosa — Bellacosa Mainframe Chronicles

---

“Antes de um Jedi empunhar seu sabre de luz, ele aprende a sentir a Força. No Mainframe, antes de rodar um programa, o Padawan precisa aprender a sentir o zumbido do MVS.”
— Mestre Bellacosa

---

🚀 Capítulo 1: O Despertar do Terminal

Todo Jedi Mainframe começa no TSO/ISPF, o templo sagrado onde o código nasce.
Aqui, não há cliques, não há mouse, só o poder dos comandos.

🌀 Dica do Mestre:
TSO significa Time Sharing Option. É o modo como o z/OS permite que vários usuários interajam simultaneamente com o sistema.
O ISPF (Interactive System Productivity Facility) é o ambiente gráfico textual — sim, gráfico de ASCII, mas ainda assim — onde tudo acontece.

Para começar:

1. Entre no TSO (geralmente com um logon ID e senha).

2. Ao ver o menu do ISPF, escolha a opção 2 – Edit.

3. Crie seu primeiro dataset para o código-fonte:

   CREATE 'USERID.COBOL.SOURCE'
   

   (substitua USERID pelo seu logon)

---

🧙‍♂️ Capítulo 2: Invocando o Espírito do COBOL

Dentro do dataset USERID.COBOL.SOURCE, vamos escrever o primeiro feitiço:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLOMF.
       PROCEDURE DIVISION.
           DISPLAY 'HELLO MAINFRAME WORLD!'.
           STOP RUN.

💡 Curiosidade Bellacosa:
O primeiro programa COBOL Hello World rodou em 1959. Desde então, milhões de “HELLOs” ecoaram nos datacenters do mundo — inclusive em satélites e sistemas bancários.

🧩 Easter Egg Técnico:
Se você escrever DISPLAY 'HELLO WORLD' sem o ponto final (.), o compilador pode engasgar!
No COBOL, o ponto é sagrado — é o ponto final das sentenças, não só da gramática. 😉

---

🧰 Capítulo 3: O Ritual do JCL

Nenhum programa vive sem o JCL (Job Control Language) — o pergaminho que instrui o Mainframe a compilar e executar seu código.

Crie outro dataset:

CREATE 'USERID.JCL'

Agora o job:

//HELLOJOB JOB 'COBOL TEST',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IGYCRCTL
//COBOL.SYSIN DD DSN=USERID.COBOL.SOURCE(HELLOMF),DISP=SHR
//COBOL.SYSLIN DD DSN=&&LOADSET,UNIT=VIO,SPACE=(CYL,(1,1)),DISP=(MOD,PASS)
//SYSOUT   DD SYSOUT=*
//SYSPRINT DD SYSOUT=*

//STEP2    EXEC PGM=HELOWMF
//STEPLIB  DD DSN=USERID.LOADLIB,DISP=SHR
//SYSOUT   DD SYSOUT=*

⚙️ Explicando o feitiço:

• JOB é o início da magia — identifica o job ao JES2, o oráculo do spool.

• EXEC chama o compilador (IGYCRCTL) e depois o programa.

• SYSOUT=* manda a saída para o spool, visível com o comando SDSF ou OUTLIST.

🪄 Easter Egg Jedi:
O compilador COBOL chama o “IGYCRCTL” (IBM Guy’s Compiler Routine Control) — sim, o “IGY” vem da IBM Guy, apelido do engenheiro que escreveu o protótipo original em 1959 (piada interna).

---

🖥️ Capítulo 4: Invocando o Spool

Após submeter o job com o comando SUBMIT, use:

=SD

ou

SDSF -> ST (Status)

Para ver o job rodando. Quando terminar, veja a saída (? ou S).

Se tudo der certo, o spool mostrará:

HELLO MAINFRAME WORLD!

🎉 Parabéns, Padawan!
Você acaba de executar seu primeiro programa em um dos sistemas mais poderosos e estáveis do planeta.

---

🧭 Capítulo 5: As Trilhas do Aprendizado

Agora que sentiu o gosto da Força, siga o mapa dos próximos passos:

Nível	Missão	Ferramenta	Dica do Mestre
🥉 Iniciante	Criar programas COBOL simples	ISPF Edit	Sempre compile com atenção às mensagens IGY*
🥈 Aprendiz	Manipular VSAM	IDCAMS + COBOL	Aprenda REDEFINES e FILE STATUS
🥇 Cavaleiro	Criar programas CICS	CEDA + BMS	Domine COMMAREA e LINKAGE SECTION
🧙 Mestre	Criar Web Services no z/OS	CICS Web Services / z/OS Connect	COBOL + JSON = futuro clássico

---

☕ Curiosidade Bellacosa:

• O z/OS ainda roda código compilado há 40 anos — sim, o seu HELLOMF pode rodar em 2065 se bem armazenado.

• Em alguns bancos, a política é: “nunca mexa em programa que funciona há mais de 20 anos” — o código é tratado como reliquia sagrada.

• O STOP RUN. equivale ao “May the Force be with you” do COBOL — encerra o ciclo do programa com honra.

---

🌠 Conclusão: O Caminho do Código Antigo

O Mainframe não é um sistema — é uma filosofia.
Cada tela azul do ISPF é um portal para o passado, e cada DISPLAY é um elo com o futuro.
Ser um Padawan Mainframe é aprender que, antes de tudo, o poder está na paciência, na curiosidade e no amor por sistemas que nunca morrem.