In your opinion, what are the quality rules for building COBOL-CICS-DB2 programs ?
For example, indentation, not hardcore, numbered paragraphs nnnn-XXXX, not SQL SELECT *, forbidden verbs as ALTER - GO TO, arrays with INDEXED clause.
Regards
Leonardo
Not sure I understand the question. Please clarify.
Também fiquei na dúvida sobre a pergunta. Me parece pelo que fala, ser a formatação da forma de escrever o código fonte e a exclusão de alguns comando.
Sobre go to ou perform, acho que devem ser usados da melhor forma, não tem o certo e o errado, apenas não usar goto para ir e voltar, se for assim, usasse perform.
Thanks!
I’m improving a software named QUACOBOL to control COBOL-CICS-DB2 code based on rules.
One of them: GO TO is a forbidden verb.
Other rules are : identation, SQL forbidden sentences, CICS forbidden commands, order of paragraphs, data definition levels, data definition names with prefix, no static CALLs , one point per paragraph, use of END terminators, etc.
I asked people and organization to includ more cases and rules.
Hola, brigado!.
Estoy mejorando un producto que desarrolle para el control de la calidad de codigo COBOL-CICS-DB2 basado en reglas.
QUACOBOL tiene mas de 50 reglas. Consulto a los expertos COBOL y a las organizaciones cuales creen que deban ser las reglas de buena construccion de programas para incluirlas
Hi Elaine,
I’m improving QUACOBOL my own software to control the quality of COBOL-CICS-DB2 programs based in rules.
For instance, no use of GO TO or ALTER, use numbered paragraphs, no use of SELECT *, only one STOP RUN / GOBACK, identation, use of END- delimiters, etc.
QUACOBOL works with more than 50 rules. I ask people and organizations to see if there are more interesting rules to include.
Regards
Leonardo
You are on the right track. Indentation and alignment make programs easier to read. PIC clauses, Value clauses, the TO, should all be aligned. Use consistent constants, eg. ZERO vs ZEROS / ZEROES. Comments at the beginning of the program should describe the general purpose of the program and then address the general flow of data. In the procedure division, comments should be made for any complicated code. A search should be explained as to its purpose. Any constants should be explained as to what they represent, example, IF MY-CODE = ‘F’ - The F should be explained. Definitely do not use the ALTER verb, same with EVALUATE. The latter is a strong verb, but too many programmers (that will perform future maintenance) will have trouble understanding it. Another nicety is to have paragraphs limited to about 16-18 lines, this allows the paragraph to be viewed on a screen without scrolling, thus easier to digest. In CICS programs, many programmers like to use the GO TO when leaving the program. I like the PERFORM, however, it gives a false impression that control will be returned. I do like the INDEXED BY vs. using a subscript. Hope all this helps.
Hello Leonardo,
If I understand correctly if what you are asking…this is what I do.
Here are few…
General.
Use meaningful paragraph and section names. Begin each with an ascending four digit number indicating the sequence of the paragraph or section within the hierarchy chart. The number should be followed by a dash and the descriptive name, gaps should be left between numbers to facilitate program maintenance. For example:
1000-INITIALIZE.
2000-COMPUTE-TAX.
3000-PRINT-REPORT.
Your first paragraph should be 0000-MAIN or 0000-BEGIN or similar notation. The paragraphs listed above represent the first level paragraphs UNDER 0000-MAIN.
Each paragraph should contain a comment listing the paragraphs that PERFORM that paragraph, any paragraphs that this paragraph PERFORMs, the purpose of the paragraph and an explanation of any involved logic.
Therefore every paragraph should have an exit.
Always exit a paragraph from a call paragraph.
Modularity.
A paragraph must be a functionally independent unit of code.
A paragraph may not consist of a single PERFORM statement.
A paragraph has only one entrance and one exit.
Stay safe. Stay healthy.
Elaine,
thanks for your answer.
Basically your rules are covered by my soft.
I’ll added 0000-MAIN and 0000-BEGIN to the actual 0000-START and 0000-Program name.
Also covered:
Files: for each file ( DDNAME - FD - OPEN - CLOSE - READ - WRITE - REWRITE - DELETE -START)
Tables: for each table ( SELECT - UPDATE - INSERT - DELETE )
Variables: list of variables defined and not used by the program
Paragraphs: list of paragraphs defined and not used by the program
I generally use the 'KISS" method: KEEP IT SIMPLE, STUPID. You want the next person after you to know/understand what you did.
I think some of the “rules” provided are a little short sighted. For example, the “GOTO” should be allowed, but only to an EXIT.
I always use the rule “Read a DB through a VIEW, update directly.” If you do a “SELECT *” in your program, and the database changes, you will start getting data you aren’t ready for. If you have a view that selects the individual fields, you’ve isolated yourself from those changes. But when you update, you need to be cognizant of the fields.
Another thing is that the CICS manual says that you should avoid PERFORMs as possible. CICS programs are structured, but should be fall through. My belief is that this rule isn’t as important if you are using an optimizing compiler – if you have a paragraph only performed once, the compiler will put it inline.
The compiler doesn’t care about how the text is formatted, so make it easier for the person who has to maintain the program in the future .
GOTO only to an EXIT is nice to avoid the ‘spaghetti’ code.
SELECT trough a view also inteseting.
Thanks for your comment.
Prezado thesharpes,
Embora reconheça que muitos alinham o "TO", gostaria de chamar a sua atenção para o desperdício que é tal alinhamento, uma vez que, existem pesquisas necessárias para identificar quais programas, e em quais pontos, poderemos ou precisaremos ajustar.
Logo, o alinhamento deve ocorrer no comando, e em hipótese alguma dentro do comando, onde espaços desnecessários impedirão a utilização eficaz de qualquer recurso de pesquisa.
Afinal, qualquer recurso que me permita procurar "TO VALOR-A" estará respeitando para esta pesquisa a quantidade de espaços entre o "TO" e o "VALOR-A".
Já tive muito trabalho desnecessário para identificar utilizações específicas em pesquisas que envolvem um ou mais Sistemas.
O comando deve ser escrito naturalmente com um espaço entre cada elemento do mesmo.Prezado(a) lzrycki,
Me permita fazer algumas considerações:
Apenas 1 ponto por parágrafo
A linguagem tem como pré-requisito que cada comando termine com um ponto.
Muitos ainda não utilizam o comando COBOL II “CONTINUE” em substituição ao comando COBOL I “NEXT_SENTENCE”, que sendo utilizado, em conjunto com o a opção de um ponto ao final da rotina, fará com que todos os comandos entre o “NEXT_SENTENCE” e o ponto no fim do parágrafo acabem não sendo processados.
Obedecer a regras da linguagem permite proteger a qualidade do código em caso de substituição ou evolução do compilador COBOL utilizado.
Apenas 1 Stop Run / Goback / Exec Cics Return
Em programas BATCH pode ser interessante, contudo, em programas COBOL/CICS pseudo-conversacionais faz toda a diferença, uma vez que, o código é na realidade um conjunto físico único de código que contém vários conjuntos lógicos, que podem, e devem, ser finalizados isoladamente.
parágrafo numerado nnnn-xxxxx
A vantagem da Numeração é a facilidade de identificar a localização da rotina no código, bem como, que em programas COBOL Estruturados são finalizados por parágrafos “STUBs” que possuem somente o comando COBOL “EXIT”, e por isso, podem ser denominados pelo número seguido do sufixo “-FIM” ou “-EXIT”.
Executa apenas nos parágrafos definidos abaixo
A Leitura de Cima para Baixo e da Esquerda para a Direita é a base do chamado “PROGRAM DESIGN” que é a forma gráfica de se definir a estrutura de um Programa Estruturado. Algo que facilita a própria numeração nos nomes do parágrafos.
Contudo, programas COBOL/CICS pseudo-conversacionais, por serem compostos por vários segmentos lógicos, torna esta regra um grande obstáculo.
Níveis de dados: apenas {01, 02,05,10,15,20, etc)
A definição de uma DCLGEN nos apresenta sua mas contundente inviabilidade, uma vez que, toda Coluna DB2 VARCHAR é representada na DCLGEN com um item de grupo de nível “01” e dois itens elementares de nível “49”. Logo, o que importa na definição das variáveis, exceção feitas aos “Níveis” “66”, “77” e “88”, não é seu intervalo, mas a clareza, pela indentação, das estruturas e sub-estruturas.
As matrizes devem ser definidas com a cláusula INDEXED_BY
A Cláusula INDEXED_BY não pode, e nem deve, ser obrigatoriedade, uma vez que, podemos utilizar uma tabela interna REFERÊNCIA para “ponteiramento” de outras tabelas internas, que por serem diferentes pode ter ocorrências com diferentes tamanhos, e por isso, nos permite utilizar um único ponteiro para todas as tabelas referenciadas em conjunto com a tabela reeferência.
A obrigatoriedade deve estar relacionada a possibilidade da utilização do “SEARCH ALL” (pesquisa binária), que para tanto, exige que a coluna utilizada na pesquisa esteja em ordem de classificação.
Verbos COBOL proibidos detectados (GO_TO, ALTER, etc)
Para os Programas COBOL Estruturado “GO_TO” desviando para o final da rotina é performático e indicado.
Para os Programas COBOL/CICS pseudo-conversacionais o “GO_TO” é necessário, uma vez que, se trata de um conjunto de segmentos de código lógico, razão pela qual, sempre que o “GO_TO” é proibido é substituído por um comando “PERFORM sem volta”, o que dificulta a leitura e o entendimento do Código.
Instruções SQL proibidas detectadas (ALTER, GRANT, EXECUTE IMM, etc)
A utilização de DECLARE DINÂMICO deve ser permitida sempre que identificarmos vantagem, uma vez que, esta opção esta relacionada a possibilidade de variações significativas de filtro, tendo um ou mais itens de filtro opcionais.
A utilização de “CREATE_TABLE” de tabela temporária deve ser utilizada sempre identificarmos vantagem, uma vez que, esta opção esta relacionada a possibilidade de se utilizar a potencialidade do DB2 na construção e manutenção, temporária, de linhas de uma tabela, garantindo, que ao final do processo, somente façam parte da atualização definitivas as linhas temporárias identificadas como necessárias.