✨ 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

terça-feira, 8 de novembro de 2016

Engenharia Militar : Especial — Guerrilha no Campo e na Floresta

Bellacosa Mainframe e a estrategia militar especial guerrilha no campo e na floresta

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Especial — Guerrilha no Campo e na Floresta

Quando um Programador COBOL Descobre que a Natureza Também Pode Ser uma Arquitetura... e que a Maior Aliada Nem Sempre é a Tecnologia, mas o Conhecimento do Terreno

Introdução

Muito antes dos satélites, drones, radares e computadores, a natureza já era um dos elementos mais decisivos da história militar.

Montanhas.

Pântanos.

Desertos.

Campos.

Selvas.

Florestas.

Rios.

Cada ambiente impunha desafios diferentes aos exércitos e obrigava comandantes a adaptar suas estratégias. Em muitos conflitos, a geografia teve mais influência sobre o resultado do que o tamanho das forças envolvidas.

É nesse contexto que estudiosos da história militar analisam a guerrilha em ambientes rurais e florestais: conflitos em que o terreno, o clima e a vegetação alteram profundamente a mobilidade, a logística e a comunicação.

Mais do que confrontos, esse tipo de estudo revela como sistemas complexos precisam ser projetados para operar em condições imprevisíveis.

Para um profissional IBM Z, a analogia é imediata.

Nem todos os ambientes computacionais são iguais.

Alguns Data Centers são altamente padronizados.

Outros convivem com aplicações legadas de décadas diferentes, integrações heterogêneas, restrições operacionais e mudanças constantes.

Nesses cenários, conhecer profundamente o ambiente faz tanta diferença quanto dominar a tecnologia.

Pegue seu café.

Hoje exploraremos como a natureza moldou campanhas militares, inspirou animes memoráveis e oferece lições surpreendentes para arquitetos de sistemas.

A Natureza Como Sistema

Uma floresta parece caótica.

Mas, na verdade, funciona como um enorme sistema distribuído.

Cada elemento depende de muitos outros.

Árvores.

Rios.

Animais.

Clima.

Solo.

Vegetação.

Luz.

Água.

Se um componente muda, todo o ecossistema reage.

O mesmo acontece em um ambiente Mainframe.

Uma alteração em uma aplicação pode produzir efeitos inesperados em dezenas de integrações, filas MQ, bancos Db2, rotinas batch e serviços CICS.

A verdadeira dificuldade está em compreender as interdependências.

O Campo de Batalha Invisível

Ao longo da história, diversos conflitos mostraram que conhecer profundamente o ambiente pode compensar diferenças significativas de recursos.

Por isso, historiadores militares estudam fatores como:

geografia;
clima;
sazonalidade;
hidrografia;
cobertura vegetal;
infraestrutura existente;
mobilidade;
linhas de suprimento.

A engenharia militar moderna utiliza esses conhecimentos principalmente para planejamento, mobilidade, proteção de tropas e apoio humanitário.

Os Animes que Melhor Retratam Ambientes Rurais e Florestais

Embora poucos tratem especificamente de guerrilha, diversas obras exploram sobrevivência, campanhas em florestas, adaptação ao terreno e operações prolongadas em ambientes naturais.

1. Princess Mononoke (Mononoke Hime)

Lançamento: 1997

Personagens

Ashitaka
San
Lady Eboshi

A floresta é tratada como um organismo vivo, onde natureza, tecnologia e sociedade entram em conflito.

Lição Bellacosa

Nunca subestime a complexidade do ambiente onde seu sistema opera.

2. Vinland Saga

Lançamento: 2019

Personagens

Thorfinn
Askeladd
Canute

Grande parte das campanhas depende da leitura do terreno, do clima e das rotas de deslocamento.

3. Golden Kamuy

Lançamento: 2018

Personagens

Sugimoto
Asirpa

A sobrevivência depende do conhecimento detalhado da natureza e das culturas locais.

4. Moribito: Guardian of the Spirit

Lançamento: 2007

Personagens

Balsa
Chagum

Atravessar montanhas, rios e florestas torna-se parte essencial da narrativa.

5. The Heroic Legend of Arslan

Lançamento: 2015

As campanhas mostram a importância das rotas terrestres, dos recursos naturais e da geografia.

6. Kingdom

Lançamento: 2012

Florestas, montanhas e vales influenciam diretamente as grandes campanhas militares.

7. Goblin Slayer

Lançamento: 2018

Diversas missões acontecem em cavernas, bosques e regiões rurais.

O protagonista adapta constantemente suas decisões ao ambiente.

8. Dororo

Lançamento: 2019

As viagens por regiões devastadas mostram como a natureza e o relevo influenciam deslocamentos e sobrevivência.

9. Drifters

Lançamento: 2016

Mistura líderes históricos em campanhas realizadas em ambientes variados, incluindo extensas áreas florestais.

10. The Twelve Kingdoms (Juuni Kokuki)

Lançamento: 2002

Explora reinos vastos onde geografia, recursos naturais e administração territorial são elementos centrais da narrativa.

Engenharia Militar do Terreno

Os engenheiros militares analisam o ambiente natural sob diversos aspectos:

travessia de rios;
construção de pontes temporárias;
abertura de vias;
proteção ambiental;
abastecimento;
comunicações;
mobilidade;
apoio à população;
recuperação de infraestrutura após desastres.

Perceba que quase todos esses temas envolvem planejamento e logística, não apenas operações militares.

O Paralelo com IBM Z

Imagine um ambiente composto por:

aplicações COBOL desenvolvidas ao longo de quarenta anos;
bancos Db2;
VSAM;
IMS;
MQ;
APIs modernas;
microsserviços;
aplicações distribuídas.

Esse ambiente lembra uma floresta antiga.

Existem árvores centenárias.

Novas espécies.

Raízes profundas.

Interdependências invisíveis.

Uma pequena mudança pode produzir consequências muito além do ponto onde ela começou.

Por isso arquitetos IBM Z estudam cuidadosamente impactos antes de modificar sistemas críticos.

Assim como um engenheiro ambiental analisa um ecossistema inteiro antes de alterar um rio.

Curiosidades

Durante diferentes períodos históricos, florestas desempenharam papéis decisivos como barreiras naturais, corredores logísticos e áreas de refúgio para populações civis. Essas características também influenciaram o desenvolvimento de técnicas de cartografia, engenharia de pontes e planejamento de infraestrutura, muitas das quais continuam relevantes em operações de resposta a desastres e reconstrução.

Hoje, tecnologias como sensoriamento remoto, satélites e sistemas de informação geográfica ajudam engenheiros civis e militares a compreender melhor esses ambientes, reforçando a importância do conhecimento do terreno para a tomada de decisões.

Easter Egg Bellacosa

Um estagiário perguntou ao velho Sysprog:

— Qual é o maior segredo para entender um Mainframe?

O veterano respondeu:

— Caminhe pela floresta.

O rapaz olhou sem entender.

— O que árvores têm a ver com COBOL?

O Sysprog sorriu.

— Em uma floresta, você vê troncos.

No Mainframe, você vê programas.

Mas o que realmente sustenta ambos...

...são as raízes que ninguém enxerga.

Conclusão

Ao estudar a guerrilha em campos e florestas pela ótica da engenharia militar, percebemos que o verdadeiro protagonista não é o conflito, mas o ambiente.

A natureza impõe limites, cria oportunidades e exige adaptação constante.

Esse princípio também define os grandes ecossistemas IBM Z.

Os sistemas mais importantes do mundo não sobrevivem apenas por causa da potência de seus processadores.

Eles permanecem ativos porque foram construídos respeitando o ambiente onde operam, compreendendo dependências, preservando continuidade e evoluindo sem romper aquilo que já funciona.

Talvez essa seja a maior lição deste especial.

Na floresta, vence quem compreende o ecossistema.

No Mainframe, vence quem compreende o legado.

Em ambos os casos, a força não está apenas na tecnologia.

Está na capacidade de enxergar as conexões invisíveis que mantêm todo o sistema vivo.

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

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

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Arquivo estratégico

Um Data Center analisado como uma fortaleza em guerra

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

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

Sala de operações

Índice da campanha

25 documentos localizados

Pesquisar no arquivo Categoria Ordenação

Índice permanente

Links completos da série Engenharia Militar

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

Engenharia Militar — Índice da campanha

O JavaScript está desativado. Utilize o índice permanente de links exibido nesta página para acessar os artigos.

segunda-feira, 7 de novembro de 2016

Mainframe History : Especial VIII A — Tommy Flowers: O Pai Esquecido da Computação Eletrônica

Bellacosa Mainframe e outro computador z especial complemento parte viii a

☕ Um Café no Bellacosa Mainframe

Muito Antes do IBM Z Existia Outro "Z"

Especial VIII A — Tommy Flowers: O Pai Esquecido da Computação Eletrônica

O Homem que Acendeu 2.500 Válvulas, Encurtou a Segunda Guerra Mundial e Depois Voltou para Casa Como um Anônimo

"A História costuma celebrar quem aparece nos jornais. A Engenharia costuma ser construída por aqueles que permanecem escondidos nos laboratórios."

Se você perguntar a um grupo de profissionais de TI quem foi Konrad Zuse, alguns responderão corretamente.

Se perguntar quem foi John von Neumann, muitos lembrarão da famosa arquitetura que domina praticamente todos os computadores modernos.

Se mencionar Alan Turing, provavelmente ouvirá referências à Enigma, à inteligência artificial e ao famoso Teste de Turing.

Agora faça outra pergunta.

Quem foi Tommy Flowers?

É bem provável que boa parte das pessoas permaneça em silêncio.

E isso é profundamente injusto.

Porque, sem Tommy Flowers, talvez a computação eletrônica tivesse demorado muito mais para conquistar a confiança da comunidade científica e da indústria.

Hoje vamos conhecer um engenheiro que nunca buscou fama.

Nunca escreveu autobiografias.

Nunca apareceu em campanhas publicitárias.

Nunca recebeu o reconhecimento proporcional ao tamanho de sua contribuição.

Mesmo assim, ajudou a mudar o destino da Segunda Guerra Mundial e da própria computação.

Um Engenheiro dos Correios

Thomas Harold Flowers nasceu em Londres, em 1905.

Sua formação não aconteceu em uma universidade famosa de matemática.

Nem em um laboratório de física.

Flowers era engenheiro de telecomunicações.

Trabalhava no General Post Office (GPO), o serviço postal britânico, que também era responsável pela infraestrutura telefônica do país.

Hoje isso pode parecer estranho.

Mas, naquela época, telefonia e telecomunicações estavam entre as áreas mais avançadas da engenharia.

Ali, Flowers aprendeu algo que mudaria sua vida.

Como construir equipamentos eletrônicos capazes de funcionar continuamente.

O Mundo das Centrais Telefônicas

Imagine uma central telefônica da década de 1930.

Milhares de ligações.

Relés abrindo e fechando contatos.

Operadoras conectando chamadas manualmente.

Depois, sistemas automáticos assumindo essa função.

A confiabilidade era essencial.

Uma falha interrompia centenas de comunicações.

Flowers especializou-se justamente em tornar esses sistemas mais rápidos e mais confiáveis.

Enquanto muitos engenheiros ainda confiavam apenas em mecanismos eletromecânicos, ele acreditava que o futuro estava nas válvulas eletrônicas.

Essa convicção seria colocada à prova poucos anos depois.

☕ Café com Naftalina

Quando hoje falamos em "alta disponibilidade", pensamos em clusters, replicação síncrona, Parallel Sysplex ou GDPS.

Na década de 1930, alta disponibilidade significava manter milhares de chamadas telefônicas funcionando sem interrupção.

Os princípios são os mesmos.

Mudaram apenas as tecnologias.

Um Convite para Bletchley Park

Com o início da Segunda Guerra Mundial, o governo britânico reuniu cientistas, matemáticos e engenheiros em um lugar que permaneceria secreto por décadas.

Seu nome era Bletchley Park.

Ali trabalhavam alguns dos maiores talentos da época.

Entre eles estava Alan Turing.

O objetivo era simples de explicar e extremamente difícil de executar:

Ler mensagens inimigas sem que o inimigo percebesse.

No início, os esforços concentraram-se na famosa máquina Enigma.

Mas havia um desafio ainda maior.

O sistema criptográfico Lorenz SZ40/42, utilizado para comunicações do alto comando alemão.

Era muito mais complexo que a Enigma.

Resolver esse problema manualmente era praticamente impossível.

Era necessário construir uma máquina.

"Isso Nunca Vai Funcionar"

Quando Tommy Flowers apresentou sua proposta, muitos colegas foram céticos.

Sua ideia era utilizar cerca de 2.500 válvulas eletrônicas.

Na época, isso parecia absurdo.

O argumento era sempre o mesmo.

"As válvulas queimam o tempo todo."

"Uma máquina com milhares delas jamais será confiável."

Flowers discordava.

Com base em sua experiência nas centrais telefônicas, sabia que a maior parte das falhas ocorria justamente durante o aquecimento e o resfriamento dos componentes.

Sua solução era surpreendentemente simples.

Nunca desligar a máquina.

As válvulas permaneceriam energizadas continuamente.

Hoje essa estratégia parece familiar.

Datacenters modernos evitam ciclos desnecessários de desligamento justamente para reduzir estresse térmico em diversos componentes.

Mais uma vez, uma boa ideia atravessou décadas.

🔧 Oficina do Engenheiro

Uma válvula termiônica controla o fluxo de elétrons em um ambiente de vácuo. Ela cumpre funções de amplificação e chaveamento semelhantes às que mais tarde seriam desempenhadas pelos transistores.

Embora fossem grandes, consumissem muita energia e gerassem calor, as válvulas permitiam operações muito mais rápidas que os relés eletromecânicos.

O Colossus demonstrou, na prática, que sistemas eletrônicos complexos podiam operar continuamente com alta confiabilidade quando bem projetados.

Nasce o Colossus

Em dezembro de 1943, o primeiro Colossus começou a operar.

Era uma máquina impressionante.

Cerca de 2.400 válvulas eletrônicas (na primeira versão).
Leitura óptica de fita perfurada em alta velocidade.
Processamento eletrônico.
Configuração por chaves e painéis.
Operação praticamente contínua.

Poucos meses depois surgiu o Colossus Mark II, ainda mais rápido e sofisticado.

Ao final da guerra, havia várias unidades em operação.

Enigma? Não.

Existe um dos maiores equívocos da história da computação.

Muita gente acredita que o Colossus foi construído para quebrar a Enigma.

Na realidade, sua principal missão era analisar mensagens produzidas pela máquina Lorenz, utilizada pelo alto comando alemão.

A Enigma era extremamente importante.

Mas o Lorenz protegia comunicações estratégicas entre Hitler e seus principais comandantes.

Quebrar esse sistema fornecia informações de enorme valor militar.

O Computador Invisível

O Colossus funcionou.

E funcionou muito bem.

Contribuiu para acelerar significativamente o trabalho dos criptanalistas britânicos.

Entretanto, quando a guerra terminou, aconteceu algo extraordinário.

As máquinas foram desmontadas.

Projetos destruídos.

Documentos classificados.

Os engenheiros assinaram compromissos de confidencialidade.

Durante décadas, praticamente ninguém podia comentar sua existência.

Enquanto isso, livros de história apresentavam o ENIAC como a grande revolução eletrônica.

Não porque o ENIAC não fosse extraordinário.

Mas porque quase ninguém sabia que o Colossus havia existido.

📦 Baú do Sysprog

Imagine participar do desenvolvimento de um sistema revolucionário e passar quase trinta anos proibido de mencionar esse trabalho, até mesmo para amigos ou familiares.

Foi exatamente isso que aconteceu com Tommy Flowers e muitos integrantes da equipe de Bletchley Park.

O Que um Sysprog IBM Z Aprende com Tommy Flowers?

Mais do que velocidade, Tommy Flowers nos ensina sobre confiabilidade.

Ele enfrentou um problema que qualquer Sysprog reconhece imediatamente:

Como manter um sistema complexo funcionando continuamente?

Sua resposta foi engenharia.

Testes.

Redundância.

Conhecimento profundo dos componentes.

Operação disciplinada.

É exatamente essa cultura que encontramos hoje nos ambientes IBM Z.

Não basta processar milhões de transações por segundo.

É preciso fazer isso todos os dias, durante anos, com disponibilidade próxima de 100%.

Um Herói Silencioso

Tommy Flowers não buscou reconhecimento.

Depois da guerra voltou ao trabalho em telecomunicações.

Não ficou rico.

Não fundou uma grande empresa de computadores.

Não se tornou uma celebridade.

Mas deixou uma herança extraordinária.

Demonstrou que computadores eletrônicos podiam ser rápidos, robustos e confiáveis.

Essa certeza influenciou toda a evolução posterior da computação.

O Legado

Konrad Zuse mostrou que computadores programáveis eram possíveis.

Tommy Flowers provou que computadores eletrônicos eram viáveis em larga escala.

Eckert e Mauchly levaram essa tecnologia ao conhecimento do público.

Von Neumann organizou seus princípios arquiteturais.

A IBM transformou tudo isso em plataformas comerciais confiáveis.

Quando um IBM Z processa bilhões de transações por dia, há um pouco de cada um desses pioneiros trabalhando silenciosamente dentro dele.

Inclusive de um engenheiro dos Correios britânicos que acreditou em 2.500 válvulas quando quase ninguém acreditava.

Talvez essa seja a maior lição de Tommy Flowers.

A inovação nem sempre nasce do consenso.

Às vezes, ela nasce da coragem de um engenheiro que insiste em provar que todos os outros estavam errados.

E, de vez em quando...

Ele realmente consegue.

📚 Índice completo da série

GUIA
O Guia do Viajante do Tempo
Índice geral da série Muito Antes do IBM Z Existia Outro “Z”.
I
O Engenheiro que Cansou de Fazer Contas e Acabou Inventando o Futuro
Konrad Zuse, o nascimento do Z1 e o início de uma revolução.
II
Abrindo a Tampa do Z1: Quando os Bits Eram Feitos de Aço
CPU mecânica, memória binária, engrenagens e lógica de aço.
III
O Z2: Quando os Bits Pararam de Ranger
O encontro entre a lógica binária e os relés telefônicos.
IV
Z3: O Computador que Desafiou a História
O computador programável que consolidou a visão de Konrad Zuse.
V
Z4: O Computador que Sobreviveu à Guerra e Ensinou a Europa a Computar
A máquina que escapou da destruição e chegou à computação científica.
VI
Plankalkül: A Linguagem Criada Antes de o Mundo Estar Pronto
A linguagem de programação imaginada por Konrad Zuse antes do COBOL.
VII
Cartões Perfurados, Hollerith e a IBM
Quando dois mundos caminhavam silenciosamente para o mesmo futuro.
VIII A
Afinal, Quem Inventou o Primeiro Computador?
A Guerra dos Gigantes: pioneiros, máquinas e diferentes definições de “primeiro”.
VIII B
EDVAC e John von Neumann: A Ideia que Mudou Todos os Computadores
Programa armazenado na memória e a arquitetura que atravessou gerações.
IX
IBM System/360: O Computador que Mudou a História dos Mainframes
Compatibilidade, arquitetura unificada e o nascimento do ecossistema moderno.
ESPECIAL
Tommy Flowers: O Pai Esquecido da Computação Eletrônica
Colossus, 2.500 válvulas e o engenheiro que voltou para casa como anônimo.
X
Das Engrenagens ao IBM Z: O Legado dos Pioneiros
O encerramento da jornada, ligando as máquinas históricas ao IBM Z.

ARTIGO SELECIONADO

O Guia do Viajante do Tempo

Abrir em nova guia ↗

Preparando a máquina do tempo...

Caso o navegador impeça a exibição incorporada, utilize o botão Abrir em nova guia.

O JavaScript está desativado. Os links do índice continuam disponíveis, mas o visualizador incorporado não poderá trocar de capítulo.

domingo, 6 de novembro de 2016

☕ Os Holocrons dos Utilitários JCL: As Ferramentas Secretas que Transformam um Padawan COBOL em um Mestre do Batch

Bellacosa Mainframe e os utilitarios de jcl que aumentam a produtividade

☕ Os Holocrons dos Utilitários JCL: As Ferramentas Secretas que Transformam um Padawan COBOL em um Mestre do Batch

"Todo programador COBOL aprende IF, PERFORM e READ. Poucos descobrem que grande parte do trabalho pesado do mundo IBM Z é realizado por pequenos utilitários invisíveis que trabalham silenciosamente há décadas."

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

Ele passou três horas escrevendo um programa COBOL para copiar arquivos.

Depois mais duas horas desenvolvendo outro para ordenar registros.

Em seguida criou um terceiro para contar ocorrências.

Um quarto para apagar datasets.

Um quinto para gerar relatórios simples.

E então aparece um velho Sysprog tomando café, olha para a tela e pergunta:

— Por que você escreveu tudo isso?

— Porque precisava fazer essas tarefas...

O veterano sorri.

— Meu jovem Padawan... o z/OS faz isso desde antes de você nascer.

E então ele abre o Holocron dos Utilitários.

O que são utilitários no mundo JCL?

Utilitários são programas fornecidos pela IBM ou por produtos instalados que executam tarefas administrativas, operacionais e de manipulação de dados.

São verdadeiros canivetes suíços do IBM Z.

Eles permitem:

Copiar datasets
Ordenar milhões de registros
Filtrar informações
Mesclar arquivos
Criar datasets
Excluir datasets
Imprimir conteúdos
Fazer backup
Gerar estatísticas
Converter formatos
Executar manutenção

Sem escrever uma única linha de COBOL.

O desenvolvedor produtivo não programa tudo.

Ele sabe quando reutilizar ferramentas.

1. IEBGENER — O utilitário que todo Padawan deveria conhecer primeiro

É provavelmente o utilitário mais usado do ambiente z/OS.

Função principal:

Copiar datasets.

Exemplo

//STEP01 EXEC PGM=IEBGENER

//SYSUT1 DD DSN=ARQ.ORIGEM,
//       DISP=SHR

//SYSUT2 DD DSN=ARQ.DESTINO,
//       DISP=OLD

//SYSPRINT DD SYSOUT=*

//SYSIN DD DUMMY

Pode parecer simples.

Mas resolve dezenas de situações.

Copiar arquivos VSAM exportados.

Duplicar layouts.

Criar arquivos de teste.

Mover resultados batch.

Quando evita escrever COBOL?

Imagine desenvolver um programa com:

OPEN INPUT

OPEN OUTPUT

READ

WRITE

EOF

Tudo isso apenas para copiar um arquivo.

IEBGENER faz em segundos.

2. SORT (DFSORT/SYNCSORT)

Este talvez seja o utilitário mais poderoso do ecossistema IBM.

É praticamente uma linguagem própria.

Pode:

Ordenar

Mesclar

Somar

Agrupar

Transformar

Filtrar

Criar relatórios

Converter formatos

Gerar arquivos

Manipular datas

Remover duplicidades

Exemplo simples

SORT FIELDS=(1,10,CH,A)

Ordena pelo campo posição 1 tamanho 10.

Remover duplicados

SORT FIELDS=(1,10,CH,A)

SUM FIELDS=NONE

Resultado:

Arquivo limpo.

Filtrar registros

INCLUDE COND=(1,1,CH,EQ,C'A')

Mantém apenas registros iniciados por A.

OUTFIL

Uma das funcionalidades mais incríveis.

Separar arquivos.

Criar múltiplas saídas.

Gerar cabeçalhos.

Gerar trailers.

Formatar colunas.

Exemplo:

OUTFIL FNAMES=CLIENTE

INCLUDE=(1,1,CH,EQ,C'C')

OUTFIL FNAMES=FORNEC

Um arquivo vira dois.

Sem COBOL.

3. IDCAMS

O mestre Jedi dos datasets.

Principalmente VSAM.

DELETE

DELETE CLIENTES.KSDS

DEFINE CLUSTER

Criar VSAM.

DEFINE CLUSTER -

(NAME(CLIENTES)) -

INDEXED

LISTCAT

Consultar catálogo.

LISTCAT ENT(CLIENTES)

Retorna:

Volume

Datas

Extents

Organização

REPRO

Copiar VSAM.

REPRO -

INFILE(INPUT)

OUTFILE(OUTPUT)

Muito usado em testes.

4. IEHLIST

Pouco conhecido pelos iniciantes.

Extremamente útil.

Lista informações físicas.

Volumes.

Tracks.

Datasets.

Exemplo:

LISTVTOC

Excelente para administradores.

5. IEFBR14

O programa mais famoso do z/OS.

Possui praticamente uma única instrução.

BR 14

Retornar.

Mas é extremamente útil.

Criar datasets

//EXEC PGM=IEFBR14


//ARQ DD DSN=TESTE.ARQ,

//DISP=(NEW,CATLG),

//SPACE=(CYL,(1,1))

Apagar datasets

DISP=(OLD,DELETE)

Padawan normalmente fica surpreso.

"Um programa vazio consegue criar arquivos?"

Sim.

Porque quem cria é o sistema.

IEFBR14 apenas dispara a alocação.

6. IEBCOPY

Especialista em bibliotecas.

PDS

PDSE

Loadlibs

JCLLIB

PROCLIB

COPYLIB

Copiar membros

COPY OUTDD=OUT


INDD=IN

Selecionar membros

SELECT MEMBER=(PROG1)

Ideal para:

Promotion

Deploy

Backup

Migração

7. IEBUPDTE

O ancestral do Git.

Poucos conhecem.

Mas era revolucionário.

Permitia atualizar bibliotecas por comandos.

Exemplo

./ ADD NAME=PROG1

Inserir membros.

Alterar.

Excluir.

Décadas antes do GitHub.

8. ICETOOL

O irmão mais sofisticado do DFSORT.

Executa tarefas complexas.

COUNT

DISPLAY

UNIQUE

OCCUR

SPLICE

STATS

Contar registros

COUNT FROM(INPUT)

Encontrar duplicados

OCCUR

Estatísticas

STATS

Ideal para auditorias.

9. ADRDSSU

Backup corporativo.

Conhecido como DFDSS.

Pode:

Copiar volumes

Backup

Restore

Compressão

Dump

Movimentação

Exemplo

DUMP DATASET(INCLUDE(TESTE))

Muito usado em produção.

10. IKJEFT01

Uma verdadeira ponte entre TSO e Batch.

Executa comandos TSO.

DB2.

REXX.

CLIST.

Executar DB2

EXEC PGM=IKJEFT01

Rodar:

SPUFI

DSN

BIND

REBIND

RUNSTATS

REORG

Executar REXX

Automação total.

11. DSNUTILB

Utilitário poderoso do DB2.

Executa:

LOAD

UNLOAD

COPY

RUNSTATS

REORG

CHECK DATA

MODIFY

Exemplo

LOAD DATA

Carga massiva.

Milhões de registros.

Muito mais rápido que COBOL.

12. File Manager, SORT Products e Ferramentas Modernas

Em muitos ambientes corporativos existem produtos adicionais.

IBM File Manager

Syncsort

CA-Easytrieve

DB2 Utilities

Abend-AID

Xpediter

Ganhos impressionantes:

Visualização rápida

Edição de arquivos

Comparação datasets

Conversão

Debug

Geração de testes

A Mentalidade do Desenvolvedor COBOL Produtivo

Um erro comum dos iniciantes é acreditar que produtividade significa escrever mais programas.

No IBM Z ocorre exatamente o oposto.

Um desenvolvedor experiente faz constantemente a seguinte pergunta:

"Existe um utilitário que já resolva este problema?"

Muitas vezes a resposta é sim.

Em vez de construir um COBOL de 800 linhas para separar registros, o especialista utiliza DFSORT.

Ao invés de criar um programa apenas para copiar arquivos, usa IEBGENER.

No lugar de escrever uma rotina de manutenção VSAM, emprega IDCAMS.

Em vez de desenvolver scripts externos para estatísticas, utiliza ICETOOL.

O resultado é significativo:

Menos código para manter;
Menos testes;
Menor risco de erros em produção;
Redução de consumo de CPU;
Processamentos batch mais rápidos;
Maior padronização operacional;
Entregas mais ágeis.

No universo IBM Z, conhecimento técnico não se mede apenas pela capacidade de programar COBOL sofisticado. Mede-se também pela habilidade de reconhecer quando não é necessário programar.

O verdadeiro Mestre Jedi do Batch entende que o sistema operacional já oferece um arsenal construído ao longo de mais de cinquenta anos de evolução. Cada utilitário é um pequeno holocron de sabedoria acumulada, refinado por milhares de empresas que processam diariamente bilhões de transações financeiras, seguros, telecomunicações e sistemas governamentais.

E talvez esta seja uma das maiores lições para um Padawan COBOL: a produtividade não está em produzir mais linhas de código. Está em conhecer profundamente as ferramentas disponíveis, reutilizar capacidades existentes e permitir que o IBM Z faça aquilo para o qual ele foi projetado desde o início: executar trabalho pesado com elegância, estabilidade e uma eficiência que continua impressionando gerações sucessivas de desenvolvedores. Afinal, no mundo do mainframe, muitas vezes o melhor programa COBOL é justamente aquele que você nunca precisou escrever.

sábado, 5 de novembro de 2016

☕💣📚 O GRANDE MAPA DAS CLASSIFICAÇÕES DE ANIME

Bellacosa Mainframe e grande mapa de classificacao de anime

☕💣📚 O GRANDE MAPA DAS CLASSIFICAÇÕES DE ANIME

CLASSIFICAÇÃO DEMOGRÁFICA

(Público-alvo)

Kodomo

Crianças.

Exemplos:

Doraemon
Anpanman
Pokémon

Shounen

Meninos adolescentes.

Exemplos:

Naruto
One Piece
Bleach
Dragon Ball

Características:

amizade
superação
batalhas
treinamento

Shoujo

Meninas adolescentes.

Exemplos:

Sailor Moon
Cardcaptor Sakura
Fruits Basket

Seinen

Homens adultos.

Exemplos:

Berserk
Monster
Ghost in the Shell
Vinland Saga

Josei

Mulheres adultas.

Exemplos:

Chihayafuru
Nodame Cantabile
Honey and Clover

CLASSIFICAÇÃO POR ESTILO NARRATIVO

Iyashikei

Animes terapêuticos.

Aria
Yuru Camp
Flying Witch

Slice of Life

Histórias do cotidiano.

Barakamon
Non Non Biyori
Azumanga Daioh

CGDCT

(Cute Girls Doing Cute Things)

Garotas fazendo atividades comuns.

K-On!
Yuru Camp
Slow Loop

Coming of Age

Amadurecimento.

A Place Further Than The Universe
Silver Spoon

Denpa

Obras estranhas, psicológicas e desconectadas da realidade.

Serial Experiments Lain
Boogiepop Phantom

CLASSIFICAÇÃO POR ATMOSFERA

Isekai

Pessoa transportada para outro mundo.

Re:Zero
Mushoku Tensei
Overlord

Reverse Isekai

Seres de outro mundo vêm para o nosso.

The Devil is a Part-Timer

Dark Fantasy

Fantasia sombria.

Berserk
Claymore
Goblin Slayer

Grimdark

Tudo dá errado.

Berserk
Made in Abyss

Cozy Fantasy

Fantasia confortável.

Frieren
Hakumei to Mikochi
Restaurant to Another World

CLASSIFICAÇÃO POR ARQUÉTIPO

Power Fantasy

Protagonista absurdamente poderoso.

Overlord
Misfit of Demon King Academy

Underdog

Herói azarão.

Naruto
Black Clover

Villain Protagonist

Protagonista é o vilão.

Overlord
Death Note

CLASSIFICAÇÃO POR TEMA

Mecha

Robôs gigantes.

Gundam
Macross
Evangelion

Mahou Shoujo

Garotas mágicas.

Sailor Moon
Madoka Magica

Sports

Esportes.

Haikyuu
Slam Dunk
Blue Lock

Idol

Cantoras e grupos musicais.

Love Live
Idolmaster

Military

Temática militar.

Legend of the Galactic Heroes
Gate

TERMOS MUITO USADOS PELOS FÃS

Moe

Personagens feitos para despertar afeição.

Exemplo:

K-On!

Chuunibyou

Personagens com "síndrome da oitava série".

Exemplo:

Love, Chunibyo & Other Delusions

Genki Girl

Garota hiperativa e energética.

Exemplo:

Nadeshiko (Yuru Camp)

Tsundere

Fria por fora, gentil por dentro.

Exemplo:

Taiga (Toradora)

Kuudere

Calma e quase sem emoções.

Exemplo:

Rei Ayanami

A CLASSIFICAÇÃO MAIS CURIOSA

Existe um termo chamado:

Nichijou-kei (日常系)

Literalmente:

"estilo cotidiano"

É praticamente um primo do Iyashikei.

Diferença:

Iyashikei

Objetivo:
Curar e relaxar.

Exemplos:

Aria
Mushishi
Yuru Camp

Nichijou-kei

Objetivo:
Mostrar o cotidiano.

Exemplos:

K-On!
Lucky Star
Azumanga Daioh

Todo Iyashikei é quase um Slice of Life.

Mas nem todo Slice of Life é Iyashikei.

A FÓRMULA BELLACOSA MAINFRAME

Se fosse classificar animes como sistemas:

Tipo	Equivalente Mainframe
Shounen	Batch crítico em produção
Seinen	Sistema bancário
Isekai	Migração para outra plataforma
Mecha	Hardware IBM
Cyberpunk	Datacenter pós-incidente
Slice of Life	Ambiente de homologação
Iyashikei	Backup restaurado com sucesso
CGDCT	Equipe tomando café após o deploy
Dark Fantasy	Produção sem documentação
Grimdark	Produção sem documentação e sem backup

E é justamente por isso que o Iyashikei se tornou tão querido: ele é o raro momento em que o sistema para de emitir mensagens de erro e finalmente apresenta a mensagem que todo operador gostaria de ver:

$HASP999 SYSTEM NORMAL — NO ACTION REQUIRED. ☕🌿💻🏕️📚

sexta-feira, 4 de novembro de 2016

☕💣🌫️ O IPL MAIS DIFÍCIL DOS ANIMES — HAI TO GENSOU NO GRIMGAR E O DIA EM QUE USUÁRIOS FORAM COLOCADOS EM PRODUÇÃO SEM MANUAL, SEM BACKUP E SEM MEMÓRIA

Bellacosa Mainframe e o doloroso Hai to Gensou no Grimgar

☕💣🌫️ O IPL MAIS DIFÍCIL DOS ANIMES — HAI TO GENSOU NO GRIMGAR E O DIA EM QUE USUÁRIOS FORAM COLOCADOS EM PRODUÇÃO SEM MANUAL, SEM BACKUP E SEM MEMÓRIA

Ficha Técnica

Título Original

灰と幻想のグリムガル (Hai to Gensou no Grimgar)

Título Internacional

Grimgar of Fantasy and Ash

Autor

Ao Jūmonji

Ilustrações da Light Novel

Eiri Shirai

Estúdio

A-1 Pictures

Direção

Ryosuke Nakamura

Exibição Original

Janeiro de 2016 a Março de 2016

Episódios

12 episódios + OVA

Gêneros

Isekai
Fantasia
Drama
Sobrevivência
Aventura
Psicológico
Slice of Life

Classificação Indicativa

Normalmente recomendado para maiores de 14 anos, devido a violência moderada, temas existenciais e morte.

Sinopse

Um grupo de jovens desperta em um mundo chamado Grimgar sem qualquer lembrança de suas vidas anteriores.

Eles não sabem quem são.

Não sabem de onde vieram.

Não sabem por que estão ali.

Sabem apenas uma coisa:

Precisam sobreviver.

Sem habilidades lendárias.

Sem níveis absurdos.

Sem protagonista invencível.

Sem cheat.

Eles se tornam soldados voluntários e precisam ganhar dinheiro matando goblins para não morrerem de fome.

O Conceito Que Faz Grimgar Ser Diferente

A maioria dos isekais funciona assim:

LOGIN
↓
PODER SUPREMO
↓
HARÉM
↓
REI DEMÔNIO
↓
FIM

Grimgar funciona assim:

IPL
↓
ERRO DE INICIALIZAÇÃO
↓
FALTA DE MEMÓRIA
↓
RECURSOS INSUFICIENTES
↓
TENTATIVA DE SOBREVIVÊNCIA

É provavelmente o anime que mais se aproxima de como seria uma migração real de usuários para um ambiente completamente desconhecido.

A História Vista Como um Ambiente Mainframe

Imagine que alguém executou um:

//MIGRACAO EXEC PGM=HUMANOS

e vários usuários foram carregados em produção.

O problema?

O dataset de memória não foi restaurado.

Resultado:

MEMORY FILE NOT FOUND
DEFAULT HUMAN PACKAGE LOADED

Os personagens mantêm suas personalidades básicas.

Mas perderam todo o histórico.

Perderam experiências.

Perderam referências.

Perderam contexto.

Exatamente como um sistema recuperado sem seus logs históricos.

O Verdadeiro Protagonista Não É Haruhiro

Muitos acreditam que o protagonista seja Haruhiro.

Mas na prática o verdadeiro protagonista é:

A Fragilidade Humana

Todo episódio gira em torno da incapacidade dos personagens.

Eles erram.

Eles sentem medo.

Eles falham.

Eles choram.

Eles entram em pânico.

Eles fogem.

Eles não são heróis.

São apenas pessoas.

E isso é extremamente raro no gênero.

Personagens Principais

Haruhiro

O líder improvisado.

Não é forte.

Não é genial.

Não possui poderes especiais.

Ele simplesmente continua avançando.

Representa o operador que assume o turno da madrugada quando ninguém mais quer assumir a responsabilidade.

Manato

O líder original.

Experiente.

Calmo.

Competente.

É o SYSADM do grupo.

Sua ausência gera um colapso operacional enorme.

Merry

Talvez a personagem mais profunda da obra.

Carrega traumas.

Carrega culpa.

Carrega perdas.

Representa ambientes que sobreviveram a falhas anteriores e carregam cicatrizes invisíveis.

Ranta

O usuário problemático.

Barulhento.

Impulsivo.

Difícil de administrar.

Mas surpreendentemente útil em momentos críticos.

Todo ambiente tem um Ranta.

Yume

A otimista do grupo.

Mantém a moral elevada.

Representa o fator humano que impede sistemas e equipes de colapsarem emocionalmente.

Moguzo

Gigante.

Gentil.

Leal.

Uma espécie de servidor robusto que trabalha silenciosamente sem receber reconhecimento.

O Grande Tema de Grimgar

A maioria dos animes fala sobre:

vencer
conquistar
evoluir

Grimgar fala sobre:

sobreviver
aceitar perdas
amadurecer
continuar

A diferença parece pequena.

Mas é gigantesca.

O Episódio Que Mudou Tudo

Sem entrar em spoilers pesados.

Existe um evento específico envolvendo Manato.

Até aquele momento o espectador ainda acredita que está vendo um isekai comum.

Após esse acontecimento:

AMBIENTE DE TESTES ENCERRADO

A partir dali tudo muda.

O anime passa a discutir luto.

E poucos isekais fazem isso tão bem.

As Mensagens Ocultas

1. A Vida Não Tem Balanceamento

Em videogames existe balanceamento.

Na vida não.

Grimgar mostra isso brutalmente.

Algumas pessoas nascem com vantagens.

Outras não.

E o mundo não se importa.

2. A Morte Não É Narrativamente Conveniente

Em muitos animes:

PERSONAGEM MORRE
↓
RESSUSCITA

Em Grimgar:

PERSONAGEM MORRE
↓
FIM

As consequências permanecem.

3. Liderança É Solidão

Haruhiro aprende que liderar significa tomar decisões sem saber se está certo.

Uma lição extremamente próxima da realidade corporativa.

4. Trauma Não Desaparece

Merry é uma demonstração clara disso.

O anime trata saúde emocional de maneira surpreendentemente madura.

O Visual Mais Diferente da Década

Aquarela Viva

A direção artística de Grimgar é única.

Os cenários parecem pinturas.

Muitas cenas lembram quadros feitos à mão.

O resultado transmite uma sensação constante de sonho, nostalgia e melancolia.

Poucos animes possuem uma identidade visual tão reconhecível.

Houve Censura?

Não houve censura significativa ou polêmica relevante.

O anime foi exibido normalmente no Japão.

As adaptações para TV mantiveram praticamente todo o conteúdo importante da obra original.

O que ocorreu foi uma redução de material devido à quantidade enorme de conteúdo das light novels.

Em outras palavras:

SOURCE CODE > ANIME BUILD

Grande parte do conteúdo ficou fora da adaptação por limitação de episódios.

Impacto Cultural

Grimgar nunca foi um fenômeno de massa como:

Sword Art Online
Re:Zero
Overlord
Mushoku Tensei

Mas tornou-se uma obra cult.

Entre fãs de isekai experientes existe quase um consenso:

"Se você quer saber como seria um isekai realista, assista Grimgar."

Até hoje aparece constantemente em listas de:

Isekais subestimados
Melhores fantasias dramáticas
Obras que merecem continuação

Por Que Não Existe Segunda Temporada?

A pergunta que atormenta fãs há uma década.

Os motivos mais citados são:

vendas moderadas de Blu-ray
adaptação usada principalmente para divulgar as light novels
custo elevado da produção visual
estratégia comercial do estúdio

O material original possui conteúdo suficiente para muitas temporadas.

Veredito Bellacosa Mainframe ☕💣

Se Sword Art Online é um ambiente cloud elástico cheio de recursos...

Se Overlord é um SYSADM com autoridade total...

Se Re:Zero é um sistema com rollback infinito...

Então Grimgar é o operador recém-contratado que recebe um terminal 3270, um manual incompleto e a seguinte mensagem:

IEF000I WELCOME TO PRODUCTION

NO DOCUMENTATION FOUND
NO BACKUP FOUND
NO MEMORY FOUND

GOOD LUCK

E talvez seja justamente por isso que ele seja tão inesquecível.

Nota Bellacosa Mainframe: ☕☕☕☕☕ (10/10)

Porque Grimgar não é uma história sobre heróis.

É uma história sobre pessoas comuns tentando continuar executando seus jobs depois que o sistema da vida entrou em abend.

quinta-feira, 3 de novembro de 2016

☕🩸💣 HIGURASHI NO NAKU KORO NI — O JOB MALDITO QUE REPROCESSA O MESMO ABEND ATÉ A HUMANIDADE ENCONTRAR O BUG DA PRÓPRIA ALMA

Bellacosa Mainframe e o sombrio Higurashi no naku koro

☕🩸💣 HIGURASHI NO NAKU KORO NI — O JOB MALDITO QUE REPROCESSA O MESMO ABEND ATÉ A HUMANIDADE ENCONTRAR O BUG DA PRÓPRIA ALMA

"Você acredita que conhece a verdade? Em Hinamizawa, cada IPL da realidade gera um novo relatório de erro."

Dados Técnicos

Título Original: Higurashi no Naku Koro ni (ひぐらしのなく頃に)

Título Internacional: When They Cry

Autor Original: Ryukishi07

Obra Original: Visual Novel produzida pela 07th Expansion

Primeiro Lançamento da Visual Novel: 2002

Anime (Primeira Temporada): 2006

Estúdio: Studio Deen

Direção: Chiaki Kon

Música: Kenji Kawai

Gêneros:

Terror Psicológico
Mistério
Suspense
Drama
Thriller
Sobrenatural
Horror

Classificação Indicativa:
16 a 18 anos dependendo da região devido à violência gráfica, temas psicológicos pesados e conteúdo perturbador.

Quantidade de Episódios

Série Principal

Higurashi no Naku Koro ni (2006)

26 episódios

Higurashi no Naku Koro ni Kai (2007)

24 episódios

Higurashi no Naku Koro ni Rei (OVA)

5 episódios

Higurashi no Naku Koro ni Kira

4 episódios

Higurashi no Naku Koro ni Gou (2020)

24 episódios

Higurashi no Naku Koro ni Sotsu (2021)

15 episódios

Total superior a 90 episódios considerando continuações e OVAs.

Sinopse

Junho de 1983.

Keiichi Maebara muda-se para a pequena vila rural de Hinamizawa.

Aparentemente é um lugar pacífico.

As crianças brincam.

Os moradores sorriem.

A vida segue normalmente.

Mas existe um detalhe curioso.

Todos os anos, durante o Festival de Oyashiro-sama, alguém morre.

E outra pessoa desaparece.

Quando Keiichi começa a investigar os acontecimentos, sua percepção da realidade começa a falhar.

Amigos tornam-se suspeitos.

Memórias tornam-se inconsistentes.

E a própria narrativa parece entrar em loop.

A História: O Mainframe Que Reinicia a Realidade

Ao estilo Bellacosa Mainframe, Hinamizawa pode ser entendida como um ambiente de produção preso em processamento circular.

Imagine um sistema que executa:

PERFORM UNTIL DESTINO-SEJA-ALTERADO

   EXECUTA-HINAMIZAWA

   IF RESULTADO = TRAGEDIA
      REINICIA-TUDO
   END-IF

END-PERFORM

É exatamente isso.

A obra é estruturada em diversos arcos.

Cada arco mostra eventos semelhantes.

Porém pequenas alterações produzem resultados completamente diferentes.

O espectador inicialmente acredita estar vendo histórias independentes.

Na verdade está observando múltiplas execuções do mesmo programa.

Cada reinicialização revela novos logs.

Novos dumps.

Novas pistas.

Até que o erro raiz seja identificado.

O Que Torna Higurashi Diferente?

Praticamente tudo.

Em 2006 a maioria dos animes de terror dependia de fantasmas, monstros ou demônios.

Higurashi escolheu outro caminho.

O monstro é a dúvida.

Você não sabe:

quem está mentindo
quem está enlouquecendo
quem está sendo manipulado
quem é vítima
quem é agressor

O anime usa paranoia como mecanismo narrativo.

O espectador perde a capacidade de confiar até mesmo no próprio narrador.

Isso era extremamente inovador para a época.

Principais Personagens

Keiichi Maebara

O operador recém-chegado ao sistema.

Representa o espectador.

É através dele que descobrimos os erros do ambiente.

Quanto mais investiga, mais instável se torna.

Rena Ryugu

A personagem mais famosa da franquia.

Sua aparência inocente contrasta com momentos profundamente perturbadores.

Ela simboliza a linha tênue entre afeto e obsessão.

Mion Sonozaki

Líder informal do grupo.

Extrovertida.

Carismática.

Mas ligada a uma das famílias mais influentes da vila.

Shion Sonozaki

Uma das personagens mais complexas da obra.

Responsável por alguns dos momentos mais brutais da série.

Sua trajetória é uma aula sobre trauma psicológico.

Satoko Houjou

Inicialmente parece apenas uma garota travessa.

Com o avanço da história, torna-se uma das figuras mais trágicas da franquia.

Rika Furude

O núcleo central da narrativa.

A verdadeira administradora do sistema.

A personagem que mais compreende os loops.

Também é quem mais sofre.

As Aventuras Não São Aventuras

Este é um detalhe brilhante.

Em muitos animes temos jornadas físicas.

Em Higurashi a aventura é investigativa.

Cada arco funciona como uma expedição dentro do mesmo labirinto.

O objetivo não é derrotar um vilão.

O objetivo é descobrir:

"Por que tudo termina em tragédia?"

É quase uma investigação forense em um sistema condenado.

Temáticas Profundas

Paranoia

O tema central.

O anime mostra como a desconfiança destrói relacionamentos.

Solidão

Quase todos os personagens carregam dores ocultas.

Trauma

Grande parte das tragédias nasce de traumas não resolvidos.

Destino

Pode o futuro ser alterado?

Ou estamos presos a um script inevitável?

Amizade

Curiosamente, a resposta para muitos problemas não está na força.

Está na confiança.

As Mensagens Ocultas

Aqui encontramos o verdadeiro coração da obra.

Muitos espectadores focam apenas na violência.

Mas Ryukishi07 estava discutindo temas muito maiores.

A Falta de Comunicação Mata

Quase todas as tragédias poderiam ser evitadas se os personagens conversassem honestamente.

Parece simples.

Mas é devastador.

O Medo Cria Monstros

Os personagens frequentemente enxergam ameaças onde não existem.

A paranoia transforma amigos em inimigos.

O Conhecimento Parcial É Perigoso

Saber metade da verdade pode ser pior que não saber nada.

Uma lição extremamente atual para a era das redes sociais.

A Síndrome de Hinamizawa

Um dos elementos mais fascinantes.

Durante muito tempo o espectador acredita que tudo é sobrenatural.

Depois surgem explicações médicas.

Depois novas dúvidas aparecem.

A série brinca constantemente com:

ciência
superstição
religião
folclore
psicologia

O espectador nunca se sente totalmente seguro.

Houve Censura?

Sim.

E muita discussão.

A violência extrema do anime gerou controvérsias no Japão.

Após alguns crimes cometidos por menores que ganharam repercussão nacional, algumas emissoras passaram a tratar conteúdos violentos com mais cautela.

Em diversas exibições internacionais ocorreram:

cortes de cenas
escurecimento de imagens
redução de detalhes gráficos

Mesmo assim, Higurashi continuou famoso justamente porque o terror psicológico era mais impactante que o conteúdo visual.

Impacto Cultural

Poucas obras influenciaram tanto o horror psicológico moderno.

Sua influência pode ser percebida em:

Another
Mirai Nikki
Summertime Rendering
Re:Zero
School-Live!
Happy Sugar Life
diversos jogos de horror psicológico

Além disso, ajudou a popularizar visual novels fora do Japão.

Também consolidou Ryukishi07 como um dos maiores escritores de mistério da cultura pop japonesa.

A Grande Sacada de Ryukishi07

O autor entendeu algo que poucos criadores compreendem.

O ser humano teme mais a dúvida do que o monstro.

Não sabemos exatamente quem é o vilão.

Não sabemos exatamente o que é real.

Não sabemos exatamente o que aconteceu.

E justamente por isso não conseguimos parar de assistir.

Veredito Bellacosa Mainframe

Higurashi no Naku Koro ni não é uma história de assassinatos.

Não é uma história de fantasmas.

Não é uma história de maldições.

É uma auditoria completa em um ambiente de produção chamado humanidade.

Cada arco é um novo IPL.

Cada tragédia é um novo dump.

Cada personagem carrega um dataset corrompido por medo, culpa ou trauma.

E a mensagem final do autor é brilhante:

Os maiores ABENDS da vida raramente são causados por falta de tecnologia.

Eles acontecem quando pessoas deixam de confiar umas nas outras.

☕🩸💣 Nota Bellacosa Mainframe: 10/10 dumps psicológicos analisados.

Status do Sistema:
LOOP DETECTED IN HINAMIZAWA
ROOT CAUSE: HUMAN FEAR
JOB CONTINUES EXECUTING...

quarta-feira, 2 de novembro de 2016

☕📈 “O PROFISSIONAL QUE DECIDE SE O BANCO SOBREVIVE AMANHÃ” — O UNIVERSO BRUTAL DO MAINFRAME CAPACITY NO IBM Z 💣🖥️

Bellacosa Mainframe e o system capacity em z/os

☕📈 “O PROFISSIONAL QUE DECIDE SE O BANCO SOBREVIVE AMANHÃ” — O UNIVERSO BRUTAL DO MAINFRAME CAPACITY NO IBM Z 💣🖥️

Existe uma área do Mainframe que quase ninguém fora do IBM Z entende.

Ela não aparece em filmes.
Não vira hype no LinkedIn.
Não ganha palco em eventos de startup.

Mas é uma das funções mais críticas da computação corporativa mundial.

Porque ela responde uma pergunta assustadora:

“Quanto tempo falta para o sistema entrar em colapso?”

Estamos falando de:

Mainframe Capacity Planning.

Ou simplesmente:

Capacity.

No universo IBM Z, Capacity não significa apenas medir CPU.

Significa prever o futuro operacional da empresa.

⚡ O QUE É CAPACITY NO IBM Z?

Capacity é a disciplina responsável por:

prever crescimento computacional
evitar saturação operacional
otimizar consumo de recursos
controlar custos milionários
garantir SLA
sustentar expansão do negócio
evitar colapsos invisíveis

O profissional de Capacity trabalha analisando:

CPU
memória
I/O
DASD
network
batch
transações online
workload
throughput
comportamento sistêmico

Mas o verdadeiro trabalho não é medir recurso.

É entender comportamento corporativo.

Porque cada gráfico conta uma história.

☠️ O MAIOR ERRO SOBRE CAPACITY

Muitos imaginam que Capacity é apenas:

“tirar relatório de CPU”.

Errado.

Capacity em IBM Z é quase uma ciência preditiva.

O especialista precisa responder perguntas perigosíssimas:

O ambiente suporta a Black Friday?
O batch vai fechar no horário daqui 8 meses?
Quanto custa crescer 20%?
O Sysplex está perto do limite?
O WLM está mascarando degradação?
Existe gargalo invisível em I/O?
O consumo MSU vai explodir?
O zIIP está realmente eficiente?
O throughput real acompanha o crescimento do negócio?
O storage suporta expansão orgânica?

Capacity trabalha no território do invisível.

Quando ele acerta…
ninguém percebe.

Quando ele erra…
a empresa inteira sente.

🖥️ O PROFISSIONAL DE CAPACITY

Ele é uma mistura rara de:

engenheiro operacional
matemático corporativo
especialista em performance
analista financeiro
estrategista de infraestrutura
investigador sistêmico
arquiteto de crescimento

Ele precisa entender:

tecnologia
comportamento do negócio
sazonalidade
arquitetura
custos
performance
tendências operacionais

Porque no IBM Z…

crescimento descontrolado custa milhões.

☕ ROTINA DIÁRIA DO PROFISSIONAL DE CAPACITY

📊 Monitoramento de Consumo

Todos os dias ele analisa:

utilização de CPU
consumo MSU
uso de zIIP
paging
utilização de memória
filas JES2
throughput batch
transações CICS
locks DB2
contention
saturação de canais
resposta de aplicações
uso de DASD

O objetivo não é “olhar gráfico”.

É detectar tendências invisíveis.

🔥 DETECÇÃO DE ANOMALIAS

O profissional de Capacity aprende algo brutal:

O desastre sempre deixa sinais antes.

Ele procura:

crescimento anormal
degradação gradual
workloads desbalanceados
aumento silencioso de batch
crescimento de I/O
consumo zIIP ineficiente
explosão de transações
mudanças de perfil operacional

Pequenos desvios hoje podem virar desastre daqui 6 meses.

⚙️ ANÁLISE DE PERFORMANCE

Capacity trabalha profundamente com:

WLM
RMF
SMF
throughput
response time
dispatch delay
enqueue contention
cache behavior
coupling facility
HiperDispatch

Aqui começa a engenharia pesada do IBM Z.

🧠 CONHECIMENTOS OBRIGATÓRIOS

📈 RMF E SMF

Esses são os “olhos” do Capacity.

Sem eles, o ambiente fica invisível.

O especialista domina:

RMF Monitor I
RMF Monitor III
SMF 70-79
SMF 30
SMF 72
performance classes
workload activity
device activity
coupling activity

Ele literalmente reconstrói o comportamento do sistema usando telemetria.

⚡ WLM (WORKLOAD MANAGER)

Capacity sem entender WLM é impossível.

Porque o WLM pode:

esconder gargalos
redistribuir prioridade
mascarar degradação
alterar percepção operacional

O profissional precisa entender:

service classes
velocity
response goals
importance
discretionary workloads
enclaves
policy tuning

💾 STORAGE E I/O

Aqui mora uma das maiores armadilhas.

Muitos ambientes parecem ter CPU sobrando…

mas estão morrendo em I/O.

Capacity analisa:

cache hit ratio
IOS queueing
device response
channel path utilization
FICON saturation
DASD growth
SMS behavior

Porque I/O mal dimensionado destrói performance invisivelmente.

🌐 NETWORK E TRANSAÇÕES

Mainframe moderno é distribuído.

Capacity também acompanha:

TCP/IP
OSA
Sysplex Distributor
MQ throughput
CICS transaction rate
DB2 concurrency
API workload
OpenTelemetry metrics

Hoje IBM Z é altamente conectado.

📅 ROTINAS SEMANAIS

📊 Trending Analysis

O profissional cria tendências de:

crescimento CPU
uso storage
throughput batch
workload online
utilização zIIP
expansão de transações
crescimento de datasets

Aqui nasce o planejamento estratégico.

💣 Forecasting

Uma das tarefas mais críticas.

Ele projeta:

crescimento de negócio
impacto operacional
expansão de recursos
necessidade de upgrade
consumo futuro de licenciamento

Capacity não trabalha apenas com TI.

Ele impacta diretamente:

orçamento
planejamento financeiro
expansão corporativa

🛠️ Tuning Estratégico

O especialista sugere:

redistribuição de workloads
tuning WLM
otimização batch
uso eficiente de zIIP
melhorias de scheduling
balanceamento Sysplex
redução de gargalos

Pequenos ajustes podem economizar milhões por ano.

📆 ROTINAS MENSAIS

💰 Revisão de Custos

No IBM Z, performance e dinheiro estão ligados.

Capacity participa de:

controle de MSU
análise de software billing
consumo MLC
redução de picos
SCRT analysis
otimização de licenciamento

Aqui entra uma verdade brutal:

Às vezes reduzir 5% de CPU economiza milhões.

🔥 Planejamento de Upgrade

Ele avalia:

expansão do CPC
novos processadores
upgrade zIIP
expansão memória
crescimento storage
novos links FICON

Capacity participa diretamente da evolução física do ambiente.

🚨 TESTES DE ESTRESSE

Capacity também participa de:

testes de pico
DR simulations
Black Friday preparation
fechamento bancário
virada fiscal
sazonalidade crítica

Porque o ambiente precisa sobreviver ao pior cenário possível.

🧰 FERRAMENTAS MAIS IMPORTANTES

📊 RMF

A principal ferramenta de performance do z/OS.

📈 SMF

A caixa-preta operacional do ambiente.

⚡ MXG

Muito usado para consolidar e analisar métricas históricas.

🔍 OMEGAMON

Observabilidade moderna enterprise.

🧠 IntelliMagic

Analytics avançado para IBM Z.

📉 zBNA

IBM z Business Network Analyzer.

🖥️ IBM zPCR

Ferramenta para projeção de capacidade futura.

☠️ O PESO DA RESPONSABILIDADE

Capacity trabalha com um problema cruel:

O futuro ainda não aconteceu.

Ele precisa prever comportamento antes do desastre aparecer.

Isso exige:

experiência
estatística
visão sistêmica
interpretação operacional
conhecimento profundo do negócio

Porque crescimento linear quase nunca existe.

🚀 O FUTURO DO CAPACITY NO IBM Z

A área está mudando rapidamente.

Hoje Capacity envolve:

IA preditiva
machine learning operacional
observabilidade cognitiva
analytics em tempo real
automação adaptativa
anomaly detection
self-optimization

Mas existe uma ironia fascinante:

Quanto mais automação surge…

mais valioso fica quem realmente entende comportamento sistêmico.

☕ CONCLUSÃO — O PROFISSIONAL QUE ENXERGA O FUTURO ANTES DO CAOS

O especialista de Capacity não administra apenas recursos.

Ele administra:

crescimento
sobrevivência
estabilidade
dinheiro
continuidade corporativa

Ele é o profissional que olha para gráficos…

e consegue enxergar o amanhã.

Enquanto o resto da empresa vê:

“o sistema funcionando”.

O Capacity vê:

riscos
tendências
gargalos
explosões futuras
limites invisíveis

E talvez essa seja a definição perfeita do Capacity em IBM Z:

O homem que precisa impedir um desastre que ainda não aconteceu.

Translate

terça-feira, 8 de novembro de 2016

Engenharia Militar : Especial — Guerrilha no Campo e na Floresta

Bellacosa Mainframe e a estrategia militar especial guerrilha no campo e na floresta☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Especial — Guerrilha no Campo e na Floresta

Quando um Programador COBOL Descobre que a Natureza Também Pode Ser uma Arquitetura... e que a Maior Aliada Nem Sempre é a Tecnologia, mas o Conhecimento do Terreno

Introdução

A Natureza Como Sistema

O Campo de Batalha Invisível

Os Animes que Melhor Retratam Ambientes Rurais e Florestais

1. Princess Mononoke (Mononoke Hime)

Personagens

2. Vinland Saga

Personagens

3. Golden Kamuy

Personagens

4. Moribito: Guardian of the Spirit

Personagens

5. The Heroic Legend of Arslan

6. Kingdom

7. Goblin Slayer

8. Dororo

9. Drifters

10. The Twelve Kingdoms (Juuni Kokuki)

Engenharia Militar do Terreno

O Paralelo com IBM Z

Curiosidades

Easter Egg Bellacosa

Conclusão

Um Data Center analisado como uma fortaleza em guerra

Índice da campanha

Links completos da série Engenharia Militar

segunda-feira, 7 de novembro de 2016

Mainframe History : Especial VIII A — Tommy Flowers: O Pai Esquecido da Computação Eletrônica

☕ Um Café no Bellacosa Mainframe

Muito Antes do IBM Z Existia Outro "Z"

Especial VIII A — Tommy Flowers: O Pai Esquecido da Computação Eletrônica

O Homem que Acendeu 2.500 Válvulas, Encurtou a Segunda Guerra Mundial e Depois Voltou para Casa Como um Anônimo

Um Engenheiro dos Correios

O Mundo das Centrais Telefônicas

☕ Café com Naftalina

Um Convite para Bletchley Park

"Isso Nunca Vai Funcionar"

🔧 Oficina do Engenheiro

Nasce o Colossus

Enigma? Não.

O Computador Invisível

📦 Baú do Sysprog

O Que um Sysprog IBM Z Aprende com Tommy Flowers?

Um Herói Silencioso

O Legado

O Guia do Viajante do Tempo

domingo, 6 de novembro de 2016

☕ Os Holocrons dos Utilitários JCL: As Ferramentas Secretas que Transformam um Padawan COBOL em um Mestre do Batch

☕ Os Holocrons dos Utilitários JCL: As Ferramentas Secretas que Transformam um Padawan COBOL em um Mestre do Batch

O que são utilitários no mundo JCL?

1. IEBGENER — O utilitário que todo Padawan deveria conhecer primeiro

Exemplo

Quando evita escrever COBOL?

2. SORT (DFSORT/SYNCSORT)

Exemplo simples

Remover duplicados

Filtrar registros

OUTFIL

3. IDCAMS

DELETE

DEFINE CLUSTER

LISTCAT

REPRO

4. IEHLIST

5. IEFBR14

Criar datasets

Apagar datasets

6. IEBCOPY

Copiar membros

Selecionar membros

7. IEBUPDTE

8. ICETOOL

Contar registros

Bellacosa Mainframe e a estrategia militar especial guerrilha no campo e na floresta

☕ Um Café no Bellacosa Mainframe