Page 1 of 2

Table definition in a copy member

PostPosted: Sat Aug 24, 2013 5:10 pm
by dfx1
Hello,

I've been given a source to copy into my program containing the program's output parameters :

01     COPY_MEMBER.
         05   MY_TABLE.
              10 MY_TABLE_LINE OCCURS 2 INDEXED BY MY_INDEX.
                  15 MNTPRS-U.
                       20 MNTPRS             PIX X. 
                  15 MNTPRT-U.
                       20 MNTPRT             PIX X. 
              10  FILLER                       PIC X OCCURS 10

I've changed the names obviously, could someone explain to a newcomer at COBOL like myself what each line means?
I'm guessing that some of the lines are superfluous. Are the level 15's really necessary?
Thanks in advance!

Code'd

Re: Table definition in a copy member

PostPosted: Sat Aug 24, 2013 7:29 pm
by BillyBoyo
As they stand, in this particular instance, with a single one-byte alpha-numeric field subordinate to it, the level-15s in question are superfluos.

Your copyook has four significant bytes, in the form of two entries to a table, each two bytes long.

You have a 10-byte FILLER, which defines storage but cannot be referenced directly.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 12:16 am
by dick scherrer
Hello,

If you used the original names, it might give a clue as to why this is so coded . . .

What are the "program's output parameters"? This is not a term I've used?

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 2:41 am
by dfx1
I changed the names to avoid any problems with the company. By output parameters I meant that the copy member is the same name that is declared in the linkage section to be returned to the calling program.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 3:15 am
by Robert Sample
declared in the linkage section to be returned to the calling program
Your understanding of the LINKAGE SECTION is the complete opposite of reality. LINKAGE SECTION variables are passed from a calling program to a called program; values may be updated by the called program but those values may -- or may not, depending upon the calling program -- be returned to the calling program at all. (look at CALL BY VALUE and CALL BY REFERENCE in the COBOL Language Reference manual via the IBM Manuals link at the top of this page). Memory for LINKAGE SECTION variables is allocated in the calling program, not in the called program.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 3:39 am
by dick scherrer
Hello,

I changed the names to avoid any problems with the company.
Then use names that mean the same but are not the same . . .

I have trouble understanding how an array with only 2 data fields could be so worrisome . . .

I suppose the code that "builds" this gathers info from wherever and sets some indicators . . . ? The better info you provide, the more help we can provide.

As Robert mentioned, you need to spend some time learning how modules call / are called and how data is used between them.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 2:00 pm
by dfx1
Robert Sample wrote:
declared in the linkage section to be returned to the calling program
Your understanding of the LINKAGE SECTION is the complete opposite of reality. LINKAGE


What a stupid thing to write. What exactly is your understanding of MY understanding of the LINKAGE SECTION? I don't think I gave mine. So COBOL passes parameters by value or by reference or not at all, what am I missing? This was not the subject of my post.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 2:13 pm
by dfx1
dick scherrer wrote:Hello,

I have trouble understanding how an array with only 2 data fields could be so worrisome . . .

The number of data fields should not make a difference. Neither should the names. I did not say I was worried either. What I did say was that I was new to COBOL and I wanted to fully understand the code.
This was answered by BillyBoyo.

As Robert mentioned, you need to spend some time learning how modules call / are called and how data is used between them.

Now what makes you think that? I know several other languages, have passed parameters with COBOL, have re read the doc, why are you telling me to go learn? Is there something special about COBOL parameters? If so I admit that I haven't found it.
Why did you reply after BillyBoyo's message?
You haven't added anything of value at all!

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 10:30 pm
by dick scherrer
Hello,

Why did you reply after BillyBoyo's message?
Because I was naïve enough to believe you actually wanted help . . .

You haven't added anything of value at all!
Opinions vary.

By your post, you say you don't know COBOL and you have shown that you don't know much. Rather than whine about what we suggest, you should take advantage of what we provide and hopefully will learn from it.

This was not the subject of my post.
Well, they way you worded posts led us to believe you were lost with the definitions and then you mentioned linkage . . . So we relied about both the definitions and later the linkage issue. Your original post was incredibly lacking and we took a shot,

If you want answers more to your liking, post better questions or ask for help defining your question.

Re: Table definition in a copy member

PostPosted: Sun Aug 25, 2013 11:36 pm
by dfx1
dick scherrer wrote:Hello,

Because I was naïve enough to believe you actually wanted help


I did wonder if there was some sarcasm when you replied "What are the "program's output parameters"? This is not a term I've used?" and that confirms it.
I have not whined. I have not worried. I have had the answer to my question on the first post. I am rather irritated to receive rather snide remarks about my understanding of using parameters, for a reason I do not understand. I do not feel I have a problem with parameters unless COBOL operates differently. I did ask but no reply.