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.