gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Help understanding this behaviour


From: Charles Anthony
Subject: Re: [open-cobol-list] Help understanding this behaviour
Date: Sun, 1 Sep 2013 18:12:50 -0700

[Again, I am speaking from general knowledge of compilers]

What is passed from the calling procedure to the called is the address of the string, not the string itself. The COBOL compiler allocates a chunk of memory for constant string storage, and fills it with all of the constants strings, thusly:


       address          value
         xxx0               s
         xxx1               o
         xxx2               m
         xxx3               e
         xxx4               w
         xxx5               h
         xxx6               y
                etc

So, "some" starts at address xxx0 and "why is ...." starts at address xxx4. When the call to stack-controller is constructed, the address xxx0 is passed in. The procedure stack-controller expects 17 bytes, and is told that the 17 bytes starts at xxx0, and so it sees "somewhy".

The "pass string by address" is the usual practice for most of the compilers that I am familiar with; other techniques are possible. Research "calling conventions", "call by name", "call by value" and "call by reference". I would bet that the VAX COBOL compiler would pass not the address of the string, but rather the address of a string  descriptor, a structure containing the address of the string, its allocated length, and its assigned length.

Some languages and/or compilers would generate a warning at compile time that the size of the argument in the call did not match the size of the argument in the LINKAGE section.

COBOL veterans on this list could provide much information on classic COBOL compiler behaviors for this issue.

-- Charles


On Sun, Sep 1, 2013 at 5:53 PM, Patrick <address@hidden> wrote:
Hi Charles

Thanks for answering my post !

So I see were you are going with this, 17 bytes expected, 4 sent but why would the calling procedure tack on 13 bytes of junk? The calling procedure does not have knowledge of what is expected to be received, wouldn't it just send what is enclosed in the quotes?

I actually just changed it to X(50) and the whole string "why is this string showing up later" gets sent along with the value enclosed in quotes.

At the end of the day, if I have to send only values defined in working storage, it's not a big deal, it's just that I don't really get the logic behind this.

Thanks for helping me to narrow the problem down to the calling side, I thought it was on the receiving end and thanks again for posting-Patrick





On 09/01/2013 08:36 PM, Charles Anthony wrote:
[COBOL newbie here; this may be wrong.]

              LINKAGE SECTION.
              01 instruction-argument PIC X(17)  

states that the argument is PIC X(17); when you pass in "some", only four bytes are allocated and initialized. The subroutine, expecting 17 bytes, picks up the "some" plus the following 13 bytes which happen to be where the constant "why ....".

-- Charles


On Sun, Sep 1, 2013 at 4:10 PM, Patrick <address@hidden> wrote:
Hi Everyone

I have attached a code snippet at the end of this email.

I don't understand the behaviour of the program.

There is an outer procedure calling in inner one. There is a linkage
section.

In the outer program, if I create a record in the working storage
section and pass this, everything works in the program being called.

However if I pass a string not defined in the working storage section, a
part of a string in a paragraph from the outer program shows up later,
the "value is spaces" no longer seems to work and an unwanted value is
showing up later.

In hello world cobol programs there is no working storage. I am assuming
that when we code DISPLAY "hello world" the compiler has allocated the
memory for "hello world" but it looks like I have to create working
storage records for everything or there will be trouble later.

So specifically with this program I have a statement:
DISPLAY "why is this string showing up later"

If I pass the variable some-str the result makes sense
./confused
some              <-- this is instruction-string

but if I pass the string "some" I get some of the string from a previous
display statement, "why is th"
./confused
somewhy is th <-- this is instruction-string

I don't understand why this is happening, could someone help clear it up
for me?

Thanks for reading-Patrick




        >>SOURCE FORMAT FREE
        IDENTIFICATION DIVISION.
        PROGRAM-ID. confused.
        ENVIRONMENT DIVISION.
        DATA DIVISION.
        WORKING-STORAGE SECTION.
        01 some-str PIC X(17) VALUE IS "some" .

        PROCEDURE DIVISION.

       *>this is a problem = CALL 'stack-controller' USING "some"
          CALL 'stack-controller' USING some-str
          END-CALL
        STOP RUN
        .
             100-TEST-PARA.
             DISPLAY "why is this string showing up later"
             .

*>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

              IDENTIFICATION DIVISION.
              PROGRAM-ID. stack-controller.
              ENVIRONMENT DIVISION.
              DATA DIVISION.
              WORKING-STORAGE SECTION.

              01 instruction-string PIC X(17) VALUE IS SPACES   .

              LINKAGE SECTION.
              01 instruction-argument PIC X(17)   .

              PROCEDURE DIVISION USING
                              BY VALUE instruction-argument.

              MOVE instruction-argument TO instruction-string

              DISPLAY instruction-string WITH NO ADVANCING DISPLAY " <--
this is instruction-string"

              EXIT PROGRAM.
              END PROGRAM stack-controller
              .


        END PROGRAM confused
        .

       *> If I pass the variable some-str the result makes sense
       *>./confused
       *>some              <-- this is instruction-string


       *> but if I pass the string "some" I get some of the string from
the DISPLAY in 100-TEST-PARA
       *>./confused
       *> somewhy is th <-- this is instruction-string

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list




reply via email to

[Prev in Thread] Current Thread [Next in Thread]