O assunto era a chamada de sub-rotinas
dentro de um programa Cobol. Hipoteticamente, temos um programa XXXP0001 que
chama a sub-rotina XXXS999.
Quando chegava um programador novo,
geralmente passava-se a seguinte orientação:
- Olha, para chamar o subprograma você
deve codificar:
Na Working
Storage:
XXXS9999 PIC X(8) VALUE “XXXS9999”.
E na Procedure
Division:
CALL XXXS9999 USING “Variáveis”.
- Uai (geralmente os programadores novos
eram mineiros)! Disseram-me que era pra chamar direto, entre aspas (CALL ”XXXS9999” USING “Variáveis”)! E
funcionou!
Ou ainda:
- Bah (alguns eram gaúchos)! Eu tenho
que chamar vários programas! Porque preciso declarar a variável XXXS9999? É
melhor criar uma variável genérica, tipo GDA- SUBROTINA! Funciona, fica mais
claro e eu posso reusar a guarda!
Nesse caso, o código na Procedure
Division ficaria assim:
MOVE “XXXS9999”
TO GDA-SUBROTINA.
CALL GDA-SUBROTINA USING “Variáveis”.
MOVE “XXXS8888”
TO GDA-SUBROTINA.
CALL GDA-SUBROTINA USING “Variáveis”.
A resposta, nos dois casos,
geralmente dada por quem não tinha ido atrás dos porquês, era sempre a mesma:
- Olha, esse é o padrão do pessoal da Governança de TI.
Esses caras de processo vivem inventando moda! É melhor fazer como eles querem e
ficar quieto.
Assim, as coisas funcionavam, os
caras da MDS (metodologia de desenvolvimento de sistemas) eram os chatos e a
vida seguia.
Mas não era bem assim. O padrão
estava certo. Aliás, perfeito. A única falha dos “chatos da MDS” era não ter
comunicado adequadamente qual o motivo do bendito padrão.
Vamos tentar clarear um pouco:
No caso do mineirim, ao dar o CALL na
sub-rotina entre aspas, estamos passando ao processo de compilação (na realidade,
de linkedição) a informação de que a chamada é estática, e não dinâmica.
Portanto, o executável resultante do
processo de compilação e linkedição do programa XXXP0001 teria incorporado
também o XXXS999. Funciona? Sim, funciona, inclusive até mais rápido.
No entanto, no momento em que
versionássemos a sub-rotina XXXS9999, apareceria um dos seguintes problemas:
- Se a XXXS9999 tivesse instruções SQL, o programa XXXP0001 abendaria com o famoso SQLCODE -805 (acho que já falei sobre isso no post “Desmistificando o Bind”), no momento de acessar o banco de dados DB2, por divergência no timestamp do Cobol X999 com o do package de mesmo nome;
- Se fosse uma sub-rotina em Cobol puro (sem SQL), o problema seria ainda maior. O P0001 continuaria rodando, mas chamando a versão anterior da S9999, embutida no seu executável.
Portanto, ao declarar a variável, o
CALL passa a ser dinâmico, com o P0001 chamando a X9999 em tempo de execução,
sempre em sua versão mais recente.
Bem, já o caso do gaúcho é um pouco
mais sutil, e mesmo “programalistas” experientes não sabem bem o porquê do
padrão ser o nome da variável com o mesmo da sub-rotina.
A palavra-chave aqui é
rastreabilidade. Existem ferramentas (na minha empresa temos o X-REF, dentre outras) que buscam a cadeia de chamadas dos módulos.
Isso é bastante útil para sabermos qual o impacto de uma alteração em um
programa chamado por vários outros.
Essas ferramentas são bem
interessantes, mas algumas delas (na realidade quase todas) trabalham por
varredura no código-fonte, e não seriam capazes de detectar que o programa
P0001 chama o S9999 no “CALL GDA-SUBROTINA”, como ocorre no “CALL XXXS9999”. Na
realidade, usamos de um artifício para “enganar” o X-REF, pois ele acha que
estamos chamando diretamente o XXXS9999, quando estamos mesmo é chamando uma
variável de mesmo nome. Como o seu conteúdo é exatamente o mesmo (ver o VALUE
no início do texto), o resultado é a chamada rastreada corretamente.
Bom, o objetivo dessa sopa de bits e
bytes era apenas reforçar a importância dos padrões e da comunicação no nosso
trabalho.
Um abraço e até a próxima!
