Uma transação CICS não é uma requisição HTTP

A modernização de CICS mais perigosa é a que parece óbvia. Uma equipe encontra um código de transação, envolve a entrada em JSON, cria uma rota POST e declara que entendeu o limite. As telas funcionam na demonstração. Sob tráfego real aparecem envios duplicados, estado desatualizado, commits antecipados e atualizações distribuídas pela metade.

Uma transação CICS é uma tarefa com recursos gerenciados pelo CICS, regras de recuperação e um fim preciso. Uma requisição HTTP é uma troca de transporte na qual o servidor pode perder o cliente antes que qualquer lado saiba o que ocorreu. As duas podem carregar o mesmo comando de negócio, mas não definem a mesma unidade de trabalho. Uma reescrita segura preserva a máquina de estados do negócio e explicita o limite do commit, em vez de deixar o framework web inventá-lo.

O limite da tarefa determina a semântica

Uma transação CICS começa quando o CICS anexa uma tarefa e termina quando o programa de nível superior devolve o controle ou a tarefa é encerrada. Essa tarefa pode chamar vários programas com LINK ou transferir o controle com XCTL. Essas chamadas não criam novas transações só porque o controle cruza um módulo. O ID da transação escolhe um ponto de entrada. Ele não descreve método de requisição, recurso ou contrato de resposta.

HTTP oferece outro invólucro. Uma requisição tem cabeçalhos, corpo, conexão e resposta, mas o protocolo não sabe quais gravações formam uma ação de negócio. O servidor pode fazer commit antes de enviar a resposta. O cliente pode expirar depois do commit e tentar novamente. Um proxy pode repetir uma requisição que a aplicação nunca classificou como segura. Nada disso tem equivalente direto no modelo de tarefas CICS.

A primeira pergunta de projeto não é qual URL substituirá um ID de quatro caracteres. Pergunte quais mudanças recuperáveis devem ter sucesso ou falhar juntas, qual entrada inicia a decisão e qual fato durável prova sua conclusão. Só então uma rota pode representar o comando corretamente.

Essa distinção também evita um erro comum de granularidade. Uma interação de tela pode executar uma tarefa CICS, vários programas vinculados e mudanças em Db2 e recursos CICS recuperáveis. Separar cada programa em um serviço de rede introduz falhas dentro de uma unidade que antes falhava inteira. Juntar várias etapas pseudoconversacionais numa requisição longa comete o erro oposto: mantém trabalho aberto enquanto uma pessoa pensa.

Trate o grafo de chamadas legado como evidência, não como arquitetura alvo. Marque início de tarefas, arestas LINK e XCTL, mudanças em arquivos e bancos, mensagens de saída, syncpoints explícitos e retornos do nível superior. Os limites do trabalho recuperável raramente coincidem com telas ou programas.

A pseudoconversa libera a tarefa entre telas

Uma aplicação pseudoconversacional parece uma sessão para o usuário, mas executa uma série de tarefas curtas. A tarefa recebe entrada, reconstrói contexto suficiente, envia a próxima tela, nomeia a transação da entrada seguinte, passa dados de continuação e volta ao CICS. Enquanto o usuário lê, nenhuma tarefa da aplicação espera pela resposta.

A documentação CICS da IBM descreve isso como transações não conversacionais inseridas numa sequência. O projeto economiza memória e evita prender recursos exclusivos durante o tempo de reflexão humano. A conversa aparente é uma experiência do usuário, não uma transação contínua.

Uma saída COBOL simplificada costuma ter este formato:

       EXEC CICS SEND MAP('ACCT1') MAPSET('ACCT')
       END-EXEC
       EXEC CICS RETURN
            TRANSID('AC02')
            COMMAREA(WS-CONTINUATION)
            LENGTH(WS-CONTINUATION-LEN)
       END-EXEC

RETURN TRANSID normalmente não chama AC02 imediatamente. Ele informa ao CICS qual transação receberá a próxima entrada do terminal. A tarefa atual termina. Quando a entrada chega, o CICS anexa uma nova tarefa e o primeiro programa pode acessar a COMMAREA transferida. Um channel também pode cumprir essa função.

Mapear a sequência para um único objeto de sessão HTTP costuma ocultar duas coisas independentes. O navegador tem estado de apresentação, como página atual e campos editáveis. A aplicação tem estado de workflow, como conta escolhida, versão lida, permissões verificadas e comandos permitidos. A segunda categoria precisa de representação versionada no servidor ou token resistente a adulteração. Um mapa de sessão na memória do processo não é durável nem claro o bastante.

O limite moderno deve expor cada decisão do usuário como comando curto. Um GET busca uma projeção para exibição. Um POST envia uma decisão contra uma versão do workflow. Nenhuma transação de banco fica aberta enquanto o navegador espera. Isso se aproxima da intenção operacional da pseudoconversa, embora o transporte seja diferente.

Uma COMMAREA é contrato de continuação, não sessão

Uma COMMAREA é um contrato de bytes entre programas ou tarefas sucessivas. O copybook dá significado a esses bytes. Ela pode conter código de função, identificadores, indicadores, campos de tela, códigos de retorno e dados para a tarefa seguinte. Também pode guardar resíduos históricos que nenhum caminho ativo lê. Chamar a estrutura inteira de estado de sessão evita a análise exigida pela migração.

Numa pseudoconversa, o CICS mantém a COMMAREA para o primeiro programa da tarefa seguinte. A IBM documenta um limite importante: a COMMAREA não é recuperável. Se uma tarefa faz commit de uma mudança no banco e prepara bytes de continuação, esses bytes não viram parte do mesmo recurso recuperável só porque o CICS os transporta.

O limite prático de tamanho também alerta contra tratá-la como armazenamento de objetos. O máximo teórico documentado para RETURN fica perto de 32 KB, com recomendação histórica da IBM de usar menos. Channels e containers removem a restrição de uma única COMMAREA e oferecem compartimentos nomeados, mas não tornam a continuação uma verdade durável do negócio.

Decodifique cada COMMAREA em três categorias. Identidade de negócio inclui valores estáveis como cliente, sinistro ou pedido. Controle do workflow inclui etapa, função, ação anterior e versão otimista. Resíduo de apresentação inclui rótulos copiados, literais da tela, cursor e campos que podem ser consultados de novo. Guarde o estado do negócio, modele o controle explicitamente e descarte a apresentação salvo quando ela afetar o comportamento observável.

O tratamento do comprimento faz parte do contrato. Um programa COBOL receptor costuma conferir EIBCALEN antes de ler DFHCOMMAREA; versões posteriores do copybook podem acrescentar campos. Um decodificador JSON que exige todo campo novo pode ser menos compatível que o programa antigo. Registre comprimentos aceitos, inicialização, convenções de espaços e zeros, conversão EBCDIC, decimais compactados e ramos de redefinição antes de projetar um substituto tipado.

Não serialize o copybook como um JSON enorme e chame isso de preservação. Isso expõe o layout de memória como API pública, permite que clientes controlem campos indevidos e transforma cada mudança no copybook em mudança de API. Traduza os bytes para um comando com intenção clara e mantenha a entrada bruta apenas em testes e evidências de auditoria quando a política permitir.

Um syncpoint confirma uma unidade de trabalho, não uma resposta

O CICS confirma mudanças recuperáveis num syncpoint. A aplicação pode executar EXEC CICS SYNCPOINT, e o CICS também cria um implícito quando uma tarefa superior termina normalmente. Um abend costuma disparar o backout dinâmico das mudanças recuperáveis na unidade atual. Esse ciclo não tem relação automática com uma resposta HTTP ter chegado ao chamador.

A consequência passa despercebida num wrapper. Suponha que a tarefa atualize Db2, escreva numa fila recuperável, retorne normalmente e o gateway perca a conexão antes da resposta. O CICS fez commit. O chamador vê timeout. Se o substituto interpretar timeout como falha e repetir sem regra de idempotência, executará a ação duas vezes.

Também há a falha inversa. Um handler web pode gravar 200 OK num buffer e depois falhar quando o commit ocorre após o retorno do código. Abstrações do framework fazem a construção da resposta parecer conclusão, embora a conclusão durável ainda não tenha ocorrido. O substituto deve definir sucesso como resultado confirmado e organizar a resposta em torno desse fato.

Inventarie todo syncpoint explícito em vez de supor que só existe o fim da tarefa. Um syncpoint fecha a unidade atual e abre outra enquanto a tarefa continua. Um rollback reverte apenas mudanças desde o último ponto. Se um programa confirma uma linha de auditoria no meio e depois desfaz uma conta, envolver todo o handler numa transação muda a recuperação visível.

Efeitos não recuperáveis exigem tratamento separado. Uma chamada externa, um e-mail entregue a um sistema não transacional ou uma gravação não recuperável não volta com o Db2. A aplicação antiga pode depender da ordem, das tentativas ou do reparo pelo operador. Preserve o resultado, não a ficção de que uma transação da linguagem controla todo recurso.

Commit em duas fases não se substitui por tentativas

O commit em duas fases coordena gerenciadores recuperáveis numa unidade distribuída. Na primeira fase, participantes se preparam e prometem cumprir a decisão. Na segunda, o coordenador manda confirmar ou desfazer. Se a comunicação falha após a preparação, um participante pode ficar em dúvida até conhecer a decisão. Essa incerteza é estado do protocolo, não erro comum da aplicação.

O CICS coordena trabalho distribuído entre recursos e conversas compatíveis. A documentação da IBM diz que um processo distribuído deve ter um iniciador do syncpoint, enquanto agentes podem aceitar ou forçar rollback. O gerenciador de recuperação registra estado suficiente para ressincronizar quando a conexão volta. Uma cadeia HTTP não oferece isso por padrão.

Substituir a unidade por serviço A chama B e tenta de novo no erro cria uma lacuna sem dono. Se B confirma e A perde a resposta, A não sabe se deve repetir, compensar ou informar sucesso. Repetir pode duplicar o efeito. Compensar pode desfazer algo que não ocorreu. Retornar erro pode dizer que falhou uma ação já concluída.

Há dois padrões honestos. Mantenha trabalho atômico num limite transacional se os dados puderem ficar sob um gerenciador. Se serviços precisam possuir dados separados, use workflow explícito com comandos duráveis, consumidores idempotentes, outbox ou registro atômico equivalente e compensações como operações do negócio. O segundo abandona atomicidade imediata e deve expor pendente, concluído, rejeitado e reparo.

Não chame o segundo de commit em duas fases. Uma saga coordena commits separados e possíveis compensações. O commit em duas fases coordena uma decisão entre participantes preparados. Confundi-los promete atomicidade e implementa reparo posterior.

A falha comum do wrapper tem sequência precisa

A análise mais útil acompanha um comando pelo limite e registra o que cada lado sabe. Considere uma tarefa CICS de pagamento exposta por POST. Ela confere a conta, atualiza Db2, grava um registro recuperável para processamento posterior e retorna normalmente.

1. O cliente envia uma requisição com referência P7319.
2. O gateway inicia a tarefa CICS e espera.
3. A tarefa atualiza os dois recursos e chega ao syncpoint final.
4. O CICS faz commit, mas a conexão fecha antes de a resposta chegar.
5. O cliente tenta novamente por causa do timeout, e outra tarefa recebe o mesmo comando.

Se o programa gera nova referência a cada chamada, a segunda tarefa não reconhece a primeira. Se apenas confere o saldo, as duas podem passar. Se HTTP cria um token de idempotência fora do commit da mudança, uma falha pode deixar token e pagamento em desacordo.

A correção começa com ID de comando estável no cliente e uma reivindicação atômica. Na unidade que confirma o pagamento, guarde ID, impressão digital da requisição, estado e referência do resultado. Duplicata com a mesma impressão devolve o resultado. O mesmo ID com outro conteúdo é conflito. Resultado ainda pendente recebe resposta pendente verdadeira, não nova tentativa cega.

Uma resposta mínima pode ser:

{
  "command_id": "P7319",
  "workflow_version": 12,
  "status": "completed",
  "result_ref": "PAY-88421"
}

Esse registro faz mais que eliminar duplicatas. Dá à operação uma resposta durável quando o transporte é ambíguo. Também permite igualar o resultado confirmado do sistema antigo sem fingir que entrega TCP e commit eram um evento.

Modele o limite como comandos e estados

O novo limite deve mostrar intenção do negócio, estado do workflow e dono do commit. Comece com tabela de transições, não controllers. Para cada comando, nomeie estados anteriores, versão, validação, gravações recuperáveis, efeitos externos, estado resultante e comportamento duplicado.

Um envelope útil é deliberadamente menor que a COMMAREA:

{
  "command_id": "7f6c2b1a",
  "workflow_id": "CLAIM-2048",
  "expected_version": 4,
  "action": "approve",
  "input": {
    "amount": "125.00",
    "currency": "USD"
  }
}

O handler carrega CLAIM-2048, verifica versão 4 e transição approve, aplica regras, grava estado e resultado numa transação local e devolve o resultado salvo. Se o trabalho posterior não puder participar, o mesmo commit grava uma outbox. Um dispatcher repete a entrega sem repetir a transição.

Mantenha conceitos de protocolo fora do domínio. Status HTTP descrevem a troca e devem ser mapeados a partir dos resultados. Versão antiga pode virar 409 Conflict. Comando concluído com a mesma impressão devolve o resultado. Comando aceito de modo assíncrono pode devolver 202 Accepted com referência. São políticas do limite, não regras de conta.

O próximo ID pseudoconversacional vira uma decisão de transições permitidas, não redirecionamento disfarçado. A interface pergunta ao workflow quais ações existem. O servidor as impõe. Um chamador não pula da revisão à conclusão adivinhando uma rota.

O projeto também elimina afinidade de terminal sem perder sequência. Qualquer instância trata o comando seguinte porque o estado durável guarda versão e resultado. Se algum estado fica no cliente, assine, versione, valide a idade e espere repetição. Não coloque autoridade, preço ou permissão num token sem assinatura.

Idempotência precisa de contrato de recuperação

Um cabeçalho não torna um comando seguro. O sistema precisa de regras de escopo, persistência, comparação, concorrência, retenção e recuperação. Sem elas, ele apenas decora a mesma falha ambígua.

Limite a chave ao ator e operação. Vincule a uma impressão canônica. Imponha unicidade na transação que possui a mudança. Devolva o resultado apenas se a impressão coincidir. Retenha registros pela janela de repetição do negócio, não por expiração conveniente do cache.

Duplicatas concorrentes precisam de um vencedor. Restrição única ou linha bloqueada reivindica a execução. As outras devem ver pending e consultar, ou esperar com limite, não reiniciar. Se o vencedor cai antes do commit, reivindicação e mudanças voltam juntas. Se cai depois, outros encontram o registro concluído.

Recuperação também precisa de estados visíveis. received, completed e rejected cobrem o caminho limpo; dispatch_pending, compensation_pending e manual_review descrevem trabalho além de limite não transacional. Não transforme tudo em HTTP 500. O operador precisa de IDs, última transição durável, efeito tentado e próxima ação segura.

Tentativas pertencem à camada que sabe se a operação pode ser repetida. Uma biblioteca pode repetir conexão ou leitura. Não deve repetir em silêncio um POST sem contrato. Internamente, um dispatcher repete porque o consumidor deduplica por ID e o produtor já confirmou a intenção.

Isso é mais estrito que muitos wrappers CICS, mas expressa a proteção antes dada pela recuperação e pelos syncpoints coordenados. Ao cruzar HTTP e bancos independentes, a aplicação deve assumir a incerteza.

O adaptador deve declarar quem controla o commit

Um adaptador HTTP pode ficar fora do CICS, dentro de uma região ou atrás de gateway e Distributed Program Link. A posição muda latência e operação, mas o dono do commit importa mais. Quem retorna sucesso deve saber que a unidade confirmou e nunca sugerir que uma chamada remota participa da transação local sem coordenador real.

Um adaptador externo fino trata a transação como processador com resultado de transporte ambíguo. Envia ID estável, espera e consulta após timeout. Não abre transação local, chama CICS, atualiza sua tabela e supõe uma ação conjunta. Sem coordenação são dois commits e uma lacuna.

Com DPL vale o mesmo cuidado. O servidor vinculado nem sempre possui o syncpoint. A IBM documenta que sem SYNCONRETURN ele não pode emitir um independente; o cliente possui a unidade distribuída. Com SYNCONRETURN, o servidor confirma ao retornar, mas separa suas mudanças do trabalho anterior do chamador. É decisão transacional, não ajuste de desempenho.

Antes de posicionar, responda quatro perguntas:

• Qual processo atribui o ID estável?
• Qual recurso guarda o resultado autoritativo?
• Qual coordenador cobre os participantes?
• Como o chamador resolve timeout sem repetir o efeito?

Se há dois bancos e nenhum coordenador, projete limite assíncrono. Confirme comando e outbox juntos na origem. Deixe o CICS reivindicar o ID e guardar resultado com a atualização. Concilie confirmações sem confundir entrega com commit. Isso acrescenta estados que descrevem incerteza existente.

HTTP síncrono ainda pode ficar na frente. O adaptador espera brevemente completed ou rejected e devolve 202 Accepted se continuar. Uma leitura mostra o resultado durável. O usuário vê conclusão rápida no normal e pendência verdadeira no atraso. Não mantenha a conexão aberta para imitar tarefa conversacional.

Segurança segue o mesmo modelo. Autentique na borda, mas passe principal limitado e contexto autorizado. Não confie em conta, operador ou permissão porque antes estavam numa COMMAREA protegida. Valores que cruzam navegador ou broker são validados onde a transição ocorre.

Guarde código CICS e diagnóstico na evidência do adaptador e mapeie para contrato público pequeno. Expor todo EIBRESP acopla clientes; descartá-los dificulta paridade e reparo. O limite precisa de resultado estável para chamadores e detalhe legado para provar equivalência.

Testes de paridade devem quebrar conversas

Comparar campos no caminho feliz não prova a migração. O harness deve comparar comportamento confirmado entre limites, tentativas, abends, continuação antiga e falhas perto do syncpoint. Tela igual pode esconder outra unidade de trabalho.

Crie traces de tráfego gravado apenas sob as regras de dados da organização. Capture estado inicial, bytes e campos, transação, mudanças, posições de syncpoint, saídas, próxima transação e estado final. O mascaramento preserva diferenças que mudam ramos, como espaços contra low values ou códigos com o mesmo rótulo.

Execute caminhos antigo e novo com dados isolados e reiniciáveis. Compare resultados, não ruído. Tempos, IDs e ordem podem ser normalizados; valores, estados, permissões e efeitos confirmados devem coincidir.

A matriz deve incluir:

• Repetir o comando antes e depois da conclusão.
• Perder a resposta após commit e repetir com o mesmo ID.
• Falhar antes do syncpoint e após efeito não recuperável.
• Enviar comando válido com versão antiga.
• Retomar com cada comprimento e versão de COMMAREA.

CodeHero usa um harness de paridade contra tráfego de produção gravado ao reescrever CICS e código vizinho, pois semelhança de fonte não revela diferenças de recuperação. O mesmo harness deve injetar falhas antes de confiar gravações ao substituto.

Preserve o comportamento sem preservar o acidente

Modelar corretamente não exige recriar CICS num serviço web. Exige preservar regras observáveis: comandos permitidos, mudanças confirmadas juntas, duplicatas, trabalho incompleto e recuperação conhecida.

Alguns detalhes devem ser aposentados. Um ID de quatro caracteres não precisa virar rota. Uma COMMAREA não precisa virar payload público. Afinidade de terminal não precisa virar sessão fixa. Um limite de gerenciador deve sobreviver até sua atomicidade ser substituída deliberadamente por workflow e reparo.

Escreva uma especificação por comando: identidade estável, estado anterior, versão, dono, efeitos dentro e fora, duplicata e reparo do operador. Revise com quem diagnostica CICS. Geralmente encontram syncpoint implícito, comportamento de fila ou suposição de reinício ausente.

O teste difícil é perder a resposta após commit. Se o projeto explica o que o cliente repete, o que o servidor lê, o que devolve e por que o efeito não se repete, o limite provavelmente é real. Se depende de requisição e transação terminarem juntas, ainda confunde HTTP com CICS.