Are identifier names case sensitive?

I know that the keywords in COBOL are not case sensitive. That is,
"PROCEDURE DIVISION" could just as well be written "procedure division". But
are the identifier names case sensitive? That is, if I declare in my data
division an item called "StudentID", can I later refer to it in a DISPLAY
statement as "StudentId" (lowercase 'd')?

What (other?) exceptions are there to COBOL's case-insensitivity? I know
that the PIC strings are case sensitive, so that PIC AAA is not the same as
PIC aaa. And string literals are probably case sensitive (that is, the
literal "Hello World!" probably evaluates to a different value that "hello
world!"). Anything else?

- Oliver

William M. Klein wrote:
> Pic AAA *is* the same as PIC aaa
>
> All NON-literal "COBOL characters" (identifiers, key words, words reserved
 in
> context) are case IN-sensitive (unless some non-Standard extension is in
> effect).  Even the "D" in column 7 is case insensitive.
>
> NOTE:
>   Particularly "interesting" is that
>
> 01  This External Pic X.
>
> *will* match
>
> 01  THIS External PIC x.
>
> in another program.
>
> NOTE:
>   There was a question/issue about "editing" symbols in PICTURE clauses, b
ut I
> *believe* that this is now resolved and they, too, are "insensitive"  (sim
ilarly
> "CR" and "DB" in NumVal-C).
>
> NOTE2:
>   With the '02 Standard, there are also issues about "non-Latin-1" charact
ers.
> The "Unicode" upper-/lower-case rules apply - and are documented in the '0
2
> Standard.
>
Without getting into details [too much to digest here], you may want to
check out the Ent. COBOL Compiler option:
> PGMNAME(LONGMIXED)
> With PGMNAME(LONGMIXED), program-names are processed as is, without trunca
tion,
> translation, or folding to uppercase.
See the Programming Guide for details.
Carl

"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:91b47$43ec1942$453db2dd$26451@FUSE.NET...

> Without getting into details [too much to digest here], you may want to
> check out the Ent. COBOL Compiler option: 
> See the Programming Guide for details.
> Carl

Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
readers in all shops be understod to be THE programming guide?  And how does
this "feature" relate to the requirement of ISO/IEC 1989:2002 page 62,
8.1.2.1, COBOL character repertoirte, General Rule 3a:  "Except when used in
the non-hexadecimal formats of alphanumeric and national literals, each
uppercase COBOL basic letter is equivalent to its corresponding lowercase
COBOL basic letter, if any"?

Stated a different way, I might want to "see the Programming Guide for
details", but I fail to see exactly what those details would have to do with
programming in standard COBOL or, for that matter, with programming in COBOL
on Unisys enterprise servers!

Or are we back to the premise that the only *real* computers are IBM
mainframes and the only *real* COBOL is whatever IBM offers at the moment?

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:V6QGf.126002$fw3.56478@fe07.news.easynews.com...
> Pic AAA *is* the same as PIC aaa

Thanks for that correction. I read through my references to try to find
what I was thinking of, and found this:

<quote>
The lowercase letters corresponding to the uppercase letters representing
the PICTURE symbols A, B, P, S, V, X, Z, CR and DB are equivalent to their
uppercase representations in a PICTURE character-string. Other lowercase
letters are not equivalent to their corresponding uppercase representations.
This means that if a lowercase q, for example, has been designated as the
currency symbol the uppercase Q may not be substituted for it, and vice
versa.
</quote>

so it looks like I mis-remembered what the reference had said.

>
> All NON-literal "COBOL characters" (identifiers, key words, words reserved
> in context) are case IN-sensitive (unless some non-Standard extension is
> in effect).  Even the "D" in column 7 is case insensitive.

Okay, so to turn the sentence around, *ONLY* literal character strings
are considered case sensitive. Is this correct?

- Oliver

Oliver Wong wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:V6QGf.126002$fw3.56478@fe07.news.easynews.com...
> 
>
>
>     Thanks for that correction. I read through my references to try to fin
d
> what I was thinking of, and found this:
>
> <quote>
> The lowercase letters corresponding to the uppercase letters representing
> the PICTURE symbols A, B, P, S, V, X, Z, CR and DB are equivalent to their
> uppercase representations in a PICTURE character-string. Other lowercase
> letters are not equivalent to their corresponding uppercase representation
s.
> This means that if a lowercase q, for example, has been designated as the
> currency symbol the uppercase Q may not be substituted for it, and vice
> versa.
> </quote>
>
>     so it looks like I mis-remembered what the reference had said.
>
> 
>
>
>     Okay, so to turn the sentence around, *ONLY* literal character strings
> are considered case sensitive. Is this correct?
>
>     - Oliver
>
To the last question I would suggest "Yes". Literals "Hello World",
"hello world" or "HeLlO wOrLd" are not the same thing if you are doing
comparisons. No big deal. Consider those three if you were using a
Windows Help file, or even writing your own. You enter the characters,
one by one, "HELL" - temporarily change both your input and the element
being searched both to UPPERCASE or LOWERCASE, (using the intrinsic
functions) and compare Input-Literal(1:4) to on-line Help-Element(1:4)
and you have a match, on the input so far - the program 'jumps' and
highlights the first matching entry in the Listbox, (if there is one).

PC-wise I'm not sure if there are specific rules that all the compilers
follow but using OO, Net Express will find methods "OpenFile" or
"OPENFILE" - if the method is found to be missing, then N/E will
generate an error message in LOWERCASE, "Class xxxx doesn't understand
method 'openfile'". The one specific LOWERCASE that I can think of is in
N/E's old style Class Control (read Repository Section) :-

Class-Control.
EidtCustomers class is "edtcustmrs".

It will hiccup on "EDTCUSTMRS".

But as you can see - that's a requirement for a specific compiler approach.

BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
seen code where they have been used - we are adequately covered by
either pic 9 or pic x. I'd be curious to know if anybody is aware of any
current code where pic a(3) is used.

Jimmy

Chuck Stevens wrote:
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:91b47$43ec1942$453db2dd$26451@FUSE.NET...
> 
>
> Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
> readers in all shops be understod to be THE programming guide?  And how do
es
> this "feature" relate to the requirement of ISO/IEC 1989:2002 page 62,
> 8.1.2.1, COBOL character repertoirte, General Rule 3a:  "Except when used 
in
> the non-hexadecimal formats of alphanumeric and national literals, each
> uppercase COBOL basic letter is equivalent to its corresponding lowercase
> COBOL basic letter, if any"?
>
> Stated a different way, I might want to "see the Programming Guide for
> details", but I fail to see exactly what those details would have to do wi
th
> programming in standard COBOL or, for that matter, with programming in COB
OL
> on Unisys enterprise servers!
>
> Or are we back to the premise that the only *real* computers are IBM
> mainframes and the only *real* COBOL is whatever IBM offers at the moment?

Since the request did not specify any specific environment, I provided a
point of reference that addressed his question.  Since it was not YOUR
question, maybe you should temper your temper...  You seem to think that
the only COBOL is 'standard' COBOL.   'Standards' do not execute.
Compilers implemented on specific platforms generate code that execute.
I doubt that there is any compiler that is pure 'standard' with no
'implementor defined' variations.

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dsiat0$2nk6$1@si05.rsvl.unisys.com...
>
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:91b47$43ec1942$453db2dd$26451@FUSE.NET...
> 

Ah, yes, that would be the COBOL used by the Ents on planet Lizardworld. Or
was it the COBOL that Ear, Nose and Throat specialists use? I find this all
so bewildering... I need to go and lie down...
 
>
> Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
> readers in all shops be understod to be THE programming guide?
Blasphemy! Heresy! Get some tar and faggots... (Oops... sticks)  Burn the
heretic! Implicit criticism of the Holy Blue! "THE Programming Guide" is the
inspired word of God as revealed through His prophet Gene Amdahl and
enshrined in the Holy Book of POOs. In His wisdom, Holy Blue wrote "THE
Programming Guide" so that mere mortals who could not follow the esoteric
mysteries of the POO could still find salvation through programming. There
is only ONE! All others are false Gods and idols...!

>And how does this "feature" relate to the requirement of ISO/IEC 1989:2002
>page 62, 8.1.2.1, COBOL character repertoirte, General Rule 3a:  "Except
>when used in the non-hexadecimal formats of alphanumeric and national
>literals, each uppercase COBOL basic letter is equivalent to its
>corresponding lowercase COBOL basic letter, if any"?
>
> Stated a different way, I might want to "see the Programming Guide for
> details", but I fail to see exactly what those details would have to do
> with programming in standard COBOL or, for that matter, with programming
> in COBOL on Unisys enterprise servers!
>
> Or are we back to the premise that the only *real* computers are IBM
> mainframes and the only *real* COBOL is whatever IBM offers at the moment?
>

Back to that premise...?  I didn't know we ever left it.... :-)

You're not seriously suggesting that a puny little outfit like Unisys should
be taken seriously, are you Chuck?

Next we'll have NCR, ICL (Fujitsu), Siemens, Honeywell and CDC people all
requiring equal air time...

Just because Univac were one of the main movers and shakers behind COBOL 48
years ago doesn't mean their derivative company should have any say today.
They didn't go the distance; IBM did.

It is interesting to note that IBM nearly lost their company by "inventing"
the PC. At the very least they shot themselves in the foot. Now they are
promoting Websphere/Java/OpenSource solutions as well as their "real" COBOL
offering... Back both horses and you must come in somewhere...

If one were forced to back ONE of these options, which would it be? Where do
Unisys stand on Java/Open Source solutions? Nowhere? Ooops...

To get serious for a minute (and I hope you realised the above was not...),
I have been part of a triumvirate interviewing people for my own and some
other projects we are currently looking at.  Our main platform is currently
Unisys, with the applications running LINC-generated COBOL. (It will be
replaced by a distributed solution, either WinTel or Java or possibly both).
One of my colleagues on the interview panel is responsible for this
environment and LINC and UNISYS are very dear to his heart. Every single
candidate was asked: "Do you have any experience with LINC?" and every
single one responded with a bemused look. It became kind of amusing by the
second day... I'm sure some of them will thnk they missed the job because
they didn't know what LINC was... (certainly not true).

It is also interesting that Unisys are now touting the ability of LINC to
generate C# rather than COBOL. Maybe they ARE trying to have options other
than COBOL... (I wouldn't blame them...)

Pete.

"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:716c2$43ecf645$453db2dd$20456@FUSE.NET...
> Chuck Stevens wrote: 
>
> Since the request did not specify any specific environment, I provided a
> point of reference that addressed his question.  Since it was not YOUR
> question, maybe you should temper your temper...  You seem to think that
> the only COBOL is 'standard' COBOL.   'Standards' do not execute.
> Compilers implemented on specific platforms generate code that execute. I
> doubt that there is any compiler that is pure 'standard' with no
> 'implementor defined' variations.

Chuck is sensitive on this point and maybe you can understand why he would
be. He has worked tirelessly for many years on providing support and service
to people and on getting a better COBOL standard. He has suffered fierce
debate and abuse in this forum (much of it from me...I am as passionately
anti-standard as he is pro, and I still believe the fiasco of the Standards
committee (17 years to create a standard and then producing something that
requires a degree in International Law so you can read it) was a major nail
in the coffin of COBOL). I have been one of the strongest opponents of the
standard here, and my position is very close to your own; I don't know a
single programmer who reaches for the standards manual rather than the
vendor's manual, when something needs to be looked up or checked.

But having said that, it is important to recognise there are some very good
and dedicated people who have genuinely striven
to make things better in COBOL land. Bill Klein is one (and was villified
for his position by others who were less rigorous in their approach), Chuck
is another. I have kind of agreed not to discuss the standards here
(feelings run pretty high on both sides), so I won't.

Understand that Chuck works for Unisys, and like most of us, is proud of the
company he represents. IBM are a main competitor, and it is irritating when
people just "assume" that any COBOL environment under discussion must
automatically be IBM. As a courtesy, it is good for anyone posting here to
note the environment they are referring to.

BTW, I found your post "interesting" :-) It is many years since I worked on
IBM mainframes but I am always interested to see "new" (well, to me at
least...) compiler options and smart JCL examples. I have followed the posts
on DFSORT with interest also. Maybe Easytrieve will be the final programming
language of choice... :-)

Pete.

James J. Gavan wrote:
> (snip - a lot of stuff)
> BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
> seen code where they have been used - we are adequately covered by
> either pic 9 or pic x. I'd be curious to know if anybody is aware of any
> current code where pic a(3) is used.
>
> Jimmy

I think I have only seen PIC A once in 26 years of COBOL coding.  I
will have to try it to see if it actually enforces alphabetic characters.

Another thing I have NEVER seen in production COBOL program is a
picture clause with a P in it.  I think I know what it should do, but
it's never been needed in any program I saw.

The final thing I have never seen in COBOL is USAGE COMP-1 or COMP-2.
In IBM mainframe COBOL that would be floating-point, single
precision and double-precision, respectively.

Based on my (not necessarily exhaustive) experience, you could remove
PIC A, PIC P, and floating-point from COBOL, and nobody in the
business world would even notice they were gone.

And to get back on topic, I like it that COBOL reserved words or
user-defined names are case-insensitive.

--
http://arnold.trembley.home.att.net/


Arnold Trembley wrote:

>
>
> James J. Gavan wrote:
> 
>
>
> I think I have only seen PIC A once in 26 years of COBOL coding.  I
> will have to try it to see if it actually enforces alphabetic characters.
>
> Another thing I have NEVER seen in production COBOL program is a
> picture clause with a P in it.  I think I know what it should do, but
> it's never been needed in any program I saw.
>
> The final thing I have never seen in COBOL is USAGE COMP-1 or COMP-2.
>  In IBM mainframe COBOL that would be floating-point, single precision
> and double-precision, respectively.
>
> Based on my (not necessarily exhaustive) experience, you could remove
> PIC A, PIC P, and floating-point from COBOL, and nobody in the
> business world would even notice they were gone.
>
> And to get back on topic, I like it that COBOL reserved words or
> user-defined names are case-insensitive.
>
Arnold,
You would care about the removal of floating-point if you had ever
called IBM graphics routines (the product called GDDM) from your COBOL
program.  I wrote a set of programs to produce GANTT charts (basically,
graphical project status reports) in COBOL some years ago.  Many of the
calls require floating point arguments.

I'm surprised you've never used the "P" picture character.  It would be
useful if you received a number, such as "1", which represented hundreds
of units.  You could use this number in an arithmetic operation without
multiplying it by 100 in your own code.

Picture character "A" was outlawed in the shop where I used to work at
least twenty years ago.  We just figured that we didn't need to have
data definitions which used "A" in preference to "X".  I'll bet you
could, if you tried, find a place to use it, though -- maybe to describe
English highway designations?
Colin