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

[Michael Anderson]

01 some-str PIC X(17) VALUE IS "some" .

Also, the above declaration renders a 17 byte character string, containing chars 's', 'o', 'm', 'e', followed by 13 spaces (hex 20).
I know the Cobol spec says that when you MOVE "some" to a X(17) string, it is first initialize to spaces, then "some" is strung into the first four bytes.
I think the same rule applies to initial value clauses, it shouldn't contain garbage.

In scenario #1, "CALL 'stack-controller' USING some-str"
The calling program, calls the nested sub, passing some-str by reference (the default), which passes the address of 'some-str' (&some-str), however, oddly, the nested subprogram is using "BY VALUE", on a 32-bit platform the subroutine should receive four bytes containing the address of 'some-str', the results are unpredictable..

For scenario #1, I would remove the "BY VALUE" clause in the nested subroutine, and all should work as expected.

In scenario #2, CALL 'stack-controller' USING "some".
Calling a subprogram, passing a literal string, like "whatever", then the subroutine should be using the BY VALUE clause, however in this case the length of the string will be an issue, C handles this by using null terminated strings, or by passing an additional item to specify length. You may impliment the same or similar in Cobol, but both routines need to be in cahoots, cooperating.

Please read the section in the OpenCobol manual (that Gary wrote) where it explains calling "BY VALUE" and "BY REFERENCE".

For scenario #2, make sure the length is negotiated properly, between the caller and the called.

Basically,
scenario #2:
By value makes a copy of the item being passed, and then gives the copy to the subroutine.
The calling program will not see any changes made to that item by the called subroutine.

scenario #1:
By reference passes the address of the callers variable, so when called subroutine is invoked it has access to the exact same variable in the callers working storage, and therefore the called subprogram can make changes and caller will see those changes upon return.

--
Mike.


On 09/01/2013 07:53 PM, Patrick 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

------------------------------------------------------------------------------
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