Den 2023-09-09 kl. 15:15, skrev bill:
> On 9/8/2023 6:59 PM, Chris Townley wrote:
>> On 08/09/2023 23:50, bill wrote:
>>> On 9/8/2023 4:40 PM, Arne Vajhøj wrote:
>>>> On 9/8/2023 1:55 PM, bill wrote:
>>>>> On 9/8/2023 1:13 PM, Arne Vajhøj wrote:
>>>>>> On 9/8/2023 12:45 PM, Brian Schenkenberger wrote:
>>>>>>> I have the SYS$MGBLSC working... at least, in the debugger.  I
>>>>>>> defined a test global section with two longwords.
>>>>>>>
>>>>>>> 1,-1
>>>>>>> 2,-2
>>>>>>> 3,-3
>>>>>>> etc.,-etc.
>>>>>>> 0,0
>>>>>>>
>>>>>>> I have the following for the global section's element definition:
>>>>>>>
>>>>>>> LINKAGE SECTION.
>>>>>>>
>>>>>>> 01 GLOBAL-SECTION.
>>>>>>>   02 ELEMENT OCCURS 2000 TIMES.
>>>>>>>     03 A        PIC S9(9) COMP.
>>>>>>>     03 B        PIC S9(9) COMP.
>>>>>>>
>>>>>>> and the procedure...
>>>>>>>
>>>>>>> PROCEDURE DIVISION USING GLOBAL_SECTION.
>>>>>>> PARAGRAPH-MAIN.
>>>>>>>     PERFORM PARAGRAPH-ENTER THRU PARAGRAPH-EXIT
>>>>>>>             VARYING I FROM 1 BY 1 UNTIL A(I) = 0 AND B(I) = 0.
>>>>>>> PARAGRAPH-ENTER.
>>>>>>>     DISPLAY "First[" I "]: " A(I) "  Second[" I "]: " B(I).
>>>>>>> PARAGRAPH-EXIT.
>>>>>>>     EXIT.
>>>>>>> END PROGRAM GBLSEC.
>>>>>>>
>>>>>>> In the debugger, A(I) and B(I) show me the values but DISPLAY pukes
>>>>>>> on them. It'd be great too if there was a way to DISPLAY them in HEX
>>>>>>> but just getting it to DISPLAY without regurgitaing garbage would be
>>>>>>> great.
>>>>>>
>>>>>> Add a couple of temporary variables:
>>>>>>
>>>>>> WORKING-STORAGE SECTION.
>>>>>> 01 AI PIC 9(4) DISPLAY.
>>>>>> 01 BI PIC 9(4) DISPLAY.
>>>>>>
>>>>>> and do:
>>>>>>
>>>>>> MOVE A(I) TO AI
>>>>>> MOVE B(I) TO BI
>>>>>> DISPLAY "First[" I "]: " AI "  Second[" I "]: " BI.
>>>>>>
>>>>>> If anyone that actually knows Cobol has a better solution then
>>>>>> I am also interested!
>>>>>
>>>>> I really don't have that much experience with VMS COBOL and have no idea
>>>>> what $MGBLSC means,
>>>>
>>>> SYS$MGLBSC is the VMS system service to map a global section.
>>>>
>>>>>                      but, if it is merely a display problem how about a
>>>>> REDEFINES from COMP to DISPLAY instead of another variable and the MOVE?
>>>>
>>>> How would that look like?
>>>
>>> Can you point me at a copy of the VMS COBOL Reference Manual?
>>> This is something VMS specific.  I tried a couple sites.  One
>>> of them returned XML errors and sector7 pointed me at localhost.
>>> If I can grab a quick look at the manual I can probably provide
>>> a fairly clean way to do it.  I may even try to figure out how
>>> to get to EISNER after the port change and then I will actually
>>> test what I write.
>>>
>>
>> Try https://docs.vmssoftware.com/vsi-cobol-for-openvms-reference-guide
>> There is also a User guide
>>
>
>
> Afraid I will have to take a pass on this one.  Too much VMS
> specific stuff that makes no sense to me in COBOL.
> An example:
> ------------------------------
> LINKAGE SECTION.
>
>    01 GLOBAL-SECTION.
>
> -----------------------
>
> PROCEDURE DIVISION USING GLOBAL_SECTION.
>
> -----------------------------
>
> Note that the names don't match.  And, GLOBAL is a reserved word.
>
> And I thought IBM COBOL was convoluted.
>
> bill
>

As that same manual says in section "1.2.1.1. User-Defined Words":

"Throughout this manual, and except where specific rules apply, the
hyphen (-) and the underline (_) are treated as the same character
in a user-defined word."

So the two symbols "GLOBAL-SECTION" and "GLOBAL_SECTION" are the same.
Could had been clearer to if that had been avoided...

There are some other special cases, search the manual for "underline".

On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:

> "Throughout this manual, and except where specific rules apply, the
> hyphen (-) and the underline (_) are treated as the same character
> in a user-defined word."

I guess that could be compared to "case insensitive", but while I consider case
sensitivity to be less than reasonable, I find the above to be really stupid.
Sure makes searching for specific words in a program complex.

Got to understand Bill's objection to such.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Den 2023-09-09 kl. 16:02, skrev Dave Froble:
> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>
>> "Throughout this manual, and except where specific rules apply, the
>> hyphen (-) and the underline (_) are treated as the same character
>> in a user-defined word."
>
> I guess that could be compared to "case insensitive", but while I consider
> case sensitivity to be less than reasonable, I find the above to be really
> stupid. Sure makes searching for specific words in a program complex.
>
> Got to understand Bill's objection to such.
>

Stupid or not, it was not known to Bill and created that
wrong comment of being two differnt symbols. I just showed
that they are probably handled as the same symbol.

That doesn't mean that I disagree with you... :-)

On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:

>>> "Throughout this manual, and except where specific rules apply, the
>>> hyphen (-) and the underline (_) are treated as the same character
>>> in a user-defined word."
>>
>> I guess that could be compared to "case insensitive", but while I
>> consider case sensitivity to be less than reasonable, I find the above
>> to be really stupid. Sure makes searching for specific words in a
>> program complex.
>>
>> Got to understand Bill's objection to such.
>
> Stupid or not, it was not known to Bill and created that
> wrong comment of being two differnt symbols. I just showed
> that they are probably handled as the same symbol.
>
> That doesn't mean that I disagree with you... :-)

Old languages sometimes has some rules that appears
very weird, because the expectation today is determined
by how a hundred newer languages has agreed on doing things
a different way.

Take as an example this perfectly valid Fortran 77 program:

program weird
integer*4 abc
abc = 123
write(*,*) abc
write(*,*) a b c
write(*,*) a b c
end

WTF??

Arne

In article <udhrva$2ib2$1@dont-email.me>, jan-erik.soderholm@telia.com
(Jan-Erik S�derholm) wrote:

> So the two symbols "GLOBAL-SECTION" and "GLOBAL_SECTION" are the
> same. Could had been clearer to if that had been avoided...

I have not done any COBOL for 41 years, and you've just made me happier
about that.

John

On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
> On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
>> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>
>>>> "Throughout this manual, and except where specific rules apply, the
>>>> hyphen (-) and the underline (_) are treated as the same character
>>>> in a user-defined word."
>>>
>>> I guess that could be compared to "case insensitive", but while I
>>> consider case sensitivity to be less than reasonable, I find the
>>> above to be really stupid. Sure makes searching for specific words in
>>> a program complex.
>>>
>>> Got to understand Bill's objection to such.
>>
>> Stupid or not, it was not known to Bill and created that
>> wrong comment of being two differnt symbols. I just showed
>> that they are probably handled as the same symbol.
>>
>> That doesn't mean that I disagree with you... :-)
>
> Old languages sometimes has some rules that appears
> very weird, because the expectation today is determined
> by how a hundred newer languages has agreed on doing things
> a different way.
>
> Take as an example this perfectly valid Fortran 77 program:
>
>       program weird
>       integer*4 abc
>       abc = 123
>       write(*,*) abc
>       write(*,*) a b c
>       write(*,*) a     b     c
>       end
>
> WTF??
>

As an old school Fortran programmer as well as COBOL (Fortran was my
second language other than various assemblers) all I see in this is
that you don't understand Fortran. That is a perfectly valid, not
weird at all, program. If you wanted it to treat "a", "b" and "c"
as separate and distinct variables you should have used commas as the
the language expects. Spaces in that context are meaningless. :-)

bill

On 9/9/2023 11:33 AM, John Dallman wrote:
> In article <udhrva$2ib2$1@dont-email.me>, jan-erik.soderholm@telia.com
> (Jan-Erik Söderholm) wrote:
>
>> So the two symbols "GLOBAL-SECTION" and "GLOBAL_SECTION" are the
>> same. Could had been clearer to if that had been avoided...
>
> I have not done any COBOL for 41 years, and you've just made me happier
> about that.
>

It's not a COBOL problem, it's a VMS problem. Other compilers
will flag the reference to "GLOBAL_SECTION" as not defined.

bill

On 9/9/2023 11:36 AM, bill wrote:
> On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
>> On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
>>> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>>>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>>
>>>>> "Throughout this manual, and except where specific rules apply, the
>>>>> hyphen (-) and the underline (_) are treated as the same character
>>>>> in a user-defined word."
>>>>
>>>> I guess that could be compared to "case insensitive", but while I
>>>> consider case sensitivity to be less than reasonable, I find the
>>>> above to be really stupid. Sure makes searching for specific words
>>>> in a program complex.
>>>>
>>>> Got to understand Bill's objection to such.
>>>
>>> Stupid or not, it was not known to Bill and created that
>>> wrong comment of being two differnt symbols. I just showed
>>> that they are probably handled as the same symbol.
>>>
>>> That doesn't mean that I disagree with you... :-)
>>
>> Old languages sometimes has some rules that appears
>> very weird, because the expectation today is determined
>> by how a hundred newer languages has agreed on doing things
>> a different way.
>>
>> Take as an example this perfectly valid Fortran 77 program:
>>
>>        program weird
>>        integer*4 abc
>>        abc = 123
>>        write(*,*) abc
>>        write(*,*) a b c
>>        write(*,*) a     b     c
>>        end
>>
>> WTF??
>
> As an old school Fortran programmer as well as COBOL (Fortran was my
> second language other than various assemblers) all I see in this is
> that you don't understand Fortran.  That is a perfectly valid, not
> weird at all, program.  If you wanted it to treat "a", "b" and "c"
> as separate and distinct variables you should have used commas as the
> the language expects.  Spaces in that context are meaningless.  :-)

Today it is considered weird that you can insert arbitrary
spaces in variable names.

Arne

On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
> On 9/9/2023 11:36 AM, bill wrote:
>> On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
>>> On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
>>>> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>>>>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>>>
>>>>>> "Throughout this manual, and except where specific rules apply, the
>>>>>> hyphen (-) and the underline (_) are treated as the same character
>>>>>> in a user-defined word."
>>>>>
>>>>> I guess that could be compared to "case insensitive", but while I
>>>>> consider case sensitivity to be less than reasonable, I find the
>>>>> above to be really stupid. Sure makes searching for specific words
>>>>> in a program complex.
>>>>>
>>>>> Got to understand Bill's objection to such.
>>>>
>>>> Stupid or not, it was not known to Bill and created that
>>>> wrong comment of being two differnt symbols. I just showed
>>>> that they are probably handled as the same symbol.
>>>>
>>>> That doesn't mean that I disagree with you... :-)
>>>
>>> Old languages sometimes has some rules that appears
>>> very weird, because the expectation today is determined
>>> by how a hundred newer languages has agreed on doing things
>>> a different way.
>>>
>>> Take as an example this perfectly valid Fortran 77 program:
>>>
>>>        program weird
>>>        integer*4 abc
>>>        abc = 123
>>>        write(*,*) abc
>>>        write(*,*) a b c
>>>        write(*,*) a     b     c
>>>        end
>>>
>>> WTF??
>>
>> As an old school Fortran programmer as well as COBOL (Fortran was my
>> second language other than various assemblers) all I see in this is
>> that you don't understand Fortran.  That is a perfectly valid, not
>> weird at all, program.  If you wanted it to treat "a", "b" and "c"
>> as separate and distinct variables you should have used commas as the
>> the language expects.  Spaces in that context are meaningless.  :-)
>
> Today it is considered weird that you can insert arbitrary
> spaces in variable names.
>

That is all about parsing and really has nothing to do with the
function of the language. The separator in that context is a comma,
not a space, tab or any other invisible character. :-)

bill

On 09/09/2023 17:47, bill wrote:
> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:

>> Today it is considered weird that you can insert arbitrary
>> spaces in variable names.
>>
>
> That is all about parsing and really has nothing to do with the
> function of the language.  The separator in that context is a comma,
> not a space, tab or any other invisible character.  :-)
>
> bill

I would not consider it good practice. I have never used Fortran, and i
was fazed by Arne's snippet

--
Chris

On 9/9/2023 12:51 PM, Chris Townley wrote:
> On 09/09/2023 17:47, bill wrote:
>> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
>
>
>
>>> Today it is considered weird that you can insert arbitrary
>>> spaces in variable names.
>>>
>>
>> That is all about parsing and really has nothing to do with the
>> function of the language.  The separator in that context is a comma,
>> not a space, tab or any other invisible character.  :-)
>>
>> bill
>
> I would not consider it good practice. I have never used Fortran, and i
> was fazed by Arne's snippet
>

A lot of things were done at the time Fortran came about that are not
considered good practice today. Like self-modifyng code. But people
here, if anyone, know that changing behavior can have a devastating
effect on legacy applications.

No one writing real Fortran today would do that. I doubt anyone in
the past ever did it deliberately. But I am sure the parser was written
in a very resource limited environment and many things were left out.
You know that COBOL had no range or bounds checking originally. You
wouldn't do that today and most COBOL compilers today (all of the ones
I am familiar with) have it at least as an option. Hind sight is always
20/20.

bill

On 9/9/2023 12:47 PM, bill wrote:
> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
>> On 9/9/2023 11:36 AM, bill wrote:
>>> On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
>>>> On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>>>>>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>>>>>>> "Throughout this manual, and except where specific rules apply, the
>>>>>>> hyphen (-) and the underline (_) are treated as the same character
>>>>>>> in a user-defined word."
>>>>>>
>>>>>> I guess that could be compared to "case insensitive", but while I
>>>>>> consider case sensitivity to be less than reasonable, I find the
>>>>>> above to be really stupid. Sure makes searching for specific words
>>>>>> in a program complex.
>>>>>>
>>>>>> Got to understand Bill's objection to such.
>>>>>
>>>>> Stupid or not, it was not known to Bill and created that
>>>>> wrong comment of being two differnt symbols. I just showed
>>>>> that they are probably handled as the same symbol.
>>>>>
>>>>> That doesn't mean that I disagree with you... :-)
>>>>
>>>> Old languages sometimes has some rules that appears
>>>> very weird, because the expectation today is determined
>>>> by how a hundred newer languages has agreed on doing things
>>>> a different way.
>>>>
>>>> Take as an example this perfectly valid Fortran 77 program:
>>>>
>>>>        program weird
>>>>        integer*4 abc
>>>>        abc = 123
>>>>        write(*,*) abc
>>>>        write(*,*) a b c
>>>>        write(*,*) a     b     c
>>>>        end
>>>>
>>>> WTF??
>>>
>>> As an old school Fortran programmer as well as COBOL (Fortran was my
>>> second language other than various assemblers) all I see in this is
>>> that you don't understand Fortran.  That is a perfectly valid, not
>>> weird at all, program.  If you wanted it to treat "a", "b" and "c"
>>> as separate and distinct variables you should have used commas as the
>>> the language expects.  Spaces in that context are meaningless.  :-)
>>
>> Today it is considered weird that you can insert arbitrary
>> spaces in variable names.
>>
>
> That is all about parsing and really has nothing to do with the
> function of the language.

True.

But treating - as _ in Cobol (in some contexts) is also just parsing
and not function.

Arne

On 9/9/2023 9:15 AM, bill wrote:
> On 9/8/2023 6:59 PM, Chris Townley wrote:
>> On 08/09/2023 23:50, bill wrote:
>>> On 9/8/2023 4:40 PM, Arne Vajhøj wrote:
>>>> On 9/8/2023 1:55 PM, bill wrote:
>>>>>                      but, if it is merely a display problem how
>>>>> about a
>>>>> REDEFINES from COMP to DISPLAY instead of another variable and the
>>>>> MOVE?
>>>>
>>>> How would that look like?
>>>
>>> Can you point me at a copy of the VMS COBOL Reference Manual?
>>> This is something VMS specific.  I tried a couple sites.  One
>>> of them returned XML errors and sector7 pointed me at localhost.
>>> If I can grab a quick look at the manual I can probably provide
>>> a fairly clean way to do it.  I may even try to figure out how
>>> to get to EISNER after the port change and then I will actually
>>> test what I write.
>>
>> Try https://docs.vmssoftware.com/vsi-cobol-for-openvms-reference-guide
>> There is also a User guide
>>
>
>
> Afraid I will have to take a pass on this one.  Too much VMS
> specific stuff that makes no sense to me in COBOL.
> An example:
> ------------------------------
> LINKAGE SECTION.
>
>    01 GLOBAL-SECTION.
>
> -----------------------
>
> PROCEDURE DIVISION USING GLOBAL_SECTION.
>
> -----------------------------
>
> Note that the names don't match.  And, GLOBAL is a reserved word.

I think there are 3 parts of this:
A) how to call VMS system service SYS$MGBLSC
B) how to use returned address for Cobol data, which is where the
routine call somes in
C) how to display a comp

A and B are settled.

So you can focus on C.

Arne

On 9/9/2023 1:16 PM, Arne Vajhøj wrote:
> On 9/9/2023 12:47 PM, bill wrote:
>> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
>>> On 9/9/2023 11:36 AM, bill wrote:
>>>> On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
>>>>> On 9/9/2023 10:20 AM, Jan-Erik Söderholm wrote:
>>>>>> Den 2023-09-09 kl. 16:02, skrev Dave Froble:
>>>>>>> On 9/9/2023 9:29 AM, Jan-Erik Söderholm wrote:
>>>>>>>> "Throughout this manual, and except where specific rules apply, the
>>>>>>>> hyphen (-) and the underline (_) are treated as the same character
>>>>>>>> in a user-defined word."
>>>>>>>
>>>>>>> I guess that could be compared to "case insensitive", but while I
>>>>>>> consider case sensitivity to be less than reasonable, I find the
>>>>>>> above to be really stupid. Sure makes searching for specific
>>>>>>> words in a program complex.
>>>>>>>
>>>>>>> Got to understand Bill's objection to such.
>>>>>>
>>>>>> Stupid or not, it was not known to Bill and created that
>>>>>> wrong comment of being two differnt symbols. I just showed
>>>>>> that they are probably handled as the same symbol.
>>>>>>
>>>>>> That doesn't mean that I disagree with you... :-)
>>>>>
>>>>> Old languages sometimes has some rules that appears
>>>>> very weird, because the expectation today is determined
>>>>> by how a hundred newer languages has agreed on doing things
>>>>> a different way.
>>>>>
>>>>> Take as an example this perfectly valid Fortran 77 program:
>>>>>
>>>>>        program weird
>>>>>        integer*4 abc
>>>>>        abc = 123
>>>>>        write(*,*) abc
>>>>>        write(*,*) a b c
>>>>>        write(*,*) a     b     c
>>>>>        end
>>>>>
>>>>> WTF??
>>>>
>>>> As an old school Fortran programmer as well as COBOL (Fortran was my
>>>> second language other than various assemblers) all I see in this is
>>>> that you don't understand Fortran.  That is a perfectly valid, not
>>>> weird at all, program.  If you wanted it to treat "a", "b" and "c"
>>>> as separate and distinct variables you should have used commas as the
>>>> the language expects.  Spaces in that context are meaningless.  :-)
>>>
>>> Today it is considered weird that you can insert arbitrary
>>> spaces in variable names.
>>>
>>
>> That is all about parsing and really has nothing to do with the
>> function of the language.
>
> True.
>
> But treating - as _ in Cobol (in some contexts) is also just parsing
> and not function.

Not really the same. The space is not considered a valid character
within a name in any language that I know of. In COBOL the "-" and
"_" are considered valid characters for use in names and should
therefore be considered different.
Cases where different characters are considered
equivalent exist and are covered in the documentation. That is upper
and lower case letters are considered equivalent. No other characters
are considered equivalent in any compiler I have worked with except
the VMS compiler. I would love to see a pointer to any other compiler
that allows this.

bill

On 2023-09-09 18:47, bill wrote:
> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
>> On 9/9/2023 11:36 AM, bill wrote:
>>> On 9/9/2023 10:26 AM, Arne Vajhøj wrote:
>>>> Old languages sometimes has some rules that appears
>>>> very weird, because the expectation today is determined
>>>> by how a hundred newer languages has agreed on doing things
>>>> a different way.
>>>>
>>>> Take as an example this perfectly valid Fortran 77 program:
>>>>
>>>>        program weird
>>>>        integer*4 abc
>>>>        abc = 123
>>>>        write(*,*) abc
>>>>        write(*,*) a b c
>>>>        write(*,*) a     b     c
>>>>        end
>>>>
>>>> WTF??
>>>
>>> As an old school Fortran programmer as well as COBOL (Fortran was my
>>> second language other than various assemblers) all I see in this is
>>> that you don't understand Fortran.  That is a perfectly valid, not
>>> weird at all, program.  If you wanted it to treat "a", "b" and "c"
>>> as separate and distinct variables you should have used commas as the
>>> the language expects.  Spaces in that context are meaningless.  :-)
>>
>> Today it is considered weird that you can insert arbitrary
>> spaces in variable names.
>>
>
> That is all about parsing and really has nothing to do with the
> function of the language.  The separator in that context is a comma,
> not a space, tab or any other invisible character.  :-)

It is not purely about parsing, but about the definition of the
language. Fortran 77 explicitly considered whitespace in this context as
non-significant.

Parsing is (or should be) based on the language specification/definition.

Johnny

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>Today it is considered weird that you can insert arbitrary
>spaces in variable names.

It has been for a while, but it was also one of the first things I taught
students when I taught freshman Fortran. Along with 2.0 and 2 being
completely different values that aren't equal.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Johnny Billquist <bqt@softjar.se> wrote:
>It is not purely about parsing, but about the definition of the
>language. Fortran 77 explicitly considered whitespace in this context as
>non-significant.

"Never put whitespace in equations because if you get in the habit of
doing that you'll use more continuation cards and cards are expensive."
-- M. Newell

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9/9/2023 2:38 PM, bill wrote:
> On 9/9/2023 1:16 PM, Arne Vajhøj wrote:
>> On 9/9/2023 12:47 PM, bill wrote:
>>> On 9/9/2023 12:15 PM, Arne Vajhøj wrote:
>>>> Today it is considered weird that you can insert arbitrary
>>>> spaces in variable names.
>>>>
>>>
>>> That is all about parsing and really has nothing to do with the
>>> function of the language.
>>
>> True.
>>
>> But treating - as _ in Cobol (in some contexts) is also just parsing
>> and not function.
>
> Not really the same.  The space is not considered a valid character
> within a name in any language that I know of.  In COBOL the "-" and
> "_" are considered valid characters for use in names and should
> therefore be considered different.
> Cases where different characters are considered
> equivalent exist and are covered in the documentation. That is upper
> and lower case letters are considered equivalent.  No other characters
> are considered equivalent in any compiler I have worked with except
> the VMS compiler.  I would love to see a pointer to any other compiler
> that allows this.

Not the exact same context, but close:

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

Arne

On 9/8/2023 10:38 PM, Arne Vajhøj wrote:
> Or if you really want to hack it:
>
> identification division.
> program-id.hex2.
> *
> data division.
> working-storage section.
> 01  v       pic 9(9) comp.
> 01  fmt     pic x(11) value "%d %08x%c%c".
> 01  cr      pic 9(9) comp value 13.
> 01  lf      pic 9(9) comp value 10.
> *
> procedure division.
> main-paragraph.
>     move 123 to v
>     call "DECC$GXPRINTF"
>         using
>            by reference fmt
>            by value v
>            by value v
>            by value cr
>            by value lf
>     end-call
>     stop run.

Not good code. No guarantee that there will be
a terminating zero byte. And %c%c CR LF is
clumsy instead of \n.

So:

identification division.
program-id.hex2.
* data division.
working-storage section.
01 v pic 9(9) comp.
01 fmt.
03 str pic x(7) value "%d %08x".
03 lfz pic 9(9) comp value 10.
* procedure division.
main-paragraph.
move 123 to v
call "DECC$GXPRINTF"
using
by reference fmt
by value v
by value v
end-call
stop run.

Arne

On 9/7/2023 4:51 PM, Arne Vajhøj wrote:
> On 9/7/2023 1:44 PM, Brian Schenkenberger wrote:
>> On 2023-09-07 14:36:31 +0000, Brian Schenkenberger said:
>>> I need to tell a customer how to map, assuming this is even possible,
>>> a global section into which I write data for them. They only do
>>> COBOL. :( Is this possibe? How does one reference the data once
>>> mapped in the expanded region? I've tried to make heads or tails of
>>> COBOL but I get totally lost in the PICs.
>>>
>>> If only somebody would do what Jim Duff did for calling system
>>> services with C but using COBOL. So very few examples exist.
>>
>> OK.  I've gotten this far but now I have no idea how to access the
>> data in the mapped region.
>>
>> IDENTIFICATION DIVISION.
....
>> *** NOW WHAT???
....
> For inspiration:
>
> $ type main.cob
> IDENTIFICATION DIVISION.
....
> $ type brian.cob
> IDENTIFICATION DIVISION.

I have updated https://www.vajhoej.dk/arne/articles/vmsipc.html
sections "Shared Memory" and "Memory Mapped File" with:
* added Cobol example (before only C, Fortran and Pascal)
* added expanding P0 region examples (before only mapping
existing address space)
* fixed a small bug in sys$crmpsc call

Arne