Table definition in a copy member



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Re: Table definition in a copy member

Postby dick scherrer » Mon Aug 26, 2013 3:11 am

Hello,

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.
How lost you are. . . . I rarely post anything sarcastic and then to those I know rather well. . .

I asked because parameters are more than 99% input but y9ou mentioned output. . .

I have not whined...
I am rather irritated to receive rather snide remarks about my understanding...
What you posted later in the same paragraph (I underlined) IS whining. What have you considered "snide remarks"? Part of the issue/misunderstanding may be the language understanding between people. This happens often here because so many with questions do not have English as their first language.

I do not feel I have a problem with parameters unless COBOL operates differently. I did ask but no reply.
Suggest you reread what BB and Robert have posted and if you then have a question, post it along with your understanding.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Re: Table definition in a copy member

 

Re: Table definition in a copy member

Postby BillyBoyo » Mon Aug 26, 2013 4:02 am

dfx1,

This is a site for Mainframe Beginners and Students.

The people answering questions here have many years of Mainframe experience, and because accuracy is important for communicating to humans (else things like this happen) and computers (else something goes wrong, you can count on it, it is a computer).

Until Dick commented and you replied I had no clue that you were talking about a copybook for LINKAGE SECTION data, I would have said something else.

I like the others do not believe, from what you have expressed, that you understand the LINKAGE SECTION and CALLs between COBOL programs. Don't worry about it, many people don't understand it, misunderstand it, and have explanations for it which are just plain wrong.

We are trying to help here. We do this in our own time, and for free.

So,

10  FILLER.
    15  A-DATA-NAME.
        20  ANOTHER-DATA-NAME PIC X.
        20  YET-ANOTHER PIC 9.


10  FILLER.
    15  A-DATA-NAME.
        20  ANOTHER-DATA-NAME PIC X.
        20  YET-ANOTHER PIC X.


Now, is your understanding correct, or were you "right by co-incidence". That is why I phrased my response as I did.

Can the level 15s in my examples have any significance?

You do not understand the CALL, and the way programs interoperate on the Mainframe.

If you want to understand, we are perfectly willing to help, though if you continue with your attitude, some of the willingness is bound to wear thin,

If you came here to get your ideas about something rubber-stamped, we don't do that. Not if you are wrong.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Table definition in a copy member

Postby dfx1 » Mon Aug 26, 2013 10:43 pm

BillyBoyo wrote:dfx1,

This is a site for Mainframe Beginners and Students.


Then it would help if those who replied to the posts addressed the poster accordingly.

You do not understand the CALL, and the way programs interoperate on the Mainframe.

Ok the third person to make that remark. Now I am concerned. Please enlighten me, as I feel I DO understand. I am therefore unable to ask for help on that subject. Please tell me how you make that assumption.
dfx1
 
Posts: 13
Joined: Fri Jun 14, 2013 1:17 am
Has thanked: 0 time
Been thanked: 0 time

Re: Table definition in a copy member

Postby Akatsukami » Mon Aug 26, 2013 11:40 pm

dfx1 wrote:
BillyBoyo wrote:
You do not understand the CALL, and the way programs interoperate on the Mainframe.

Ok the third person to make that remark. Now I am concerned. Please enlighten me, as I feel I DO understand. I am therefore unable to ask for help on that subject. Please tell me how you make that assumption.

On what basis do you conclude these are output parameters?
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day
User avatar
Akatsukami
Global moderator
 
Posts: 1053
Joined: Sat Oct 16, 2010 2:31 am
Location: Bloomington, IL
Has thanked: 6 times
Been thanked: 51 times

Re: Table definition in a copy member

Postby BillyBoyo » Tue Aug 27, 2013 1:52 am

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.


Firstly "returned to the calling program" is wrong. With one caveat (RETURNING, which you may never use), nothing is ever "returned" to the CALLing COBOL program in the sense that the phrase would have in another (non-Mainframe) language.

PROGA.

CALL PROGB USING DATA-A DATA-B


DATA-A and DATA-B are defined in the CALLing program in the DATA DIVSION. To keep things simple, we'll assume PROGA is not CALLed by another program and that DATA-A and DATA-B are defined in the WORKING-STORAGE.
01  DATA-A PIC X.
01  DATA-B
    05  DATA-B1 PIC XX.
    05  DATA-B2 PIC X.


PROGB.

LINKAGE SECTION,
01  BANANA PIC 99.
01  APPLE PIC 9.
PROCEDURE DIVISION USING APPLE BANANA.


BANANA is a "redefinition" of the storage in PROGA named DATA-A.

APPLE is a "redefinition" of the storage in PROGA named DATA-B.

Data is not "returned" to PROGA, as it never "leaves" PROGRA.

So, secondly, the names of data on a CALL USING/PROCEDURE DIVISION USING do not have to be the same. Add to that that the length of the data do not have to be the same, nor do the types of the data do not have to be the same.

If you knew this, then fine, you probably understand how a CALL works but are unable to describe it accurately.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Previous

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post