segunda-feira, 29 de agosto de 2011

🏺✨KINTSUGI – quando a falha vira feature (e o bug vira legado) 🏺✨

 

Bellacosa Mainframe momento de paz e serenidade com kintsugi ao redor

🏺✨KINTSUGI – quando a falha vira feature (e o bug vira legado) 🏺✨


Eu sempre digo que o Japão tem uma habilidade quase mágica de transformar erro em filosofia. E se tem um conceito que parece ter sido escrito por um velho programador de COBOL zen, sentado num data center silencioso às três da manhã, esse conceito se chama Kintsugi.

Kintsugi (金継ぎ) significa literalmente “emenda de ouro”. É a arte japonesa de consertar cerâmicas quebradas usando laca misturada com pó de ouro, prata ou platina. Em vez de esconder a rachadura, o japonês faz exatamente o oposto: ele destaca a cicatriz. O objeto não volta a ser “como era antes” — ele se torna algo novo, único e mais valioso.

Se isso não é filosofia de vida, eu não sei o que é.


🕰️ Origem – quando o conserto virou arte

A história mais contada diz que, no século XV, o xogum Ashikaga Yoshimasa quebrou sua tigela de chá favorita. Mandou consertar na China e recebeu de volta algo remendado com grampos metálicos (bem feio, diga-se). Insatisfeito, artesãos japoneses resolveram criar um método que respeitasse a estética… e nasceu o Kintsugi.

Aqui já aparece o primeiro easter egg japonês:

não é só consertar — é respeitar a história do objeto.


🧠 Filosofia por trás do ouro

Kintsugi está profundamente ligado ao wabi-sabi — a beleza do imperfeito, do transitório, do incompleto.

Traduzindo para o nosso mundo:

  • a falha não é vergonha

  • a quebra faz parte do caminho

  • a cicatriz conta uma história

Ou, como eu diria em bom mainframe:

sistema que nunca caiu não tem histórico confiável.


🛠️ A prática do Kintsugi (spoiler: não é rápido)

Nada de cola instantânea. O processo tradicional pode levar semanas ou meses:

  1. união das partes com urushi (laca natural)

  2. tempo de cura em ambiente controlado

  3. aplicação do pó de ouro nas fissuras

  4. polimento final

É quase um batch job filosófico: lento, cuidadoso, sem pressa e sem rollback.


🗾 Importância cultural no Japão

O Kintsugi vai muito além da cerâmica. Ele influencia:

  • arte

  • arquitetura

  • literatura

  • comportamento social

  • forma de lidar com perdas e fracassos

No Japão, falhar não é o fim — é uma etapa. O que importa é como você retorna.


🎎 Curiosidades & fofoquices

  • Nem todo Kintsugi usa ouro: há versões com prata ou latão

  • Algumas peças restauradas ficam mais valiosas que as originais

  • Em animes e mangás, o conceito aparece de forma simbólica em personagens “quebrados” que retornam mais fortes (👀 sim, estou olhando para você, Naruto, Vagabond, Demon Slayer)


🎮 Dicas para entender (e viver) o Kintsugi

  • Não esconda suas falhas — aprenda com elas

  • Aceite que você não volta ao “estado original”

  • Transforme dor em narrativa

  • Use suas rachaduras como assinatura


☕ Bellacosa comenta…

Se o Japão fosse um sistema, o Kintsugi seria aquele módulo legado que ninguém ousa reescrever, mas todo mundo respeita. Ele nos ensina que não somos descartáveis por quebrar, e sim mais interessantes por ter sido consertados.

No fundo, Kintsugi é isso:
a vida não exige perfeição — exige continuidade.

E se for para remendar… que seja com ouro.

domingo, 28 de agosto de 2011

A estaçao ferroviaria em Cremona

Descansando e aguardo o trem para retornar a casa.


Em minha estadia na Italia, aproveitava todos os tempos livres para andar, feito um andarilho caminhava pelas cidades, apreciando cada cantinho. Nestes dias de liberdade, as vezes caminhava mais de 20 quilómetros.

Então ao final do dia estava mortinho, quando retornava a estação só queria um banquinho para sentar e aguardar meu trem para voltar a bat-caverna.



A maneira de Forrest Gump sentado e esperando o trem, aproveitada para conversar com as pessoas, outras vezes ficava fotografando trens, em uma destas vezes aproveitei para registrar o movimento em Cremona.


segunda-feira, 22 de agosto de 2011

O dia em que o mini Oni perdeu para o cãozinho do apocalipse

 


📜 El Jefe Midnight Lunch – Bellacosa Mainframe Logs
O dia em que o mini Oni perdeu para o cãozinho do apocalipse

Voltemos à Pirassununga, 1983 — aquele ambiente rural-urbano onde o asfalto não era bem asfalto, o silêncio não era bem silêncio, e as crianças não eram exatamente crianças… eram unidades autônomas de caos, equipadas com energia infinita, pés ligeiros e zero bom senso.

E no meu caso específico:
um pequeno Oni em modo provocação contínua.




🐕💀 O cruz-credo em miniatura – 30 cm de ódio puro

No caminho da escola, existia um ser.
Um daemon canídeo.
Uma criatura saída diretamente do IBM Hell Center, versão 30 centímetros de altura, perninhas finas, latência zero e latido com volume de sirene de teste de descompressão.

Eu tentava passar no modo stealth.
Mas a peste me detectava a 100 metros de distância, como se tivesse um RACF EXIT escrito só para identificar Bellacosa.

E começava o ataque sonoro.
Latido atrás de latido…
Um log interminável de aborrecimento.

A antipatia era mútua:
eu achava ele insuportável,
e ele achava que minha existência era uma ofensa pessoal.



🥢 A guerra fria Bellacosa vs. Mini-Cão

Em certos dias, eu no modo Oni provocador:

  • batia o pé no chão

  • arrastava galhos na grade

  • fazia tec-tec-tec-tec só pra irritar

  • e ainda olhava com cara de “chama no x1, coragem!”

Todo santo dia tinha algum episódio.
E nenhum de nós queria perder.

Mas… toda guerra tem um dia decisivo.



☠ A vingança canina – O ataque surpresa

Lá vou eu caminhando com um pote de peixinhos (não lembro por quê, mas a vida do Bellacosa é um RDD cheio de registros bizarros).
Um adolescente estava com o portão aberto e pediu para ver os peixes.
Eu, educado, entreguei o pote.

Foi quando, do fundo do inferno, saiu ele:

o mini Cavaleiro do Apocalipse, versão toy, vindo na velocidade de um I/O mal configurado.

Eu, com o dono ali do lado, não podia reagir como de costume.
Então fiz o que qualquer Oni covarde, desesperado e consciente da própria mortalidade faria:

fugi e trepei numa árvore.

E foi por pouco.
Mas o ódio canino daquele demônio de 30 cm era maior que seu tamanho.

Ele deu um salto.
Um salto digno de Olimpo canino.

E abocanhou minha panturrilha.

Não foi profundo.
Não foi sério.
Mas doeu…
e pior…
feriu o orgulho.

Meu log interno registrou:

“Erro crítico: mini-cão venceu o embate. Orgulho comprometido. Reiniciar?”

O dono capturou a fera, pediu desculpas, prendeu o mini-cerberus e quase se ajoelhou de vergonha.
Eu respondi:

— “Tá tudo bem… não foi nada…”

Por dentro?

Eu queria formatar aquele cachorro.
Com baixa densidade.
E sem backup.



🐦 Sobre animais… cada um com seu bicho

Esse episódio reforçou algo que me acompanha até hoje:
nunca fui fã de cachorros, principalmente os barulhentos.

A Vivi sempre foi o oposto: ama cães, gatos, tudo que tenha pelo e quatro patas.
Os bichinhos sempre foram dela — eu só convivia.

Eu?
Sou do time das aves.
Mas não curto gaiolas.
Gosto de liberdade.
Gosto do som de asas.
Da ideia de voar.

Mas essa conversa fica para outro capítulo.



📌 E assim termina o dia em que o Oni foi derrotado…

Derrotado por um canino de bolso.
Um microserviço do caos.
Um processo zombie cheio de dentes.

Mas faz parte da vida.
Nem sempre o herói vence.
Às vezes, quem ganha é o monstrinho de 30 cm com complexo de Napoleão.

Quando quiser, puxo mais um registro desse data set da infância.
É só mandar o comando:

CALL RARIDADE,MODE=NOSTALGIA

Bellacosa out. 🐕🔥🕶️


domingo, 21 de agosto de 2011

Viagem de trem de Milao a Monza.

Olhando pela janela do trem entre Milano e Monza.


Feito uma criança la vou eu olhando pela janelinha do trem, vendo a paisagem correndo sem fim...

E uma sensação prazeirosa, deixar a mente divagar enquanto se vê a paisagem, ouvindo o ta-tata-taaaaa ta-tata-taaaaa


Ansioso por chegar a famosa Monza, cidade que tantas historia ouvi de um amigo de outra época, o Geovanio, que como funcionário da Honda la pelos idos dos 90, fez algumas actividades nesta cidade, para auxiliar na organização a equipe Honza que participava do GP de Monza.

sábado, 20 de agosto de 2011

🔥 Error Handling Techniques no CICS

 


🔥 Error Handling Techniques no CICS

 


☕ Midnight Lunch, abend na tela e o silêncio mortal

São 12h58.
Usuário digita Enter.
A tela pisca.
ASRA.

No console, ninguém fala.
Alguém finalmente quebra o gelo:

“Isso não foi tratado…”

Hoje o almoço é pesado. Vamos falar de tratamento de erros no CICS — a diferença entre um sistema profissional e um sistema que vive de reza e IPL.


🏛️ História: quando erro virou disciplina

Nos primórdios, erro em CICS era simples:

  • Deu problema → abend

  • Debug → dump

  • Corrige → volta pra produção

Com o crescimento de sistemas 24x7, isso virou inaceitável.
O CICS evoluiu e trouxe mecanismos formais de error handling, muito antes de try/catch virar moda.

📌 CICS não evita erro. Ele oferece ferramentas para dominá-lo.


🧠 Conceito essencial (grave isso)

Erro não tratado = falha arquitetural
Erro tratado = comportamento esperado

Mainframe não tolera improviso.


🧯 Principais técnicas de Error Handling no CICS

Vamos separar por camadas — como todo bom sistema corporativo.


1️⃣ RESP / RESP2 – o primeiro escudo

O que é?

Quase todo comando CICS retorna:

  • RESP → código principal

  • RESP2 → detalhe fino do erro

Exemplo

EXEC CICS READ FILE('ARQCLI') INTO(WS-REG) RESP(WS-RESP) RESP2(WS-RESP2) END-EXEC.

Boa prática

  • Sempre testar RESP

  • Nunca confiar que “vai dar certo”

📌 RESP ignorado é bug incubado.


2️⃣ HANDLE CONDITION – o guarda-costas antigo

O que é?

Permite capturar condições específicas e redirecionar o fluxo.

EXEC CICS HANDLE CONDITION NOTFND(LABEL-NOTFND) DUPREC(LABEL-DUP) END-EXEC.

Vantagens

✔ Simples
✔ Muito usado em código legado

Riscos

❌ Global demais
❌ Difícil de rastrear
❌ Pode mascarar erro

📌 HANDLE CONDITION é faca de cozinha: útil, mas perigosa.


3️⃣ IGNORE CONDITION – o tapa pra debaixo do tapete

O que é?

Ignora explicitamente uma condição.

EXEC CICS IGNORE CONDITION NOTFND END-EXEC.

⚠️ Use só quando:

  • A condição é esperada

  • Você sabe exatamente o impacto

📌 IGNORE CONDITION sem comentário é crime técnico.


4️⃣ HANDLE ABEND – o airbag

O que é?

Intercepta abends CICS antes de matar a transação.

EXEC CICS HANDLE ABEND PROGRAM('ABENDPGM') END-EXEC.

O que dá pra fazer?

  • Logar contexto

  • Gravar TDQ/TSQ

  • Avisar monitoria

  • Encerrar com dignidade

📌 HANDLE ABEND não evita o erro. Evita o caos.


5️⃣ ABEND explícito – erro controlado é maturidade

Às vezes, abendar é a decisão correta.

EXEC CICS ABEND ABCODE('APPL') NODUMP END-EXEC.

Use quando:

  • Integridade foi comprometida

  • Continuar é mais perigoso

  • Auditoria exige parada

📌 Abend consciente é melhor que sucesso falso.


🛠️ Passo a passo Bellacosa (como tratar erro direito)

1️⃣ Capture RESP / RESP2
2️⃣ Decida: recuperar ou encerrar
3️⃣ Registre contexto (log)
4️⃣ Informe o usuário de forma clara
5️⃣ Garanta consistência de dados

📌 Tratamento de erro também é UX.


⚠️ Erros clássicos (easter eggs mainframe)

🐣 RESP nunca testado
🐣 HANDLE CONDITION genérico demais
🐣 IGNORE CONDITION sem explicação
🐣 Dump infinito em produção
🐣 Abend sem log

📌 Todo ASRA famoso começou assim.


📦 Integração com TSQ, TDQ e logs

Boas práticas:

  • TDQ para log de erro

  • TSQ para contexto temporário

  • SMF para auditoria

  • Integração com monitoria (OMEGAMON, Instana)

📌 Erro que não é logado vai voltar.


📚 Guia de estudo para mainframers

Domine estes tópicos:

  • CICS Conditions & RESP codes

  • Abend codes (AEI0, ASRA, APCT)

  • Program Control error handling

  • Recovery & Backout

  • Logging e monitoramento

📖 Manual essencial: CICS Application Programming Guide


🤓 Curiosidades de boteco mainframe

🍺 HANDLE CONDITION é mais antigo que Java
🍺 Muitos sistemas “estáveis” vivem à base de IGNORE CONDITION
🍺 O melhor log é o que nunca precisa ser lido
🍺 Já vi HANDLE ABEND salvar auditoria milionária


💬 Comentário El Jefe Midnight Lunch

“Erro não mata sistema.
Falta de tratamento, sim.”


🚀 Aplicações reais hoje

  • Sistemas bancários 24x7

  • Processamento de cartões

  • Governo e seguradoras

  • Plataformas críticas globais


🎯 Conclusão Bellacosa

CICS não exige perfeição.
Exige responsabilidade.

Quem trata erro direito:

  • Dorme melhor

  • Evita incidente grave

  • Ganha respeito do operador

🔥 Error handling não é opcional. É caráter técnico.


sábado, 9 de julho de 2011

🔥 CICS Transaction Server for z/OS 4.x

Bellacosa Mainframe apresenta CICS 4.2

 🔥 CICS Transaction Server for z/OS 4.x



☕ Midnight Lunch no meio da evolução

Se o CICS 3.x foi a virada que conectou o mundo transacional ao HTTP + Web Services, então o CICS 4.x foi o momento em que o CICS ganhou maturidade corporativa para o novo milênio — consolidando padrões, melhorando integração e abrindo portas para mashups e aplicações modernas por décadas.

Vamos entender esta versão com história, contexto, detalhes técnicos, easter eggs e o velho comentário Bellacosa.


📅 Linha do Tempo 4.x

VersãoData de LançamentoFim de Vida
CICS TS 4.12009Fora de suporte hoje*
CICS TS 4.22011Fora de suporte hoje*

* IBM oficialmente encerrou essas versões há muitos anos, substituídas por séries 5.x e posteriores.


CICS 4.2

🆕 O que há de novo nas séries 4.x

💫 CICS TS 4.1 — o “CICS com Web 2.0”

📍 Lançado em 2009 com foco no novo mundo conectado:

✔ Detecção não invasiva de business events
✔ Atom feeds e interfaces RESTful
✔ Integração com mashups e aplicativos Web 2.0
CICS Explorer simplificando desenvolvimento & gestão

🧠 Bellacosa comenta:

“Esta foi a primeira vez que o CICS deixou de ser apenas ‘transação e Web Services SOAP’ para passar a se conectar com tecnologias event-driven e interfaces mais modernas.”

👉 É aqui que o CICS ganhou pernas para participar de aplicações situacionais e não apenas sistemas lineares.


🚀 CICS TS 4.2 — robustez e inovação real

📍 Lançado em 2011, 4.2 trouxe foco técnico profundo:

🔹 Eventos aprimorados

  • Novos system events

  • Melhor ciclo de vida para eventos

  • “Assured events” para garantir entrega

🔹 Java ampliado

  • Novo ambiente Java 64-bit

  • Melhor desempenho e integração

🔹 Mais de 50 requisitos graduados pela comunidade

  • Segurança

  • Serviço

  • Operações

🧠 Bellacosa insight:

“4.2 foi o primeiro CICS a realmente ouvir milhares de clientes corporativos e converter esses pedidos em funcionalidades reais.”


🧪 Melhorias e Mudanças Centrais

💡 REST + Atom Feeds — Abertura para consumo de dados e integração com aplicações situacionais e mashups sem middleware pesado.
💡 Eventos nativos — Antes dos padrões modernos de event streaming, CICS já sabia identificar, produzir e gerenciar eventos de negócio.
💡 CICS Explorer como ponto de convergência — Não mais apenas consoles 3270; os administradores e desenvolvedores ganharam IDE gráfico para operar e explorar o CICS.
💡 Melhor suporte Java — Consolidação da tecnologia para uso transacional em z/OS.


🧠 Curiosidades, Eastereggs e Insights Bellacosa

🍺 REST antes do JSON-on-everything: A geração 4.x começou a empurrar CICS em direção a “real mashup” e integração com portais — numa era em que ninguém ainda chamava isso de microservices.

🍺 CICS Explorer era um fenômeno: Ferramenta amplamente esquecida hoje, mas antes do VS Code, já servia como primeira janela gráfica para CICS no mundo corporativo.

🍺 Java 64-bit não foi um luxo: Empresas que hoje rodam Spring Boot + CICS devem parte dessa jornada de integração ao suporte e maturidade começados em 4.2.


🧠 Exemplo de impacto em produção — “O Banco que virou Web em 2010”

Em 2010, um grande banco tinha seu core em CICS green screen + TS 3.x.
Quando migraram para 4.1, eles:

  1. Criaram Atom Feeds para integrações com portais internos

  2. Implementaram REST para acessar contas em tempo real

  3. Integraram dashboards situacionais sem passar por WebSphere tradicional

💬 Bellacosa comenta:

“Esse foi o primeiro cliente onde o ‘frontend’ deixou de ser 3270… sem perder desempenho e com integridade transacional total.”


🧠 Dicas importantes para mainframers

Estude eventos nativos: o sistema de “system events” em 4.x é ancestral das práticas modernas de event-driven architecture.
Domine CICS Explorer: entender essa ferramenta faz você ver CICS como um servidor de aplicações, não apenas um COBOL runner.
Java 64-bit é legado útil: é a base de como CICS interage hoje com cargas de trabalho modernas.


📜 Fim de Vida

As versões 4.1 e 4.2 já estão fora de suporte oficial há bastante tempo.
O foco da IBM migrou para as séries 5.x e 6.x que trazem suporte oficial até meados de 2025 e além (Ex.: CICS TS 5.5 EOS 30 set 2025).

Mesmo assim, a 4.x é um marco na evolução moderna do CICS.


🎯 Conclusão Bellacosa

CICS TS 4.x não foi apenas um release.
Foi o catalisador que transformou o CICS de servidor transacional puro em servidor de aplicações conectadas.

Ele trouxe:
✔ Eventos de negócio
✔ RESTful interfaces
✔ CICS Explorer
✔ Java 64-bit
✔ Integrabilidade corporativa real

🔥 4.x é onde o CICS começou a conversar com o mundo moderno — sem perder a alma transacional.


sexta-feira, 8 de julho de 2011

🔥 File Handling no CICS

 


🔥 File Handling no CICS



☕ Midnight Lunch, arquivo aberto e o NOTFND clássico

12h55.
A transação entra.
O operador olha o console.
Você já sabe o final:

NOTFND

E alguém pergunta, com a serenidade de quem já sofreu:

“Esse arquivo está OPEN?”

Hoje o prato principal é File Handling no CICS — VSAM, controle de concorrência, comandos, erros clássicos e aquela sabedoria que só o mainframe ensina com dor.


🏛️ História: arquivos online antes do “real-time” virar moda

Antes de:

  • NoSQL

  • APIs

  • Microservices

o CICS já fazia acesso concorrente a arquivos VSAM, com controle transacional, locking fino e integridade garantida.

📌 File Handling no CICS é um tratado de engenharia.


🧠 Conceito essencial (grave isso)

Arquivo no CICS não é batch
Cada READ é uma negociação com o sistema

Aqui não existe “abre, lê tudo e fecha”.


📂 Tipos de arquivos usados no CICS

📌 VSAM KSDS

  • O mais comum

  • Acesso direto por chave

  • Ideal para online

📌 VSAM ESDS

  • Acesso sequencial

  • Muito usado para log

📌 VSAM RRDS

  • Acesso relativo

  • Menos comum, mas existe

📌 Se não é VSAM, pense duas vezes antes de usar no CICS.


🛠️ Principais comandos de File Handling

🔹 READ

Lê um registro por chave ou sequencial.

EXEC CICS READ FILE('ARQCLI') INTO(WS-REG) RIDFLD(WS-CHAVE) RESP(WS-RESP) END-EXEC.

🔹 WRITE

Inclui novo registro.

EXEC CICS WRITE FILE('ARQCLI') FROM(WS-REG) RIDFLD(WS-CHAVE) END-EXEC.

🔹 REWRITE

Atualiza registro existente.

EXEC CICS REWRITE FILE('ARQCLI') FROM(WS-REG) END-EXEC.

🔹 DELETE

Remove registro.

EXEC CICS DELETE FILE('ARQCLI') RIDFLD(WS-CHAVE) END-EXEC.

🔐 Concorrência e locking (onde mora o perigo)

READ com UPDATE

  • Bloqueia o registro

  • Exige REWRITE ou DELETE depois

READ sem UPDATE

  • Leitura limpa

  • Sem lock

📌 UPDATE sem REWRITE é pecado capital.


🧠 File Handling e transação (UOW)

CICS garante:

  • Atomicidade

  • Consistência

  • Rollback automático em caso de abend

Se a task cai:

  • Updates não commitados voltam

  • Locks são liberados

📌 CICS faz isso há décadas.


⚠️ Erros clássicos (easter eggs)

🐣 NOTFND tratado como erro fatal
🐣 DUPREC em produção às 14h
🐣 READ UPDATE esquecido (deadlock)
🐣 Arquivo fechado no CICS

🐣 DELETE sem validar dependências

🐣 Ignorar RESP1 / RESP2

📌 Todo file handling errado vira incidente.


🛠️ Passo a passo Bellacosa (fluxo seguro)

Defina intenção (ler ou alterar)

1️⃣ READ sem UPDATE para validar
2️⃣ READ UPDATE se for alterar
3️⃣ Tratar NOTFND e DUPREC
4️⃣ REWRITE ou DELETE imediatamente
5️⃣ Logar erros relevantes

📌 Lock curto é sinal de maturidade.


📦 Integração com Recovery

  • Arquivos participam da UOW

  • Backout automático se houver erro

  • Logs garantem consistência

📌 CICS é ACID antes do termo existir.


📦 Integração com TSQ, TDQ e logs

Boas práticas:

  • TSQ para staging temporário

  • TDQ para auditoria de alterações

  • Log funcional separado de log técnico

📌 Arquivo sem log é auditoria esperando desastre.


📚 Guia de estudo para mainframers

Estude com carinho:

  • VSAM internals

  • CICS File Control

  • Locking e ENQ/DEQ

  • RESP / RESP2

  • Recovery e backout

  • CEMT I FILE

📖 Manual essencial: CICS File Control Guide


🤓 Curiosidades de boteco mainframe

🍺 CICS controla lock em nível de registro
🍺 Muitos sistemas ainda usam ESDS como log
🍺 RRDS quase ninguém usa, mas ele está lá
🍺 Já vi READ UPDATE sem REWRITE travar região inteira

🍺 KSDS já sustentou banco inteiro
🍺 READ UPDATE mal usado é vilão silencioso
🍺 CICS libera lock até em abend (milagre técnico)
🍺 Já vi arquivo “perfeito” virar gargalo por lógica ruim


💬 Comentário El Jefe Midnight Lunch

“Arquivo em CICS é compromisso.
Leu com UPDATE? Case e honre.”

        “Arquivo não trava sistema.

        Programador que segura lock, sim.” 


🚀 Aplicações reais hoje

  • Core bancário

  • Cadastro de clientes

  • Processamento de seguros

  • Sistemas governamentais

  • Plataformas 24x7 

  • Sistemas de pagamento

  • Seguros e previdência

  • Governo e utilities

  • Ambientes híbridos VSAM + DB2


🎯 Conclusão Bellacosa

File Handling no CICS é simples na sintaxe
e profundo no impacto.

É disciplina, tempo e respeito à concorrência.

Quem domina:

  • Evita deadlock

  • Mantém integridade

  • Ganha confiança do ambiente

🔥 Arquivo mal tratado não perdoa.

🔥 CICS não é lento. Lento é o desenho errado.