Festa em Itatiba, 28º aniversario, o sultão e a família na maior festança da Rua Jose Brunelli Filho... Obrigado meus amigos vocês foram demais, foi uma festa memorável.
✨ 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
quinta-feira, 4 de fevereiro de 2010
sexta-feira, 8 de janeiro de 2010
🍺🧘 CERVEJAS JAPONESAS & FILOSOFIA ZEN
| Bellacosa Mainframe aproveitando uma tarde num izakaya e bebendo sapporo |
🍺🧘 CERVEJAS JAPONESAS & FILOSOFIA ZEN
Se no Ocidente a cerveja virou barulho, rótulo gritante e hype de fim de semana…
no Japão, cerveja é silêncio que refresca.
Hoje vamos falar de Zen, mas não aquele de camiseta.
O Zen do cotidiano, do gesto simples, do copo frio, da conversa curta.
E sim: cerveja japonesa entende Zen melhor do que muito guru.
☸️ O QUE É ZEN (SEM INCENSO, SEM VIAGEM)
Zen vem do Budismo Chan, importado da China e lapidado no Japão.
Tradução Bellacosa:
Zen é fazer o básico muito bem, sem frescura.
Nada de excesso.
Nada de enfeite inútil.
Nada de “olha como sou diferente”.
Se isso não lembra mainframe… você nunca viu um JCL limpo.
| Cervejas japonesas sapporo, asahi, kirin, suntory |
🍺 A CERVEJA JAPONESA É ZEN POR NATUREZA
As grandes cervejas japonesas (Sapporo, Asahi, Kirin, Suntory):
✔ não são doces
✔ não são exageradamente amargas
✔ não têm aromas espalhafatosos
✔ não tentam “te surpreender”
Elas apenas:
existem, cumprem seu papel e não atrapalham a refeição
Isso é Zen líquido.
🧠 PRINCÍPIOS ZEN APLICADOS À CERVEJA
🪨 1. Wabi-Sabi – Beleza na simplicidade
Wabi-Sabi valoriza o simples, o discreto, o imperfeito.
🍺 Uma Sapporo gelada não tenta ser memorável.
Ela tenta ser correta.
Assim como:
um batch que roda todo dia
um sistema que ninguém comenta porque nunca cai
🌊 2. Ma (間) – O espaço entre as coisas
No Zen, o vazio importa tanto quanto o cheio.
Na cerveja japonesa:
sabor leve
final limpo
espaço para a comida
espaço para a conversa
Não ocupa tudo.
Não grita no paladar.
🍺 É a cerveja que respeita o silêncio entre um gole e outro.
🔁 3. Repetição consciente
Zen é repetir até ficar simples.
Cervejas japonesas são feitas para:
✔ beber várias
✔ em vários dias
✔ em qualquer estação
Sem cansar.
Mainframe feelings:
“esse sistema tá aí há 20 anos e ninguém mexe”.
🍜 IZAKAYA = TEMPLO ZEN DISFARÇADO
A izakaya japonesa não é bar.
É um ritual social.
🍺 cerveja
🍢 petiscos
🗣️ conversa baixa
🧠 sem pressa
Ninguém vai para “encher a cara”.
Vai para descomprimir a mente.
Zen puro.
🎌 CERVEJAS & PERSONALIDADE ZEN
🍺 Sapporo
➡️ Zen do norte
➡️ fria, limpa, silenciosa
🍺 Asahi Super Dry
➡️ Zen urbano
➡️ seca, rápida, eficiente
🍺 Kirin Lager
➡️ Zen tradicional
➡️ maltada, clássica, conservadora
🍺 Suntory Premium Malts
➡️ Zen estético
➡️ mais aromática, mas controlada
Cada uma é um caminho (Do).
🧠 EASTER EGGS CULTURAIS
🍺 No Japão, beber em silêncio não é estranho
🍺 Espuma excessiva é vista como desleixo
🍺 O copo sempre importa
🍺 A cerveja acompanha, não lidera
👉 Diferente do Ocidente, onde a cerveja quer ser protagonista.
💬 COMENTÁRIO BELLACOSA
Cerveja japonesa me lembra mainframe porque:
ninguém elogia quando funciona
todo mundo reclama quando falta
existe para sustentar o sistema, não para aparecer
Zen é isso:
fazer bem, sem aplauso
🏁 CONCLUSÃO – ZEN NÃO É MODA
Cerveja japonesa não quer likes.
Quer continuidade.
É a cerveja de quem:
✔ já correu muito
✔ já viu hype morrer
✔ prefere estabilidade a barulho
🍺🧘
Beber uma Sapporo é um koan líquido:
“Se a cerveja não chama atenção… ela cumpriu sua função?”
quinta-feira, 7 de janeiro de 2010
📦 SMP/E for z/OS – SYSMOD Packaging
| Bellacosa Mainframe apresenta smp/e sysmod packaging |
📦 SMP/E for z/OS – SYSMOD Packaging
Entendendo MCS e técnicas de empacotamento sem dor de cabeça
🧠 Ideia central (em uma frase)
SYSMOD = conteúdo + instruções (MCS)
O como, onde e quando instalar é decidido pelas MCS.
🧩 O que existe dentro de um SYSMOD?
Todo SYSMOD tem duas coisas:
-
Texto de modificação
-
módulos
-
macros
-
source
-
dados
-
HFS / JAR
-
-
MCS – Modification Control Statements
-
instruções para o SMP/E
-
dizem onde, quando e em que ordem instalar
-
📌 Durante o RECEIVE, o SMP/E:
-
lê primeiro as MCS
-
grava tudo no SMPPTS
-
cada SYSMOD vira uma MCS entry
🧱 Tipos de elementos em DLIB / TLIB
| Tipo | O que é |
|---|---|
| Module | Código compilado/ligado |
| Macro | Fonte reutilizável |
| Source | Código fonte |
| Data | CLIST, PARM, PROC etc |
| HFS | Arquivos Unix |
| JAR | Java Archive |
🧾 Regras básicas das MCS (cai em prova)
-
Todas começam com
++ -
Colunas 1–2 →
++ -
Terminam com ponto (.)
-
Podem continuar linha se não houver ponto antes da coluna 73
-
Colunas 73–80 são ignoradas
🪪 HEADER e identificação do SYSMOD
++HEADER
-
identifica o tipo do SYSMOD
-
define o SYSMOD-ID
Tipos de SYSMOD
| Tipo | Para quê |
|---|---|
| FUNCTION | Introduz produto |
| PTF | Correção testada |
| APAR | Correção de problema |
| USERMOD | Correção local |
🧬 FMID — quem “é dono” do código
-
FMID = Function Modification ID
-
7 caracteres
-
identifica a função dona do elemento
-
em FUNCTION, o FMID é o próprio SYSMOD-ID
📌 Todo SYSMOD exceto base FUNCTION usa FMID no ++VER.
🔗 ++VER — relacionamento e dependências
O ++VER é o cérebro da compatibilidade
Regras:
-
Obrigatório
-
Deve vir logo após o HEADER
-
Define:
-
release suportado (SREL)
-
dependências
-
pré-requisitos
-
co-requisitos
-
supersedes
-
Operandos importantes
| Operando | Função |
|---|---|
| SREL | Release do sistema |
| FMID | Função dona |
| PRE | Pré-requisito |
| REQ | Co-requisito |
| SUP | Supersede |
🚦 ++HOLD — bloqueios controlados
Existem 3 tipos:
| Tipo | Quando usar |
|---|---|
| ERROR | PTF com erro |
| SYSTEM | Ação manual necessária |
| USER | Regra local |
📌 HOLD impede APPLY/ACCEPT até ser resolvido
📌 Pode vir no SYSMOD ou em HOLDDATA separado
🏗️ MCS estruturais – como o sistema é montado
++JCLIN
-
descreve como o load module é ligado
-
não executa, apenas é analisado
-
grava estrutura no TZONE
Sem JCLIN → SMP/E não sabe reconstruir load modules.
🧩 MCS de elemento (o que será instalado)
| MCS | O que instala |
|---|---|
| ++MOD | Módulo |
| ++SRC | Source |
| ++MAC | Macro |
| ++DATA | Dados |
| ++HFS | Arquivo Unix |
| ++JAR | JAR inteiro |
| ++ZAP | Patch binário |
| ++SRCUPD | Update de source |
| ++MACUPD | Update de macro |
| ++JARUPD | Update parcial de JAR |
📌 ZAP / UPD = alteração parcial
📌 DATA / HFS = sempre substituição total
☕ JAR no SMP/E (pegadinha comum)
-
++JAR→ substitui o JAR inteiro -
++JARUPD→ atualiza arquivos internos -
SMP/E usa comandos do JDK (jar x / jar u)
📦 Técnicas de empacotamento SYSMOD
Como o conteúdo chega até o SMP/E
1️⃣ Relative File (tape)
📼 Clássico IBM
-
MCS em um arquivo
-
elementos em arquivos seguintes
-
usa
RELFILE
✔️ Muito usado em FUNCTION SYSMOD
2️⃣ Inline
📄 Tudo junto
-
MCS + conteúdo no mesmo arquivo
-
registros fixos de 80 bytes
-
simples, direto
⚠️ Dados variáveis precisam de GIMDTS
3️⃣ Indirect Library
📚 USERMOD raiz
-
MCS no SMPPTS
-
conteúdo fica fora (PDS indicado no APPLY)
-
usa
TXLIB,LKLIB
✔️ Ideal para USERMOD
4️⃣ GIMZIP Archive
🌐 Moderno / rede
-
arquivo compactado no HFS
-
inclui:
-
MCS
-
elementos
-
HOLDDATA
-
-
usa:
-
GIMZIP
-
GIMUNZIP
-
RECEIVE FROMNETWORK
-
✔️ Base do Shopz / Internet delivery
❌ “What’s wrong with this picture?” (clássico de prova)
Erros comuns:
-
++MOD não é o último MCS
-
Inline com RELFILE
-
FMID ausente
-
Falta ponto final
-
SREL inválido (2038 ≠ Z038)
🧠 Resumo final (para memorizar)
🔑 RECEIVE lê MCS
🔑 APPLY instala no target
🔑 ACCEPT congela no DLIB
🔑 ++VER controla dependências
🔑 JCLIN explica como montar
🔑 Packaging define onde está o conteúdo
terça-feira, 5 de janeiro de 2010
🖥️ MVS Console Commands – Principais Comandos
| Bellacosa Mainframe apresenta MVS Commands |
🖥️ MVS Console Commands – Principais Comandos
⚠️ Aviso importante
A maioria desses comandos exige privilégio de operador (OPERCMDS,OPERATIONS, etc.).
Em ambiente restritivo, eles são substituídos por SDSF.
🔍 1️⃣ Comandos de Display (D)
Usados para consulta (os mais comuns e mais seguros).
🔹 D A,L – Displays Active Jobs
D A,L
📌 Mostra jobs ativos no sistema
🧠 Base de automação e monitoramento
🔹 D R,L – Displays Outstanding Replies
D R,L
📌 Mostra WTORs pendentes
💬 Operação vive aqui
🔹 D U,ALL – Displays Users
D U,ALL
📌 Usuários logados
⚠️ Pode ser restrito por segurança
🔹 D IPLINFO
D IPLINFO
📌 Data/hora do último IPL
🧠 Muito usado em troubleshooting
🔹 D OMVS
D OMVS
📌 Status do UNIX System Services (USS)
🔹 D XCF,STRUCTURE
D XCF,STRUCTURE
📌 Estruturas de sysplex
🧠 Ambiente Parallel Sysplex
▶️ 2️⃣ Comandos de Job Control ($ – JES2)
🔹 $D JOBS
$D JOBS
📌 Lista jobs no spool
🔹 $DA jobname
$DA PAYROLL
📌 Detalhe de um job específico
🔹 $C jobname
$C PAYROLL
📌 Cancela job
⚠️ Perigoso – exige autoridade
🔹 $P jobname
$P PAYROLL
📌 Pausa job
🔹 $A jobname
$A PAYROLL
📌 Libera job pausado
🔄 3️⃣ Comandos de Sistema (F, S, P)
🔹 S procname
S TCPIP
📌 Inicia started task
🔹 P procname
P TCPIP
📌 Para started task
⚠️ Impacto alto
🔹 F procname,command
F JES2,STATUS
📌 Envia comando para STC
🧠 Muito usado para CICS, DB2, MQ.
🧠 4️⃣ Comandos de Memória / Performance
🔹 D ASM
D ASM
📌 Status de memória auxiliar
🔹 D REAL
D REAL
📌 Memória real
🔹 D VIRT
D VIRT`
📌 Memória virtual
🔹 D IOS
D IOS
📌 Subsystem de I/O
🌐 5️⃣ Rede / Comunicação
🔹 D NET,ID=
D NET,ID=VTAM
📌 Status VTAM
🔹 D TCPIP
D TCPIP
📌 Status da pilha TCP/IP
🧾 6️⃣ Storage, Datasets e Devices
🔹 D U,DASD
D U,DASD
📌 DASDs online/offline
🔹 VARY ONLINE
VARY 1234,ONLINE
📌 Ativa device
⚠️ Altíssimo impacto
🔹 VARY OFFLINE
VARY 1234,OFFLINE
📌 Desativa device
🧯 7️⃣ Comandos de Emergência (raros)
🔹 CANCEL
CANCEL jobname
🔹 RESET
RESET`
⚠️ Normalmente restritos a operadores sênior.
🧪 8️⃣ Uso via REXX
ADDRESS MVS "D A,L"
📌 Alternativa segura:
ADDRESS SDSF ISFEXEC DA
💬 Bellacosa comenta:
“REXX + console é espada de dois gumes.”
📊 Resumo rápido (cola de operador)
| Categoria | Comando |
|---|---|
| Jobs ativos | D A,L |
| WTOR | D R,L |
| Spool JES | $D JOBS |
| Cancelar job | $C job |
| STC | S / P / F |
| IPL | D IPLINFO |
| Rede | D NET, D TCPIP |
| DASD | D U,DASD |
☕ Conclusão Bellacosa Mainframe
“Console command não é para testar —
é para saber exatamente o que está fazendo.”
Em ambiente moderno:
👑 Operador usa console
🧪 Automação usa SDSF
🔐 Auditoria dorme tranquila
segunda-feira, 4 de janeiro de 2010
⚖️ Lei da Casualidade — ou: nada acontece “do nada” (ao estilo Bellacosa Mainframe) ⚖️
| Bellacosa Mainframe e a lei da casualidade |
⚖️ Lei da Casualidade — ou: nada acontece “do nada” (ao estilo Bellacosa Mainframe) ⚖️
Eu sempre gostei de observar padrões. Talvez seja deformação profissional de quem passou a vida debugando COBOL, analisando dumps, JES2 lotado e aquele abend que “simplesmente apareceu”. No fundo, a tal lei da casualidade funciona exatamente assim: nada acontece por acaso absoluto — há sempre uma cadeia de eventos, mesmo que a gente não enxergue todas as linhas do JCL da vida.
🧠 O que é a Lei da Casualidade?
De forma simples:
👉 Todo efeito tem uma causa, ainda que seja sutil, invisível ou esquecida.
Ela aparece em várias filosofias:
No budismo, como causa e efeito (karma)
No taoismo, como fluxo natural das coisas
Na filosofia ocidental, desde Aristóteles
E no dia a dia… quando a gente diz:
“isso não aconteceu por acaso”
Casualidade não é sorte.
Casualidade é consequência acumulada.
🏗️ Origem do conceito
O termo vem do latim causalis — aquilo que gera algo.
No Japão, isso conversa fortemente com ideias como:
Inga ōhō (因果応報): causa e retribuição
Shikata ga nai: aconteceu porque tinha que acontecer
Mottainai: desperdiçar causa desequilíbrio
Nada surge do vácuo. Nem um bug crítico em produção 😄
💾 Bellacosa Mainframe Mode ON
Pensa assim:
A vida é o sistema
Suas ações são o código
O resultado é o output
Se o batch deu erro, alguém:
Alterou um copybook
Esqueceu um
IFMudou um dataset
Ignorou um warning
A casualidade é só o log dizendo:
“isso aqui já vinha sendo construído faz tempo”
🧩 Como entender na prática
✔️ Observe padrões recorrentes
✔️ Veja onde você insiste nos mesmos comportamentos
✔️ Analise os “pequenos eventos”
✔️ Aceite que nem tudo é imediato
Na vida, muito resultado é batch noturno — você só vê no dia seguinte.
🛠️ Como praticar (dicas reais)
Pare de culpar o acaso
Revise suas decisões passadas
Aja melhor hoje (o efeito vem depois)
Não ignore sinais pequenos
Tenha paciência com o processamento
💡 Dica de ouro:
Se algo se repete, não é azar. É lógica.
🥚 Easter eggs & curiosidades
No Japão, encontros “por acaso” são chamados de en (縁) — laços invisíveis
Muitos animes usam isso como motor da história (Steins;Gate, Your Name)
O “destino” japonês raramente é mágico — ele é construído
Até o caos segue regras… só que muito complexas
😏 Fofoquices filosóficas
Sabe aquela pessoa que “sempre se dá mal”?
Ou aquela que “sempre cai em boas oportunidades”?
Spoiler:
👉 não é sorte
👉 é histórico de decisões + ambiente + atitude
O universo não pune nem recompensa — ele responde.
🌏 Importância cultural
A lei da casualidade ensina:
Responsabilidade
Consciência
Humildade
Paciência
Observação
No Japão, isso molda:
Relações pessoais
Trabalho
Ética
Persistência
Resiliência silenciosa
🧾 Fechando o job (sem abend)
“Nada acontece por acaso.
A gente só esquece de olhar o log.”
Entender a lei da casualidade é aceitar que cada pequena ação escreve uma linha do nosso próprio programa de vida. E quando o resultado vem… não adianta culpar o sistema.
Porque, no fundo,
o código foi nosso.
domingo, 3 de janeiro de 2010
Como treinar IA para Mainframe
Passo a passo para evoluir legado em IA
Definição de Padrões Técnicos, Controle de Qualidade e Melhoria de Processos
Definir métricas de sucesso de qualidade específicas para COBOL em projetos de anotação de código e rotulagem de conjuntos de dados.
Desenvolver Procedimentos Operacionais Padrão (POPs), rubricas de garantia da qualidade (QA) e materiais de referência específicos para cada projeto, a fim de garantir que os resultados estejam alinhados com os padrões técnicos do cliente.
Revisar os resultados do projeto (scripts COBOL, anotações de código, exemplos de modernização de sistemas legados) em relação aos padrões definidos, sinalizando e corrigindo defeitos antes da entrega ao cliente.
Realizar verificações de QA estruturadas nos entregáveis; rastrear, sinalizar e resolver defeitos de forma eficiente para cumprir os prazos de entrega.
Devolver o trabalho aos contratados com notas de correção precisas e contexto sobre a sintaxe COBOL, lógica e padrões de sistemas legados.
Fornecer consultoria sobre ferramentas, frameworks, emuladores e melhorias de fluxo de trabalho para manter os padrões de qualidade em ambientes de mainframe e processamento em lote.
Lidar com alterações de especificações e cenários extremos (por exemplo, diferentes dialetos COBOL, codificação EBCDIC vs. ASCII, dependências de JCL) e elaborar os critérios de aceitação ou soluções alternativas correspondentes.
Organize bibliotecas de exemplos de código COBOL de "padrão ouro", exemplos de modernização e anotações de conjuntos de dados para calibração e consistência entre projetos.
Avaliação de Talentos e Melhoria de Resultados
Participe de avaliações técnicas de talentos terceirizados, incluindo a revisão de avaliações de código COBOL e avaliações baseadas em tarefas.
Revise exemplos de resultados de terceirizados e forneça feedback escrito claro e acionável para melhorar a correção, legibilidade e eficiência do código.
Desenvolva recursos de treinamento e calibração direcionados, como:
Diretrizes de qualidade de código COBOL (por exemplo, consistência de divisão de dados, estruturação de parágrafos)
Melhores práticas para código procedural limpo e de fácil manutenção
Documentação de referência para padrões de interação com sistemas legados
Padrões de rotulagem de conjuntos de dados para treinamento de modelos relacionados a COBOL
Suporte à Entrega de Projetos
Aconselhe sobre o escopo e os requisitos técnicos durante a configuração do projeto, incluindo versionamento de COBOL, integração de JCL e formatos de dados de mainframe.
Forneça orientação especializada para casos extremos e alterações de especificações, como o tratamento de copybooks, registros de comprimento variável ou integração com DB2 e VSAM.
Contribuir para as revisões pós-projeto a fim de capturar lições aprendidas e refinar continuamente os padrões.
Identificar e resumir insights do sistema do cliente, como problemas recorrentes de sintaxe, erros de lógica ou inconsistências na formatação de dados.
Criar painéis ou rastreadores de defeitos com problemas categorizados para revelar temas recorrentes e impulsionar melhorias de processo.
Conduzir análises pós-projeto para analisar tendências de defeitos e propor etapas de garantia de qualidade atualizadas, melhorias na documentação ou treinamentos de reciclagem.
terça-feira, 29 de dezembro de 2009
Que beijinho mais gostoso o Luigi e os Esquilos natalinos.
Feliz Natal do pequeno Luigi para a famiglia Bellacosa. O pequenino Luigi aprontando arte, brincando com os Esquilinhos dançantes. Na época para ele era uma loucura ouvir esses esquilinhos, ele adorava brincar, agarrar, abraçar, apertar as musiquinhas sempre fazendo bagunca com eles.