Page 2 of 2

Re: Table definition in a copy member

PostPosted: Mon Aug 26, 2013 3:11 am
by dick scherrer
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.

Re: Table definition in a copy member

PostPosted: Mon Aug 26, 2013 4:02 am
by BillyBoyo
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.

Re: Table definition in a copy member

PostPosted: Mon Aug 26, 2013 10:43 pm
by dfx1
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.

Re: Table definition in a copy member

PostPosted: Mon Aug 26, 2013 11:40 pm
by Akatsukami
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?

Re: Table definition in a copy member

PostPosted: Tue Aug 27, 2013 1:52 am
by BillyBoyo
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.