✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

sábado, 28 de janeiro de 2023

☕💣👑 O ESTAGIÁRIO QUE RECEBEU PERFIL SPECIAL NO NASCIMENTO — Jitsu wa Ore, Saikyō Deshita? E O MAIOR ERRO DE SEGURANÇA JÁ APROVADO PELOS DEUSES

Bellacosa Mainframe alguem se enganou Jitsu wa Ore, Saikyo Deshita

☕💣👑 O ESTAGIÁRIO QUE RECEBEU PERFIL SPECIAL NO NASCIMENTO — Jitsu wa Ore, Saikyō Deshita? E O MAIOR ERRO DE SEGURANÇA JÁ APROVADO PELOS DEUSES

Ficha Técnica

Título Original: 実は俺、最強でした？
Romanizado: Jitsu wa Ore, Saikyō Deshita?
Título Internacional: Am I Actually the Strongest?

Autor da Light Novel: Sai Sumimori
Ilustrador: Ai Takahashi
Mangá: Takahashi Airi
Estúdio: Staple Entertainment
Direção: Takashi Naoya
Lançamento do Anime: Julho de 2023
Episódios: 12
Temporadas: 1
Status: Concluído (até junho de 2026)

☕ O IPL MAIS CATASTRÓFICO DA HISTÓRIA DOS ISEKAIS

Imagine a seguinte situação:

Um novo usuário nasce no ambiente.

O sistema executa automaticamente uma validação de privilégios.

O relatório mostra:

MAGIA: 0002
STATUS: INÚTIL
AÇÃO: DESCARTAR
RC=00

O problema?

O campo estava truncado.

Na verdade era:

MAGIA: 1002
STATUS: AMEAÇA EXISTENCIAL
AÇÃO: NÃO TOCAR

E assim começa Jitsu wa Ore, Saikyō Deshita?.

Uma obra que parece mais um isekai genérico na superfície, mas que esconde uma crítica interessante sobre julgamentos precipitados, métricas erradas e a obsessão humana por indicadores superficiais.

Sinopse

Haruto morre em nosso mundo e recebe uma nova chance de vida.

Uma deusa o reencarna em um universo de magia.

Seu poder mágico é tão absurdo que ultrapassa os limites de medição existentes.

Quando seus pais veem o resultado da avaliação, acreditam que ele possui apenas nível 2 de magia.

Conclusão?

O recém-nascido é abandonado na floresta.

Sim.

Os próprios pais executam um DELETE sem BACKUP.

Mas Haruto sobrevive.

E descobre que talvez seja o ser mais poderoso daquele mundo.

A História

Diferentemente de muitos isekais focados em vingança ou conquista mundial, Haruto tem um objetivo extremamente simples:

Não trabalhar.

Ele quer apenas viver tranquilamente.

Assistir seus equivalentes de anime.

Ler.

Dormir.

Fugir de responsabilidades.

Ou seja:

O sonho secreto de metade dos profissionais de TI após uma janela de manutenção de 18 horas.

Mas o universo possui outros planos.

Cada tentativa de permanecer anônimo gera mais fama.

Cada tentativa de evitar problemas cria novos problemas.

Cada solução improvisada cria consequências maiores.

O que começa como uma fantasia leve evolui para conspirações políticas, ameaças demoníacas e conflitos entre nações.

O Que Torna Esse Anime Diferente?

À primeira vista parece apenas mais um:

"Protagonista absurdamente apelão em outro mundo."

Mas existem algumas diferenças.

1. O Herói Não Quer Ser Herói

Haruto não sonha em salvar o mundo.

Não quer ser rei.

Não quer derrotar o rei demônio.

Não quer montar harém.

Ele quer paz.

Isso gera situações cômicas porque o mundo inteiro tenta empurrá-lo para posições de liderança.

2. Charlotte Rouba a Série

Se existe uma personagem que se tornou fenômeno entre os fãs, essa personagem é Charlotte.

Ela é a irmã adotiva de Haruto.

Pequena.

Fofoleta.

Mas completamente obcecada pelo irmão.

Sua inteligência, carisma e interações se transformaram em um dos maiores atrativos da obra.

Muitos fãs afirmam que Charlotte acabou se tornando mais popular que o protagonista.

3. O Poder Não É o Centro

Curiosamente, o anime raramente usa seu protagonista para criar tensão.

Todo mundo sabe que ele vencerá.

A diversão está em observar:

como ele esconde o poder;
como os outros interpretam suas ações;
como situações simples se tornam crises gigantescas.

Personagens Principais

Haruto Zenfis

O protagonista.

Uma mistura de:

gênio;
preguiçoso profissional;
administrador de sistemas relutante.

Recebe um poder praticamente ilimitado.

Mas prefere evitar responsabilidades.

Charlotte Zenfis

A irmã mais nova.

Talvez a personagem mais querida da série.

Possui momentos de humor, inteligência e emoção que frequentemente roubam a cena.

Flay

Uma antiga dragão extremamente poderosa.

Após ser derrotada por Haruto, torna-se sua subordinada.

Representa o clássico arquétipo do ser lendário que descobre que existe alguém ainda mais absurdo.

Liza

Guerreira leal.

Ajuda Haruto em diversas aventuras.

Funciona como uma ponte entre o protagonista e o restante do mundo.

Temática Oculta

Aqui está o aspecto mais interessante.

O anime fala repetidamente sobre:

Julgamento por Métricas

Haruto foi descartado porque alguém confiou cegamente em um número.

Quantas vezes empresas fazem exatamente isso?

KPIs errados.
Métricas incompletas.
Avaliações superficiais.
Indicadores fora de contexto.

A série sugere que números sem interpretação podem produzir decisões absurdas.

Potencial Invisível

A obra trabalha constantemente a ideia de que valor real nem sempre é imediatamente percebido.

O mundo vê aparência.

O sistema vê registros.

Mas a realidade costuma ser mais complexa.

O Peso das Expectativas

Haruto deseja liberdade.

Mas seu talento atrai responsabilidades.

É uma metáfora interessante sobre pessoas altamente capacitadas que acabam se tornando prisioneiras de suas próprias competências.

As Aventuras

Durante a série encontramos:

ataques demoníacos;
criaturas mágicas;
conflitos políticos;
organizações secretas;
ameaças ao reino;
conspirações envolvendo heróis;
investigações sobrenaturais.

Mas tudo é filtrado por uma camada constante de humor.

A obra nunca tenta se tornar excessivamente sombria.

Houve Censura?

Não existe histórico relevante de censura envolvendo o anime.

A adaptação manteve a essência da light novel.

O que ocorreu, como em praticamente toda adaptação, foram simplificações e cortes de conteúdo para caber nos 12 episódios.

Diversos eventos receberam ritmo acelerado em comparação ao material original.

Impacto Cultural

Jitsu wa Ore, Saikyō Deshita? não revolucionou o gênero.

Não foi um novo Sword Art Online.

Não foi um novo Mushoku Tensei.

Não foi um novo Re:Zero.

Mas conquistou seu espaço entre os fãs de:

protagonistas overpower;
fantasia leve;
comédia isekai;
personagens carismáticos.

Sua principal contribuição foi reforçar uma tendência moderna:

O protagonista superpoderoso já não precisa provar força.
O desafio agora é sobreviver às consequências sociais de ser forte demais.

Classificação

Gêneros:

Isekai
Fantasia
Comédia
Aventura
Magia
Slice of Life Fantástico

Faixa Indicativa:
14 anos (varia conforme país e plataforma)

Veredito Bellacosa Mainframe ☕

Se eu tivesse que resumir esse anime em linguagem de datacenter, seria:

Um bebê recebeu autoridade SYSADM, SPECIAL, OPERATIONS e SECURITY no nascimento.
O sistema de auditoria interpretou tudo errado.
O usuário foi excluído da organização.
Sobreviveu.
Criou um ambiente paralelo.
Assumiu controle da infraestrutura sem perceber.
E ainda passou metade do tempo tentando evitar reuniões.

Jitsu wa Ore, Saikyō Deshita? é uma divertida reflexão sobre competência invisível, erros de avaliação e o perigo de confiar cegamente em relatórios.

Porque, às vezes, o maior talento do ambiente não é o usuário com mais certificados.

É justamente aquele que foi marcado como "inútil" por um sistema incapaz de medir seu verdadeiro potencial. ☕💣👑

quinta-feira, 26 de janeiro de 2023

A Sociedade do Feed Infinito - Vicios e Virtudes

Bellacosa Mainframe apresenta a sociedade do feed infinito

☕ Um Café no Bellacosa Mainframe

A Sociedade do Feed Infinito

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Psicologia, Sociologia, Algoritmos e Como as Redes Sociais Estão Reprogramando a Forma Como Enxergamos o Sucesso

"Nunca tivemos tanto acesso ao mundo. Talvez justamente por isso nunca tenha sido tão difícil encontrar paz dentro dele."

Introdução

Imagine um operador de Mainframe monitorando milhares de transações por segundo.

Agora imagine que, em vez de processar apenas transações bancárias, ele processa comparações sociais.

Todos os dias.

Sem pausa.

Sem manutenção.

Sem janela de IPL.

Esse sistema existe.

Chama-se cérebro humano.

A diferença é que ele foi projetado para comparar dezenas de pessoas da tribo, não bilhões de perfis espalhados pelo planeta.

Enquanto nossa tecnologia evoluiu em velocidade exponencial, nossa arquitetura biológica continua praticamente a mesma de dezenas de milhares de anos atrás.

E talvez seja justamente aí que esteja um dos maiores desafios da sociedade moderna.

Quando a Comparação Era Local

Durante quase toda a história da humanidade, uma pessoa conhecia poucas centenas de indivíduos.

Seu conceito de sucesso era baseado em perguntas simples:

Meu vizinho está melhor?
Minha família está segura?
Minha colheita foi boa?
Tenho alimento suficiente?

O "rico" existia.

Mas normalmente era o fazendeiro da região, o comerciante da cidade ou o proprietário das terras.

Hoje, antes mesmo do café da manhã, alguém pode assistir:

um jantar em um restaurante Michelin em Tóquio;
uma viagem de jatinho para Mônaco;
um show exclusivo em Las Vegas;
uma cobertura em Dubai;
um influencer experimentando frutas que jamais chegarão ao supermercado da sua cidade.

A comparação deixou de ser local.

Ela se tornou global.

O Mainframe da Mente

Se fôssemos desenhar isso como uma arquitetura IBM Z, teríamos algo parecido:

Instagram
TikTok
YouTube
Facebook
LinkedIn
Threads
Pinterest
          │
          ▼
  Algoritmos de Recomendação
          │
          ▼
 Sistema Límbico
          │
          ▼
Comparação Social
          │
          ▼
Emoções
          │
          ▼
Decisões Financeiras
Relacionamentos
Saúde Mental
Autoestima

O problema?

Nosso hardware biológico nunca foi atualizado para esse volume de entrada.

A Teoria da Comparação Social (Leon Festinger)

Em 1954, Leon Festinger propôs a Teoria da Comparação Social.

Segundo ela, avaliamos nosso próprio valor comparando-nos com outras pessoas.

Isso era extremamente útil em pequenas comunidades.

Hoje, entretanto, o algoritmo nos faz comparar nossa vida comum com os momentos mais extraordinários de milhões de desconhecidos.

Estamos comparando nossos bastidores com o palco dos outros.

Privação Relativa

A sociologia chama isso de Privação Relativa.

Curiosamente, uma pessoa pode estar objetivamente melhor do que estava há dez anos e, ainda assim, sentir-se mais pobre.

Por quê?

Porque sua referência mudou.

Antes:

"Tenho uma casa."

Hoje:

"Tenho uma casa... mas aquele influencer tem uma mansão."

A riqueza percebida diminui mesmo quando a riqueza real aumenta.

O Consumo Conspícuo (Thorstein Veblen)

O economista Thorstein Veblen descreveu o Consumo Conspícuo.

Pessoas compram determinados produtos não apenas pela utilidade.

Compram para comunicar posição social.

Um relógio de luxo marca as horas exatamente como um relógio simples.

Mas apenas um comunica status.

As redes sociais transformaram esse comportamento em espetáculo permanente.

O Capital Cultural (Pierre Bourdieu)

Pierre Bourdieu mostrou que riqueza não é apenas dinheiro.

Também existe:

capital cultural;
capital social;
capital simbólico.

Hoje vemos isso diariamente.

Alguém posta:

o vinho raro;
o restaurante exclusivo;
a viagem "autêntica";
o show VIP;
a universidade famosa;
a conferência internacional.

Nem sempre é ostentação financeira.

Muitas vezes é ostentação cultural.

A Pirâmide de Maslow Revisitada

Maslow imaginava uma sequência:

necessidades básicas;
segurança;
pertencimento;
estima;
autorrealização.

As redes sociais embaralharam essa ordem.

Muitas pessoas sacrificam:

descanso;
alimentação;
saúde financeira;

para manter uma aparência de pertencimento digital.

A Economia da Atenção

Hoje, o produto não é o vídeo.

Não é a fotografia.

Não é o post.

O produto é a atenção humana.

Quanto mais tempo você permanece olhando para a tela, maior o faturamento das plataformas.

E existe um detalhe importante.

Os algoritmos não foram programados para deixá-lo feliz.

Foram programados para mantê-lo conectado.

Existe uma diferença enorme entre essas duas coisas.

O Viés da Disponibilidade

Outro conceito importante da psicologia é o Viés da Disponibilidade.

Nosso cérebro tende a acreditar que aquilo que vê repetidamente é comum.

Se todos os dias aparecem Ferraris, iates e hotéis de luxo no feed, cria-se a falsa impressão de que esse estilo de vida é frequente.

Na realidade, trata-se de uma pequena parcela da população, amplificada por algoritmos.

A Adaptação Hedônica

A psicologia também descreve a Adaptação Hedônica.

Depois de conquistar algo desejado, rapidamente nos acostumamos.

Logo surge um novo objetivo.

Novo celular.

Novo carro.

Nova viagem.

Nova casa.

Nunca parece suficiente.

O feed acelera esse ciclo infinitamente.

O FOMO

Fear Of Missing Out.

Ou simplesmente FOMO.

O medo constante de estar perdendo alguma experiência.

Enquanto você trabalha...

Alguém está viajando.

Enquanto você estuda...

Alguém está em um festival.

Enquanto você economiza...

Alguém publica um relógio de R$ 500 mil.

O resultado é ansiedade permanente.

A Curadoria da Vida

Pouquíssimas pessoas publicam:

a dívida;
o divórcio;
o desemprego;
a insônia;
a depressão;
o medo.

Mas publicam:

o prêmio;
a promoção;
a viagem;
o casamento;
a compra.

Consumimos diariamente uma coleção dos melhores momentos da vida alheia.

E, sem perceber, usamos isso como referência para avaliar nossa vida inteira.

O Impacto na Democracia

Quando milhões de pessoas acreditam que nunca alcançarão o padrão exibido diariamente, cresce o sentimento de injustiça.

Isso pode favorecer:

polarização;
descrença nas instituições;
discursos radicais;
busca por soluções simples para problemas complexos.

Não é apenas economia.

É percepção.

Sociedades permanecem estáveis quando as pessoas acreditam que existe mobilidade.

Quando essa esperança desaparece, aumenta a tensão social.

O Paradoxo da Tecnologia

A mesma tecnologia que aumenta a comparação também democratiza oportunidades.

Nunca foi tão fácil aprender.

Um estudante brasileiro pode acessar gratuitamente:

Harvard;
MIT;
Stanford;
cursos de programação;
museus virtuais;
bibliotecas digitais;
artigos científicos;
comunidades técnicas.

A internet amplia desigualdades de visibilidade, mas também reduz barreiras ao conhecimento.

O desafio é transformar informação em oportunidade real.

O Que Podemos Aprender com o Mainframe?

No IBM Z existe um conceito fundamental.

Prioridade.

Nem toda carga recebe o mesmo tratamento.

O WLM (Workload Manager) distribui recursos de acordo com a importância de cada serviço.

Talvez devêssemos fazer o mesmo com nossa atenção.

Nem toda informação merece CPU.

Nem toda postagem merece memória.

Nem toda comparação merece processamento.

Nosso cérebro precisa de um "Workload Manager" pessoal.

Caminhos para o Futuro

Como indivíduos:

desenvolver alfabetização digital e emocional;
compreender como algoritmos influenciam escolhas;
praticar consumo consciente de redes sociais;
valorizar relações reais e comunidades locais;
investir mais em conhecimento do que em aparência.

Como empresas:

adotar métricas de bem-estar, não apenas de engajamento;
tornar algoritmos mais transparentes;
reduzir incentivos à desinformação e ao conteúdo exclusivamente sensacionalista.

Como governos e escolas:

incluir educação midiática e pensamento crítico desde cedo;
incentivar pesquisa sobre impactos da economia da atenção;
promover inclusão digital com foco em capacitação, não apenas em acesso.

Como sociedade:

redefinir sucesso para além da ostentação;
reconhecer diferentes formas de riqueza: tempo, saúde, conhecimento, comunidade e propósito.

Conclusão

No Mainframe aprendemos que um sistema saudável não é aquele que processa o maior número possível de requisições.

É aquele que processa as requisições certas, com estabilidade, segurança e equilíbrio.

Talvez a sociedade precise seguir a mesma lógica.

A tecnologia continuará evoluindo.

A Inteligência Artificial criará imagens perfeitas.

Vídeos indistinguíveis da realidade.

Influenciadores virtuais.

Experiências sintéticas.

Mundos digitais praticamente ilimitados.

Mas nenhuma inovação resolverá um problema essencial:

o ser humano continuará precisando distinguir entre inspiração e comparação, entre aprendizado e ostentação, entre conexão e dependência.

Assim como um Sysprog monitora continuamente os recursos de um IBM Z para evitar gargalos, cada um de nós precisará aprender a monitorar o recurso mais valioso da era digital: a própria atenção.

Porque, no fim, quem controla sua atenção controla suas escolhas.

E quem controla suas escolhas ajuda a definir o futuro da sociedade.

quarta-feira, 25 de janeiro de 2023

COBOL Recursivo — Muito Além do Fatorial: A Engenharia Invisível da Pilha de Execução no IBM Z - Parte I

Bellacosa Mainframe apresenta o cobol recursivo parte i

☕ Um Café no Bellacosa Mainframe

COBOL Recursivo — Muito Além do Fatorial: A Engenharia Invisível da Pilha de Execução no IBM Z

"Você provavelmente passará a carreira inteira escrevendo sistemas COBOL sem precisar desenvolver um programa recursivo. Ainda assim, compreender recursividade talvez seja uma das melhores formas de entender como o Enterprise COBOL realmente funciona por dentro."

Introdução

Existe um fenômeno curioso no universo do desenvolvimento Mainframe.

Pergunte para cem programadores COBOL se eles já utilizaram um programa recursivo em produção.

Talvez apenas cinco levantem a mão.

Pergunte agora se eles sabem exatamente como funciona um CALL, como o compilador cria uma nova instância do programa, o que acontece com a Working-Storage, como a pilha de execução (Call Stack) é organizada pelo Language Environment (LE) e por que existe a Local-Storage Section.

Muito provavelmente o número continuará sendo pequeno.

E esse é justamente o paradoxo.

Embora a recursividade seja pouco utilizada nos sistemas corporativos tradicionais, ela revela alguns dos conceitos mais importantes da arquitetura do COBOL moderno.

Ela nos obriga a abandonar a visão simplificada de que um programa é apenas uma sequência de comandos e nos faz enxergar aquilo que realmente está acontecendo:

memória;
pilha de execução;
contexto de chamadas;
passagem de parâmetros;
gerenciamento de variáveis;
criação e destruição de ambientes de execução.

Em outras palavras...

Recursividade não é apenas um algoritmo.

É uma janela para entender como o próprio Enterprise COBOL foi construído.

Prepare seu café.

Hoje vamos abrir a tampa do compilador.

O mito da recursividade em COBOL

Existe uma frase repetida há décadas.

"COBOL não foi feito para recursividade."

Essa afirmação está apenas parcialmente correta.

O COBOL clássico da década de 1960 realmente não possuía suporte adequado para chamadas recursivas.

Naquela época, memória era extremamente cara.

Processadores trabalhavam com poucos kilobytes.

Cada instrução era planejada para consumir o mínimo possível.

O objetivo principal do COBOL era simples:

ler registros;
processar registros;
gravar registros.

Tudo de forma linear.

Imagine um processamento bancário.

READ

↓

VALIDA

↓

CALCULA

↓

UPDATE

↓

WRITE

↓

READ

Milhões de vezes.

Sem árvores.

Sem grafos.

Sem estruturas hierárquicas.

Sem necessidade de chamar o mesmo programa novamente.

A arquitetura inteira do COBOL nasceu voltada para processamento sequencial.

Então por que o COBOL moderno suporta recursividade?

Porque o mundo mudou.

Hoje o Enterprise COBOL conversa diariamente com:

XML
JSON
REST APIs
C
C++
Java
Assembler
Language Environment
Web Services
z/OS Connect
IBM MQ

E todos esses ambientes trabalham intensamente com estruturas hierárquicas.

Uma árvore XML, por exemplo, é naturalmente recursiva.

<empresa>

    <departamento>

        <funcionario>

            <dependente/>

        </funcionario>

    </departamento>

</empresa>

Cada elemento pode conter outros elementos.

Não existe limite teórico.

A melhor maneira de percorrer isso?

Recursão.

O verdadeiro significado de um programa recursivo

Quando um Padawan ouve falar em recursividade, normalmente pensa:

"É quando um programa chama ele mesmo."

Tecnicamente isso está correto.

Mas essa definição é superficial.

O que realmente acontece é isto:

Cada chamada cria um novo ambiente completo de execução.

Isso muda completamente nossa visão.

Imagine uma rotina simples.

PROCESSA(5)

Ela chama:

PROCESSA(4)

Que chama:

PROCESSA(3)

Que chama:

PROCESSA(2)

Que chama:

PROCESSA(1)

Visualmente:

PROCESSA(5)

↓

PROCESSA(4)

↓

PROCESSA(3)

↓

PROCESSA(2)

↓

PROCESSA(1)

Não existe apenas um programa funcionando.

Existem cinco instâncias simultâneas do mesmo programa.

Cada uma em um estágio diferente da execução.

Esse conceito é fundamental.

A grande mágica acontece na pilha (Stack)

Sempre que uma chamada ocorre, o Language Environment cria um novo frame.

Pense na pilha como uma torre de caixas.

+----------------------+
| PROCESSA(1)          |
+----------------------+
| PROCESSA(2)          |
+----------------------+
| PROCESSA(3)          |
+----------------------+
| PROCESSA(4)          |
+----------------------+
| PROCESSA(5)          |
+----------------------+

Cada caixa contém:

parâmetros;
registradores;
endereço de retorno;
variáveis locais;
contexto da execução.

Quando PROCESSA(1) termina:

a caixa é removida.

Depois PROCESSA(2).

Depois PROCESSA(3).

Até voltar ao programa original.

Essa estrutura recebe o nome de Call Stack.

Todo programador deveria conhecê-la.

Mesmo que nunca escreva um algoritmo recursivo.

A pilha sempre existiu

Existe outro detalhe curioso.

Mesmo programas totalmente lineares utilizam pilha.

Por exemplo.

Programa A.

CALL B

Programa B.

CALL C

Programa C.

CALL D

Visualmente:

A

↓

B

↓

C

↓

D

O sistema operacional precisa lembrar para onde voltar.

Então cria uma pilha.

+-----------+
| D         |
+-----------+
| C         |
+-----------+
| B         |
+-----------+
| A         |
+-----------+

Perceba algo interessante.

A recursividade apenas repete esse processo.

A diferença é que quem aparece novamente é o mesmo programa.

O compilador não tem medo disso

Muitos imaginam que o compilador "fica confuso".

Na realidade...

Para ele não faz diferença.

Ele apenas cria outra instância.

Depois outra.

Até encontrar a condição de parada.

O maior perigo da recursividade

Imagine o seguinte pseudocódigo.

PROCESSA

↓

PROCESSA

↓

PROCESSA

↓

PROCESSA

↓

PROCESSA

↓

PROCESSA

E nunca para.

O que acontece?

A pilha cresce.

+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+
| PROCESSA       |
+----------------+

Cada chamada ocupa memória.

Mais cedo ou mais tarde...

Não haverá mais espaço.

Resultado:

Stack Overflow.

Em ambientes z/OS isso normalmente termina em um abend relacionado ao esgotamento da pilha ou da região disponível para a tarefa.

Por isso existe uma regra absoluta.

Toda recursão precisa possuir uma condição de parada.

Sem exceções.

O conceito mais importante para um Padawan

Existe um exercício mental muito útil.

Imagine cinco cópias do mesmo programa.

Não uma.

Cinco.

Cada uma com seus próprios parâmetros.

Cada uma em um ponto diferente da execução.

É exatamente isso que a recursividade produz.

Ela não "volta para o começo".

Ela cria outra execução.

Depois outra.

Essa mudança de mentalidade faz toda diferença.

RECURSIVE x NON-RECURSIVE

O Enterprise COBOL precisa saber antecipadamente se um programa poderá chamar a si mesmo.

Por quê?

Porque isso muda completamente a estratégia de gerenciamento de memória.

Um programa tradicional pressupõe que existe apenas uma instância ativa.

Já um programa recursivo pode possuir dezenas ou centenas de ativações simultâneas.

É como comparar um apartamento ocupado por uma família com um hotel onde vários hóspedes utilizam quartos iguais ao mesmo tempo.

A estrutura física é parecida.

A forma de administrar os recursos é completamente diferente.

O papel do compilador

Quando um programa é preparado para suportar recursividade, o compilador gera código considerando que cada ativação precisará preservar seu próprio contexto.

Isso inclui:

parâmetros recebidos;
endereço de retorno;
variáveis locais;
registradores utilizados;
informações necessárias para retomar a execução exatamente do ponto em que foi interrompida.

Essa organização é uma das responsabilidades compartilhadas entre o Enterprise COBOL e o Language Environment (LE).

O maior erro de iniciantes

Existe um erro extremamente comum.

O desenvolvedor escreve:

WORKING-STORAGE SECTION.

01 WS-CONTADOR PIC 9(4).

Depois cria um algoritmo recursivo.

Na primeira chamada:

WS-CONTADOR = 1

Na segunda:

WS-CONTADOR = 2

Na terceira:

WS-CONTADOR = 3

Quando retorna...

O conteúdo foi alterado por outra ativação.

A lógica começa a produzir resultados inesperados.

O motivo?

Todas as ativações estão compartilhando a mesma Working-Storage.

Esse é um dos primeiros conceitos que todo Padawan precisa dominar.

Working-Storage: a memória compartilhada

A Working-Storage Section existe durante praticamente toda a vida do programa.

Ela é excelente para:

constantes;
tabelas fixas;
áreas de trabalho;
buffers reutilizados;
indicadores globais;
variáveis de controle que realmente precisam ser compartilhadas.

Mas ela não foi pensada para armazenar o estado individual de cada chamada recursiva.

Imagine uma lousa em uma sala de reunião.

Todos escrevem na mesma superfície.

O último a apagar ou sobrescrever vence.

É exatamente esse comportamento que pode ocorrer quando um programa recursivo utiliza Working-Storage para guardar informações específicas de cada ativação.

Local-Storage: a grande aliada da recursão

Foi justamente para resolver esse problema que surgiu a Local-Storage Section.

Ao contrário da Working-Storage, ela é criada novamente para cada ativação do programa.

Voltando ao exemplo da pilha:

+----------------------+
| PROCESSA(1)          |
| LOCAL-STORAGE        |
+----------------------+
| PROCESSA(2)          |
| LOCAL-STORAGE        |
+----------------------+
| PROCESSA(3)          |
| LOCAL-STORAGE        |
+----------------------+

Cada chamada possui sua própria cópia das variáveis locais.

Uma alteração realizada em uma ativação não interfere nas demais.

Esse comportamento torna a Local-Storage a escolha natural para programas recursivos e também para rotinas reentrantes e altamente concorrentes.

Uma analogia para nunca mais esquecer

Imagine uma cozinha industrial.

A Working-Storage seria uma única bancada compartilhada por todos os cozinheiros. Se um chef espalha farinha, outro pode encontrar essa farinha antes de começar sua própria receita.

A Local-Storage, por outro lado, funciona como uma bancada individual entregue a cada cozinheiro no início do trabalho. Cada um organiza seus ingredientes, prepara sua receita e, ao terminar, aquela bancada é desmontada sem afetar os demais.

Essa simples analogia ajuda a entender por que tantos problemas em programas recursivos desaparecem quando o estado da execução deixa de ser compartilhado e passa a ser local.

Conclusão da Parte 1

Ao ouvir a palavra recursividade, muitos programadores pensam imediatamente em exercícios acadêmicos como fatorial ou sequência de Fibonacci. No entanto, para quem trabalha com IBM Z, esse é apenas um detalhe.

O verdadeiro valor da recursão está em revelar como o Enterprise COBOL administra memória, organiza a pilha de execução, preserva contextos de chamadas e separa dados compartilhados de dados locais.

Mais do que aprender um algoritmo, estudar programas recursivos significa compreender os bastidores da linguagem — uma compreensão que será útil mesmo em projetos onde nenhuma rotina recursiva seja escrita.

No próximo café, vamos construir um programa recursivo completo em Enterprise COBOL, acompanhar cada chamada passo a passo dentro da pilha de execução, comparar sua execução com uma solução iterativa e descobrir em quais situações a recursão realmente se torna a melhor ferramenta para um desenvolvedor Mainframe.

Na Parte 2, aprofundaremos com código COBOL completo e comentado, execução passo a passo da pilha (stack), exemplos de fatorial, Fibonacci, árvores, XML/JSON, busca em diretórios, algoritmos clássicos (DFS, QuickSort e MergeSort) e diagramas de memória mostrando exatamente o que acontece a cada chamada recursiva.

terça-feira, 24 de janeiro de 2023

Beast Tamer - EXPULSO DA PARTY, ABSURDAMENTE OVERPOWER E COM WAIFUS FELINAS: O ANIME QUE VIROU O “JCL DO ISEKAI”!

Bellacosa Mainframe analise o anime Beast Tamer

EXPULSO DA PARTY, ABSURDAMENTE OVERPOWER E COM WAIFUS FELINAS: O ANIME QUE VIROU O “JCL DO ISEKAI”!

Se existe um gênero que domina o mundo dos animes modernos do mesmo jeito que COBOL domina o core bancário, é o famoso:

“Você me expulsou? Então vou virar absurdamente poderoso enquanto vocês quebram em produção.”

E poucos animes representam isso tão bem quanto:

Yuusha Party wo Tsuihou sareta Beast Tamer, Saikyoushu no Nekomimi Shoujo to Deau
ou simplesmente:

Beast Tamer

Um anime que mistura:

fantasia medieval,
protagonista injustiçado,
crescimento absurdo de poder,
garotas “ultimate species”,
guildas,
magia,
e aquele clássico sentimento:

“O time caiu porque mandou embora o cara certo.”

Sim… praticamente um paralelo perfeito com muito ambiente mainframe corporativo.

O QUE SIGNIFICA O TÍTULO?

O nome gigantesco traduzido fica mais ou menos assim:

“O Beast Tamer Expulso da Party do Herói Encontra uma Garota Gato da Raça Suprema”

E sinceramente?

Isso resume 90% do anime.

Mas também revela algo importante sobre a indústria moderna:
os títulos de light novel viraram praticamente um dump de SYSOUT explicando a aplicação inteira antes mesmo do IPL.

DATA DE LANÇAMENTO

Light Novel

Início: 11 de junho de 2018

Mangá

Início: 30 de janeiro de 2019

Anime

Estreia: 1 de outubro de 2022
Episódios: 13

AUTOR E PRODUÇÃO

Autor

Suzu Miyama

Criador da light novel original.

Ilustradores

Hotosoka/Subachi (volumes iniciais)
Nozomi (volumes posteriores)

Estúdio

EMT Squared

Mesmo estúdio de:

Kuma Kuma Kuma Bear
Assassins Pride
I’m Quitting Heroing

RESUMO DA HISTÓRIA

O protagonista:

Rein Shroud

é um Beast Tamer que fazia parte da party do herói.

O problema?

A party inteira acreditava que ele era inútil.

Porque ele:

não dava dano absurdo,
não explodia montanhas,
não soltava Hadouken mágico,
e trabalhava mais no suporte/logística.

Ou seja:
o clássico profissional invisível da TI.

Até que um dia:

“Você só brinca com animais. Está demitido.”

E ele é expulso da equipe.

Só que a party não percebeu um detalhe IMPORTANTÍSSIMO:

Rein era o cara que sustentava toda a operação.

Exatamente igual:

operador de mainframe,
sysprog,
especialista em JES2,
DBA DB2,
ou aquele cara do batch noturno que ninguém valoriza.

Quando ele sai…

o ambiente começa a colapsar.

Enquanto isso, Rein encontra:

Kanade

uma garota-gato da “Ultimate Species”.

E a partir daí:
o anime vira uma mistura de:

evolução de poder,
aventura,
fantasia,
harém leve,
e revenge story corporativa.

PRINCIPAIS PERSONAGENS

Rein Shroud

O protagonista.

No começo parece fraco.

Mas isso é pura ilusão operacional.

Rein é:

estrategista,
suporte,
buffer,
summoner,
controlador,
e escalador absurdo de poder.

Quanto mais contratos ele faz com espécies supremas:
mais overpower ele fica.

Ele representa perfeitamente:

“O profissional subestimado que carregava a empresa inteira.”

Kanade

A famosa nekomimi.

Ela pertence à raça dos gatos — uma das “Ultimate Species”.

Características:

força absurda,
velocidade monstruosa,
carisma gigantesco,
e energia caótica de mascote oficial do anime.

Kanade é basicamente:

um CICS hiper otimizado com orelhinhas de gato.

Tania

A dragon girl.

Chega desafiando Rein para combate.
Perde.
Vira aliada.

O clássico fluxo shounen.

Ela aumenta brutalmente o poder mágico de Rein.

Sora e Luna

As gêmeas fada.

Uma mais calma.
Outra mais travessa.

Aqui o anime começa a acelerar o fator:

“party overpower”,
“família encontrada”,
e “coleção de personagens ultra apelonas”.

Arios Orlando

O herói.

E provavelmente:
um dos personagens MAIS ODIADOS do anime.

Porque ele representa:

arrogância,
incompetência gerencial,
ego corporativo,
e incapacidade de reconhecer talento.

Ele literalmente desmonta a própria equipe por ego.

O GRANDE TEMA DO ANIME

Muita gente acha que Beast Tamer é só:

ecchi leve,
waifu collection,
fantasy genérico.

Mas existe um tema muito forte aqui:

VALORIZAÇÃO INVISÍVEL

O anime inteiro gira em torno disso.

Rein nunca foi “fraco”.

Ele só fazia:

tarefas invisíveis,
suporte,
sincronização,
logística,
estabilidade.

Até que ele saiu.

E então:
a party do herói entra em degradação operacional.

Isso é MUITO mainframe.

Porque:

ninguém lembra do batch quando funciona,
ninguém lembra do storage,
ninguém lembra do scheduler,
ninguém lembra do RACF.

Mas quando cai…

o caos começa.

CURIOSIDADES ABSURDAMENTE INTERESSANTES

1. O anime surfou a onda do “banished from hero party”

Nos últimos anos surgiu um subgênero inteiro:

protagonista expulso,
depois fica overpower,
enquanto os antigos colegas afundam.

Beast Tamer virou um dos exemplos mais populares dessa fórmula.

2. Rein é MUITO mais forte que um Beast Tamer normal

O anime vai revelando aos poucos que:
ele é uma anomalia completa.

Ele consegue:

múltiplos contratos,
compartilhamento de habilidades,
buffs absurdos,
e crescimento exponencial.

Na prática:
ele é quase um “admin root” do sistema de contratos.

3. O herói é praticamente um vilão

Isso quebra um pouco a expectativa clássica de fantasia.

Arios:

manipula,
trai,
enlouquece pelo ego,
e afunda moralmente.

É quase um estudo sobre:

liderança incompetente destruindo equipes técnicas.

4. A opening é MUITO energética

“Change The World” do MADKID virou uma das marcas do anime.

Ela passa exatamente a sensação:

aventura,
liberdade,
crescimento,
e “agora vou provar meu valor”.

EASTER EGGS E DETALHES ESCONDIDOS

O simbolismo das “Ultimate Species”

Cada garota representa um tipo de poder:

força,
magia,
velocidade,
ilusão,
resistência,
poder divino.

Rein funciona quase como:
um “integrador de sistemas”.

Ele conecta diferentes “módulos” e cria uma arquitetura absurda.

Sim.
O cara praticamente virou um z/OS humano.

O anime inverte o trope clássico do herói

Normalmente:
o herói é o protagonista moral.

Aqui:
o “suporte demitido” é o verdadeiro coração da obra.

A narrativa inteira questiona:

meritocracia superficial,
liderança arrogante,
e julgamento baseado só em aparência de poder.

O colapso da Hero Party lembra incidentes corporativos reais

Sem brincadeira:
a degradação da equipe após a saída do Rein parece:

perda de conhecimento institucional,
ausência de documentação,
dependência de especialista,
turnover crítico em TI.

É praticamente:

“o sysprog pediu demissão e ninguém sabia o que ele fazia.”

O ANIME É BOM?

Depende do que você procura.

Se quiser:

filosofia profunda estilo Monster,
política complexa,
roteiro ultra sofisticado…

não é isso.

Mas se quiser:

diversão,
fantasia confortável,
protagonista overpower,
personagens carismáticos,
sensação de evolução constante,
e revenge fantasy extremamente satisfatória…

Beast Tamer entrega MUITO bem.

ANÁLISE BELLACOSA MAINFRAME

Rein é o operador invisível do ambiente

Ele:

não aparece,
não recebe crédito,
ninguém entende o que faz,
mas sustenta tudo.

Até que removem ele.

Resultado?

ABEND organizacional.

Arios é o gerente que destrói o time técnico

Ele olha só:

para output imediato,
para glamour,
para ego.

E ignora:

estabilidade,
suporte,
arquitetura,
integração.

O resultado é inevitável:
colapso operacional.

CONCLUSÃO

Yuusha Party wo Tsuihou sareta Beast Tamer parece apenas mais um fantasy genérico.

Mas no fundo:
é uma história sobre:

reconhecimento,
competência invisível,
equipes disfuncionais,
e crescimento pessoal.

Tudo embalado com:

waifus felinas,
dragões,
magia,
porradaria,
e um protagonista absurdamente roubado.

E sinceramente?

Para quem trabalha em tecnologia…

é impossível NÃO olhar para Rein e pensar:

“Esse cara era o único que sabia manter o ambiente em pé.” 🔥

segunda-feira, 23 de janeiro de 2023

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

Bellacosa Mainframe apresente o orquestrador de atualizaçõs no Z/OS

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

Se você é um dev COBOL sênior, já escreveu milhares de linhas, já enfrentou abends misteriosos, já discutiu copybook em reunião… mas existe uma verdade silenciosa:

Quem realmente controla o seu ambiente não é o COBOL. É o SMP/E.

E se você nunca mergulhou fundo nele… você está dirigindo um Ferrari com os olhos vendados.

🏛️ Origem: Quando instalar software virou um problema sério

Nos primórdios do mainframe:

Software era entregue em fitas físicas
Instalação era manual
Dependências? 😅 Boa sorte…

Foi aí que a IBM criou o:

👉 SMP (System Modification Program)
E depois evoluiu para o SMP/E (Extended)

💥 O objetivo:

Transformar o caos de instalação em um processo controlado, auditável e reversível

🧩 O mundo real: o que você usa… sem perceber

Você roda:

COBOL ✔
CICS ✔
DB2 ✔
REXX ✔
ISPF ✔

Mas tudo isso chegou ao sistema via:

👉 SMP/E

📦 O conceito mais importante: SYSMOD

Tudo no SMP/E gira em torno de:

👉 SYSMOD (System Modification)

Tipos:

FMID → Produto base
PTF → Fix oficial
APAR → Fix temporário
USERMOD → Customização

💥 Regra de ouro:

Se modifica algo → depende de um FMID

🧠 Easter Egg #1 (prova e vida real)

APAR não é elemento — é SYSMOD
(essa derruba muita gente 😄)

🧱 Elementos: o que realmente vai pro sistema

Um SYSMOD é composto por:

MOD → executável
SRC → source
MAC → macro
JAR / zFS → mundo UNIX
Panels / REXX / CLIST

💥 Tradução COBOL:

Seu load module veio de um MOD, que veio de um SRC, controlado pelo SMP/E

📀 RELFILE: o “pacote de entrega”

Antes do APPLY, existe o pacote:

👉 RELFILE

Hoje:

Download via internet

Antes:

📼 Fita magnética

Dentro dele:

MCS (metadados)
Elementos do software

⚙️ O pipeline sagrado do SMP/E

Aqui está o coração da operação:


RECEIVE → APPLY → ACCEPT

📥 RECEIVE (entrada no sistema)

Carrega RELFILE
Atualiza GLOBAL ZONE
Prepara staging

👉 Ainda não instala nada

⚙️ APPLY (instalação real)

Copia elementos para TARGET LIBRARIES
Atualiza TARGET ZONE

👉 Agora o software roda

✅ ACCEPT (consolidação)

Copia para DISTRIBUTION LIBRARIES
Atualiza DLIB ZONE

👉 Vira baseline

🧠 Easter Egg #2 (nível prova)


RECEIVE → GLOBAL
APPLY   → TARGET
ACCEPT  → DLIB

Se decorar isso → passa em qualquer prova 😎

🗃️ CSI: o cérebro do SMP/E

👉 CSI (Consolidated Software Inventory)

Baseado em VSAM KSDS

Guarda:

Versões
Dependências
Elementos
Histórico

💥 É o “CMDB raiz” do mainframe

🧠 Curiosidade forte

Um CSI pode controlar vários produtos ao mesmo tempo

⚠️ O pulo do gato: dependências

Antes de instalar:

Prerequisite (PRE) → precisa antes
Corequisite (CO) → precisa junto

👉 SMP/E valida automaticamente

🧠 Easter Egg #3

SMP/E pode:

✔ Instalar dependências
✔ Cancelar instalação

Mas nunca:

❌ Instalar versão mais antiga sobre nova
❌ Desinstalar arbitrariamente

🔥 Insight de produção

SMP/E não é apt-get
SMP/E é governança

🏭 Exemplo real (modo Bellacosa)

Você precisa aplicar um fix no CICS:

Recebe PTF
SMP/E verifica:
- FMID correto
- PRE/CO ok
APPLY:
- Atualiza loadlibs
Testa em ambiente
ACCEPT:
- Consolida baseline

⚠️ Prática avançada (ouro)

👉 Nunca dê ACCEPT imediatamente

Porque:

APPLY = reversível
ACCEPT = compromisso

🧠 Easter Egg #4 (experiência real)

Erro clássico:


GIMxxxx

👉 80% das vezes:

FMID errado
Dependência faltando
CSI inconsistente

🔌 Interfaces SMP/E

Você pode usar:

ISPF
Batch (JCL)
API

💥 Sim — SMP/E pode ser automatizado

🚀 SMP/E no mundo DevOps

Tradução moderna:

DevOps	SMP/E
Pipeline	RECEIVE/APPLY/ACCEPT
Deploy	APPLY
Promote	ACCEPT
Artifact	RELFILE

🧠 Easter Egg final

O mainframe já fazia DevOps… antes de ser moda.

🎯 Conclusão

Se você escreve COBOL e ignora SMP/E:

👉 Você domina a aplicação
👉 Mas não domina o ambiente

🔥 Frase final (pra guardar)

COBOL escreve o sistema.
SMP/E garante que ele exista.

domingo, 22 de janeiro de 2023

Os Holocrons Esquecidos do Tratamento de Erros no IBM Z – O Despertar das DECLARATIVES - EXCEPTION/ERROR Procedures em COBOL: Parte I

Bellacosa Mainframe e o tratamento de erro no Cobol Parte 1

EXCEPTION/ERROR Procedures em COBOL: Os Holocrons Esquecidos do Tratamento de Erros no IBM Z

Parte 1 – O Despertar das DECLARATIVES

Quando o Padawan Descobre que COBOL Possui Seu Próprio Mecanismo Jedi de Tratamento de Erros

Por Bellacosa Mainframe

"Todo Padawan aprende FILE STATUS. Alguns aprendem AT END. Pouquíssimos descobrem que COBOL possui um mecanismo ancestral capaz de interceptar falhas antes que elas se transformem em um ABEND às três da manhã."
Mestre Bellacosa Sysprog Jedi

Introdução

Existe um momento na vida de praticamente todo desenvolvedor COBOL em que ele acredita ter dominado completamente o tratamento de erros.

Ele aprendeu:

FILE STATUS.

Aprendeu:

AT END

Aprendeu:

INVALID KEY

Aprendeu:

ON EXCEPTION

Aprendeu:

ON SIZE ERROR

E então pensa:

Mestre...
Acho que já sei tudo sobre tratamento de erros em COBOL.

O mestre Bellacosa sorri.

Abre um velho manual ANSI COBOL.

Mostra algumas linhas quase esquecidas.

E pergunta:

DECLARATIVES.

ARQ-ERROR SECTION.

USE AFTER STANDARD ERROR PROCEDURE ON ARQUIVO1.

O jovem Padawan arregala os olhos.

O que é isso?

O mestre responde:

Jovem Padawan...
Você acaba de encontrar um dos Holocrons mais antigos e menos estudados do COBOL.

O Grande Mito

Existe um mito bastante difundido.

Muitos acreditam:

COBOL não possui tratamento centralizado de erros.

Na verdade possui.

Há décadas.

E ele atende pelo nome:

DECLARATIVES

O que são DECLARATIVES?

Declaratives são blocos especiais.

São definidos antes da PROCEDURE DIVISION.

Possuem finalidade específica.

Capturar condições excepcionais.

Visualmente.

Programa COBOL


↓

Erro


↓

DECLARATIVES


↓

Tratamento


↓

Continua

ou

Termina

É quase um ancestral dos modernos:

try
catch
exception handler
interceptor
middleware de erros

Quando surgiu?

Precisamos voltar bastante no tempo.

COBOL-68

Possuía capacidades limitadas.

ANSI COBOL 74

Introduziu mecanismos iniciais.

ANSI COBOL 85

Consolidou.

DECLARATIVES.

USE.

Error Procedures.

IBM manteve suporte.

VS COBOL II.

COBOL for MVS.

Enterprise COBOL.

COBOL 6.5.

Sim.

Em 2026.

Ainda funciona.

Por que quase ninguém usa?

Porque a maioria dos programadores aprende.

FILE STATUS.

INVALID KEY.

AT END.

E para por aí.

As Declaratives ficaram escondidas.

Por décadas.

Muitos profissionais com vinte anos de experiência.

Nunca escreveram uma.

Anatomia das Declaratives

Estrutura.

DECLARATIVES.

ERRO-ARQ SECTION.

USE AFTER STANDARD ERROR PROCEDURE
ON ARQCLIENTE.

TRATA-ERRO.

DISPLAY 'ERRO'.

END DECLARATIVES.

Depois.

PROCEDURE DIVISION.

Muito importante.

Declaratives ficam.

Antes.

Da lógica principal.

O que significa USE?

USE é uma instrução especial.

Ela informa.

Ao runtime.

Quando determinada condição ocorrer.

Execute.

Este bloco.

Exemplo.

USE AFTER STANDARD ERROR PROCEDURE
ON CLIENTES.

Significa.

Se CLIENTES falhar.

Execute.

Esta rotina.

O que é STANDARD ERROR PROCEDURE?

Talvez seja a expressão mais misteriosa.

Significa.

Erros detectados.

Pelo sistema de I/O COBOL.

Exemplos.

OPEN

READ

WRITE

REWRITE

DELETE

START

Falhou.

Declaratives.

Recebem controle.

Primeiro exemplo do Padawan

Passo 1

Arquivo.

SELECT CLIENTE

ASSIGN TO ARQCLI

FILE STATUS WS-FS.

Passo 2

Status.

01 WS-FS.

PIC XX.

Passo 3

Declarative.

DECLARATIVES.


ARQ-ERRO SECTION.


USE AFTER STANDARD ERROR PROCEDURE


ON CLIENTE.


ARQ-ERRO-PROC.


DISPLAY 'ERRO'


WS-FS.


END DECLARATIVES.

Passo 4

Procedure.

PROCEDURE DIVISION.


OPEN INPUT CLIENTE.

Arquivo inexistente.

Declarative executa.

Muito elegante.

Fluxo interno

Visualmente.

OPEN


↓

Erro


↓

Runtime COBOL


↓

Declarative


↓

Retorna


ou


STOP RUN

Quase um middleware.

Memória

Padawan pergunta.

Mestre...
Como isso funciona na memória?

Boa pergunta.

Compilador.

Cria.

Tabelas internas.

Associa.

Arquivo.

↓

Rotina.

Quando erro.

Runtime.

Consulta.

Tabela.

Transfere.

Controle.

Visualmente.

Tabela


CLIENTE


↓

ARQ-ERRO

Sem overhead grande.

Muito eficiente.

Chamada automática

Importante.

Programador.

Não faz.

PERFORM ARQ-ERRO

Runtime.

Faz.

Automaticamente.

Quase.

Interrupção.

Controlada.

Pode haver vários?

Sim.

Exemplo.

CLIENTE


↓

DECL1



PEDIDO


↓

DECL2



ESTOQUE


↓

DECL3

Muito poderoso.

FILE STATUS versus DECLARATIVES

Muitos perguntam.

Qual melhor?

FILE STATUS

Explícito.

Exemplo.

OPEN INPUT ARQ.


IF WS-FS NOT = '00'

Vantagem.

Simples.

Problema.

Repete.

Muito.

DECLARATIVES.

Centralizado.

Muito elegante.

Grande volume.

Melhor.

INVALID KEY

Outra dúvida.

INVALID KEY.

Funciona.

Com VSAM.

Declarative.

Mais abrangente.

Pode capturar.

Vários erros.

Cuidados

Nem tudo.

São flores.

Primeiro.

Evitar.

Lógica complexa.

Dentro.

Declarative.

Segundo.

Não abrir.

Mesmo arquivo.

Novamente.

Terceiro.

Cuidado.

Loops.

Exemplo ruim.

Erro.

↓

Declarative.

↓

READ.

↓

Erro.

↓

Declarative.

↓

Loop.

Muito perigoso.

Performance

Excelente.

Quase.

Zero impacto.

Só executa.

Quando.

Erro.

Em produção.

Pouco custo.

Segurança

Pouco comentado.

Muito útil.

Auditoria.

Exemplo.

Registrar.

Arquivo.

Usuário.

Timestamp.

Erro.

Excelente.

Compliance.

LGPD.

SOX.

Auditoria.

Framework Bellacosa

Gosto bastante.

Modelo.

Declarative


↓

Logger


↓

Dataset LOG


↓

MQ


↓

Splunk


↓

Observabilidade

Muito elegante.

Curiosidades

Pouquíssimos desenvolvedores COBOL modernos.

Conhecem.

DECLARATIVES.

Muitos arquitetos bancários.

Adoram.

Principalmente.

Frameworks.

Antigos.

Curiosidade 2

VS COBOL II.

Utilizava.

Muito.

Hoje.

Menos comum.

Curiosidade 3

CICS.

Possui.

Algo semelhante.

HANDLE CONDITION.

Veremos.

Parte 3.

Bellacosa Best Practices

Sempre.

FILE STATUS.

Mesmo.

Com Declaratives.

Documente.

Tudo.

Não abuse.

Use.

Logging.

Padronize.

Framework.

Não coloque.

Regra negócio.

Somente.

Tratamento.

Erro.

O Conselho do Mestre Bellacosa

Durante décadas, milhares de programadores COBOL trataram erros utilizando IF FILE-STATUS, INVALID KEY e AT END.

E isso funciona muito bem.

Mas escondido nas profundezas dos antigos padrões ANSI existe um mecanismo sofisticado.

Elegante.

Pouco conhecido.

Quase esquecido.

Chamado DECLARATIVES.

Ele lembra uma antiga técnica Jedi.

Não é utilizada todos os dias.

Não é necessária para pequenos programas.

Mas quando um sistema possui dezenas de arquivos, centenas de jobs e requisitos rigorosos de auditoria, observabilidade e recuperação, ela pode transformar um emaranhado de verificações repetitivas em uma arquitetura limpa e centralizada.

Talvez esta seja a principal lição da primeira jornada.

O jovem Padawan verifica FILE STATUS.

O Cavaleiro utiliza ON EXCEPTION.

O Mestre Bellacosa conhece DECLARATIVES.

E o Conselho Jedi do IBM Z sabe exatamente quando utilizá-las.

Continua na Parte 2

O Padawan Aprende a Domar os Abends do Dataset – VSAM, KSDS, FILE STATUS 35/39/92/93, Retry, Logging e Frameworks Corporativos de Recuperação.

domingo, 15 de janeiro de 2023

🇯🇵 Estereótipos Regionais no Anime – quando o sotaque também conta história!

🇯🇵 Estereótipos Regionais no Anime – quando o sotaque também conta história!

Quem mergulha fundo no mundo dos animes logo percebe: nem todo japonês fala igual! E isso não é só detalhe — é roteiro cultural disfarçado de sotaque. O Japão, embora pequeno no mapa, é um mosaico de dialetos e temperos sociais. Cada região tem sua “personalidade”, e os animes amam exagerar isso pra dar cor, humor e identidade aos personagens. 🍱

🎙️ O sotaque que denuncia a alma: Kansai-ben

Se você já viu personagens que falam alto, piadistas e cheios de energia (tipo Osaka em Azumanga Daioh ou Satoru Gojo em certos momentos de Jujutsu Kaisen), bem-vindo ao Kansai-ben, o dialeto da região de Osaka e Kyoto.

Ele é o “carioquês” do Japão — divertido, informal, cheio de ritmo e expressões regionais.
👉 Normalmente indica um personagem:

extrovertido,
trapaceiro charmoso,
ou aquele “malandro de bom coração”.

Curiosidade Bellacosa: o stand-up japonês, o manzai, nasceu em Osaka — por isso o Kansai-ben virou sinônimo de humorista nato.

🍵 Kanto – o japonês “padrão”

A região de Kanto, onde fica Tóquio, é o equivalente ao nosso “português neutro de telejornal”. Quando você ouve aquele japonês limpinho, educado e formal, é Kanto puro.

Nos animes, personagens com esse jeito falam de forma direta e um tanto fria. Representam o urbanita racional, o “corporativo”, o “herói padrão de shonen”.

💼 Exemplo: Light Yagami (Death Note) é o estereótipo do estudante perfeito de Tóquio — formal, elegante e... perigosamente controlado.

⛩️ Kyoto – o sotaque nobre

Ah, o Kyoto-ben… é o dialeto dos templos, do chá e das gueixas.
Em animes, personagens que o usam costumam ser refinados, calmos e misteriosos. Falam de forma lenta e com muita cortesia, o que às vezes soa meio passivo-agressivo.

🎴 Personagens de Kyoto têm um ar antigo, quase espiritual — uma espécie de “nobreza disfarçada”.

🌾 Tohoku e Hokkaido – o campo e o frio

No norte do Japão, os dialetos são vistos como “rústicos” ou “do interior”. Quando aparece um personagem com sotaque forte de Tohoku ou Hokkaido, prepare-se para o arquétipo do ingênuo, puro ou trabalhador rural.

🐄 Costuma ser o amigo de infância, o cara do campo, ou a garota que se muda pra cidade grande com o coração aberto.
Nos animes de romance, esse contraste “cidade x interior” é clássico — uma metáfora do Japão moderno tentando não esquecer suas raízes.

🌋 Kyushu e Okinawa – o exótico e o rebelde

Os sotaques do sul, como Hakata-ben (Fukuoka) e Okinawa-ben, são pouco usados — mas quando aparecem, é pra dar força e identidade rebelde.
Personagens dessas regiões costumam ser calorosos, temperamentais e cheios de sotaques cantados.

🔥 Exemplo: em Barakamon, o protagonista vai parar numa ilha de Okinawa e descobre que “vida simples” é sinônimo de sabedoria local.

🗾 Por que isso importa?

Nos animes, o dialeto é um elemento narrativo. Ele informa de onde o personagem vem, o que valoriza e até como enxerga o mundo. É a “cor” invisível da fala — e os japoneses a percebem imediatamente.

Nós, ocidentais, perdemos esse detalhe nas legendas, mas saber disso faz toda a diferença pra entender o subtexto.
Quando alguém muda de dialeto em cena, é tão significativo quanto mudar de roupa ou de expressão.

💡 Dica Bellacosa para Padawans Otaku

Assista animes com áudio original e tente notar o ritmo e o tom de voz. Mesmo sem entender japonês, dá pra sentir a energia regional.
Quer um desafio? Compare o jeito de falar de personagens de Osomatsu-san (puro Kansai) com os de Your Name (Tokyo Kanto). É outro Japão! 🇯🇵

✨ Conclusão:
Os estereótipos regionais nos animes são mais do que sotaques engraçados — são retratos culturais, cheios de identidade, humor e emoção.
Eles revelam o quanto o Japão é diverso dentro de si mesmo. Afinal, nem todo samurai nasce em Kyoto, e nem todo gênio vem de Tóquio.

E você, padawan — de qual região do Japão seria seu sotaque de anime? 😄

#BellacosaMainframe #AnimeParaPadawans #CulturaJaponesa #DialetosDosAnimes #OtakuCultural

Translate

sábado, 28 de janeiro de 2023