Bellacosa Mainframe apresenta Deployment Patterns

☕ Um Café no Bellacosa Mainframe

🚀 Buck Rogers no Mundo Mainframe — Deployment Patterns no Século XXV

Big Bang, Rolling, Blue-Green, Canary, Feature Toggle, Shadow Deployment, CICS, COBOL, Db2, VSAM, MQ, JCL e a estranha arte de colocar uma V2 em produção sem destruir o universo conhecido.

Imagine a cena.

O programador COBOL termina sua alteração. O compilador não reclamou. O link-edit terminou corretamente. Os testes passaram. O load module está pronto.

Na tela verde surge a mensagem que todo jovem tripulante da nave z/OS esperava:

MAXCC=0000

Ele sorri.

— Funcionou!

Buck Rogers, recém-descongelado depois de séculos, olha desconfiado para a tela.

— Funcionou onde?

Silêncio.

— Em desenvolvimento.

Buck continua:

— Com quais dados?

— Dados de teste.

— Com quantos usuários?

— Um.

— E quando colocarmos isso em produção?

Novo silêncio.

Bem-vindo ao verdadeiro problema.

Desenvolver V2 é somente metade da aventura. A outra metade é descobrir como substituir V1 sem transformar uma alteração COBOL aparentemente inocente em um incidente interplanetário.

É aqui que entram os Deployment Patterns.

E embora Big Bang, Rolling, Blue-Green, Canary e Feature Toggle sejam frequentemente apresentados usando containers, Kubernetes, microsserviços e aplicações web, seus princípios são extremamente úteis quando transportados para o universo do IBM Mainframe.

Prepare o café.

Wilma Deering já está na ponte.

Twiki está emitindo alguns bidi-bidi-bidi preocupantes.

E alguém acabou de perguntar:

“Quem vai promover isso para produção?”

🚀 CAPÍTULO 1 — Deployment não é simplesmente copiar um load module

Vamos começar com nosso sistema fictício de cartões, o BELLACARD.

Temos aproximadamente:

POS / ATM / MOBILE
        |
        v
      API
        |
        v
       MQ
        |
        v
      CICS
        |
        v
+------------------+
| AUTHORIZATION    |
|      COBOL       |
+------------------+
        |
   +----+----+
   |         |
  Db2       VSAM
   |
   v
FRAUD / LIMIT / PRODUCT

Existe hoje:

AUTHORIZATION V1

Nossa equipe desenvolveu:

AUTHORIZATION V2

A V2 introduz uma nova regra de risco para compras internacionais.

Compilamos.

Testamos.

Homologamos.

Agora precisamos colocar V2 em produção.

É tentador pensar:

V1
 ↓
V2

Mas o sistema real pode ser:

                    COPYBOOK
                       |
                       v
JCL ───────────────> COBOL <──────────── CICS
                       |
              +--------+--------+
              |        |        |
              v        v        v
             Db2      VSAM      MQ
              |                  |
              v                  v
            BATCH               API
              |
              v
           ARQUIVO
              |
              v
         DOWNSTREAM

Portanto, mudar um programa pode significar alterar uma aresta de um enorme grafo de dependências.

Essa é a primeira lição de Buck Rogers:

Deployment no mainframe não é mover um programa. É introduzir uma mudança em um ecossistema.

💥 CAPÍTULO 2 — Big Bang: todos os motores para potência máxima

Big Bang é o modelo mais simples de compreender.

Temos:

PRODUÇÃO

AUTORIZA = V1

Fazemos a implantação:

         DEPLOY
            |
            v

AUTORIZA = V2

Todos passam a executar V2.

No universo batch isso pode parecer absolutamente natural.

Imagine:

//AUTHJOB JOB ...
//STEP010 EXEC PGM=AUTORIZA
//STEPLIB DD DSN=BELLACARD.PROD.LOADLIB,DISP=SHR

Antes:

BELLACARD.PROD.LOADLIB(AUTORIZA)
                           |
                           V1

Depois:

BELLACARD.PROD.LOADLIB(AUTORIZA)
                           |
                           V2

Simples.

Mas existe uma propriedade importante:

O blast radius é enorme.

Se V2 estiver errada e todo o tráfego estiver usando V2:

BUG
 |
 +---- Cliente A
 +---- Cliente B
 +---- Cliente C
 +---- Banco A
 +---- Banco B
 +---- Canal Mobile
 +---- ATM
 +---- POS

O erro se espalha imediatamente.

Isso não significa que Big Bang seja sempre errado.

Um batch fortemente acoplado pode exigir uma mudança coordenada:

JOB001 V2
   |
   v
FILE V2
   |
   v
JOB002 V2
   |
   v
DB2

Às vezes manter V1 e V2 simultaneamente seria mais perigoso.

Portanto:

Big Bang não significa incompetência. Significa concentração temporal do risco.

🛞 CAPÍTULO 3 — Rolling: Buck troca os motores com a nave voando

Agora imaginemos quatro regiões CICS:

                 +--> CICS A
                 |
TRANSAÇÕES ------+--> CICS B
                 |
                 +--> CICS C
                 |
                 +--> CICS D

Todas utilizam V1.

Podemos atualizar gradualmente:

FASE 0

A V1
B V1
C V1
D V1

Depois:

FASE 1

A V2
B V1
C V1
D V1

Observamos.

Então:

FASE 2

A V2
B V2
C V1
D V1

Até:

A V2
B V2
C V2
D V2

Parece maravilhoso.

Não houve aquele instante dramático em que todo o universo passou simultaneamente de V1 para V2.

Mas Buck Rogers percebe alguma coisa no radar.

Durante algum tempo temos:

V1 + V2

Isso gera a pergunta mais importante do Rolling Deployment:

V1 e V2 conseguem coexistir?

👽 CAPÍTULO 4 — O inimigo não era o COBOL. Era o COPYBOOK

Imagine V1 trabalhando com:

01 CARD-RECORD.
   05 CARD-NUMBER       PIC X(16).
   05 CARD-STATUS       PIC X.
   05 CARD-LIMIT        PIC S9(9)V99 COMP-3.

V2 introduz novos campos ou altera a representação utilizada por algum fluxo.

Enquanto fazemos Rolling:

CICS A → PROGRAM V2
CICS B → PROGRAM V1

Ambos podem consumir ou produzir dados para:

Db2
VSAM
MQ
ARQUIVOS
OUTROS PROGRAMAS

Se V2 produz algo que V1 não compreende:

V2
 |
 v
NOVO LAYOUT
 |
 v
V1
 |
 v
💥

O deployment gradual transformou-se em uma armadilha.

Por isso um conceito aparentemente banal como compatibilidade de copybooks pode decidir se Rolling Deployment é seguro.

E não basta procurar quem chama o programa.

É preciso procurar quem compartilha seu contrato de dados.

🔵🟢 CAPÍTULO 5 — Blue-Green: duas Terras, uma produção

Buck Rogers encontra agora dois ambientes.

BLUE:

CICS BLUE
AUTORIZA V1

GREEN:

CICS GREEN
AUTORIZA V2

O tráfego começa assim:

                 BLUE V1
                   ↑
                   |
               100%
                   |
TRANSAÇÕES --------+
                   
                 GREEN V2
                    0%

GREEN pode ser preparado e validado.

Quando decidimos liberar:

BLUE V1   0%

GREEN V2 100%

Problema?

Voltamos:

BLUE V1 100%

GREEN V2  0%

Parece o Santo Graal do rollback.

Mas Dr. Huer chama Buck pelo comunicador:

— Capitão, temos um pequeno problema.

— Qual?

— O Db2.

Ah.

O banco de dados.

Sempre ele.

🗄️ CAPÍTULO 6 — O código voltou. Os dados não.

Imagine:

BLUE V1 ───┐
           |
           +---- DB2
           |
GREEN V2 ──┘

GREEN recebeu tráfego durante quinze minutos.

Nesse intervalo processou:

82.347 autorizações

Algumas atualizaram Db2.

Outras atualizaram VSAM.

Outras produziram mensagens MQ.

Talvez outras tenham chamado sistemas externos.

Agora alguém diz:

“Deu problema. Volta para BLUE!”

Podemos devolver o tráfego para V1 em segundos.

Mas o que fazemos com as 82.347 operações produzidas por V2?

Eis uma das lições mais importantes deste artigo:

CODE ROLLBACK
      ≠
STATE ROLLBACK

Restaurar o executável antigo não significa desfazer:

UPDATE DB2
WRITE VSAM
MQ PUT
arquivo produzido
API chamada
pagamento efetuado
evento publicado

Em sistemas financeiros isso se torna ainda mais importante porque alguns efeitos precisam ser compensados, não simplesmente apagados.

Rollback é um problema de arquitetura de estado.

🐤 CAPÍTULO 7 — Canary: mande Twiki primeiro

Imagine que Buck tenha uma ideia.

— Em vez de mandar toda a frota para aquele planeta, vamos mandar Twiki.

Twiki responde:

Bidi-bidi-bidi.

É basicamente Canary Deployment.

Começamos:

99% → AUTORIZA V1
 1% → AUTORIZA V2

Observamos.

Se tudo estiver correto:

90% → V1
10% → V2

Depois:

50% → V1
50% → V2

Finalmente:

100% → V2

Se V2 tiver um defeito catastrófico, reduzimos o número inicial de usuários afetados.

Estamos reduzindo o:

Blast Radius

Compare:

BIG BANG

BUG
 |
 v
100% usuários

com:

CANARY

BUG
 |
 v
1% usuários

Mas existe uma condição.

📡 CAPÍTULO 8 — Canary sem radar é apenas uma nave perdida

Se enviarmos 1% do tráfego para V2 mas não observarmos o que acontece, apenas demoraremos mais para descobrir o desastre.

Precisamos de telemetria.

No universo mainframe podemos pensar em indicadores técnicos envolvendo:

ABENDs
response time
CPU
transaction rate
SQLCODEs
timeouts
MQ queue depth
CICS performance
erros de aplicação

Mas Buck pergunta:

— E quantas compras estamos recusando?

Excelente pergunta.

Suponha:

V1 APPROVAL RATE = 91,4%
V2 APPROVAL RATE = 73,1%

Enquanto isso:

ABEND      = 0
SQL ERROR  = 0
CPU        = NORMAL
MQ         = NORMAL
CICS       = NORMAL

Do ponto de vista computacional:

Tudo verde.

Do ponto de vista do negócio:

Houston... quer dizer, New Chicago... temos um problema.

V2 está recusando milhares de clientes legítimos.

Daí nasce uma regra preciosa:

RC=0000 não significa que o negócio está correto.

Observabilidade moderna precisa juntar:

TECHNICAL OBSERVABILITY
          +
BUSINESS OBSERVABILITY

🚩 CAPÍTULO 9 — Feature Toggle: a arma secreta

Agora chegamos a uma diferença conceitual importantíssima.

Feature Toggle não é exatamente a mesma categoria dos outros padrões.

Big Bang, Rolling, Blue-Green e Canary respondem principalmente:

Como V2 entra no ambiente?

Feature Toggle responde:

Quando determinada funcionalidade de V2 será utilizada?

Podemos fazer deployment hoje:

AUTORIZA V2

mas manter:

NEW-RISK-SCORE = OFF

A nova lógica está instalada, porém não liberada.

Depois:

NEW-RISK-SCORE = ON

Em COBOL, conceitualmente:

IF WS-NEW-RISK-SCORE = 'Y'
    PERFORM 7000-RISK-SCORE-V2
ELSE
    PERFORM 6000-RISK-SCORE-V1
END-IF.

Temos então:

DEPLOYMENT
    ≠
RELEASE

Essa separação é extremamente poderosa.

🏛️ CAPÍTULO 10 — Mainframe fazia isso antes de virar moda

Existe uma deliciosa ironia histórica aqui.

Feature Flags parecem extremamente modernas quando aparecem em apresentações sobre Cloud Native.

Mas sistemas corporativos há décadas controlam comportamento através de:

PARÂMETROS
SYSIN
TABELAS DB2
DATASETS
CONFIGURAÇÕES
SWITCHES
REGRAS DE PRODUTO

Não estou dizendo que cada parâmetro antigo seja uma feature flag moderna.

Estou dizendo que o princípio:

“colocar código em produção sem necessariamente ativar determinado comportamento”

não nasceu ontem.

Mainframe frequentemente nos ensina que tecnologias novas são, algumas vezes, ideias antigas usando nomes novos e camisetas mais bonitas.

🧟 CAPÍTULO 11 — A Feature Flag que se recusou a morrer

Feature Toggle possui seu próprio perigo.

Começamos inocentemente:

IF FEATURE-A = 'Y'
   ...
END-IF

Depois:

IF FEATURE-A = 'Y'
   IF FEATURE-B = 'N'
      ...
   END-IF
END-IF

Cinco anos depois:

IF FEATURE-A = 'Y'
   IF FEATURE-B = 'N'
      IF FEATURE-C = 'Y'
         IF PRODUCT-TYPE = '07'
            IF OLD-MIGRATION-FLAG NOT = 'X'
               ...

Buck Rogers pede imediatamente para ser congelado novamente.

Feature Flags precisam de ciclo de vida:

CREATE
   ↓
TEST
   ↓
DEPLOY OFF
   ↓
ENABLE CANARY
   ↓
OBSERVE
   ↓
EXPAND
   ↓
100% ON
   ↓
REMOVE OLD CODE
   ↓
REMOVE FLAG

O último passo é importantíssimo.

Caso contrário criamos technical debt condicional.

👻 CAPÍTULO 12 — Shadow Deployment: o universo paralelo

Existe uma sexta estratégia que merece entrar na nave.

Imagine que estamos substituindo um algoritmo COBOL de risco.

Hoje:

RISKV1

Novo:

RISKV2

Não confiamos suficientemente em V2 para deixá-lo decidir transações.

Podemos conceitualmente executar ambos:

                     +---- RISKV1
TRANSAÇÃO -----------|        |
                     |        +--> DECISÃO REAL
                     |
                     +---- RISKV2
                              |
                              +--> SOMENTE OBSERVAÇÃO

V1 diz:

APPROVED

V2 também:

APPROVED

Excelente.

Outra:

V1 = APPROVED
V2 = DECLINED

Interessante.

Depois de grande volume:

V1 = V2       99,96%
V1 != V2       0,04%

Agora investigamos aquele 0,04%.

Isso pode ser extremamente poderoso para testar novas regras, modelos de risco ou modernizações sem entregar imediatamente a decisão de produção ao componente novo.

Mas existe uma regra fundamental:

Shadow não pode duplicar efeitos colaterais.

Se ambos executarem:

UPDATE ACCOUNT
MQ PUT
POST TRANSACTION

acabamos de transformar uma compra em duas.

O universo explodiu.

Obrigado, Buck.

🧬 CAPÍTULO 13 — Expand and Contract: preparando o Db2 para duas épocas

Imagine que V2 precise de:

RISK_SCORE

na estrutura de dados.

A abordagem ingênua seria mudar tudo simultaneamente.

Uma abordagem evolutiva pode seguir:

FASE 1

SCHEMA antigo
+
estrutura nova compatível

Depois:

FASE 2

V1 + V2 conseguem trabalhar

Depois:

FASE 3

V2 assume

Depois:

FASE 4

V1 desaparece

Finalmente:

FASE 5

estruturas antigas são removidas

É o princípio de Expand and Contract:

OLD
 |
 v
OLD + NEW
 |
 v
NEW
 |
 v
REMOVE OLD

Ele é importantíssimo quando queremos coexistência entre versões.

📦 CAPÍTULO 14 — Batch: a galáxia esquecida pelos diagramas DevOps

Muitos diagramas modernos assumem algo parecido com:

USER → LOAD BALANCER → SERVER

No mainframe podemos encontrar:

JOB001
   |
   v
FILE01
   |
   v
JOB002
   |
   v
DB2
   |
   v
JOB003
   |
   v
REPORT

Agora alteramos JOB001.

Ele passa a produzir:

LAYOUT V2

Mas JOB002 continua esperando:

LAYOUT V1

Resultado:

JOB001 V2
    |
    v
FILE V2
    |
    v
JOB002 V1
    |
    v
   💥

Portanto, em processamento batch, a unidade de deployment pode não ser um programa.

Pode ser uma cadeia inteira de processamento.

Essa é uma mudança mental importantíssima para o iniciante.

🕸️ CAPÍTULO 15 — Antes de fazer deploy, desenhe o grafo

Buck Rogers agora encontra uma ferramenta muito mais poderosa que qualquer pistola laser:

um lápis.

Antes do deployment, desenhe:

                   COPYBOOK
                       |
                       v
 JCL -------------> COBOL <------------- CICS
                       |
             +---------+---------+
             |         |         |
             v         v         v
            DB2       VSAM       MQ
             |                   |
             v                   v
           BATCH                API
             |
             v
           FILE
             |
             v
        DOWNSTREAM

Pergunte:

Quem chama?

Quem é chamado?

Quem lê os dados produzidos?

Quem escreve os mesmos dados?

Quem compartilha copybook?

Quem recebe MQ?

Quem depende do arquivo?

Quem depende da tabela?

Quem depende da semântica da informação?

Porque o risco não mora apenas nos nós.

Muitas vezes ele mora nas arestas.

🔐 CAPÍTULO 16 — Buck Rogers veste o capacete do Red Team

Deployment Patterns também criam superfícies de segurança.

Blue-Green possui dois ambientes.

Canary possui mecanismo de roteamento.

Feature Toggle possui mecanismo de ativação.

Shadow replica tráfego.

Rolling mantém versões coexistindo.

O Red Team começa a perguntar:

Quem pode alterar a feature flag?

Quem consegue mudar o routing?

Quem pode promover load modules?

Quem controla datasets de configuração?

GREEN tem as mesmas proteções de BLUE?

V1 continua acessível?

Quem pode alterar STEPLIB?

Quem controla as libraries?

Existem credenciais esquecidas no ambiente standby?

Shadow recebe dados sensíveis?

As mudanças são auditadas?

No z/OS isso pode trazer para a investigação controles e componentes relacionados a:

RACF
dataset profiles
CICS security
Db2 privileges
USS permissions
started tasks
libraries
pipeline credentials

Veja a transformação.

Começamos discutindo:

Como fazer deployment?

Agora estamos discutindo:

Quem possui autoridade para alterar o comportamento de produção?

Essa segunda pergunta é muito mais interessante para segurança.

⚔️ CAPÍTULO 17 — O rollback que existia apenas no PowerPoint

Toda reunião de mudança possui aquela pergunta:

“Tem rollback?”

E alguém responde:

“Sim.”

Buck Rogers deveria imediatamente perguntar:

“Mostre.”

Porque:

BACKUP EXISTE

não significa:

RESTORE FOI TESTADO

LOAD MODULE V1 EXISTE

não significa:

SISTEMA CONSEGUE VOLTAR PARA V1

Se V2 alterou dados, publicou eventos e disparou processos downstream, voltar o programa talvez seja apenas uma parte da recuperação.

Um plano real deveria considerar:

Código
Dados
Mensagens
Arquivos
Configuração
Permissões
Jobs
Dependências
Efeitos externos

O rollback precisa ser tratado como capacidade operacional testável, não como frase tranquilizadora em um documento.

📊 CAPÍTULO 18 — A matriz de Buck Rogers

Podemos resumir nossas estratégias assim:

Estratégia	Ideia central	Principal vantagem	Principal risco
Big Bang	V1 → V2 de uma vez	simplicidade	grande blast radius
Rolling	troca gradual	reduz exposição	coexistência V1/V2
Blue-Green	dois ambientes	troca/retorno rápidos	estado e custo
Canary	V2 recebe pouco tráfego	limita impacto	exige observabilidade
Feature Toggle	funcionalidade controlada	deploy ≠ release	dívida técnica
Shadow	V2 observa tráfego	validação realista	efeitos colaterais
Expand/Contract	evolução compatível	suporta coexistência	maior disciplina

Nenhum deles é “o melhor”.

A pergunta correta é:

Qual risco estou tentando controlar?

🚀 CAPÍTULO 19 — A combinação intergaláctica

O grande segredo é que não precisamos escolher apenas um.

Podemos ter:

                       TRANSAÇÕES
                            |
                         ROUTER
                       /         \
                      /           \
               BLUE V1          GREEN V2
                                   |
                              FEATURE FLAG
                               /        \
                             OFF         ON
                                          |
                                       CANARY
                                         1%

GREEN recebe V2.

A feature permanece OFF.

Ativamos para um pequeno grupo.

Monitoramos.

Expandimos.

Se necessário, desligamos a funcionalidade.

Se o executável inteiro apresentar problema, alteramos o roteamento.

Temos várias camadas de contenção.

É quase uma defesa em profundidade aplicada ao deployment.

👨‍💻 CAPÍTULO 20 — O programador COBOL iniciante recebe sua primeira missão

Você recebeu a seguinte solicitação:

“Alterar AUTORIZA para implementar nova regra de compras internacionais.”

Não abra imediatamente o fonte.

Primeiro investigue.

Passo 1 — Entenda a mudança

Descubra:

Regra de negócio
Entrada
Saída
Dados alterados
Efeitos colaterais

Passo 2 — Descubra dependências

Mapeie:

CALLs
COPYBOOKs
Db2
VSAM
MQ
CICS
JCL
arquivos
downstream

Passo 3 — Pergunte sobre coexistência

V1 consegue ler V2?
V2 consegue ler V1?

Passo 4 — Escolha como limitar o risco

Talvez:

Feature Toggle
+
Canary

seja melhor que simplesmente Big Bang.

Passo 5 — Defina observabilidade

Não somente:

ABEND?

Também:

Approval Rate?
Decline Rate?
Tempo médio?
Fraude?
Volume?

Passo 6 — Defina rollback

Pergunte:

Como voltar código?
Como voltar configuração?
Como tratar dados?
Como tratar mensagens?
Como tratar efeitos externos?

Passo 7 — Teste a recuperação

Porque o pior momento para descobrir que o procedimento de rollback está errado é durante o incidente.

🥚 EASTER EGG — 03:17

São 03:17.

O celular toca.

— Produção.

Buck atende.

— O que aconteceu?

— Implantamos V2.

— Qual padrão?

— Big Bang.

— Canary?

— Não.

— Feature Toggle?

— Não.

— Shadow?

— Não.

— Observabilidade?

Silêncio.

— Rollback?

Outro silêncio.

Twiki surge no corredor:

Bidi-bidi-bidi... ABEND... bidi-bidi...

Buck olha diretamente para a câmera.

Continua no próximo episódio.

☕ EPÍLOGO — O futuro chegou, mas o COBOL já estava esperando

Há algo deliciosamente Buck Rogers nessa história.

Deployment Patterns aparecem frequentemente envoltos em uma estética futurista:

Cloud
Containers
Kubernetes
GitOps
Microservices
DevOps
Progressive Delivery

E tudo isso trouxe técnicas, automação e possibilidades importantíssimas.

Mas quando olhamos para o problema essencial encontramos perguntas extremamente familiares ao mundo mainframe:

Qual versão está executando?

Quem pode promovê-la?

Quais dados ela utiliza?

Quem depende desses dados?

Como controlar sua ativação?

Como limitar impacto?

Como observar produção?

Como retornar?

Quem audita tudo isso?

Mainframe nunca esteve fora dessa conversa.

O vocabulário apenas mudou.

Talvez ontem chamássemos determinada solução de parâmetro, hoje de Feature Flag.

Talvez tivéssemos múltiplas regiões e hoje alguém reconheça nelas possibilidades associadas a Rolling ou Canary.

Talvez uma mudança coordenada durante a janela batch seja reconhecida conceitualmente como Big Bang.

Não devemos forçar equivalências técnicas onde elas não existem. Kubernetes não é CICS, uma LPAR não é um pod e trocar uma STEPLIB não transforma automaticamente um sistema COBOL em Blue-Green.

O que podemos transportar são os princípios de engenharia.

E essa talvez seja a maior lição para quem começa agora no COBOL.

O programador iniciante acredita que sua responsabilidade termina aqui:

COMPILE
   ↓
LINK
   ↓
MAXCC=0000

O engenheiro começa a enxergar:

SOURCE
   ↓
COMPILE
   ↓
TEST
   ↓
DEPLOY
   ↓
RELEASE
   ↓
OBSERVE
   ↓
VALIDATE BUSINESS
   ↓
EXPAND
   ↓
RECOVER IF NECESSARY
   ↓
REMOVE OLD VERSION

E o profissional realmente experiente ainda acrescenta uma pergunta antes de tudo isso:

“O que acontece com o resto da galáxia quando eu mudar esta linha?”

Essa é a diferença entre programar um COBOL e entender o sistema no qual aquele COBOL vive.

Buck Rogers acordou no século XXV esperando encontrar um mundo completamente diferente.

Encontrou naves espaciais, computadores avançados, cidades futuristas e tecnologias inimagináveis.

Mas, em algum canto da Federação Terrestre, provavelmente ainda existiria um sistema crítico perguntando:

IF NEW-FEATURE = 'Y'
    PERFORM NEW-LOGIC
ELSE
    PERFORM OLD-LOGIC
END-IF.

E alguém, diante da console, perguntaria:

“Tem certeza de que podemos colocar isso em produção?”

Bidi-bidi-bidi.

Talvez algumas perguntas sejam eternas. 🚀☕

Translate

sábado, 3 de setembro de 2022