Contributed by: remy Tuesday, 02 July 2013, 13:16 @ CEST
When Cobol was conceptualized, computer characters were mainly uppercased. Functions like ignoreCase were not available and did not even circulate the minds of IT professionals. And there is no need, nowadays, to stick to UPPERCASE.
While in the originating years (70's) of Cobol's growth, the programs were large and often monolithic. That did not change much over the years, but today's demands are for relative short programs that can be used as building blocks of complete systems. In short: callable subprograms, or subroutines, that can be fit in a control structure embedded in a OLTP queueing system of choice.
Matching todays demands needs a proper attitude to the language itself, to programming as a disciple and some means to apply generic structures. The Cobol language -- as is -- deserves respect when the volume of use is conceived, when the volume of processed data is considered, when its age becomes clear. It certainly looks like that the available crowds of IT specialists don't have the power to redo Cobol projects within time frames their language of choice would allow for. A similar prose can be expressed on "discipline". Matching todays demands means simply to deliver correct programs that excel in readability and scale well. This is not to be confused with the demand to be productive, which is heard along time lines now and than.
With CoCoS there are simple but restrictive rules. Once one sticks with them, i.e. decides to follow them, it is possible to produce clean, readable, scaling and correct programs in Cobol Text. Some of these rules do introduce control structures and implicit support for large architectures.
The most restrictive rule is on casing, i.e. using upper-, lower-, camel-, snake- and other -case.
In short, the usage of various casing methods can be tied to programming languages, sometimes also to individuals. This is no different with Cobol, which lives at large out there in UPPERCASE. This is a good method and signals a mainframe that processes EBCDIC.
This rule says that you either use lowercase, either use uppercase for all of your productions. Exceptions can be found in uppercasing Cobol reserved words (i.e. all syntax) within a lowercased text. But that is all.
On certain maturity levels a need for syntactic sugar arises. This is mostly found in camelCase (Java) or snake_case (C, C++). This type of casing comes along with naming your variables, dataFields, paragraph names. For those addicted to such, the following rules (with reference to WikiPedia on lettering case[*1] ) are suggested:
Cobol has a lot of reserved words; the complete syntax consists of reserved words. And these words are in the English Language. Which makes it sometimes tricky to name data fields properly. Using lowercase for them won't change that, though it could be anticipated that this could change in the future.
So, while naming a data field MOVE is illegal since it is a reserved word, naming it move is illegal too.
CoCoS advises to never use any camelCase in syntax. Stick to lower- or uppercase, for 100%.