RE: [open-cobol-list] Bug Report and Fix

[William M. Klein]

If you check out the current IBM mainframe LRM at:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR30/6.2.4 

You will see that "literal-2" may follow can follow "BY CONTENT"

And "literal-3" may follow "BY VALUE"

*NO* literal may follow (implicit or explicit) "BY REFERENCE"

I don't even know WHAT should happen if you pass a literal by reference.
Does this pass the address of the "literal pool"?  What happens if the
subprogram modifies the Linkage Section item?  Does it CHANGE the literal in
the calling program?  Something else?

P.S.  If Enterprise COBOL actually supports this on the mainframe, then you
should submit a "Reader's Comment form" telling them to update the LRM.

-----Original Message-----
From: Robert Sherry [mailto:address@hidden 
Sent: Wednesday, November 16, 2005 5:33 PM
To: address@hidden
Subject: RE: [open-cobol-list] Bug Report and Fix

William,

       This example works on an IBM mainframe running MVS. I also believe it
is standard COBOL but I really do not now. I do not know of any rule in any
COBOL compiler that does not allow alphanumeric literals to be passed as
arguments by reference. If you know of such a rule, I would like to hear
about it.

Thanks,
Bob Sherry

-----Original Message-----
From: William M. Klein [mailto:address@hidden
Sent: Wednesday, November 16, 2005 6:31 PM
To: 'Robert Sherry'; address@hidden
Subject: RE: [open-cobol-list] Bug Report and Fix

Robert,
   For my information, what dialect allows a 

  CALL whatever Using "alphanumeric literal"

Instead of
  
  Call whatever using by Content/Value "alphanumeric literal"

The first SHOULD default to "BY REFERENCE" which should NOT allow an
alphanumeric literal as the argument.

________________________________

From: address@hidden
[mailto:address@hidden On Behalf Of Robert
Sherry
Sent: Wednesday, November 16, 2005 12:59 PM
To: address@hidden
Subject: [open-cobol-list] Bug Report and Fix



Gentlemen (Including Roger While),

 

First, I claim that variables defined in the COBOL LINKAGE SECTION need to
hold their values between subroutine calls. This is not currently happening
in the latest version of the Open Source COBOL COMPILER. Please consider the
following two COBOL Programs. It consists of a main program and a
subroutine:

 

Main Program:

 

       IDENTIFICATION DIVISION.

       PROGRAM-ID. top1.

 

       ENVIRONMENT DIVISION.

       CONFIGURATION SECTION.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       01 FUN-NAME PIC X(8) VALUE 'FOO'.

       PROCEDURE DIVISION.

           CALL 'bot' USING '1' FUN-NAME.

           CALL 'bot' USING '0'.

           GOBACK.

 

Subroutine:

 

       IDENTIFICATION DIVISION.

       PROGRAM-ID. bot.

 

       ENVIRONMENT DIVISION.

       CONFIGURATION SECTION.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       LINKAGE SECTION.

       01 LN-MODE PIC X(1).

       01 LN-VAL PIC X(8).

       01 LN-NAME PIC X(8).

       PROCEDURE DIVISION USING LN-MODE LN-VAL.

           IF LN-MODE = '1'

             SET ADDRESS OF LN-NAME TO ADDRESS OF LN-VAL

           ELSE

             DISPLAY 'NAME=' LN-NAME

           END-IF.

           GOBACK.

 

When compiled with the latest version of the Open Source COBOL Compiler the
above programs dies with a core dump. The function output_internal_function
has the following line of code:

                 output_line ("unsigned char *%s%d = NULL;", CB_PREFIX_BASE,
f->id);

 

This line of code puts out the data variable definitions for COBOL data
items defined in the LINKAGE SECTION. I claim that the above bug can be
fixed by chaning the above line to:

                 output_line ("static unsigned char *%s%d = NULL;",
CB_PREFIX_BASE, f->id);

 

Bob Sherry