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:

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.

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. . .

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.

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.

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.

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 wrote:

would you be so kind as to provide the method of determining the value of N
as well as how to provide for more than one variable (multiple parms in USING List).

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!

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