 |
| Bellacosa Mainframe e as diferencas entre o goback e o stop run |
Dos Cartões Perfurados ao Enterprise COBOL: A Evolução do STOP RUN e do GOBACK
Essa é uma excelente pergunta, e a resposta curta é:
Hoje, em projetos modernos de Enterprise COBOL para z/OS, a IBM e a maioria das empresas recomendam usar
GOBACKem vez deSTOP RUN. Não é apenas modismo; existem razões técnicas, arquiteturais e de reutilização do ambiente de execução (Language Environment). (IBM)
Vamos analisar como um arquiteto de Mainframe faria.
A origem do STOP RUN
Quando COBOL surgiu na década de 1960, praticamente todos os programas eram executados diretamente pelo sistema operacional.
O fluxo era simples:
JCL
│
▼
Programa COBOL
│
STOP RUN
│
▼
MVS
Naquela época:
não existiam APIs REST;
não existiam aplicações reutilizáveis;
praticamente não existiam subprogramas complexos;
o programa começava e terminava.
O STOP RUN fazia exatamente isso:
"Acabei. Pode encerrar tudo."
O surgimento do GOBACK
Com o crescimento dos sistemas apareceram:
subprogramas
bibliotecas
módulos reutilizáveis
CICS
IMS
DB2
Language Environment (LE)
Agora um programa não era mais necessariamente o "programa principal".
Exemplo:
JCL
MAIN01
│
CALL CLIENTE
│
CALL CALCJURO
│
CALL VALIDA
Imagine se CALCJURO executasse:
STOP RUN
O que aconteceria?
Toda a aplicação terminaria imediatamente.
Não apenas o módulo.
Todo o Run Unit.
É exatamente isso que a IBM documenta. STOP RUN termina toda a Run Unit; já GOBACK retorna ao chamador quando usado em um programa chamado. (IBM)
A grande diferença
STOP RUN
Programa
↓
encerra TODA a Run Unit
↓
retorna ao sistema operacional
GOBACK
Programa
↓
retorna para quem chamou
↓
continua a execução
Se o programa for o principal:
GOBACK
↓
faz praticamente o mesmo trabalho do STOP RUN
A IBM afirma isso explicitamente:
Em um programa principal, GOBACK funciona como STOP RUN. Em um subprograma, GOBACK funciona como EXIT PROGRAM. (IBM)
Exemplo prático
Programa principal
MAIN
CALL "A"
DISPLAY "FIM"
STOP RUN
Programa A
DISPLAY "A"
STOP RUN
Resultado
A
O DISPLAY "FIM"
nunca acontece.
Agora usando GOBACK
Programa A
DISPLAY "A"
GOBACK
Resultado
A
FIM
Porque voltou para o MAIN.
Então por que muitas empresas proíbem STOP RUN?
Não porque ele esteja errado.
Mas porque ele cria risco.
Imagine um programa hoje.
Batch
↓
Framework
↓
Biblioteca
↓
Serviço
↓
Seu Programa
Você nem sempre sabe quem chamou seu módulo.
Se usar
STOP RUN
você encerra toda a aplicação.
Se usar
GOBACK
o programa simplesmente devolve o controle.
Muito mais seguro.
O princípio da reutilização
Hoje escrevemos programas para serem reutilizados.
Um módulo pode ser chamado por:
Batch
CICS
IMS
API REST
MQ
Java
z/OS Connect
outro COBOL
O módulo não deve assumir que é o "dono" da aplicação.
Ele apenas faz seu trabalho.
Depois devolve o controle.
Isso é exatamente o comportamento do GOBACK.
O impacto no Language Environment (LE)
Aqui está uma das razões mais importantes.
O Enterprise COBOL roda sobre o Language Environment (LE).
O LE controla:
memória
pilha
heap
tratamento de exceções
inicialização
reutilização do runtime
Quando ocorre
STOP RUN
o LE encerra o Run Unit.
Quando ocorre
GOBACK
ele apenas retorna ao chamador.
Isso permite reutilizar o ambiente de execução em muitos cenários. (IBM)
O caso do RTEREUS
Pouca gente conhece essa opção.
Existe um parâmetro do LE chamado
RTEREUS
(Runtime Reuse)
Ele permite reutilizar o ambiente de execução COBOL.
A IBM afirma claramente:
Para obter os benefícios do RTEREUS, substitua STOP RUN por GOBACK. STOP RUN encerra o ambiente reutilizável. (IBM)
Ou seja:
STOP RUN
↓
destrói o ambiente
↓
novo ambiente precisa ser criado
Enquanto
GOBACK
↓
reutiliza o ambiente
↓
menos overhead
Performance
O ganho normalmente não é enorme em um programa isolado.
Mas imagine milhares de execuções por minuto.
1000 programas
↓
cada um recria o Runtime
↓
mais CPU
Com reutilização:
Runtime permanece ativo
↓
menos inicialização
↓
menos CPU
É exatamente por isso que grandes bancos adotam GOBACK como padrão.
E no CICS?
No CICS normalmente termina-se com
EXEC CICS RETURN
e não com
STOP RUN
porque quem controla a aplicação é o CICS.
O mesmo raciocínio vale para IMS.
O programa devolve o controle ao ambiente.
Não encerra a Run Unit.
Um exemplo interessante: DFSORT
A IBM é ainda mais direta na documentação de user exits do DFSORT:
User exits escritos em COBOL não devem usar STOP RUN. Para retornar ao DFSORT, use GOBACK. (IBM)
Ou seja,
STOP RUN
↓
encerra tudo
↓
ERRADO
GOBACK
↓
retorna ao DFSORT
↓
CORRETO
Existe recomendação oficial da IBM?
Sim.
A documentação oficial afirma que:
em programas principais,
GOBACKtem o mesmo efeito deSTOP RUN;em subprogramas,
GOBACKretorna ao chamador, enquantoSTOP RUNtermina toda a Run Unit. (IBM)
Além disso, para ambientes reutilizáveis (RTEREUS), a IBM recomenda trocar STOP RUN por GOBACK. (IBM)
Documentação oficial da IBM:
Minha recomendação para um COBOL Padawan
Se você está desenvolvendo em Enterprise COBOL moderno, adote esta regra simples:
| Situação | Recomendação |
|---|---|
| Programa Batch principal | GOBACK |
Subprograma (CALL) | GOBACK |
| Biblioteca reutilizável | GOBACK |
| Módulo chamado por Java, CICS, IMS ou APIs | GOBACK |
| Novo desenvolvimento | GOBACK como padrão |
Na prática, GOBACK é um superconjunto de STOP RUN: ele faz o papel de STOP RUN quando está no programa principal e o de EXIT PROGRAM quando está em um programa chamado. Isso reduz riscos, melhora a reutilização do runtime e torna o código mais flexível para arquiteturas modernas. Por esse conjunto de vantagens, a preferência atual por GOBACK é muito mais uma decisão de engenharia do que um simples modismo.
Sem comentários:
Enviar um comentário