So, I am n a discussion with someone regarding the use of "-" and "_"
in COBOL names. It started using VMS COBOL but moved to others. The
following was run under GnuCOBOL.

------------------------------------
C:\Work>type m2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
MOVE 123 TO I-V
CALL "R2"
STOP RUN.

C:\Work>type r2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.R2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I_V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
DISPLAY I_V.
END PROGRAM R2.

C:\Work>cobc -Wall -free -x m2.cob r2.cob

C:\Work>m2
000000123
----------------------------------------

Are "I-V" and "I_V" the same object? If so, where is this documented?

bill

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

On 9/9/2023 7:42 PM, bill wrote:

So, I am n a discussion with someone regarding the use of "-" and "_"
in COBOL names.  It started using VMS COBOL but moved to others.  The following was run under GnuCOBOL.

------------------------------------
C:\Work>type m2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V  PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
    MOVE 123 TO I-V
    CALL "R2"
    STOP RUN.

C:\Work>type r2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.R2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I_V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
    DISPLAY I_V.
    END PROGRAM R2.

C:\Work>cobc -Wall -free -x m2.cob r2.cob

C:\Work>m2
000000123
----------------------------------------

Are "I-V" and "I_V" the same object?  If so, where is this documented?

You could have asked in c.o.v..

:-)

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL and newer
ISO COBOL standards (2002, 2014, 2023), as well as many extensions
included in other COBOL compilers (IBM COBOL, MicroFocus COBOL,
ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
....
• working storage items having the EXTERNAL clause (lower-case letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

Arne






--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

Hello bill!

Sunday September 10 2023 00:42, bill wrote to All:

So, I am n a discussion with someone regarding the use of "-" and "_"
in COBOL names. It started using VMS COBOL but moved to others. The following was run under GnuCOBOL.

------------------------------------

C:\Work>> type m2.cob

IDENTIFICATION DIVISION.
PROGRAM-ID.M2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
MOVE 123 TO I-V
CALL "R2"
STOP RUN.

C:\Work>> type r2.cob

IDENTIFICATION DIVISION.
PROGRAM-ID.R2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I_V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
DISPLAY I_V.
END PROGRAM R2.

C:\Work>> cobc -Wall -free -x m2.cob r2.cob

C:\Work>> m2

000000123
----------------------------------------

Are "I-V" and "I_V" the same object? If so, where is this documented?

They are different variables and what the C compiler sees them as is
immaterial to the Cobol programmer but what is important is that using an underscore character it will get lost if you use a matrix or line printer
type and produced your listing to it (i.e., music paper etc).

Using underscore has been a no-no for many year (like 50+) for that reason
and for those that use other printers the underscore is easy to miss
whereas the hyphen is not.

But hey, I am old school programming in Cobol (and others) since 1963.

And yes I would love to get a working Matrix printer capable of 132 and 160 columns but the prices in the UK as 3 - 5 times more than in the 80's and
the quality less than half and 25% of the speed along with, in some cases
the same model was around in the 80's.

There are times, I do wish I had kept the two fast printers I had instead
of selling them off just because of small hardware faults.

If only for printing out program listings at least used during debugging.

A4 paper even landscape is not that easy to see and use! OK my eyes are not
as good as there were.

Mind you the matrix printers did take up a fair bit of space in my study / computer room but nothing compared to a line printer but it would wake up
the houses each side of my terrace house when running :).


Vincent


SEEN-BY: 25/0 21 250/0 1 2 4 5 8 13 14 263/0 362/6 371/52 467/4 712/1321

On 9/9/2023 9:18 PM, Arne Vajhøj wrote:

On 9/9/2023 7:42 PM, bill wrote:

So, I am n a discussion with someone regarding the use of "-" and "_"
in COBOL names.  It started using VMS COBOL but moved to others.  The
following was run under GnuCOBOL.

------------------------------------
C:\Work>type m2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V  PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
     MOVE 123 TO I-V
     CALL "R2"
     STOP RUN.

C:\Work>type r2.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.R2.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I_V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
     DISPLAY I_V.
     END PROGRAM R2.

C:\Work>cobc -Wall -free -x m2.cob r2.cob

C:\Work>m2
000000123
----------------------------------------

Are "I-V" and "I_V" the same object?  If so, where is this documented?

You could have asked in c.o.v..

:-)

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL and newer
ISO COBOL standards (2002, 2014, 2023), as well as many extensions
included in other COBOL compilers (IBM COBOL, MicroFocus COBOL,
ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
...
• working storage items having the EXTERNAL clause (lower-case letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

So let's see if I now understand this. A bunch of European
Unix System manufacturers decided to break the COBOL language
in a very bad way and everyone is jumping on the band wagon?

Let's hope the majority of serious COBOL programmers avoid this
like the plague.

bill


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

On 9/10/2023 9:11 AM, bill wrote:

On 9/9/2023 9:18 PM, Arne Vajhøj wrote:

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler.
GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL
and newer ISO COBOL standards (2002, 2014, 2023), as well as many
extensions included in other COBOL compilers (IBM COBOL, MicroFocus
COBOL, ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
...
• working storage items having the EXTERNAL clause (lower-case
letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

So let's see if I now understand this.  A bunch of European
Unix System manufacturers decided to break the COBOL language
in a very bad way and everyone is jumping on the band wagon?

Let's hope the majority of serious COBOL programmers avoid this
like the plague.

X/Open later Open Group was original created by Bull (France),
ICL (UK), Siemens (Germany), Olivetti (Italy) and Nixdorf
(Germany).

But at the time of publishing this doc they had been joined
by: Philips (Netherlands), Ericsson (Sweden), AT&T (US), Digital (US),
HP (US), Sun (US), Unisys (US), NCR (US), IBM (US), Prime (US),
Apollo (US), Fujitsu (Japan), Hitachi (Japan) and NEC (Japan).

And they do a lot of different stuff:
* Single Unix Specification
* CLI (the database meaning of that acronym)
* XA
* DCE
* Motif & CDE
* TOGAF

As a standardization organization I think they are much less
important than ISO and its national counterparts, and less
important than ECMA and OASIS.

Arne



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 9/10/2023 9:11 AM, bill wrote:

On 9/9/2023 9:18 PM, Arne Vajhøj wrote:

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler.
GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL
and newer ISO COBOL standards (2002, 2014, 2023), as well as many
extensions included in other COBOL compilers (IBM COBOL, MicroFocus
COBOL, ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
...
• working storage items having the EXTERNAL clause (lower-case
letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

So let's see if I now understand this.  A bunch of European
Unix System manufacturers decided to break the COBOL language
in a very bad way and everyone is jumping on the band wagon?

Let's hope the majority of serious COBOL programmers avoid this
like the plague.

I don't know why they did this.

But I could guess that it is because X/Open or Open Group
is very much focused on interoperability.

And names with hyphen are typical not supported in other
languages.

Back to VMS Cobol:

$ typ m3.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M3.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
MOVE 123 TO I-V
CALL "R3"
STOP RUN.
$ typ r3.c
#include <stdio.h>
#include <string.h>

extern char i_v[9];

void r3()
{
char temp[10];
memcpy(temp, i_v, 9);
temp[9] = 0;
printf("%s\n", temp);
}
$ cob m3
$ cc/extern=common r3
$ link m3 + r3
$ run m3
000000123

i-v is not a valid name in C but i_v is.

Anyway it is a rather weird feature. But let us not forget that
it only came up because Brian made a typo. :-)

Arne



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 9/10/2023 1:38 PM, Arne Vajhøj wrote:

On 9/10/2023 9:11 AM, bill wrote:

On 9/9/2023 9:18 PM, Arne Vajhøj wrote:

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler.
GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL
and newer ISO COBOL standards (2002, 2014, 2023), as well as many
extensions included in other COBOL compilers (IBM COBOL, MicroFocus
COBOL, ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
...
• working storage items having the EXTERNAL clause (lower-case
letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

So let's see if I now understand this.  A bunch of European
Unix System manufacturers decided to break the COBOL language
in a very bad way and everyone is jumping on the band wagon?

Let's hope the majority of serious COBOL programmers avoid this
like the plague.

I don't know why they did this.

But I could guess that it is because X/Open or Open Group
is very much focused on interoperability.

And names with hyphen are typical not supported in other
languages.

So what? Because C doesn't like it we should change COBOL?

Back to VMS Cobol:

$ typ m3.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M3.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V  PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
    MOVE 123 TO I-V
    CALL "R3"
    STOP RUN.
$ typ r3.c
#include <stdio.h>
#include <string.h>

extern char i_v[9];

void r3()
{
    char temp[10];
    memcpy(temp, i_v, 9);
    temp[9] = 0;
    printf("%s\n", temp);
}
$ cob m3
$ cc/extern=common r3
$ link m3 + r3
$ run m3
000000123

i-v is not a valid name in C but i_v is.

Again, so what? Why didn't they change C like they did COBOL?

Anyway it is a rather weird feature. But let us not forget that
it only came up because Brian made a typo.  :-)

Feature to some bug to others.

bill



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

bill wrote:

On 9/10/2023 1:38 PM, Arne Vajhøj wrote:

On 9/10/2023 9:11 AM, bill wrote:

On 9/9/2023 9:18 PM, Arne Vajhøj wrote:

https://sourceforge.net/projects/gnucobol/

<quote>
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler.
GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL
and newer ISO COBOL standards (2002, 2014, 2023), as well as many
extensions included in other COBOL compilers (IBM COBOL, MicroFocus
COBOL, ACUCOBOL-GT and others).
</quote>

The important part is "X/Open COBOL".

https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf

<quote>
8.10 EXTERNAL NAMES AND CASE CONVENTIONS
...
• working storage items having the EXTERNAL clause (lower-case
letters, digits and
hyphens; hyphens are converted to underscores)
</quote>

I have no idea about how widely implemented that rule is.

So let's see if I now understand this.  A bunch of European
Unix System manufacturers decided to break the COBOL language
in a very bad way and everyone is jumping on the band wagon?

Let's hope the majority of serious COBOL programmers avoid this
like the plague.

I don't know why they did this.

But I could guess that it is because X/Open or Open Group
is very much focused on interoperability.

And names with hyphen are typical not supported in other
languages.

So what? Because C doesn't like it we should change COBOL?

Back to VMS Cobol:

$ typ m3.cob
IDENTIFICATION DIVISION.
PROGRAM-ID.M3.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 I-V  PIC 9(9) DISPLAY EXTERNAL.
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
     MOVE 123 TO I-V
     CALL "R3"
     STOP RUN.
$ typ r3.c
#include <stdio.h>
#include <string.h>

extern char i_v[9];

void r3()
{
     char temp[10];
     memcpy(temp, i_v, 9);
     temp[9] = 0;
     printf("%s\n", temp);
}
$ cob m3
$ cc/extern=common r3
$ link m3 + r3
$ run m3
000000123

i-v is not a valid name in C but i_v is.

Again, so what?  Why didn't they change C like they did COBOL?

Anyway it is a rather weird feature. But let us not forget that
it only came up because Brian made a typo.  :-)

Feature to some bug to others.

bill

If I understand this correctly, the equivalencing of "-" and "_" only
happens with data items marked as EXTERNAL. The version of COBOL I used
to use did this differently,

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
I-O-CONTROL.
APPLY EXREF I-V. (meant that I-V could be accessed by name
from other programs).

APPLY EXDEF I-V. (meant that I-V was external to the program).

Some parts of the COBOL specs are "implementor defined" and the
limitations on the data-item names thus defined were in that category,
that meant that EXDEF/EXREF names were limited to 12 characters with one compiler. I can't remember any restrictions on which characters could
be used, but folding "-" to "_" makes perfect sense if you are
communicating with any one of a number of other languages.
The alternative would have been to have defined the field (and the
names) in an assembler routine and to have made sure I-V and I_V
occupied the same storage location.
Sub-optimal.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: To protect and to server (2:250/1@fidonet)