☕ 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

domingo, 2 de fevereiro de 2025

🥋 Laboratório COBOL para Padawans Do Zero ao Primeiro Jedi do Batch

 

Bellacosa Mainframe apresenta laboratorio inicial para padawan cobol

🥋 Laboratório COBOL para Padawans

Do Zero ao Primeiro Jedi do Batch

Este laboratório foi criado para alguém que nunca programou em COBOL. Os exercícios são progressivos e apresentam conceitos, sintaxe, boas práticas, armadilhas comuns e soluções comentadas.

Objetivo:

  • Aprender sintaxe COBOL

  • Escrever programas simples

  • Compreender variáveis

  • Utilizar DISPLAY

  • Aprender IF, PERFORM, EVALUATE

  • Trabalhar com tabelas OCCURS

  • Evitar erros comuns

  • Pensar como um desenvolvedor Mainframe


Laboratório 1 – Seu primeiro programa

Objetivo

Entender estrutura COBOL.

IDENTIFICATION DIVISION.
PROGRAM-ID. LAB001.

PROCEDURE DIVISION.

    DISPLAY 'OLA PADAWAN'.

    STOP RUN.

O que aprendemos

  • DIVISION

  • PROGRAM-ID

  • DISPLAY

  • STOP RUN


Armadilhas

Esquecer:

STOP RUN.

faz o programa terminar de maneira inadequada.


Laboratório 2 – Variáveis

Objetivo

Criar variáveis.

WORKING-STORAGE SECTION.

01 WS-NOME PIC X(20).
01 WS-IDADE PIC 99.

Programa


MOVE 'VAGNER' TO WS-NOME.
MOVE 52 TO WS-IDADE.


DISPLAY WS-NOME.
DISPLAY WS-IDADE.

Boas práticas

Prefixo WS

WS-NOME
WS-SALARIO
WS-TOTAL

Evite

NOME
X1
ABC

Laboratório 3 – MOVE

Objetivo

Copiar dados.

MOVE 100 TO WS-VALOR.
MOVE WS-VALOR TO WS-TOTAL.

Erro comum

Mover texto para campo numérico

Errado

MOVE 'ABC' TO WS-IDADE.

Laboratório 4 – ACCEPT

Ler teclado.


DISPLAY 'DIGITE SEU NOME'.

ACCEPT WS-NOME.



DISPLAY WS-NOME.

Laboratório 5 – Soma

Objetivo

Calcular.


01 A PIC 999.
01 B PIC 999.
01 C PIC 9999.



ADD A B GIVING C.



DISPLAY C.

Alternativa

COMPUTE C=A+B.

Laboratório 6 – Subtração


SUBTRACT A FROM B.


DISPLAY B.

Laboratório 7 – Multiplicação


MULTIPLY A BY B.


DISPLAY B.

Laboratório 8 – Divisão


DIVIDE A INTO B.


DISPLAY B.

Melhor

DIVIDE A INTO B GIVING C.

Laboratório 9 – IF

Objetivo

Decisão.



IF WS-IDADE >=18

   DISPLAY 'MAIOR'

ELSE

   DISPLAY 'MENOR'

END-IF.

Boa prática

Sempre

END-IF

Laboratório 10 – IF aninhado



IF IDADE >60

   DISPLAY 'IDOSO'

ELSE

   IF IDADE >=18

      DISPLAY 'ADULTO'

   ELSE

      DISPLAY 'MENOR'

   END-IF

END-IF.

Laboratório 11 – EVALUATE

Mais elegante.


EVALUATE NOTA

WHEN 10
 DISPLAY 'EXCELENTE'

WHEN 8
 DISPLAY 'OTIMO'

WHEN OTHER
 DISPLAY 'ESTUDAR'

END-EVALUATE.

É o SWITCH do COBOL.


Laboratório 12 – PERFORM

Criando parágrafos.


PERFORM MOSTRAR.



MOSTRAR.

DISPLAY 'OLA'.

Boa prática

Dividir lógica.

Não fazer:

500 linhas seguidas.


Laboratório 13 – PERFORM TIMES



PERFORM 5 TIMES

 DISPLAY 'COBOL'

END-PERFORM.

Laboratório 14 – PERFORM UNTIL



MOVE 1 TO I.



PERFORM UNTIL I >5


DISPLAY I


ADD 1 TO I


END-PERFORM.

Resultado

1

2

3

4

5


Laboratório 15 – Tabelas OCCURS


01 WS-NUMEROS.

   05 WS-NUM OCCURS 5 TIMES PIC 999.

Preenchendo



MOVE 10 TO WS-NUM(1).

MOVE 20 TO WS-NUM(2).

MOVE 30 TO WS-NUM(3).

Laboratório 16 – Percorrer tabela


01 I PIC 9.


PERFORM VARYING I FROM 1 BY 1 UNTIL I >5


DISPLAY WS-NUM(I)


END-PERFORM.

Muito usado em produção.


Laboratório 17 – Strings


STRING

'NOME='

WS-NOME


DELIMITED BY SPACE


INTO WS-SAIDA.



DISPLAY WS-SAIDA.

Laboratório 18 – INSPECT

Contar letras.



INSPECT WS-TEXTO

TALLYING WS-QTD

FOR ALL 'A'.

Laboratório 19 – Inicialização


INITIALIZE REGISTRO.

Substitui:


MOVE SPACES TO REGISTRO.

MOVE ZEROS TO REGISTRO.

Laboratório 20 – Mini Projeto Final

Cadastro simples

Menu

1-Incluir

2-Consultar

3-Sair

Variáveis


01 OPCAO PIC 9.

01 NOME PIC X(30).

01 IDADE PIC 99.

Fluxo



PERFORM UNTIL OPCAO=3


DISPLAY MENU


ACCEPT OPCAO


EVALUATE OPCAO


WHEN 1

PERFORM INCLUIR


WHEN 2

PERFORM CONSULTAR


WHEN 3

DISPLAY 'ATE LOGO'


WHEN OTHER

DISPLAY 'INVALIDO'


END-EVALUATE


END-PERFORM.

📚 Erros Mais Comuns do Padawan COBOL

ErroProblema
Esquecer ponto finalCompilação falha
Não usar END-IFCódigo confuso
Índice fora do OCCURSABEND
Mover texto para PIC 9Dados inválidos
Divisão por zeroS0CB
Variável não inicializadaResultado imprevisível
Não usar GIVINGSobrescreve dados
PERFORM infinitoLoop sem fim
Nomes genéricosManutenção difícil
Misturar lógica em um único parágrafoCódigo espaguete

🎓 Checklist do Padawan COBOL

Ao concluir os 20 laboratórios, o aluno deverá saber:

✅ Criar programas COBOL
✅ Declarar variáveis
✅ Usar PIC X e PIC 9
✅ Fazer cálculos
✅ Receber dados com ACCEPT
✅ Exibir informações com DISPLAY
✅ Trabalhar com IF e EVALUATE
✅ Criar laços com PERFORM
✅ Utilizar OCCURS
✅ Manipular strings
✅ Inicializar estruturas
✅ Identificar erros comuns
✅ Desenvolver pequenos programas estruturados
✅ Aplicar boas práticas de nomenclatura e modularização

Este conjunto de laboratórios fornece uma base sólida para avançar posteriormente para arquivos sequenciais, VSAM, JCL, DB2, CICS e desenvolvimento COBOL empresarial em IBM z/OS.


Apresentação do Laboratório COBOL para Padawans

Este laboratório foi concebido para desenvolvedores iniciantes que desejam aprender COBOL de maneira prática, gradual e estruturada. O principal objetivo é fornecer uma base sólida sobre a linguagem, permitindo que o estudante compreenda sua sintaxe, suas instruções fundamentais e as boas práticas utilizadas em ambientes corporativos, especialmente no ecossistema IBM Z.

A didática adotada é baseada em pequenos desafios progressivos, nos quais cada exercício apresenta um conceito novo, seguido por uma solução comentada, observações sobre armadilhas comuns e recomendações de codificação. Essa abordagem reduz a curva de aprendizado, incentiva a experimentação e ajuda o aluno a desenvolver confiança ao escrever seus primeiros programas.

COBOL é uma linguagem predominantemente associada ao paradigma de programação estruturada e procedural. Seu modelo enfatiza a decomposição do problema em etapas sequenciais, a modularização por meio de parágrafos e seções, além do uso de estruturas de decisão e repetição claramente definidas. Essa característica torna a linguagem particularmente adequada para o processamento de regras de negócio, cálculos financeiros e sistemas transacionais de grande porte.

Realizar este laboratório permite ao estudante adquirir fundamentos essenciais antes de avançar para tópicos mais complexos, como manipulação de arquivos, JCL, VSAM, DB2, CICS e modernização de aplicações. Mais do que aprender comandos, o participante desenvolve uma mentalidade disciplinada de desenvolvimento, manutenção e qualidade de software, altamente valorizada no mercado de tecnologia corporativa.


sábado, 1 de fevereiro de 2025

🧩 Entendendo o contexto emocional

 


🧩 Entendendo o contexto emocional

Pessoas com esse perfil — sempre na rua, críticas, insatisfeitas — geralmente:

  • fogem de si mesmas: manter-se ocupada na rua é uma forma de não lidar com o que sente em casa (solidão, culpa, arrependimento, vazio).

  • usam a crítica como defesa: falar mal dos outros é um modo de projetar frustrações internas; assim, evita-se olhar para dentro.

  • reclamam da profissão porque já não veem sentido no que fazem, mas também não sabem o que mais poderiam fazer.

  • têm conflitos familiares (como as filhas em extremos opostos — uma apática e outra obcecada) que reforçam o sentimento de fracasso como mãe.

  • E, no caso do divórcio, pode haver perda de autoestima, raiva e sensação de “não ser mais vista”.


💬 Como você pode ajudar na prática

1. Escute sem confrontar

Evite tentar “corrigir” a pessoa quando ela reclama.
Em vez de dizer “você fala demais dos outros”, diga:

“Parece que isso te incomoda muito… o que você acha que te deixa mais cansada com essa situação?”

Isso muda o foco da crítica (os outros) para a emoção dela.


2. Ofereça espaço para reflexão, não julgamento

Você pode tentar plantar sementes como:

“Você sente que estar na rua ajuda a distrair a cabeça?”
“O que te faz sentir mais leve quando está sozinha?”
Essas perguntas ajudam a pessoa a reconhecer seus mecanismos de fuga — sem sentir que está sendo julgada.


3. Reforce o valor dela

Pessoas nessa fase sentem que “não servem mais pra nada”.
Elogios sinceros, focados em atitudes (não aparência) ajudam:

“Você tem uma energia impressionante, sabia? Pouca gente consegue manter essa disposição.”
“Mesmo com tudo o que passou, você continua buscando movimento — isso mostra força.”


4. Sugira novos vínculos e rotinas

  • Incentive-a a participar de grupos sociais saudáveis (oficinas, voluntariado, caminhadas, aulas de arte).

  • Atividades estruturadas ajudam a canalizar a energia para algo produtivo, em vez de dispersar em reclamações.

  • Se ela gosta de estar fora, talvez precise apenas de um motivo mais construtivo para sair.


5. Sobre as filhas

Evite entrar direto nos conflitos — isso costuma ser território delicado.
Mas pode ajudar a reformular:

“Você já percebeu que cada uma das meninas lida de um jeito diferente com a vida? Talvez isso mostre que elas precisam de coisas diferentes, né?”

Essa fala ajuda a diminuir a comparação e a culpa — e abre espaço pra ela pensar em novas formas de relação.


6. Estimule (aos poucos) o autocuidado emocional

Se for viável, incentive buscar apoio psicológico — às vezes uma conversa de orientação familiar ou individual muda muito.
Pode ser dito com naturalidade, tipo:

“Você já pensou em conversar com alguém sobre tudo isso? Às vezes ajuda a colocar as ideias no lugar.”


7. Cuide de si mesmo também

Convivência com alguém constantemente negativa é emocionalmente drenante.
Crie limites saudáveis:

  • Ouça, mas não absorva.

  • Mude de assunto quando perceber que ela está repetindo um ciclo de queixas.

  • Preserve seu humor e sua rotina.

sexta-feira, 24 de janeiro de 2025

A polemica do "Prefiro as Loiras"

 


💇‍♀️ 1. A frase não é inocente no vácuo histórico

Durante boa parte do século XX (e antes), a mídia — especialmente hollywoodiana — glorificou a mulher loira como símbolo de beleza, pureza e sucesso.
Daí nasceram estereótipos como “loira burra”, “loira fatal”, “loira de comercial de shampoo” etc.

Quando um homem diz “prefiro loiras”, muita gente ouve não apenas um gosto pessoal, mas um eco de padrões de beleza impostos, que excluíram (por décadas) outras etnias e estilos.


🎯 2. O problema é o peso simbólico, não o gosto

Ter preferência estética é natural. O que incomoda é quando isso é dito como valor absoluto ou comparativo, tipo:

“Prefiro loiras porque morenas são feias.”

Aí deixa de ser gosto e vira hierarquia de beleza, que reforça preconceitos — especialmente raciais.

Em tempos de discussões sobre representatividade, esse tipo de frase vira combustível pro debate sobre “padrão eurocêntrico” (aquele que privilegia traços brancos e europeus como “modelo ideal”).


📱 3. A internet transformou tudo em trending topic moral

Na era das redes sociais, opinião pessoal virou performance pública.
Então, quando alguém fala “prefiro loiras” em rede aberta, parece uma declaração política, e não só uma preferência.

O mesmo vale pra qualquer frase do tipo “prefiro X”, “não gosto de Y” — elas já vêm prontas pra serem julgadas, debatidas e distorcidas.


🤷‍♂️ 4. E se for só gosto mesmo?

Se a frase vem de forma leve, sem ofensa ou comparação, é só gosto — igual preferir café sem açúcar.
Mas o “mundo pós-tiktok” vive num modo em que tudo é lido com subtexto social, então o que era pessoal vira discussão coletiva.


💡 5. Como sair dessa com elegância.

  • Prefira falar do que te atrai sem desvalorizar o resto.

  • Evite generalizações: ninguém gosta de ser “categoria”.

  • Se for brincadeira, use contexto e tom — texto seco na internet é pólvora.

  • E lembre-se: gosto muda com o tempo (e às vezes com um bom sorriso).


☕ Conclusão Bellacosa

Dizer “prefiro loiras” só é polêmico porque a sociedade ainda está tentando equilibrar liberdade de expressão com respeito à diversidade.
É uma frase que flutua entre “meu gosto, minha vida” e “reforço inconsciente de um padrão excludente”.

Então, como em tudo na vida moderna: pode dizer, mas saiba o peso das palavras.
Ou, em versão barista:

“Pode ser loira, morena ou ruiva — o importante é não ser amargo no trato.” ☕

 

quinta-feira, 23 de janeiro de 2025

CASE Tools A Tecnologia que Tentou Automatizar a Engenharia de Software Muito Antes da Inteligência Artificial - Parte I

 

Bellacosa Mainframe e as case tools parte I

☕ Um Café no Bellacosa Mainframe

CASE Tools

A Tecnologia que Tentou Automatizar a Engenharia de Software Muito Antes da Inteligência Artificial

"Todo desenvolvedor acredita que a IA começou a automatizar software em 2022. Quem viveu a Engenharia de Software dos anos 80 sabe que essa história começou quase quarenta anos antes."


Introdução

Existe uma curiosidade interessante na história da computação.

Sempre que surge uma nova tecnologia capaz de produzir software mais rapidamente, aparecem manchetes dizendo que "os programadores serão substituídos".

Foi assim com as linguagens de quarta geração (4GL).

Foi assim com os geradores de código.

Foi assim com RAD (Rapid Application Development).

Foi assim com Low-Code.

Foi assim com No-Code.

E agora acontece novamente com a Inteligência Artificial.

Mas poucos profissionais conhecem o verdadeiro ancestral de todas essas tecnologias.

Seu nome era CASE Tools.

Para quem trabalha hoje com COBOL, CICS, DB2, IMS ou aplicações IBM Z, entender CASE significa compreender a origem de praticamente todas as ferramentas modernas de desenvolvimento.

Muito antes do GitHub Copilot, do ChatGPT ou dos assistentes inteligentes, já existiam ferramentas capazes de desenhar sistemas inteiros e gerar milhares de linhas de código automaticamente.

E, curiosamente, o ambiente Mainframe foi um dos maiores beneficiados dessa revolução.


O que significa CASE?

CASE significa

Computer-Aided Software Engineering

ou

Engenharia de Software Assistida por Computador.

Observe um detalhe importante.

Não significa programação automática.

Não significa inteligência artificial.

Não significa geração mágica de sistemas.

CASE nasceu com outro objetivo:

Ajudar engenheiros de software a construir sistemas melhores.

A palavra-chave é "assistida".

Da mesma forma que existe CAD (Computer-Aided Design) para engenharia mecânica e arquitetura, surgiu a ideia de criar um "CAD para software".

Em vez de desenhar prédios...

Desenharíamos sistemas.

Em vez de plantas arquitetônicas...

Teríamos modelos de software.

Em vez de construir diretamente...

Primeiro projetaríamos.

Hoje isso parece óbvio.

Na década de 1970 era revolucionário.


O problema da Programação Tradicional

Imagine um banco em 1978.

Ele precisava desenvolver:

  • Cadastro de clientes

  • Conta corrente

  • Empréstimos

  • Cobrança

  • Cartões

  • Tesouraria

  • Auditoria

  • Contabilidade

Tudo isso era escrito praticamente à mão.

Cada programa COBOL era desenvolvido individualmente.

Cada programador tinha seu próprio estilo.

Cada documentação era diferente.

Frequentemente a documentação sequer existia.

O resultado era previsível.

Após cinco anos...

Ninguém mais entendia completamente o sistema.


A Crise do Software

Entre o final dos anos 60 e toda a década de 70 surgiu um problema conhecido mundialmente como

Software Crisis.

Não faltavam computadores.

Não faltavam programadores.

Faltava capacidade de construir software grande.

Os sintomas eram conhecidos.

Projetos atrasavam.

Custos explodiam.

Erros apareciam constantemente.

Documentação desaparecia.

Manutenção tornava-se impossível.

Cada nova funcionalidade criava novos defeitos.

Essa crise levou pesquisadores a uma pergunta simples:

Como outras engenharias conseguem construir obras gigantescas com organização?

Um prédio de cinquenta andares não começa com pedreiros.

Começa com arquitetos.

Começa com plantas.

Começa com cálculos.

Começa com modelos.

Por que software era diferente?


O nascimento da Engenharia de Software

Em 1968 ocorreu um evento histórico patrocinado pela OTAN.

Foi a NATO Software Engineering Conference.

Foi ali que o termo

Software Engineering

ganhou força.

A ideia era tratar software como engenharia.

Isso significava:

  • planejamento

  • documentação

  • metodologia

  • padronização

  • revisão

  • qualidade

Essa conferência mudou completamente a indústria.

Ela também abriu caminho para o nascimento das CASE Tools.


A ideia revolucionária

Imagine um arquiteto.

Ele desenha uma planta.

Depois o engenheiro estrutural utiliza essa planta.

Depois o eletricista.

Depois o hidráulico.

Depois a construtora.

Todos trabalham sobre o mesmo projeto.

Agora imagine um sistema bancário.

Em vez de começar programando COBOL...

Primeiro seria criado um modelo.

Desse modelo nasceriam:

  • banco de dados

  • telas

  • relatórios

  • documentação

  • diagramas

  • código COBOL

  • programas CICS

  • scripts SQL

  • especificações técnicas

Tudo derivado do mesmo modelo.

Essa era a visão das CASE Tools.


Antes do Código vem o Modelo

Essa talvez seja a principal mudança de mentalidade.

O programador deixa de pensar:

Vou escrever um programa.

E passa a pensar:

Vou modelar uma solução.

O código passa a ser consequência.

Não o início.

Hoje chamamos isso de

Model Driven Development.

Na década de 80 isso já existia.


Os primeiros CASE Tools

As primeiras ferramentas começaram a aparecer no final dos anos 70.

Mas foi durante os anos 80 que elas explodiram.

Entre as pioneiras estavam soluções como:

  • Excelerator

  • IEW

  • Texas Instruments IEF

  • KnowledgeWare IEW

  • Bachman

  • ADW

  • System Architect

  • Oracle Designer

  • IBM AD/Cycle

Cada fabricante possuía sua própria visão.

Mas todas compartilhavam uma ideia comum.

Modelar primeiro.

Programar depois.


O conceito de Repositório

Talvez a inovação mais importante das CASE Tools tenha sido o conceito de

Repository.

Hoje usamos Git.

Na época usava-se um repositório de conhecimento.

Ali ficavam armazenados:

  • entidades

  • processos

  • atributos

  • regras

  • telas

  • menus

  • relacionamentos

  • fluxos

  • documentação

Não era apenas um repositório de arquivos.

Era um banco de conhecimento.

Hoje chamaríamos isso de um metamodelo.


A documentação deixou de ser um problema

Antes das CASE Tools a documentação era feita depois do sistema.

Quando sobrava tempo.

Normalmente não sobrava.

Resultado:

O documento dizia uma coisa.

O programa fazia outra.

CASE resolveu isso de maneira elegante.

A documentação era produzida automaticamente.

Mudou o modelo?

A documentação era atualizada.

Mudou o banco?

O diagrama era atualizado.

Mudou uma entidade?

Tudo era sincronizado.

Hoje isso parece comum.

Na época era extraordinário.


O poder dos Diagramas

As CASE Tools popularizaram diversos diagramas.

Entre eles:

  • Fluxogramas

  • Diagramas Entidade-Relacionamento

  • Diagramas de Dados

  • Diagramas de Processos

  • Diagramas de Estrutura

  • Diagramas Hierárquicos

  • Diagramas de Fluxo de Dados (DFD)

Por exemplo:

Cliente
   │
   ├──── Possui
   │
Conta Corrente
   │
   ├──── Gera
   │
Lançamentos

Hoje isso parece simples.

Na época substituía centenas de páginas de documentação textual.


A Revolução dos Dicionários de Dados

Outra inovação marcante foi o Data Dictionary.

Antes, o campo:

CODCLI

Poderia significar qualquer coisa.

Código do cliente?

Código do fornecedor?

Código do funcionário?

Ninguém sabia.

Com CASE surgiram descrições padronizadas.

CODCLI

Tipo:
Cliente

Formato:
PIC 9(09)

Descrição:
Identificador único do cliente.

Essa simples ideia economizou milhares de horas de manutenção.


A Engenharia Reutilizável

Outro conceito introduzido foi o de reutilização.

Em vez de criar tudo novamente...

Criavam-se componentes.

Por exemplo:

Cadastro de Cliente.

Em vez de existir em vinte programas diferentes...

Passava a existir apenas um modelo reutilizável.

Hoje chamamos isso de reutilização de componentes.

Nos anos 80 isso já fazia parte das CASE Tools.


O impacto nos bancos

Bancos rapidamente perceberam o potencial.

Imagine manter:

  • milhões de contas

  • milhares de agências

  • dezenas de milhões de clientes

Manual?

Impossível.

Modelando primeiro...

Era possível garantir consistência.

Essa foi uma das razões pelas quais instituições financeiras investiram fortemente em CASE.


O Mainframe tornou-se um ambiente ideal

O Mainframe possui uma característica importante.

Sistemas vivem décadas.

Enquanto aplicações web frequentemente são substituídas após poucos anos, sistemas COBOL podem permanecer ativos por 30, 40 ou até 50 anos.

Isso torna documentação, padronização e rastreabilidade ainda mais importantes.

CASE atendia exatamente essas necessidades.

Não era apenas uma ferramenta de produtividade.

Era uma ferramenta de governança.


O sonho da geração automática

Talvez o aspecto mais conhecido das CASE Tools fosse a geração automática de código.

O fluxo era parecido com este:

Modelo

↓

Entidades

↓

Processos

↓

Banco de Dados

↓

Programas

↓

Documentação

Em muitos ambientes era possível gerar:

  • COBOL

  • C

  • PL/I

  • SQL

  • JCL

  • CICS

  • telas

  • relatórios

  • menus

Naturalmente, o código gerado ainda exigia revisão e customização, mas representava um enorme ganho de produtividade em tarefas repetitivas.


CASE não eliminava programadores

Este é um mito que acompanha a tecnologia desde sua criação.

Alguns acreditavam que bastaria desenhar diagramas e a ferramenta faria todo o restante.

Na prática, isso nunca aconteceu.

O que ocorreu foi uma mudança de foco.

Os profissionais passaram a gastar menos tempo escrevendo estruturas repetitivas e mais tempo analisando regras de negócio, arquitetura e qualidade.

A engenharia ganhou espaço sobre a simples codificação.

Curiosamente, esse mesmo debate reaparece hoje com a Inteligência Artificial.


Por que muitas CASE Tools desapareceram?

Apesar do enorme entusiasmo, muitas ferramentas perderam espaço durante os anos 1990.

Os principais motivos foram:

  • custo elevado de aquisição e manutenção;

  • necessidade de treinamento especializado;

  • dificuldade de adaptação a mudanças rápidas nos negócios;

  • geração de código excessivamente dependente do fornecedor (vendor lock-in);

  • modelos complexos para projetos pequenos;

  • ascensão da orientação a objetos e de novas metodologias de desenvolvimento.

Ainda assim, suas ideias não desapareceram. Elas foram incorporadas a UML, IDEs modernas, geradores de código, ferramentas de DevOps, plataformas Low-Code e, mais recentemente, aos assistentes baseados em IA.


Muito além de uma tecnologia antiga

É comum ouvir que CASE é uma tecnologia "do passado". Na realidade, o nome caiu em desuso, mas seus princípios continuam presentes.

Quando um desenvolvedor cria um modelo UML que gera classes Java, está aplicando conceitos de CASE.

Quando uma ferramenta cria APIs a partir de um contrato OpenAPI, há geração baseada em modelos.

Quando um pipeline de DevOps produz documentação automaticamente a partir do código, há automação da engenharia.

E quando uma IA sugere código a partir de uma descrição funcional, ela está ampliando uma ideia que começou décadas antes: reduzir o esforço repetitivo para que o engenheiro concentre sua atenção na solução do problema.


Conclusão

As CASE Tools nasceram para resolver um desafio que permanece atual: como desenvolver software cada vez mais complexo sem perder qualidade, organização e capacidade de manutenção.

Elas introduziram conceitos que hoje parecem naturais: modelagem antes da implementação, repositórios de conhecimento, documentação automática, dicionários de dados, reutilização de componentes e geração de código.

Para quem trabalha com COBOL e IBM Z, compreender essa história é entender por que tantos ambientes corporativos ainda valorizam modelagem, rastreabilidade e padronização. O Mainframe não ficou preso ao passado; ele foi um dos grandes laboratórios onde essas ideias amadureceram e provaram seu valor em sistemas que processam bilhões de transações com confiabilidade excepcional.

No próximo artigo, veremos como as CASE Tools evoluíram em categorias como Upper CASE, Lower CASE e Integrated CASE (I-CASE), conheceremos suas principais metodologias, analisaremos exemplos práticos de uso e entenderemos por que elas influenciam diretamente as plataformas Low-Code, No-Code e até mesmo a Inteligência Artificial aplicada ao desenvolvimento de software.

"Toda geração acredita ter inventado uma nova forma de desenvolver software. A história mostra que quase todas elas começam pela mesma ideia: pensar antes de programar. As CASE Tools foram uma das primeiras grandes tentativas de transformar essa ideia em engenharia."

 

quarta-feira, 22 de janeiro de 2025

☕ Por que é errado ser politicamente correto?



Por que é errado ser politicamente correto?

☕ Antes que alguém se ofenda com o título...

Calma. O café nem esfriou ainda.

Antes que alguém abra o teclado, estale os dedos e comece a preparar uma resposta de dezessete parágrafos explicando por que este texto representa tudo aquilo que há de errado na humanidade, talvez seja importante esclarecer uma coisa: não existe nada de errado em respeitar as pessoas.

Aliás, deveria ser exatamente o contrário.

Durante boa parte da vida aprendemos algumas regras bastante simples de convivência: não humilhar alguém gratuitamente, não transformar diferenças em motivo de desprezo, pensar um pouco antes de falar e, quando perceber que pisou no pé de alguém, simplesmente tirar o pé.

Não parece particularmente complicado.

O problema começa quando aquilo que deveria funcionar como bom senso ganha tantas regras, exceções, interpretações e patrulhas que conversar passa a parecer uma tentativa de atravessar um campo minado carregando uma xícara de café cheia até a borda.

Foi daí que nasceu minha curiosidade sobre o chamado politicamente correto.

Em algum momento, uma ideia essencialmente razoável — prestar atenção às palavras e respeitar quem está do outro lado — entrou no liquidificador da política, das redes sociais, dos algoritmos, das guerras culturais e, naturalmente, da extraordinária capacidade humana de transformar qualquer coisa em discussão.

E chegamos a uma situação curiosa.

De um lado, pessoas com medo de dizer qualquer coisa.

Do outro, pessoas orgulhosas de dizer absolutamente qualquer coisa.

No meio delas existe provavelmente a maioria de nós, tentando descobrir se ainda podemos contar uma piada, discordar educadamente, cometer um erro, pedir desculpas, aprender alguma coisa e continuar a conversa.

Talvez seja justamente aí que esteja a questão.

O problema nunca foi aprender a respeitar.

O problema começa quando deixamos de conversar.

Então coloque o café na mesa, desligue por alguns minutos o botão imaginário do “cancelar” e venha comigo explorar esse estranho manual moderno de convivência que ninguém recebeu, todo mundo parece conhecer e absolutamente ninguém consegue interpretar da mesma maneira.


(Ou: como perdemos o manual de “como conversar sem ofender ninguém”)

Ah, o politicamente correto. Esse ser mítico que nasceu com boas intenções, cresceu cheio de regras e hoje vive assombrando grupos de WhatsApp, churrascos e timelines.

🌍 A origem: quando tudo era mato (e piada de tiozão)

O termo surgiu lá pelos anos 1970, entre movimentos sociais e universidades — especialmente nos EUA. A ideia era simples: usar linguagem inclusiva e respeitosa pra não reforçar preconceitos.
Mas como toda boa invenção humana... o pessoal exagerou.

Virou um jogo de tabuleiro moderno:

  • “Pode falar isso?”

  • “Depende do contexto.”

  • “E se for ironia?”

  • “Depende da intenção.”

  • “E se for meme?”

  • “Depende do algoritmo.”

Resultado: ninguém sabe mais quando está sendo gentil ou cancelável.

🧠 A razão: o medo do “cancelamento”

O politicamente correto nasceu da empatia, mas virou um manual de etiqueta com 18 volumes e notas de rodapé.
Hoje, em vez de dizer “bom dia”, muita gente pensa:

“Será que ofendo alguém que não acredita em dias bons?”

O medo de errar nos transformou em robôs sociais: sorrimos, concordamos, mas pensamos “lá vem textão”.

📜 A evolução (ou involução)

Nos anos 2000, o “politicamente correto” começou a virar arma política.
Um grupo dizia “seja mais sensível”, o outro retrucava “vocês estão mimando o mundo”.
E assim nasceu a guerra santa da internet: os ofendidos versus os debochados.

Curiosamente, ambos querem o mesmo: liberdade pra falar — só divergem em como.

🤯 Curiosidades

  • O termo “politicamente correto” era originalmente uma brincadeira entre ativistas de esquerda — usado de forma irônica!

  • Em 1990, o New York Times publicou uma série de artigos sobre o tema, e o termo explodiu.

  • No Brasil, o auge veio nos anos 2010, quando descobrimos o poder de um “lacrou” e um “cancelado” no mesmo post.

  • A internet transformou a empatia em um campo minado sem tutorial.

☕ Dicas pra sobreviver ao politicamente correto

  1. Fale com empatia, mas não viva em pânico.

  2. Pergunte antes de ofender (funciona em 80% dos casos).

  3. Evite generalizações, a menos que seja pra falar mal de fila de banco.

  4. Aprenda e siga em frente. Errar é humano, repetir é “cringe”.

  5. Lembre-se: humor sem maldade é possível — só dá mais trabalho.

💬 Comentário final do Bellacosa

Ser politicamente correto não é errado — o problema é esquecer que humor, contexto e intenção ainda existem.
O segredo é simples: respeito com leveza.
Nem tanto o “mimimi”, nem tanto o “tiozão do pavê”.

Ou como diria o filósofo do boteco digital:

“Se você não pode rir de nada, então estamos ferrados. Mas se você ri de tudo, o problema é você.”

No fim das contas, o politicamente correto é igual café: na dose certa, desperta consciência; em excesso, dá azia social.

segunda-feira, 20 de janeiro de 2025

🧠 1. Entenda o "ritmo digital"

 


🧠 1. Entenda o "ritmo digital"

Mensagens curtas demais parecem frias, longas demais soam cansativas.
➡️ Dica: tente manter um equilíbrio. Use frases completas, mas diretas, e sinalize emoções com sutileza (“haha”, “entendo bem isso”, “👍”, “boa sacada”). Pequenas expressões humanizam o texto.


💬 2. Use o tempo de resposta a seu favor

Responder rápido pode passar entusiasmo — ou ansiedade.
Responder devagar pode demonstrar reflexão — ou desinteresse.
➡️ Dica: se demorar, contextualize (“fui pegar um café”, “tava pensando no que você disse”). Isso evita mal-entendidos e aproxima.


🪞 3. Espelhe o estilo da outra pessoa

Perceba se o outro escreve de modo formal, brincalhão, detalhista ou objetivo.
➡️ Dica: adapte levemente seu estilo. Essa “sincronia comunicativa” gera empatia e faz a conversa parecer mais natural.


🔍 4. Dê sinais de escuta ativa

Mostre que está acompanhando:
“Interessante isso que você falou...”
“Conta mais sobre tal parte...”
➡️ Isso substitui o olhar e o aceno que usamos presencialmente.


🎭 5. Cuide da expressividade sem exagerar

Emoticons, GIFs e pontuações são os “gestos” do chat.
➡️ Use-os para pontuar humor ou leveza — mas sem transformar a conversa em carnaval visual. Equilíbrio é a alma da interação digital.


🧩 6. Não tenha medo do silêncio virtual

Nem toda conversa precisa ser constante. Muitas pessoas alternam períodos de fala intensa e pausas naturais.
➡️ Dica: aceite o fluxo. Isso evita a sensação de “precisar entreter” o outro.


❤️ 7. Lembre-se: empatia é o que conecta

Mesmo no texto, é a intenção humana que dá cor à conversa. Seja curioso, sincero e gentil — o resto é técnica.

sexta-feira, 17 de janeiro de 2025

Mahōtsukai no Yakusoku: quando 21 magos traumatizados receberam um chamado de produção para impedir a Lua de derrubar o mundo

 

Bellacosa Mainframe apresenta o Mahotsukai no Yakusoku

☕ Um Café no Bellacosa Mainframe

Mahōtsukai no Yakusoku: quando 21 magos traumatizados receberam um chamado de produção para impedir a Lua de derrubar o mundo

Ou: por que a Grande Calamidade parece um SEV-1 anual, Akira vira gerente de relacionamentos sem treinamento, e o verdadeiro feitiço não é lançar fogo — é convencer pessoas complicadas a não destruírem umas às outras

ItemInformação
Título original魔法使いの約束 (Mahōtsukai no Yakusoku)
Título ocidentalPromise of Wizard
OrigemJogo mobile narrativo da coly
Lançamento do jogo26 de novembro de 2019, para iOS e Android
Roteiro originalBunta Tsushimi
Design originalDangmill
Anime6 de janeiro a 24 de março de 2025
Episódios12
EstúdioLIDENFILMS
DireçãoNaoyuki Tatsuwa
Roteiro do animeNanami Higuchi
GênerosFantasia sombria, drama, aventura, mistério, joseimuke/otome game, ficção de personagens
Faixa etária sugeridaAdolescente em diante; não é explícito, mas lida com morte, violência fantástica, trauma, preconceito e relações emocionalmente pesadas

O ponto essencial: isto não nasceu como light novel nem como mangá. Mahōtsukai no Yakusoku nasceu como um jogo gratuito de desenvolvimento e vínculo com magos — com compras internas, narrativa em capítulos, cartas de personagens e eventos. O próprio site o define como um “jogo de treinamento que conecta corações com magos”. Fonte oficial

Portanto, quando alguém entra esperando um isekai de espada, level, baú de tesouro e protagonista que resolve a geopolítica com uma magia proibida, pode estranhar. Aqui, o recurso mais escasso não é mana. É maturidade emocional.


Prólogo — “Bem-vindo ao mundo quebrado”; por favor, abra um chamado

Akira Masaki é uma pessoa comum da Terra que, numa noite de lua cheia, entra em um elevador e chega a outro mundo. Não foi convocada porque possuía uma habilidade EXTRA-SSS. Não ganhou tela de status, escrava-gata, castelo ou harém.

Foi convocada como Sábia.

A função é quase a pior possível: tornar-se a pessoa capaz de aproximar e guiar 21 magos escolhidos para lutar contra a Grande Calamidade — uma Lua colossal que, uma vez por ano, desce sobre o mundo e o castiga.

É uma premissa belíssima porque a Lua não é simplesmente um chefão. Ela é uma ameaça inevitável, cíclica e quase religiosa. Todo ano o mundo sabe que ela voltará. Todo ano os magos precisam se reunir. Todo ano eles fazem isso carregando rancores, culpas, lutos, preconceitos e segredos que fariam uma reunião de war room de mainframe parecer um encontro de escoteiros.

O mundo possui cinco países, cada qual com cultura, perigos e relação distinta com a magia. A obra, oficialmente, se apresenta como uma história coral de Akira e 21 magos convocados de outro mundo para enfrentar essa calamidade. Apresentação oficial



A grande aventura: não é matar a Lua; é sobreviver a si mesmo

A aventura de Mahoyaku funciona em duas camadas.

Na camada visível, há viagens, rituais, ferimentos mágicos, monstros, disputas entre reinos, investigação de fenômenos estranhos e a preparação para enfrentar a Grande Calamidade.

Na camada importante, cada aventura pergunta: “o que este mago se tornou para não sofrer de novo?”

É por isso que alguém pode ser arrogante, cruel, infantil, isolado, excessivamente gentil, imprudente ou incapaz de confiar. O anime não trata essas características como meros botões de “waifu/husbando”; geralmente há uma cicatriz estrutural por baixo.

A Sábia não controla os magos como unidades de RPG. Ela precisa observá-los, escutá-los, descobrir limites e criar uma razão para continuarem juntos. Em linguagem de CPD: Akira não ganhou RACF SPECIAL; recebeu a responsabilidade de coordenar 21 sistemas legados que não documentaram suas dependências e guardam trauma em produção.



Os cinco domínios — uma topologia de pessoas quebradas

Reino Central: o serviço que precisa parecer estável

  • Arthur é o príncipe idealista, criado para ser símbolo de esperança.

  • Oz, seu tutor, é um mago poderosíssimo, distante e carregado de história.

  • Cain traz a figura do cavaleiro sociável e confiável — mas a obra não deixa essa simplicidade intacta.

  • Riquet é o jovem religioso, sincero e ainda em formação.

O Centro é o país do dever, da política e da imagem pública. Sua mensagem é cruelmente adulta: não basta ser bom; às vezes o mundo exige que você pareça inabalável, mesmo quando está com os módulos internos pegando fogo.

Reino do Norte: o datacenter em zona de desastre

  • Snow e White são os anciãos gêmeos, quase infantis na aparência, mas milenares e perigosos.

  • Mithra é brutal, sedutor e obcecado por força.

  • Owen gosta do medo e da maldade alheia; é o tipo de colega que responde ao incidente perguntando se pode piorar.

  • Bradley, ex-líder de bandidos e prisioneiro, é agressivo, guloso e, surpreendentemente, capaz de lealdade.

O Norte é gelado, violento e moralmente instável. Aqui, a magia não é perfume de fada: é poder, fome, sobrevivência e ameaça. A obra recusa a ideia confortável de que indivíduos violentos são “maus por estética”. Eles têm história, e história não equivale a absolvição.



Reino do Leste: o departamento que chama trauma de tradição

  • Shino é pequeno, combativo e extremamente poderoso.

  • Faust é o mago intelectual, ferido e severo.

  • Heathcliff carrega o peso de sua posição e de sua origem.

  • Nero parece relaxado, mas percebe mais do que demonstra.

O Leste trabalha especialmente bem o tema de classe social, servidão, hierarquia e afeto que não sabe se expressar. A relação entre Shino e Heathcliff é um dos melhores exemplos da série: os dois importam profundamente um para o outro, mas foram educados num sistema que torna esse vínculo desigual, embaraçoso e doloroso.

É o tipo de arco que diz: “você pode amar alguém e ainda assim reproduzir uma estrutura que o machuca”.

Reino do Oeste: charme, teatro e falha lógica

  • Murr é alegre, caótico e misterioso.

  • Shylock é elegante, sofisticado e cheio de camadas.

  • Chloe é costureiro, gentil e aprende a afirmar a própria identidade.

  • Rustica é teatral, romântico e não cabe em explicações fáceis.

O Oeste é o território da aparência, da arte, do desejo e da performance. Mas não é apenas “os magos bonitos e excêntricos”. É onde a obra pergunta quem você pode ser quando a sociedade exige que você se esconda, se adapte ou vire personagem de si mesmo.

Reino do Sul: onde a gentileza também tem histórico de incidentes

  • Figaro é médico, inteligente, simpático e absolutamente pouco confiável no sentido mais fascinante.

  • Lennox é o pastor silencioso que provavelmente resolveria uma batalha dando um soco no problema.

  • Rutile é professor, doce e voltado à convivência entre humanos e magos.

  • Mitile, seu irmão mais novo, quer ficar mais forte e ainda está descobrindo o mundo.

O Sul parece ser a área mais amena da topologia, mas esconde algumas das histórias mais melancólicas. Figaro, em particular, é aquele profissional veterano que entra sorrindo na sala, resolve tudo em dez minutos e faz você perceber três temporadas depois que ele sabia de algo desde o início.


O que há de diferente?

A diferença central é que Mahōtsukai no Yakusoku não quer apenas que o público “escolha seu mago favorito”. Ele quer que você conviva com ele.

Há um olhar de otome game — muitos homens carismáticos, visual refinado e relações intensas —, mas a obra evita funcionar como romance automático. Não existe um harém tradicional com Akira distribuindo afeto e conquistando todos por existir. O foco é mais amplo: amizade, cuidado, medo, lealdade, desigualdade, abandono, identidade e o custo de proteger alguém.

Também importa que Akira não seja apresentada como guerreira suprema. A função da Sábia é de presença e escuta. Para parte do público isso pode parecer pouca ação; para mim, é precisamente a proposta. Há histórias em que o herói salva o mundo com espada. Nesta, salvar o mundo exige impedir que pessoas traumatizadas se tornem armas sem freio.

A Lua vira uma metáfora quase perfeita para uma dor recorrente: ela sempre retorna, ninguém pode fingir que não existe, e a saída não é vencê-la sozinho.

Mensagens ocultas — ou o SYSOUT emocional que muita gente ignora

1. Poder não cura ferida

Os magos são absurdamente capazes. Ainda assim, não conseguem resolver luto, culpa, medo ou abandono só com magia. É uma boa vacina contra a fantasia de que competência técnica resolve a vida inteira.

Pode resolver o abend. Não necessariamente resolve a pessoa que provocou o abend por exaustão, medo ou uma década sendo ignorada.

2. Coexistir não é tolerar à distância

Humanos e magos vivem no mesmo mundo, mas isso não significa igualdade. Há suspeita, exploração, medo e hierarquias. A obra insiste que convivência é trabalho ativo: escutar, negociar limites, corrigir violência e reconhecer privilégios.

3. Cuidar não é possuir

Muitos vínculos da série caminham numa fronteira delicada entre proteção, dependência e controle. Algumas relações parecem ternas; outras parecem perigosamente apertadas. A obra frequentemente pergunta se alguém está cuidando do outro ou apenas tentando impedir que ele tenha liberdade.

4. Não há “reset anual” para a dor

A Grande Calamidade volta todo ano. Isto é importante: a vitória de hoje não apaga a vulnerabilidade de amanhã. É uma mensagem madura sobre manutenção. Segurança, relações, saúde mental, observabilidade e confiança não são projeto de uma vez só. São operação contínua.

O anime da LIDENFILMS — bonito, competente e espremido

A produção da LIDENFILMS tem direção de Naoyuki Tatsuwa, composição e roteiro de Nanami Higuchi, design de personagens de Nozomi Nagatomo e música de Shūji Katayama. A abertura é “Year N”, da Mili; o encerramento é “Bokura wa Ai ni Koishite Ikiru”, por LIP×LIP. Equipe oficial do anime · Página da LIDENFILMS

O estúdio acerta na atmosfera: palácios, neve, luas, interiores antigos e personagens parecem pertencer ao mesmo conto de fadas rachado. A música ajuda a criar aquele sentimento de beleza que pode, a qualquer momento, virar funeral.

O principal problema é aritmético: 21 magos + Akira + cinco países + mitologia + arcos emocionais em 12 episódios.

É como tentar colocar uma aplicação COBOL, CICS, Db2, MQ, RACF, batch, WLM e painel de operação em uma apresentação de quinze minutos. Há bom material, mas não existe espaço suficiente para todos respirarem. O anime serve melhor como porta de entrada ou como reencontro visual para quem já conhecia o jogo; ele apresenta muitos nomes, passados e conexões num ritmo que pode deixar o novato com a sensação de ter chegado ao episódio 47 de uma série que começou sem ele.

Impacto cultural — um universo de mídia, não apenas um anime

Mahoyaku tornou-se uma franquia muito mais forte no Japão do que a presença internacional do anime sugere. O jogo gerou mangás, antologias, peças teatrais, eventos, produtos, rádio e experiências presenciais. A longevidade é real: em 2026 a franquia lançou um teatro imersivo, no qual o visitante entra no salão e acompanha a narrativa como convidado, aprendiz ou “fantasma” invisível — uma adaptação extremamente coerente para uma obra construída em torno de estar ao lado dos personagens. Teatro imersivo oficial

O fenômeno das peças 2.5D, apelidadas de Mahostage, também mostra o tamanho do apego japonês ao elenco. Ali o público não compra apenas uma trama; compra a oportunidade de ver relações favoritas ganharem corpo, voz e presença. Site oficial do palco

A franquia chegou a anunciar mais de seis milhões de downloads no material promocional de sua adaptação teatral. Isso não faz dela um fenômeno mundial do tamanho de Genshin Impact, mas a coloca como uma propriedade sólida e duradoura do nicho narrativo feminino japonês. Registro promocional oficial

Censura e classificação: há algo cortado?

Não há uma “versão adulta” secreta, nem uma origem eroge escondida debaixo da mesa do CPD. A franquia é voltada ao mercado joseimuke/otome, com sensualidade visual, ambiguidade romântica, homens belos e relações intensas, mas não é pornográfica.

Também não existe informação confiável de uma edição censurada específica do anime. O que há é adaptação: uma obra de jogo com dezenas de horas de história inevitavelmente perde contexto quando comprimida em doze episódios. Isso é corte de narrativa, não censura moral.

O conteúdo pode incomodar crianças pequenas por morte, ameaças, violência mágica, manipulação emocional e temas de trauma. Porém, não é uma série de gore explícito, erotismo gráfico ou choque gratuito. Seu peso vem mais da melancolia do que da imagem.

Mangás, novels, jogos e outras versões

Jogo

É a origem de tudo: lançado em 2019 pela coly para iOS e Android, com roteiro de Bunta Tsushimi e conceito visual de Dangmill. A história principal continuou além do anime, dividida em grandes partes e eventos. Ficha oficial

Mangá original

O primeiro mangá oficial foi desenhado por Uta Shinonome, publicado pela Ichijinsha na revista Comic ZERO-SUM. Ele teve três volumes e adaptou a introdução da história. A editora credita Shinonome no desenho, Tsushimi/coly no original e Dangmill no design. Editora Ichijinsha

Mahōtsukai no Yakusoku COMIC

Uma segunda adaptação em mangá começou com arte de Shibatarō Nakamura, também pela Ichijinsha. Ela recomeça a entrada de Akira no mundo dos magos e é uma opção mais recente para quem preferir a história em quadrinhos. Página oficial

Light novel

Aqui está a pegadinha bibliográfica: não há uma light novel como obra original da franquia. É comum procurar porque tantos animes de fantasia vêm de web novels, mas Mahoyaku seguiu o caminho inverso: jogo narrativo → mangá, teatro e anime.

Veredito Bellacosa

Mahōtsukai no Yakusoku é para quem aceita que magia não é sinônimo de escapismo leve. É um conto de fadas bonito, povoado por homens elegantes, mas com a estrutura emocional de um sistema crítico que funciona há séculos porque ninguém teve coragem de desligá-lo para manutenção.

Se você gosta de isekai em que o herói vira um semideus e põe o mundo em fila, talvez ele pareça lento. Se gosta de histórias de personagem, relações ambíguas, fantasia triste e daquele tipo de elenco em que cada um parece carregar um arquivo TRAUMA.PROD sem documentação, há bastante riqueza aqui.

E eis o easter egg final: o verdadeiro mago mais poderoso não é necessariamente Oz, Mithra ou qualquer criatura capaz de explodir uma montanha. É quem consegue sentar com Owen, Figaro, Faust, Shino e Bradley na mesma mesa, terminar o café e não abrir um incidente de prioridade máxima.



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