I have different areas and these areas are used by multiple programs
I confirmed that the SBPGMC is receiving areas WS-REG-A, WS-REG-B and WS-REG-C, in that order. How is it possible? Is there any way this SBPGMC receive only the areas WS-REG-A and WS-REG-C using the WS-PARAMETERS that was shown?
If so can any body expalin it with example.
Thanks a lot.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Pay attention to Mr Bill's comments. It will be a great help to anyone looking at the called programs.
You have two seperate things you are passing to the called programs, so you should have two 01-levels in the linkage sections of each of the called programs.
For program B, which wants A and B data, references to A and B in one linkage section item would actually "work" because the B data immediately follows the A data, and matches in definitions, in the called programs.
Programs C and D would get "valid" fields, but which would be a total mingle of data passed from the calling program and would not "work" in any resonable sense of the word, although they would not abend because all the data definitions are USAGE DISPLAY. Any processing using those fields would be rubbish, however.
As to your questions.
Quote:
I confirmed that the SBPGMC is receiving areas WS-REG-A, WS-REG-B and WS-REG-C, in that order. How is it possible?
When you pass an item to a sub-program on the USING of the CALL, all that is passed to the called program is the address of each item on the USING.
It is up to you to define the data as expected in the Linkage Section of the called program. For each item on the USING of the call, you need an item on the USING of the Procedure Division of the called program.
The two USING's (the CALL and Procedure Division) define the addresses passed and received. The compiler does not provide any information about the definitiojn of the data. That is entirely up to you to get right. The Linkage Editor/Binder does nothing either with respect to the data formats.
There is no "length" of the item passed to or defined in the sub-program. Nothing. No data-definition. No length.
So, you have passed WS-REG-A. This happens to be followed by WS-REG-B and WS-REG-C and whatever is after that in the working-storage section of the calling program, or indeed even the program code of the calling program. Remember, just the address is passed. If you "look" at a linkage-section item, you will "see" as much as continue to look.
Remember, just address, no length, no definition. The linkage section items are just a "mapping" for the data in the calling program at the address passed.
In the first sub-program, the data will "work" although this is clearly not as intended from the CALL in the other program.
In the second two programs, the data mapping does not match that of the data in the called program, so will not even "work".
You need,
Code:
CALL progb USING A B
CALL progc USING A C
CALL progd USING B C
PROCEDURE DIVISION USING A B in progb
with Linkage Section having two 01-levels with the layouts of A, B respectively
PROCEDURE DIVISION USING A C in progc
with Linkage Section having two 01-levels with the layouts of A, C respectively
PROCEDURE DIVISION USING B C in progd
with Linkage Section having two 01-levels with the layouts of B, C respectively
The Linkage Section names don't have to bear any relationship to those in the called prgrom as far as the compiler or anything is concerned. Good practice to do what Mr Bill has said, and change the prefix but leave the rest the same.
I hope this is not production code. It can't be, it can't have got through any level of testing at all.
Hopefully your second question is covered here.
Don't just try to take all this in from here. Check it out in the manuals, understand what they are describing. If you are not sure about what they are saying, do some experiments to clarify for yourself. If you are still stuck, tell us what you understand, how you have shown that it is the case, and what you are still having problems with.
