Linkage section and pointers

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

hi guys,

My requirement is as below:

I have a prog A which is calling prog B.
Linkage section of program B is as mentioned below.
In procedure division of program B I need to access the variables ws-var1 and ws-var2
and display them.

Prog A

01 ws-var1 PIC X(3) value 'XYZ'.
01 ws-var2 PIC X(3) value 'abc'.

Call 'B' using ws-var1
ws-var2.

Prog B

Linkage section.

01 ws-var3 PIC X(1).

Procedure division.

----
----.

I understand that this needs to be done using pointers, but somehow I am not able to achieve this.
Please help.

Anuj Dhawan · Posted: Mon Oct 04, 2010 7:29 pm

I'm not able to understand your request quite well and not sure why do you mention about pointers? Here are some threads on pointers (if you insist and want to read about them), you mihgt like to look at, however:

ibmmainframes.com/post-155622.html
ibmmainframes.com/post-135797.html

GuyC · Posted: Mon Oct 04, 2010 7:51 pm

normally it is
Prog B

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

See the problem is that two variables ws-var1 and ws-var2 are passed to program B.
And in program B there is only one variable in the linkage section ws-var3 with picture clause pic X(1).

So how do I access the variables ws-var1 and ws-var2 in program B?

dbzTHEdinosauer · Posted: Tue Oct 05, 2010 2:06 pm

1. how are the two variables (ws-var1 and ws-var2) being passed by program A?

2. change program b

Robert Sample · Posted: Tue Oct 05, 2010 4:36 pm

Why on earth do you want to violate the normal rules of COBOL by not addressing both WS-VAR1 and WS-VAR2 in program B by using the appropriate LINKAGE SECTION and PROCEDURE DIVISION USING statements? No good can come of such violations -- even if you cobble together something that worked, it would be a nightmare to maintain.

If you cannot change program B, make a new copy of it and add both variable to the LINKAGE SECTION and PROCEDURE DIVISION USING statements. Pointers were not created to allow you to violate COBOL standards.

dbzTHEdinosauer · Posted: Tue Oct 05, 2010 5:24 pm

why this BS about pointers?
the program at least requires new code to deal with the new variables.

again, the TS has not given us any info,
he only wants help on how to implement the solution to which he has already arrived.

The quality of questions on this board continues to deteriorate.

dick scherrer · Posted: Tue Oct 05, 2010 8:09 pm

Hello,

Why/how do you believe a module that "passes" 2 variables should invoke a module that is coded to use only one?

What business or technical reason is there for even trying?

If there is no real reason, implement properly (both modules will have 2 variables). If there is some reason that none of us have imagined, describe what is so special with this and someone may have a suggestion. . .

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

Okay... I will explain in more detail.
Also I have googled a solution for the same.

Actual requirement is any program which calls program B can pass a data area varying from PIC X(10) to PIC X(100) to program B.

Program B will always called by reference.
Program B is supposed to display the data that is passed to it.

If the data passed to the program B varies from PIC X(10) to PIC X(100), it is not possible for me to code the linkage section in program B.

So just code a variable with PIC X(1) in the linkage section of program B and obtain all the variables that are passed to this program as below.

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

hey there was an error in what I posted above

Instead of adding 4 to add-pointer

GuyC · Posted: Wed Oct 06, 2010 1:17 pm

1st : this is something completely different than the original question.
original = passing 2 variables
new = passing 1 variable of varying length.

2nd: how will n be determined ?
you could just define ls-var1 X(100). in the linkage section
and if N=3 make sure you only use the first 3 pos of ls-var1.
display ls-var1(1:n)
move spaces to ls-var (1:n)

The risk with this (or with your approach adding 1 to an address) is that when
n> actual length of the ws-var in program A you can overwrite other variables or areas of program A.
move spaces to ls-var or in your solution looping 100 times while n = 3
would be a serious mistake.

I wouldn't appreciate such programs in my environment.

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 2:01 pm

often legacy systems have to be changed and usually some manager
has decided that the change is to be implemented with the least amount of
program change.

Some super tech has figured out how to play assembler with cobol and
provides the manager with a 'slick solution' to the problem.
then this idea gets passed to someone with little or no technical abilities.
Missing of course is the code to walk thru control blocks or registers
to pick-up little items like number of parms passed, length of parm, etc...

problem is that the
real cost to program changes is the testing involved
prior to implementation to production. But as we have seen more and more,
this testing is not done.
or as probably in this case, the cost of testing is allocated to another manager.

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

@GuyC

Above logic can be used for two variables also
And getting the exact value of N will not be a problem.

I agree such coding practice shud not be used but I do not have an alternative solution as we are not in a position to make multiple copies of this program B.
Also I could find a similar logic as posted above by me in one of the IBM mainframe sites.

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 3:10 pm

GuyC · Posted: Wed Oct 06, 2010 3:55 pm

two variables (01 levels in WS) are located in memory on two different
adresses (base register & offset). suppose BR1:Offset1 and br2:offset2
If you're lucky and they are defined right after each other in pgmA, then br1 = br2 and offset2 = offset1 + length of var1.
But there is no guarantee that it will be so and remain so after recompile or upgrade of the compiler or something.

So I'm also very interesting how :

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 4:25 pm

GuyC,
you have to remember that the CALLing program generates a transfer instruction
that contains (in registers and/or data areas 'pointed to by the register') the addresses of the USING List, as well as the lengths of each structure.

Bill or another assembler tech will have to provide the exact explanation

the code generated by the PROCEDURE DIVISION USING statement,
loads addresses to associated linkage items.

the info is there, it is not easy in COBOL to access this data,
because the CALL and PROCEDURE DIVISION USING 'macros' do all the interpretation.

as the CALLed program is executed, somewhere, someplace, the allowable address ranges of the CALLing program are available to the OP-System so that it can decide whether to execute the instruction or issue a S0C4.

as i said earlier,
COBOL code to

walk thru the control blocks
access the register contents
interpret the data

is what I wanted AMBy to provide.

it is doable, i have done it years ago with COBOL 2.
it is just such a can of worms and you only need one clown to come along
and change something,
or do something just a little different
and it all becomes a bag of wet s..t!

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 4:32 pm

and as a side note:
the data structure referenced in a CALL USING
does not have to be a level-01. it can be anything except 66 or 88.
actually don't know about 66. I never use them, but they could be acceptable.

the data structure reference in a PROCEDURE DIVISION USING
does have to be

level 01 or 77
in linkage

Amb · New User Joined: 12 Mar 2010 Posts: 64 Location: India

@ GuyC and @DBZ

Sorry for the confusion I agree with you